本番環境におけるHDFS Erasure Coding

原文: https://blog.cloudera.com/blog/2019/06/hdfs-erasure-coding-in-production/

著者: Xiao Chen, Sammi Chen, Kitti Nansi, Jian Zhang

Apache Hadoop 3.0で提供された主要な機能であるHDFS Erasure Coding（EC）は、Spark、Hive、MapReduceなどのアプリケーションで使用するために、CDH 6.1でも利用可能です。ECの開発はHadoopコミュニティ全体にわたる長期間の共同作業でした。ECが含まれているCDH6.1は、Clouderaの一流のエンタープライズサポートが加わったことで、顧客はこの新機能を採用することができます。

これまでのバージョンのHDFSは、データの複数のコピーを複製することでフォールトトレランスを実現していましたが（従来のストレージアレイのRAID1と似ています）、HDFSのECは（RAID 5と同様に）パリティセルを使用することで、同等以上のフォールトトレランスを実現しながらストレージのオーバーヘッドを大幅に削減します。ECが導入される前は、HDFSはフォールトトレランスのために3倍の複製（以降、3レプリケーション）を使用していました。つまり1GBのファイルには、3GBのローディスク領域が使用されます。ECを使用すると、同じレベルのフォールトトレランスが1.5 GBのローディスク領域を使用するだけで実現できます。その結果、この機能によって 、Hadoopを使用するためのTCOが大幅に変わることが期待されています。

このブログは、以前のECの紹介ブログ（英語）と進捗報告フォローアップ記事です。最新のパフォーマンステストの結果、ECの本番環境の準備、およびデプロイの際の考慮事項に焦点を当てています。この記事ではECに関する以前の記事をご覧いただいており、すでにECについて基本的な理解を得ている読者をを想定しています。

用語

過去の2つのブログ記事で使われているこれらの用語は、本記事を読むのに役立つでしょう。

• NameNode (NN) ：ファイルとブロックの名前空間とメタデータを管理するHDFSのマスターサーバー
• DataNode (DN)：ファイルのブロックを格納するサーバー
• 複製 ：デフォルトで複製係数3（つまり3レプリケーション）を使用する、HDFSでの従来からの複製ストレージ方針
• ストライプ/ストライピング ：HDFS ECによって導入された新しいストライプブロックレイアウト形式 。従来のレプリケーションで使用されている、デフォルトの連続(contiguous)ブロックレイアウトを補完する
• リードソロモン(RS)：デフォルトの消去符号化コーデックアルゴリズム
• Erasure Codingポリシー：このブログ記事ではErasure Coding (消失符号化) ポリシーを説明するために以下を使用します。

• <codec>-<データブロック数>-<パリティブロック数>-<セルサイズ> 。たとえば RS-6-3-1024k
• <codec>(<データブロック数>,<パリティブロック数>) 。たとえば RS(6, 3)

詳しくはこのドキュメントを参照してください 。

• レガシーコーダー：FacebookのHDFS-RAIDプロジェクトから誕生した、レガシーのJava RSコーダー
• ISA-L：SSE、AVX、AVX2、AVX-512のようなIntelの命令セット用の、パフォーマンス最適化を提供するRSアルゴリズムを実装したIntelストレージアクセラレーションライブラリー
• ISA-Lコーダー ：Intel ISA-Lライブラリーを活用するネイティブのRSコーダー
• 新しい Java コーダー ：リードソロモンアルゴリズムのピュアJava実装（必要なCPUモデルがないシステムに適している）。このコーダーはISA-Lコーダーと互換性があり、JVMの自動ベクトル化機能も利用する。

性能評価

次の図は、ClouderaとIntelが（2つのユースケースを除く）ほぼすべてのユースケースでEC性能をテストするために使用しているハードウェアとソフトウェアのセットアップの概要を示しています。障害からのリカバリおよびSparkのテストは、以降の対応するセクションで説明する、異なるクラスターのセットアップ環境で実行しました。

次の表はハードウェア構成の詳細を示しています。 すべてのノードは同じToRスイッチの同じラック上にあります。

テストの結果

以下のセクションでは TeraSuite の結果を紹介します。このテストではECと3レプリケーションのパフォーマンスを比較します。このテストには、障害からの回復、および利用可能な異なるECコーデックのパフォーマンスの比較が含まれています。また、レプリケーションとECをさまざまなコーデックで比較した時のI/Oパフォーマンステストの結果、TPC-DSテストの結果、および異なるファイルサイズによるECのパフォーマンスへの影響を測定した、エンドツーエンドのSparkのテストの結果を紹介します。

