実際のアプリケーションで ClickHouse を使用する理論と実践。 アレクサンダー・ザイツェフ (2018)

現在、ほとんどどこにでも大量のデータがあるにもかかわらず、分析データベースは依然として非常に珍しいものです。 それらはあまり知られておらず、さらに効果的に使用することもできません。 多くの人は、他のシナリオ向けに設計された MySQL や PostgreSQL を使って「サボテンを食べ」続け、NoSQL に悩まされたり、商用ソリューションに過剰なお金を払ったりしています。 ClickHouse はゲームのルールを変え、分析 DBMS の世界に入る敷居を大幅に下げます。

BackEnd Conf 2018 のレポートであり、講演者の許可を得て掲載しています。

私は何者で、なぜ ClickHouse について話しているのですか? 私は、ClickHouse を使用している LifeStreet の開発ディレクターです。 また、私は Altinity の創設者でもあります。 これは、ClickHouse を推進し、Yandex が ClickHouse をさらに成功させるのを支援する Yandex パートナーです。 ClickHouse に関する知識を共有する準備もできています。

そして私はペティア・ザイツェフの兄弟ではありません。 このことについてよく質問されます。 いいえ、私たちは兄弟ではありません。

「誰もが知っている」ClickHouse は次のとおりです。

• とても早い、
• とても快適
• Yandex で使用されます。

どの企業でどのように使用されているかは、あまり知られていません。

Yandex を除いて、ClickHouse がなぜ、どこで、どのように使用されるのかを説明します。

さまざまな企業で ClickHouse を利用して特定のタスクがどのように解決されているか、タスクに使用できる ClickHouse ツール、およびそれらがさまざまな企業でどのように使用されているかについて説明します。

ClickHouseをさまざまな角度から紹介するXNUMXつの事例をピックアップしました。 面白いと思いますよ。

最初の質問は、「なぜ ClickHouse が必要なのか?」です。 かなり明白な質問のように思えますが、これに対する答えは複数あります。

• 最初の答えはパフォーマンスに関するものです。 ClickHouseは非常に高速です。 ClickHouse の分析も非常に高速です。 他の何かが非常に遅い、または非常に悪い場合によく使用されます。
• XNUMX 番目の答えはコストです。 そしてまず第一に、スケーリングのコストです。 たとえば、Vertica は非常に優れたデータベースです。 テラバイト単位のデータがあまりない場合には、非常にうまく機能します。 しかし、数百テラバイトやペタバイトとなると、ライセンスとサポートのコストはかなりの額になります。 そして高価です。 そしてClickHouseは無料です。
• XNUMX 番目の答えは、運用コストです。 これは少し異なるアプローチです。 RedShift は優れたアナログです。 RedShift では、非常に迅速に決定を下すことができます。 これはうまく機能しますが、同時に、これは非常に高価なサービスであるため、毎時間、毎日、毎月、Amazon に多額の料金を支払うことになります。 Google BigQueryも。 誰かがそれを使用した場合、そこでいくつかのリクエストを実行すると、突然数百ドルの請求書が届く可能性があることがわかります。

ClickHouse にはこれらの問題はありません。

ClickHouse は現在どこで使用されていますか? Yandex に加えて、ClickHouse はさまざまなビジネスや企業で使用されています。

• まず第一に、これは Web アプリケーション分析です。つまり、これは Yandex から来たユースケースです。
• 多くのアドテック企業が ClickHouse を使用しています。
• さまざまなソースからのトランザクション ログを分析する必要がある多くの企業。
• いくつかの企業が ClickHouse を使用してセキュリティ ログを監視しています。 それらを ClickHouse にアップロードし、レポートを作成し、必要な結果を取得します。
• 企業は財務分析にそれを使用し始めており、徐々に大企業もClickHouseにアプローチしています。
• クラウドフレア。 ClickHouse をフォローしている人なら、おそらくこの会社の名前を聞いたことがあるでしょう。 これはコミュニティからの重要な貢献者の XNUMX 人です。 そして、彼らは非常に本格的なClickHouseをインストールしています。 たとえば、彼らは ClickHouse 用の Kafka エンジンを作成しました。
• 通信会社も使い始めた。 いくつかの企業が、ClickHouse を概念実証として、またはすでに運用中として使用しています。
• ある企業では、ClickHouse を使用して生産プロセスを監視しています。 彼らは超小型回路をテストし、大量のパラメータを書き留めます。約 2 の特性があります。 そして、ゲームが良いか悪いかを分析します。
• ブロックチェーン分析。 Bloxy.info というロシアの会社があります。 これはイーサリアムネットワークの分析です。 彼らはClickHouseでもこれを行いました。

そして、サイズは関係ありません。 XNUMX 台の小規模サーバーを使用している企業は数多くあります。 そして彼は彼らが問題を解決できるようにします。 そして、多くのサーバーまたは数十台のサーバーからなる大規模なクラスターを使用する企業はさらに多くなっています。

そして記録を見ると、次のようになります。

