ClickHouse から ByConity に移行した後、毎日 320 TB のデータが追加され、クエリのパフォーマンスは非常に安定しています。

背景の紹介

ByConity はさまざまなビジネスシナリオに適しており、リアルタイムデータアクセス、大規模で幅広いテーブルの集計クエリ、大量のデータに基づく複雑な分析と計算、および複数テーブルの相関クエリにおいて非常に優れたパフォーマンスを発揮します。実際のビジネスシナリオを使って、この行動分析システムを紹介してみましょう。この行動分析システムは、多次元のユーザー行動分析プラットフォームに基づいており、イベント分析、リテンション分析、コンバージョン分析、ユーザーのグループ化、分析などの複数の分析手法とシナリオを提供します。ユーザーの維持。この記事では、元の ClickHouse クラスターを使用するときにこの多次元ユーザー行動分析プラットフォームが遭遇する問題と課題、および ByConity の移行後にこれらの問題を解決してビジネスにメリットをもたらす方法を紹介します。

図1 行動分析システムの アーキテクチャ設計

問題と課題

当初、このシステムは ClickHouse クラスターに導入されましたが、一方で、ビジネスの急速な発展により、データ量は日々増加し、1 日あたりの最大新規データ数は 320 TB を超えました。新しい行数は 2.3 兆を超え、ユーザーデータのディメンションは 20,000 を超えました。一方、ユーザークエリのニーズはより柔軟で多様化しており、詳細なクエリ、集計クエリ、対話型分析クエリを同時にサポートする必要があります。迅速な応答結果を提供します。さらに、データ量は増加し続けるため（年率 35% の増加）、このような大規模なデータ増加によってもたらされる課題に対応できるだけでなく、コストの増加率を一定の範囲内に制御する必要があります。

しかし、既存の ClickHouse クラスターでこれを行うのは困難です。その理由は、ClickHouse は Shared-Nothing アーキテクチャに基づいており、各ノードが独立しており、ストレージリソースを共有しないため、コンピューティングリソースとストレージリソースが密接に結合されており、次の問題が発生します。

スケールアップとスケールダウンのコストは高くなり、データ移行が必要となるため、必要に応じてリアルタイムでスケールアップとスケールダウンができなくなり、リソースの浪費や制御不能なコストの発生にもつながります。
密結合アーキテクチャでは、共有クラスター環境でマルチテナントが相互に対話し、ユーザークエリが相互に影響を及ぼします。
クラスタ上のノードの読み取りと書き込みは同一ノード上で完了するため、読み取りと書き込みは相互に影響を及ぼします。
複数テーブルの結合操作などの複雑なクエリのパフォーマンスサポートはあまり優れておらず、クエリに対するユーザーの多様なニーズを満たすことができません。

テクノロジーの選択

そのため、企業は 2022 年の初めに、コンピューティングとストレージの分離アーキテクチャを備えた ByConity をメインの OLAP エンジンとして使用し始めました。 ByConity は、コンピューティングとストレージの分離アーキテクチャを採用し、コンピューティングとストレージの分離、柔軟な拡張と縮小、マルチテナントリソースの分離、データの読み取りと書き込みの強力な一貫性など、複数の主要な機能をサポートするオープンソースのクラウドネイティブデータウェアハウスです。。列ストレージ、ベクトル化実行、MPP 実行、クエリ最適化などの主流の OLAP エンジン最適化を利用することで、ByConity は優れた読み取りおよび書き込みパフォーマンスを提供できます。

図 2 ByConity の 3 層技術アーキテクチャ図

ByConity は、オープンソースの ClickHouse アーキテクチャに基づいたアップグレードで、コンピューティングとストレージを分離するアーキテクチャを導入し、コンピューティングとストレージが各ノードでローカルに管理されるアーキテクチャを、クラスタ全体のすべてのタスクを統合して管理します。分散ストレージデータアーキテクチャは、各コンピューティングノードをステートレスな純粋なコンピューティングノードにし、分散ストレージの拡張機能とコンピューティングノードのステートレス特性を使用して動的な拡張と縮小を実現します。この改善により、ByConity には次の重要な機能が追加されました。

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

事業収入

ByConity を導入した後、全体的なパフォーマンスは 91% に達し、ユーザーからのフィードバック調査により、このパフォーマンス指標もユーザーの許容範囲内に収まりました。 ByConity への移行によってもたらされる全体的なメリットとエクスペリエンスの概要を以下に示します。

リソースのプリエンプションを回避し、クエリのパフォーマンスが 100% 安定していることを確認します 。

