ClickHouse のストレージとコンピューティングの分離変革: Xiaohongshu の自社開発クラウドネイティブ データ ウェアハウスの実践

ClickHouse は業界で最も強力な OLAP システムとして、広告、コミュニティ、ライブ ストリーミング、e コマースなど、Xiaohongshu のさまざまなビジネス分野で広く使用されています。ただし、ネイティブの ClickHouse MPP アーキテクチャには、運用および保守コスト、柔軟な拡張、障害回復の点で大きな制限があります。これらの課題に対処するため、Xiaohongshu のデータフロー チームは、オープン ソースの ClickHouse をベースに、クラウドネイティブのリアルタイム データ ウェアハウス RED ClickHouse (以下、「REDck」) を独自に開発しました。

ClickHouse 本来の超高性能を維持しながら、徹底的なクラウドネイティブ化を実施し、コンピューティング層とストレージ層の弾力的な拡張と縮小機能を実現し、運用と保守の負担を効果的に軽減し、コストを削減します。 REDck は、PB レベルのデータのユーザー インタラクティブ分析をサポートする機能を備えており、さまざまなデータ分析ニーズに柔軟に対応して、Xiaohongshu の成長するビジネスとデータ分析のニーズに対応できます。

現在、REDck は、e コマース、広告、コミュニティ、ライブ ストリーミングなど 10 を超えるビジネス シナリオに導入されており、総ストレージ規模は 30 PB を超えています。特に実験プラットフォームやユーザー行動分析プラットフォームなどの典型的なシナリオにおいて、コストの削減と効率性の向上において顕著な成果を達成しました。実験プラットフォームを例にとると、過去2年間で、実験プラットフォームのデータ保存サイクルは2か月から2年に増加し、実験指標と分析シナリオの数は10倍以上に増加しました。このような急速なビジネス成長に伴い、REDck は実験プラットフォームに対して 99.9% の可用性保証を提供し、その強力な拡張性はビジネス拡大の強力なサポートとなっています。

1. 背景

1.1 XiaohongshuリアルタイムOLAPの開発

Xiaohongshu のインフラストラクチャ システム全体は、創業以来、パブリック クラウド上に構築されており、クラウドネイティブとなっています。

リアルタイムOLAP導入前のシステムアーキテクチャ

上図に示すように、Xiaohongshu のクラウドネイティブ ビッグデータ アーキテクチャ システムは、上から順に、アプリケーション層、コンピューティング エンジン層、コンピューティング リソース層、データ層、ストレージ層で構成されています。

●ストレージ層の中核となるのは、大手クラウドベンダーが提供するオブジェクトストレージサービスです。データ レイヤーは、Parquet、ORC、Avro などの一般的なデータ形式を使用し、Hive Metastore を通じて統合されたメタデータ サービスを提供します。

●コンピューティング層では、Xiaohongshu は Kubernetes や YARN などのコンピューティング リソース フレームワークを使用して、リソース プーリングと柔軟な拡張機能を提供します。

●コンピューティングエンジン層では、Spark、Flinkなどの技術を使用してオフラインおよびリアルタイムETLリンクを実装し、PrestoやSparkSQLなどのツールを通じてオフラインレポート機能やデータ分析機能を外部に提供します。

この典型的なクラウドネイティブ アーキテクチャにより、Xiaohongshu のデータ処理は高い柔軟性とスケーラビリティを実現します。しかし、このアーキテクチャシステムでは、リアルタイム OLAP エンジンが不足しているため、Xiaohongshu のデータ分析ビジネスの発展が制限されていました。増大するデータ分析のニーズを満たすために、強力な分析パフォーマンスを備えたリアルタイム OLAP エンジンを導入することが急務となっています。

リアルタイムOLAP導入後のシステムアーキテクチャ

ClickHouse は、高性能なリアルタイム OLAP データベースとして、その卓越したパフォーマンス、高速で安定した更新の反復、積極的に反応するオープン ソース コミュニティにより、大手企業に支持されています。より高速なクエリと分析を実現するために、Xiaohongshu データフロー チームは、同社の実験プラットフォーム用に ClickHouse クラスターを構築しました。

1.2 問題点