• Yandex: 500 台以上のサーバーがあり、25 日あたり XNUMX 億件のレコードが保存されています。
• LifeStreet: サーバー 60 台、75 日あたり約 XNUMX 億レコード。 Yandex よりもサーバーの数が少なく、レコードの数が多くなります。
• CloudFlare: 36 台のサーバーで、200 日あたり XNUMX 億件のレコードが保存されます。 サーバーの数はさらに少なくなり、さらに多くのデータが保存されます。
• ブルームバーグ: サーバー 102 台、XNUMX 日あたり約 XNUMX 兆件のエントリ。 記録保持者。

地理的にもこれはたくさんあります。 このマップは、ClickHouse が世界中で使用されている場所のヒートマップを示しています。 ここではロシア、中国、アメリカがはっきりと際立っています。 ヨーロッパの国はほとんどありません。 そしてクラスターは4つあります。

これは比較分析であり、絶対的な数字を探す必要はありません。 これは、Altinity の Web サイトにはロシア語を話す人がいないため、英語の資料を読んだ訪問者の分析です。 そして、ロシア、ウクライナ、ベラルーシ、つまりコミュニティのロシア語を話す地域が最も多くのユーザーを占めています。 次にアメリカとカナダが続きます。 中国は非常に追いついています。 半年前にはそこには中国はほとんど存在しなかったが、今では中国はすでにヨーロッパを追い越し、成長を続けている。 古いヨーロッパもそれに遠く及ばず、奇妙なことに、ClickHouse の使用のリーダーはフランスです。

なぜ私がこんなことを話しているのでしょうか？ ClickHouse がビッグデータ分析の標準ソリューションになりつつあり、すでに多くの場所で使用されていることを示すため。 それを使えば、あなたは正しい傾向にいます。 まだ使用していない場合は、多くの人がすでにこれを使用しているため、孤立して誰も助けてくれないことを恐れる必要はありません。

これらは、いくつかの企業で実際に ClickHouse が使用されている例です。

• 最初の例は広告ネットワークです。Vertica から ClickHouse への移行です。 そして、私は Vertica から移行した、または移行途中の企業を数社知っています。
• XNUMX 番目の例は、ClickHouse のトランザクション ストレージです。 これはアンチパターンに基づいて構築された例です。 開発者のアドバイスに従って ClickHouse で実行すべきでないことはすべて、ここで実行されます。 そしてそれは非常に効果的に行われているので、うまくいきます。 そして、それは典型的なトランザクションソリューションよりもはるかにうまく機能します。
• XNUMX 番目の例は、ClickHouse での分散コンピューティングです。 ClickHouse を Hadoop エコシステムにどのように統合できるかについての質問がありました。 非常に重要なタスクを計算するために、ある企業が ClickHouse のマップ リデュース コンテナーと同様のことを実行し、データのローカリゼーションを追跡するなどの方法を実行した例を示します。

• LifeStreet は、広告ネットワークに付随するあらゆるテクノロジーを備えたアドテク企業です。
• 彼女は広告の最適化、プログラマティック入札に従事しています。
• 大量のデータ: 10 日あたり約 XNUMX 億のイベント。 同時に、そこでのイベントはいくつかのサブイベントに分割できます。
• このデータのクライアントは数多くありますが、それらは人間だけではなく、さらに多くの、プログラマティック入札に関与するさまざまなアルゴリズムです。

同社は長く険しい道を歩んできた。 そして私はそれについてHighLoadで話しました。 まず、LifeStreet は MySQL (Oracle に少し立ち寄りました) から Vertica に移行しました。 そして、それに関する物語を見つけることができます。

すべては非常に良好でしたが、データが増大し続けており、Vertica が高価であることがすぐに明らかになりました。 したがって、さまざまな代替案が模索されました。 そのうちのいくつかをここにリストします。 そして実際、私たちは 13 年目から 16 年目に市場で入手可能で、機能の点でほぼ適切だったほぼすべてのデータベースの概念実証、または場合によってはパフォーマンス テストを行いました。 そして、それらのいくつかについては HighLoad でも話しました。

データが増大したため、そもそもの課題は Vertica から移行することでした。 そして、それらは長年にわたって飛躍的に成長しました。 その後、それらは棚に置かれましたが、それでもなおです。 そして、この成長を予測し、ある種の分析を行う必要があるデータ量のビジネス要件を予測すると、すぐにペタバイトについて議論されることは明らかでした。 また、ペタバイトの料金を支払うのはすでに非常に高価であるため、代わりの場所を探していました。

どこへ行く？ そして、一方では商用データベースがあり、それらはうまく機能しているように見えるため、長い間、どこに行くべきかまったく明確ではありませんでした。 Vertica とほぼ同じように動作するものもあれば、それより劣るものもあります。 しかし、どれも高価で、これより安くて良いものは見つかりませんでした。

一方で、オープンソース ソリューションもありますが、その数はそれほど多くありません。つまり、分析に関しては指で数えられる程度です。 そして、それらは無料または安価ですが、遅いです。 そして、必要な便利な機能が欠けていることもよくあります。

そして、商用データベースにある良いものと、オープンソースにあるすべての無料のものを組み合わせるものは何もありませんでした。

