「アップグレード」という名のもと、クラウドネイティブデータウェアハウスAnalyticDBのコア技術についてお話ししましょう

著者 |ヘンイ

背景

客室のアップグレードといえば、まず思い浮かぶのはエコノミークラスからビジネスクラスまたはファーストクラスへのアップグレードです。 Alibaba CloudのエンタープライズレベルのクラウドネイティブデータウェアハウスAnalyticDB（ADB）[1]も、金融機関を支援するプロジェクトで「アップグレード」の概念を採用しており、主にデジタルトランスフォーメーションと従来のデータウェアハウスのアップグレードに活用されています。

長い間、エンタープライズレベルのデータ ウェアハウスの構築は、主に Teradata、Oracle、DB2、Vertica、Greenplum などに基づいて行われてきました。これらのシステムは、一方では完全に機能し、安定しており、信頼性が高いのですが、他方ではコストが高く、専用のハードウェア制限があるものもあり、同時にビジネス データ量の幾何級数的な増加に対処する必要があります。 Hadoop エコシステムに代表されるビッグデータ システムは、主にデータ分析における大規模データ量の問題を解決します。これらの従来のデータ ウェアハウスと比較すると、機能の完全性、使いやすさ、保守性においてまだギャップがあります。そのため、ほとんどの金融機関は、既存の MPP データ ウェアハウスのコア ビジネスを維持しながら、データの増加によってもたらされるコストの問題を解決し、革新的なビジネス探索のために Hadoop システムを導入しようとしています。一方で近年、海外ではAWS Redshift、Snowflake、Google BigQuery、Azure Synapseに代表されるクラウドネイティブなデータウェアハウス（パブリッククラウド形式）が登場しており、従来のデータウェアハウスやオフライン形式のHadoopシステムに取って代わり、革命を起こす可能性を秘めています。一方、前述の従来のデータウェアハウスメーカーによる国内テクノロジー市場への投資の減少と政策要因が相まって、金融やオペレーターなどの業界はデータ規模の拡大、デジタル変革、従来のデータウェアハウスのアップグレードの必要性に直面しており、次世代のデータ管理および分析システムを選択する必要がある。さらに、国内外の市場や政策の違いにより、わが国の金融、オペレーター、政府などの業界におけるデータウェアハウスの構築は、主にハイブリッドクラウドに基づいています。このような状況において、エンタープライズレベルのクラウドネイティブデータウェアハウスであるAnalyticDBは、金融、オペレーター、政府関係などの業界が、データ規模の拡大、ビジネスのデジタル変革、従来のデータウェアハウスの置き換えやアップグレードの必要性に対応するために、次世代のデータ管理および分析システムを構築できるよう支援することを目的としたアップグレードプランを提案しました。 7月19日、「数千の倉庫とデータベース、ライトクラウドが一気にトップへ - Alibaba Cloud データベースアップグレード計画実践サミット」がオンラインで開催されます。

製品紹介

全体的なアーキテクチャ

AnalyticDB for PostgreSQL（略してADB）は、オープンソースのGreenplum[2]とPostgreSQL[3]をベースに独自に開発されています。構文レベルでは両方と互換性があり、機能レベルではオープンソースの Greenplum のスーパーセットです。また、ほとんどの Oracle および Teradata の構文および関数と互換性があり、最小限の変換作業で既存のデータ ウェアハウス ビジネスを移行およびアップグレードするためのビジネス アプリケーションをサポートします。全体的な構造は次のとおりです。

図1 全体的なアーキテクチャ

ADB は、調整ノードとコンピューティング ノードという 2 つの主要コンポーネントで構成されています。コーディネーション ノードは、グローバル トランザクション管理、グローバル メタデータ ストレージ、SQL 解析、書き換え、最適化、実行プランの生成、およびスケジュール設定を担当します。コンピューティング ノードには、主に実行エンジンとストレージ エンジンが含まれます。実行エンジンは、Greenplum/PostgreSQL の強力なネイティブ エンジンと、データ分析シナリオでのパフォーマンス最適化のための独自開発のベクトル化エンジンの両方をサポートします。ポリモーフィック ストレージ エンジンは、ストレージとコンピューティングの分離アーキテクチャに基づいて、ローカル行ストレージ ヒープ テーブル、列ストレージ圧縮テーブル、外部テーブル、およびクラウド ネイティブ テーブルをサポートします。コーディネーション ノードとコンピューティング ノードは、デュアル レプリカを通じて高可用性を確保し、水平および垂直の拡張を通じてコン​​ピューティング リソースとストレージ リソースの線形拡張を提供します。

ADB は Alibaba Cloud エコシステムと高度に統合されており、OSS をバックアップ ストレージ メディアとして使用して、分散型の一貫性のあるバックアップとリカバリ (完全バックアップと増分バックアップを含む) をサポートします。また、DBS を介して NAS や HDFS などのサードパーティ製ストレージ メディアへのバックアップもサポートします。 OSS に保存されている ORC、Parquet、JSON、CSV 形式のユーザー データ、および MaxCompute 上のユーザー テーブルとパーティションについては、ローカル デバイスへの並列高速インポートとロード、または列フィルタリングと述語プッシュダウンを通じて OSS 上のデータに対して直接データ レイク分析を実行することがサポートされています。クラウドネイティブ アーキテクチャでは、クラウドネイティブ テーブルにはコンピューティング ノード上にローカルにキャッシュされたデータのみが含まれ (コンピューティング ノードはステートレス)、すべてのデータは低コストの OSS に保存されます。

使用シナリオと生態系の統合

上記は、ADB の全体的なアーキテクチャと内部コンポーネントについて説明しています。従来のデータ ウェアハウスを移行および置き換えたり、次世代のデータ管理および分析システムを構築したりするには、可用性と拡張性に優れた分散システム アーキテクチャと、完全に機能する高性能カーネル エンジンに加えて、オープン エコシステムの統合および管理ツールも必要です。次の図は、データ同期からデータ処理、そしてデータクエリと分析まで、データ処理の各段階における ADB のエコロジカル統合、サポートツール、およびシナリオサポート機能を示しています。

