アーキテクチャ上の特徴から機能上の欠陥まで、分析分散データベースを新たな視点で見てみましょう

大規模なインターネット アプリケーションの普及に伴い、分散データベースは過去 2 年間で注目の話題になりました。同様に、銀行がメインフレームやミニコンピュータを制限するために X86 を推進しているため、従来のスタンドアロン データベースは徐々にボトルネックが発生しており、分散データベースを導入するかどうかという問題にすぐに直面することになります。

最近、私は個人の公開アカウントで「銀行が分散データベースを導入する必要性」についていくつかの予測をし、何人かの友人からフィードバックをもらいました。分散データベースに関する具体的な技術的な議論に加えて、「Teradata や Greenplum などの MPP についても話していただけますか? これらも分散データベースですが、上司は常に OLTP シナリオのものだけが重要だと考えています。」という非常に興味深い提案もありました。

実際、OLAP シナリオのニーズを満たすために、分散アーキテクチャ製品とソリューションがかなり早い段階で登場しており、それらは現在の OLTP ソリューションと多くの共通点を持っています。そして、将来的には、OLAP と OLTP という 2 つの分野の技術の開発が必然的に絡み合いながら前進し、お互いから学ぶことができると信じています。

これを踏まえて、この記事では OLAP シナリオに分散データも含め、「分散データベース」を 2 つの次元から分析します。最初の部分では、さまざまな「分散データベース」を水平に説明し、それらを 5 つのカテゴリに分類し、OLAP シナリオの 3 つのカテゴリの概要分析を行います。第 2 部では、NoSQL と NewSQL の違いを組み合わせて、OLTP シナリオにおける「分散データベース」実装ソリューションの主要な技術的ポイントを垂直的に説明します。これは前回の記事の延長であり、分散データベースに関する特別記事の概要です。要点については別の記事でも解説します。

まず、さまざまな「分散データベース」について水平的に説明します。

1. すべてのRDBMSは同じです

1990年代以降、リレーショナルデータベース管理システム（RDBMS）が主流となり、代表的な製品としてはSybase、Oracle、DB2などが挙げられます。同時期は、国内IT産業の黎明期でもありました。 RDBMS の基本的な特性は学術的に定義されているため、ここでは繰り返しません。

しかし、実用化の観点から見ると、最も懸念される点が 2 つあると思います。

• データは内部的にはリレーショナル モデルに保存され、外部的には ANSI SQL インターフェイスをサポートします。
• トランザクション管理の ACID 機能、特に強力な一貫性 (トランザクション内のすべての変更が中間状態なしで失敗するか成功するかのいずれかであることを意味します) をサポートします。

その後登場したさまざまな「分散データベース」は、主にこれら 2 つのポイントを他の領域の機能と引き換えにトレードオフしました。

「データベース」には古典的な定義がありますが、多くのビッグデータ製品は、おそらく従来のデータベースの一部機能の代替としての役割を促進するために、「データベース」という名前を借用しています。その結果、この概念は実践において継続的に拡大され、その境界はますます曖昧になってきました。この記事の目的の 1 つは、これらの製品と従来のデータベースとの違いと継承を明らかにすることです。そのため、「データベース」を弱めて「データ ストレージ」に拡張することもできます。

では、「分散データストレージ」システムとは何でしょうか?

「分散型」は建築スタイルです。これを利用して「データストレージ」を実現する最も現実的な目的は、データベース製品のパフォーマンス上限を開放し、システムの高い信頼性を確保することです。さらに詳しく説明すると、「分散データベース」には 2 つの条件が必要です。

• 水平拡張をサポートし、高いパフォーマンスを確保

マシン ノードの数を増やすことで、システム全体の処理能力が向上し、専用機器への依存がなくなり、専用機器ソリューションのパフォーマンスの上限を突破できます。ここでのマシン ノードは通常、X86 サーバーをサポートします。

• 安価な機器＋ソフトウェアで高い信頼性を確保

単一マシンの信頼性が低いという前提の下で、システム全体の高い信頼性はソフトウェアによって保証され、さらに「データストレージの高信頼性」と「サービスの高信頼性」に分けられます。つまり、単一障害点によってサービス レベルが短期的に局所的に低下する可能性がありますが、システム全体の正常な動作には影響しません。

これら 2 つの点を「分散データベース」の必要条件として考えると、少なくとも 5 つの異なる「分散データベース」が存在すると大まかにまとめることができます。

