はじめに: MaxCompute の新しい Transaction Table2.0 (以下、Transaction Table 2.0) テーブル タイプは、2023 年 6 月 27 日にテストで利用可能になります。これは、Transaction Table 2.0 に基づいた、ほぼリアルタイムのデータ ストレージとコンピューティング ソリューションをサポートします。
著者: Shi Yuyang 氏、 Renjia シニア データ R&D エンジニア
事業紹介
Renrenjia は、Alibaba Dingding と Renrenwo が共同投資して設立したインターネット企業で、顧客が人材のデジタル化に参入し、製品と技術の革新に頼って戦略を推進できるよう支援します。同社は主に人事管理、給与管理、社会保険管理、付加価値サービスなどの人事SaaSサービスを提供し、人事領域のエンパワーメントを加速し、人事における新たな働き方を実現している。現在、電子商取引、小売サービス、その他の分野の複数の業界の顧客にサービスを提供しています。
Renrenjia は典型的な新興企業です。現在、競争の激しい市場環境にあります。同社は複数の製品を所有しており、各製品のデータは独立しています。同時に、社内の CRM データのニーズを満たし、より適切に統合するために、これはデータ ウェアハウス チームにとって大きな課題であり、安定性、正確性、タイムリーな対応が求められます。データ ウェアハウス チームは、内部データのニーズを満たすだけでなく、コンピューティング コストを最適化することも求められます。
ビジネスの問題点
Alibaba Cloud のビッグデータ コンピューティング サービス MaxComputeを使用する過程で、ストック データが増加するにつれて、増分データ重複排除のコストがますます増大していることが判明し、具体的に分析した結果、次の 4 つの理由が判明しました。
増分データの規模が小さい
同社は複数の製品を持っていますが、毎日の新しいユーザー データと履歴変更の量は、すべての履歴データの規模 (GB) に比べて小さい規模 (MB) です。
過去データの二次計算
増分データ重複排除では、昨日の完全な履歴データと今日の新しいデータを使用してウィンドウ重複排除計算を毎日実行します。ただし、完全な履歴データに対して更新する必要があるデータの量は実際には非常に少量であり、履歴データは計算すると、これは間違いなく比較的大きな計算コストになります。
重複を削除するためのウィンドウ処理は計算コストが高くなります
row_number 関数を使用してウィンドウを開いて重複を排除し、ビジネス主キーの最新データを取得するには、昨日の履歴データと今日のデータを組み合わせる必要があります。ユーザー テーブルのサイズは数億です。ただし、ストレージ コストとその後のモデリングを節約するために、データ重複排除のための操作を実行する場合、この部分のコストはかなり大きくなりますが、実際、履歴データのほとんどは更新されておらず、基本的に計算処理を再度行う必要はありません。単一の SQL ステートメントの推定コストユーザーテーブルの重複排除を 1 日 1 回行うのにかかる費用は 4.63 元です (従量課金制)。
全額引き出すとコストがかかる
ビジネスデータベースのデータを毎日フルに取得すると、データ量は数億単位になりますが、実際には更新されるデータの量は少ないため、ビジネスエンドのデータベースに大きな負担がかかり、業務に深刻な影響を及ぼします。ビジネスエンドデータベースのパフォーマンス。
トランザクション Table2.0 データ重複排除の改善
MaxCompute の新しいTransaction Table2.0 (以下、Transaction Table 2.0) テーブル タイプは、2023 年 6 月 27 日にテストで利用可能になります。MaxCompute は、Transaction Table 2.0 に基づくほぼリアルタイムのデータ ストレージとコンピューティング ソリューションをサポートします。人事データ ウェアハウスの研究開発チームはすぐにその特徴と機能を理解し始め、その特徴的な主キー モデルを使用してデータの重複を排除し、ウィンドウ処理の計算コストを削減できることを発見しました。主な実装方法は次のとおりです。
- 毎日増分されるユーザーの基本情報が開かれ、複製されます。
- 主キーテーブルの主キーを空にすることはできないため、ビジネス主キーが空であるデータをフィルタリングして除外する必要があります。
- ウィンドウ化された毎日の増分データと重複排除されたデータを主キー テーブルに直接挿入すると、システムはビジネス主キーに基づいて重複排除計算を自動的に実行します。
具体的な改善策
総合比較
| 重複排除 SQL 実行時間 (単位 s) | 重複排除 SQL の推定コスト (単位元) | |
|---|---|---|
| 普通の時計 | 151 | 4.63 |
| トランザクションテーブル2.0 | 72 | 0.06 |
コストと計算時間の比較
1. table ステートメントを作成し、update ステートメントを挿入します。
更新ステートメント
2. 費用と計算
パーティション テーブルの重複排除操作の推定コスト:
概算費用は、実際の請求基準としては使用できませんので、参考値としてご利用ください。実際の費用は請求書を参照してください。
主キーテーブルの重複排除の実行にかかる推定コスト:
概算費用は、実際の請求基準としては使用できませんので、参考値としてご利用ください。実際の費用は請求書を参照してください。
パーティションテーブルの計算時間とリソース
トランザクション テーブル 2.0 の主キー テーブルの計算時間とリソース
上記の比較により、ユーザーテーブルの毎日の計算SQLコストは4.63元から0.06元に低下し、計算時間は半分に短縮され、reduce_numが大幅に増加し、マップ側が減少し、リデュース側のデータ量が大幅に増加しました。 。
小さなファイルを結合する
トランザクション テーブル 2.0 は、ほぼリアルタイムの増分書き込みとタイムトラベル クエリ機能をサポートしています。データが頻繁に書き込まれるシナリオでは、必然的に多数の小さなファイルが導入されます。小さなファイルをマージするには、合理的かつ効率的なマージ戦略を設計する必要があります。これにより、多数の小さなファイルに対する IO の読み取りおよび書き込みの非効率性が解決され、ストレージ システムへの負荷が軽減されますが、頻繁な圧縮によって引き起こされる深刻な書き込み増幅や競合エラーも回避する必要があります。
現在、データを結合するには主に 2 つの方法があります。
- クラスタリング: データの内容を変更せずに、コミットの DeltaFile を大きなファイルにマージするだけです。このシステムは、新しく追加されたファイルのサイズやファイル数などの要因に基づいて定期的に実行され、ユーザーによる手動操作は必要ありません。主に、小さなファイル IO の読み取りおよび書き込みの効率と安定性の問題を解決します。
- 圧縮: すべてのデータ ファイルは特定の戦略に従ってマージされ、新しい BaseFile のバッチが生成されます。同じ PK を持つデータ行には最新のステータスのみが保存され、履歴ステータスやシステム列情報は含まれません。したがって、BaseFile は実行します。タイムトラベル操作はサポートされておらず、主にクエリ効率を向上させるために使用されます。ビジネスシナリオに応じてユーザーがアクティブにトリガーできるようサポートするほか、テーブル属性を設定することでシステムによる定期的な自動トリガーもサポートします。
要約すると、増分データが主キー サーフェスに直面した場合、小さなファイルはすぐにマージされず、多数の小さなファイルが生成され、大量のストレージ領域を占有し、データの保存に役立ちません。上記の状況を考慮して、挿入後に主キー テーブルを手動でマージする小さなファイルを追加したり、設定によって時間頻度やコミット数などの次元に応じて圧縮メカニズムを自動的にトリガーしたりすることができます。テーブルのプロパティを変更するか、システムによるクラスタリングのマージを待ちます。データが 1 日に 1 回だけ更新される場合は、システムのクラスタリング メカニズムを使用することをお勧めします。
注意点：
desc extend table_name で表示される file_num と size には、ごみ箱データが含まれています。現時点では、これを正確に表示する方法はありません。ごみ箱データをクリアするか、圧縮を使用して、ログの末尾にある filenum の数を確認します。
データの時間と空間の移動クエリと履歴データの修復
トランザクション テーブル 2.0 タイプのテーブルの場合、MaxCompute は、履歴スナップショット クエリ (TimeTravel クエリ) について、ソース テーブルの特定の履歴時間またはバージョンに戻るクエリをサポートします。また、履歴増分に対してソース テーブルの特定の履歴時間間隔またはバージョン間隔の指定もサポートします。クエリ (増分クエリ)。クエリ)、TimeTravel クエリと増分クエリを使用するには、acid.data.retain.hours を設定する必要があります。
データタイムトラベルクエリ
1. TimeTravel に基づいて、指定された時刻までのすべての履歴データ (日時形式の文字列定数など) をクエリします (設定が必要です)。
select * from mf_tt2 timestamp as of '2023-06-26 09:33:00' where dd='01' and hh='01';
履歴データとバージョン番号のクエリ
show history for table mf_tt2 partition(dd='01',hh='01');
指定されたバージョン定数までのすべての履歴データをクエリします
select * from mf_tt2 version as of 2 where dd='01' and hh='01';
2. 増分クエリに基づいて、指定された時間間隔の履歴増分データ (日時形式の文字列定数など) 定数値は、特定の操作の時間に応じて構成する必要があります。
select * from mf_tt2 timestamp between '2023-06-26 09:31:40' and '2023-06-26 09:32:00' where dd= '01' and hh='01';
指定されたバージョン間隔の履歴増分データをクエリします。
select * from mf_tt2 version between 2 and 3 where dd ='01' and hh = '01';
データ修復
TimeTravel クエリに基づいて、指定された時刻までの全データが一時テーブルに直接挿入され、現在のトランザクション テーブル 2.0 の主キー テーブルのデータがクリアされ、一時テーブルのデータが現在のトランザクション テーブル 2.0 の主キーに挿入されます。テーブル。
注意点と今後の予定
データを動的に完全削除する
履歴データをハード削除する方法はありません (この部分は flink-cdc に依存する必要があります)。現時点では、ソフト削除、または一定期間の履歴データの蓄積を通じて実現でき、すべての履歴データをフィルタリングして再挿入できます。全体として主キー テーブルに追加します。ここで言及すべき点の 1 つは、flink-cdc+flink-sql はデータのリアルタイムのハード削除をサポートしていますが、単一テーブルの flink-cdc タスクは比較的重く、複数のテーブルには異なるタスクが必要であるということです。 server-ids. ソースで DB 負荷が深刻なビジネス システムには推奨されません。後続の cdas データベース全体の同期を楽しみにしています。
収納スペースの増加
トランザクション テーブル 2.0 の主キー モデルのデータ ストレージ スペースは、パーティション テーブルのウィンドウ処理後のデータよりわずかに大きくなりますが、その主な理由は、ウィンドウ処理後のデータがより均等に分散され、データ圧縮率が大きいためです。 SQL の毎日のデータを使用すると、1 回限りのコンピューティング コストとストレージ スペースの毎日のコストは、より低いコスト レベル (無視できるほど) になります。
フリンクCDC
flink-cdcと連携することで、準リアルタイムのデータ同期を直接実現し、データの鮮度を向上させることができます。
データベース全体の同期
Alibaba Cloud のリアルタイム コンピューティング Flink cdas 構文ターゲットが MaxCompute 側と統合されて、完全なライブラリ同期と DDL 変更が実現されることを楽しみにしています。
マテリアライズドビュー
これは、マテリアライズド ビュー + flink-cdc の組み合わせを使用して実行できます。