図2 使用シナリオとエコシステムの統合

1. データ同期フェーズでは、データはリアルタイム書き込みまたはバッチロードを通じてデータベースに保存され、ODS (Operational Data Model) レイヤーが形成されます。一般的なデータ ソースには、MySQL/SQL Server/PostgreSQL/Oracle などの OLTP ビジネス データベース、ビジネス アプリによって生成されたリアルタイム データ、OSS/MaxCompute/Hadoop 上のアーカイブ データまたは元のデータ、Kafka/Flink からのストリーミング データなどがあります。ADB は、MVCC、2 フェーズ コミット (2PC)、およびグローバル トランザクション管理 (GTM) メカニズムを通じて、分散トランザクション機能 (デフォルトの分離レベルは Read Committed) を提供します。また、リアルタイム書き込みシナリオでの Upsert on Conflict (Oracle の Merge Into に相当) もサポートし、外部テーブル、ファイル、カスタム プログラム出力などの複数の並列高速読み込みシナリオもサポートします。

2. データ処理段階では、ODS レイヤーのデータがデータベース内で処理され、CDM (Common Data Model) レイヤーと ADS (Application Data Service) レイヤーが形成されます。一般的な操作には、INSERT INTO SELECT、CREATE TABLE AS などがあります。3. データ クエリおよび分析フェーズでは、データベース内のデータがビジネス ニーズに応じてクエリおよび分析されるか、下流のシステムによる消費および処理のために提供されます。一般的なクエリおよび分析シナリオには、インタラクティブ分析、BI レポート、データ関連のビジネス アプリケーションなどがあります。ADB は、ストレージ エンジン インデックス ソートなどの機能を通じて、高同時実行性、低レイテンシ、多次元のポイント クエリおよび範囲クエリ シナリオをサポートし、ベクトル化実行エンジン、CBO アダプティブ オプティマイザー、列指向ストレージを通じて、大量のデータや複数テーブルの関連付けと集計を伴う複雑な分析シナリオもサポートします。

製品形態とハードウェアプラットフォーム

ADBは、パブリッククラウド上で国内外の拠点にSaaSサービスを提供するほか、オフライン展開のニーズに応えるため、Alibaba Cloud Apsara Enterprise Edition（ApsaraStack）とAgile Edition（DBStack）を介したハイブリッドクラウド出力もサポートしています。独自のハードウェア プラットフォームを必要とする従来のデータ ウェアハウスとは異なり、ADB 自体は x86 の一般的なハードウェア展開、Arm アーキテクチャ、国産の Kunpeng プラットフォーム、Hygon プロセッサ、Kirin システムなどをサポートしています。一般的なハードウェアと国産プラットフォームのサポートは、金融などの分野でデータ ウェアハウスをアップグレードするための重要な参照要素でもあります。

コアテクノロジー

上記の一般的な製品紹介を通じて、ADB の全体的なアーキテクチャ、使用シナリオとエコツール、製品形式、ハードウェア プラットフォームのサポートについて基本的な理解が得られました。 「アップグレード」プロジェクトのコアテクノロジーのいくつかを詳しく見てみましょう。これには、自社開発のベクトル化実行エンジン、ポリモーフィック ストレージ エンジン、コストベースの適応型オプティマイザー、テナント間の異なるインスタンス間およびテナント内の異なる負荷間のリソース分離、ストレージとコンピューティングが分離されたクラウドネイティブ アーキテクチャが含まれます。

ベクトル化された実行エンジン

PostgreSQL が 1980 年代に誕生したとき、データ ウェアハウス分析 OLAP シナリオはまだ登場していませんでした。主に OLTP シナリオの処理に使用されました。実行エンジンは、レコード指向 (一度に 1 つのタプル) のボルケーノ モデルでした。 Greenplum は PostgreSQL をベースに MPP 分散データベースを構築し、実行エンジン層に Motion ノードを導入しました。これにより、クラスター内の各コンピューティング ノードは単一マシンの PostgreSQL のように実行し、調整ノードが発行した SQL 分散実行プランを共同で完了できるようになります。最後に、クエリ結果が要約され、コーディネーション ノードを通じて返されます。分散並列実行により、単一マシンの PostgreSQL のパフォーマンスボトルネックが大幅に改善されます。ただし、各コンピューティング ノードの実行エンジン内では、PostgreSQL のネイティブ レコード指向モデルが引き続き使用されます (つまり、各演算子は一度に 1 つのレコードを処理します)。この実行モデルは、主にポイント クエリまたは小規模データ処理シナリオに基づく TP シナリオには適していますが、主に大規模データ処理シナリオに基づく OLAP シナリオでは、1 つのレコードを処理するオーバーヘッドが大きく、全体的なパフォーマンスと効率が低くなります。その後、Postgres 上に構築された Redshift、Vertica、Vectorwise (正確には、Postgres の前身である Ingres に基づく) などのデータ分析システムはすべて、元の PG 実行エンジンを置き換えて変革しました。 Redshift は主にコード生成 (JIT、ジャストインタイム コンパイル) とベクトル化スキャンに基づいていますが、Vectorwise は純粋なベクトル化実行に基づいています。 PostgreSQL 11は、SQLでの式処理を高速化するために、式のJIT[4]もサポートしています。

ADB は、ネイティブの Greenplum/PostgreSQL エンジンを維持しながら、大規模なデータ ボリューム分析シナリオを処理するための独自のブロック指向 (一度にバッチ処理) ベクトル化実行エンジンを開発しました。次の図は、2 つの側を関連付けた後に集計する単純な SQL ステートメントを使用して、2 つを比較しています。

図 3 実行モデル: レコード指向とブロック指向の比較 レコード指向では、getNext() インターフェイスを介して一度に 1 つのレコードを取得して処理しますが、ブロック指向モードでは、getNextBlock() インターフェイスを介して一度に複数のレコードを取得します。同時に、各実行オペレータはベクトル化[5]とジャストインタイムコンパイル（JIT）[6]技術を使用して、このレコードのバッチに対して同じ処理ロジックを実行します。その結果、次の利点により、リソースの使用効率が向上し、実行パフォーマンスが向上します。