元の ClickHouse クラスターでは、ClickHouse がリソースの分離とテナントの分離を実現していないため、複数のユーザーがクエリのためにクラスターを共有すると、1 人のユーザーがリソースにクエリを実行すると、オーバーヘッドが非常に高くなるという問題が頻繁に発生しました。リソースのプリエンプションにより、このクラスター上のすべての共有ユーザークエリが不安定になり、サービス品質が満足できなくなります。ただし、ByConity に移行すると、コンピューティンググループが完全に物理的に分離されるため、異なるユーザーのクエリが相互に影響を受けることがなくなり、すべてのユーザーのクエリの全体的なパフォーマンスが 91% に達します。 10秒以内に完了できます。さらに、ByConity は、独自に開発した複雑なクエリリンク、コールドデータの読み取りを削減するための独自に開発したディスクキャッシュ、および頻繁に使用される配列のインデックスを提供します。また、オリジナルの ClickHouse クラスターと比較して、ホット読み取りの効率も向上しています。 ClickHouse クラスター、ByConity クラスターのパフォーマンス損失は 10% 以内です。

運用とメンテナンスのコストが低く、障害のあるノードは数秒で交換できます 。

本来、Clickhouse クラスターでは、クラスター内のノードが壊れていることが判明した場合、修復のためにマシン全体を停止する必要があります。これは、ClickHouse のコンピューティングリソース、ストレージリソース、およびメタデータ情報がすべてこのノード上にあるためです。新しいノードを交換する前に、壊れたノードのローカルディスクをバックアップし、新しいノードに移行する必要があります。保守コストは比較的高くなります。高いため、データの一貫性を保証するのは困難です。 ByConity の場合、コンピューティンググループが壊れた場合、コンピューティンググループにはデータが保存されず、ステートレスコンピューティングノードのみが含まれるため、データの信頼性と一貫性は HDFS によって提供されるだけです。ビジネスクエリのパフォーマンスに応じてローカルホットリードデータキャッシュの損失を確実に制御できるようにするため、この部分は主に ByConity ストレージとコンピューティング分離アーキテクチャの恩恵を受けます。

センサーレスの 伸縮により リソースコストを節約:

ByConity は、Kubernetes の柔軟なスケーラビリティに基づいて、シームレスな拡張と縮小を実現できます。同時に、サーバーに障害が発生した場合でも、無制限に拡張できます。 ByConity のノードはステートレスコンピューティングノードにすぎず、それを直接削除してもクラスター全体にはほとんど影響しないため、心配する必要はありません。さらに、適応スケジューリングを使用して、遅いノードを回避し、スループット能力を向上させ、ノードのリソース使用率を向上させます。同時に、ByConity の圧縮率は非常に高く、1 日あたり 460 TB のデータが追加され、圧縮後は 100 TB に達し、低基数のエンコーディングもサポートしています。 ZSTD およびその他の圧縮方法。極端な場合には、寄木細工よりも消費するストレージが少なくなります。

データの一貫性が強く保証されており、メンテナンスの複雑さはゼロに近いです 。

ByConity に移行した後、ByConity にはローカルのマスター/スレーブ同期の問題がなく、データの一貫性の問題は HDFS/S3 などの基盤となるオブジェクトストレージによって直接解決されるため、データの一貫性の問題は完全に解決されました。このようにして、一貫性維持の複雑さが大幅に軽減され、エラーの可能性も低くなります。現在、データの一貫性の問題を報告するユーザーはほとんどいません。しかし、ClickHouse クラスターはノード間通信を通じて複数のコピーによって維持され、一貫性の問題は一貫性キューによって維持されるため、以前はこの問題が頻繁に発生していました。また、実装は非常に複雑でエラーが発生しやすいものでもありました。さらに、ByConity は HDFS を介してデータファイルに直接アクセスでき、さまざまなコンピューティングエンジンがさまざまなコネクタに適応してデータを読み取り、ユニバーサルな機能を備えています。

今後の展望

1 年半にわたる実践的な調査を経て、ByConity は社内で使用されるメインの OLAP エンジンとなり、後に多数のユーザーとデータが移行され、最終的には元の ClickHouse クラスターに置き換わることになります。 ByConity は、コンピューティングとストレージが分離された OLAP エンジンとして、高性能、高スケーラビリティ、高安定性という利点を備えており、大規模なデータ処理と分析のニーズを満たすことができることがわかります。同時に、コミュニティでのコミュニケーションやコミュニティ https://github.com/ByConity/ByConity/issues/26 によってリリースされたロードマップディスカッションを通じて、ByConity は将来的に主に次の方向に焦点を当てます。

実行層の多段階実行、ETL機能などをサポート
Hudi、Iceberg などのデータレイクフェデレーションクエリをサポートします。

ByConity コミュニティには多くのユーザーがおり、非常にオープンなコミュニティです。Github で共同構築について話し合ってください。また、WeChat グループ、Feishu グループ、または Discord に参加してコミュニケーションに参加することもできます。

GitHub：https://github.com/ByConity/ByConity