以降のテストは単一ラックのクラスターで実行しました。ECのパフォーマンスは複数ラック環境で使用する場合に影響を受ける可能性があります。Erasure Codingのデータでは、読み取り、書き込み、およびデータの再構築がすべてリモートで行われるためです。

TeraSuite

レプリケーションとECでのエンドツーエンドのパフォーマンス比較について洞察を得るために、MapReduceに含まれるTeraSuiteテストスイートのTeraGenとTeraSortを使用して一連のテストを実行しました。 TeraGenは書き込み専用のテスト、TeraSortは読み取りと書き込みの両方の操作を使用する、書き込み負荷の高いテストであることに注意してください。デフォルトでは、TeraSortは複製係数 1で出力ファイルを書き込みます。実験の目的で複製のテストを2回行いました。1回目は出力ファイルに対してデフォルトの複製係数1を用い、もう1回は出力ファイルに複製係数3を用いました。それぞれのテストにつき5回の試験を実施しました。以下はそれらの結果の平均値です。TeraSuiteのテストは1TBのデータを使用するように設定しています。

次の表はジョブの詳細構成を示しています。

上記の結果は、TeraGenではECがレプリケーションよりも50%以上も速く実行されたことを示しています。ECは、並列書き込みと書き込みデータ量の大幅な削減の恩恵を受けています。3レプリケーションが元データサイズの300％を占めるのに対してECは元データサイズの150%を占めますが、それでも同じレベルの耐障害性を提供しています。

TeraSortテストでは2種類の異なる実行を行いました。1つ目はすべてのDataNodeが稼働している状況でのテスト、2つ目はTeraSortのテストの実行前に、ランダムに選択した2台のDataNodeを手動でシャットダウンしてのテストです。障害があるDataNodeでのTeraSortテストでは、ECは3レプリケーションと比較して50％以上高速に実行されました。3レプリケーションで出力ファイルの複製係数を1に設定した場合では同等のパフォーマンスを達成しました。3レプリケーションに設定した出力ファイルを用いるTeraSortテストでは、予想どおり、1レプリケーションの出力ファイルを使用するデフォルトのTeraSortよりも40％遅く実行されたことに注意してください。3レプリケーションのテストでは、1レプリケーションに設定した出力ファイルを使用するテストの3倍のデータが書き込まれるためです。

9台のDataNodeのうち2台をシャットダウンした場合のECのパフォーマンスは、9台のDataNodeすべてが稼働している場合の結果とほぼ同じです。これが類似しているのは、計測したエンドツーエンドの時間が、主にストレージ時間だけでなくジョブの実行時間も含まれているためです。2台のDataNodeをシャットダウンしましたが、NodeManagerは実行されており、計算能力は同じでした。したがって「オンザフライ」での再構築のオーバーヘッドは、計算処理のオーバーヘッドと比較した場合には無視できるほど小さいものです。

コーデックマイクロベンチマークの結果

Erasure Codingの計算を実行するコーデックは、HDFS ECの重要なアクセラレーターになる可能性があります。エンコードとデコードはかなりCPU負荷が高く、読み取り/書き込みパスのボトルネックになる可能性があります。HDFS ECはリードソロモン（RS）アルゴリズムを使用し、デフォルトではRS(6,3)のスキームを使用します。次の図では、Intel ISA-Lコーダーが新しいJavaコーダーとレガシーコーダーの両方を大幅に上回ることを示しています。これらのテストは、使用率が100％の1CPUコアで、上記と同じハードウェアプロファイルで行いました。

シングルスレッドの場合、エンコードとデコードの両方のベンチマークにおいて ISA-Lコーダーは新しいJavaコーダーの約16倍性能が良く、同時40スレッドでも約8倍性能が良い結果となりました。従来のコーダーと比較して、シングルスレッドの場合は約70倍、同時40スレッドの場合は約35倍になりました。これらの結果により、HDFS EC用のISA-Lコーダーを活用することはあらゆるユースケースに大きな価値を提供します。ISA-LはCDH 6.1に同梱され、デフォルトで有効になっています。

