Hologres は、宣言型データ処理アーキテクチャとして機能する動的テーブル機能を提供します。 動的テーブル機能を使用すると、1 つ以上のベーステーブルのデータ集計結果の自動処理と保存を実装できます。 動的テーブル機能は、さまざまな組み込みデータリフレッシュポリシーを提供します。 ビジネス要件に基づいてデータリフレッシュポリシーを設定し、ベーステーブルから動的テーブルへの自動データ転送を実装できます。 これにより、集中型ビジネス開発、自動データ転送、ビジネス処理の適時性という要件が満たされます。
背景情報
リアルタイムのデータウェアハウスシナリオでは、複数テーブル結合クエリや大規模テーブル集計クエリなど、ビジネスデータの複雑な処理が頻繁に行われます。 以下の情報は、さまざまなシナリオにおけるビジネスの適時性に関する要件について説明しています。
リスク管理やレコメンデーションなどのリアルタイムシナリオ: 数秒または数ミリ秒以内の結果出力が求められます。
リアルタイムレポートやビジネスインテリジェンスベースのデータ表示などのほぼリアルタイムのシナリオ: 数分のレイテンシが許容されます。
定期レポートや履歴データクエリなどのオフラインシナリオ: クエリ頻度は低くなります。 数時間のレイテンシが許容されます。
結合クエリが必要になる場合があります。 この場合、データ標準の一貫性を厳密に確保する必要があります。
ビジネスリソースコストの削減、開発効率の向上、ビジネスの適時性の向上という要件を満たすために、業界は初期の Lambda アーキテクチャや統合ストリーミングおよびバッチ処理アーキテクチャなどのアーキテクチャの研究開発と進化を行ってきました。 これらの取り組みによって特定のビジネスおよび開発の問題は解決されましたが、以下の問題は依然として残っています。
アーキテクチャ: さまざまなビジネスシナリオでの適時性の要件を満たすために、現在の市場にあるさまざまな製品が組み合わされています。 単一の製品ですべてのビジネス要件を満たすことはできません。
データ抽出、変換、ロード (ETL) 操作: データウェアハウスのデータ詳細レイヤーからアプリケーションレイヤーへのデータ処理に利用できる明確な方法論はありません。 その結果、低コストでの自動データ転送を実現できず、リソースコストが高くなり、開発効率が低下します。
前述の問題に対処するために、Hologres は動的テーブル機能を提供します。 動的テーブル機能は、完全データ処理モードと増分データ処理モードをサポートしています。 これにより、より効率的かつ費用対効果の高い方法で自動データ転送と階層化を実装できます。 Hologres が提供する他の機能とともに動的テーブル機能を使用することで、開発効率と適時性の要件を満たす統一ストレージレイヤー、統一コンピューティングレイヤー、統一データサービスレイヤーを構築できます。
メリット
簡素化されたデータウェアハウスアーキテクチャ
動的テーブル機能は、複数のデータリフレッシュモードをサポートしており、さまざまなレベルのレイテンシを実現します。 これにより、適時性が重要なビジネスのクエリ要件が満たされます。 Hologres は、オンライン分析処理 (OLAP)、オンラインサービス、AI および大規模モデルなど、さまざまなアプリケーションシナリオでのクエリ要件を満たすために動的テーブル機能とともに使用できる、統一されたリアルタイムおよびオフラインデータストレージをサポートしています。 これにより、データウェアハウスアーキテクチャが効果的に簡素化され、開発および運用保守コストが削減されます。
自動データ階層化
動的テーブル機能を使用することで、データを自動的にリフレッシュできます。 これにより、運用データストア (ODS) > データウェアハウス詳細 (DWD) > データウェアハウスサービス (DWS) > アプリケーションデータサービス (ADS) の順序でデータレイヤー間の自動データ転送が実装され、データ階層化におけるユーザーエクスペリエンスが向上します。
ETL 効率の向上
完全データリフレッシュモードと増分データリフレッシュモードがサポートされており、さまざまな適時性の要件を満たします。 増分データリフレッシュモードでは、増分データのみが処理されます。 これにより、ETL プロセスで計算されるデータ量が削減され、データ処理効率が大幅に向上します。
簡素化された開発と保守
リフレッシュタスク、およびデータ間の階層と依存関係が自動的に管理されます。 これにより、開発および運用保守プロセスが簡素化され、開発効率が向上します。

