Streaming Data Warehouse Storage

1. データウェアハウスにおけるコンピューティング

コンピューティングの分野において、データウェアハウス (DW または DWH) は、レポート生成およびデータ分析を行うシステムであり、ビジネスインテリジェンスのコアコンポーネントと位置付けられています。現在および過去のデータを一箇所に集約し、企業全体の従業員向けに分析レポートを作成します。[1]

一般的な ETL (抽出、変換、ロード) ベースのデータウェアハウスは、ODS レイヤー、DWD レイヤー、DWS レイヤーを使用して主要機能を構成します。データアナリストは、データウェアハウス内の各レイヤーを柔軟にクエリして、貴重なビジネス情報を取得できます。

データウェアハウスには 3 つの重要な指標があります [2]：

*データの鮮度：データが生成されてから、ウェアハウス内の一連の処理を経てユーザーのクエリに対応可能になるまでの時間です。通常、ETL はデータを準備するための一連のプロセスであり、一連のストリームコンピューティングまたはバッチコンピューティングジョブのスケジューリングと実行によって処理されます。
*データのクエリ遅延：データの準備が完了した後、ユーザーが Query を通じてテーブル内のデータをクエリします。ユーザーがクエリを送信してからクエリ結果を受信するまでの時間がクエリ遅延です。クエリ遅延はエンドユーザーの体感を直接決定します。
*コスト：一定量のデータ分析 (ETL やクエリなどの各種計算を含む) を完了するために必要なリソース量です。コストもデータウェアハウスにおける重要な指標です。

これら 3 つの指標の関係はどのようになっているでしょうか。

企業は、コストを抑制しながら、より優れたクエリ遅延と鮮度を実現する必要があります。データによっては、異なるコスト要件がある場合もあります。

鮮度とクエリレイテンシは、場合によってはトレードオフの関係にもなります。たとえば、データの準備、クレンジング、前処理に時間をかければ、クエリはより高速になります。

したがって、これら 3 つはデータウェアハウスにおけるトライアングル型のトレードオフを構成します [2]：


このトライアングル型のトレードオフに対し、業界の現在の主流アーキテクチャにはどのようなものがあるでしょうか。

2. 業界の主流アーキテクチャ

代表的なオフラインデータウェアハウス：

オフラインデータウェアハウスは、バッチ ETL を使用してパーティション粒度で INSERT OVERWRITE (上書き) を行います。非常に大規模なデータに対応しながら、優れたコスト管理を実現します。

ただし、2 つの深刻な問題があります：

鮮度が低い：データ遅延は一般的に T+1、つまり当日のビジネスで生成されたデータは翌日にクエリ可能になります。

更新ストリーム (変更ログ) の処理が不得意：オフラインデータウェアハウスにはすべての追加データが保存されます。データベースの変更ログのような更新ストリームを受け取る必要がある場合、全量データと増分データを繰り返しマージする必要があり、コストが急増します。

上記の問題を解決するため、リアルタイムデータウェアハウスが徐々に登場しています。代表的なリアルタイムデータウェアハウス実装は、Realtime Compute for Apache Flink + ApsaraMQ for Kafka ソリューションを使用して中間レイヤーを構築し、最終的にオンラインデータベースまたは分析システムに書き込んで、秒単位のフルリンク遅延を実現します。非常に優れたデータ鮮度を確保できます。

しかし、いくつかの問題も徐々に明らかになりました。

問題 1：中間レイヤーがクエリ不可

Kafka に保存されたデータのクエリには制限があり、OLAP クエリを柔軟に実行できず、長期的な履歴データは通常保存されません。これは広く利用されているデータウェアハウスとは大きく異なります。成熟したウェアハウスシステムでは、データウェアハウス内の各データセットはクエリ可能なテーブル抽象化であるべきですが、Kafka はテーブル抽象化に関するユーザーのすべてのニーズを満たすことができません。たとえば：

