寄木細工を使用してスリップしない方法

HaquetのParquet ファイルのデータストレージに関する情報はあまりないため、 WrikeがSparkと組み合わせて実装した経験についてのストーリーが役立つことを願っています。
特に、この記事では次のことを学びます。

-なぜ「寄木細工」が必要なのですか。
-仕組み
-いつ使用するか。
-その場合、あまり便利ではありません。



おそらく、質問から始める価値があります。予備集計の代わりにデータを保存し、結果をデータベースに保存する新しい方法を探し始めたのはなぜですか。決定を下す際にどのような基準が私たちを導きましたか？

Wrike分析部門では、ビッグデータを操作するためのスケーラブルで成長中のツールであるApache Sparkを使用します（着信データとイベントのさまざまなログやその他のストリームがあります）。 以前に Sparkがどのように機能するかについて話しました 。

最初は、インフラストラクチャをあまり洗練せずにシステムを迅速にデプロイしたかったので、スタンドアロンSparkのクラスターマネージャーとJsonが記述されたテキストファイルに限定することにしました。 当時、大きな入力データストリームはなかったため、 hadoopなどをデプロイします 。 意味がありませんでした。

初期段階でどのような画像があったかについて：

• 最小限のテクノロジースタックで対処し、システムをできる限りシンプルにしようとしたため、すぐにSparkをhadoop、 Cassandra 、MongoDB、および特別な管理が必要なその他のストレージメソッドの上に置きました。 私たちのディスクは非常に機敏で、データフローにうまく対応しています。さらに、クラスター内のマシンは互いに近くにあり、強力なネットワークインターフェースで接続されています。
• 入力データの構造が不十分だったため、普遍的なスキームを選択することは困難でした。
• 新しいイベントを常に追加し、ユーザーアクティビティの追跡を改善したため、スキームは急速に進化しました。そのため、データ形式としてjsonを選択し、プレーンテキストファイルに入れました。
• イベントベースの分析に近づけようとしました。 また、この場合、各イベントは、結合操作の数を最小限に抑えるために、可能な限り情報を充実させる必要があります。 実際には、データエンリッチメントにより、回路内の列がますます生成されます（これは重要なポイントであり、ここに戻ります）。 さらに、完全に異なる種類の多数のイベントが相互接続され、さまざまなパラメーターによって特徴付けられているため、回路も多数の列を取得し、情報は完全に放電されました。
• 私たちは不変のデータで作業しました。記録してから、ただ読みました。

数週間の作業の後、jsonデータの操作は不便で時間がかかることに気付きました。さらに、読み取りが遅く、さらに多数のテストリクエストがあるため、Sparkが最初にファイルを読み取ってスキームを決定し、その後でリクエスト自体に直接アクセスする必要があります。 もちろん、事前にスキームを指定することでSparkのパスを短くすることができますが、毎回この追加作業を行いたくありませんでした。
Sparkを調べてみると、彼自身が寄せ木細工の形式を積極的に使用していることがわかりました。

寄木細工とは

Parquetは、もともとhadoopエコシステム用に作成されたバイナリの列指向のデータストレージ形式です。 開発者は、このストレージ形式がビッグデータ（不変）に最適であると主張しています。
最初の印象は歓声でした。Sparkで作業するのがようやく便利になりました。生き返ったばかりですが、不思議なことに、予期せぬ問題が発生しました。 実際、寄せ木張りは不変のテーブルまたはデータベースのように動作します。 そのため、列に対して型が定義されており、複雑なデータ型（ネストされたjsonなど）と単純な（通常の文字列値）を突然組み合わせると、システム全体が崩壊します。 たとえば、2つのイベントを取得し、Json形式で書き込みます。
{
“event_name”: “event 1”,
“value”: “this is first value”,
}

{
“event_name”: “event 2”,
“value”: {“reason”: “Ok”}
}


最初のケースには文字列があり、2番目のケースには複合型があるため、それらを寄木細工のファイルに書き込むことはできません。 さらに悪いことに、システムが入力データストリームをファイルに書き込む場合、たとえば1時間ごとに。 最初の1時間は文字列値を持つイベントが発生し、2番目の時間には複合型の形式でイベントが発生します。 その結果、もちろん寄木細工のファイルを作成することは可能ですが、スキーマのマージ操作中に型の非互換性エラーが発生します。

この問題を解決するには、少し妥協する必要がありました。 情報の一部について、データプロバイダースキームによってよく知られ保証されているものを決定し、残りは上位レベルのキーのみを取得しました。 同時に、上記の例の場合、データ自体はテキスト（多くの場合、json）として記録され、セルに保存されました（後で、単純なmap-reduce操作の助けを借りて、便利なDataFrameになりました）。 Ok "} 'turns into'" value "：" {\” reason \”：\” Ok \”}” ' また、データをSparkのパーツに分割する機能にも遭遇しました。

Parquetファイル構造はどのように見えますか

寄木細工は、jsonを内部に含む同じテキストファイルと比較すると、かなり複雑な形式です。
このフォーマットは、Googleの開発、つまりDremelと呼ばれるプロジェクトでも定着したことは注目に値します-これはHabréですでに言及されていますが 、Dremelの荒野には入りません。誰でもここで読むことができます： research.google.com /pubs/pub36632.html

