Data modeling

マテリアライズドビューを使用したデータモデリング

このトピックでは、StarRocksの非同期マテリアライズドビューを使用してデータモデリングを行う方法について説明します。これにより、データウェアハウスのETLパイプラインを大幅に簡素化し、データ品質とクエリパフォーマンスを大幅に向上させることができます。

概要

データモデリングとは、データをクリーンアップし、階層化し、集約し、関連付けることによって、合理的な方法論でデータを処理するプロセスです。これにより、粗すぎる、複雑すぎる、または直接分析するためにコストがかかりすぎる生データのわかりやすい表現が作成され、データに関する実行可能な洞察が提供されます。

しかし、現実世界のデータモデリングでは、モデリングプロセスがビジネスの発展のペースに追いつくのに苦労し、データモデリングの投資対効果を測定することが難しいという共通の課題があります。モデリング手法はシンプルですが、ビジネスの専門家はデータの整理とガバナンスについての堅固なバックグラウンドを持っている必要があり、これは複雑なプロセスです。ビジネスの初期段階では、意思決定者はデータモデリングに十分なリソースを割くことはめったにありませんし、データモデリングがもたらす価値を見ることが難しいです。さらに、ビジネスモデルは急速に変化することがあり、モデリング手法自体も反復と進化が必要です。そのため、多くのデータアナリストはモデリングを回避し、生データを直接使用する傾向があります。その結果、データ品質とクエリパフォーマンスの問題が避けられません。モデリングの必要性が生じた場合、既に確立されたデータモデルのデータ分析パターンをデータモデルに合わせて再構築することが困難になります。

マテリアライズドビューを使用してデータモデリングを行うことで、これらの問題を効果的に解決することができます。 StarRocksの非同期マテリアライズドビューは以下の機能を持っています：

データウェアハウスアーキテクチャの簡素化：StarRocksがワンストップのデータガバナンス体験を提供するため、他のデータ処理システムを維持する必要がなくなり、人的およびシステムリソースを節約することができます。
データモデリングの経験を容易にする：基本的なSQLの知識だけで、どのデータアナリストでもStarRocksを使用してデータモデリングができます。データモデリングはもはや経験豊富なデータエンジニアの専売特許ではありません。
メンテナンスの複雑さを削減：StarRocksの非同期マテリアライズドビューは、データレイヤ間の血統関係と依存関係を自動的に管理し、このタスクを処理するための完全なデータプラットフォームを必要としません。

実際のビジネスシーンでは、StarRocksのビュー（論理ビュー）と非同期マテリアライズドビューの使用を組み合わせてデータモデリングを行うことができます。

ビューを使用してリアルタイムデータと次元データを関連付け、マテリアライズドビューを使用してデータレイクからの歴史データを次元データと関連付けます。必要なデータクリーニングと意味マッピングを実行して、ビジネスシナリオで必要とされる詳細データを持つ中間レイヤを取得します。
アプリケーションレイヤでは、ビジネスシナリオに合わせたデータの結合、集計、連結、ウィンドウ演算を実行します。これにより、リアルタイムパイプライン用のビューとネアリアルタイムパイプライン用のマテリアライズドビューが得られます。
アプリケーションの側で、タイムリネスとパフォーマンスの要件に基づいて適切な解析データストア（ADS）を選択します。これらのADSはリアルタイムのダッシュボード、ネアリアルタイムのBI、アドホッククエリ、定期レポートにサービスを提供できます。

このプロセスでは、StarRocksのいくつかの組み込み機能を活用します。これらの機能については、次のセクションで詳しく説明します。

非同期マテリアライズドビューの機能

StarRocksの非同期マテリアライズドビューには、データモデリングに役立つ次の機能があります。

自動リフレッシュ：データがベーステーブルにロードされた後、マテリアライズドビューは自動的にリフレッシュされます。外部のスケジューリングタスクの保守は必要ありません。
パーティションリフレッシュ：タイムシリーズを特徴とするテーブル上に構築されたマテリアライズドビューのパーティション化リフレッシュにより、ネアリアルタイムな計算が実現されます。
ビューとの相互運用性：マテリアライズドビューと論理ビューの使用により、マルチレイヤモデリングを実現し、中間レイヤを再利用し、データモデルを簡素化することができます。
スキーマ変更：複雑なデータパイプラインを変更する必要なく、シンプルなSQLステートメントを使用して計算結果を変更することができます。

