ビッグデータのファイル形式: 簡単な教育プログラム

天気の神様 by レマリン

チーム Mail.ru クラウド ソリューション 提供 記事の翻訳 Clairvoyant のエンジニア Rahul Bhatia が、ビッグ データにはどのようなファイル形式があるのか​​、Hadoop 形式の最も一般的な機能は何か、どの形式を使用するのが良いのかについて説明します。

なぜさまざまなファイル形式が必要なのでしょうか?

MapReduce や Spark などの HDFS 対応アプリケーションの主なパフォーマンスのボトルネックは、データの検索、読み取り、書き込みにかかる時間です。 固定スキーマではなく進化するスキーマがある場合、またはストレージに何らかの制約がある場合、大規模なデータ セットの管理が困難になるため、これらの問題はさらに悪化します。

ビッグ データを処理すると、ストレージ サブシステムの負荷が増加します。Hadoop はフォールト トレランスを実現するためにデータを冗長的に保存します。 ディスクの他にプロセッサ、ネットワーク、入出力システムなどが搭載されます。 データの量が増加するにつれて、データの処理と保存のコストも増加します。

さまざまなファイル形式 Hadoopの これらの問題を正確に解決するために発明されました。 適切なファイル形式を選択すると、次のような大きな利点が得られます。

1. 読書時間の短縮。
2. 録音時間が短縮されました。
3. 共有ファイル。
4. スキーマ進化のサポート。
5. 拡張された圧縮サポート。

ファイル形式には、一般的な使用を目的としたもの、より特殊な用途を目的としたもの、および特定のデータ特性を満たすように設計されたものがあります。 したがって、選択肢は実際には非常に大きいです。

Avro ファイル形式

のために データのシリアル化 Avro は広く使用されています - それ 文字列ベースの、つまり、Hadoop における文字列データの保存形式です。 スキーマは JSON 形式で保存されるため、あらゆるプログラムで簡単に読み取って解釈できます。 データ自体はバイナリ形式であり、コンパクトで効率的です。