初期段階では、ClickHouse は優れたパフォーマンスを発揮し、クエリ応答速度が非常に速く、柔軟性とリアルタイムのパフォーマンスを提供し、Xiaohongshu のデータ分析サービスにさらに強力なアドホック分析機能を提供しました。しかし、データが蓄積され、クラスターのサイズが拡大し続けると、既存のリアルタイム OLAP システムでは使用中に次のような問題が発生します。

● 弾性拡張の難しさ

小紅書の事業が急速に発展するにつれ、生産能力の拡大はチームにとって頻繁な運用・保守業務となりました。 ClickHouse は Share-Nothing アーキテクチャを採用しており、各ノードのコンピューティング リソースとストレージ リソースは強くバインドされているため、クラスターの拡張はマシンのスケジューリング サイクルによって制限されます。同時に、拡張プロセスでは毎週または毎月のデータ移行作業が導入され、安定性や一貫性の問題など、ユーザークエリに影響を及ぼします。

● リソース利用率が低い

ClickHouse はマルチコピーメカニズムを通じて全体的な信頼性を向上させますが、リソースの幾何学的増加にもつながります。ストレージとコンピューティングの不均衡により、ほとんどのシナリオでは、データ ストレージの需要がコンピューティングの需要をはるかに上回りますが、ストレージとコンピューティングの結合により、コンピューティング能力が大幅に浪費されます。さらに、多くのビジネスでは明らかなピークと谷があり、弾力的な拡張機能が欠如しているため、深刻なリソースの冗長性が生じます。

● 安定性の問題

ClickHouse はリソース分離機能が弱いため、ユーザーのクエリ エクスペリエンスが不安定になりやすくなります。クエリのピーク期間中、リソース不足により、クエリの失敗率とクエリの待ち時間が大幅に増加する可能性があります。さらに、ClickHouse のマルチコピー メカニズムは Zookeeper に大きく依存しています。クラスターのサイズが一定のレベルに達すると、Zookeeper の障害頻度が増加し、クラスターのスケーラビリティが制限されます。

● データ同期の問題

ClickHouse は、成熟した分散トランザクション システムが欠如していることでユーザーから常に批判されており、データ同期中にデータの不整合が頻繁に発生します。

● 保守性の問題

ClickHouse の分散テーブルと基礎となるレプリケーション テーブル モードにより、テーブル管理の難易度が大幅に高まります。同時に、ノードの参加、ノードの終了、レプリカのバランス調整などの必要な分散管理機能が欠けているため、クラスターの数が増えるとメンテナンスコストが膨大になります。

上記の理由から、ClickHouse のコミュニティ オープンソース バージョンは、広告、コミュニティ、ライブ ストリーミング、電子商取引、その他のビジネス ニーズにおける企業の大規模なアプリケーション ニーズを満たすことが困難です。チームにとって、クラスターの不安定なストレージ制限と運用および保守の問題を解決することが急務となっています。

1.3 ソリューションの選択

解決策1: クラスターの拡張

クラスターの拡張は、ストレージのボトルネックの問題に対する一般的な解決策です。ただし、ClickHouse のコミュニティ オープン ソース バージョンには、データ負荷の自動分散のサポートが組み込まれていないため、新しく追加されたノードは手動で負荷を分散し、他のクラスターのテーブル構造を同期する必要があります。さらに、容量の拡張だけでは、大規模データ サービスの課題を真に解決することはできず、最終的には履歴データを削除するために TTL を追加する必要があります。同時に、拡張されたクラスターには可用性のリスクがあり、単一点障害によるデータ損失を回避するために 2 倍のマシン リソースが必要になるため、コストと複雑さが増大します。

要約すると、クラスター拡張ソリューションは、運用と保守の難易度を大幅に高めるだけでなく、ストレージのボトルネックの問題を根本的に解決することに失敗します。ストレージの問題は、依然としてチームの頭上に常につきまとう「ダモクレスの剣」です。

ソリューション2: ストレージとコンピューティングの分離

もう 1 つのより困難な解決策は、独自のクラウドネイティブのリアルタイム データ ウェアハウスを開発することです。このソリューションは、メタデータの集中化、ストレージとコンピューティングの分離、コンテナ化など多くの課題に直面しており、チームが運用と保守の機能から独立した研究開発に移行することを必要としますが、スケーラビリティの問題を根本的に解決できます。