• ノーSQL
• 新しいSQL
• マルチレベル
• Hadoop テクノロジー エコシステム
• ライクメサ

注: 学生の中には、Kafka、Zookeeper などを挙げる人もいるかもしれません。これらも分散データ ストレージですが、それぞれに異なる特性と適用可能なシナリオがあるため、議論の「データベース」の概念に含める必要はありません。

これら 5 つのカテゴリのうち、最初の 2 つは主に OLTP シナリオをサポートし、最後の 3 つは主に OLAP シナリオをサポートします。 OLAP シナリオの 3 つのカテゴリをタイムラインに従って分析します。

2. OLAPシナリオにおける分散データベース

1990年代から2000年代にかけて、アプリケーションシステムの広範な構築と徹底的な利用に伴い、データの規模はますます大きくなり、この段階で国内銀行業界の「国家集中化」は基本的に完了しました。この時期にはRDBMSが広く使用され、OracleがSybaseを破ってデータベース分野の王者となりました。

基本的なトランザクション シナリオが満たされると、データが蓄積され、さらなる分析ニーズが自然に生まれます。単一のデータベース内でオンライン トランザクションと分析要件の両方をサポートするには多くの問題があり、オンライン トランザクションに支障をきたすことが多いため、新しいソリューションが必要です。これは MPP の台頭の機会となります。

1. マルチプロポーション

MPP（超並列処理）とは、複数のプロセッサ（または独立したコンピュータ）による一連の協調計算の並列処理を指します[1]。

各ノードの独立した計算能力を確保するために、MPP データベースでは通常、ShareNothing アーキテクチャが採用されています。最も代表的な製品は Teradata (略して TD) です。その後、Greenplum (略して GPDB)、Vertica、Netezza などの競合製品も登場しました。

アーキテクチャの特徴:

MPP は、「分散」の基本要件を満たす、マルチマシンの水平スケーラブルなアーキテクチャです。 TD は外部の集中ストレージを使用しますが、GPDB はローカル ディスクを直接使用します。この観点から見ると、GPDB はより徹底した Share Nothing アーキテクチャです。

TD のビジネス戦略ではオープンではないオールインワン ソリューションを採用しており、GPDB はオープン ソース度が高いことを考慮して、次の記事では、後者のアーキテクチャ特性を分析して MPP の動作メカニズムを分析します。

GPDBはマスタースレーブアーキテクチャを採用している[2]。スレーブ ノードはセグメントと呼ばれ、メインのデータ処理ノードです。 PostgreSQL をベースにしたパッケージと修正です。トランザクション処理機能を持ち、水平方向に拡張可能です。クラスター内にアクティブなマスター ノードは 1 つだけです。メタデータの保存やスケジュール機能に加え、一定のワークロードも担います。つまり、クラスター データへのすべての外部オンライン アクセスは、マスター ノードを経由する必要があります。

高信頼性設計の観点から、マスターノードに障害が発生したときにタスクを引き継ぐスタンバイマスターノードが最初に設定されます。次に、セグメント ノードはプライマリとミラーという 2 つの異なる役割に分割されます。後者は前者のバックアップノードです。データが送信されると、2 つのノード間で強力な同期が実行され、プライマリ ノードに障害が発生した場合に、ミラーがプライマリ ノードのタスクを引き継ぐようにスケジュールできるようになります。

データ分析には、次のような IT 機能が必要です。

• 複雑なクエリ機能。
• バッチデータ処理。
• 特定の同時アクセス機能。

MPP は上記の機能をより適切にサポートしており、ビッグデータ以前の時代に広く使用されてきました。ただし、この期間のデータの総量はまだ比較的限られており、一般的には TB レベルであり、対応するクラスターの規模は通常、単一クラスターで 100 ノード未満でした。

データの価値への注目が高まるにつれて、企業分析の範囲に含まれるデータがますます増えています。同時に、実際のアプリケーションにおけるデータの保存と転送のコストを考慮すると、データは 1 つまたは少数のクラスターに集中する傾向があり、クラスター サイズの急速な増加が促進されています。

大規模なクラスター (数百から数千) で使用する場合、MPP はバッチ処理とオンライン アクセスの両方でいくつかの欠点があります。以下の内容は主にPivotal（GPDBの元の製造元）の公式ブログ投稿に基づいています[3]。

注：クラスメイトによる翻訳も質が高く、一読をお勧めします[4]。

欠陥：

• バッチ処理