• 毎回同じロジックを使用してレコードデータのバッチを読み取って処理することで、CPU命令とデータキャッシュのヒット率を高めることができます[7]。
• 1つの関数呼び出しで1つのレコードを処理することから、1つの関数呼び出しでデータのバッチを処理することまで、JITは関数呼び出しを直接回避し、関数呼び出しの総数とオーバーヘッドを削減します[8]。
• メモリの割り当てと回復も、各レコードの割り当てと回復から各レコードのバッチの割り当てと回復に変更され、全体的にメモリの割り当てと回復の回数と断片化管理のオーバーヘッドが削減されました[9]。
• バッチ処理モデルでは、コード実装をベクトル化された方法でより適切に実装できます。 CPUがデータをプリフェッチすることは、一方では有益であり、他方では、プログラムの条件付きジャンプ（if...else...、switch、その他の分岐判断から）と無条件ジャンプ（関数呼び出しから）を最小限に抑え、CPUがより良い命令パイプライン実行[10]を実現し、分岐予測[11]の失敗を減らすことを可能にします。コンパイラがSIMD[12]命令を生成し、実行効率を向上させることも有益である。

次の図は、ハッシュ、バケット アドレス指定、および合計ステップのグループ化および集計 SQL シナリオでの ADB ベクトル化の列ベースのベクトル化実行の例と、スキャンおよびフィルタリング SQL シナリオでの JIT による式計算の実行の例を示しています。

図4 ベクトル化とJIT実装の例

ベクトル化されたバッチ読み取りおよび処理により、処理されるデータと処理命令を CPU L1/L2 キャッシュに常駐させることができます。キャッシュヒットの場合、パフォーマンスはメモリからの読み取りの10～30倍になります[13]。同じ命令をバッチデータで処理すると、CPUパイプラインの実行が改善され、CPUのハザードが軽減されることもあります[14]。 JIT コード生成は、式処理シナリオを対象とし、解釈実行モードでの高頻度の関数呼び出し (関数呼び出し) を直接回避します。

多態的ストレージエンジン

PostgreSQLのネイティブストレージエンジンはヒープテーブル[15]であり、主にOLTPシナリオで使用されます。コア コンポーネントには、デフォルトで 8 KB 単位の行レベル MVCC を備えたデータ ページ、キャッシュ マネージャー バッファー マネージャー、先行書き込みログ WAL、および主に Btree に基づくインデックスが含まれます。 Greenplum は、主に OLAP シナリオ向けに PostgreSQL ベースの分散データベースを構築し、ストレージ層に次の技術的な変更を加えました。

1. コーディネーション ノードは、グローバル メタデータとグローバル トランザクション ステータス管理を追加して、分散アーキテクチャの下でコーディネーション ノード内のメタデータ システム テーブルの読み取りを必要とするトランザクション管理、SQL 解析、実行プラン生成などの操作をサポートします。

2. 分散アーキテクチャ内のテーブルに水平分散メカニズムを追加しました (ハッシュ、ランダム、レプリケーション分散戦略をサポートし、ビジネス レイヤーに対して透過的です)。また、ノード内に垂直パーティション メカニズムを追加しました (範囲パーティションとリスト パーティションをサポートし、PostgreSQL の以降の上位バージョンでもパーティション メカニズムが追加されました)。これら 2 つの組み合わせにより、より大きなデータ スケールとクエリ フィルタリングの効率がサポートされます。

3. 行ストレージ ヒープ テーブルのデフォルトのページ サイズは、データ分析シナリオでスキャン効率を向上させるために 8 KB から 32 KB に設定されています。

4. 新しい列格納圧縮テーブルが追加されます。 PostgreSQL のネイティブの行格納ヒープ テーブルと比較すると、列のプルーニングと圧縮により、分析シナリオのスキャン効率がさらに向上します。さらに、列ストレージ テーブルのタプル ID はヒープ テーブルのタプル ID と同じ 48 ビットのままであり、これを既存の PostgreSQL インデックス メカニズム (Btree、Brin、GIN、GiST など) に直接適用して、指定された列値のインデックス スキャンを実行し、ポイント クエリ シナリオを高速化できます。さらに、MVCC トランザクション分離メカニズムをサポートする行ストレージ ヒープ テーブルが、列ストレージのメタデータ補助テーブルとして使用されます。まず、列ストレージデータのアドレス指定に使用されます。次に、削除をマークすることで追加書き込みに基づいて更新と削除をサポートするために、削除ビットマップが導入されました。同時に、列ストレージ データには間接的に MVCC およびトランザクション分離機能も備わっています。

5. HDFS、Hive、MySQL、PostgreSQL などの外部システムにアクセスするために、PXF 外部テーブルが導入されました。

ADB は、Greenplum をベースに、ローカルの列格納型圧縮テーブルと行格納型ヒープ テーブル (列格納型のソートとマージ、ソートの高速化計算、MIN および MAX 粗フィルタリング、リアルタイム マテリアライズド ビュー、自動分析/バキューム/マージ、アップサートなど) をさらに強化し、外部テーブル用の Alibaba Cloud OSS と MaxCompute の並列インポートとデータ レイク分析機能を追加しました。同時に、クラウドネイティブ ストレージとコンピューティング分離テーブルが追加され (クラウドネイティブ アーキテクチャ製品フォームでサポート)、ストレージはオンデマンドで課金され、柔軟で弾力性のあるスケーリングとデータ共有がサポートされます。次の図は、ADB ポリモーフィック ストレージ エンジンの概要を示しています。

図5 ポリモーフィックストレージエンジン

以下は、ストレージ エンジン層における ADB の独自開発機能のいくつかに関する技術的な詳細です。

スパースインデックス

