オープンソースのクラウドネイティブデータウェアハウスエンジン ByConity ストレージとコンピューティングの分離アーキテクチャと利点

寄稿 | ByConity 技術チーム

制作 | CSDNクラウドコンピューティング

ByConity は、ByteDance のオープンソースのクラウドネイティブデータウェアハウスエンジンです。その重要な利点の 1 つは、ストレージとコンピューティングが分離されたアーキテクチャを採用しており、読み書きの分離と柔軟な拡張と縮小を実現していることです。このアーキテクチャにより、読み取り操作と書き込み操作が相互に干渉せず、コンピューティングリソースとストレージリソースが分離されます。これら 2 つはオンデマンドで個別にスケールアップおよびスケールダウンできるため、リソースの効率的な使用とデータの読み取りと書き込みの強力な一貫性が保証されます。さらに、ByConity は、異なるテナントが相互に影響を与えないようにマルチテナントのリソース分離をサポートしており、これはマルチテナント環境により適しており、同時に、ByConity は主流の OLAP エンジンの最適化を採用し、より優れた読み取りおよび書き込みパフォーマンスを提供します。

1. ByConityの技術的背景

ClickHouse は、オープンソースの列型データベース管理システムであり、Shared-Nothing アーキテクチャを採用しており、次のような典型的な特徴があります。

各ノードはデータの一部を独立して管理します
ノード間でデータを共有しない
ストレージとコンピューティングは密接に結合されています

そのクエリの実行は、大きく 2 つのフェーズに分かれています。最初の段階では、各ノードが管理するデータフラグメントを独立して処理し、I/O、クエリ、計算を担当します。第 2 段階では、コーディネーターノードはデフォルトで第 1 段階で各ノードによって計算された結果を要約し、クライアントに返します。このアーキテクチャは、高いパフォーマンスとスケーラビリティを実現でき、固定されたビジネス規模での同時実行性の高いクエリに特に適しています。同時に、ノード間でデータを共有しないため、スケーラビリティが比較的容易であり、線形拡張を実現できます。

図 1 クリックハウスのアーキテクチャ

しかし、実際に使用してみると次のような問題が見つかりました。

拡張および縮小のコストが高い: 急成長しているビジネスでは、頻繁な拡張操作が必要であり、データの再シャッフルとデータの再配置は実際の読み取りおよび書き込み操作に影響します。
マルチテナントは相互に影響を与える可能性があります: 異なるビジネスは異なるビジネス特性を持っている可能性があり、特定の時点で一部のビジネスがクラスター全体のリソースプールを占有し、他のテナントに影響を与える可能性があります。
読み取りおよび書き込み操作が影響を受けます。各ノードは読み取りおよび書き込みタスクの一部を担当する必要があります。ノードのリソース使用率が高い場合、クエリのパフォーマンスが影響を受ける可能性があります。
リソースの使用が無駄になります。特に複数の中小企業が同じクラスターを共有している場合、リソースの見積もりが不十分であったり、リソースの無駄につながるその他の状況が発生したりする可能性があります。

2. ByConity アーキテクチャの概要

上記の利用プロセスで見つかった問題に基づいて、オープンソースの ClickHouse アーキテクチャをアップグレードし、コンピューティングとストレージの分離アーキテクチャを導入し、各ノードでローカルに管理されていた元のコンピューティングとストレージのアーキテクチャを分散ストレージに変換しました。クラスタ全体の全データを一元管理することで、各計算ノードをステートレスな純粋計算ノードとし、分散ストレージのスケーラビリティと計算ノードのステートレス特性を利用して動的な拡張・縮小を実現します。さらに、このアーキテクチャは、マルチテナントの分離と読み取りタスクと書き込みタスクの分離もサポートしています。次の利点が実現されます。

高い弾力性と高い拡張性: コンピューティングとストレージの独立した拡張と縮小
マルチテナントの分離: 異なるテナントが異なるコンピューティンググループを使用します。
読み取りと書き込みの分離: 読み取りと書き込みは異なるコンピューティングリソースを使用します。

ストレージコンピューティングの分離アーキテクチャ

全体的なアーキテクチャに関して、ByConity のストレージとコンピューティングの分離アーキテクチャを図 3 に示します。これは主に、共有サービス層、コンピューティング層、クラウドストレージ層の 3 つの層に分かれています。