予想外に、Yandex が帽子をかぶった魔術師のように、ウサギのように ClickHouse を引き出すまでは何もありませんでした。 そしてそれは予期せぬ決断だったので、彼らは今でも「なぜ？」という疑問を抱いていますが、それでもなおです。

そして 2016 年の夏にすぐに、私たちは ClickHouse とは何なのかを検討し始めました。 そして、場合によっては Vertica よりも高速な場合があることが判明しました。 さまざまなクエリでさまざまなシナリオをテストしました。 また、クエリでテーブルが XNUMX つだけ使用された場合、つまり結合 (結合) がなかった場合、ClickHouse は Vertica の XNUMX 倍高速でした。

先日、あまりにも怠惰ではなかったので、Yandexのテストを調べました。 それは同じです。ClickHouse は Vertica の XNUMX 倍速いので、彼らはそれについてよく話題にします。

しかし、クエリに結合がある場合、すべてが明確ではないことがわかります。 また、ClickHouse は Vertica の XNUMX 倍遅くなる可能性があります。 そして、リクエストを少し修正して書き直すと、それらはほぼ同等になります。 悪くない。 しかも無料。

そしてテスト結果を受け取り、それをさまざまな角度から検討した後、LifeStreet は ClickHouse に行きました。

気がつけば今年で16年目です。 それは、泣き叫んで自分自身を刺しながらもサボテンを食べ続けるネズミについての冗談のようでした。 これについては詳しく説明されており、これに関するビデオもあります。

したがって、詳細については話しません。結果と、その時は話さなかったいくつかの興味深い点についてのみ話します。

結果は次のとおりです。

• 移行が成功し、XNUMX 年以上にわたってシステムはすでに実稼働環境で稼働しています。
• 生産性と柔軟性が向上しました。 10 日あたり短期間保存できる 75 億件のレコードのうち、LifeStreet は現在 3 日あたり XNUMX 億件のレコードを保存しており、これを XNUMX か月以上保存できます。 ピーク時にカウントすると、XNUMX 秒あたり最大 XNUMX 万件のイベントが発生します。 XNUMX 日に XNUMX 万件を超える SQL クエリがこのシステムに届きますが、そのほとんどはさまざまなロボットからのものです。
• Vertica よりも ClickHouse に多くのサーバーが使用されたという事実にもかかわらず、Vertica ではかなり高価な SAS ディスクが使用されていたため、ハードウェアも節約されました。 ClickHouseはSATAを使用していました。 なぜ？ Vertica では挿入が同期的であるためです。 また、同期には、ディスクの速度が低下しすぎないこと、およびネットワークの速度が低下しすぎないことが必要であり、かなりコストのかかる操作になります。 また、ClickHouse では挿入は非同期です。 さらに、いつでもすべてをローカルに書き込むことができ、追加コストはかかりません。そのため、低速ドライブであっても、Vertika よりもはるかに速くデータを ClickHouse に挿入できます。 そして読書もほぼ同じです。 SATA での読み取りは、RAID 内であれば、すべて十分に高速です。
• ライセンスによる制限はありません。つまり、3 台のサーバー (60 台のサーバーが 20 つのレプリカ) にある 6 ペタバイトのデータと、ファクトと集計の XNUMX 兆件のレコードです。 Vertica ではこのようなものはありません。

次に、この例の実践的な内容に移ります。

• XNUMXつ目は効率的なスキームです。 多くはスキーマに依存します。
• XNUMX つ目は効率的な SQL 生成です。

典型的な OLAP クエリは選択です。 一部の列はグループ化に使用され、一部の列は集計関数に使用されます。 立方体のスライスとして表現できる場所があります。 グループ全体は投影として考えることができます。 それが多変量データ分析と呼ばれる理由です。

そして多くの場合、これはスタースキームの形でモデル化されます。その場合、中心的な事実と、側面や光線に沿ったこの事実の特徴があります。

そして、物理的なデザイン、つまりテーブルにどのようにフィットするかという点では、通常は正規化された表現が行われます。 非正規化することもできますが、ディスクに負荷がかかり、クエリではあまり効率的ではありません。 したがって、通常、それらは正規化された表現、つまりファクト テーブルと非常に多くのディメンション テーブルを作成します。

しかし、ClickHouseではうまく機能しません。 理由は XNUMX つあります。

• XNUMX つ目は、ClickHouse の結合があまり優れていないためです。つまり、結合はありますが、悪いものです。 悪いながらも。
• XNUMX つ目は、テーブルが更新されないことです。 通常、スター回路の周囲にあるこれらのプレートでは、何かを変更する必要があります。 たとえば、顧客名、会社名などです。 そしてそれは機能しません。

そして、ClickHouseにはこれを解決する方法があります。 XNUMXつでも:

• 一つ目は辞書の活用です。 外部辞書は、アップデートなどにより、スター スキーマの問題を 99% 解決するのに役立ちます。
• XNUMX つ目は配列の使用です。 配列は、結合や正規化の問題を取り除くのにも役立ちます。