MPP アーキテクチャでは、ワークロード ノード (GPDB の場合はセグメント ノード) は完全に対称であり、データはこれらのノードに均等に保存されます。処理中、各ノード (つまり、ノード上の Executor) は、ローカル CPU、メモリ、ディスク、およびその他のリソースを使用して、ローカル データ処理を完了します。このアーキテクチャは優れたスケーラビリティを提供しますが、大きな問題である Straggler が隠れています。つまり、ノードに問題があり、その速度が他のノードよりも遅い場合、そのノードは Straggler になります。

この時点では、クラスターの規模に関係なく、バッチの全体的な実行速度は Straggler によって決まります。他のノードのタスクが完了すると、それらのノードは Straggler を待機するアイドル状態になり、その作業を共有できなくなります。ノード処理速度が低下する主な原因は、ディスクなどのハードウェアの損傷です。ディスク自体の一定の故障率（Google の統計によると、故障率は最初の 3 か月で 2%、2 年目には 8% に達する）を考慮すると、クラスターの規模が一定レベルに達すると、故障が頻繁に発生し、ストラグラーが一般的な問題になります。

• 同時

MPP の「完全な対称性」により、つまりクエリの実行が開始されると、各ノードはまったく同じタスクを並列で実行します。つまり、MPP でサポートされる同時実行の数は、クラスター内のノードの数とは関係ありません。記事のテスト データによると、4 ノードのクラスターと 400 ノードのクラスターでサポートされる同時クエリの数は同じです。同時クエリの数が増えると、両方のクラスターのパフォーマンスがほぼ同時に急激に低下します。

従来の MPP オンライン クエリは、主にエンタープライズ管理レベルの少数のユーザーを対象としており、同時実行機能に対する要件は低くなっています。ビッグデータの時代では、データ利用者は戦略管理レベルから戦術実行レベル、さらには最前線の担当者へと移行し、また、孤立した分析シナリオからビジネストランザクションシナリオとの統合へと移行しています。オンライン クエリの同時実行機能は MPP 時代をはるかに上回り、OLAP シナリオにおいて分散データベースが考慮しなければならない重要な問題になっています。

上記の 2 つの点に加えて、GPDB アーキテクチャのマスター ノードは一定のワークロードを負担します。すべてのオンライン クエリ データ フローはこのノードを通過する必要があるため、マスターにも一定のパフォーマンス ボトルネックがあります。同時に、実際には、GPDB はデータベース接続の数の管理にも非常に慎重です。私が参加したプロジェクトでは、Pivo​​tal の専門家が、クラスターのサイズが大きくなっても増加しない推奨最大値を示しました。

要約すると、MPP (少なくとも GPDB) にはクラスター サイズに関して一定の制限があると大まかに結論付けることができます。

2000 年から 2010 年にかけて、ほとんどの株式会社銀行と少数の都市商業銀行が、主に MPP 製品を使用してデータ ウェアハウスまたは ODS システムを構築しました。過去 10 年間は MPP 製品にとって最も輝かしい時代であったと言えます。これまでのところ、MPP は依然として、銀行業界がデータ ウェアハウスやデータ マート システムを構築するための主なテクノロジの選択肢となっています。 MPP 同時アクセスの欠陥とバッチ タスクによるオンライン クエリへの影響を回避するために、通常、データはアプリケーションの粒度に応じて異なる単一の OLTP データベースに分割され、オンライン クエリをサポートします。

2. Hadoop エコシステム

長い間、MPP はオールインワン ソリューション (TD に代表される) と同等でしたが、非常に高価で、一般の企業には手が届きませんでした。主に銀行や通信などの業界の大手企業で使用されていました。 2010 年代、ビッグデータ時代の到来とともに、Hadoop エコシステムが繁栄し、オープンソースの利点により急速に普及しました。

Hadoop技術システムによりデータ分析システムの構築コストが大幅に削減され、データ分析・マイニング作業は「データ民主化」の時代を迎えました。 Hadoop エコシステムでは、分析ニーズに必要な機能はバッチ処理とオンライン アクセスに分割され、さまざまなコンポーネントの組み合わせによって実装されます。バッチ処理では、MapReduce、Tez、Spark などの実行エンジンが使用されます。使いやすいセマンティック サポートを実現するために、Hive や SparkSQL などのコンポーネントが追加され、SQL アクセス インターフェイスが提供されます。

オンライン アクセスに関しては、初期の Hive から Impala、Hawk、Kylin、Presto などのソリューションへの移行により、アクセスの遅延が徐々に短縮されました。