従来のデータベース システムでは、通常、ストレージとコンピューティングは強く結び付けられており、同じマシン リソースを共有しています。クラウドネイティブ テクノロジーの急速な発展により、ストレージとコンピューティングを分離したアーキテクチャを採用するデータベース システムが増えています。これにより、ストレージ層とコンピューティング層が分離され、ストレージ リソースとコンピューティング リソースを個別に柔軟に拡張できるようになりました。ストレージとコンピューティングを分離したアーキテクチャには、多くの利点があります。まず、クラウド ベンダーが提供するオブジェクト ストレージにデータを保存すると、データ ストレージをほぼ無限に拡張できるようになります。次に、高頻度リアルタイムコンピューティングのパフォーマンス要件を満たし、コストを制御するために、需要に応じてコンピューティングリソースを動的に調整します。最後に、障害が発生した場合でも、外部データ ストレージを迅速に移行および復元できるため、データの信頼性が大幅に向上します。

現在、SnowFlake、Redshift、TiDB など、クラウドネイティブ データベースのほとんどは、ストレージとコンピューティングを分離したアーキテクチャに基づいて実装されています。ストレージとコンピューティングの分離は、分散データベースの主流の方向性になっていると言えます。

1.4 私たちの選択

最終的に、私たちは正しいが難しい道を選択し、自社開発のストレージとコンピューティングの分離アーキテクチャを通じて、リアルタイム OLAP エンジンの容量拡張と運用保守の問題を根本的に解決し、Xiaohongshu の分析ビジネスの急速な発展をより良くサポートすることを望んでいます。自社開発のテクノロジーにより、ビジネスニーズに迅速に対応し、コストを管理することができます。

ClickHouse のコミュニティ オープン ソース バージョンに基づいて、オブジェクト ストレージ ベースのストレージとコンピューティングを分離したバージョン Red ClickHouse ( REDckと呼ばれる) を作成しました。

2. クラウドネイティブリアルタイムデータウェアハウスの設計と実装

クラウドネイティブリアルタイムデータウェアハウスの全体設計図

Xiaohongshu が自社開発したクラウドネイティブ分析データベースの全体設計図を上図に示します。 REDckは、膨大なデータに対して数秒以内にリアルタイムで複雑な分析を提供する機能を備えており、A/Bテスト分析、ユーザー行動分析、広告ユーザーセグメンテーションなど、社内の幅広いビジネスシナリオを幅広くサポートしてきました。

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

次の図に、3 つのレイヤーで構成される REDck のストレージとコンピューティングの分離アーキテクチャを示します。

REDck 全体アーキテクチャ図

● 統合メタ情報センター

オープンソースの ClickHouse では、メタ情報は各ノードのローカル ディスク ディレクトリに保存され、ディレクトリ リストを読み取ることで対応するメタ情報が構築されます。 REDck によって構築された統合メタデータ サービスは、内部ストレージや外部ストレージなどの複数のストレージ方法を含む、ステートレスな集中型サービスです。内部ストレージ モデルでは、リレーショナル データベース (MySQL など) またはキー値データベース (Redis など) を選択し、外部ストレージ モードでは、Hive データ ウェアハウスや Iceberg データ レイクと深く統合できます。

統一されたメタデータ サービス レイヤーを構築する利点は、クラスターの全体的な情報が各マシン ノードに分散されるのではなく、集中的に制御できることです。集中化された情報管理機能により、データベース エンジンはストレージとコンピューティングの分離およびトランザクション メカニズムをより簡単に実装できるようになります。現在、各クラスターには独自の独立したメタデータ サービスがあります。将来的には、マルチクラスター メタデータ サービスがさらに実現される可能性があります。つまり、メタデータ サービスのコピーは 1 つだけであり、複数のクラスターで共有できます。

● 計算層

コンピューティング グループが基本単位です。各コンピューティング グループは、マルチノード分散コンピューティング クラスターです。ユーザーは、基盤となるサーバー ノードとワーカー ノードの詳細を気にすることなく、ゲートウェイを介してコンピューティング ウェアハウスにアクセスします。コンピューティング タスクは、必要に応じて実行するためにサーバー ノードからワーカー ノードにディスパッチされます。さらに、クラスターには、クラスターの中心的なステータスの管理と調整を担当するマスター ロールもあります。ストレージとコンピューティングの分離の実装により、クラスターを水平方向および垂直方向に簡単に拡張できます。

