You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Istvan Toth (Jira)" <ji...@apache.org> on 2023/04/28 14:04:00 UTC

[jira] [Created] (PHOENIX-6944) Randomize mapper task ordering for Indexing MR tools

Istvan Toth created PHOENIX-6944:
------------------------------------

             Summary: Randomize mapper task ordering for Indexing MR tools
                 Key: PHOENIX-6944
                 URL: https://issues.apache.org/jira/browse/PHOENIX-6944
             Project: Phoenix
          Issue Type: Improvement
          Components: core
            Reporter: Istvan Toth


Currently, splits are generated by PhoenixInputFormat are in ascending order.
MR does not use this ordering directly, it instead orders the partitions by size in descending order.
We set the sizes of the splits to the region size. (Even when splitting by guideposts, but this not really a problem)
The result is that mapper jobs are grouped by regions, so usually all the mappers running are working on one, or few regions. As a result we have the following problems:

Read hotspotting:
All scan operations for the indexing job hit the same one or few region servers, causing high loads and slowdowns.

Write hotspotting:
If the data rowkeys and index rowkeys strongly correlate, then the data read from one or few data regions will be written to one or few index regions, causing high loads and slowdowns. This is a bit of a corner case, we have obeserved it when building an index for a column which starts with the same bytes as the primary key for the data table.

We can improve this by making sure that the generate mapper jobs are executed in a random order. The only way to change the execution order is to manipulate the length of the splits. As the length is only used for ordering, and calculating completion percentage, this is unlikely to cause problems (we already specify wildly off lengths when splitting by guidepost )



--
This message was sent by Atlassian Jira
(v8.20.10#820010)