書き込みパフォーマンスを向上させるために、Hbase から ORC にいくつかのデータを移植しようとしています。Hbase では、データは行キーに対して合計 10 列に格納されます。Hbase を使用しているので、これらの列のスパース性について心配する必要はありません。ほとんどの行にゼロ以外の値を持つ列が 2 つしかない場合でも、Hbase は 2 つの列しか格納しないので問題ありません。
データを移植するときの私の最初の本能は、上記の列修飾子をマップに関連する値に変換することでした。ただし、これは検索にはあまり効率的ではありません。ORC が null を解釈する方法を理解しようとしています。値をマップとしてではなく、10 個の個別の列として保存した方がよいでしょうか? 最悪の場合、この行列は非常にまばらになります。
ORC の書き込みパフォーマンスはおそらく Hbase よりも悪く、ORC は読み取り負荷の高いユースケースに使用され、ソートされた大量のデータを格納するように最適化されています。これが光る時です。その機能のほとんどは、たとえば述語のプッシュダウンなど、読み取りクエリの高速化を中心に構成されています。データについてあまり知らなくても、書き込みの多い操作にはおそらく Hbase の方が適していると思います。質問への回答: ORC は列指向の形式であるため、データを個別の列に分割することはほぼ必須です。まばらなデータを非常にうまく処理します。
ORC のドキュメントから:
ORC ファイルでは、各列は複数のストリームに格納され、ファイル内で隣り合って格納されます。たとえば、整数列は2 つのストリームとして表されます。PRESENT は、値が NULL でない場合に値ごとのビットを記録するものを使用し、DATA は NULL 以外の値を記録します。ストライプ内のすべての列の値が NULL でない場合、PRESENT ストリームはストライプから除外されます。
つまり、最悪の場合、null 値ごとにちょうど 1 ビットのコストがかかります。平均的なケースでは、圧縮アルゴリズムを指定すると、ORC はこれらのストリームをさらに圧縮します。そのため、null 値のコストが 1 ビット未満になる状況になる可能性があります。
そうは言っても、それが特定のアプリケーションにとってより効率的であるかどうかはわかりません。各行から特定の値 (つまり、列) を読み取る必要がある場合、読み取りパフォーマンスが大幅に向上する可能性があります。ORC には列チャンクのスキップをサポートするインデックスがあるため、読み取りが条件付きの場合、たとえば if COL2 == "someValue" の場合、I/O をさらに改善できます。