• 参加する必要はありません。
• アップグレード可能。 2018 年 XNUMX 月以降、辞書を部分的に更新する、つまり変更されたエントリを更新する文書化されていない機会が出現しました (これは文書には見つかりません)。 実際にはテーブルのようなものです。
• 常にメモリ内にあるため、ディクショナリとの結合は、テーブルがディスク上にある場合よりも高速に動作しますが、キャッシュ内に存在することはまだ事実ではありません。おそらくそうではありません。

• 結合も必要ありません。
• これはコンパクトな 1 対多の表現です。
• 私の意見では、配列はオタク向けに作られています。 これらはラムダ関数などです。

これは赤文字用ではありません。 これは非常に強力な機能であり、多くのことを非常にシンプルかつエレガントな方法で行うことができます。

配列を解くのに役立つ典型的な例。 これらの例は単純かつ明確です。

• タグから検索します。 そこにハッシュタグがあり、ハッシュタグでいくつかの投稿を見つけたい場合。
• キーと値のペアで検索します。 値を持つ属性もいくつかあります。
• 別のものに変換する必要があるキーのリストを保存します。

これらすべてのタスクは配列なしで解決できます。 タグは行に入れて正規表現または別のテーブルで選択できますが、その場合は結合を行う必要があります。

ClickHouse では、何もする必要はありません。ハッシュタグの文字列配列を記述したり、キーと値のシステムの入れ子構造を作成したりするだけで十分です。

ネストされた構造は最適な名前ではない可能性があります。 これらは、名前に共通部分といくつかの関連する特性を持つ XNUMX つの配列です。

タグ検索も簡単です。 機能がある has、配列に要素が含まれていることを確認します。 皆さん、私たちのカンファレンスに関連するすべてのエントリを見つけました。

subid による検索は少し複雑です。 まずキーのインデックスを見つけてから、このインデックスを持つ要素を取得して、この値が必要なものであることを確認する必要があります。 ただし、非常にシンプルでコンパクトです。

正規表現を XNUMX 行にまとめて書くと、まず、不格好になります。 そして第二に、XNUMX つのアレイよりもはるかに長く動作しました。

もう一つの例。 ID を保存する配列があります。 そして、それらを名前に変換することができます。 関数 arrayMap。 これは典型的なラムダ関数です。 そこにラムダ式を渡します。 そして、各 ID の名前の値を辞書から取り出します。

検索も同様に行えます。 要素が一致するものをチェックする述語関数が渡されます。

これらにより回路が大幅に簡素化され、多くの問題が解決されます。

しかし、私たちが直面している次の問題は、効率的なクエリーであることについて触れておきたいと思います。

• ClickHouse にはクエリ プランナーがありません。 絶対違う。
• それでも、複雑なクエリを計画する必要があります。 どのような場合に？
• クエリ内に複数の結合がある場合は、それらを副選択でラップします。 そして、それらが実行される順序が重要です。
• そして XNUMX つ目は、リクエストが分散された場合です。 分散クエリでは、最も内側のサブ選択のみが分散実行され、その他はすべて接続した XNUMX つのサーバーに渡され、そこで実行されるためです。 したがって、多数の結合 (結合) を含む分散クエリがある場合は、順序を選択する必要があります。

また、より単純な場合でも、スケジューラの作業を実行してクエリを少し書き直す必要がある場合もあります。

ここに一例を示します。 左側には、上位 5 か国を示すクエリがあります。 私の意見では、それには 2,5 秒かかります。 右側は同じクエリですが、少し書き直されています。 文字列でグループ化する代わりに、キー (int) でグループ化するようになりました。 そしてそれはより速いです。 そして、その結果に辞書を接続しました。 リクエストには 2,5 秒ではなく 1,5 秒かかります。 これはいい。

フィルタを書き換える同様の例。 これはロシアへの要望です。 5秒間実行されます。 文字列ではなく数値を、ロシアに関連するキーのセットと再度比較するように書き直すと、はるかに高速になります。

このようなトリックはたくさんあります。 また、すでに高速に実行されていると思われるクエリや、逆に低速に実行されていると思われるクエリを大幅に高速化することができます。 さらに高速に作成することもできます。

• 分散モードでの最大作業量。
• int で行ったように、最小型で並べ替えます。
• 結合 (ジョイン) やディクショナリがある場合は、最後の手段としてそれらを実行することをお勧めします。既にデータが少なくとも部分的にグループ化されている場合、結合操作またはディクショナリ呼び出しの呼び出し回数が減り、処理が高速になります。 。
• フィルターの交換。

私が紹介したテクニックだけではなく、他にもテクニックがあります。 そしてそれらはすべて、クエリの実行を大幅に高速化できる場合があります。

次の例に進みましょう。 アメリカのX社。 彼女は何をやっている？

タスクがありました:

• 広告トランザクションのオフラインリンク。
• さまざまなバインディング モデルをモデリングします。

シナリオは何ですか?

普通の訪問者は、たとえば、さまざまな広告から月に 20 回サイトにアクセスします。あるいは、このサイトのことを覚えているため、広告なしで訪問することもあります。 いくつかの商品を見て、カゴに入れたり、カゴから取り出したりします。 そして最終的には何かが買われます。