並列性が異なるベンチマークに加えて、さまざまなバッファサイズを用いていくつかの追加テストを行いました。シングルスレッドの場合、64 KBまたは128 KBのバッファサイズが、1024 KBのバッファサイズよりも約8％優れていることがわかりました。これはシングルスレッドテストがCPUキャッシュの恩恵を最も受けていたためと考えられます。5つ以上の同時スレッド数の場合、1024 KBのバッファサイズが最高のパフォーマンスをもたらしました。このため、HDFSのデフォルトのECポリシーはすべて1024 KBのセルサイズを持つように構成されています。

訳注: セルサイズの変更はHDFS-12303で議論されました。バッファサイズはこのコードで定義されています。1024KB(1MB)のセルサイズは固定されており変更できません。

DFSIO

3レプリケーションとECのスループットを比較するために、DFSIO（Hadoopの分散I/Oベンチマーク）で一連のテストを実行しました。このテストでは、異なる数のMapperでそれぞれのMapperが25GBのファイルを処理します。各テストを実行する前にオペレーティングシステムのキャッシュをクリアしました。結果は全体の実行時間を記録しました。DFSIOテストではデータローカリティが使用されないため、本番環境のユースケースでは結果が多少異なるかもしれません。というのも、本番環境ではレプリケーションがデータローカリティの恩恵を受けることができるのに対し、ECではそうではないからです。

ISA-Lを使用するECは、読み取りテストと書き込みテストの両方において、一貫して3レプリケーションよりも優れていました。

Mapperが1つだけの場合、ECは読み取りテストで3レプリケーションを300％上回りました。Mapperの数を増やすと、ECは3レプリケーションよりも約30%速くなります。これはMapperの同時実行性が高いと、ディスクI/Oの競合が多くなり全体のスループットが低下するためです。また、Mapper1つだけを使用した場合、クラスター間のディスク使用率は、レプリケーションよりもECを使用した場合の方が5倍以上高いことがわかりました。40個のMapperを使用した場合、ディスク使用率は同様で、ECのパフォーマンスがわずかに向上しました。

書き込みテストでは、Mapperの数が少ない場合、3レプリケーションは新しいJavaコーデックを使用したECよりもパフォーマンスが優れていましたが、ISA-Lを使用したECよりも30％から50％遅くなりました。 40個のMapperを使用した場合、3レプリケーションが最も遅く、ECの実行時間の倍以上を要しました。これは2倍のデータ量を書き込む必要があるためです。(300％対150％)

TPC-DS

さまざまなクエリのパフォーマンスに関する洞察を得るために、Hive on Sparkを使用して包括的なTPC-DSのテストを実施しました。テストはORCとテキストの両方のフォーマット（のデータに対して）実行しました。すべてのテストを3回実行し、以下の結果はそれらの平均になっています。好奇心が強い方のために、完全な結果はこのスプレッドシートにあります。

TPC-DSの実行結果では、ほとんどの場合、ECのパフォーマンスはレプリケーションよりもわずかに悪くなっています。全体的なパフォーマンス低下の重要な要因の1つはErasure Codingデータの読み書きのリモート性です。ECのパフォーマンスが20％以上遅くなるCPU集中型のクエリがいくつかありました。これらのクエリを実行する際、CPUがほぼ完全に使用されました。Erasure Codingデータの書き込みは、パリティブロック計算のためにCPUの使用量が多くなるため、実行時間が長くなります。それらのクエリはテキストフォーマットのクエリ番号28、31、および88です。同様の理由により、ORCファイルフォーマットを使用した場合、Erasure Codingでテスト結果が少し悪くなりました。これはORCファイルで使用されるデータ圧縮により全体的なCPU使用率が増えためです。

Spark

さまざまなファイルサイズでの、エンドツーエンドのSparkジョブにおけるECのパフォーマンスをより良く理解するために、Erasure CodingのRS(10,4)のポリシーを使用し、20ノードの異なるクラスター上で、TeraSortとSparkのワードカウントを用いていくつかのテストを行いました。各テストでは全体的なデータ量が固定されていますが、テスト用に異なるファイルサイズとファイル数を設定しています。TeraSortには600GBのデータを、ワードカウントには1.6TBのデータを使用することにしました。3つの一連のテストを実行し、ブロックサイズ（128MB）よりはるかに小さい、またはそれに近い、あるいは何倍も大きいファイルサイズをシミュレートしました。この記事の残りの部分では、これら3つの一連のテストをそれぞれ、小規模、中規模、大規模ファイルのテストと呼びます。