これらの機能を使用することで、さまざまなビジネスニーズとシナリオに対応した包括的で適応性のあるデータモデルを設計することができます。

自動リフレッシュ

非同期マテリアライズドビューを作成する際に、リフレッシュ戦略をREFRESH句を使用して指定することができます。現在、StarRocksは以下のリフレッシュ戦略をサポートしています。

自動リフレッシュ (REFRESH ASYNC): ベーステーブル内のデータが変更されるたびにリフレッシュタスクがトリガされます。データの依存関係はマテリアライズドビューによって自動的に管理されます。
スケジュールされたリフレッシュ (REFRESH ASYNC EVERY (INTERVAL <refresh_interval>)): 定期的な間隔（例：毎分、毎日、毎月）でリフレッシュタスクがトリガされます。ベーステーブルにデータの変更がない場合、リフレッシュタスクはトリガされません。
手動リフレッシュ (REFRESH MANUAL): REFRESH MATERIALIZED VIEWを手動で実行することでのみリフレッシュタスクがトリガされます。このリフレッシュ戦略は、リフレッシュタスクをトリガする外部のスケジューリングフレームワークを維持している場合に使用することができます。

構文：

CREATE MATERIALIZED VIEW <name>
REFRESH 
    [ ASYNC | 
      ASYNC [START <time>] EVERY(<interval>) | 
      MANUAL
    ]
AS <query>

パーティションリフレッシュ

非同期マテリアライズドビューを作成する際に、PARTITION BY句を使用して、ベーステーブルのパーティションとマテリアライズドビューのパーティションを関連付けて、パーティションレベルのリフレッシュを実現することができます。

PARTITION BY <column>: ベーステーブルとマテリアライズドビューで同じパーティション列を参照することができます。その結果、ベーステーブルとマテリアライズドビューは同じ粒度でパーティション分割されます。
PARTITION BY date_trunc(<column>): date_trunc関数を使用して、時間単位を切り捨てることで、マテリアライズドビューのパーティション戦略（粒度レベル）を異なるパーティション戦略に割り当てることができます。
PARTITION BY { time_slice | date_slice }(<column>): date_truncと比べて、time_sliceおよびdate_sliceはより柔軟な時間粒度の調整を提供し、時間に基づいたパーティショニングをより細かく制御することができます。

構文：

CREATE MATERIALIZED VIEW <name>
REFRESH ASYNC
PARTITION BY 
    [
        <base_table_column> | 
        date_trunc(<granularity>, <base_table_column>) |
        time_slice(<base_table_column>, <granularity>) | 
        date_slice(<base_table_column>, <granularity>)
    ]
AS <query>

ビューとの相互運用性

マテリアライズドビューはビューを元に作成することができます。この場合、ビューが参照するベーステーブルがデータの変更を受けると、マテリアライズドビューが自動的にリフレッシュされます。
他のマテリアライズドビューを元にしてマテリアライズドビューを作成することもできます。これにより、多レベルの連鎖リフレッシュメカニズムが可能になります。
マテリアライズドビューを元にしてビューを作成することもできます。これは通常のテーブルと同等のビューです。

スキーマ変更

ALTER MATERIALIZED VIEW SWAPステートメントを使用して、2つの非同期マテリアライズドビュー間でのアトミックな交換を実行することができます。これにより、新しいマテリアライズドビューを作成し、列を追加したり列の型を変更したりした後で、古いマテリアライズドビューを置き換えることができます。
ALTER VIEWステートメントを使用して、ビューの定義を直接変更することができます。
StarRocksの通常のテーブルは、SWAPまたはALTER操作のいずれかを使用して変更することができます。
ベーステーブル（マテリアライズドビュー、ビュー、または通常のテーブル）に変更があると、対応するマテリアライズドビューでカスケード的な変更がトリガされます。

階層化モデリング

現実のビジネスシナリオでは、リアルタイムの詳細データ、次元データ、データレイクからの歴史的データなど、さまざまな形式のデータソースがあります。一方、ビジネスの要件では、リアルタイムダッシュボード、ネアリアルタイムのBIクエリ、アドホッククエリ、定期レポートなどのさまざまな分析手法が求められます。さまざまなシナリオにはさまざまな要件があります - 柔軟性が必要なもの、パフォーマンスが重視されるもの、コスト効果が重視されるものなど。