アーキテクチャの特徴:

HDFS、Spark、Hive、および Hadoop エコシステムのその他のコンポーネントを紹介する記事はすでに多数あるため、この記事では詳細には触れません。一般に、そのアーキテクチャの焦点は、高スループットのデータ処理機能にあります。 MPP と比較すると、トランザクションの点ではより単純であり、粗粒度のトランザクション管理のみを提供します。

欠陥：

Hadoop にも明らかな欠陥があり、主に次の 3 点です。

• バッチ処理の効率が低い

MPP 支持者は、Hadoop コンピューティング エンジンの実行効率が低いことをしばしば批判します。実際、同じサイズのクラスター上で同じデータ処理ロジックを実行する場合、MPPはSpark [3]と比較しても大幅に時間がかかりません。主な理由は、ディスク上とメモリ内でデータを整理する方法が異なるためです。

MPP は RDBMS から来ており (たとえば、Vertica と GPDB はどちらも PostgreSQL に基づいて開発されています)、データの編成方法は従来の方法に近く、ゾーン、セグメント、ブロックなどの単位で編成され、データを前処理して使用時の効率を向上させます。 Hadoop エコシステムは HDFS ファイル ストレージに基づいています。 HDFS は、従来のデータベースのように連続したディスク領域を独立して管理するのではなく、データ テーブルをさまざまなデータ ファイルに直接マッピングし、テーブル パーティションもディレクトリやファイルなどの形式で反映されます。

HDFS の最も単純な txt 形式は単なるフラットなデータ ファイルであり、処理プロセスは必然的に単純で大まかになります。ただし、Avro、ORCFile、Parquet などの多くの新しいストレージ形式の導入により、HDFS ベースのバッチ処理はより洗練されるようになりました。全体的なアーキテクチャの観点から見ると、Hadoop は大量のデータのバッチ処理のスループット能力に重点を置いています。

同時に、Hadoop には MPP にはないバッチ タスク調整機能があります。データ ストレージの複数のコピーにより、「ローカライズされた」データ処理用の代替ノードを増やすことができます。さらに、データ処理はデータの保存に限定されません。ノードの動作効率に応じてタスクの配分を動的に調整できるため、大規模な展開でも全体的に安定した効率が得られます。対照的に、MPP は比較的小さなデータ量でより優れた実行効率を実現します。

• EDWの実装方法をシームレスに統合できない

長期的な実践では、エンタープライズ市場の主流のインテグレーターは、MPP の機能に一致する EDW プロジェクト用の固定実装方法を開発しましたが、Hadoop をそれらとシームレスに統合することはできません。典型的な例は、履歴データの保存です。従来の方法は、「ジッパー テーブル」形式を使用することです。つまり、現在有効なデータについては、その有効性の開始時刻が記録されます。データが変更または削除されると、有効期限が行の別の列に記録されます。このようにして、現在のデータが履歴データに変更されます。この増分表現方法により、ストレージスペースとディスク IO が大幅に節約されます。

ジッパーテーブルの設計コンセプトは、実際にはタイムスタンプベースの MVCC メカニズムと同じであることがわかります。

Hadoop のストレージ基盤である HDFS 自体は更新操作を提供しないため、データ操作レベルでのすべての更新は最終的にファイル レベルでの削除および挿入操作に変換され、効率が大幅に低下します。私の知る限り、多くの企業の実務では、この増分ストレージがフルストレージに変換され、多くのデータの冗長性がもたらされ、実装方法の変更も発生します。

• オンラインクエリの同時実行が不十分

オンライン クエリのシナリオの場合、最も一般的なソリューションは SQL on Hadoop です。これは、Impala や HAWQ などの MPP エンジンを HDFS 上に構築し、バッチ データとオンライン クエリが同じデータを共有します。 MPP エンジンは MPP データベースの設計経験を活用し、Hive などのコンポーネントよりも低いレイテンシを実現します。しかし、MPP と同じ問題、つまり同時実行能力が不十分という問題があります。

いくつかのプロジェクト テストを通じて、ほぼ同じデータ量とクエリ ロジックでは、Impala の同時実行性は GPDB よりも低いことがわかりました。これには多くの理由があり、調整の余地がありますが、システム アーキテクチャ レベルで議論する価値のある内容もあります。例えば、メタデータの読み取りでは、ImpalaはHive MetaStoreを再利用しますが、後者によって提供されるアクセスサービスは比較的長い待ち時間があり、これもImpalaの同時実行能力を制限します[7]。

