Details

    • Type: Improvement Improvement
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: task
    • Labels:
      None
    • Environment:

      x86-64 Linux/Unix

    • Release Note:
      Task level native optimization
    • Tags:
      optimization task

      Description

      I'm recently working on native optimization for MapTask based on JNI.

      The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs emitted by mapper, therefore sort, spill, IFile serialization can all be done in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising results:

      1. Sort is about 3x-10x as fast as java(only binary string compare is supported)

      2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware CRC32C is used, things can get much faster(1G/

      3. Merge code is not completed yet, so the test use enough io.sort.mb to prevent mid-spill

      This leads to a total speed up of 2x~3x for the whole MapTask, if IdentityMapper(mapper does nothing) is used

      There are limitations of course, currently only Text and BytesWritable is supported, and I have not think through many things right now, such as how to support map side combine. I had some discussion with somebody familiar with hive, it seems that these limitations won't be much problem for Hive to benefit from those optimizations, at least. Advices or discussions about improving compatibility are most welcome

      Currently NativeMapOutputCollector has a static method called canEnable(), which checks if key/value type, comparator type, combiner are all compatible, then MapTask can choose to enable NativeMapOutputCollector.

      This is only a preliminary test, more work need to be done. I expect better final results, and I believe similar optimization can be adopt to reduce task and shuffle too.

      1. DESIGN.html
        42 kB
        Binglin Chang
      2. dualpivot-0.patch
        5 kB
        Chris Douglas
      3. dualpivotv20-0.patch
        4 kB
        Chris Douglas
      4. fb-shuffle.patch
        76 kB
        Todd Lipcon
      5. MAPREDUCE-2841.v1.patch
        180 kB
        Binglin Chang
      6. MAPREDUCE-2841.v2.patch
        190 kB
        Binglin Chang

        Issue Links

          Activity

          Todd Lipcon made changes -
          Link This issue is related to MAPREDUCE-5962 [ MAPREDUCE-5962 ]
          Todd Lipcon made changes -
          Assignee Binglin Chang [ decster ] Sean Zhong [ clockfly ]
          Todd Lipcon made changes -
          Attachment fb-shuffle.patch [ 12638882 ]
          Cheng Haowei made changes -
          Environment x86-64 Linux x86-64 Linux/Unix
          Cheng Haowei made changes -
          Description I'm recently working on native optimization for MapTask based on JNI.

          The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs emitted by mapper, therefore sort, spill, IFile serialization can all be done in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising results:

          1. Sort is about 3x-10x as fast as java(only binary string compare is supported)

          2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware CRC32C is used, things can get much faster(1G/

          3. Merge code is not completed yet, so the test use enough io.sort.mb to prevent mid-spill

          This leads to a total speed up of 2x~3x for the whole MapTask, if IdentityMapper(mapper does nothing) is used.

          There are limitations of course, currently only Text and BytesWritable is supported, and I have not think through many things right now, such as how to support map side combine. I had some discussion with somebody familiar with hive, it seems that these limitations won't be much problem for Hive to benefit from those optimizations, at least. Advices or discussions about improving compatibility are most welcome:)

          Currently NativeMapOutputCollector has a static method called canEnable(), which checks if key/value type, comparator type, combiner are all compatible, then MapTask can choose to enable NativeMapOutputCollector.

          This is only a preliminary test, more work need to be done. I expect better final results, and I believe similar optimization can be adopt to reduce task and shuffle too.




          I'm recently working on native optimization for MapTask based on JNI.

          The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs emitted by mapper, therefore sort, spill, IFile serialization can all be done in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising results:

          1. Sort is about 3x-10x as fast as java(only binary string compare is supported)

          2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware CRC32C is used, things can get much faster(1G/

          3. Merge code is not completed yet, so the test use enough io.sort.mb to prevent mid-spill

          This leads to a total speed up of 2x~3x for the whole MapTask, if IdentityMapper(mapper does nothing) is used

          There are limitations of course, currently only Text and BytesWritable is supported, and I have not think through many things right now, such as how to support map side combine. I had some discussion with somebody familiar with hive, it seems that these limitations won't be much problem for Hive to benefit from those optimizations, at least. Advices or discussions about improving compatibility are most welcome:)

          Currently NativeMapOutputCollector has a static method called canEnable(), which checks if key/value type, comparator type, combiner are all compatible, then MapTask can choose to enable NativeMapOutputCollector.

          This is only a preliminary test, more work need to be done. I expect better final results, and I believe similar optimization can be adopt to reduce task and shuffle too.




          Cheng Haowei made changes -
          Description I'm recently working on native optimization for MapTask based on JNI.

          The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs emitted by mapper, therefore sort, spill, IFile serialization can all be done in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising results:

          1. Sort is about 3x-10x as fast as java(only binary string compare is supported)

          2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware CRC32C is used, things can get much faster(1G/s).

          3. Merge code is not completed yet, so the test use enough io.sort.mb to prevent mid-spill

          This leads to a total speed up of 2x~3x for the whole MapTask, if IdentityMapper(mapper does nothing) is used.

          There are limitations of course, currently only Text and BytesWritable is supported, and I have not think through many things right now, such as how to support map side combine. I had some discussion with somebody familiar with hive, it seems that these limitations won't be much problem for Hive to benefit from those optimizations, at least. Advices or discussions about improving compatibility are most welcome:)

          Currently NativeMapOutputCollector has a static method called canEnable(), which checks if key/value type, comparator type, combiner are all compatible, then MapTask can choose to enable NativeMapOutputCollector.

          This is only a preliminary test, more work need to be done. I expect better final results, and I believe similar optimization can be adopt to reduce task and shuffle too.




          I'm recently working on native optimization for MapTask based on JNI.

          The basic idea is that, add a NativeMapOutputCollector to handle k/v pairs emitted by mapper, therefore sort, spill, IFile serialization can all be done in native code, preliminary test(on Xeon E5410, jdk6u24) showed promising results:

          1. Sort is about 3x-10x as fast as java(only binary string compare is supported)

          2. IFile serialization speed is about 3x of java, about 500MB/s, if hardware CRC32C is used, things can get much faster(1G/

          3. Merge code is not completed yet, so the test use enough io.sort.mb to prevent mid-spill

          This leads to a total speed up of 2x~3x for the whole MapTask, if IdentityMapper(mapper does nothing) is used.

          There are limitations of course, currently only Text and BytesWritable is supported, and I have not think through many things right now, such as how to support map side combine. I had some discussion with somebody familiar with hive, it seems that these limitations won't be much problem for Hive to benefit from those optimizations, at least. Advices or discussions about improving compatibility are most welcome:)

          Currently NativeMapOutputCollector has a static method called canEnable(), which checks if key/value type, comparator type, combiner are all compatible, then MapTask can choose to enable NativeMapOutputCollector.

          This is only a preliminary test, more work need to be done. I expect better final results, and I believe similar optimization can be adopt to reduce task and shuffle too.




          Dong Yang made changes -
          Link This issue relates to MAPREDUCE-1270 [ MAPREDUCE-1270 ]
          Binglin Chang made changes -
          Attachment DESIGN.html [ 12512978 ]
          Binglin Chang made changes -
          Link This issue relates to MAPREDUCE-3247 [ MAPREDUCE-3247 ]
          Binglin Chang made changes -
          Link This issue relates to MAPREDUCE-3246 [ MAPREDUCE-3246 ]
          Binglin Chang made changes -
          Attachment MAPREDUCE-2841.v2.patch [ 12492208 ]
          Chris Douglas made changes -
          Attachment dualpivot-0.patch [ 12491994 ]
          Attachment dualpivotv20-0.patch [ 12491995 ]
          Binglin Chang made changes -
          Attachment MAPREDUCE-2841.v1.patch [ 12490790 ]
          Binglin Chang made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Binglin Chang made changes -
          Field Original Value New Value
          Assignee Binglin Chang [ decster ]
          Binglin Chang created issue -

            People

            • Assignee:
              Sean Zhong
              Reporter:
              Binglin Chang
            • Votes:
              4 Vote for this issue
              Watchers:
              53 Start watching this issue

              Dates

              • Created:
                Updated:

                Development