Min&Max Skip Index は、Greenplum 列ストレージに ADB が追加した最初の独自開発機能です。これは、PostgreSQL 9.5 でサポートされている BRIN に似ています。簡単に言えば、列格納テーブルの対応する列データの各格納ブロック（varblock など）内のすべてのデータの最小値（MIN）と最大値（MAX）を記録します。スキャン時に、フィルタ条件が各ストレージ ブロックの MIN および MAX と比較され、フィルタ条件を含まないストレージ ブロックが除外されます。フィルタリング条件を含む可能性のあるストレージ ブロックについては、特定のデータが読み取られ、解凍され、スキャンされ、比較されて、特定の一致するレコードが取得されます。現在、主流の列ストレージシステムはすべてこの機能を提供しています（Redshiftのゾーンマップ[16]やClickHouseのスキップインデックス[17]など）が、ここでは詳しく説明しません。 ADB は、各ストレージ ブロックの MIN と MAX を記録するだけでなく、連続する複数のストレージ ブロック全体の MIN と MAX も記録するため、さらに迅速なフィルタリングを実現できます。

並べ替え 結合

ソートは列ストレージ エンジンの重要な機能です。主流の列ストレージエンジンは、テーブルを作成するときにソートキーを定義することをサポートしています（Redshiftの複合ソートキー[18]とインターリーブソートキー[19]、Snowflakeのクラスタリングキー[20]、ClickHouseのOrder By[21]など）。また、効率的なスキャンとフィルタリングを実現するために、手動またはバックグラウンドでの自動マージソートもサポートしています。同時に、上記の MIN&MAX スキップ インデックスが実際に機能するには、ソートに依存する必要があります (データが書き込まれるときに自然に順序付けられている場合を除く)。データが無秩序な場合、各ストレージ ブロックの最大値と最小値の範囲にフィルタリング条件が含まれる可能性があることを想像してください。比較すると、スキップできるデータ ブロックは非常に少ないため、MIN&MAX スキップ インデックスは効果がありません。

ADBは、列ストレージソート機能に関して、複合ソート（RedshiftのCompound Sortに相当）と多次元ソート（RedshiftのInterleaved Sortに相当、DatabricksのDelta Lake[22]にもこの機能がある）をサポートしています。両者の違いや使用シナリオについては、ここでは詳しく説明しませんので、Redshiftのブログ[23]を参照してください。新しく書き込まれたデータは、通常、乱雑な状態にあります。 ADB は、複合ソートのバックグラウンド自動ソートとマージをサポートしています (ETL ステップで multisort <table> を実行することで、多次元ソートを実行できます)。優れた自動マージソート戦略では、次の 4 つの目標を達成する必要があります。

1. ほとんどのデータを整然とした状態に保つ（理想的にはすべてのデータが整然とした状態）

2. データ ファイルの数と、データ ファイル内の無効なデータ (削除や更新によるもの) の割合を減らします (理想的には、1 つのファイルにすべての有効で順序付けられたデータが含まれます)。

3. ソートとマージに必要なリソースオーバーヘッド（IO、CPU、MEMを含む）を最小限に抑える

4. フロントエンドのビジネス負荷への影響を最小限に抑える（ロック、リソース競合など）

この分野で公開されているドキュメントがある最高の製品としては、Snowflakeの自動クラスタリング[24]やSingleStoreのバックグラウンドマージャー[25]などがあります。前者は、上記の目標 1、2、3 を達成するために Overlap-Depth の概念を導入し、後者の楽観的/悲観的戦略では、上記の目標すべてを考慮に入れます。

ADB の具体的な実装では、列に格納されたデータを未ソート領域とソート領域の 2 つの部分に分割します。バックグラウンドの自動ソートおよびマージ ワーカーは、未ソート領域のデータをソート済み領域のファイルにソートおよびマージする役割を担います。ソートされた領域は、異なるソートされた部分に分割されます。各ソートパート内の異なる順序のファイルの MIN 値と MAX 値は重複しません。スキャン中、ソートされた部分全体を 1 つの順序付けられたファイルとして扱うことで、スキャン効率を向上させることができます。ソート領域内のデータのスキャンとフィルタリングの効率をさらに向上させるために、ソート領域内の異なるソート部分にあるファイルが自動的に結合され、異なるソート部分間の MIN と MAX の重複が排除され、新しいソート部分が形成されます。ユーザーからの初期のフィードバックを受けて、ソートされていない領域からソートされた領域へのソートのマージは、ソートされた領域内のソートされたパーツ間のマージよりも優先度が高いと考えています。したがって、優先順位の異なる 2 つのシナリオを処理するために、高速ワーカーと共通ワーカーを定義します。同時に、ソートプロセス全体がビジネス側の DML 操作に影響を与えないため、上記の 4 つの目標が達成されます。全体的なソートマージは、以下の図の下半分に示されています。

図6 ソートとマージとクエリの高速化

上の図に示されているもう 1 つの機能は、順序付けられたデータに基づくクエリの高速化です。データは整っています。まず、MIN&MAX スキップ インデックスの有効性が向上し、条件付きフィルタリング中のファイルのスキップと IO のスキャンの精度が向上しました。さらに、実行エンジン自体には、SQL で OrderBy、Group Agg、Merge Join、Distinct などの演算子を実装するのに役立つ Sort 演算子があります。ストレージ エンジン データ自体が順序付けられている場合 (または、リアルタイム書き込みシナリオでは未ソート領域が通常の存在であるため、ほとんど順序付けられている場合)、実行エンジンは、順序付けられたデータを必要とする上記の演算子を実行するときにこれを使用して、追加のソート オーバーヘッドを削減し、全体的なパフォーマンスを向上させることができます。したがって、ADB がここで行うことは、これらの演算子に必要な Sort 演算子を Scan (SortScan と呼びます) にプッシュして、Scan が上位レベルの演算子に吐き出すデータが整然としたものになるようにすることです。データがリアルタイムで継続的に書き込まれるテーブルの場合、各ノード上のデータは通常、ソート済み領域 (大部分) と未ソート領域 (一部) の両方に分散されます。 SortScan の具体的な実装は上の図に示されています。まず、未ソート領域のデータが素早くソートされ（テーブルデータの書き込みや更新が比較的少ない場合、この部分の作業は通常不要です）、次にソート領域のデータとマージおよびソートされて、分割されたデータが全体として整然としたものになり、ソートに依存する上位層の演算子が高速化されます。さらに、順序付けられたデータは、実行エンジンが処理しているときに優れたキャッシュヒット率をもたらし、パフォーマンスを向上させます。たとえば、ハッシュ テーブル計算では、連続した順序付きデータは、カーディナリティが比較的低い場合に繰り返しが多くなり、ハッシュ バケットをアドレス指定するときに連続データ範囲内では常に同じになります。

