Uploaded image for project: 'Phoenix'
  1. Phoenix
  2. PHOENIX-5313

All mappers grab all RegionLocations from .META

    XMLWordPrintableJSON

    Details

      Description

      Phoenix's MapReduce integration lives in PhoenixInputFormat. It implements getSplits by calculating a QueryPlan for the provided SELECT query, and each split gets a mapper. As part of this QueryPlan generation, we grab all RegionLocations from .META

      In PhoenixInputFormat:getQueryPlan:

       // Initialize the query plan so it sets up the parallel scans
       queryPlan.iterator(MapReduceParallelScanGrouper.getInstance());
      

      In MapReduceParallelScanGrouper.getRegionBoundaries()

      return context.getConnection().getQueryServices().getAllTableRegions(tableName);
      

      This is fine.

      Unfortunately, each mapper Task spawned by the job will go through this same exercise. It will pass a MapReduceParallelScanGrouper to queryPlan.iterator(), which I believe is eventually causing getRegionBoundaries to get called when the scans are initialized in the result iterator.

      Since HBase 1.x and up got rid of .META prefetching and caching within the HBase client, that means that not only will each Job make potentially thousands of calls to .META, potentially thousands of Tasks will each make potentially thousands of calls to .META.

      We should get a QueryPlan and setup the scans without having to read all RegionLocations, either by using the mapper's internal knowledge of its split key range, or by serializing the query plan from the client and sending it to the mapper tasks for use there.

      Note that MapReduce tasks over snapshots are not affected by this, because region locations are stored in the snapshot manifest.

        Attachments

        1. PHOENIX-5313-v1.patch
          22 kB
          Chinmay Kulkarni
        2. PHOENIX-5313-4.x-HBase-1.3.patch
          22 kB
          Chinmay Kulkarni

          Issue Links

            Activity

              People

              • Assignee:
                ckulkarni Chinmay Kulkarni
                Reporter:
                gjacoby Geoffrey Jacoby
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 50m
                  50m