● ストレージ層

ストレージ層は、分散ファイル システムやオブジェクト ストレージなどのさまざまな低コストのストレージ方式を実装し、データベースに大量データ処理のニーズを満たす効率的でスケーラブルなストレージ機能を提供します。

2.2 統合メタデータサービス

クラウド上のオブジェクト ストレージにデータを保存した後、すべてのノードがデータのメタデータにアクセスできるようにすることは困難な作業です。オープンソースの ClickHouse では、メタデータはディスク ディレクトリから取得され、対応するメタデータはディレクトリ リストを読み取ることによって構築されます。ただし、メタデータは各ノード内に分散しており、各ノードには固有の状態があります。ノードがダウンすると、クラスター全体が使用できなくなります。各ノードが統合されたメタデータ情報を共有し、信頼性を向上できるようにするために、REDck は統合メタデータ リポジトリとメタストア ロールを導入します。メタストアは、クラスターのメタ情報の統合管理を担当します。各コンピューティング ノードが起動したら、最新のメタデータを取得するためにメタストアにアクセスするだけで済みます。

統合メタデータ リポジトリ ストレージは、内部ストレージと外部ストレージの 2 種類に分かれています。メタデータを保存するための内部ストレージとして MySQL を使用し、全体的な一貫性を確保するために MySQL のトランザクション機能を使用します。 Metastore はクラスター全体の情報を引き継いで維持するため、クラスターを Zookeeper で管理する必要がなくなり、Zookeeper は ClickHouse の制約から解放されます。同時に、メタデータの保存には、社内で開発した REDkv (オープンソースの Redis に類似) を使用して一連のファイル システム マッピングを実装し、クラスターをディスク ファイル システムの制限から完全に解放し、真のクラウド ネイティブを実現します。外部ストレージに関しては、Hive データ ウェアハウスや Iceberg データ レイクと積極的に統合し、REDck が外部ストレージから直接メタデータを読み取ることができるようにしています。

Metastore と REDck 間の通信プロセスを下の図に示します。まず、デプロイされた MetaStore は、サービスを登録するために登録センターに登録要求を送信します。 REDck クラスターがデプロイされると、レジストリからサービス検出を要求し、検出されたサービスにアクセスしてメタデータ情報を取得します。

統合メタストア呼び出し図

2.3 オブジェクトストレージアクセスの最適化

オブジェクト ストレージは、無制限のスケーラビリティ、低コスト、極めて高い信頼性という特徴を備えています。オブジェクト ストレージを使用してデータを保存することで、増大するデータ ストレージの需要を根本的に解決し、従来のデータ ストレージによってもたらされる問題に別れを告げることができます。オブジェクト ストレージの信頼性により、レプリカ メカニズムを放棄できるようになり、レプリカの一貫性、リソースの無駄、Zookeeper の安定性などの一連の厄介な問題が解決され、REDck ノードのステートレス性の基盤が提供されます。

ただし、オブジェクト ストレージは完璧ではありません。オブジェクト ストレージを導入した後、次のような問題が発生しました。

●アクセス速度: オブジェクト ストレージの総スループットの制限は理論的には帯域幅によってのみ制限されますが、シングル スレッドのアクセス速度は低く、ディスクよりもはるかに低くなります。

●レイテンシ: 現在、オブジェクト ストレージへのアクセスは主に HTTP プロトコルを介して行われており、レイテンシが高く (接続の確立などの操作のレイテンシも含め、20 ミリ秒に達することがあります)、一部の小さなファイルには非常に不向きです。

●安定性: 複数のクラウドベンダーのオブジェクト ストレージの安定性の問題がコンピューティング層に与える影響を軽減する方法。

オブジェクト ストレージは REDck の基礎であり、そのパフォーマンスの問題がデータベース システム全体のボトルネックになります。この目的のために、オブジェクト ストレージの読み取りと書き込みの問題に対して次の最適化を行いました。

●キャッシュ メカニズムの改善: キャッシュ メカニズムを通じてオブジェクト ストレージのアクセス速度を改善し、クエリ パフォーマンスを 100 倍向上させます (詳細については、キャッシュ戦略を参照してください)。キャッシュされていないデータの場合、並列化を使用してデータのダウンロード速度が向上し、パフォーマンスが 10 倍向上します。