自動ソートおよびマージは、読み取りと書き込みのパフォーマンスの最適なバランスを実現するために、列ストレージ エンジンがバッチ処理とリアルタイム処理の両方のシナリオをサポートする必要がある場合に不可欠な機能です。

リアルタイムのマテリアライズドビュー

インデックスを使用して SQL データ スキャン演算子 (スキャン) のフィルタリング機能 (インデックス スキャン) を高速化する場合、マテリアライズド ビューを使用してクエリ SQL 全体を高速化します。 PostgreSQL 10[26]とGreenplum 6.2[27]はどちらもマテリアライズドビューのサポートを開始していますが、その機能と使用シナリオは比較的限られています。どちらも手動での完全更新が必要であり、自動クエリ書き換えはサポートされていません。リアルタイム マテリアライズド ビューには通常、自動増分更新機能と自動クエリ書き換え機能が必要です。さらに高度なものには、履歴 SQL 実行ステータスに基づいてマテリアライズド ビューを自動的に作成するバックグラウンドも必要です。 Oracle[28]、Redshift[29]、Snowflake[30]などの主流のデータ管理システムはすべて、自動増分更新とクエリ書き換え機能に関して対応する機能を備えています。

ADB は、ローカル行ストレージ ヒープ テーブル用のリアルタイム マテリアライズド ビュー機能も構築します。全体的なデザインは次のとおりです。

図7 リアルタイムマテリアライズドビュー

ワークフローは次のステップに分かれています。

1. ビューの作成: まず、ユーザーは一般的なビジネス クエリ SQL に基づいて、高速化のために対応するリアルタイム増分マテリアライズド ビューを作成します。

2. ビューの自動メンテナンスと更新: データの書き込み、更新、削除操作は、まずユーザー テーブル自体に対して実行され、対応する変更ログ (新しいデータと削除されたデータを含む) を生成し、デルタ ログに同期します。増分マージ リフレッシュはデルタ ログを読み取り、サポートされている各演算子 (フィルタリング、投影、関連付け、集計など) に増分マージ リフレッシュ アルゴリズムを MV の特定の定義と組み合わせて適用し、マテリアライズド ビューのコンテンツを更新します。

3. 自動クエリ書き換え：SELECTクエリSQL実行時に、SQL自体とライブラリ内のマテリアライズドビュー定義に基づいて書き換えに使用できるマテリアライズドビューを検索し、書き換えを完了することでクエリを高速化します。利用可能なマテリアライズド ビューがない場合、または入力 SQL が自動書き換えをサポートしていない場合でも、元のテーブル データが照会されます。

ADB は現在、マテリアライズド ビューを強力な一貫性モデルとして実装しています。インデックスと同様に、クエリのパフォーマンスを高速化する一方で、書き込みパフォーマンスにも一定の影響を与えます。このようなメカニズム自体は、書き込みパフォーマンスとクエリパフォーマンスの間のトレードオフです。将来的に最終的に一貫性のあるモデルがサポートされる場合、書き込みパフォーマンスとクエリのリアルタイム パフォーマンスの間でトレードオフが発生します。

自動分析と真空

PostgreSQL自体は自動分析[31]と自動バキューム[32]をサポートしています。前者は統計情報を自動的に収集するために使用され、後者はテーブルデータが更新または削除された後にスペースを自動的にリサイクルして再利用するために使用されます。 Greenplum はスタンドアロンの PostgreSQL を分散アーキテクチャに変換しましたが、これら 2 つの機能については分散変換を行っていませんでした。前者はgp_auto_stats_mode[33]に置き換えられましたが、後者はDBAが定期的に実行する必要がありました。 gp_auto_stats_mode の仕組みは、統計情報がない場合に最初のデータ書き込みの終了時に Analyze を自動的にトリガーするようにテーブルを設定するか、書き込まれて更新されるデータの量が一定量に達するたびに Analyze を自動的にトリガーするようにテーブルを設定することです。このメカニズムは、データ ウェアハウスのバッチ インポートやデータ処理のシナリオではうまく機能しますが、リアルタイムの書き込みや更新のシナリオでは問題が発生します。初期の頃、ADB パブリック クラウド オンラインでは、リアルタイム ストリーミング書き込みシナリオで問題がよく発生していました。テーブルでは、少量のデータが初めて書き込まれたときに Analyze が実行されましたが、再度実行されることはありませんでした (on_no_stats 設定)。または、リアルタイム シナリオで毎回書き込まれるデータの量が少ないため、on_change 設定 (gp_autostats_on_change_threshold) で Analyze をトリガーする条件を満たすことはほとんどありませんでした。これら 2 つの状況によって発生する問題は、統計情報が不正確になり、実行プランが不十分になり、クエリ パフォーマンスが低下することです (たとえば、Index Scan の代わりに Seq Scan が使用される、Redistribute Motion の代わりに Broadcast Motion が使用される、Hash Join の代わりに Nestloop Join が使用されるなど)。 DBA に定期的にバキューム処理を実行するように要求することも、クラウドネイティブ データベースの位置付けと一致しません。

このような背景から、ADB は分散アーキテクチャに自動分析機能と自動バキューム機能を追加しました。これにより、各テーブルのデータ量の変化が設定されたしきい値に達したときに、分析とバキュームを自動的にトリガーできます (これは累積計算であり、1 回の変更で達する必要がある gp_auto_stats とは異なります)。この機能は汎用的な機能であることを考慮して、リリース後にそのコードを Greenplum オープンソース コミュニティにも提供しました。

