Apache Hadoopエコシステムにおける、異なるファイル形式とストレージエンジンのパフォーマンス比較 [翻訳記事]
著者/Author: Zbigniew Branowski (Cern)
Zbigniew Baranowskiはデータベースシステムの専門家であり、CERNでセントラルデータベースとHadoopベースのサービスを提供、サポートしているグループのメンバーです。 このブログはもともとCERNの「Databases at CERN」ブログで公開されており、CERNの許可を得てここで公開されています。
トピック
この記事では、Apache Hadoopエコシステムで利用可能ないくつかの一般的なデータフォーマットとストレージエンジンのパフォーマンスの比較を示しています。スペースの効率性、データのインジェスト（取り込み）性能、分析スキャンやランダムデータの検索の分野において、Apache Avro、Apache Parquet、Apache HBase、Apache Kuduを比較します。これは、あなたの大きなデータワークロードの処理をそれぞれがどのように（そしていつ）改善できるかを理解するのに役立ちます。
はじめに
Hadoopのファイル形式とストレージエンジンの比較を行うための最初のアイデアは、CERN（ATLAS EventIndex）でHadoopを大規模に採用した最初のシステムの1つを改訂することによるものでした。
このプロジェクトは、MapReduceでCSVを処理することがビッグデータを処理する一般的な方法であった2012年に開始されました。その時点では、Apache Spark、Apache Impala（インキュベート中）、AvroやParquetのようなファイル形式は、今日のように成熟したものではなく普及していませんでした。従って、振り返ってみると、HDFSで MapFilesを使用することに基づいて選択された設計は「古く」なり、あまり一般的ではなくなってます。
ATLAS EventIndexデータを使用したテストの最終的な目標は、データを格納するためのどのアプローチを適用するのが最適か、システムの主なユースケースに関するこのようなアプリケーションの期待される利点を理解することでした。比較したい主な側面は、データの量とパフォーマンスでした。
- データのインジェスト（取り込み）
- ランダムデータの検索
- フルデータスキャン
EVENTINDEXのデータについて
ATLAS粒子加速器である大型ハドロン衝突型加速器のために構築された粒子検出器実験の1つです。
ATLAS EventIndexは、ATLAS実験で発生したすべての衝突-コリジョン（「イベント」と呼ばれる）のメタデータカタログであり、後からCERNストレージインフラストラクチャ内に永続的に格納されることが認められています（通常、数百イベント/秒）。物理学者は、このシステムを使用して関心のある事象を特定し、その事象集団を共通点でグループ化し、生産サイクルの一貫性をチェックします。
各インデックス付きのコリジョンは、ATLAS EventIndexに平均1.5KBの長さで56個の属性を持つ、独立したレコードとして格納され、そのうちの6個がコリジョンを一意に識別します。属性のほとんどはテキスト型ですが、そのうちいくつかは数値です。与えられた瞬間には、数十テラバイト（データ複製を含まない）を占めるHDFSに保存されている6e10個のレコードがあります。
HADOOPでテストしたストレージのアプローチ
異なるストレージ技術と圧縮アルゴリズム（Snappy、GZipまたはBZip2）を使用して、同じデータセットが同じHadoopクラスタに格納されています。
・Apache Avroは、HDFSに永続データを格納するため、および通信プロトコルに広く使用されている、コンパクトなバイナリ形式のデータシリアライゼーションの標準です。Avroを使用する利点の1つは、軽量で高速なデータのシリアライズとデシリアライズであり、非常に優れた処理性能を提供できます。さらに、MapFileのような内部インデックスがなくても、高速なランダムデータアクセスが必要な場合はHDFSのディレクトリベースのパーティショニング手法を適用して、目的のコレクションにすばやくナビゲートできます。
テストでは、主キーの最初の3列のタプルをパーティションキーとして使用しました。これにより、パーティション数（数千）と平均パーティションサイズ（数百メガバイト）のバランスが良好になりました。
・Apache Parquetは、効率的なデータ分析のための列指向のデータシリアライゼーションの標準です。追加の最適化には、エンコード（RLE、ディクショナリ、ビットパッキング）と、同一の列の一連の値に適用される圧縮が含まれており、非常に良好な圧縮率が得られます。HDFSにParquet形式のデータを格納する場合、Avroの場合と同じパーティショニング戦略を使用しました。
・Apache HBase -キーと値のペアを格納するための、HDFS上のスケーラブルで分散したNoSQLデータベース。キーは索引付け（インデックス）されているため、レコードに非常に迅速にアクセスできます。
ATLAS EventIndexデータをHBaseに格納する際、各イベントの属性は別のセルに格納され、行キーはイベント識別属性列を連結して構成しました。さらに、行キー（DATA_BLOCK_ENCODING）の差分（FAST_DIFF）エンコーディングは、HBaseブロックのサイズを小さくするために有効化されています（これがない場合は8KBの長さになります）。
・Apache Kuduは、新しい、スケーラブルかつ分散されるテーブルベースのストレージです。Kuduは、インデックスとカラムナのデータ構成を提供し、インジェストの速度と分析パフォーマンスとの間での良好な妥協を達成します。HBaseの場合と同様に、KuduのAPIはすでにシステムに保存されているデータを変更することができます。
この評価では、すべてのリテラル型は辞書エンコーディング、およびビットシャッフルエンコーディングを伴う数値型で格納しました。さらに、レンジ・キーとハッシュ・パーティションの組み合わせは、主キーの最初の列（HBaseの場合のような同じ列で構成されています）をパーティション・キーとして使用して導入しました。
得られた結果
データアクセスおよび処理テストは、以下の14台の物理マシンで構成されたクラスター上で実施しました：
- 2 × 8 cores @2.60GHz
- 64GBのメモリ
- 2×24 のSASドライブ
HadoopクラスタはCloudera Enterprise Data Hub (CDH) 5.7.0をインストールしました。これには次のものが含まれます。
- Hadoop core 2.6.0
- Impala 2.5.0
- Hive 1.1.0
- HBase 1.2.0 (リージョンサーバーのJVMのヒープサイズは30GBに設定)
- （CDHからではない）Kudu 1.0（メモリ制限= 30GBに設定）
このレポートの後半に掲載されたすべての実施テストでは、Apache Impala（インキュベーション中）をデータの取り込みとデータアクセスフレームワークとして使用しました。
重要：可能な限り正確な結果を得るために努力をしていますが、テストされた技術の普遍的な基本ベンチマークとしてこれらを扱うべきではありません。テストに影響を与える可能性のある変数が多すぎるため、以下のような固有のケースが増えます。
- 選択されたテストケース
- 使用されたデータモデル
- ハードウェアの仕様と構成
- データ処理およびその構成/チューニングに使用されるソフトウェアスタック
フォーマットごとのスペース使用率
テストの説明：異なるテクニックと圧縮を使用して（数百万レコードの）同じデータセットを保存した後の平均レコードサイズを測定。
コメント：
- 測定結果によると、KuduとParquetでエンコードされたデータが最高の圧縮率を示しました。SnappyやGZipなどの圧縮アルゴリズムを使用すると、MapFilesを使用した元のデータセットのエンコーディングと比べてさらに10倍も大幅にボリュームを減らすことができます。
- HBaseはデータを保存する方法により、スペース効率の良いソリューションです。HBaseブロックの圧縮率は非常に良いですが、KuduとParquetで得られた圧縮率からはまだ離れています。
- Apache AvroはMapFileのような他のHDFSへの行ストア(row store)のように、スペース占有率に関しても同様の結果をもたらします。
フォーマットごとの取り込み速度
テストの説明：単一のデータパーティションへのレコードの取り込み速度を測定する。
- Apache Impalaは、単一のHDFSディレクトリ（Hiveパーティション）にシリアルで書き込むためにデータの再編成を実行するので、HDFSフォーマットとHBaseまたはKuduで得られた結果は、単一のデータパーティションの取り込み効率性のフィールドで直接比較できます。
- AvroまたはParquetでエンコードされたHDFSファイルへの書き込みは、HBaseやKuduのようなストレージエンジンよりもはるかに優れた結果を出しました（少なくとも5倍）。Avroは最も軽量のエンコーダを備えているため、最高の取り込み性能を実現しました。
- 他方では、このテストにおけるHBaseは非常に遅い（Kuduより悪い）です。ここれは行キー（6個の連結された列）の長さに起因する可能性が最も高く、平均で約60バイトでした。HBaseでは行の各列のキーを別々にエンコードする必要があります。これは、長いレコード（多数の列を持つ）に対しては最適ではない可能性があります。
フォーマットごとのランダムなデータルックアップ時間
テストの説明：レコード識別子（複合キー）を提供することでレコードから非キーの属性を取得する。
コメント：
- レコードキーでデータにアクセスする場合、組み込みのインデックスを使用しているためKuduとHBaseが最も高速でした。プロット上の値はコールドキャッシュ（キャッシュに乗っていない）で測定しました。
- ランダムなルックアップテストにApache Impalaを使用すると、実際に実行されるより前に、クエリ（計画、コード生成など）の設定にかなりの時間が費やされるため、KuduとHBaseには最適ではありません。これは通常は約200msです。従って、低レイテンシのデータアクセスの場合、Impalaをスキップして専用APIを使用することをお勧めします（KuduとHBaseでのこのアプローチと結果は同様でした）。コールドキャッシュでは <200ms、ウォームアップされたキャッシュでは<80msでした）。
- KuduとHBaseとは対照的に、Avro形式で保存された個々のレコードからデータを取得することは、データパーティション全体をブルートフォーススキャンすることでしか行えません（データはレコードキーの一部によって分割されるため、このような場合パーティションプルーニング（刈り込み）が適用されます）。平均パーティションサイズはGB単位であるため、必要なレコードを取得するには数秒（IOスループットに依存）かかり、かなりの量のクラスタリソースが使用されます。これは、最終的に、クラスタ上でフルスピードで実行されなければならない同時クエリの数を減少させます。
- Parquetにも同じ問題が当てはまりますが、カラムナの性質上、パーティションのスキャンを比較的高速に実行できます。列のプロジェクションと列の述語プッシュダウンのおかげで、スキャンの入力セットは、最終的にGBからわずか数MBに削減されました（実際には56のうち3つの列だけがスキャンされました）
フォーマットごとのデータスキャンレート
テストの説明：レコードコレクション全体の非キー列の1つで特定の部分文字列を持つレコードの数を数える
コメント：
- 列のプロジェクションを適用して入力が減ったため、このテストでのParquetはAvroを置き去りにしました。コアごとの処理速度の点で最も効率的であっただけでなく、処理を完了するのも最も速い処理速度でした。
- ParquetとAvroの場合、データアクセスの並列化の単位はHDFSのファイルブロックです。Hadoopクラスタで使用できるすべてのリソースに処理を均等に分散することができます。
- スキャンの効率の観点から、Kudu（Snappy 圧縮あり）はParquetとはあまりかけ離れてはいませんでした。 これは、列のプロジェクションから利益を得ています。
- KuduとHBaseに格納されたデータのスキャンは、並列化の単位が両方の場合テーブルのパーティションであるため、不均衡になる可能性があります。 従って、スキャンに含まれるリソースの量は、指定されたテーブルのパーティションの数、およびクラスタ全体の分散に依存します。
- このテストケースでは、使用された述語をKuduがサポートしていなかったため、Kuduのネイティブな述語プッシュダウン機能を使用することはできませんでした。 追加のテストでは、サポートされている述語が使用されている場合、KuduのスキャンがParquetよりも高速になる可能性があることが証明されました。
- HBaseでテストを実行する前に、スキャンされる列を専用のHBaseの列ファミリーに分離しました。これは5倍のスキャン効率の改善です。ParquetやKuduからはまだだいぶ離れています。
試験から学んだ教訓
ここでは、参照ワークロードによるテストから浮上したデータフォーマットの長所と短所を考慮して、データフォーマットの使用に関する追加の考慮事項を共有したいと思います。
- ストレージの効率性 — ParquetまたはKuduでSnappy圧縮を使用すると、圧縮されていないシンプルなシリアライズフォーマットと比較して、データの総容量を10倍減らすことができます。
- データの取り込み速度 — — テストされたすべてのファイルベースのソリューションでは、特殊なストレージエンジンまたはMapFiles（ソートされたシーケンス）よりも速い処理速度（x2〜x10）を提供しています。
- ランダムデータアクセス時間 — HBaseまたはKuduを使用した典型的なランダムデータのルックアップの速度は500ms以下です。ParquetはHDFSの名前空間を賢く分割することにより秒レベルでランダムな検索を行うことができますが、より多くのリソースを消費します。
- データ分析 — ParquetやKuduを使用すると、データの集約、フィルタリング、レポート作成など、高速でスケーラブルな（通常、CPUコアあたり300kを超えるレコード数）を実行することが可能です。
- インプレースでのデータ変更のサポート — HBaseおよびKuduは、HDFSファイルに直接格納されたデータでは不可能な、インプレースでレコード（スキーマおよび値）を変更できます
特に圧縮アルゴリズムは、データ量の削減だけでなく、データ取り込みとデータアクセスのパフォーマンスの向上にも重要な役割を果たしました。 これらすべてのフィールドで、 Snappyコーデックはテストされたすべてのテクノロジで最良の結果をもたらしました。圧縮なしのプレーンなエンコーディングよりもかなり優れています。（Avroの場合を除く）
結論
Hadoopエコシステムで人気のある格納のテクニックを評価した結果、全体のデータ量の削減、取り込みの簡素化、データアクセスのパフォーマンスの向上など、さまざまな面でそれぞれの長所と短所を実証しました。
Apache Avroは、構造化データ用の高速汎用エンコーダであることが証明されています。 非常に効率的なシリアライゼーションとデシリアライゼーションのため、レコードのすべての属性へのアクセスが同時に必要な場合は、データ転送、ステージング領域など、非常に優れたパフォーマンスが保証されます。
一方、Apache HBaseは非常に優れたランダムなデータアクセス性能と、データ表現の格納方法（スキーマレスなテーブル）の最大の柔軟性を提供します。 HBaseデータのバッチ処理のパフォーマンスは選択されたデータモデルに大きく依存し、通常、他にテストした技術とこの分野で競うできません。 従って、HBaseデータを使用した分析は、まれにしか実行されません。
テストによると、 Apache ParquetやApache Kuduのようなカラムストアは、高速なデータ取り込みと高速ランダムデータルックアップ、スケーラブルなデータ分析との間で非常に優れた柔軟性をもたらし、システムのシンプルさを確保しました。
Parquetは高速なデータスキャンや取り込みに優れ、Kuduはより高速なランダムなルックアップに優れています。
単一のストレージ技術を実装する代わりに、（Parquetのような）ランダムアクセスのためのバッチ処理と、（HBaseのような）インデクシング層のためのRawストレージで構成された ハイブリッドシステムが考えられます。これにより、各テクノロジーの最善の利益を十分に得ることができます。特に、そのようなアプローチはデータの重複とシステムアーキテクチャの全体的な複雑さと高いメンテナンスコストという代償を払うことになります。したがって、システムの単純さが重要な要素の1つである場合、Apache Kuduは良い妥協案に見えます。
謝辞
著者はテスト中に関連するインプット、およびLuca Canali、Rainer Toebbicke、Julius Hirvnac、Dario Barberisに感謝します。