共有サービス層: 主なコンポーネントはクラウドサービスであり、すべてのクエリのエントリポイントであり、クエリを解析して最適化し、クエリプランを生成し、処理のためにコンピューティング層に送信します。これは、一部のサービス、コンポーネント、トランザクションの管理を担当するコーディネーターの役割にも相当し、メタデータ (メタデータストレージ) の管理も含まれます。
コンピューティング層: 主にコンピューティングリソースグループ - 仮想ウェアハウス (VW と呼ばれます)、読み取り VW と書き込み VW を含むコンピューティングリソースコンポーネントを動的に開始および停止できます。Read VW では、各ワーカーノードにはオプティマイザーとランタイムモジュール、および分散ストレージリモートシステムへのアクセスを減らすために一部のデータをキャッシュするディスクキャッシュモジュールがあり、ホットデータはディスクキャッシュモジュールに保存されます。Writer VW では、データは ClickHouse 形式でローカルディスクに書き込まれます。つまり、最初にローカルディスクに書き込まれ、その後、書き込みパフォーマンスを向上させるために分散ストレージにバッチで書き込まれます。
クラウドストレージレイヤー: 分散型の統合ストレージシステムです。すべての ByConity データはこのレイヤーに保存されます。コンピューティングレイヤーでクエリを実行すると、データはクラウドストレージレイヤーから読み取られます。クラウドストレージレイヤーの特定の実装では、HDFS、S3 などのさまざまなクラウドストレージサービスを使用できます。

さらに、ByConity には、TSO、デーモンマネージャー、リソースマネージャー、バックグラウンドタスク、サービス検出コンポーネントなどのいくつかの共有サービスコンポーネントも含まれています。

図 2 ByConityストレージコンピューティングの分離アーキテクチャ

3. ByConity アーキテクチャの利点

リソースの分離

ビッグデータのシナリオでは、リソースの分離が非常に重要です。これにより、システムリソースの使用率、パフォーマンス、セキュリティ、信頼性、柔軟性が向上し、企業が次のような多くのビジネス上の課題を解決できます。

異なるテナント間のリソースの競合を回避し、データのセキュリティとテナントのエクスペリエンスを向上させます。
さまざまなビジネスシナリオに応じてさまざまなリソースを割り当て、リソースの使用率とパフォーマンスを向上させます。
さまざまなデータ処理タスクまたはデータベースインスタンスを分離することで、データセキュリティを向上させ、アクセスを制限します。
柔軟な拡張と縮小を実現し、さまざまなビジネスやデータ量の要件に応じてリソース割り当てを動的に調整します。
システムの信頼性と安定性を向上させ、障害を分離し、システム全体への影響を回避します。

ただし、ClickHouse にはリソース分離のための特別な設計はなく、クラスターとレプリケーションの構成、load_balanding 戦略、および指定されたローカルテーブルへの書き込みを通じて、一定の読み取りと書き込みの分離が実現されます。ホットとコールドの分離については、ClickHouse はストレージポリシーを構成し、TTL、TO DISK、TO VOLUME などのテクノロジを使用して実装します。

ByConity は、ストレージとコンピューティングの分離のアーキテクチャ設計により、リソースの分離を適切に実現します。コンピューティンググループ (仮想ウェアハウス: VW) の概念を導入します。仮想ウェアハウスは、コンピューティングリソースを複数に分割することができる、コンピューティングリソースの仮想的な組織です。仮想クラスターは、物理的なクラスターを提供します。異なるテナント間のリソースの分離。同時に、元々コンピューティングリソースと結合していたストレージを分散ストレージ管理に統合した後、コンピューティングリソースとストレージリソースは完全に分離され、ステートレスになるため、コンピューティングノードは主にデータ書き込み、ユーザークエリ、またはコンピューティングタスクを担当します。いくつかのバックグラウンドタスク。したがって、ByConity は、仮想ウェアハウスの展開と使用を通じて、マルチレベルのリソース分離を実装します。

図 3 ByConityコンピューティンググループ

テナントの分離: ByConity の仮想ウェアハウスはステートレスであり、さまざまなビジネスやシナリオに応じてオンデマンドで作成でき、各仮想ウェアハウスは排他的なシステムリソースであるため、マルチテナントの分離を簡単に実現できます。もちろん、リソースの使用率を向上させるために、ByConity は仮想ウェアハウス間のリソースのリースもサポートし、リソースの共有を実現します。
コンピューティングリソースの分離: 仮想ウェアハウスはコンピューティングリソースの物理的な分離を可能にし、各仮想ウェアハウスには複数のワーカーを含めることができ、柔軟に作成できます。

読み取りと書き込みの分離

リソースの分離に加えて、読み取りと書き込みの分離も実現したいと考えています。読み取りと書き込みの分離とは、読み取り操作と書き込み操作を別々に処理することです。実際のビジネスでは、読み取り操作と書き込み操作ではハードウェアリソースと時間に対する要件が異なるため、読み取り操作と書き込み操作が相互に影響してシステムのパフォーマンスに影響を与えることを避けるために、読み取り操作と書き込み操作には異なるハードウェアリソースを使用することが望まれます。 . 資源を無駄にすることで、具体的なメリットは以下のとおりです。

