0. 序文
OLAP システムは、BI、レポート、アドホック、ETL データ ウェアハウス分析などのシナリオで広く使用されています.この記事では、主に OLAP システムのコア技術ポイントを体系的な観点から分析し、業界の既存の OLAP から共通点を抽出します.ストレージ、計算の話、オプティマイザーの話、トレンドの話の4章。
1.保管
1.1 列ストレージのデータ編成形式
- 行ストレージ: 常にリレーショナル データベースを伴ってきた NSM (N-ary Storage Model) 組織形態と見なすことができます. innodb[1] の B+ ツリー クラスター インデックスなどの OLTP シナリオに適しています.ページにはいくつかの並べ替えが含まれており、一度にタプルのチェックと更新などを十分にサポートできます。
- 列ストレージ: 初期の DSM (Decomposition Storage Model) [2] を経験し、後に NSM と DSM を混合しようとする PAX (Partition Attributes Cross) を提案し、C-Store 論文 [3] の後、徐々に有名になりました。 OLAP の場合、分析タイプはトランザクション シナリオとは異なります。ストレージ IO がボトルネックになることが多く、列ストレージは必要な列のみを読み取ることができ、無駄なデータをスキップし、IO 増幅を回避できます。同種のデータ ストレージはよりコンパクトであり、コーディング圧縮は使いやすいです。 、これらの利点により IO を削減できるため、パフォーマンスが向上します。
1.2 エンコードと圧縮
数値や文字列などの基本的な型の場合、列ストレージは適切なエンコーディングを使用してデータ量を削減できます. C-Store 論文では、並べ替えの有無と NDV (Number of Distince Values) の識別について、これらの 4 つの順列を使用します。数値型、順序付けされていない小さい NDV をビットマップに変換し、ビット パッキング エンコーディングなど、いくつかの解決策が提案されています。他のシナリオのエンコーディングには、varint、デルタ、RLE (Run Length Encoding)、辞書エンコーディング (Dictionary Encoding) などがあります。これらの軽量エンコーディング手法は、より多くの CPU しか必要とせず、多くの IO を節約できます。
複雑な型とネストされた型の場合、Google Dremel の論文 [4] を使用して Striping/Assembly アルゴリズム (オープン ソースの Parquet) を提案し、Definition Level+Repetition Level を使用してエンコードとデコードを行うことができます。一部の数値型の変換に bitshuffle[14] を使用することもできますが、圧縮効果も高く、たとえば KUDU[7] や Baidu Palo (Doris) に適用されています。エンコーディングに基づいて、lz4、snappy、zstd、zlib などの従来の圧縮も実行できます。通常、圧縮率が理想的でない場合は、有効にする必要はありません。
HBase を含むいくつかの他のオプションは、実際には純粋なバイナリを格納し、実際には列形式ではない列ファミリーのみをサポートします. 一部のシリアル化フレームワークは、列形式のストレージではない Avro など、Hadoop とより適切に統合されています.
1.3 保存形式
現代の OLAP は、行と列のストレージを混在させる方式を採用することが多く、データ ブロック + ヘッダー/フッターのファイル構造を採用しています。
たとえば、Parquet、ORC、および Data Block は 3 つのレベルを使用します。
行グループ(Parquet を呼び、ORC を Stripe と呼びます) ->列チャンク->ページ
各レイヤーにはメタデータがあり、Row Group メタには暴行カウント (*) を解決するための行数が含まれ、Column Chunk メタには max、min、sum、count、distinct count、average length などが含まれ、列プルーニングを解決するための辞書エンコーディングが含まれます。オプティマイザへの基本情報ページ メタには最大値、最小値なども含めることができ、計算を高速化するためにページ スキップが使用されます。
1.4 ストレージインデックス
Parquet と ORC では、列のメタ情報を除いて、他のインデックスは提供されません. 他のストレージでは、より豊富なインデックスがサポートされています. インデックスは、個別のブロック (インデックス ブロック) にするか、独立したファイルを形成することができます.
たとえば、Alibaba Cloud ADB[5] では、カーディナリティが小さい場合、ビットマップ インデックスを使用でき、複数の条件をプッシュ ダウンして and/or を使用できます。逆インデックスもオプションであり、スペースとパフォーマンスの間で妥協が必要であり、全文検索もサポートできます。
ブルーム フィルターは、ページの粒度に応じて多くのグループを作成し、「in」、「=」クエリを高速化し、ページのプルーニングを迅速に実行できます。
さらに、データが特定の列または複数の列に従って順序付けられていると仮定すると、データのランダム性を減らすことができます. 利点は、同様のデータが圧縮のエンコードに有利であり、行グループのメタに基づいて効果的である可能性があることです. 、Column Chunk、およびPageフィルタリングとプルーニングには、シーケンスにB-Tree、Masstree[6]（KUDU[7]など）を使用するか、LevelDBのアイデアから学んでIndexのシーケンスに疎なインデックスを作成できます二分探索に便利なブロック インデックスブロックはLRUが使える キャッシュはできるだけメモリ上に常駐させるべきであり、ソート列による順次走査のポイントクエリやレンジクエリに有利 さらに、他の列を疎順序索引として使用することもできます。シーケンスが一意であれば、OLTP における主キーの概念と見なすことができます。
1.5 分散ストレージ
DAC (Divide And Conquer) も分散分野で試行錯誤されています.1 台のマシンのストレージ サイズと IO の制限を突破するには、ファイルをいくつかの小さなシャードに分割 (シャーディング) し、特定のデータを使用する必要があります。ラウンドロビン、定数、ランダム、範囲、ハッシュなどの列は、分散ストレージを形成するために異なるファイルまたはマシンに分散されます。
1.5.1 デポジットと計算の統合
ストレージとコンピューティングを統合するアーキテクチャは、スタンドアロン ディスク (SATA、SSD、NVM) をベースにしています。たとえば、Greenpulm は PostgreSQL をベースにしており、ClickHouse、Baidu Palo (Doris) などもシェア ナッシング アーキテクチャです。複数のコピーを実現できるため、リシャードは拡張に時間がかかることがよくあります。
ストレージとコンピューティングの統合アーキテクチャにより、ファイルとシャーディング管理システムをより注意深く設計できます. KUDU や OLTP の新しい Tikv など、集中型マスター + 複数のタブレット アーキテクチャを採用しています. シャードの複数のコピーは、一貫性プロトコル Multi-Paxos に依存しています.またはサポートランダム Raft プロトコルが順番に送信され、複数のシャードが Raft グループを形成するため、テーブル (ファイル) をマルチシャードおよびマルチコピーアーキテクチャに分割でき、スケーラビリティと高可用性の両方が保証されます。Centralized Master は、フラグメントの場所とメタデータを管理します。これは、ロード バランシング、分割、マージに便利です。
1.5.2 ストレージと計算の分離
ストレージとコンピューティングを分離し、ファイルは分散ストレージ (GFS、HDFS) またはオブジェクトストレージ (S3、OSS、GCS) に存在する共有エバーシング (共有ストレージ) アーキテクチャであり、スケーラビリティと可用性の向上に利点があります。 They all do batch and append writing instead of random writing. この両刃の剣はまた、OLAP がリアルタイムで更新することをより困難にします。
ストレージとコンピューティングが分離されているアーキテクチャでは、たとえば、ファイルが HDFS に格納されている場合、各フラグメントは HDFS ブロック (たとえば、サイズが 128MB) であり、高スループットの大きなブロック IO シーケンシャル読み取りに便利です。行グループのサイズはブロック サイズと同じです。これは、Spark SQL ジョブの並列計算などの上位層のコンピューティング エンジンに便利です。
1.6 さらに分割されたデータ
データ シャーディングに基づいて、よりきめ細かいパーティショニングを実行できます。これは、パーティションのプルーニングに便利で、スキャンする必要のないファイルを直接スキップします。
シャーディング戦略は、範囲に応じて OLAP 範囲クエリと迅速なチェックを最適化し、ハッシュ パーティションに従って、完全に分散し、ホットスポット ホットスポットを効果的に解決できます。この 2 つを組み合わせて、Alibaba Cloud ADB、ClickHouse、KUDU などの 2 レベルのパーティションを作成します。これは、DISTRIBUTED BY HASH をサポートし、次に PARTITION BY RANGE をサポートしますが、Baidu Palo (Doris) は通常、最初のレベルで時間によって最初にパーティション化します。より良い ホット データとコールド データが区別され、セカンダリ パーティションでのバケット化にはハッシュが使用されます。
1.7 リアルタイム書き込みと ACID
リアルタイム データ ウェアハウス、HTAP、HSAP[8] などの概念の台頭により、長いリンク、データの冗長性、データの一貫性の低さなど、従来のデータ処理に対する Lambda アーキテクチャの欠点が浮き彫りになりました。OLTP の機能を統合すると、最初のポイントは、前述のイミュータブル テーブル ファイルに対して、リアルタイムで追加、削除、および変更を行うことです.低レイテンシと高スループットを確保するために、LSM-Tree のアイデアから学習して最適化することができますスループットを書き込み、低レイテンシ ストリームをランダムに書き込みます。最終的にバッチ ミニバッチのグループ コミット シーケンスになり、永続性を確保するために先行書き込みログに依存し、最終的に Base + Delta のファイル構造を形成します。読み取りプロセスには次のものが含まれます。チェックまたはスキャン. ベースに基づいて、デルタをマージすることも必要です. さらに、バックグラウンドは、マイナー圧縮とメジャー圧縮を通じてデルタとベースを継続的にマージし、読み取りパフォーマンスを継続的に最適化できます. 同様のソリューションは、Alibaba Cloud ADB、KUDU、およびGoogle MESA[9]。
読み取りと書き込みの一貫性のレベルでは、ACID とトランザクション分離機能を提供する必要があります, これにより、単一行とミニバッチの原子性がより確実に保証されます. 耐久性は自明です. 一貫性とトランザクション分離のために、MVCC メカニズムを使用できます各書き込みバージョンでは、バージョン チェックの一貫性とスナップショットの分離を実装するのは非常に簡単です。
2.計算
2.1 クエリ手順
SQL 言語は OLAP の標準構成であり、完全な SQL クエリの手順は次のとおりです。
- SQL字句解析、構文解析
- 抽象構文木 (AST) を形成する
- 校正チェック
- AST を関係代数式 (関係代数) に変換
- 関係代数式に基づいて実行計画を生成し、まず論理計画（logical plan）を生成します
- 最適な実行計画はオプティマイザによって生成されます
- 実行計画に基づいて物理的な実行計画（物理計画）を生成します
- 最後に、executor によって実行され、結果を返します。
SQLからASTまではクラスライブラリやツールが豊富で、C++ならLex/Yacc、JavaならJavaCC/ANTLRが使え、手で実装することもできます。AST から関係代数式まで、ビジター モードを使用してトラバースできます。
2.2 OLAP データ モデリングの分類
2.2.1 ロールラップ
リレーショナル OLAP (ROLAP) は、SQL、柔軟なクエリを適切にサポートし、組み合わせモデル、スノーフレーク、またはスター モデルを使用して複数のテーブルを整理します。ROLAP計算のデータ規模は、オフラインのビッグデータ計算(Hive/Spark)よりも小さいことが多く、従来のGreenpulm、Vertica、Teradata、Presto、Impala、Spark SQL、Sql-on-HadoopシステムのHAWQなど、多くのROLAP製品があります。 、クラウド コンピューティング メーカー、Alibaba Cloud ADB、Google BigQuery、AWS RedShift、MonetDB[10]、学界が生み出したもの、そして新興の ClickHouse などがあります。
クエリフェーズが分割されている場合
cache / \ | pre-computing -> computing -> post computing
上記のストレージ技術は、計算段階での ROLAP の最適化のためのものですが、計算のエントロピーを前計算段階に転送して事前計算を行うと、計算段階も大幅に最適化できます。
2.2.2 モラップ
多次元 OLAP (MOLPA) はデータを事前に計算できます. 一部のシナリオでは、きめの細かいファクトは必ずしも必要ではありません. ディメンション列とインデックス列は厳密に区別できます. Kylin、Druid などを使用してデータ キューブ (データ キューブ) を作成しますこれにより、OLAP シナリオでの集計クエリの IO を大幅に削減できます. さらに、マテリアライズド ビューとしてのロールアップ操作に基づく Baidu Palo と Google MESA も IO 消費を削減するため、一般に高い同時実行性をサポートします。その理由は、クエリが十分に柔軟ではなく、データが冗長であることです。
2.3 コンピューティング エンジンの分類
物理的な実行計画は DAG であることが多く、各ノードはオペレーターであり、最も下流のリーフ ノードは一般的に TableScan オペレーターです. この DAG の分散実行者はコンピューティング エンジン (クエリ エンジン) であり、2 つのジャンルに分けられます
2.3.1 オフライン コンピューティング エンジン
最初のタイプは、Hive on MR、Spark SQL、Alibaba Cloud MaxCompute などのオフライン コンピューティング エンジンに基づいており、超大規模データをサポートし、フォールト トレランスを保証し、複数のステージでディスクにスピルし、リソース マネージャーのスケジューリングとキューイングを使用します。 . ジョブは非常に長く、リソースを大量に消費し、同時実行性が低い場合があります。
2.3.2 MPP
2 番目のタイプは、Greenpulm、Presto、Impala、Alibaba Cloud ADB などの MPP です。RedShift は大規模なデータをサポートし、リソース マネージャーがリソースを割り当てたり、時間のかかるタスクをスケジュールしたりする必要はありません。クエリは一般にフォールト トレラントであり、演算子は並列で実行され、ストラグラー ノードが TP99 に影響を与えないように並列度は制限されています.オフライン ベースのコンピューティング エンジンと比較して、多くの場合短いタスクであり、クエリ時間はかかりません。長すぎる。
Presto と Impala は Sql-on-Hadoop MPP に属します. Hive メタストアを使用して、Parquet や ORC などのファイル形式を直接読み取ります. Greenpulm と RedShift は PostgreSQL に基づいています. Pangu の分散ストレージ.
2.4 計算実行
DAG がデータ フローを実行するとき、パイプライン方式を採用します。つまり、上流ステージは、下流ステージの実行が完了するのを待たずに、データをプルして計算を実行できます。データはディスクにドロップされず、オペレーターは送信のためにメモリを介してソケット バッファに直接コピーされます. メモリが十分に大きいことを確認する必要があります. そうしないと、OOM が発生しやすくなります.
The Volcano-style model is a implementation of the Row-Based Streaming Iterator Model operator. ボトムアップからのデータの "プル" を実現し、計算を駆動するために必要なのは、open、next、および close の 3 つの関数だけです。
ベクトル化された実行 (ベクトル化されたクエリ)。MonetDB の論文では、火山モデルの改善計画が提案されています。ベクトル化された実行、一度に火山モデルをタプルで実現すること、各オペレーターが実行され、上流のオペレーターに渡されて実行が継続されること、関数呼び出しが多すぎること、多数の仮想関数呼び出し、条件付き分岐予測の失敗、直接的な現象は CPU 使用率の低下 (低 IPC) です。最新の CPU には、命令レベルの並列処理を実現するマルチステージ パイプライン、アウト オブ オーダー実行を実現するスーパー スカラー、forloop を効果的に最適化する機能、ハイパー スレッディングによってスレッド レベルの並列処理を実現する機能、CPU マルチレベル キャッシュ、およびキャッシュライン コンパイラの最適化と組み合わせてキャッシュミスを回避することを有効に使用すると、計算プロセスが大幅に高速化されます。ベクトル化された実行の考え方は、オペレーター間の入力と出力がデータのバッチ (バッチ、数千行など) であるため、頻繁なインタラクティブな切り替えではなく、計算をより関数内に留めることができ、パフォーマンスが向上します。 CPU パイプライン. 並列処理、また、AVX 命令セットなどの SIMD 命令を使用してデータ並列処理を実現することもできます。実際の実装では、たとえば、Impala の各演算子の入力は TableScan 演算子を除いて RowBatch ですが、その他は火山モデルの実行スタイルでの行単位の処理、TableScan の読み取りと格納、カラムナ メモリ レイアウトです。 Postpush は、SIMD 命令を使用して集計を高速化することもできます。ただし、ベクトル化は追加のオーバーヘッド、つまり中間結果の実体化 (マテリアライゼーション) ももたらします。これは、より高い計算パフォーマンスと引き換えに、マテリアライゼーションのオーバーヘッドを犠牲にします。
動的コード生成 (codegen)。解釈された演算子は、一般化のために設計されているため、大規模なデータ セットでは効率が悪いことがよくあります. codegen を使用して、演算子ロジックを動的に生成できます. たとえば、Java は ASM または Janino を使用し、C++ は LLVM IR を使用します. この方法で生成された演算子は、コンピューティングに近く、冗長性と仮想関数呼び出しを削減し、複数の演算子を 1 つの関数に結合できます。さらに、式計算のコード生成をより極端に行うことができ、いくつかの単純な計算をアセンブリ命令にしてさらに高速化することができます。
ベクトル化またはコード生成については、どちらが優れているかについて、論文 Everything You Always Wanted to Know About Compiled and Vectorized Queries But Were Afraid to Ask [11] で詳細な比較が行われました。両者を組み合わせることで、codegen を介してベクトル化された実行コードを生成することもできます.さらに、ステージ全体の codegen を行う必要はなく、解釈と実行を連携させることもできます。
計算時間の一部は、IO と CPU のアイドル状態で失われます。メモリのレイアウトと管理、行レイアウトまたは列レイアウト、それが CPU キャッシュ、メモリ プール、またはオンデマンド割り当てに適しているかどうかはすべて、システムのスループットに影響します. C++ は、それ自体で Arena を維持することも、jemalloc などのフレームワークを使用することもできます。一方、Java のヒープ メモリの非効率性は GC にも影響するため、Unsafe API を使用してオフ ヒープ メモリを操作します。また、Arrow の台頭により、クロスプロセス通信の後、データのデシリアライズ、メモリ割り当て、コピーを行わずにカラムナ データを読み取ることができるため、計算がさらに高速化されます。
2.5 共通演算子の実現
TableScan オペレーターは、コネクターを非常にうまく抽象化し、複数のデータ ソース (Hadoop、オブジェクト ストレージなど) に接続できる Presto などの基礎となるデータ ソースを直接読み取り、通常はプロジェクションとフィルターをサポートするため、フィルターのプッシュダウンとTableScan への射影プッシュダウン、さらに、述語を行うときに、レイジー マテリアライゼーション (遅延マテリアライゼーション) 手法を使用して短絡し、不要な列を削除することができます。
Join 演算子を実装するには、2 つのテーブルが非常に小さい場合、インメモリ ハッシュ結合と単純なネストされたループ結合を使用するのが最も簡単です。一方は大きく、もう一方は小さく、小さなテーブルをブロードキャスト (ブロードキャスト) できます。一般に、ディメンション テーブルは大きなテーブルにインデックスがある場合は、小さなテーブルをスキャンし、大きなテーブルに基づいてインデックス ルックアップ ジョインを実行します。そうでない場合は、小さなテーブルに基づいてテーブルを構築し、大きなテーブルのプローブ テーブルを使用してハッシュを実装します。結合; 2 つの大きなテーブル、2 つのテーブルの結合キーが最初のレベルにある場合 パーティション戦略が同じ場合は、大きなテーブルのシャッフルを回避するために適切に配置し、大きなテーブルのシャードで直接ローカル結合を行うことができます整列できない場合、2 つのテーブルは結合キーに従って他のノードにシャッフルされ、再分配後に結合されます; さらに、2 つのテーブルの結合キーが順序付けられている場合は、ソートマージ結合も使用できます.
2.6 リソース管理とスケジューリング
MPP アーキテクチャでは、コーディネーターはスケジューラーがタスクをワーカー ノードにディスパッチする必要があります. 長い計算タスクまたは ETL タスクの場合、多くのリソースを占有するため、OLAP の同時実行性が制限され、他の要求をキューに入れる必要があるため、外部のオンライン要求を処理することは困難です. 混合負荷に対応するために, 従来のスケジューラの単純で大まかなスケジューリングとリソース管理はもはや要件を満たすことができないため, タスクのきめ細かいスケジュールを使用してアイドル状態のリソースを回避できます. , そしてリクエスト間のリソースの使用は, 悪いクエリがリソースをいっぱいにするのを避けるために, できるだけ分離されるべきです. 単純な戦略はラベル クラスタリングを介して渡すことができます.タスクに迅速に対応できます。OLAP システムが十分なパフォーマンスを備えている場合、より優れたリソース管理とスケジューリングにより、OLAP は高度な同時実行性と低待機時間をサポートし、単なる社内分析システムではなくオンライン サービスを提供できるシステムに改善されます。
3.オプティマイザー
クエリ オプティマイザは、従来のデータベース DB2、Oracle、および MySQL のコアであるだけでなく、OLAP でも重要です。AST は SQL 形式式言語に変換されます—関係代数. コードの実装は関係演算子で構成されるツリーです. クエリの最適化は主に、対応する変換と最適化のための「等価交換」の原則に基づいています. 関係代数式. 関係代数の基本的な操作には、射影 (project)、選択 (select)、和 (union)、差分 (set difference)、接続 (join) などがあります。オプティマイザーには、ルールベースのオプティマイザー (RBO) とコストベースのオプティマイザー (CBO) の 2 種類があります。
3.1 RBO
元の式を切り出し、一連のルール (Rule) をたどり、条件が満たされる限り変換し、最終的な実行計画を生成します。いくつかの一般的なルールには、パーティションのプルーニング、列のプルーン、述語のプッシュダウン、プロジェクションのプッシュダウン、集計のプッシュダウン、制限のプッシュダウン、ソートのプッシュダウン、定数の折りたたみ、結合するサブクエリのインラインなどがあります。
3.2 CBO
元の式はそのままに、統計情報＋コストモデルをもとに同値関係式の探索・生成を試み、最終的にコストが最小となる実行計画に差し替えます。
CBO の実装には、Volcano モデルと Cascades モデルの 2 つのモデルがあります. 非常に人気のある Calcite [12] は Volcano モデルを使用しています. たとえば、Flink と Hive はこれに基づいています. Orca は Cascades モデルを使用しています.グリーンパルムで。
オプティマイザは可能な限り効率的である必要があります. 検索スペースの効率的な生成, 検索スペースの動的な計画とトラバーサル (トップダウン, ボトムアップ, 深さ優先など), および効率的なプルーニング戦略はすべて、最適化プロセスをスピードアップできます.
統計には、テーブルのデータ サイズ、行数が含まれます。列特性のメタデータ (最小、最大、カーディナリティなど)、並べ替え、利用可能なインデックス、ヒストグラム分布統計などをクエリします。
結合は、OLAP で最もスループットを消費する演算子の 1 つであり、分析用の ROLAP の最も強力な部分でもあります. 複数のテーブルに関連付けられたクエリを実行できます. 一般的な最適化方法には、左側の深いツリーまたは茂みのあるツリーを使用した結合の並べ替えが含まれます結合を実行する. 結合アルゴリズムの実装を選択する方法 (前のセクションで説明したさまざまな結合実装の選択), 効率的なインデックス構造によって実装されるインデックス結合と組み合わせる, グループによるプッシュダウン, トップ n プッシュダウンなど
4. トレンド
OLAP分野は、RDBMSで確立されたSQL+OLAPからETL+独自のOLAPへとデータウェアハウスの段階を経て進化を続けており、さらに多くのクラウドベンダーもこの分野に参入し、次のような傾向を見せています。
リアルタイム分析。従来の OLAP は、データをインポートするためにさまざまなパイプラインと ETL を実行する必要があります.このようなアーキテクチャでは、データの複数のコピーが保存されます.これは、冗長性と一貫性を保証するのが容易ではありません.また、あまりにも多くの技術スタックと複雑さを導入し、リアルタイム分析を満たすことができません. . ミニバッチ処理でさえ、せいぜい数分しかかかりません。業界の傾向は、OLAP に高スループットのリアルタイム書き込み機能とリアルタイム クエリ機能を与えることです.たとえば、上流のデータ ソースはストリーム コンピューティング システムを通過します.古いアーキテクチャはラムダに基づいています.履歴データはストレージに書き込まれます.リアルタイム データが一部の NoSQL にインポートされる. ユーザーが行う必要がある. さまざまなデータ ソースをマージする一般的な方法は、ストリーム コンピューティング システムで OLAP を直接記述することであり、データ アイランドを回避し、単純なリンクを保証します. HSAP (Hybrid Serving/Analytical Processing) [8] Alibaba Cloud Hologres チームが提案したのはまさにこのアイデアです。
HTAP . トランザクション処理と分析処理が 1 つのデータベースで提供されるのが最も理想的な状態ですが、2 つの技術システムは統合が困難な場合が多いため、現在多くのデータベース ベンダーがこの点で試みを行っており、データの一貫性を確保することは非常に重要です。 1 つの考え方は OLTP から OLAP へ、複数のコピーが格納される場合、一部のコピーは OLAP 用に特別にカスタマイズされ、専用の OLAP エンジンを使用してクエリを提供し、もう 1 つは ACID およびトランザクション機能を OLAP システムに付与することです。その OLAP は INSERT /DELETE/UPDATE 操作もサポートしています。
クラウドネイティブ。Exadata などの従来の OLAP は、ハイエンドのハードウェアに依存しています. 多くのオンプレミス ソリューションは、スケーラビリティとコストの問題にも直面しています. クラウドネイティブ アーキテクチャは、仮想化テクノロジを通じて、より優れたエラスティック コンピューティングを実現できます. ストレージとコンピューティングが分離されている場合、アーキテクチャはまた、柔軟なストレージを実装し、これらの水平拡張メカニズムは、高いパフォーマンス、コスト、およびスケーラビリティのバランスを取ることができます。
マルチモーダルデータ構造の分析。構造化データに限らず、ベクトル検索、JSON、ARRAY検索など、半構造化および非構造化データの分析もOLAPに徐々に適用されています。
ソフトウェアとハードウェアの統合。コンピューティングに関しては、クエリが NUMA 認識を満たすことができるようにマルチコア並列処理をより有効に活用し、求核性 (親和性) によりシステムのスループットをさらに絞り込み、FPGA、GPU ハードウェア アクセラレーションを使用し、超高帯域幅を使用することができます。これらのハードウェアによって提供される深いパイプラインにより、一部のベクトル計算と集計操作が高速化されます。ストレージに関しては、ストレージ クエリの帯域幅が増加し、レイテンシが減少するため、より多くの新しいストレージを適用できます。たとえば、Intel Optane NVM 3D-XPoint SSD[13] 2.6G/秒のシーケンシャル リード スループットを提供し、高同時実行クエリの遅延を 10 マイクロ秒以内に制御できます; ネットワークに関しては、RDMA ネットワークに基づいて、DPDK およびその他のテクノロジーが従来の tcp を置き換え、カーネル バイパスを実行し、ネットワーク遅延を削減できます。上位層の OLAP ソフトウェアは、これらの新しいハードウェアに基づいてカスタマイズして、より優れたパフォーマンスを提供できます。
参考文献
[1] [MySQL InnoDB 物理ファイル形式からのインデックスの深い理解] ( MySQL InnoDB 物理ファイル形式からのインデックスの深い理解)
[2] [分解ストレージ モデル]( http://www.inf.ufpr.br/eduardo/ensino/ci763/papers/DSM-columns.pdf )
[3] [C ストア: 列指向の DBMS]( http://www.vldb.org/archives/website/2005/program/paper/thu/p553-stonebraker.pdf )
[4] [Dremel: Web スケール データセットの対話型分析]( https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/36632.pdf )
[5] [AnalyticDB: Alibaba Cloud のリアルタイム OLAP データベース システム]( http://www.vldb.org/pvldb/vol12/p2059-zhan.pdf )
[6] [高速マルチコア キー値ストレージのキャッシュの巧妙さ]( https://pdos.csail.mit.edu/papers/masstree:eurosys12.pdf )
[7] [Kudu: 高速データの高速分析用ストレージ]( https://kudu.apache.org/kudu.pdf )
[8] [データ ウェアハウス、データ レイク、ストリーム バッチの統合、ついに誰かが明らかにした] ( Aliyun Hologres: データ ウェアハウス、データ レイク、ストリーム バッチ統合、ついにマスターが明らかにした! )
[9] [メサ: 地理的に複製された、ほぼリアルタイムのスケーラブルなデータ ウェアハウジング]( https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/42851.pdf )
[10] [MonetDB/X100: ハイパーパイプライン クエリ実行]( https://w6113.github.io/files/papers/monetdb-cidr05.pdf )
[11] [コンパイルおよびベクトル化されたクエリについて常に知りたいと思っていたが、尋ねるのを恐れていたすべて]( https://www.vldb.org/pvldb/vol11/p2209-kersten.pdf )
[12] [Apache Calcite: 異種データ ソースに対する最適化されたクエリ処理の基礎フレームワーク]( https://arxiv.org/pdf/1802.10233.pdf )
[13] [インテル Optane シリーズ](インテル® Optane™ DC SSD シリーズ)
[14] [bitshuffle]( https://github.com/kiyo-masui/bitshuffle )