次の表は、テストで使用したさまざまなファイルサイズの一覧です。

両方のグラフの「Gen」とはそれぞれのジョブ実行のためにファイルを作成することを意味します。これは書き込み負荷の高いワークロードです。「Sort」と「Count」は、HDFSから入力ファイルの読み取り、タスクの実行、および出力ファイルの書き込みを含むジョブの実行を意味します。前述のようにワードカウントジョブの出力ファイルサイズは通常とても小さく、数百バイトの範囲です。

上記のTeraSortのグラフから、中規模および大規模ファイルのテストではECが3レプリケーションよりも優れていることがわかります。ただし小規模ファイルのテストでは、複数のDataNodeから多くの小さいブロックを同時に読み取ることによる多くのオーバーヘッドが発生するため、ECはレプリケーションよりもパフォーマンスが悪くなっています。Erasure Codingのデータとレプリケーションされたデータの両方について、TeraSortでは中規模ファイルよりも大容量ファイルの方がわずかにパフォーマンスが低下していることに注意してください。

ワードカウントの実行でも同様の結果が見られました。ワードカウントジョブの出力ファイルは非常に小さいため、ECは一貫して3レプリケーションよりも劣ったパフォーマンスを示しました。これは、(後述の）「本番環境における考慮事項」の「ファイルサイズとブロックサイズ」のセクションで説明するNameNodeのメモリ負荷の増加を考慮すると当然のことです。さらに、ファイルサイズがECのセルサイズよりも小さい場合（デフォルトでは1 MB）、ECのファイルはデータをそのすべてのパリティブロックに複製するためにフォールバックしなければならず、事実上、RS(6,3)では4つの同一の複製が、RS(10,4)では5つの同一の複製が生成されます。詳細については「ファイルサイズとブロックサイズ」を参照してください。

障害のリカバリ

ECのブロックの1つが破損すると、HDFSのNameNodeは問題のあるECのブロックを再構築するために、問題のブロックを再構築するようDataNodeのためにreconstructionと呼ばれる処理を開始します。この処理は、NameNodeが、レプリケーションを使うファイルがunder-replicatedとなっているときに行う複製作業に似ています。

ECのブロックの再構築処理は以下の手順からなります。

1. 破損したECのブロックはNameNodeによって検出され、NameNodeはリカバリ作業をDataNodeの1つに委任します。
2. ポリシーに基づいて、残りのデータおよびパリティブロックの最小必要数が並列に読み取られ、これらのブロックから新しいデータブロックまたはパリティブロックが計算されます。Erasure Codingのデータの場合、各データブロックとパリティブロックは異なるDataNode、理想的には異なるラックにも存在するため、再構築はネットワーク負荷の高い処理になることに注意してください。
3. 復号化が終了すると、リカバリされたブロックがDataNodeに書き込まれます。

ECに関する一般的な懸念事項の1つは、reconstructionによってクラスター全体の多くのリソース（CPU、ネットワーク）が消費される可能性があり、DataNodeが停止することでパフォーマンスが低下したりリカバリが遅くなる可能性があることです。reconstrucdtionに使用されるデータとパリティブロックは異なるDataNode、および通常は異なるラックに分散されるため、Erasure Codingのデータのreconstructionはレプリケーションよりもはるかにネットワーク負荷が高くなります。十分な数のラックがある理想的な構成では、Erasure Codingされた論理ブロックの各ストレージブロックは異なるラックに分配されます。したがってreconstructionでは、複数の異なるラックからストレージブロックを読み取る必要があります。たとえば、RS(6,3)を用いる場合、ブロックをreconstructionするには6つの異なるラックからデータを取得する必要があります。Erasure Codingのデータのreconstructionは、別の場所から単にコピーするだけではなく新しいブロックを計算する必要があるため、レプリケーションよりもCPUに負荷がかかります。

reconstructionの影響を観察するためにテストを行いました。20ノードのクラスターのうちの1台のDataNodeをシャットダウンし、通常の3レプリケーションに対して、Erasure CodingのRS(3,2)のポリシーを使用したリカバリの速度を測定しました。Erasure Codingのデータの場合、3レプリケーションよりもリカバリに6倍の時間がかかりました。

通常3レプリケーションよりもErasure Codingのデータの方がリカバリは遅くなりますが、よりフォールトトレラントなポリシーが使用されている場合はそれほど重要ではありません。例えばRS(6,3)が使用されていて1つのブロックが失われた場合、さらに2つのブロックのロストを許容することができます。したがって、高い耐障害性はreconstructionの優先度を下げ、データ損失のリスクを増やすことなく遅いペースでreconstructionを行うことを可能にします。データブロックとパリティブロックそれぞれが異なるラックに分散されるのに十分なラックがある場合、ラックをロストすることについても同じことが言えます。Erasure Codingのデータがラック間でどのように分散されるかについては、詳細はこのブログ記事後半の「ローカリティ（局所性）」セクションをご参照ください。

Apache HDFSのドキュメントに記載されているパラメータは、reconstruction処理をきめ細かく制御するために調整できます。

本番環境に関する考慮事項

ストレージの効率性と単一ジョブのパフォーマンスに加え、本番環境にErasure Codingを実装するかどうかを決定する際は他にも多くの検討事項があります。既存のデータをECに移行する方法についてはClouderaのドキュメントを参照してください。

ローカリティ（局所性）

データローカリティはHadoopにとって当初から非常に重要な概念でした。データが複製される従来のHDFSでは、HDFSのブロック配置ポリシーにより、書き込み操作を実行しているノードにレプリカの1つを配置して、NameNodeは読み手に最も近いレプリカから読み取り要求を満たそうとします。可能な場合には、このアプローチによりクライアントアプリケーションはデータのローカリティを利用してネットワークトラフィックを減らすことができます。DataNodeには、ローカル読み取りをさらに最適化するための「ショートサーキットリード」などの機能もあります。

Erasure Codingファイルの場合、すべての読み取りおよび書き込みは、必ずリモートネットワークトラフィックになります。実際には、ブロックは通常リモートホストからだけでなく、複数の異なるラックからも読み取られます。

デフォルトでは、ECはレプリケーションとは異なるブロック配置ポリシーを使用します。ラック・フォールトトレラントなブロック配置ポリシーを使用します。つまり、データはラック全体に均等に分散されます。Erasure Codingのブロックは、データストライプ幅と同じ数の異なるDataNodeに分散されます。データストライプ幅は、Erasure Codingのポリシーで定義されているデータブロック数とパリティブロック数の合計です。データストライプ幅よりもラック数が多い場合、Erasure Codingのブロックは、データストライプ幅に等しいランダムに選択された多数のラックに格納されます。つまり、各DataNodeは異なるラックから選択されます。ラック数がデータストライプ幅より小さい場合、各ラックには(データストライプ幅／ラック数)の値より少し大きな数のストレージブロックが割り当てられます。残りのストレージブロックは、論理ブロック用の他のストレージブロックを保持していない他のDataNodeに分配されます。詳細についてはClouderaのドキュメントECのためのラックとノードのセットアップのベストプラクティス( Best Practices for Rack and Node Setup for EC)をご参照ください。

このため、ECはラック間の帯域幅がオーバーサブスクライブされていない環境、またはオーバーサブスクリプションが非常に少ない環境で最適に動作します。ラック全体に分散配置されるECファイルが増えてくる場合はネットワークのスループットを慎重に監視する必要があります。この影響は、ClouderaがコールドデータでECを使うことを推奨する大きな理由の1つでもあります。詳細についてはClouderaのドキュメントを参照してください。

ファイルサイズとブロックサイズ

ECに関するその他の重要な考慮事項はファイルサイズとブロックサイズです。CDHのHDFSのブロックサイズはデフォルトで128 MBです。レプリケーションの場合、ファイルは128MBのチャンク（ブロック）に分割されて異なるDataNodeに複製されます。しかし、それぞれの128MBのブロックは内部で完結しており、直接読み取って使用することができます。ECの場合、ベースとなるデータブロックとパリティブロックのそれぞれが、異なる128MBの通常のブロックに配置されます。ブロックからデータを読み取るということは、ブロックグループ内のすべてのブロックからデータを読み取ることを意味します。ブロックグループのサイズは（128 MB * データブロック数）です。たとえば、RS(6, 3) のブロックグループのサイズは768 MB（128 MB * 6）です。

このモデルがNameNodeのメモリ使用量、特にNameNodeブロックマップ内のブロック数に与える影響を考慮することが重要です。ECの場合、小さなファイルではバイト数/ブロック数の比率が悪くなり、NameNodeのメモリ使用量が増加します。RS(6, 3) の場合、NameNodeは10MBのファイルに対して、768 MBのファイルの場合と同じ量のブロックオブジェクト、つまり9個のブロックオブジェクトを格納します。3レプリケーションと比較すると、3レプリケーションの10MBのファイルはNameNodeに3個のブロックオブジェクトが存在することを意味します。 EC (RS(6,3))を使用する10MBのファイルは、NameNode内に9個のブロックオブジェクトがあることを意味します。

データブロックの値×セルサイズ（RS(6,3)の場合は 6 * 1MB)よりもサイズが小さい非常に小さなファイルでは、バイト数/ブロック数の比率も悪くなります。これはパリティブロックの数が常に同じであるにも関わらず、実際のデータブロックの数がErasure Codingのポリシーで定義されているデータブロックよりも少ないためです。たとえば、セルサイズが1 MBのRS(6,3)の場合、1 MBのファイルは6個ではなく1個のデータブロックで構成されますが、パリティブロックは3個あります。したがって、1MBのファイルには合計4個のブロックオブジェクトが必要です。3レプリケーションを使用した場合、同じファイルに必要なブロックオブジェクトは3個だけです。図12と図13では、さまざまなファイルサイズのブロック数が確認できます。