明らかに、単一のソリューションではこれらの多様な要求を十分に満たすことはできません。 StarRocksは、ビューとマテリアライズドビューの使用を組み合わせることで、これらのニーズに効率的に対応することができます。ビューは物理的なデータを保持しないため、そのビューがクエリされるたびに、クエリはビューの定義に従ってパースされて実行されます。対照的に、事前計算結果を保持するマテリアライズドビューは、繰り返し実行のオーバーヘッドを防ぐことができます。ビューはビジネスセマンティクスを表現し、SQLの複雑さを簡素化するのに適していますが、クエリの実行コストを削減することはできません。一方、マテリアライズドビューは事前計算によってクエリのパフォーマンスを最適化し、ETLパイプラインを簡素化するために適しています。

以下は、ビューとマテリアライズドビューの違いの要約です：

	ビュー	マテリアライズドビュー
使用例	ビジネスモデリング、データガバナンス	データモデリング、透明な高速化、データレイクの統合
ストレージコスト	ストレージコストなし	プリコンピュート結果の保存によって発生するストレージコスト
更新コスト	更新コストなし	ベーステーブルのデータが更新されるときに発生するリフレッシュコスト
パフォーマンスの利点	パフォーマンスの利点なし	プリコンピュート結果の再利用によって導入されるクエリの高速化
データのリアルタイム属性	ビューはリアルタイムで計算されるため、最新のデータが返されます。	データは事前計算されるため、最新のものとは限りません。
依存関係	ビューは、ベーステーブルの名前を参照しているため、ベーステーブルの名前が変更されるとビューが無効になります。	ベーステーブルの名前の変更はマテリアライズドビューの可用性に影響を与えません。
作成構文	CREATE VIEW	CREATE MATERIALIZED VIEW
変更構文	ALTER VIEW	ALTER MATERIALIZED VIEW

ビュー、マテリアライズドビュー、およびベーステーブルを変更するには、次のステートメントを使用できます：

-- テーブルの変更
ALTER TABLE <table_name> ADD COLUMN <column_desc>;

-- 2つのテーブルを交換する
ALTER TABLE <table1> SWAP WITH <table2>;

-- ビューの定義を変更する
ALTER VIEW <view_name> AS <query>;

-- 2つのマテリアライズドビューを交換する
-- （2つのマテリアライズドビューの名前を交換して、データに影響を与えずに行う）
ALTER MATERIALIZED VIWE <mv1> SWAP WITH <mv2>;

-- 資格情報が外部依存テーブルのデータ変更を無視する
ALTER MATERIALIZED VIEW <mv_name> ACTIVE;

スキーマ変更は次の原則に従います：

テーブルの名前変更とスワップ操作は、依存するマテリアライズドビューを非アクティブに設定します。スキーマ変更操作がマテリアライズドビューが参照するベーステーブルの列で実行される場合、依存するマテリアライズドビューは非アクティブに設定されます。
ビューの定義を変更すると、依存するマテリアライズドビューは非アクティブに設定されます。
マテリアライズドビューがスワップされる場合、それに基づくネストされたマテリアライズドビューは非アクティブに設定されます。
マテリアライズドビューの依存関係がなくなるまで、非アクティブステータスは上方にカスケードします。
非アクティブなマテリアライズドビューはリフレッシュできず、自動的なクエリの書き換えに使用することはできません。
非アクティブなマテリアライズドビューは直接クエリできますが、データの整合性は再度アクティブになるまで保証されません。

非アクティブなマテリアライズドビューのデータの整合性を保証できない場合は、次の方法を使用して機能を回復できます：

手動修復：ALTER MATERIALIZED VIEW <mv_name> ACTIVEを実行することで、非アクティブなマテリアライズドビューを手動で修復することができます。このステートメントは、元のSQL定義に基づいてマテリアライズドビューを再作成します。ただし、SQLの定義はスキーマの変更後も有効である必要があることに注意してください。それ以外の場合、操作は失敗します。
自動修復：StarRocksは、非アクティブなマテリアライズドビューを自動的にアクティブ化しようとしますが、このプロセスのタイムリネスは保証されません。

パーティションモデリング

階層化モデリングに加えて、パーティションモデリングもデータモデリングの重要な側面です。データモデリングには、ビジネスセマンティクスに基づいてデータを関連付け、データの生存期間（TTL）をタイミング要件に応じて設定する必要があることがよくあります。パーティションモデリングは、このプロセスで重要な役割を果たしています。

パーティションモデリングは、階層化モデリングを補完するデータモデリングの重要な側面であり、ビジネスセマンティクスに基づいてデータを関連付け、データの生存期間（TTL）を設定することを含みます。データパーティショニングは、このプロセスで重要な役割を果たします。

