🧖🏼 👇🏾 👨🏽‍🍳 Yandexでの継続的な統合。パート2 🎣 🦊 🚶

前の記事では、トランクベースの開発アプローチを使用した単一リポジトリへの開発の移行、アセンブリ、テスト、展開、および監視のための統合システム、継続的な統合システムがそのような状況で効果的に機能するために解決しなければならないタスクについて説明しました。

本日は、Habr読者に継続的インテグレーションシステムのデバイスについて説明します。

継続的インテグレーションシステムは、確実かつ迅速に動作する必要があります。システムは、着信イベントに迅速に応答する必要があり、テスト実行結果をユーザーに配信するプロセスに追加の遅延を導入しないでください。アセンブリとテストの結果は、リアルタイムでユーザーに配信する必要があります。

継続的インテグレーションシステムは、遅延が最小限のストリーミングデータ処理システムです。

特定の段階（構成、ビルド、スタイル、小規模テスト、中規模テストなど）ですべての結果を送信した後、ビルドシステムはこれを継続的インテグレーションシステムに通知し（ステージを「閉じる」）、ユーザーはこのチェックとこの段階では、すべての結果がわかっています。各ステージは独立して閉じます。ユーザーは便利な信号をより速く受け取ります。すべてのステージを閉じた後、チェックは完了したと見なされます。

システムを実装するために、 Kappaアーキテクチャを選択しました。システムは2つのサブシステムで構成されています。

イベントとデータの処理はリアルタイム回路で行われます。入力データはすべてデータストリーム（ストリーム）として扱われます。最初に、イベントがストリームに記録されてから処理されます。
データ処理の結果はデータベースに継続的に書き込まれ、APIを介して呼び出しが行われます。 Kappaアーキテクチャでは、これはサービングレイヤーと呼ばれます。

システムの現在の状態を常に把握する必要があるため、データ変更のすべての要求はリアルタイム回線を経由する必要があります。読み取り要求はデータベースにのみ送信されます。

可能な限り、追加専用ルールに従います。古い不要なデータを削除する場合を除き、オブジェクトの変更や削除はありません。

1日に2 Tbを超える生データがサービスを通過します。

利点：

ストリームには、すべてのイベントとメッセージが含まれます。何がいつ起こったかを常に理解できます。ストリームは大きなログとして認識されます。
高効率で最小限のオーバーヘッド。ポーリングを失うことなく、完全にイベント指向のシステムになります。イベントはありません。特別なことは何もしていません。
アプリケーションコードは、実際には、スレッド同期のプリミティブとスレッド間で共有されるメモリを処理しません。これにより、システムの信頼性が高まります。
プロセッサは互いに十分に分離されているため、ストリームを介してのみ、直接対話します。良好なテスト範囲を提供できます。

ただし、ストリーミングデータはそれほど単純ではありません。

計算モデルの十分な理解が必要です。既存のデータ処理アルゴリズムを再考する必要があります。すべてのアルゴリズムがすぐにストリームモデルに該当するわけではなく、頭を少し壊す必要があります。
イベントの受信と処理の順序の保存を保証する必要があります。
相互に関連するイベントを処理できる必要があります。新しいメッセージの処理中に必要なすべてのデータにすばやくアクセスできます。
また、重複したイベントを処理できる必要があります。

ストリーム処理

プロジェクトの作業中に、Stream Processorライブラリが作成されました。これにより、実稼働環境でストリームデータ処理アルゴリズムを迅速に実装および起動できました。

Stream Processorは、ストリーミングデータ処理システムを構築するためのライブラリです。ストリームは、潜在的に無限のデータ（メッセージ）のシーケンスであり、新しいメッセージの追加のみが可能です;既に記録されたメッセージは変更されず、ストリームから削除されません。あるストリームから別のストリームへのコンバーター（ストリームプロセッサ）は、機能的に3つの部分で構成されます：通常、1つ以上のストリームからメッセージを読み取り、処理キューに入れる着信メッセージプロバイダー、着信メッセージを発信ストリームに変換してキューに入れるメッセージプロセッサータイムウィンドウ内でグループ化された発信メッセージが出力ストリームに分類される記録と書き込み。 1つのストリームプロセッサで生成されたデータメッセージは、後で他のプロセッサで使用できます。したがって、ストリームとプロセッサは、サイクルが可能な有向グラフを形成します。特に、ストリームプロセッサは、データを受信した場所から同じストリームでメッセージを生成することさえできます。