上の図に示すように、ブロック数はレプリケーションのファイルサイズに比例しますが、ストライピングレイアウトの性質上、ECはステップ関数になります。このため、ECは多くのスモール・ファイルを含むクラスターでNameNodeに対するメモリー負荷を悪化させる可能性があります。（スモール・ファイルの問題に関する詳細は 以前のブログ記事をご覧ください）。大きなファイルはECに適しています。これは、１ファイルの格納のために必要なブロックがブロックグループに対して割り当てられるので、それぞれのブロックグループに含まれるブロック数が均質になるためです。理想的なワークフローには、スモール・ファイルを1つの大きなファイルにマージして圧縮し、その圧縮された大きなファイルにECを適用するプロセスが含まれます。詳細については、Hiveを使用したスモールファイルの圧縮に関するドキュメントを参照してください。

デコードとリカバリ

HDFSでErasure Codingのファイルを読み取るとき、データブロックから読み取って論理ブロック（ファイルのコンテンツ）を構築することは、ECのエンコードとデコードのコストを支払う必要がありません。ただし、データブロックを保持しているDataNodeがダウンしている、またはブロックが破損していて再構築中などの理由でデータブロックのいずれかを読み取ることができない場合、HDFSはパリティブロックから読み取って論理ブロックにデコードします。問題のあるデータブロックは後で非同期で再構築されますが、デコードにはある程度CPUが消費されます。 図 4は、このデコードより全体的なパフォーマンスにわずかなオーバーヘッドが加わっています。