OSSの外観

Alibaba Cloud OSS[34]は、大規模で低コストのオブジェクトストレージシステムであり、データ管理システムでデータレイク分析を構築するための最適な組み合わせでもあります。 ADBは、Alibaba Cloudエコシステムと高度に統合されたPostgres FDW[35]フレームワークに基づく分散アーキテクチャでOSS FDW外部テーブルを実装します。この機能は、RedshiftのSpectrum[36]やSnowflakeの外部テーブル[37]に対応しています。 OSS の登場の全体像とアーキテクチャを次の図に示します。

図8 OSSの外観

ADB ストレージ エンジンは、ローカルの行格納ヒープ テーブルとローカルの列格納圧縮テーブルに基づいて OSS 外部テーブルを追加します。複数の形式 (ORC、Parquet、CSV など) の OSS データをローカル コンピューターに並列かつ高速にロードしたり、ロードせずに直接オンライン分析したり、ローカル テーブルに関連付けられた分析 (OSS 上のファイルは、ロードまたは分析中に処理するために、対応するコンピューティング ノードに自動的に均等にマッピングされます) を実行したりできます。また、列格納テーブルをサポートし、コールド パーティション データを OSS に自動的に階層化します。オンライン分析のパフォーマンスを高速化するために、Analyze は外部テーブルの統計収集とパーティション プルーニング、および ORC と Parquet の列ベースのストレージ データの列プルーニングと述語プッシュダウンをサポートしています。 ADB は、OSS テーブルに加えて、データのバッチ ロード用の Alibaba Cloud Max Compute テーブルもサポートしています。

バックアップとリカバリ

データのバックアップとリカバリは、金融などの業界におけるエンタープライズ レベルのデータ ウェアハウス機能の一般的な要件です。スタンドアロンPostgreSQLは、pg_basebackup + WALアーカイブを通じて継続的なアーカイブとポイントインタイムリカバリ（PITR）[38]をサポートしたり、pg_dumpを通じてテーブルレベルの論理バックアップを実行したりできます。 Greenplum が単一マシンの PostgreSQL に基づく分散アーキテクチャに変換された後、対応するクラスター レベルの物理バックアップと PITR 機能は提供されませんでした。クラスタレベルの論理バックアップは、gpbackupとgprestore[39]を通じてクラスタ/テーブルレベルの並列論理バックアップとリカバリを提供します。 gpbackup 操作中、システムはテーブルを作成または削除したり、テーブル構造を変更したりすることはできません。また、ユーザー テーブルに対して切り捨てなどの操作を実行することもできません。初期の頃、ADB はこれに基づいてインスタンス レベルの論理バックアップとリカバリを定期的に実行していました。パブリック クラウドのビジネス インスタンスは多数あり、顧客ごとにメンテナンス ウィンドウが異なります。同時に、一部のビジネスではメンテナンスの時間枠を見つけることが困難です。同時に、データの量が多くなるほど、バックアップにかかる時間も長くなります。この目的のために、ADBはGPBackupでより微調整されたロック最適化を実行して、バックアップ中のビジネスへの影響を最小限に抑えます（DDLなどの操作をブロックせずに）。最適化は、基本的にバックアップ中の一部のテーブルの一貫性を犠牲にします（ビジネスDDLが発生した場合）が、回復は手動で処理できます。このトレードオフの背景は、回復が低周波動作であることですが、バックアップは毎週または週に複数回発生する高周波動作です。

論理的なバックアップとリカバリが提供できるRPOは比較的低く、デフォルトのバックアップは一般に週に1回です（最悪の場合、RPOも1週間です）。この目的のために、ADBは一貫した物理的増分バックアップとPITR回復の分布を開発しました。これは、単一マシンPostgreSQLのPITR機能を機能的に実現しています。以下に示すように、全体的な設計が実装されています。

図9物理的なバックアップ回復

簡単に言えば、各ノード（調整ノードとコンピューティングノードを含む）は、定期的なグローバル回復ポイントを介した回復中に分布の一貫性を定期的に実行します。この観点から、PITRは、元のクラスターに記録された一連の一貫した回復ポイントの1つを選択することであり、理論的RPOは最後の一貫した回復ポイントの時間であり、回復点サイクルは数分から数時間に設定できます。バックアップデータサイズを最小限に抑えるために、ADBは完全な基本的なバックアップの微分バックアップも実装します。この基本的なバックアップでは、最後の時間から変更されていない対応するテーブルのデータは再びバックアップされていません。バックアップデータストレージメディアレベルでは、パブリッククラウドはOSSを使用し、ハイブリッドクラウドはOSSをサポートするか、DBSを介してNASとHDFをサポートします[40]。

適応オプティマイザー

PostgreSQLには、オーバーヘッドが低く、パフォーマンスが低いコスト推定ベースのプランナーオプティマイザーが搭載されています。 TPシナリオとAP単純な分析シナリオにとって非常に効率的です。 GreenPlumはPostgreSQLを分散アーキテクチャに拡張しましたが、それに応じてプランナーを変更して、モーションノードを含む分散実行計画を生成できるようにしました。 GreenPlumは、CTE、マルチテーブル結合、動的パーティション剪定などの複雑な分析シナリオを処理するために、ORCAオプティマイザー[41]を追加しました。もちろん、一般的に、スタートアップコストはプランナーのコストよりも高くなっています。同時に、いくつかの制限されたシナリオでプランナーに自動的に頼ることができます。プランナーとORCAにはそれぞれ独自の利点があり、完全に機能しており、すべてのAPおよびTPシナリオをカバーしています。したがって、ADBは、実行やストレージエンジンのような自己開発のオプティマイザーを追加しませんでした。代わりに、SQLの解析および書き換えフェーズ中にSQL自体に基づいて実行計画を生成する最適なオプティマイザーを自動的に選択します。同時に、プランのヒント介入機能をプランナーに追加します。これにより、手動介入がいくつかのシナリオで実行計画を部分的に調整することができます。全体的なロジックは次のとおりです。

図10アダプティブオプティマイザー