クエリ機能が限定的：リアルタイムデータウェアハウスアーキテクチャでは、すべてのクエリ可能なデータセットを事前計算して最終的にクエリ可能な分析システムに書き込む必要がありますが、実際のビジネスではすべての計算を事前定義できるわけではありません。データアナリストの大きな需要はアドホッククエリであり、中間データのキューがクエリ不可能だと、ビジネスのデータ分析機能が深刻に制限されます。

トラブルシューティングが困難：リアルタイムデータウェアハウスでデータに問題がある場合、ユーザーはデータパイプラインを確認する必要がありますが、中間結果を保存するキューがクエリ不可能なため、確認が非常に困難です。
以上より、中間結果がパイプライン化されたデータウェアハウスではなく、どこからでもクエリ可能なリアルタイムデータウェアハウスを得るために、統一アーキテクチャが望まれます。

問題 2：リアルタイムリンクのコストが高い

リアルタイムリンクの構築には比較的高いコストがかかります。

ストレージコスト：Kafka もその後段の ADS レイヤーもオンラインサービスです。非常に低いレイテンシを実現していますが、ストレージコストは高くなります。
移行・メンテナンスコスト：リアルタイムリンクはオフラインシステムから独立した新システムであり、オフラインのツールチェーンと互換性がありません。移行およびメンテナンスコストは非常に高くなります。
したがって、低コストで、オフラインツールチェーンと互換性があり、かつ既存のオフラインデータウェアハウスを加速できるリアルタイムデータウェアハウスが求められます。

現在の 2 つのアーキテクチャは異なるトレードオフとシナリオに対応しているため、ビジネスでは通常 2 つのアーキテクチャを維持する必要があり、異なる技術チームが必要になる場合もあります。これにより、多大なリソースコストだけでなく、高額な開発コストおよび運用保守コストが発生します。

それでは、鮮度、クエリ遅延、クエリ機能、コストの面で比較的にバランスの取れたデータウェアハウスを提供することは可能でしょうか。この問いに答えるため、鮮度とクエリレイテンシの背景にある技術原理、異なるトレードオフによるさまざまなアーキテクチャ、そしてその背後にある技術的差異を分析する必要があります。

3. ETL の鮮度

まずデータの鮮度を考えます。データの鮮度は、データが生成されてから、ウェアハウス内の一連の処理を経てユーザーのクエリに対応可能になるまでの時間を測定します。データはデータウェアハウスに取り込まれ、一連の ETL 処理を経て利用可能な状態になります。

従来のバッチコンピューティングは、粒度単位で ETL 計算を行うため、鮮度は「粒度 + ETL 遅延」となります。一般的な粒度は 1 日であるため、従来のオフラインデータウェアハウスの鮮度は最低でも 1 日です。粒度単位で計算する場合、入出力は全量になります。粒度よりも小さい鮮度が必要な場合、入出力は部分、すなわち増分になります。代表的なインクリメンタルコンピューティングは、Flink Streaming などのストリームコンピューティングです。

インクリメンタルコンピューティングはストリームコンピューティングと完全には等しくありません。たとえば、小規模バッチでのインクリメンタルコンピューティングもあり得ます。フルコンピューティングもバッチコンピューティングと完全には等しくありません。たとえば、ストリームコンピューティングでもウィンドウ単位で全量出力が可能です (つまり、ストリームコンピューティングの遅延を大きくすることも可能で、それによりコストを削減できます)。

4. クエリ遅延

クエリ遅延はデータ分析の効率とユーザー体験に直接影響します。クエリ結果は人に返されます。この人はロボットではなく、フィルタリングまたは集計されたデータを見ます。従来のオフラインデータウェアハウスでは、大規模テーブルのクエリに 10 分以上かかる場合があります。