まとめ

Erasure CodingはHDFSのストレージ領域のオーバーヘッドを大幅に低減できます。また、適切なサイズのファイルに対して正しく使用される場合、より高いスループットのために高速なネットワークをよりよく利用することができます。最良のシナリオでは、Intel ISA-LライブラリとHadoopのISA-Lコーダーを使用すると、完全に十分な帯域幅を持つネットワークにおける読み取りおよび書き込みのパフォーマンスは、大きなファイルに対する従来の3レプリケーションよりも向上すると予想されます。ClouderaはErasure CodingをCDHに統合し、ファーストクラスのエンタープライズサポートを提供しています。ただし、お客様側で現在のHDFSの使用状況を評価し、それに応じてECにファイルをオンボードする計画を行うことを強くお勧めします。この場合、スモール・ファイルをECに使用すると、スモール・ファイルの問題が悪化することに注意してください。

CDHでHDFSイレイジャーコーディングを設定する方法に関するステップバイステップガイドについては Clouderaのドキュメントを参照してください。Hiveでイレイジャーコーディングを使用するためのベストプラクティスについては こちらのドキュメントを参照してください。

Xiao ChenはApache Hadoop PMCのメンバーです。
Sammi ChenはApache Hadoop PMCのメンバーです。
Kitti NanasiはClouderaのソフトウェアエンジニアです。
Jian Zhangは、Intelのソフトウェアエンジニアです。