データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

I.はじめに

ソフトウェア開発で最もよく知られている用語「アーキテクチャ」は、プロジェクト全体から最小の機能コンポーネントに至るまで、日々の開発作業を通じて使用されますが、高性能、高スケーラビリティ、高可用性という目標を達成するには、優秀な人材の支援が必要です。そこで私は、市場に出回っている古典的で優れたオープンソースプロジェクトを分析し、優れたアーキテクチャコンセプトを学び、アーキテクチャ設計における経験と考え方を蓄積し、同じ問題に遭遇したときにより深く理解できるようにするために、アーキテクチャに関する一連の記事を書こうとしました。その後の日常業務での問題点を知ってください。

この章では、リアルタイム OALP エンジン Clickhouse (略して ck) を例として、そのシナリオ指向のアーキテクチャ設計、詳細な実装などを紹介し、それがどのようにしてパフォーマンスの王様になったのかを深く理解します。 OLAP エンジン。

2. クリックハウスの紹介

Clickhouse は、2016 年にロシアの Yandex (ロシアで最もインターネットユーザー数が多い Web サイト) によってオープンソース化されたオンライン分析 (OLAP) 用の列型データベース管理システムです。C++ 言語で書かれており、主にオンライン分析とクエリの処理に使用されます。 SQL クエリを通じてリアルタイムで生成され、データレポートを分析します。

主なシナリオは、あらゆる指標とあらゆるディメンションを迅速にサポートし、大規模なデータレベルで第 2 レベルのフィードバックを実現できるアドホッククエリ (アドホッククエリ) です。

3. クリックハウスアーキテクチャの原則

Clickhouse は優れたパフォーマンスで知られており、関連するパフォーマンス比較レポートでは、ck の単一テーブル SQL クエリのパフォーマンスは、presto の 2.3 倍、impala の 3 倍、greenplum の 7 倍、hive の 48 倍となっています。単一テーブル SQL クエリにおける ck のパフォーマンスは、presto の 2.3 倍、impala の 3 倍、greenplum の 7 倍、hive の 48 倍であることがわかります。単一テーブルクエリは非常に優れています。では、ck はどのようにして効率的なクエリを実現するのでしょうか。クエリ？

1. はじめに

ck クエリの原理を紹介する前に、最も一般的な mysql を例として、単純なクエリステートメントがどのように実行されるかを考えてから、ck アーキテクトの観点から ck がどのように最適化されるべきかを考えてみましょう。mysql がデータをクエリするとき、最初にディスクからデータを読み取ります。ページ (innodb ストレージユニット) はメモリに保存され、クエリ結果はメモリから返されます。したがって、私たちの理解では、SQL クエリ (文法や字句解析などのステップを除く)最適化など）をまとめると以下の2点になります。

ディスクからメモリにデータを読み取る
メモリ内で一致するデータを解析して結果を返す

最近のコンピュータでは、CPU が計算に費やす時間は、ディスク IO に費やす時間よりもはるかに短いです。したがって、ほとんどの最新の OLAP エンジンは、ディスク IO を削減することによってクエリのパフォーマンスを向上させることも選択します。次に例を示します。

ディスク IO を削減する	原理	例	列の種類
配布された	データを並列に読み取り、単一ノードによって読み取られるデータ量を削減します。	ハイブ(テックスファイル)	データの偏り、ネットワーク時間の浪費、リソースの浪費
カラムストレージ	各列を個別に保存し、オンデマンドで読み取る	hbase	単一ビジネスを使用する列に適しています

2. アーキテクチャ

上記の導出と分析を通じて、OLAP クエリのボトルネックはディスク IO にあると結論付けることができます。そのため、CK の最適化手法も上記の対策を活用し、MPP アーキテクチャ (大規模並列処理) + カラム型ストレージ、および同様の機能を備えた他のデータベース製品を使用します。 ck のパフォーマンスはなぜこれほど優れているのでしょうか? 次に、ck の核となる機能を詳細に分析し、ck アーキテクトの独創的な建築コンセプトをさらに理解していきます。

2.1 カラムの保管

行ストレージ: 同じ行のデータを同じデータブロックに配置し、各データブロック間でデータを連続的に保存します。

列ストレージ: 同じデータ列を同じデータブロックに配置し、異なる列を個別に保存できます。