用語
ベーステーブル
動的テーブルのデータソースとして機能するテーブル。 ベーステーブルは、単一の内部テーブルまたは外部テーブル、あるいは複数テーブルの関連付けにすることができます。 サポートされるベーステーブルの種類は、データリフレッシュモードによって異なります。 詳細については、「動的テーブルの適用範囲と制限」をご参照ください。
クエリ
動的テーブルの作成時に指定されたクエリ。 クエリは、ベーステーブルのデータを処理するために使用される ETL プロセスに相当します。 サポートされるクエリの種類は、データリフレッシュモードによって異なります。 詳細については、「動的テーブルの適用範囲と制限」をご参照ください。
リフレッシュ
ベーステーブルのデータ変更を動的テーブルに更新するために行われるリフレッシュ操作。 リフレッシュタスクは、指定されたリフレッシュ操作の開始時刻とリフレッシュ間隔に基づいて、バックグラウンドで自動的に実行されます。 リフレッシュタスクの監視と保守の方法については、「動的テーブルのリフレッシュタスクを保守する」をご参照ください。
仕組み
リフレッシュタスクは、動的テーブルのクエリで定義されたデータ処理プロセスに基づいて、ベーステーブルのデータを動的テーブルに書き込むために使用されます。 このセクションでは、データリフレッシュモード、計算リソース、データストレージ、テーブルインデックスの側面における動的テーブル機能の部分的な技術的原則について説明します。
リフレッシュモード
動的テーブル機能は、完全データリフレッシュモードと増分データリフレッシュモードをサポートしています。 動的テーブル機能の技術的原則は、データリフレッシュモードによって異なります。
完全データリフレッシュ
このモードでは、リフレッシュ操作が実行されるたびに完全データが処理され、ベーステーブルのデータ集計結果がマテリアライズされて動的テーブルに書き込まれます。 このモードの技術的原則は、INSERT OVERWRITE 文の原則と似ています。
増分データリフレッシュ
このモードでは、リフレッシュ操作が実行されるたびにベーステーブルの増分データのみが読み取られ、中間集計ステータスと増分データに基づいて最終結果が計算され、動的テーブルに書き込まれます。 完全データリフレッシュモードと比較して、増分データリフレッシュモードは、毎回より少量のデータを処理するために使用されます。 これにより効率が向上し、リフレッシュタスクの適時性が向上し、計算リソースの消費が削減されます。
仕組み
増分データリフレッシュモードで動的テーブルを作成し、ストリームまたはバイナリロギング方式を使用してベーステーブルから増分データを読み取ると、システムは基盤となるレイヤーに列指向のステートテーブルを作成して、クエリの集計ステータスを保存します。 Hologres エンジンは、コーディングとストレージの面で中間集計ステータスを最適化し、中間集計ステータスの読み取りと更新を高速化します。 増分データはメモリ内でマイクロバッチに集計され、ステートテーブルのデータとマージされます。 その後、最新の集計結果がバルクロードモードで動的テーブルに効率的に書き込まれます。 マイクロバッチで増分データを処理する方法は、単一のリフレッシュ操作で処理されるデータ量を削減し、計算の適時性を大幅に向上させます。
ベーステーブルから増分データを読み取るためのストリーム方式とバイナリロギング方式の比較
増分データ読み取り方式
原則
読み取りパフォーマンス
特性
使用方法に関する注意
ストリーム (推奨)
この方式は、ファイルレベルでデータの変更を識別し、ベーステーブルの増分データを計算します。
バイナリロギング方式のパフォーマンスの 10 倍以上
この方式は使いやすいです。
増分変更を個別に記録しないため、追加のストレージオーバーヘッドがなく、バイナリログの存続時間 (TTL) 期間を管理する必要もありません。
行指向テーブルをベーステーブルとして使用することはできません。
バイナリロギング
この方式は、ベーステーブルへの DML 変更を記録し、基盤となるストレージレイヤーにバイナリログとして保存します。 ベーステーブルの増分消費中に、システムはバイナリログを読み取ることで増分データの変更を識別します。
低
DML 変更を記録するため、追加のストレージコストが発生します。
バイナリログの TTL 期間を管理する必要があります。 そうしないと、データが変更または増加するにつれて、ストレージの使用量が継続的に増加します。
なし。
注意事項
増分データリフレッシュモードでサポートされるベーステーブルには、特定の制限が課せられます。 詳細については、「動的テーブルの適用範囲と制限」をご参照ください。
増分データリフレッシュ用の組み込みステートテーブルは、一定量のストレージを占有します。 システムは、設定された存続時間 (TTL) に基づいてデータを定期的にクリーンアップします。 関数を使用して、ステートテーブルのストレージサイズを表示できます。 詳細については、「動的テーブルの構造と系列をクエリする」トピックの「ステートテーブルを管理する」セクションをご参照ください。
計算リソース
リフレッシュタスクの実行に使用される計算リソースは、現在のインスタンスのリソースまたはサーバーレス計算リソースにすることができます。
サーバーレス計算リソース (デフォルトで使用): Hologres V3.1 以降では、リフレッシュタスクの実行にサーバーレス計算リソースが使用されます。 クエリが複雑で大量のデータを処理する必要がある場合は、サーバーレス計算リソースを使用することで、リフレッシュタスクの安定性を効果的に高め、現在のインスタンス内の他のタスクとのリソースの競合を防ぐことができます。 また、単一のリフレッシュタスクの計算リソースを変更して、サーバーレス計算リソースをより効率的に使用することもできます。
現在のインスタンスのリソース: 現在のインスタンスのリソースを使用してリフレッシュタスクを実行する場合、リフレッシュタスクはインスタンス内の他のタスクとリソースを共有します。 この場合、ピーク時にはタスクがリソースを奪い合う可能性があります。
データストレージ
動的テーブルは、データストレージの点で標準テーブルと同じです。 デフォルトでは、ホットストレージモードが使用されます。 ストレージコストを削減するために、クエリ頻度の低いデータのストレージモードをコールドストレージに設定できます。
テーブルインデックス
データクエリシナリオでは、動的テーブルを直接クエリできます。これは、集計結果を直接クエリすることと同じです。 これにより、クエリのパフォーマンスが大幅に向上します。 標準テーブルと同様に、動的テーブルに行または列ストア、分散キー、クラスタリングキーなどのテーブルインデックスを設定できます。 ほとんどの場合、Hologres エンジンは、動的テーブルのクエリに基づいて必要なインデックスを導き出すことができます。 さらにチューニングが必要な場合は、動的テーブルのインデックスを再設定することで、クエリのパフォーマンスを大幅に向上させることができます。
マテリアライズドビューとの比較
動的テーブルと Hologres リアルタイムマテリアライズドビューの比較
Hologres V1.3 は、SQL 文を使用したマテリアライズドビューの管理機能を提供します。 ただし、この機能によって提供されるデータ処理機能は比較的弱いです。 次の表に、Hologres 動的テーブルと Hologres リアルタイムマテリアライズドビューの違いを示します。
機能 | Hologres 動的テーブル | Hologres リアルタイムマテリアライズドビュー |
ベーステーブルの種類 |
| 単一の内部テーブル |
ベーステーブルで実行できる操作 |
| 追加モードでのデータ書き込み |
リフレッシュの原則 | 非同期リフレッシュ (完全データリフレッシュまたは増分データリフレッシュ) | 同期リフレッシュ |
リフレッシュの適時性 |
| リアルタイム |
クエリの種類 |
説明 サポートされるクエリの種類は、データリフレッシュモードによって異なります。 詳細については、「動的テーブルの適用範囲と制限」をご参照ください。 | 集約関数や RB 関数などの制限付きオペレーター |
クエリモード | 動的テーブルを直接クエリする |
|
動的テーブルと非同期マテリアライズドビューの比較
現在の市場では、OLAP 製品の非同期マテリアライズドビューと Snowflake の動的テーブルは、Hologres の動的テーブルと類似の機能を提供しています。次の表に違いを示します。
機能 | Hologres 動的テーブル | OLAP 製品の非同期マテリアライズドビュー | Snowflake 動的テーブル |
ベーステーブルの種類 | 説明 |
|
|
リフレッシュモード |
|
|
|
リフレッシュ適時性 | 時間レベル |
| |
クエリタイプ | 説明 |
|
|
クエリモード |
| 動的テーブルの直接クエリ | |
監視または運用保守 |
| さまざまなメトリクス | 視覚化された UI |
シナリオ
動的テーブル機能を使用して、データ処理とストレージを自動化できます。 動的テーブル機能は、データクエリの高速化とビジネスの適時性の向上に役立ちます。 Lakehouse アクセラレーションとデータレイヤリングのシナリオで動的テーブル機能を使用することをお勧めします。
Lakehouse アクセラレーション
動的テーブル機能を使用する場合、ベーステーブルのデータは、Hologres テーブル、MaxCompute などのデータウェアハウス、または Object Storage Service (OSS) や Paimon などのデータレイクからのデータにすることができます。 タイムリーなデータクエリと探索の要件を満たすために、ベーステーブルのデータに対して完全または増分リフレッシュを実行できます。 推奨シナリオ:
定期レポートクエリ
定期レポートクエリなどの定期的な観察関連のシナリオでは、データ量が少なく、クエリが複雑でない場合、完全または増分データリフレッシュモードを使用して、Lakehouse 内のデータの集計と分析結果を動的テーブルに定期的にリフレッシュできます。 アプリケーション側は動的テーブルを直接クエリして分析結果を取得します。 これにより、レポートクエリが高速化されます。
リアルタイム ダッシュボードまたはレポート
リアルタイム ダッシュボードやリアルタイム レポートなどのシナリオでは、データの適時性が高くなければなりません。 このようなシナリオでは、増分データリフレッシュモードを使用して、Paimon テーブルのデータまたはリアルタイムデータの集計と分析結果を動的テーブルにリフレッシュして、リアルタイムデータ処理を高速化することをお勧めします。 アプリケーション側は動的テーブルを直接クエリしてデータ分析結果を取得し、ほぼリアルタイムの分析を行います。
データレイヤリング
ベーステーブルに大量のデータが含まれており、ビジネスの適時性の要件を満たすために複雑な ETL 処理が必要な場合、一般的なアプローチはデータレイヤリングです。 データウェアハウジングのシナリオでは、マテリアライズドビューや定期スケジューリングなどの複数のスキームがデータレイヤリングのために業界で提供されています。 これらのスキームを使用して、特定の問題を解決できます。 ただし、データの適時性が低い、開発が不便などの問題は依然として存在します。 Hologres の動的テーブル機能は、自動データ処理機能を提供します。 データレイヤリングに動的テーブル機能を使用できます。
データレイヤリングの推奨方法:
Hologres の動的テーブル機能を使用して、データレイヤー DWD、DWS、および ADS を構築します。
データレイヤー間のデータ同期に増分データリフレッシュモードを使用します。 これにより、各レイヤーで処理されるデータ量が少なくなり、不要な反復計算が削減され、データ同期が高速化されます。 また、Serverless Computing 機能を使用して、ビジネス要件に基づいてリフレッシュ タスクを実行し、リフレッシュ タスクの適時性と安定性をさらに向上させることもできます。
各レイヤーのデータ標準の一貫性を確保するために、各レイヤーのデータをリフレッシュする場合は、完全データリフレッシュモードを使用します。 また、Serverless Computing 機能を使用して、ビジネス要件に基づいてリフレッシュ タスクを実行し、リフレッシュ タスクの適時性と安定性をさらに向上させることもできます。
Hologres で各データレイヤーを構築します。 データレイヤーは明確であり、ビジネス要件に基づいて各レイヤーでクエリを実行できます。 これにより、データの可視性と再利用性が確保されます。
Hologres の動的テーブル機能を使用して、データ処理と アプリケーション を完了できます。 これにより、データウェアハウスの開発と O&M 効率が大幅に向上します。