もっともな質問: 「必要な場合、広告費は誰が支払うべきですか?」 「彼に影響を与えた広告があれば?」 つまり、なぜ彼は買ったのか、そしてこの人のような人々にも買ってもらうにはどうすればよいのかということです。

この問題を解決するには、Web サイト上で発生する出来事を適切な方法で結び付ける、つまり、何らかの方法でそれらの間につながりを構築する必要があります。 その後、分析のために DWH に送信されます。 そして、この分析に基づいて、誰にどのような広告を表示するかのモデルを構築します。

広告トランザクションは、広告の表示から始まり、何かが起こり、その後購入が行われ、さらに購入の中で購入が行われる一連の関連ユーザー イベントです。 たとえば、これがモバイル アプリケーションやモバイル ゲームの場合、通常、アプリケーションのインストールは無料で行われますが、そこで何かを行う場合、これにはお金が必要になる場合があります。 そして、ユーザーがアプリケーションに費やすほど、その価値は高まります。 ただし、そのためにはすべてを接続する必要があります。

バインディングモデルも多数あります。

最も人気のあるものは次のとおりです。

• 最後のインタラクション。インタラクションはクリックまたはインプレッションのいずれかです。
• 最初のインタラクション、つまり、ユーザーをサイトに誘導した最初のもの。
• 線形結合 - すべて均等。
• 減衰。
• 等々。

そして、そもそもそれはどのようにして機能したのでしょうか? ランタイムとカサンドラがありました。 Cassandra はトランザクション ストレージとして使用され、関連するすべてのトランザクションが Cassandra に保存されました。 そして、ランタイムで何らかのイベントが発生すると、たとえば、あるページか何かを表示すると、Cassandra に対してリクエストが行われます。そのような人がいるかどうかはわかりません。 次に、それに関連するトランザクションが取得されました。 そしてつながりができました。

幸運にもリクエストにトランザクション ID があれば、それは簡単です。 しかし、通常は運がありません。 そのため、最後のトランザクションやラストクリックのあるトランザクションなどを見つける必要がありました。

そして、バインディングが最後のクリックまで行われている限り、すべて非常にうまく機能しました。 なぜなら、10 か月の期間を設定した場合、たとえば 300 日あたり 10 万回、15 か月あたり XNUMX 億回のクリックがあるからです。 また、Cassandra では高速に実行するにはすべてがメモリ内にある必要があり、ランタイムは迅速に応答する必要があるため、約 XNUMX ～ XNUMX 台のサーバーが必要でした。

そして、トランザクションをディスプレイにリンクさせたいと思ったとき、それはすぐにあまり面白くないことがわかりました。 なぜ？ 30 倍のイベントを保存する必要があることがわかります。 したがって、30 倍のサーバーが必要になります。 そして、これはある種の天文学的な数値であることが判明しました。 実行時のサーバーの数が大幅に少ないにもかかわらず、リンクを行うために最大 500 台のサーバーを維持するということは、ある種の間違った数字です。 そして彼らは何をすべきかを考え始めました。

そして、クリックハウスに行きました。 ClickHouse でそれを行うにはどうすればよいでしょうか? 一見すると、これは一連のアンチパターンであるように見えます。

• トランザクションは成長し、ますます多くのイベントをトランザクションに接続します。つまり、トランザクションは可変であり、ClickHouse は可変オブジェクトではあまりうまく機能しません。
• 訪問者が私たちを訪れたら、キーと訪問 ID によってトランザクションを引き出す必要があります。 これもポイントクエリですが、ClickHouse ではそれを行いません。 通常、ClickHouse には大規模なスキャンがありますが、ここではいくつかのレコードを取得する必要があります。 こちらもアンチパターン。
• さらに、トランザクションは json 形式でしたが、書き換えたくなかったので、json を構造化されていない方法で保存し、必要に応じてそこから何かを取り出したいと考えていました。 そして、これもアンチパターンです。

つまり、一連のアンチパターンです。

しかし、それにもかかわらず、非常にうまく機能するシステムを作ることができました。

何が行われたのでしょうか？ ClickHouse が登場し、ログがレコードに分割されて投げ込まれました。 ClickHouse からログを受信する属性付きサービスが登場しました。 その後、エントリごとに、訪問 ID ごとに、まだ処理されていない可能性のあるトランザクションとスナップショット、つまりすでに接続されているトランザクション、つまり以前の作業の結果を受け取りました。 私はすでにそれらからロジックを作成し、正しいトランザクションを選択し、新しいイベントを接続しました。 再度ログに記録されました。 ログは ClickHouse に戻りました。つまり、ClickHouse は常に循環するシステムです。 さらに、DWH に行って、そこで分析しました。

この形ではあまりうまくいきませんでした。 また、ClickHouse にとって作業を容易にするために、訪問 ID によるリクエストがあった場合、これらのリクエストを 1 ～ 000 の訪問 ID のブロックにグループ化し、2 ～ 000 人のトランザクションをすべて抽出しました。 そして、すべてがうまくいきました。

ClickHouse の中を見ると、これらすべてを提供するメイン テーブルは 3 つだけです。