入力ストリームの各メッセージは、それに関連付けられている各プロセッサによって少なくとも1回（セマンティクスが少なくとも1回）処理されることが保証されています。また、すべてのメッセージがこのストリームに到着した順序で処理されることが保証されます。これを行うために、ストリームプロセッサはサービスのすべての作業ノードに分散されるため、一度に登録された各プロセッサのインスタンスは1つしか機能しません。

相互に関連するイベントの処理は、ストリーミングデータ処理用のシステムを構築する際の主な問題の1つです。原則として、メッセージをストリーミングする場合、ストリームプロセッサは、現在のメッセージが処理された時点で有効だった特定の状態を徐々に作成します。このような状態オブジェクトは通常、ストリーム全体ではなく、特定のメッセージのサブセットに関連付けられます。これは、このストリームのキー値によって決定されます。資産を効率的に保管することが成功の鍵です。次のメッセージを処理するとき、プロセッサがこの状態をすばやく取得し、それと現在のメッセージに基づいて送信メッセージを生成できることが重要です。これらの状態オブジェクトは、メモリ内にあるL1キャッシュ（CPUキャッシュと混同しないでください）LRUキャッシュにアクセスできます。 L1キャッシュに状態がなかった場合、ストリームが保存され、プロセッサの動作中に定期的に保存される同じストレージにあるL2キャッシュから復元されます。 L2キャッシュに状態がなかった場合、プロセッサが現在のメッセージキーに関連付けられたすべての元のメッセージを処理したかのように、元のストリームメッセージから復元されます。多くの場合、シーケンシャル処理はサーバーのパフォーマンスではなく、データウェアハウスとの通信時の要求と応答の遅延に依存するため、キャッシュ技術により、ストレージの高遅延の問題に対処できます。

メモリ効率の高い構造に加えて、L1キャッシュにデータを、メモリにメッセージデータを効果的に保存するために、オブジェクトプールを使用して、メモリ内にオブジェクト（またはその一部）のコピーを1つだけ持つことができます。この手法は、JDKで既に文字列の抑制文字列として使用されており、同様に他のタイプのオブジェクトにも適用されます。

ストリームストレージにデータをコンパクトに保存するには、一部のデータをストリームに書き込む前に正規化します。数字に変わります。その後、効果的な圧縮アルゴリズムを数値（オブジェクト識別子）に適用できます。番号が並べ替えられ、デルタがカウントされ、次にZigZagエンコードでエンコードされ、アーカイバーで圧縮されます。正規化は、ストリーミングデータ処理システムの標準技術ではありません。しかし、この圧縮技術は非常に効果的であり、最もロードされたストリームのデータ量は約1,000倍削減されます。

各ストリームおよびプロセッサについて、メッセージ処理のライフサイクルを追跡します。入力ストリームでの新しいメッセージの出現、未処理メッセージのキューのサイズ、結果のストリームに書き込むキューのサイズ、メッセージ処理時間、およびメッセージ処理ステージごとの時間の分布：

データウェアハウス

ストリーミング結果は、できるだけ早くユーザーが利用できるようにする必要があります。ストリームからの処理済みデータは、データベースに継続的に記録される必要があります。その後、データを適用できます（たとえば、テストの結果を含むレポートの表示、テストの履歴の表示）。

保存されたデータとクエリの特性。

ほとんどのデータはテスト実行です。 1か月以上で、15億を超えるビルドとテストが開始されます。起動ごとにかなり大量の情報が保存されます：エラーの結果とタイプ、エラーの簡単な説明（スニペット）、ログへのいくつかのリンク、テスト期間、数値のセット、メトリック、name = valueなどの形式です。実際にはランダムな値であるため、このデータの一部（たとえば、メトリックスと期間）は圧縮が非常に困難です。他の部分-たとえば、結果、エラーのタイプ、ログ-は、同じテストで実行ごとにほとんど変化しないため、より効率的に保存できます。

以前は、MySQLを使用して処理済みデータを保存していました。私たちは徐々にデータベースの機能に頼り始めました。