クエリの戻りを高速化する最も直感的な方法は事前計算です。本質的に、データウェアハウスの ETL は事前計算を行っています。データアナリストのクエリ計算に時間がかかりすぎる場合、データウェアハウス担当者に通知して対応する ETL パイプラインを構築し、データの準備が完了した後、アナリストは最終結果テーブルを直接クエリできます。ある視点から見れば、これは鮮度を犠牲にしてより高速なクエリレイテンシを得ていることになります。

ただし、従来のオフラインデータウェアハウスでは大量のアドホッククエリがあり、ユーザーは必要に応じて柔軟にクエリ条件を選択できます。大規模テーブルを含むクエリは 10 分以上かかることがよくあります。できるだけ早く結果を返すため、主要なストレージシステムはさまざまな最適化方法を採用しています。

たとえば、ストレージをコンピューティングに近づけることで読み取りを高速化します：

一部のメッセージキューおよび OLAP システムはローカルディスクストレージのみを提供します。読み取りパフォーマンスは保証されますが、柔軟性が犠牲になります。拡張や移行のコストは比較的高く、全体のコストも高くなります。
もう一つの方向性は、コンピューティングとストレージの分離アーキテクチャです。すべてのデータはリモートにありますが、ローカルキャッシュにより DFS / オブジェクトストアへのリモートアクセスの高コストを軽減します。
たとえば、Data Skipping は、クエリ条件とフィールドを組み合わせて不要なデータをスキップし、データ検索を高速化します：

Hive：パーティションプルーニングにより特定のパーティションをクエリし、カラムストレージにより不要なフィールドをスキップします。
レイクストレージ：カラムストレージをベースにファイル統計情報を導入し、ファイル統計に基づいて不要なファイルの読み取りを最小限に抑えます。

OLAP システム：カラムストレージをベースに、LSM 構造を使用してデータをプライマリキーに基づいて可能な限り整列させます。整列はクエリに最も適した構造の一つです (例：ApsaraDB for ClickHouse)。

KV システム：データの組織構造を通じて LSM 構造を使用し、クエリを高速化します。

メッセージキュー：特殊な読み取りインターフェースを通じてデータの迅速な位置特定を実現します。オフセット / タイムスタンプに基づく位置特定方法のみを提供し、データをインクリメンタルに読み取ります。

その他多くの最適化方法がありますが、ここでは省略します。ストレージはさまざまな方法でコンピューティングと連携してクエリを加速し、データを素早く見つけて読み取れるようにします。

上記の分析から、異なるシステムの基盤技術は基本的に同じであることがわかります：

ストリームコンピューティングとバッチコンピューティングは異なるコンピューティングモードであり、どちらも全量または増分のコンピューティングを完了できます。
ストレージがクエリパフォーマンスを加速する手段は、すべて「素早く見つけて素早く読む」ことであり、基盤原理は同じです。
理論的には、基盤技術の選択と組み合わせにより、目的のトレードオフを実現するアーキテクチャを構築できるはずです。この統一アーキテクチャは、異なるトレードオフに応じて以下のシナリオに対応する必要があるでしょう：

リアルタイムデータウェアハウス：鮮度が非常に優れています。

準リアルタイムデータウェアハウス：オフラインデータウェアハウスの加速として、過度なコストをかけずに鮮度を改善できます。

オフラインデータウェアハウス：優れたコスト管理を実現します。

オフライン OLAP：データウェアハウスの特定のデータ (ADS テーブルなど) のクエリパフォーマンスを加速します。

Streaming Data Warehouse は統一アーキテクチャを目指しています：

理想的なデータウェアハウスは、ユーザーがコスト、鮮度、クエリ遅延のトレードオフを自由に調整できるべきです。これには、オフラインデータウェアハウス、リアルタイムデータウェアハウス、OLAP のすべての機能を完全にカバーする必要があります。Streaming Data Warehouse はリアルタイムデータウェアハウスを基盤に一歩前進し、リアルタイムデータウェアハウスのコストを大幅に削減しました。