●クエリ計算プロセスを最適化: クエリ実行プランの並べ替えやマルチスレッド適応最適化などの方法により、HTTP レイテンシをユーザーが無視できるレベルまで削減します。

●アクセス モジュールの再構築: オブジェクト ストレージ アクセス モジュールを最適化および再構築し、データ チェック、タイムアウト検出、および障害再試行メカニズムを追加して、アクセスの安定性を向上させます。

具体的なプロセスを以下の図に示します。

1. クライアントはサーバーにクエリを送信します。サーバーはクエリに基づいて読み取るパーツを選択し、パーツの markRanges を並べ替えて、各接続スレッドが同じパーツのマークを読み取るようにすることで、接続数を減らし、HTTP レイテンシを削減します。

2. 並べ替えた範囲を対応する Part クラスに渡します。範囲のサイズに応じてダウンロード方法（3 種類に分かれています）を動的に選択することで、ダウンロード負荷を軽減できます。

a.大きなパーツの場合は、マルチスレッドのマルチセグメント ダウンロードを使用し、最終的に複数のセグメントを 1 つのパーツにマージします。

b.小さなパーツの場合は、まずメモリにキャッシュしてから、ローカルにダウンロードします。

紀元前その他の部分については、ローカル コンピューターに直接ダウンロードすることを選択します。

3. サーバーはダウンロードされたパーツを取得し、クエリ結果を計算してクライアントに返します。

オブジェクトストレージ最適化図

2.4 キャッシュの最適化

オブジェクト ストレージは、ストレージとコンピューティングの分離を実現するための基盤を提供しますが、クエリを実行するときにクラウドからデータを取得する必要があるために発生する遅延の問題ももたらします。オブジェクト ストレージの最適化により、ほとんどのシナリオでプルの問題が解決されていますが、頻繁にアクセスされるホット データをクラウドから繰り返しプルするのは効率的ではありません。この目的のために、私たちは、マシンのディスクをオブジェクト ストレージのキャッシュ ディスクとして使用し、高頻度のクエリ要件に対して高いパフォーマンスを保証するキャッシュ戦略を提案しました。

マルチレベルキャッシュアーキテクチャ

マルチレベル キャッシュ アーキテクチャ全体を図に示します:メモリ キャッシュ -> ローカル ディスク キャッシュ -> 分散キャッシュ。上から下にかけて、キャッシュ パフォーマンスは高から低まで、可用性と容量は低から高までの範囲で、さまざまなタイプと人気のデータに適しています。このマルチレベル キャッシュ アーキテクチャにより、最小限のコストで究極のクエリ パフォーマンス エクスペリエンスをユーザーに提供できます。データの特性に基づいて、次の 2 つのキャッシュ戦略を提供します。

●パッシブキャッシュ:予測不可能なデータに適用できます。ユーザーがクエリを実行すると、対応するデータが一時的にキャッシュされ、後続のクエリのパフォーマンスが向上します。

●アクティブ キャッシュ:頻繁にアクセスされると予測されるデータに適しています。クラスターが起動すると、システムは、ユーザーが設定したルールとユーザーのバックグラウンドでのクエリ履歴に基づいて、ユーザーが今日クエリする可能性のあるデータをプロアクティブに計算し、このデータをオブジェクト ストレージからローカル ディスクに事前キャッシュします。ユーザーがクエリを実行すると、ローカル ディスクから直接読み取られ、パフォーマンスはローカル ディスクと同等になります。

同時に、ローカル ディスク領域が限られているため、LRU とクロック スイープの 2 つのキャッシュ削除戦略を提供します。キャッシュ クリーニングの速度をさらに最適化するために、削除する必要があるキャッシュ データをすばやくフィルター処理するディスク カタログをメモリ内に構築しました。

キャッシュ戦略図

2.5 分散タスクスケジューリング

オブジェクト ストレージとキャッシュ戦略により、REDck のクラスター ノードはクラウド ベンダーに保存されているデータを共有できるため、ローカル ディスクの負荷が軽減されますが、同時にタスク実行の競合という課題も生じます。ここでのタスク タイプには、圧縮、変更、挿入、およびキャッシュ タスクが含まれます。元のアーキテクチャでは、各インスタンスは互いに独立しており、タスクのスケジュールの競合を考慮する必要はありません。ストレージとコンピューティングの分離を実現した後、競合を回避するために、異なるノード間のタスク スケジューリングを計画して、秩序立ったスケジューリングを実現する必要があります。これにより、2 つの主要な課題が生じます。