処理されるデータの量は6か月ごとに2倍になります。
過去2か月間のデータしか保存できませんでしたが、少なくとも1年間はデータを保存したかったのです。
重い（分析に近い）クエリの実行速度の問題。
複雑なデータベーススキーマ。データベースへの書き込みを複雑にする多数のテーブル（正規化）。基本スキームは、リアルタイム回路で使用されるオブジェクトのスキームとは大きく異なります。
サーバーがシャットダウンしていません。別のサーバーに障害が発生したり、データセンターがシャットダウンしたりすると、システム障害が発生する可能性があります。
かなり複雑な操作。

新しいデータウェアハウスの候補として、いくつかのオプションを検討しました：PostgreSQL、MongoDB、 ClickHouseなどのいくつかの内部ソリューション。

一部のソリューションでは、古いMySQLベースのソリューションよりも効率的にデータを保存することができません。その他では、高速で複雑な（ほとんど分析的な）クエリを実装できません。たとえば、特定のプロジェクト（いくつかのテストセット）に影響するコミットを示す、かなり重いリクエストがあります。高速なSQLクエリを実行できないすべての場合、ユーザーに長時間待機させるか、柔軟性を失って事前に計算を行う必要があります。事前に何かをとる場合、より多くのコードを記述すると同時に柔軟性を失う必要があります。動作をすばやく変更して何かを再集計する方法はありません。ユーザーが必要とするデータを返すSQLクエリを記述する方がはるかに便利で高速であり、システムの動作を変更したい場合は迅速に変更できます。

クリックハウス

ClickHouseを選択しました。 ClickHouseは、オンライン分析クエリ処理（OLAP）用の円柱状のデータベース管理システム（DBMS）です。

ClickHouseに切り替えると、他のDBMSが提供する機会の一部を意識的に放棄し、非常に高速な分析クエリとコンパクトなデータウェアハウスという形でこれに対する価値のある補償を受け取りました。

リレーショナルDBMSでは、行ごとの値は物理的に並んで格納されます。 ClickHouseでは、異なる列の値は別々に保存され、1つの列のデータは一緒に保存されます。このデータストレージの順序により、主キーを正しく選択して高度なデータ圧縮を実現できます。また、DBMSが適切に機能するシナリオにも影響します。 ClickHouseは、少数の列が読み取られ、クエリが1つの大きなテーブルを使用し、残りのテーブルが小さいクエリでより適切に機能します。ただし、非分析クエリでも、ClickHouseは良い結果を表示できます。

テーブル内のデータは主キーでソートされます。ソートはバックグラウンドで実行されます。これにより、小さなボリュームのスパースインデックスを作成でき、データをすばやく見つけることができます。 ClickHouseにはセカンダリインデックスがありません。厳密に言うと、1つのセカンダリインデックスがあります-パーティションキー（ClickHouseは、パーティションキーがリクエストで指定されているパーティションデータを遮断します）詳細

正規化を使用したデータスキームは機能的ではありません。逆に、要求に応じてデータを非正規化することをお勧めします。多数の列を持つ「幅の広い」テーブルを作成することをお勧めします。この項目は、セカンダリインデックスがないために、異なるプライマリキーを使用してテーブルのコピーを作成することがあるため、前の項目にも関連しています。

ClickHouseには、古典的な意味でのUPDATEおよびDELETEはありませんが、それらをエミュレートする可能性があります。

データはあまり頻繁に（数秒に1回）大きなブロックに挿入する必要があります。行ごとのデータ読み込みは、実際のデータボリュームでは事実上動作しません。

ClickHouseはトランザクションをサポートしていないため、システムは最終的に一貫性を保ちます。

それでも、他のDBMSと同様に、ClickHouseの一部の機能を使用すると、既存のシステムを簡単に移行できます。

ClickHouseはSQLを使用しますが、OLAPシステムに典型的なクエリにはわずかな違いがあります。集約関数の強力なシステム、ALL / ANY JOIN、関数内のラムダ式、およびほとんどすべての分析クエリを作成できるその他のSQL拡張機能があります。
ClickHouseは、レプリケーション、クォーラム記録、クォーラム読み取りをサポートしています。信頼できるデータストレージにはクォーラム書き込みが必要です。INSERTは、ClickHouseがエラーなしで指定された数のレプリカにデータを書き込むことができた場合にのみ成功します。