ログがアップロードされる最初のテーブル。ログはほとんど処理されずにアップロードされます。

XNUMX番目のテーブル。 マテリアライズド ビューを通じて、まだ属性が特定されていないイベント、つまり無関係なイベントがこれらのログから切り出されます。 そして、マテリアライズド ビューを通じて、これらのログからトランザクションが抽出され、スナップショットが作成されました。 つまり、特別なマテリアライズド ビューによってスナップショット、つまりトランザクションの最後に蓄積された状態が構築されました。

SQL で書かれたテキストは次のとおりです。 その中のいくつかの重要な点についてコメントしたいと思います。

まず重要なことは、ClickHouse の json から列とフィールドを抽出できることです。 つまり、ClickHouse には json を操作するためのメソッドがいくつかあります。 とてもとても原始的なものです。

visitParamExtractInt を使用すると、json から属性を抽出できます。つまり、最初のヒットがトリガーされます。 このようにして、トランザクション ID または訪問 ID を取得できます。 この時。

次に、ここでは扱いにくい実体化フィールドが使用されています。 どういう意味ですか？ これは、テーブルにそれを挿入できないことを意味します。つまり、それは挿入されず、挿入時に計算されて保存されます。 貼り付けるときは、ClickHouse が作業を行います。 そして、後で必要になるものはすでに json から抽出されています。

この場合、マテリアライズド ビューは生の行用です。 そして、実質的に生のログを含む最初のテーブルがそのまま使用されます。 そして彼は何をしているのでしょうか？ まず、並べ替えが変更されます。つまり、特定の人のトランザクションをすぐに抽出する必要があるため、並べ替えは訪問 ID によって行われるようになりました。

8 番目に重要なのは、index_granularity です。 MergeTree を見たことがあると思いますが、デフォルトのindex_granularity は通常 192 です。 それは何ですか？ これはインデックスの疎性パラメータです。 ClickHouse ではインデックスはまばらであり、すべてのエントリにインデックスを付けることはありません。 これは 8 192 ごとに行われます。これは、大量のデータを計算する必要がある場合には適していますが、少量の場合はオーバーヘッドが大きいため好ましくありません。 また、インデックスの粒度を小さくすると、オーバーヘッドも削減されます。 メモリが不足している可能性があるため、XNUMX つに減らすことはできません。 インデックスは常にメモリに保存されます。

スナップショットは、他の興味深い ClickHouse 機能も使用します。

まず、AggregatingMergeTreeです。 そして、AggregatingMergeTree は argMax を保存します。つまり、これは最後のタイムスタンプに対応するトランザクションの状態です。 トランザクションは特定の訪問者に対して常に生成されます。 そして、このトランザクションの最後の状態でイベントを追加し、新しい状態ができました。 再びClickHouseを襲った。 そして、この具体化されたビューの argMax を通じて、常に現在の状態を取得できます。

• バインディングはランタイムから「分離」されます。
• 毎月最大 3 億件のトランザクションが保存および処理されます。 これは、Cassandra の場合、つまり一般的なトランザクション システムの場合よりも桁違いに多くなります。
• 2x5 ClickHouse サーバーのクラスター。 5 つのサーバーがあり、各サーバーにはレプリカがあります。 これは、クリックベースのアトリビューションを行うための Cassandra の場合よりもさらに少なく、ここではインプレッションベースです。 つまり、サーバーの数を 30 倍に増やす代わりに、サーバーの数を減らすことができました。

そして最後の例は金融会社 Y で、株価の変動の相関関係を分析しました。

そして、その任務は次のとおりでした。

• 株数は約5株です。
• 100 ミリ秒ごとの引用符がわかっています。
• データは10年以上蓄積されています。 どうやら、一部の企業ではそれ以上、一部の企業ではそれ以下のようです。
• 合計で約 100 億行あります。

そして、変化の相関関係を計算する必要がありました。

ここではXNUMXつの銘柄とその株価を紹介します。 一方が上昇し、他方が上昇する場合、これは正の相関関係です。つまり、一方が上昇し、他方が上昇します。 グラフの端のように一方が上昇し、他方が下降する場合、これは負の相関関係です。つまり、一方が上昇すると他方が低下します。

こうした相互の変化を分析することで、金融市場の予測を立てることができます。

しかし、その任務は難しい。 そのために何が行われているのでしょうか？ 私たちは、時間、在庫、価格を含む 100 億件のレコードを持っています。 最初に価格アルゴリズムから runningDifference の 100 億倍を計算する必要があります。 RunningDifference は、XNUMX つの文字列の差を順番に計算する ClickHouse の関数です。

その後、相関関係を計算する必要があります。相関関係はペアごとに計算する必要があります。 5 株の場合、ペアは 000 万です。 これは非常に多く、つまり、このような相関関数を計算するのに必要な時間は 12,5 倍です。

誰かが忘れた場合、͞x と ͞y はチェックメイトになります。 サンプリングの期待。 つまり、根と和を計算するだけでなく、これらの和の中のもう 12,5 つの和も計算する必要があります。 大量の計算を 60 万回実行する必要があり、さらには時間ごとにグループ化する必要があります。 時間もたくさんあります。 そしてそれをXNUMX秒以内にやらなければなりません。 それは冗談だ。