要するに、Parquetは「定義レベル」と「繰り返しレベル」に基づいたアーキテクチャを使用しているため、データの非常に効率的なコーディングが可能になり、スキームに関する情報が別のメタデータに転送されます。
この場合、空の値が最適に保存されます。

寄木細工のファイルの構造は、ドキュメントで詳しく説明されています 。



ファイルはいくつかのレベルに分割されており、その上で非常に効果的な操作の並列実行が可能です。

行グループは、Map-Reduceレベルで並行してデータを操作できるパーティションです
列チャンク -IO操作を分散できる列レベルのパーティション
ページ -列のページ分割。コーディングと圧縮の作業を分散できます

通常のファイルシステムを使用して寄木細工のファイルのデータをディスクに保存すると、ファイルの代わりに、ファイルのコレクション全体を含むディレクトリが作成されることがわかります。 それらの一部はメタ情報であり、ダイアグラムでは、要求に応じて必要なデータブロックのみを読み取ることができる部分インデックスを含むさまざまなオーバーヘッド情報です。 残りの部分、つまりパーティションは、行グループです。

直感的に理解できるように、 行グループは共通の情報で結合されたファイルのセットと見なします。 ところで、HDFSはこのパーティションを使用して、クラスター内の各ノードがディスク上に直接配置されているデータを読み取ることができる場合、データの局所性を実装します。 さらに、行グループはMap Reduceユニットとして機能し、Sparkの各map-reduceタスクは独自の行グループで動作します。 そのため、ワーカーは行のグループをメモリに配置する必要があり、グループのサイズを設定するときは、最も弱いノードのタスクに割り当てられた最小メモリ量を考慮する必要があります。そうしないと、OOMにつまずきます。
私たちの場合、特定の条件下でテキストファイルを読み取るSparkが1つのパーティションのみを形成するという事実に直面しました。そのため、データ変換は1つのコアでのみ実行されましたが、はるかに多くのリソースが利用できました。 rddの再パーティション操作を使用して、入力を壊し、いくつかの行グループを作成し、問題はなくなりました。

列チャンク （列レベルでのパーティション分割）-ディスクでの作業を最適化します。 データを表として表示する場合、行ではなく列に記録されます。

テーブルを想像してください：

次に、csvなどのテキストファイルに、次のようにデータをディスクに保存します。

寄木細工の場合：

これにより、必要な列のみを読み取ることができます。

実際、さまざまな列のうち、特定の時点で分析に必要なのはごくわずかであり、ほとんどの列は空のままです。 Parquetは、データを処理するプロセスを時折加速します。さらに、そのような情報の構造化は、その均質性と類似性により、データの圧縮とエンコードを簡素化します。

各列はPagesに分割されます。Pag​​esには、Dremelプロジェクトのアーキテクチャの原則に従ってエンコードされたメタ情報とデータが含まれています。 これにより、かなり効率的で高速なコーディングが実現します。 さらに、圧縮はこのレベルで実行されます（構成されている場合）。 現在利用可能なsnappy、gzip、lzoコーデック。

落とし穴はありますか？

データの「寄木細工」の組織のため、ストリーミングを構成することは困難です。データを転送すると、グループ全体が完全に構成されます。 また、メタ情報を失ったり、データページのチェックサムを変更したりすると、ページ全体が失われます（列グループの場合、行グループの場合も同様に、グループが失われます）。 チェックサムはパーティションの各レベルで作成されるため、ファイルシステムレベルで計算をオフにしてパフォーマンスを向上させることができます。

結論：

Parquetのデータストレージの利点：

• hdfs用に設計されていますが、データはGlusterFsなどの他のファイルシステムまたはNFSの上に保存できます
• 本質的に、これらは単なるファイルです。つまり、作業、移動、バックアップ、複製が簡単です。
• 列ビューでは、すべての列を一度に必要としない場合にアナリストの作業を大幅に加速できます。
• Sparkの標準サポートにより、ファイルを簡単に取得してお気に入りのストレージに保存できます。
• ストレージスペースの観点から効率的なストレージ。
• 実践が示すように、他のファイル形式を使用する場合と比較して、最速の読み取りパフォーマンスを提供するのはこの方法です。

短所：

• 列ビューにより、スキームとデータ型について考えることができます。
• Sparkを除いて、Parquetは常に他の製品でネイティブサポートされているわけではありません。
• データの変更とスキーマの進化はサポートしていません。 もちろん、Sparkは時間の経過とともにスキームを変更した場合、スキームをマージできます（このため、読み取り時に特別なオプションを指定する必要があります）が、既存のファイルの何かを変更するには、新しい列を追加できない限り、上書きせずに行うことはできません。
• トランザクションは通常のファイルであり、データベースではないため、トランザクションはサポートされていません。

Wrikeでは、寄せ集めのイベントデータの格納場所として長い間寄木細工のファイルを使用しており、アナリストは毎日非常に多くのリクエストを送信しています。この技術を使用するための特別なテクニックを開発したので、試してみたい人と経験を共有できます寄せ木細工を使用して、コメントのすべての質問に答えます。

PSもちろん、後でデータストレージの形式に関する見解を繰り返し改訂しました。たとえば、より一般的なAvro形式についてはアドバイスを受けましたが、今のところ何も変更する緊急の必要はありません。

行指向データと列指向データの違いをまだ理解していない人のために、 Clouderaの優れたビデオがあります。
分析用のデータストレージ形式に関するやや面白いプレゼンテーションもあります。