私は会社のリアルタイムデータウェアハウスの最初の実践者として、自分の定義とリアルタイムデータウェアハウスの理解を記録しています。
ストリーミングデータウェアハウスの概要#
建設目的#
明確なデータ構造：各データレイヤーにはそれぞれの目的と責任があり、使用とメンテナンスの際に便利で理解しやすくなるようにする
複雑な問題の簡素化：複雑なタスクを複数のステップに分割して逐次的に完了させ、各レイヤーが特定の問題のみを解決する
データの統一的な基準：データのレイヤリングを通じて、統一的なデータ出力口と出力基準を提供する
重複した開発の削減：データのレイヤリングを規範化することで、データの再利用が可能になり、共通の中間層を開発することで重複した計算作業を大幅に削減できる
デザインの考え方#
リアルタイムストリーム処理チェーン（Flink + Kafka）を使用して、データを ODS、DWD、DWS のレイヤーに分割し、リアルタイムにオンラインサービス層に書き込み、オンラインサービス（リアルタイム OLAP）を提供します。
- オフラインデータウェアハウスと比較して、リアルタイムデータウェアハウスのデータソースストレージは異なり、Kafka をベースにデータウェアハウスを設計し、詳細データまたは集計データはすべて Kafka に保存され、次の日のディメンション情報は HIVE T+1 から読み取られます。
- オフラインデータウェアハウスと比較して、複雑なビジネスロジックはなく、データのフロー効率を追求し、データウェアハウスのレベルが少ないです。
- 各レイヤー間のデータフローと計算は Flink を使用して完了します。
適用シナリオ#
オペレーションレベル：リアルタイムなビジネスの変化、トピックごとの統計分析、および当日の時間帯別ビジネストレンド分析など。
プロダクションレベル：リアルタイムシステムの信頼性、システムの安定性、リアルタイムモニタリングシステムの健康状態など。
エンドユーザー：検索の推奨順位、リアルタイムな行動、特徴などの特徴変数の生成に必要で、ユーザーにより適切なコンテンツを推奨します。
リスク管理側：リアルタイムのリスク識別、反詐欺、異常取引など、リアルタイムデータを大量に使用するシナリオ。
OLAP に対するアーキテクチャデザイン#
データウェアハウスのデザイン例#
レイヤリング#
| レベル | 名前 | ストレージ | レベルの説明 |
|---|---|---|---|
| ODS | ソースレイヤー | cdc 後の Kafka/flink-cdc-table | 収集された非構造化データ |
| DWD | 詳細レイヤー | Kafka | フィルタリング、結合、ワイド化（フィルター、結合、結合） |
| DWS | 集計レイヤー | Kafka | ビジネスの集約（agg win, join ディメンション） |
| ADS | アプリケーションレイヤー | ||
| DIM | ディメンションレイヤー | upsert-kafka | Hive ディメンションテーブル、詳細の関連 |
ods：
ビジネスライブラリのバイナリログ：一般的にはさまざまなリレーショナルデータベースのバイナリログから取得されます。
システムログ：ログは通常ファイル形式で保存され、Flink、Kafka を使用してリアルタイムにアクセスされます。
メッセージキュー：Kafka からのデータなど
dw：
Flink 処理モデル、トピックごとに分割
ads：
通常、直接 OLAP 分析に接続するか、ビジネスレイヤーデータの呼び出しインターフェースです。
これは最上位レベルであり、通常は結果タイプのデータであり、直接使用または表示できるデータであり、データの分析度合いが最も高いレベルのデータです。
dim のソース：
詳細データのディメンション、Hive からのソース。
ケーススタディ#
食品安全ビジネスを例にする
デザイン#
ods：realtime_ods_データソース。データベース名。テーブル名
dwd：realtime_dwd. テーブル名
dim：realtime_dim. ディメンションテーブル名
dws：realtime_dws. ビジネス名に応じたワイド化
ads：realtime_ads. 指標名
トピックの例：
注意：トピック名は大文字と小文字を区別します。
問題点#
- ラムダアーキテクチャによる統一された基準の欠如などの問題（Flink 14 + のバッチストリーム統合 API を検討）
- ADS の永続化が不完全であり、Druid、ES などを使用して OLAP を行う
- 再利用性とデータウェアハウスの各レイヤーで参照可能な要求（永続的な Hive カタログテーブルの保存）