ストレージコストの削減: 読み取りおよび書き込み操作を異なるストレージノードに直接実行して、不必要なデータの重複や冗長性を回避します。
クエリ効率の向上: 読み取り操作を専用の読み取りノードに誘導してクエリの待機時間を短縮し、それによってデータ処理効率とユーザーエクスペリエンスを向上させます。
ネットワークコストの削減: ユーザーに近いノードを読み取るように読み取り操作をガイドし、データ伝送距離とネットワークコストを削減します。
システムの可用性の向上: 読み取り操作と書き込み操作を別のノードに直接実行します。ノードに障害が発生した場合、影響を受けるのはノード上の読み取りまたは書き込み操作のみであり、システム全体の可用性には影響しません。

ByConity は、仮想ウェアハウスを通じて読み取りと書き込みの分離を実現できます。ユーザーは、読み取りおよび書き込み操作に使用する仮想ウェアハウスを指定でき、システムは自動的に異なる読み取りおよび書き込みリクエストを転送します。たとえば、挿入操作は書き込み専用のコンピューティンググループを使用し、選択操作は読み取り専用のコンピューティンググループを使用します。読み取りジョブと書き込みジョブは相互に影響しません。ただし、ByConity は統合分散ストレージを使用するため、必然的にパフォーマンスの問題が発生しますが、ここでは ByConity はローカルキャッシュ (Local Cache) を使用してそれを解決します。

ローカルキャッシュ

ByConityでは、大容量のローカルキャッシュ管理のために、LRUアルゴリズムに基づいて最適化されたBucket-LRUアルゴリズムを採用しており、キャッシュ内のデータブロックを複数のバケットに分割し、各バケットに一定数のデータブロックを格納します。、LRU アルゴリズムを使用して各バケットを削除します。このようにして、キャッシュ内のデータブロックを複数のバケットに分散できるため、キャッシュ削除の頻度が減り、LRU アルゴリズムのオーバーヘッドも減ります。コンピューティンググループの拡大や縮小によりネットワークトポロジが変化した場合でも、この仕組みを利用してデータの入れ替えを回避します。

図 4 ByConityのキャッシュ強度セグメント

ByConity では、キャッシュの粒度として、図 4 に示すように、ファイル単位と圧縮ブロック単位の間のキャッシュ粒度であるセグメントの概念を導入しており、サイズは設定可能であり、ファイルストレージに適しています。セグメントは複数のマークで構成され、各マークには複数の圧縮ブロックが含まれます。クエリでセグメントを読み取る必要がある場合、まずセグメントがキャッシュに存在するかどうかを確認し、存在する場合はキャッシュからデータを直接読み取ります。存在しない場合はディスクからデータを読み取る必要があります。実際の使用では、データの特性と要件に応じて適切なキャッシュ戦略を選択し、最高のパフォーマンスと効果を達成するために最適化および調整する必要があります。ByConity のキャッシュ戦略は次のとおりです。
セグメントのアクセス頻度に応じて：データのアクセス頻度に応じて、どのデータがホットデータであるかを判断し、キャッシュします。
セグメントのアクセス範囲に応じて、アクセス頻度は高くないものの、クエリ範囲が広いデータもキャッシュする必要があります。
データ更新時間に基づいてホットデータを決定する: リアルタイムテーブルなどのシナリオでは、新しいデータは多くの場合ホットデータであり、キャッシュする必要があります。
統計情報に基づいてキャッシュ戦略を最適化する (開発中): どのデータがホットデータであり、統計情報に基づいてキャッシュする必要があるかを判断します。

ByConity のローカルキャッシュの主な目的は、コスト (容量) の低いローカルキャッシュディスクを使用して分散ストレージにデータをキャッシュし、ネットワーク読み取りによって引き起こされるパフォーマンス遅延の増加を軽減することです。ローカルキャッシュを使用すると、データのアクセス速度と応答速度が向上し、ネットワークへの依存が軽減され、システムの遅延が軽減され、システムのパフォーマンスと安定性が向上します。

無誘導伸縮

ビジネスデータが倍増するにつれ、継続的な拡張による事業展開を支援する必要がありますが、クリックハウスは拡張・縮小をアーキテクチャ上特に考慮していないため、拡張コストが非常に高くなります。運用保守の学生が手動で拡張するか、自動スクリプトによって拡張を完了し、新しい ClickHouse ノードを作成してコピーデータを移行するため、時間コストと移行結果の検証に問題があります。さらに、容量拡張中に新しいシャードを新しいノードにデプロイする必要があるため、データの不均衡が生じますが、これはデータのリバランスによって解決する必要があります。

ByConity のストレージとコンピューティングの分離アーキテクチャは、この問題を自然に解決し、ビジネスに依存しない拡張と縮小を実現できます。ByConity の拡張には、ワーカーの CPU コア数やメモリサイズを調整する垂直拡張と、ワーカーの数を増減してシステムの同時実行性を向上させる水平拡張の 2 種類があります。これらは依然として ByConity の仮想ウェアハウスとワーカーを通じて実装されています。