上で述べたように、分析クエリでは多くの場合、テーブル内のいくつかのフィールドのみが必要です。列ストアはユーザーがクエリした列を読み取るだけで済みますが、行ストアは各レコードを読み取るときにすべての列データを読み取ります。 IO では Row-Store よりもはるかに効率的であるため、パフォーマンスが向上します。

2.2ブロック

Clickhouse が処理できる最小単位はブロックです。ブロックは行のコレクションです。デフォルトの最大値は 8192 行です。各列は個別に保存されるため、各データファイルは行ベースのストレージよりも規則的です。LZ4 圧縮を使用することにより、ブロックのアルゴリズムを適用すると、全体の圧縮率は約 8:1 になります。クリックハウスは優れた圧縮率とブロック構造によりバッチ処理機能を実現しています。大量のデータを一度に 1 行ずつ処理する状況と比較すると、クリックハウスはバッチ処理機能を実現しています。ストレージの IO 数が大幅に削減され、ストレージエンジンの最適化が実現されました。

2.3 LSM

LSM の考え方: データへの増分変更はメモリに保持されます。指定された制限に達した後、これらの変更操作はバッチでディスクに書き込まれます。書き込み操作の高いパフォーマンスと比較して、読み取りはマージする必要がありますメモリ内で最近変更されたデータ。ディスク上の履歴データを操作するには、まずメモリ上にデータがあるかどうかを確認する必要があります。ヒットしない場合は、ディスクファイルにアクセスする必要があります。

LSM の原理: 大きなツリーを N 個の小さなツリーに分割します。データは最初にメモリに書き込まれます。小さなツリーが大きくなるにつれて、メモリ内の小さなツリーはディスクにフラッシュされます。ディスク内のツリーは定期的にマージされて 1 つの大きなツリーを形成し、読み取りパフォーマンスを最適化します。

Clickhouse は、LSM を介してデータの事前ソートを実装し、それによりディスク読み取り量を削減します。原理は、LSM を介して順序が崩れたデータをソートし、ストレージ用にディスクに書き込み、重複するディスクファイルを定期的にマージすることです。は次の点に要約できます。

データのすべてのバッチが書き込まれ、高可用性メカニズムを確保するために最初にログが記録されます。
ログを記録した後、ソートのためにメモリに保存し、ソート結果をディスクに書き込み、マージ数を記録します。 Level=0
ディスク上のレベル = 0 または 1 のファイルを定期的にマージし、削除対象としてマークします。その後の物理的な削除

2.4 索引

Clickhouse は、プライマリインデックス (スパースインデックス) + セカンダリインデックス (ホップインデックス) を使用してインデックスデータの位置決めとクエリを実行します。プライマリインデックスは各ブロックの最初を記録し、インデックスフィールドに基づく各クエリはクエリの数を決定するだけで済みます。 1 つのクエリですべてのデータを走査することを回避するには、ブロックだけで十分です。上で述べたように、ブロックには 8192 行があるため、1 億個のデータには 10,000 行のインデックスのみが必要となるため、第 1 レベルのインデックスが占有するストレージは少なくなり、常駐メモリによりクエリが高速化されますセカンダリインデックスはデータの集約情報から構築されますインデックスの種類に応じて、集約情報の内容も異なりますホップインデックスの目的はプライマリインデックスの目的と同じです範囲と原則はすべて「除外方法」であり、条件を確実に満たさないインデックス粒度を可能な限り除外します。

一方、ck ストレージエンジンは順序付きセットに格納するため、インデックス構造での位置決めに B+ ツリーソート機能を使用する必要がないことがわかり、実際の使用では次の条件を満たす必要はありません。フィルタ条件にインデックス列が含まれている限り、左端の原則一致。

2.5 ベクトル化された実行

ベクトル化 (ベクトル化) は、ベクトル化操作とも呼ばれ、配列プログラミングとも呼ばれます。その目的は 1 つであり、複数の for ループ計算を 1 つの計算に変換することです。ベクトル化された実行を実現するには、CPU の SIMD 命令を利用する必要があります。SIMD の正式名称は Single structive Multiple Data で、単一の命令を使用して複数のデータを操作することを意味します。現代のコンピュータシステムの概念では、データの並列処理 (他に命令レベルの並列処理やスレッドレベルの並列処理など) によってパフォーマンスを向上させる方法であり、その原理は、CPU レジスタレベルでデータに対する並列演算を実装することです。