適応型オプティマイザーの動作は、次のように単純に要約できます。AP複雑なクエリ、ORCAオプティマイザーを有効にして、いくつかの複雑な分析シナリオでより良い実行計画を生成できます。 TPリアルタイムの書き込み更新削除ポイントクエリシナリオ、およびAPシンプルなクエリ分析シナリオは、PostgreSQL独自の分散プランナーオプティマイザーを使用します。これは、ORCAよりもスタートアップ時間が短く、SQL RT全体に影響が少なく、ヒントマニュアルの微調整機能もあります。

マルチテナントリソースの分離

マルチテナンシーとリソースの分離は、クラウドネイティブのデータ倉庫に不可欠な機能です。 ADBは、テナント間の異なるインスタンスのリソース分離と、テナント内の異なる負荷のリソース分離をサポートします。前者（制御機能）は、IAAS層のさまざまなECSインスタンスを介してパブリッククラウドに実装され、コンテナとCgroupメカニズムを介してハイブリッドクラウドに実装されます。後者（カーネル機能）は、GreenPlum独自のResourceQueue [42]、ResourceGroup [43]、およびDiskquota [44]に基づいて実装されています。次の図は、DBSTACKのハイブリッドクラウドアジャイルバージョンを、マルチテナンシーの下での複数のインスタンスの展開を描写する例として、およびリソースグループを介したさまざまなビジネスワークロードの並行性、CPU、およびメモリ使用量の例を描写し、リソースの分離と異なる負荷間の共有を提供します。同時に、Diskquotaを使用して、さまざまなユーザーとさまざまなスキーマのストレージ容量の使用クォータを定義して、ビジネスデータストレージをより適切に計画することができます。

図11マルチテナントとリソースの分離

ADBの初期バージョンは、主にResourceQueueに依存して、ユーザーフレンドリーではない実行キューの並行性とCPUの優先度を制御しました。現在、徐々にリソースグループに移行しており、より洗練された効率的なリソースの粒度制御を提供できます。

クラウドネイティブアーキテクチャのアップグレード

GreenPlum自体は、TeradataやVerticaなどの従来のオフラインデータウェアハウスと同様に、古典的な共有のノーチングアーキテクチャです。同じことが、元のクラウドデータウェアハウスAWS Redshiftにも当てはまります。このタイプのアーキテクチャには、高性能と完全な機能の利点があります。また、線形膨張をサポートします。ただし、データはローカルに保存されているため、拡張には大量のデータ移行が含まれます。これには時間がかかります。移行されているテーブルには、一般に、ビジネス面での読み取りと書き込みの待機が必要です。さらに、異なるビジネス部門が複数のクラスターインスタンスを展開してリソースの分離を確実に展開する場合、各クラスターはデータアイランドです。ビジネスに同じデータの使用が含まれる場合、クラスターインスタンス全体で同期と冗長性が必要です。この要件と制限に基づいて、クラウドネイティブのデータウェアハウススノーフレーク[45]は、ストレージおよびコンピューティング分離アーキテクチャを最初に起動しました。データとメタデータの永続的なストレージは、AWS S3および自動構造分散KVシステムFoundationDBによって提供されます。コンピューティングリソースは、独立した仮想データウェアハウスで構成されており、リソースは互いに分離されています。同時に、共有されたメタデータとデータストレージは、非冗長データ共有を迅速に達成できます。ローカルノードはステートレスであるため、コンピューティングリソース自体は高速で弾力性があります。 Snowflakeのストレージコンピューティング分離アーキテクチャの進化により、RedshiftはRA3ストレージコンピューティングの分離から共有されていないものから進化し、従来のオフラインデータウェアハウスVertiaもEONモード[46]ストレージコンピューティング分離フォームを開始しました。

上記のバックグラウンドに基づいて、ADBはパブリッククラウドのストレージおよびコンピューティング分離アーキテクチャに基づいてサーバーレスモードを起動しました[47]。全体的なアーキテクチャは次のとおりです。

図12クラウドネイティブアーキテクチャのアップグレード

基本的なアイデアは、コンピューティングノードをステートレスにし、メタデータを徐々に抽出し、地域ごとに展開された高性能、分散、スケーラブルなKVシステムに保存し、データを低コストのOSに保存し、局所キャッシュを介してOSSに持続するデータを加速することです。このアーキテクチャに基づいて、データストレージはオンデマンドで支払うことができ、容量を柔軟に拡張または削減することができ、データ共有が現実になる可能性があります。 ADBのCloud-Native Architectureのアップグレードとデータ共有に関する以前の記事の共有とデモンストレーションがありましたが、ここではさらに拡張されません。興味のある読者はチェックアウトできます：マネージャーからネイティブへ、MPPアーキテクチャデータウェアハウスのクラウドネイティブプラクティスの実用的なガイド|インスタンス間のデータ共有の助けを借りて、データウェアハウスのデータフローの問題を解決する方法は？ [48]アップグレードプロセス

上記の製品機能とテクノロジーに加えて、AnalyticDBのUPSERTリアルタイム書き込みカバレッジ、ストアドプロシージャ、システム監視、診断機能は、データウェアハウスの交換とアップグレードの非常に重要な機能です。

以下は、図に示すように、従来のエンタープライズデータウェアハウスからADBへのアップグレードプロセスの紹介です。

図13アップグレードプロセス

全体的なプロセスは4つのステップに分かれています。

1.既存のシステムとビジネス移行を評価します。 Alibaba Cloudは、OracleおよびTeradataからADBへのほとんどのDDLおよびSQLステートメントの自動変換をサポートするAdam Migration Assessmentおよび適応ツールを提供します。

2。ビジネスアプリケーションは、必要に応じて変換および適応され、DDLと既存のシステムデータは同時にADBに移行されます。 DTSデータの同期とトランスミッションサービスは、OracleからADBへのリアルタイム同期をサポートし、高速並列バッチインポートを通じて1回限りの移行を完了することもできます。同時に、ADB自体は、GreenPlum Kernel TechnologyとCloud-Native Architectureのアップグレードの進化に基づいており、サードパーティの生態学的ツールとの互換性があります。