データの関連付け方によって、スタースキーマやスノーフレークスキーマなどさまざまなモデリング手法が生まれます。これらのモデルには共通点があります-すべてが事実テーブルとディメンションテーブルを使用しています。一部のビジネスシナリオでは、複数の大規模な事実テーブルが必要ですが、他のシナリオでは複雑なディメンションテーブルやそれらの関係に取り組みます。StarRocksのマテリアライズドビューは、事実テーブルのパーティション関連付けをサポートしており、事実テーブルがパーティション化され、マテリアライズドビューの結合結果も同じようにパーティション化されます。

以下の図は、マテリアライズドビューが複数の次元テーブルに事実テーブルを関連付ける構造を示しています。

特定のベーステーブル（通常は事実テーブル）のパーティションキー（PARTITION BY fact_tbl.col）をマテリアライズドビューのパーティション化キーとして参照する必要があります。各マテリアライズドビューは、1つのベーステーブルにのみ関連付けることができます。
参照テーブルのパーティションのデータが変更されると、マテリアライズドビューの該当するパーティションが他のパーティションに影響を与えずにリフレッシュされます。
非参照テーブルのデータが変更された場合、デフォルトではマテリアライズドビュー全体がリフレッシュされます。ただし、特定の非参照ベーステーブルのデータ変更を無視するように選択することもできます。

このようなパーティション関連付けは、さまざまなビジネスシナリオで活用できます：

事実テーブルの更新：事実テーブルを日次または時間単位などの細かい粒度でパーティション分割することができます。事実テーブルが更新されると、マテリアライズドビューの該当するパーティションが自動的にリフレッシュされます。
ディメンションテーブルの更新：通常、ディメンションテーブルのデータ更新は関連するすべての結果のリフレッシュにつながりますが、これはコストがかかります。一部のディメンションテーブルのデータ更新を無視してマテリアライズドビュー全体のリフレッシュを回避することもできます。また、時間範囲を指定することで、指定した時間範囲内のパーティションのみをリフレッシュすることもできます。
外部テーブルの自動リフレッシュ：Apache HiveやApache Icebergなどの外部データソースでは、パーティションレベルでデータが変更されます。StarRocksのマテリアライズドビューは、外部カタログの変更をパーティションレベルで購読し、マテリアライズドビューの該当するパーティションのみをリフレッシュします。
TTL：マテリアライズドビューのパーティショニング戦略を設定する際に、保持する最新のパーティション数を設定することで、最新のデータのみを保持することができます。これは、アナリストが一定の時間枠内で最新のデータのみをクエリし、すべての履歴データを保持する必要がないビジネスシナリオに役立ちます。

リフレッシュの動作を制御するためにいくつかのパラメータが使用できます：

partition_refresh_number：リフレッシュ操作ごとにリフレッシュするパーティションの数。
partition_ttl_number：保持する最新のパーティションの数。
excluded_trigger_tables：自動リフレッシュをトリガーするのを避けるために無視されるデータ変更のテーブル。
auto_refresh_partitions_limit：自動リフレッシュ操作ごとにリフレッシュするパーティションの数。

詳細については、CREATE MATERIALIZED VIEWを参照してください。

現在、パーティション化されたマテリアライズドビューには次の制限があります：

パーティション化されたテーブルを基にしてパーティション化されたマテリアライズドビューを作成することができます。
パーティショニングキーとしてDATEまたはDATETIME型の列のみを使用できます。STRINGデータ型はサポートされていません。
date_trunc、time_slice、およびdate_slice関数を使用してパーティションのロールアップを実行することができます。
1つの列のみをパーティショニングキーとして指定できます。複数のパーティショニング列はサポートされていません。

まとめ

StarRocksの非同期マテリアライズドビューを使用したデータモデリングは、パイプライン管理の簡素化と宣言的なモデリング言語による効率と柔軟性の向上という利点を提供します。

データモデリングに加えて、StarRocksの非同期マテリアライズドビューは、透明な高速化とデータレイクの統合を含むさまざまなシナリオで活用されます。これにより、さらなるデータ価値の探求とデータの効率の向上が実現されます。

マテリアライズドビューを使用したデータモデリング

概要​

非同期マテリアライズドビューの機能​

自動リフレッシュ​

パーティションリフレッシュ​

ビューとの相互運用性​

スキーマ変更​

階層化モデリング​

パーティションモデリング​

まとめ​

概要