1. グローバルタスク計画を統一するにはどうすればいいですか?

2. クラスターの拡張と縮小時に、タスクの競合が発生しないようにスケジュール計画を自動的に調整する方法。

統一されたスケジュールを実現するために、グローバルに選出された一意のマスター ロールを導入しました。マスターは、特定のサーバーをテーブル全体のグローバル タスク コーディネーターとして指定します。コーディネーターは、事前に設定されたスケジュール戦略 (バケットによるスケジュールなど) に従ってさまざまなタスクを割り当て、すべてのタスクが順序どおりに実行されるようにします。ただし、クラスター異常の場合、スプリットブレインや重複タスク割り当てなどの問題が発生する可能性があります。これらの問題を解決するために、タスク実行プロセス全体にトランザクション管理と異常検出ロジックを追加し、タスクの競合がないようにし、データの正確性を維持しました。

分散タスクスケジューリングアーキテクチャ図

2.6 データバケット

前述したように、分散タスク スケジューリングを実現するために、グローバルに選出されたマスター ロールを導入します。ただし、割り当てられたタスクを実行するプロセスで適切なスケジューリング戦略がない場合、データの分散が過度になり、集計や複数テーブルの結合のパフォーマンスが低下し、マシン メモリ オーバーフロー (OOM) やコンピューティング スキューなどの問題が発生することがよくあります。これらの問題を解決するために、 REDck にバケットを導入しました。  コンセプト。

バケットとは、テーブルまたはパーティション内の指定された列の値をキーとしてハッシュし、指定されたバケットにハッシュすることを意味します。たとえば、実験プラットフォームでは、ユーザー ID がバケット パーティションのキーとして指定されます。データをバケット化することで、次のような最適化効果が得られます。

● シングルポイントクエリでは、バケットキーを使用して迅速にフィルタリングし、高速インデックスを実装できるため、読み取るデータ量を削減できます。

● データのシャッフルを回避するために、バケット化を通じて集計および複数テーブル結合クエリのパフォーマンスを最適化します。

データをバケットに分割することで、タスクのスケジュール時にバケットとノード間のマッピング関係をバケット単位で柔軟にスケジュールすることができ、弾力的な拡張と縮小の基盤を提供します。

REDck バケット概略図

2.7 分散トランザクション

オブジェクト ストレージの最適化、キャッシュ戦略の追加、分散タスク スケジューリングの追加、Bucket の概念の導入など、一連の最適化対策を経て、REDck の基本的な使用は比較的安定しました。しかし、大規模にクラスターを展開した後、Hive/Spark から ClickHouse にデータをインポートするときに、トランザクション メカニズムがサポートされていないために重複データが書き込まれることがよくあることがわかりました。これは、オープンソースの ClickHouse 自体に成熟したトランザクション メカニズムが欠けているためであり、多くのユーザーから常に批判されてきました。 ClickHouse にはトランザクション メカニズムがありますが、スタンドアロン モードにのみ適用され、展開する分散クラスターには適用できません。したがって、REDck の Exactly-Once 機能を実現し、データインポート時の障害やデータの不整合を減らし、システム派生物の安定性を向上させることで、もたらされるメリットは相当なものです。

統合メタデータセンターをベースに、データ取り込み時のトランザクション管理を行うREDckトランザクションメカニズムを実装し、メタストアロールを通じてグローバルデータの可視性を一元管理することで、2フェーズトランザクションコミット機能を実現しました。この改善により、データ書き込みの一貫性と信頼性が確保され、重複データの生成を回避できます。

REDck 2フェーズコミット

REDck の 2 フェーズ コミットを実装した後、さらに Flink のチェックポイント メカニズムに接続して、 Flink -> REDck データ リンクの Exactly-Once セマンティクスを実装し、データ処理の精度と信頼性を向上させました。

2.8 オフライン同期リンクの最適化