一方、リソースマネージャー (Resource Manager) は、コンピューティングリソースの統合管理とスケジューリングを担当し、各コンピューティンググループのパフォーマンスデータとリソース使用量を収集し、読み書きタスクやバックグラウンドタスクにリソースを動的に割り当て、拡張と縮小を実行してリソースの使用率を向上させます。ByConity のコンポーネントはコンテナ化されており、Kubernetes レプリカの数を調整することで、指定したコンピューティンググループを拡張および縮小することができ、非常に便利です。また、kubernetsの伸縮閾値を設定することで、コンピューティンググループのリソース使用状況と合わせて動的な伸縮を実現できます。
一方、ByConity のメタデータとデータはリモートエンドに保存されます。ステートレスコンピューティングノードにより、拡張と縮小が非常に軽量になります。コンピューティングインスタンスが開始されるのを待つだけで、追加データなしでサービスをすぐに実行できます。リアルタイムのスケーリングを実現するための移行オーバーヘッド。

4. ByConityの使用シナリオ

ByConity は、主に OLAP クエリおよびコンピューティングシナリオで使用される、列ストレージエンジン、MPP 実行、インテリジェントなクエリ最適化、ベクトル化実行、Codegen、インデックス作成、データ圧縮など、多数の成熟した OLAP テクノロジを使用します。リアルタイムデータアクセス、大規模で幅広いテーブルの集計クエリ、大量のデータの下での複雑な分析と計算、および複数テーブルに関連するクエリシナリオにおいて非常に優れたパフォーマンスを発揮します。

シーン分類	シーン	説明	特徴
インタラクティブなクエリ	ユーザー定義のクエリ	多次元クエリ分析をサポートするデータアプリケーション	フリーディメンション、マルチテーブル関連付け、高速応答
	セルフサービスレポート	TableauなどのBIツールをサポート	フリーディメンション、マルチテーブル関連付け、高速応答
	ユーザーポートレート分析	DMPなどのサークル人物ポートレートプラットフォームをサポート	フリーディメンション、マルチテーブル関連付け、高速応答
	マーケティング効果分析	トラフィック効果ファネル分析をサポート	マルチテーブル関連付け、リアルタイム
	行動ログ分析	ログの調査と分析をサポート	ログ取得、大量データ
リアルタイムデータダッシュボード	リアルタイムのビジネス監視大画面	DataV などの大規模なビジュアル画面をサポート	リアルタイム
	ライブデータ統計ダッシュボード	リアルタイムレポートのサポート	リアルタイム
	ビジネスダッシュボード	サポートレポートツール	統計、高速応答
	システムリンク監視	リアルタイム監視アプリケーションをサポート	リアルタイム
リアルタイムデータウェアハウス	リアルタイムのデータアクセス	リアルタイムのデータ書き込みと更新をサポート	リアルタイムのデータ書き込み、すぐに確認可能
	準リアルタイムETL計算	複雑な計算、データクリーニングをサポート	混合荷重

表1

V. 総括と展望

要約すると、ByConity はストレージとコンピューティングが分離されたアーキテクチャを使用しており、多くの面で最適化およびアップグレードされており、次の利点と機能があります。

リソースの分離: 異なるテナントのリソースを分離します。テナントは相互の影響を受けません。
読み取りと書き込みの分離: コンピューティングリソースとストレージリソースは、読み取り操作と書き込み操作が相互に影響を及ぼさないように分離されます。
弾力的な拡張と収縮: 弾力的な拡張と収縮をサポートし、リアルタイムかつオンデマンドでコンピューティングリソースを拡張および縮小して、リソースの効率的な利用を確保できます。
データの強力な一貫性: データの読み取りと書き込みの強力な一貫性により、データは常に最新であり、読み取りと書き込みの間に不整合がないことが保証されます。
ハイパフォーマンス: 列ストレージ、ベクトル化実行、MPP 実行、クエリ最適化などの主流の OLAP エンジン最適化を採用し、優れた読み取りおよび書き込みパフォーマンスを提供します。

図5はByConityの今後の開発計画であり、今後は以下の観点から最適化・改善を行う予定です。

図5 ByConityの今後の開発計画

分散ディスクキャッシュがサポートされているため、ノードの再起動によるローカルキャッシュの損失の問題が解決される一方で、グローバルに最適なキャッシュメカニズムが実現され、キャッシュヒット率の向上が期待されます。
Hudi や Iceberg などの外観サービスをサポートします。
ByConity ストレージデータレイヤー上でストレージサービスをサポートし、Spark エンジンまたは Presto エンジンのコンピューティング能力を使用して一部の ETL タスクなどを実行します。