3。ビジネスのデュアルラン検証。この段階では、ビジネスカットオーバーへの移行にグレースケールメカニズムを導入できます。

4.サービスはADBに削減されます。

アップグレードプロジェクトの開始以来、ADBは、既存のビジネスシステムにおけるTeradata、Oracle、DB2、およびGreenPlumの代替およびアップグレードを含む、金融（銀行、保険、証券）、オペレーター、政府、およびその他の業界で多くの成功したケースとベンチマークを獲得しています。

要約する

アップグレード、データウェアハウステクノロジーの進化、およびビジネスニーズの背景から始めて、この記事では、Alibaba CloudのCloud-Native Data Warehouse AnalyticDB、使用シナリオ、エコシステム統合、製品フォーム、およびハードウェアプラットフォームのサポートの全体的なアーキテクチャを紹介します。次に、自己開発のベクトル化された実行エンジン、ポリ型ストレージエンジン、適応オプティマイザー、マルチテナントリソース分離、クラウドネイティブアーキテクチャのアップグレードなど、アップグレードで使用されるコアテクノロジーを導入します。自己開発テクノロジーレベルでは、スタンドアロンPostgreSQLの対応する機能、PostgreSQLでの変換後のGreenPlumの対応する機能、および業界における主流製品の関連する機能と技術、および分析DBの対応する能力と特定の技術設計と実装ルートの技術的な説明を提供します。最後に、キャビンアップグレードの4段階のプロセスが要約されています。この記事が読者にADBの製品アーキテクチャとコアテクノロジーの包括的な理解を提供し、ビジネスのアップグレードの実現可能性を評価するためにも使用できることが期待されています。

参考リンク:

[1] https://www.aliyun.com/product/gpdb

[2] https://arxiv.org/pdf/2103.11080.pdf

[3] https://www.postgresql.org/

[4] https://www.postgresql.org/docs/11/jit.html

[5] https://www.youtube.com/watch?v=hn4l8xc3-pq

[6] https://www.youtube.com/watch?v=dvhqgmrquak

[7] https://medium.com/@tilakpatidar/vectorized-compiled-queries-part-2-cd0d91fa189f

[8] https://www.ibm.com/docs/en/xl-cpp-linux/16.1.0？topic = performance-削減 - 機能 - function-call-over-over-over-overed

[9] https://en.pingcap.com/blog/linux-kernel-vs-memory-fragmentation-1/

[10] https://www.geeksforgeeks.org/computer-organization-and-architecture-pipelining-set-1-execution-and-througpput/

[11] https://www.geeksforgeeks.org/correlating-branch-prediction/

[12] http://ftp.cvut.cz/kernel/people/geoff/cell/ps3-linux-docs/cellprogrammingtutorial/basicsofsimdprogramming.html

[13] https://cvw.cac.cornell.edu/codeopt/memtimes

[14] https://www.geeksforgeeks.org/computer-organization-and-architecture-pipelining-2-dependencies-and-data-hazard/

[15] https://www.interdb.jp/pg/pgsql01.html

[16] https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-engineerings-advanced-design-playbook-and-interleaved-sort-keys/

[17] https://clickhouse.com/docs/en/guides/improving-query-performance/skipping-indexes/

[18] https://docs.aws.amazon.com/redshift/latest/dg/t_sorting_data.html

[19] https://docs.aws.amazon.com/redshift/latest/dg/t_sorting_data.html

[20] https://docs.snowflake.com/en/user-guide/tables-clustering-keys.html

[21] https://clickhouse.com/docs/en/engines/table-engines/mergetree-family/mergetree/

[22] https://docs.databricks.com/delta/optimizations/file-mgmt.html

[23] https://aws.amazon.com/cn/blogs/big-data/amazon-redshift-engineerings-advanced-design-playbook-and-interleaved-sort-keys/

[24] https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions.html

[25] https://docs.singlestore.com/managed-service/en/create-a-database/physical-database-schema-design/concepts-of-physical-database-schema-design/columstore.html

[26] https://www.postgresql.org/docs/10/rules-materializedviews.html

[27] https://gpdb.docs.pivotal.io/6-2/ref_guide/sql_commands/create_materialized_view.html

[28] https://oracle-base.com/articles/misc/materialized-views

[29] https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-overview.html

[30] https://docs.snowflake.com/en/user-guide/views-materialized.html

[31] https://www.postgresql.org/docs/current/routine-vacuuming.html

[32] https://www.postgresql.org/docs/current/routine-vacuuming.html

[33] https://docs.vmware.com/en/vmware-tanzu-greenplum/6/greenplum-database/guid-best_practices-analyze.html

[34] https://www.aliyun.com/product/oss

[35] https://www.postgresql.org/docs/current/postgres-fdw.html

[36] https://docs.aws.amazon.com/redshift/latest/dg/c-getting-started-using-spectrum.html

[37] https://docs.snowflake.com/en/user-guide/tables-external-intro.html

[38] https://www.postgresql.org/docs/current/continuous-archiving.html

[39] https://docs.vmware.com/en/vmware-tanzu-greenplum-backup-and-restore/1.25/tanzu-greenplum-backup-and-restore/guid-admin_guide-managing-backup-gpbackup.html？

[40] https://www.aliyun.com/product/dbs

[41] https://15721.courses.cs.cmu.edu/spring2017/papers/15-optimizer2/p337-soliman.pdf

[42] https://gpdb.docs.pivotal.io/6-11/admin_guide/workload_mgmt.html

[43] https://gpdb.docs.pivotal.io/6-11/admin_guide/workload_mgmt_resgroups.html

[44] https://github.com/greenplum-db/diskquota

[45] http://event.cwi.nl/lsde/papers/p215-dageville-snowflake.pdf

[46] https://www.vertica.com/wp-content/uploads/2018/05/vertica_eon_sigmod_paper.pdf

[47] https://help.aliyun.com/document_detail/383266.html

[48] https://mp.weixin.qq.com/s/h15uk4 - js5apfwuy96gka