3. ライク・メサ

Mesa は、Google が開発したほぼリアルタイムの分析データ ウェアハウスです。 2014年にその設計思想を公開した論文が出版された[5]。 Delta ファイルを事前に集計およびマージすることで、クエリ計算の量を削減し、同時実行機能を向上させます。

Mesa は既存の Google テクノロジー コンポーネントを最大限に活用し、BigTable を使用してすべての永続メタデータを保存し、Colossus (Google の分散ファイル システム) を使用してデータ ファイルを保存し、MapReduce を使用して継続的なデータを処理します。

Mesa関連のオープンソース製品には、Clickhouse[6]（2016年にYandexがオープンソース化）やPalo[7]（2017年にBaiduがオープンソース化）などがあります。

特徴：

現在、ClickHouse の情報は主にロシアのコミュニティに基づいています。皆様の理解とさらなる研究を促進するために、以下では主に Palo を例として使用します。

パロはメサの建築デザインのアイデアを完全にコピーしたわけではありません。 Hadoop のバッチ処理機能を活用しましたが、処理結果を Palo 独自のストレージにインポートし、オンライン クエリ シナリオに重点を置きました。オンラインクエリの部分では、主にImpalaの技術を借用しました。同時に、Palo は既存の分散ファイルシステムや BigTable のようなシステムを再利用せず、独立した分散ストレージエンジンを設計しました。データ ストレージではある程度の冗長性が犠牲になりますが、オンライン クエリの低レイテンシと高同時実行性の点で大きな改善が実現されています。

Palo のトランザクション管理は Hadoop システムのトランザクション管理と似ています。データ更新のアトミック粒度はデータ ロード バッチと同じくらい小さいため、複数テーブルのデータ更新の一貫性を確保できます。

全体的なアーキテクチャは、フロントエンドとバックエンドの 2 つの部分で構成されます。クエリのコンパイル、クエリ実行コーディネーター、およびストレージ エンジン カタログ管理がフロントエンドに統合されています。クエリ エグゼキュータとデータ ストレージはバックエンドに統合されています。フロントエンドの負荷は軽く、通常の構成では少数のノードで要件を満たすことができます。一方、バックエンドはワークロードノードとして、数十から数百のノードに大幅に拡張されます。データ処理部分は、Mesa と同様に、マテリアライズド ロールアップ メソッドを使用して事前計算を実現します。

Palo と ClickHouse はどちらも MPP データ ウェアハウスを実装したと主張していますが、そのアーキテクチャは従来の MPP から大幅に変更されており、バッチ処理をほぼ完全に放棄してオンライン部分に重点が置かれています。

ClickHouse と Palo は比較的新しいオープンソース プロジェクトであり、現在も開発が進められています。想定される使用シナリオは、主に広告ビジネスの時系列データ分析です。一定の制限はあるものの、引き続き注目する価値はあります。

上記は、OLAP シナリオにおける「分散データベース」の横方向の概要分析です。これは、2 つの分解次元の最初の部分です。さまざまな「分散データベース」に関する水平的な議論は終了しました。興味深いトピックはまだたくさんありますが、それについては今後の記事で引き続き議論していきます。

2 番目の部分である「分散データベース」に関する垂直的な議論では、NoSQL と NewSQL の違いを組み合わせて、OLTP シナリオにおける「分散データベース」実装ソリューションの主要な技術的ポイントについて説明します。興味のある学生は、DBAplus コミュニティでの今後の記事の公開に引き続き注目してください。

参考文献:

[1] http://en.wikipedia.org/wiki/Massively_Parallel

[2] http://greenplum.org/gpdb-sandbox-tutorials/introduction-greenplum-database-architecture/#ffs-tabbed-11

[3] Apache HAWQ: 超並列処理の次のステップ、

https://content.pivotal.io/blog/apache-hawq-next-step-in-massively-Parallel-processing

[4] MPPコンピューティングフレームワークとバッチコンピューティングフレームワークを比較すると、

http://blog.csdn.net/rlnLo2pNEfx9c/article/details/78955006

[5] A. Gupta他「Mesa: 地理的に複製された、ほぼリアルタイムのスケーラブルなデータウェアハウス」、PVLDB、vol. 7、いいえ。 12、pp.1259-1270、2014年。

[6] http://clickhouse.yandex

[7] http://github.com/baidu/palo