ClickHouse機能の詳細については、ドキュメントをご覧ください。

ClickHouseを使用する機能

主キーとパーティションキーの選択。

主キーとパーティションキーを選択する方法おそらくこれは、新しいテーブルを作成するときに生じる最初の質問です。主キーとパーティションキーの選択は、通常、データに対して実行されるクエリによって決まります。同時に、両方の条件を使用するクエリが最も効果的であることがわかりました。主キーとパーティションキーによるものです。

この場合、メインテーブルは、テストを実行するためのマトリックスです。このようなデータ構造では、一方のバイパス順序が行番号の増加順に、他方のバイパス順序が列番号の増加順になるように、キーを選択する必要があると考えるのが論理的です。

主キーをバイパスする他の列の同一の値はテーブル内のスペースをほとんど占有しないため、主キーの選択はデータストレージのコンパクト性に劇的に影響する可能性があることに留意することも重要です。したがって、たとえば、私たちの場合、テストの状態はコミットからコミットにほとんど変わりません。この事実により、主キー（テスト識別子とコミット番号のペア）の選択が本質的に事前に決定されました。また、その順序で。

パーティションキーには2つの目的があります。一方で、パーティション内のデータがすでに古くなっているため、パーティションを「アーカイブ」して、リポジトリから永久に削除できるようにします。一方、パーティションキーはセカンダリインデックスです。つまり、パーティションキーに式が存在する場合、クエリを高速化できます。

マトリックスでは、パーティションキーとしてコミット番号を選択するのは非常に自然なことです。ただし、パーティションキーの式にリビジョン値を設定すると、そのようなテーブルには不合理に多くのパーティションが存在し、クエリのパフォーマンスが低下します。したがって、パーティションキーの式では、たとえばPARTITION BY intDiv（revision、2000）のように、リビジョン値をいくつかの大きな数値に分割してパーティションの数を減らすことができます。この数は、パーティションの数が推奨値を超えないように十分大きくする必要がありますが、1つのパーティションに大量のデータが入らず、データベースがあまり多くのデータを読み取る必要がないように十分に小さくする必要があります。

UPDATEおよびDELETEを実装する方法

通常の意味では、UPDATEおよびDELETEはClickHouseではサポートされていません。ただし、UPDATEおよびDELETEの代わりに、バージョン付きの列をテーブルに追加し、特別なReplacingMergeTreeエンジンを使用できます（同じ主キー値を持つ重複レコードを削除します）。場合によっては、バージョンは最初からテーブルに自然に存在します。たとえば、テストの現在の状態に対応するテーブルを作成する場合、このテーブルのバージョンがコミット番号になります。

CREATE TABLE current_tests ( test_id UInt64, value Nullable(String), version UInt64 ) ENGINE = ReplacingMergeTree(version) ORDER BY test_id

レコードが変更された場合、削除の場合はNULL値（またはデータで見つからない他の特別な値）を使用して、新しい値でバージョンを追加します。

新しいストレージで何を達成しましたか？

ClickHouseに切り替える主な目標の1つは、テスト履歴を長期間（数年、最悪の場合は少なくとも1年）にわたって保存する機能でした。すでにプロトタイプの段階で、少なくとも3年の履歴を保存するためにサーバー内の既存のSSDを回避できることが明らかになりました。分析クエリが大幅に高速化されたため、データからはるかに有用な情報を抽出できるようになりました。 RPSマージンが増加しました。さらに、この値は、ClickHouseクラスターに新しいサーバーを追加することでほぼ線形にスケーリングされます。 ClickHouseデータベース用の新しいデータウェアハウスを作成することは、大量のデータを保存および処理する機能のおかげで、新しい機能を追加し、開発を加速および簡素化するという、より重要な目標に向けたエンドユーザーにとってはほとんど目立たないステップです。

私たちに来て

私たちの部門は常に拡大しています。複雑で興味深いタスクとアルゴリズムに取り組みたい場合は、当社をご覧ください。ご質問がある場合は、PMで直接お問い合わせください。

便利なリンク

ストリーム処理

河童建築

ClickHouse：

Yandexでの継続的な統合。 パート2

ストリーム処理

データウェアハウス

クリックハウス

ClickHouseを使用する機能

私たちに来て

便利なリンク

More articles:

Yandexでの継続的な統合。パート2