オフライン データの取り込みに関しては、元の Flink の小バッチ インポート方法の代わりに Spark オフライン インポートを使用することで、インポート リンクの複雑さが軽減され、派生物の効率が向上し、追加の圧縮作業によって発生する書き込み増幅の問題が排除されます。同時に、このオフライン インポート方法は、挿入上書きセマンティクスを自然にサポートし、ユーザーはインポートされるデータを読み取ることがないため、より優れたクエリ エクスペリエンスが提供されます。

3. 着陸効果

REDckは2年以上の開発期間を経て本格的に始動し、企業広告、電子商取引、ライブストリーミングなど多方面で10以上の事業ラインをカバーし、目覚ましい成果を上げています。

●コスト削減:ストレージとコンピューティングの分離により、実験プラットフォーム クラスターのリソース制限の問題が解決されました。変換前は、クラスターのストレージ容量は TB レベルしかありませんでした。変換後は、理論的には無制限にデータを保存できます。実際、 PB レベルのデータを保存します。最大のコンピューティング グループは10,000 コアの規模を持ち、単一クラスターの最大ストレージ容量は10PBです。さらに、ユーザーのクエリ期間の範囲も数か月から数年に増加しました。オリジナルの ClickHouse と比較すると、REDck が CPU ごとに処理できるデータ量は10 倍に増加し、CPU リソースの無駄が大幅に削減されました。同時に、ストレージとコンピューティングを分離したアーキテクチャに基づいて、マルチコピーメカニズムによってもたらされるコスト圧力を軽減し、単位ストレージコストを最大10倍削減します。

●効率性の向上:書き込みパフォーマンスに関しては、Spark を使用してオフライン リンクを完全に変換することで、オフライン インポートのパフォーマンスが2 倍になりました。クエリパフォーマンスの面では、分散メタデータサービスと低速なオブジェクトストレージの導入にもかかわらず、REDck はオブジェクトストレージの読み取り最適化、マルチレベルキャッシュ、予熱などの技術的手段を通じて単一マシンのクエリパフォーマンスを最適化し、そのクエリパフォーマンスはネイティブ ClickHouse に匹敵します。同時に、ストレージとコンピューティングの分離により、弾力的な拡張が可能になり、ビジネスのピーク時には分単位で動的な容量拡張を実行できます。ユーザーは、ピーク時のクエリの混雑を心配する必要がなくなりました。

●高可用性:ネイティブ ClickHouse の冗長で管理が難しいマルチコピー モードを廃止し、REDck はオブジェクト ストレージに依存し、さまざまな最適化方法を使用してデータの信頼性を実現します。   99.9% 。ストレージとコンピューティングの分離を実現した後、データはクラウドに保存されます。単一ノードの障害はクラスター全体の正常な実行には影響せず、全体的な可用性は99.9%に達します。

●スケーラビリティ: REDck のクラウドネイティブ機能により、クラスター拡張の運用および保守の負担が大幅に軽減され、クラスター拡張にかかる時間が数週間から数分に短縮されます。これは、統一されたメタデータ サービスによって Zookeeper の明らかな集中型のボトルネックが解消され、仮想倉庫が無制限に水平に拡張されてさまざまなビジネスの環境展開がサポートされ、仮想倉庫ノードがオンデマンドで垂直に拡張されてストレス耐性が強化され、負荷分散が実現されるためです。現在、最大の仮想倉庫は  100以上 ノードスケール。さらに、REDck は統合テーブル エンジンを使用して、分散テーブル、Zookeeper、レプリカなどの概念をユーザーに意識させないため、運用と保守の管理がより便利になります。

4. 著者情報

白樺

Xiaohongshu のデータ プラットフォーム部門の OLAP R&D エキスパート。Xiaohongshu の OLAP のアーキテクチャと R&D 作業を担当し、主にクラウド ネイティブのリアルタイム データ ウェアハウスとレイク ウェアハウスの統合の R&D と実装を行っています。彼は OLAP のアーキテクチャと実践に関して豊富な経験を持っています。

ポンボ

Xiaohongshu データ プラットフォーム部門の LakeHouse チームの責任者であり、OLAP とデータ レイクを担当しています。

ブロンズビアード

Xiaohongshu データ プラットフォーム部門 OLAP R&D。主に REDck の R&D と実装を含む Xiaohongshu OLAP R&D 業務を担当しています。