他のフォーマットと比較した寄木細工フォーマットの長所と短所は何ですか？
アパッチ寄木細工の特徴は次のとおりです。
- 自己記述的
- 円柱フォーマット
- 言語に依存しない
Avro、シーケンスファイル、RCファイルなどと比較して、フォーマットの概要が欲しいのですが。私はすでに読んだことがあります。 ImpalaとHadoopファイルフォーマットの関係 、フォーマットについての洞察が得られますが、これらの各フォーマットでデータへのアクセスとデータの格納がどのように行われるかを知りたいです。寄木細工の床は他のものよりもどのように利点がありますか？
私が説明できる主な違いは、レコード指向形式と列指向形式の違いにあります。レコード指向フォーマットは、テキストファイル、CSV、TSVなどの区切りフォーマットです。 AVROは、スキーマを時間の経過とともに変更する可能性があるため、AVROよりも若干クールです。レコードに列を追加または削除する。さまざまな形式の他のトリック（特に圧縮を含む）には、形式を分割できるかどうかが含まれます。つまり、データセット内のどこからでもレコードのブロックを読み取っても、それがスキーマであることを確認できますか。しかし、これがParquetのような円柱フォーマットの詳細です。
寄木細工や他の円柱フォーマットは非常に効率的に一般的なHadoopの状況を扱います。よく設計されたリレーショナルデータベースでは、テーブル（データセット）に予想以上に多くの列が含まれるのが一般的です。100列または200列は珍しいことではありません。これは、リレーショナル形式のデータを非正規化するための場所としてHadoopを使用することが多いためです。つまり、多数の繰り返し値とすべてのテーブルが単一のテーブルに統合されます。しかし、すべての結合が解決されているため、照会がはるかに簡単になります。状態データの保持など、他にも利点があります。それで、とにかくテーブルの中に列のボートロードがあるのは一般的です。
132個の列があり、そのうちのいくつかは本当に長いテキストフィールドで、各列が次々に続いていてレコードあたり10Kを使い果たしているとしましょう。
これらのテーブルへの問い合わせはSQLの観点からは簡単ですが、一般的には、これらの数百以上の列のうちのいくつかだけに基づいて、ある範囲のレコードを取得したいと思うでしょう。たとえば、売上が500ドルを超える顧客について、2月と3月のすべてのレコードが必要な場合があります。
行形式でこれを行うには、クエリはデータセットのすべてのレコードをスキャンする必要があります。最初の行を読み取り、レコードをフィールド（列）に解析して日付と売上の列を取得し、それが条件を満たす場合は結果に含めます。繰り返す。あなたが10年（120ヶ月）の歴史を持っているならば、あなたはちょうどそれらの月のうちの2つを見つけるためにあらゆる単一の記録を読んでいます。もちろん、これは年月にパーティションを使用する絶好の機会ですが、それでも、顧客の売上が500ドルを超えていないかどうかを確認するために、その2か月間のレコード/行ごとに10Kを読んで解析します。
列形式では、レコードの各列（フィールド）はディスク上のさまざまなブロックに分散して格納されます - 年ごとの列、月ごとの列、顧客従業員ハンドブック用の列（またはその他の列）これらのレコードを巨大なものにしている他のすべてのものは、ディスク上の別々の場所にあり、もちろん売り上げのためのコラムもあります。よく、日付と月は数字です、そして売上もそうです - 彼らはほんの数バイトです。どのレコードがクエリに一致したかを判断するために各レコードについて数バイトを読み取ればよいのであれば、それは素晴らしいことではないでしょうか。円柱状のストレージが救助に！
パーティションがなくても、クエリを満たすために必要な小さなフィールドをスキャンするのは超高速です。これらはすべてレコード順で、すべて同じサイズなので、ディスクは含まれるレコードのデータチェックをはるかに少なくします。その従業員ハンドブックや他の長いテキストフィールドを読む必要はありません - 無視してください。そのため、行ではなく列を互いにグループ化することで、ほとんどの場合、スキャンするデータ量を減らすことができます。勝つ！
しかし、待ってください、それは良くなります。クエリがこれらの値とそれ以外の数（132列のうち10列）を知っているだけで、その従業員ハンドブック列を気にしなくても、返されるレコードが適切であれば、あとは実行するだけです。データセットの132列のうち122列を無視して、結果をレンダリングするのに必要な10列に戻ります。繰り返しになりますが、私たちはたくさんの読み物を読み飛ばします。
（注：このため、2つのテーブルすべてを新しいテーブルとして保存している1つの大きな（ger）結果セットに結合している場合など、直線変換を実行する場合は、列形式がお勧めできません。とにかく完全にスキャンされるので、読み込みのパフォーマンスにはそれほどメリットはありません。また、カラム形式では、どこにあるかについてもっと覚えておく必要があるため、同様のロー形式よりも多くのメモリを使用します。
円柱のもう1つの利点：データが広がっている。 1つのレコードを取得するには、132ブロックのデータ上の132の異なる場所との間でデータを読み書きする132人の作業員を配置できます。並列化はやめましょう。
そして今クリンチャーのために：それは繰り返しのパターンを見つけることができるとき圧縮アルゴリズムははるかにうまく機能します。 AABBBBBBCCCCCCCCCCCCCCCCを2A6B16Cとして圧縮することはできますが、ABCABCBCBCBCCCCCCCCCCCCCCはそれほど小さくはなりません（実際、この場合はそうですが、私を信頼してください:-)）。だからもう一度、より少ない読書。そして書きます。
そのため、一般的なクエリに答えるために読み込むデータがはるかに少なくなり、並行して読み書きするほうが高速になる可能性があり、圧縮の方がはるかにうまく機能する傾向があります。
入力側が大きく、出力がフィルタ処理されたサブセットである場合は、Columnarが優れています。大きいものから小さいものまでが素晴らしいです。入力と出力がほぼ同じ場合、それほど有益ではありません。
しかし、今回の場合、Impalaは5、10、20、または30分で実行されていた古いHiveクエリを使用し、数秒または1分でほとんど終了しました。
これがあなたの質問の少なくとも一部の答えになることを願っています！
AvroはHadoop用の行ベースのストレージフォーマットです。
寄木細工はHadoopの列ベースのストレージ形式です。
通常、ユースケースで各クエリで1行に含まれるすべてのフィールドをスキャンまたは取得する場合は、通常Avroが最善の選択です。
データセットに多数の列があり、ユースケースで通常レコード全体ではなくそれらの列のサブセットを扱う場合、Parquetはその種の作業に最適化されています。
トムの答えは非常に詳細で徹底的ですが、あなたはまた興味を持っているかもしれません この簡単な研究 オールステートインシュアランスで行われたパーケット対アヴロについて、ここに要約されています。
「全体的に見て、Parquetはすべてのテストで類似した、またはより良い結果を示しています。[Avro]よりも大きいデータセットでのクエリパフォーマンスの違いは圧縮結果によるものです。 ParquetのデータはAvroよりも少ない。疑われるように、Avroはデータセット全体を処理するときにうまく機能しなかった。」