コンピュータシステムのアーキテクチャでは、ストレージシステムは階層構造です。一般的なサーバーコンピューターのストレージ階層を図 1 に示します。実際の経験から、記憶媒体が CPU に近づくほど、データへのアクセスが速くなります。

左から右へ、CPU から離れるほど、データアクセス速度は遅くなります。レジスタからのデータへのアクセス速度は、メモリからのデータへのアクセスの 300 倍、ディスクからのデータへのアクセスの 3,000 万倍です。したがって、CPU のベクトル化実行の特性を利用することは、プログラムのパフォーマンスを向上させる上で非常に重要です。ClickHouse は現在、SSE4.2 命令セットを利用してベクトル化された実行を実装しています。

4. クリックハウスの概要

1. クリックハウスのギブアンドテイク

クリックハウスは、上記のカラムストレージ、バッチ処理、プレソートなど、究極のパフォーマンスを追求する優れた設計を数多く採用していますが、そのアーキテクチャには両面があり、欠点もいくつかあります。

高頻度のリアルタイム書き込みに関しては、ck はバッチデータを小さなファイルに直接書き込むため、高頻度の書き込みにより多数の小さなファイルが生成およびマージされ、クエリのパフォーマンスに影響を及ぼします。書き込みパフォーマンスを向上させるための大規模で低頻度の書き込み実際のシナリオでは、バッチ書き込みを実現するために、ビジネスとデータベースの間にデータキャッシュレイヤーを導入することをお勧めします。
クエリの同時実行の問題に関しては、Clickhouse は並列処理メカニズムを使用しています。つまり、クエリの実行に CPU の半分が使用されます。インストール中に CPU コアの数が自動的に識別されます。そのため、クエリの高速性を活用しながら、同時実行機能の欠如を引き起こします。クエリが蓄積しすぎて max_concurrent_queries しきい値に達すると、同時クエリが多すぎる例外が報告されます。これは ck の現在の制限保護メカニズムでもあります。したがって、遅い SQL のトラブルシューティングに注意してください日常使用中に同時リクエストを制御することは、高可用性の鍵となります。

原理を理解すると、クリックハウスについての理解が深まり、制作現場で遭遇した問題点も説明でき、クリックハウスアーキテクトの観点から合理的に利用し、デメリットを回避し、その特性を最大限に発揮することができます。。

2. クリックハウスの実運用で発生する問題点

2.1 飼育員への高負荷の影響

現在、ReplicatedMergeTree エンジンのクリックハウスオープンソースバージョンは、マルチコピーマスター選択、データ同期、障害回復などの機能を完了するために Zookeeper に大きく依存しています。Zookeeper は高負荷条件下ではパフォーマンスが低下し、障害などの問題を引き起こす可能性もあります。コピーの書き込みとデータの同期の失敗。コピーレプリケーションプロセスを例として、Clickhouse による ZooKeeper の使用を分析します。CK による ZooKeeper へのログの頻繁な配布とデータ交換がボトルネックの原因の 1 つです。

一般的な解決策:

JD Retail: Raft 分散コンセンサスアルゴリズムに基づいて独自に開発した動物園飼育員の代替品。

2.2 リソースの管理と制御の問題

ClickHouse のリソース管理および制御機能は十分に完璧ではないため、挿入および選択の同時実行性が高いシナリオでは実行エラーが発生し、ユーザーエクスペリエンスに影響を与える可能性があります。これは、ClickHouse のコミュニティバージョンでは現在、さまざまなユーザーに基づいた最大メモリ制御のみが提供されており、しきい値を超えると実行されたクエリが強制終了されるためです。

Analysys パフォーマンスの比較: https://zhuanlan.zhihu.com/p/54907288

公式サイト性能比較： https: //clickhouse.com/

著者: Jingdong Technology Li Danfeng

出典：JD Cloud Developer Community 転載の際は出典を明記してください

アーキテクチャ探索への道 - 最初のストップ - クリックハウス | JD Cloud テクニカルチーム

I.はじめに

2. クリックハウスの紹介