ClickHouse が登場するまでは、これらすべての作業が非常にゆっくりと行われていたため、少なくとも何らかの形で時間を確保する必要がありました。

彼らは、Hadoop、Spark、Greenplum でそれを計算しようとしました。 そして、これはすべて非常に時間がかかるか、高価でした。 つまり、なんとか計算することはできましたが、その場合は高価でした。

その後、ClickHouse が登場し、事態は大幅に改善されました。

相関関係は局所化できないため、データの局所性に問題があることを思い出してください。 データの一部を XNUMX つのサーバーに配置し、一部を別のサーバーに配置して計算することはできません。すべてのデータをどこにでも配置する必要があります。

彼らは何をしたのでしょうか？ 最初に、データはローカライズされます。 各サーバーは、特定の株式セットの価格設定に関するデータを保存します。 そしてそれらは重なりません。 したがって、logReturn を並列かつ独立して計算することが可能であり、これまでの処理はすべて並列かつ分散的に行われます。

そこで、表現力を失わずにこれらのデータを削減することにしました。 配列を使用して削減します。つまり、期間ごとに、株式の配列と価格の配列を作成します。 したがって、必要なデータ容量がはるかに少なくなります。 そして、それらは少し作業が簡単です。 これらはほぼ並列操作です。つまり、部分的に並列で読み取り、その後サーバーに書き込みます。

その後、複製することができます。 文字「r」は、このデータを複製したことを意味します。 つまり、XNUMX つのサーバーすべてに同じデータがあります。これらは配列です。

そして、計算する必要があるこの 12,5 万個の相関関係のセットから特別なスクリプトを使用して、パッケージを作成できます。 つまり、2 ペアの相関関係を持つ 500 のタスクです。 そして、このタスクは特定の ClickHouse サーバー上で計算されます。 データは同じであり、それらを順番に計算できるため、彼はすべてのデータを持っています。

もう一度言いますと、こんな感じです。 まず、この構造には時間、株価、価格などのすべてのデータが含まれています。 次に、logReturn、つまり同じ構造のデータを計算しましたが、価格の代わりにすでに logReturn が得られています。 その後、それらはやり直されました。つまり、株価と価格の時刻と groupArray を取得しました。 複製されました。 その後、大量のタスクを生成し、それらを ClickHouse に供給して、タスクがカウントされるようにしました。 そしてそれはうまくいきます。

概念実証では、タスクはサブタスクでした。つまり、取得されるデータが少なくなりました。 しかもサーバーはたったのXNUMX台。

最初の XNUMX つの段階、つまり Log_return の計算と配列へのラップには約 XNUMX 時間かかりました。

そして相関関係の計算には約50時間かかります。 しかし、以前は何週間も働いていたため、50 時間では十分ではありません。 大成功でした。 そして、数えてみると、このクラスターでは 70 秒あたり XNUMX 回、すべてがカウントされたことになります。

しかし、最も重要なことは、このシステムには実質的にボトルネックがないこと、つまり、ほぼ直線的に拡張できることです。 そして彼らはそれを調べました。 スケールアップに成功しました。

• 適切な計画は成功の半分です。 そして、適切なスキームは、必要なすべての ClickHouse テクノロジーを使用することです。
• Summing/AggregatingMergeTrees は、状態スナップショットを特別なケースとして集約したり考慮したりできるテクノロジーです。 そして、多くのことが大幅に簡素化されます。
• マテリアライズド ビューを使用すると、XNUMX つのインデックス制限を回避できます。 あまりはっきりとは言えなかったかもしれませんが、ログをロードしたとき、生のログは XNUMX つのインデックスを持つテーブル内にあり、属性ログはテーブル内にありました。つまり、同じデータはフィルタリングされただけで、インデックスは完全に削除されていました。その他。 同じデータですが、並べ替えが異なるように見えます。 そして、マテリアライズド ビューを使用すると、必要に応じて、このような ClickHouse の制限を回避できます。
• ポイント クエリのインデックスの粒度を減らします。
• データを賢く分散し、可能な限りサーバー内でデータをローカライズするようにしてください。 そして、可能な限りリクエストでもローカリゼーションを使用するようにしてください。

この短いスピーチを要約すると、ClickHouse は現在、商用データベースとオープンソース データベースの両方、つまり特に分析分野の領域をしっかりと占領していると言えます。 彼はこの風景に完璧に溶け込んでいます。 さらに、ClickHouse があれば InfiniDB は必要ないため、徐々に他のものを排除し始めます。 通常の SQL サポートを作成すれば、Vertika はすぐに必要なくなる可能性があります。 楽しみ！

- ご報告ありがとうございます！ とても興味深い！ Apache Phoenix との比較はありましたか?

いいえ、誰かが比較しているのを聞いたことがありません。 私たちと Yandex は、さまざまなデータベースとのすべての ClickHouse 比較を追跡しようとしています。 なぜなら、突然何かがClickHouseよりも速いことが判明した場合、Lesha Milovidovは夜眠ることができず、すぐに速度を上げ始めるからです。 そんな比較は聞いたことがありません。