Streaming DW はリアルタイムコンピューティング機能を提供すると同時に、同じアーキテクチャの下でオフラインデータウェアハウスもカバーできます。ユーザーはビジネスニーズに応じて適切なトレードオフを行い、さまざまなシナリオの問題を解決できます。

5. ストリーミングデータウェアハウス

Streaming Data Warehouse のストレージアーキテクチャの設計を見る前に、前述した主流リアルタイムデータウェアハウスの 2 つの問題を振り返りましょう。これら 2 つの問題を解決すれば、Streaming Data Warehouse のアーキテクチャ設計が自然に見えてきます。

5.1 中間データがクエリ不可

中間の Kafka ストレージがクエリ不可能なため、リアルタイムとオフラインの統合という考え方は、リアルタイムとオフラインを並行して実行し、ビジネスレイヤーでできるだけ多くのラップを行い、ユーザーに 1 組のテーブル抽象化を見せるようにするというものです。

多くのユーザーは Flink と Kafka を使用してリアルタイムデータストリーム処理を行い、分析結果をオンラインサービスレイヤーに書き込んで表示またはさらなる分析に使用します。リアルタイムデータで補完し、毎日定期的に大規模バッチ操作 / 全量操作を実行するか、履歴データを定期的に修正します。[3]

ただし、このアーキテクチャにはいくつかの問題があります：

テーブル抽象化が異なる：異なる技術スタックを使用しているため、リアルタイムリンクとオフラインリンクに 2 組のテーブル抽象化が存在し、開発コストが増加するだけでなく開発効率も低下します。ビジネスレイヤーはできるだけラップしようとしますが、常にさまざまな不整合の問題が発生し、位置合わせの課題が多数生じます。
リアルタイムデータウェアハウスとオフラインデータウェアハウスのデータ定義は、本質的な一貫性を維持することが困難です。

Streaming Data Warehouse では、データウェアハウスがクエリ用の統一されたテーブル抽象化を持つことを目指します。これにより、すべてのフローデータにデータブラインドスポットなく分析が可能になります。この統一テーブル抽象化は以下の 2 つの機能を同時にサポートする必要があります：

メッセージキュー
OLAP クエリ
つまり、同じテーブル上で、ユーザーはメッセージキュー形式で変更ログをサブスクライブすることも、このテーブルに対して直接 OLAP クエリを実行することもできます。

次に、従来のリアルタイムデータウェアハウスの 2 番目の問題を見てみましょう。

5.2 リアルタイムリンクの高コスト
Streaming Data Warehouse が提供する統一テーブル抽象化は、鮮度とクエリ遅延の問題を十分に解決できますが、コストはオフラインデータウェアハウスよりも高くなります。多くの場合、すべてのビジネスシナリオが高い鮮度と低いクエリ遅延を必要とするわけではないため、低コストのテーブルストレージ機能を提供する必要があります。

ここでレイクストレージが適しています：

レイクストレージのストレージコストはより低い：レイクストレージは DFS / オブジェクトストアをベースとしており、サービス不要で、リソースおよび運用保守コストが低くなります。

レイクストレージのローカル更新は柔軟：履歴パーティションに問題がある場合はどうすればよいか。修正が必要な場合はどうするか。レイクストレージの計算コストはより低くなります。レイクストレージ + オフライン ETL で INSERT OVERWRITE を使用して履歴パーティションを修正する方が、リアルタイム更新よりもはるかに低コストです。

レイクストレージのオープン性：レイクストレージはさまざまなバッチコンピューティングエンジンに開放できます。

したがって、Streaming Data Warehouse は、フルリンクデータのリアルタイムフローを維持しながら低コストのオフラインストレージを提供する必要があり、アーキテクチャがリアルタイムリンクに影響を与えないようにする必要があります。リアルタイムリンクの SLA 要件は通常オフラインリンクよりも高いため、Streaming Data Warehouse ストレージの設計と実装では、キューの書き込みと消費を高い優先度とし、履歴データの保存がキューとしての機能に影響を与えないようにする必要があります。