Avro のシリアル化システムは言語に依存しません。 ファイルはさまざまな言語 (現在は C、C++、C#、Java、Python、Ruby) で処理できます。

Avro の重要な機能は、時間の経過とともに変化する、つまり進化するデータ スキーマを強力にサポートしていることです。 Avro は、フィールドの削除、追加、変更といったスキーマの変更を理解します。

Avro はさまざまなデータ構造をサポートしています。 たとえば、配列、列挙型、およびサブレコードを含むレコードを作成できます。

この形式は、データ レイクのランディング (移行) ゾーンへの書き込みに最適です (データレイク、またはデータ レイク - データ ソースに加えてさまざまな種類のデータを直接保存するためのインスタンスのコレクション)。

したがって、この形式は、次の理由により、データ レイクのランディング ゾーンへの書き込みに最適です。

1. 通常、このゾーンからのデータは、ダウンストリーム システムによるさらなる処理のために全体が読み取られます。この場合、行ベースの形式の方が効率的です。
2. ダウンストリーム システムは、ファイルからスキーマ テーブルを簡単に取得できます。スキーマを外部メタ ストレージに個別に保存する必要はありません。
3. 元のスキーマへの変更は簡単に処理されます (スキーマの進化)。

寄木細工のファイル形式

Parquet は、Hadoop のオープンソース ファイル形式です。 フラットな列形式のネストされたデータ構造.

従来の行アプローチと比較して、Parquet はストレージとパフォーマンスの点でより効率的です。

これは、幅の広い (多数の列) テーブルから特定の列を読み取るクエリに特に役立ちます。 ファイル形式のおかげで、必要な列のみが読み取られるため、I/O は最小限に抑えられます。

ちょっとした余談と説明: Hadoop の Parquet ファイル形式をより深く理解するために、列ベース (つまり、列形式) 形式が何であるかを見てみましょう。 この形式は、各列の同様の値をまとめて保存します。

例えば、レコードには ID、名前、部門フィールドが含まれます。 この場合、すべての ID 列の値が一緒に保存され、Name 列の値も同様に保存されます。 テーブルは次のようになります。

ID
名前
部門

1
emp1
d1

2
emp2
d2

3
emp3
d3

文字列形式の場合、データは次のように保存されます。

1
emp1
d1
2
emp2
d2
3
emp3
d3

カラムナ形式のファイル形式では、同じデータが次のように保存されます。

1
2
3
emp1
emp2
emp3
d1
d2
d3

テーブルから複数の列をクエリする必要がある場合は、列形式の方が効率的です。 列は隣接しているため、必要な列のみが読み取られます。 このようにして、I/O 操作は最小限に抑えられます。

たとえば、NAME 列のみが必要です。 で 文字列形式 データセット内の各レコードをロードし、フィールドごとに解析して、NAME データを抽出する必要があります。 列形式では、その列のすべての値が一緒に保存されるため、名前列に直接ドリルダウンできます。 録音全体をスキャンする必要はありません。

したがって、列指向形式では、必要な列に到達するための検索時間が短縮され、必要な列のみが読み取られるため I/O 操作の数が削減されるため、クエリのパフォーマンスが向上します。

ユニークな機能の XNUMX つ 寄せ木細工の床 この形式ではできるということですか 入れ子構造でデータを保存する。 これは、Parquet ファイルでは、ネストされた構造内のすべてのフィールドを読み取る必要がなく、ネストされたフィールドであっても個別に読み取ることができることを意味します。 Parquet は、シュレッディングおよびアセンブリのアルゴリズムを使用して、ネストされた構造を保存します。

Hadoop の Parquet ファイル形式を理解するには、次の用語を理解しておく必要があります。

1. 行グループ (行グループ): データを行に論理的に水平に分割したもの。 行グループは、データ セット内の各列のフラグメントで構成されます。
2. 列フラグメント (列チャンク): 特定の列のフラグメント。 これらの列フラグメントは特定の行グループに存在し、ファイル内で連続していることが保証されます。
3. ページ (ページ): 列フラグメントは、次々に記述されるページに分割されます。 各ページには共通のタイトルが付いているので、不要なページを読み飛ばして読むことができます。

ここではタイトルにマジックナンバーが含まれているだけです PAR1 (4 バイト) ファイルが Parquet ファイルであることを識別します。

フッターには次のように書かれています。

1. 各列のメタデータの開始座標を含むファイル メタデータ。 読み取るときは、まずファイルのメタデータを読み取り、対象となるすべての列フラグメントを見つける必要があります。 その後、列フラグメントを順番に読み取る必要があります。 その他のメタデータには、形式のバージョン、スキーマ、および追加のキーと値のペアが含まれます。
2. メタデータの長さ (4 バイト)。
3. マジックナンバー PAR1 (4バイト)。

ORC ファイル形式

最適化された行-列ファイル形式 (最適化された行列、 ORC) は、データを保存するための非常に効率的な方法を提供し、他の形式の制限を克服するように設計されました。 データを完全にコンパクトな形式で保存するため、大規模で複雑なインデックスを構築したり、手動で管理したりする必要がなく、不必要な詳細をスキップできます。

ORC 形式の利点:

1. 各タスクの出力は XNUMX つのファイルであり、NameNode (ネーム ノード) の負荷が軽減されます。
2. DateTime、XNUMX 進数、複合データ型 (構造体、リスト、マップ、共用体) を含む Hive データ型のサポート。
3. 異なる RecordReader プロセスによる同じファイルの同時読み取り。
4. マーカーをスキャンせずにファイルを分割する機能。
5. ファイル フッターの情報に基づいて、読み取り/書き込みプロセスに可能な最大ヒープ メモリ割り当てを推定します。
6. メタデータはプロトコル バッファーのバイナリ シリアル化形式で保存され、フィールドの追加と削除が可能になります。

ORC は文字列のコレクションを XNUMX つのファイルに保存し、コレクション内では文字列データが列形式で保存されます。

ORC ファイルには、ストライプと呼ばれる行のグループと、ファイルのフッターにサポート情報が格納されます。 ファイルの最後にあるポストスクリプトには、圧縮パラメータと圧縮されたフッターのサイズが含まれています。

デフォルトのストライプ サイズは 250 MB です。 このような大きなストライプにより、HDFS からの読み取りは大きな連続ブロックでより効率的に実行されます。

ファイル フッターには、ファイル内のレーンのリスト、レーンごとの行数、および各列のデータ型が記録されます。 各列の count、min、max、sum の結果の値もそこに書き込まれます。

ストリップのフッターには、ストリームの場所のディレクトリが含まれています。

行データはテーブルをスキャンするときに使用されます。

インデックス データには、各列の最小値と最大値、および各列内の行の位置が含まれます。 ORC インデックスは、クエリに応答するためではなく、ストライプと行グループを選択するためにのみ使用されます。

さまざまなファイル形式の比較

アブロと寄木細工の床の比較

1. Avro は行ストレージ形式ですが、Parquet はデータを列に格納します。
2. Parquet は分析クエリに適しています。つまり、読み取り操作とデータのクエリの方が書き込みよりもはるかに効率的です。
3. Avro での書き込み操作は、Parquet よりも効率的に実行されます。
4. Avro は回路の進化をより成熟して扱っています。 Parquet はスキーマの追加のみをサポートしますが、Avro は多機能の進化、つまり列の追加または変更をサポートします。
5. Parquet は、複数列テーブル内の列のサブセットをクエリするのに最適です。 Avro は、すべての列をクエリする ETL 操作に適しています。

ORC vs 寄木細工

1. Parquet はネストされたデータをより適切に保存します。
2. ORC は述語プッシュダウンに適しています。
3. ORC は ACID プロパティをサポートします。
4. ORC はデータをより適切に圧縮します。

このトピックに関して他に何を読むべきか:

1. クラウドでのビッグデータ分析: 企業がデータ指向になるには.
2. データベース スキーマの謙虚なガイド.
3. デジタル変革に関する電報チャネル.

出所： habr.com