• (Aleksey Milovidov) Apache Phoenix は、Hbase を利用した SQL エンジンです。 Hbase は主にキーと値の作業シナリオ用です。 各行には、任意の名前を持つ任意の数の列が存在できます。 これは、Hbase、Cassandra などのシステムについても言えます。 そして、それはまさに重い分析クエリであり、通常は機能しません。 あるいは、ClickHouse の使用経験がなければ、問題なく動作すると考えるかもしれません。

• 感謝

  • こんにちは私は分析サブシステムを持っているので、このトピックにはすでに非常に興味があります。 しかし、ClickHouse を見ると、ClickHouse はイベント分析に非常に適しており、可変であると感じます。 そして、多数の大きなテーブルを使用して大量のビジネス データを分析する必要がある場合、私の理解する限り、ClickHouse は私にはあまり適していませんか? 特に彼らが変わる場合は。 これは正しいですか、それともこれに反論できる例はありますか?

  • これは正しいです。 これは、ほとんどの特殊な分析データベースに当てはまります。 これらは、変更可能な XNUMX つ以上の大きなテーブルと、ゆっくりと変化する多くの小さなテーブルがあるという事実に合わせて調整されています。 つまり、ClickHouse は、すべてを配置して非常に複雑なクエリを構築できる Oracle とは異なります。 ClickHouse を効果的に使用するには、ClickHouse で適切に機能する方法でスキームを構築する必要があります。 つまり、過剰な正規化を避け、辞書を使用し、長いリンクを少なくするように努めます。 この方法でスキーマを構築すると、同様のビジネス タスクを従来のリレーショナル データベースよりも ClickHouse ではるかに効率的に解決できます。

ご報告ありがとうございます！ 最近の金融事件について質問があります。 彼らは分析機能を持っていました。 上り下りの様子を比較する必要がありました。 この分析のために特別にシステムを構築されたと聞きましたが? たとえば、明日、このデータに関する別のレポートが必要な場合、スキーマを再構築してデータをアップロードする必要がありますか? つまり、リクエストを取得するために何らかの前処理を行う必要がありますか?

もちろん、これは非常に特殊なタスクのための ClickHouse の使用です。 これは、より伝統的に Hadoop 内で解決できる可能性があります。 Hadoop にとって、これは理想的なタスクです。 しかし、Hadoop では非常に遅いです。 そして私の目標は、通常はまったく異なる手段で解決されるタスクを ClickHouse が解決できると同時に、はるかに効率的に実行できることを実証することです。 特定のタスクに合わせて調整されています。 同様の問題が発生した場合、同様の方法で解決できることは明らかです。

それは明らかだ。 50時間処理したとおっしゃいました。 データをロードしたり、結果を取得したりしたのは最初からですか?

はい、はい。

はい、ありがとうございます。

これは 3 サーバー クラスター上にあります。

こんにちは！ ご報告ありがとうございます！ どれもとても興味深いですね。 機能については少し質問しませんが、安定性の観点からの ClickHouse の使用について質問します。 つまり、何かありましたか、復元する必要がありましたか? この場合、ClickHouse はどのように動作しますか? それで、たまたまレプリカも持っていたんですか？ たとえば、ClickHouse が依然として制限を超えて落下するという問題が発生しました。

もちろん、理想的なシステムなどありません。 そして、ClickHouse にも独自の問題があります。 しかし、Yandex.Metrica が長い間機能していないという話を聞いたことがありますか? おそらくそうではありません。 ClickHouse では 2012 年から 2013 年まで安定して動作しています。 私の経験についても同じことが言えます。 私たちは完全な失敗を経験したことがありません。 部分的な問題が発生する可能性はありますが、ビジネスに深刻な影響を与えるほど重大なものではありませんでした。 そんなことは決して起こらなかった。 ClickHouse は非常に信頼性が高く、ランダムにクラッシュすることはありません。 心配する必要はありません。 それは生々しいものではありません。 これは多くの企業によって証明されています。

こんにちは！ データ スキーマをすぐに検討する必要があるとおっしゃいました。 それが起こったらどうなるでしょうか？ 私のデータはどんどん流れ込んでいます。 半年が経ち、このままでは無理だとわかり、データを再アップロードして何かをする必要があります。

もちろん、これはシステムによって異なります。 実質的に停止せずにこれを行う方法はいくつかあります。 たとえば、一意にマッピングできる場合は、異なるデータ構造を作成するマテリアライズド ビューを作成できます。 つまり、ClickHouse を使用したマッピングが許可されている場合、つまり、いくつかのものを抽出し、主キーを変更し、パーティションを変更すると、マテリアライズド ビューを作成できます。 そこに古いデータを上書きすると、新しいデータが自動的に書き込まれます。 次に、マテリアライズド ビューの使用に切り替えて、レコードを切り替えて古いテーブルを強制終了します。 これは通常、ノンストップの方法です。

ありがとう。

出所： habr.com