イベント処理を毎秒160万に加速

HighLoad ++の参加者がAlexander Krasheninnikovのレポートに来たとき、彼らは毎秒1,600,000イベントの処理について聞いてみたいと思っていました。 期待は実現しませんでした...パフォーマンスの準備中に、この数値は1,800,000にまで上昇したため、HighLoad ++では、現実は期待を超えています。



3年前、Alexanderは 、Badooでスケーラブルなリアルタイムに近いイベント処理システムをどのように構築したかを語りました。 それ以来、プロセスが進化し、ボリュームが増大し、スケーリングとフォールトトレランスの問題を解決する必要があり、ある時点で根本的な対策が必要になりました- 技術スタックの変更 。







復号化から、BadooでSpark + HadoopバンドルをClickHouseに置き換え、 ハードウェアを3倍節約し、負荷を6倍に増やした方法、プロジェクトの統計を収集する理由と方法、そしてこのデータをどう処理するかを学習します。







スピーカーについて： Alexander Krasheninnikov （ alexkrash ） -Badooのデータエンジニアリング責任者。 彼は、ワークロードに合わせてスケーリングするBIインフラストラクチャに従事し、データ処理インフラストラクチャを構築するチームを管理しています。 彼は、Hadoop、Spark、ClickHouseなど、配布されるすべてのものが大好きです。 OpenSourceからクールな分散システムを準備できると確信しています。

統計収集

データがない場合、私たちは盲目であり、プロジェクトを管理できません。 そのため、プロジェクトの実行可能性を監視するために統計が必要です。 エンジニアとして、私たちは製品の改善に努める必要があります。改善したい場合は測定してください。 これが私の仕事のモットーです。 まず第一に、私たちの目標はビジネス上の利益です。 統計は、ビジネス上の質問に対する答えを提供します 。 テクニカルメトリックはテクニカルメトリックですが、ビジネスは指標にも関心があり、考慮する必要があります。

統計ライフサイクル

統計のライフサイクルを4つのポイントで定義します。それぞれについて個別に説明します。

フェーズの定義-形式化

アプリケーションでは、いくつかのメトリックを収集します。 まず、これらはビジネス指標です。 たとえば、写真サービスがある場合、1日に1時間に1秒間に何枚の写真がアップロードされるのか疑問に思っています。 次のメトリックは「準技術的」です。モバイルアプリケーションまたはサイトの応答性、API操作、ユーザーがサイトと対話する速さ、アプリケーションのインストール、UX。 3番目に重要な指標は、 ユーザーの行動を追跡することです。 これらは、Google AnalyticsやYandex.Metricsなどのシステムです。 独自のクールな追跡システムがあり、そこで多くの投資をしています。



統計を扱うプロセスでは、多くのユーザーが関与します-これらは開発者とビジネスアナリストです。 全員が同じ言語を話すことが重要なので、同意する必要があります。

口頭で交渉することは可能ですが、これが正式に発生する場合は、イベントの明確な構造においてはるかに優れています。

開発者がビジネスイベントの構造を形式化すると 、開発者が登録数を言うと、アナリストは登録の総数だけでなく、国、性別、およびその他のパラメーターに関する情報も提供されたことを理解します。 そして、この情報はすべて形式化され、会社のすべてのユーザーのパブリックドメインにあります 。 イベントには、型付き構造と正式な説明があります。 たとえば、この情報をプロトコルバッファ形式で保存します。



イベント「登録」の説明：

enum Gender { FEMALE = 1; MALE = 2; } message Registration { required int32 userid =1; required Gender usergender = 2; required int32 time =3; required int32 countryid =4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

登録イベントには、 ユーザー、フィールド、イベントの時間 、およびユーザーの登録国に関する情報が含まれています。 この情報はアナリストが利用でき、将来、企業は当社が収集するものを理解します。

正式な説明が必要なのはなぜですか？

正式な説明は、開発者、アナリスト、および製品部門の統一性です。 次に、この情報は、アプリケーションのビジネスロジックの説明を実行します。 たとえば、ビジネスプロセスを記述する内部システムがあり、その中に新しい機能がある画面があります。







製品要件ドキュメントには、ユーザーがこの方法でアプリケーションと対話するときに、まったく同じパラメーターでイベントを送信する必要があるという指示を含むセクションがあります。 その後、機能がどのように機能するか、およびそれらを正しく測定したことを検証できます。 正式な説明により、このデータをデータベースに保存する方法（NoSQL、SQLなど）をさらに理解できます。 データスキーマがあり 、それは素晴らしいです。



サービスとして提供される一部の分析システムでは、シークレットストレージには10〜15個のイベントしかない。 私たちの数は1000を超えて成長し、止まることはありません。 単一のレジストリなしでは生きることは不可能です。

フェーズ概要の定義

統計は重要であると判断し、特定の主題分野について説明しました。これは良いことです。

収集フェーズ-データ収集

登録、メッセージの送信などのビジネスイベントが発生したときに、この情報を保存すると同時に、統計イベントを個別に送信するようにシステムを構築することにしました。

コードでは、統計はビジネスイベントと同時に送信されます。

データフローは別の処理パイプラインを通過するため、アプリケーションが実行されるデータストアとは完全に独立して処理されます。



EDLによる説明：

 enum Gender { FEMALE = 1; MALE = 2; } message Registration { required int32 user_id =1; required Gender user_gender = 2; required int32 time =3; required int32 country_id =4; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

登録イベントの説明があります。 APIは自動的に生成され、開発者はコードからアクセスでき、4行で統計を送信できます。



EDLベースのAPI：

 \EDL\Event\Regist ration::create() ->setUserId(100500) ->setGender(Gender: :MALE) ->setTime(time()) ->send();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イベント配信

これが外部システムです。 これを行うのは、写真データを操作するためのAPIを提供する素晴らしいサービスがあるためです。 それらはすべて、AerospikeやCockroachDBなどのクールな新しいデータベースにデータを保存します。



ある種のレポートを作成する必要がある場合は、「みんな、どれだけあるのか、どれだけあるのか」というスクランブルに行く必要はありません。すべてのデータは別のフローに送信されます。 処理コンベア-外部システム。 アプリケーションコンテキストから、ビジネスロジックリポジトリからすべてのデータを解き、さらに別のパイプラインに送信します。



収集フェーズでは、アプリケーションサーバーの可用性を想定しています。 このPHPがあります。

輸送

これは、アプリケーションコンテキストから行ったことを別のパイプラインに送信できるサブシステムです。 輸送は、プロジェクトの状況に応じて、要件からのみ選択されます。



輸送には特徴があり、最初の保証は配達保証です。 トランスポートの特性：少なくとも1回、正確に1回、このデータの重要度に基づいて、タスクの統計を選択します。 たとえば、課金システムの場合、統計に現在よりも多くのトランザクションが表示されることは受け入れられません。これは金銭であり、不可能です。



2番目のパラメーターは、プログラミング言語のバインディングです。 どういうわけかトランスポートとやり取りする必要があるため、プロジェクトが記述されている言語に応じて選択されます。



3番目のパラメーターはスケーラビリティです。 1秒あたり数百万のイベントについて話しているので、将来のスケーラビリティを念頭に置いておくとよいでしょう。



多くのトランスポートオプションがあります：RDBMSアプリケーション、Flume、KafkaまたはLSD。 私たちはLSDを使用します-これは私たちの特別な方法です。

ライブストリーミングデーモン

LSDは禁止物質とは関係ありません。 これは、 活発で非常に高速なストリーミングデーモンであり、書き込み用のエージェントを提供しません。 それを調整することができ、他のシステムとの統合があります ：HDFS、Kafka-送信されたデータを再配置できます。 LSDにはINSERTのネットワークコールがなく、ネットワークトポロジを制御できます。



最も重要なことは、これはBadooのオープンソースです -このソフトウェアを信頼しない理由はありません。



それが完璧な悪魔であれば、カフカの代わりにすべての会議でLSDについて議論しますが、すべてのLSDには軟膏のハエがあります。 私たちには私たちに合った独自の制限があり、私たちに合っています： LSDでは複製がサポートされておらず 、少なくとも1回の配信保証があります。 また、金銭取引の場合、これは最適なトランスポートではありませんが、一般にACIDをサポートする「酸性」データベースを介してのみお金と通信する必要があります。

収集フェーズの要約

前のシリーズの結果に基づいて、データの正式な説明を受け、開発者がからイベントを送信するのに便利な優れたAPIを生成し、このデータをアプリケーションコンテキストから別のパイプライン に転送する方法を見つけました。 すでに悪くはありません。次の段階に近づいています。

フェーズプロセス-データ処理

登録、アップロードされた写真、投票からデータを収集しました-これらすべてをどうするか？ このデータから、長い履歴と生データを含む チャートを取得します 。 チャートはすべてを理解します。会社の収益が増加していることを曲線から理解するために開発者である必要はありません。 オンラインレポートとアドホックに生データを使用します。 より複雑なケースでは、アナリストはこのデータに対して分析クエリを実行したいと考えています。 それとその機能の両方が私たちにとって必要です。

グラフ

チャートには多くの形式があります。







または、たとえば、10年間のデータを示す履歴を持つグラフ。







チャートもそのようなものです。







これはいくつかのABテストの結果であり、驚くべきことにニューヨークのクライスラービルに似ています。



グラフを描画するには、生データのクエリと時系列の 2つの方法があります 。 どちらのアプローチにも欠点と利点がありますが、これらについては詳しく説明しません。 ハイブリッドアプローチを使用します。運用レポート用の生データの短い「テール」と、長期保存用の時系列を保持します。 2番目は1番目から計算されます。

1秒あたり180万のイベントに成長した方法

それは長い話です-1日で数百万のRPSは発生しません。 Badooは10年の歴史を持つ会社であり、データ処理システムは会社とともに成長したと言えます。







最初は何もありませんでした。 データの収集を開始しました- 毎秒5,000イベントになりました。 1つのMySQLホストと他の何もない！ リレーショナルDBMSはすべてこのタスクに対応し、快適です。トランザクション性があります-データを入力し、リクエストを受信します-すべてがうまく動作します。 だから私たちはしばらく住んでいた。



機能的シャーディングは、ある時点で発生しました。登録データがここに来て、そこに写真があります。 したがって、 1秒間に最大200,000件のイベントを処理し、さまざまな組み合わせアプローチを使用し始めました。生データではなく、 集約されたものですが、これまでのところリレーショナルデータベース内です。 カウンターを保存しますが、ほとんどのリレーショナルデータベースの本質は、このデータに対してDISTINCTクエリを実行することができないということです。カウンターの代数モデルではDISTINCTを計算できません。



Badooのモットーは「止められない力」です。 私たちは止まらず、さらに成長しました。 1秒あたり200,000イベントというしきい値を超えた時点で、上で説明した正式な説明を作成することにしました。 それ以前は混乱があり、現在、イベントの構造化されたレジスタがあります。Hadoopに接続してシステムのスケーリングを開始し、すべてのデータがHiveテーブルに入れられました。



Hadoopは、巨大なソフトウェアパッケージであるファイルシステムです。 分散コンピューティングの場合、Hadoop氏は、「ここにデータを入れて、分析クエリを実行できるようにします」と言います。 すべてのチャートの定期的な計算を作成しましたが、うまくいきました。 しかし、チャートは迅速に更新される場合に価値があります。1日1回、チャートの更新を見ることはそれほど楽しくありません。 本番環境で致命的なエラーを引き起こす何かを展開した場合、チャートが1日おきにではなく、すぐにドロップすることを確認したいと思います。 そのため、しばらくするとシステム全体が劣化し始めました。 ただし、この段階で、選択したテクノロジースタックに固執できることに気付きました。

私たちにとって、Javaは新しいものであり、私たちはそれを気に入っており、異なる方法で何ができるかを理解しました。

1秒あたり 40万から800,000イベントの段階で、Hadoopを最も純粋な形式で置き換え、Hiveは分析クエリのエグゼキューターとしてSpark Streamingを使用して、 一般的なマップ/リデュースおよびメトリックの増分計算を作成しました。 3年前、私はそれをどうやってやったかを話しました。 それから、Sparkは永遠に生き続けるように思えましたが、そうでない場合は命が命じられました-Hadoopの限界にぶつかりました。 おそらく、他の条件があったとしても、Hadoopを使い続けます。



もう1つの問題は、Hadoopでグラフを計算することに加えて、アナリストによって駆動される信じられないほどの4階建てのSQLクエリであり、グラフはすぐには更新されませんでした。 実際には、運用データ処理にはかなり注意が必要な仕事があるため、リアルタイムで高速かつクールです。



Badooには、ヨーロッパと北米の大西洋の両側にある2つのデータセンターが対応しています。 統合レポートを作成するには、アメリカからヨーロッパにデータを送信する必要があります。 より多くの計算能力があるため、すべての統計統計を保持するのはヨーロッパのデータセンターです。 約200ミリ秒のデータセンター間の往復 -ネットワークはかなり柔軟です-別のDCに要求を行うことは、次のラックに行くことと同じではありません。



イベントと開発者の正式化を開始し、プロダクトマネージャーが関与したとき、誰もがすべてを気に入っていました。 イベントの爆発的な成長がありました 。 現時点では、クラスターで鉄を購入する時期でしたが、私たちは本当にこれをやりたくありませんでした。



1秒間に800,000イベントのピークを過ぎたときに、YandexがOpenSource ClickHouseにアップロードしたものを見つけて、試してみることにしました。 彼らは何かをしようとしている最中にコーンの馬車を埋め、その結果、すべてがうまくいったとき、彼らは最初の百万のイベントのために小さなレセプションを行いました。 おそらく、ClickHouseがレポートを終了した可能性があります。

ClickHouseを使用して、そのまま使用してください。

しかし、これは面白くないので、データ処理について引き続き説明します。

クリックハウス

ClickHouseは過去2年間の誇大広告であり、紹介する必要はありません。2018年のHighLoad ++についてのみ、それに関する5つのレポートと、セミナーおよび会議について覚えています。



このツールは、自分で設定したタスクを正確に解決するように設計されています。 Hadoopから一度に受け取ったリアルタイム更新とチップがあります ：レプリケーション、シャーディング。 ClickHouseを試さない理由はありませんでした。Hadoopでの実装では、すでに底を突破していたことを理解していたからです。 このツールはクールで、ドキュメントは一般的に火がつきます-私は自分でそこに書いたので、すべてが本当に好きで、すべてが素晴らしいです。 しかし、多くの問題を解決する必要がありました。



ClickHouseでイベントのフロー全体をシフトする方法は？ 2つのデータセンターからのデータを結合する方法は？ 私たちが管理者のところに来て、「みんな、ClickHouseをインストールしましょう」と言ったという事実から、彼らはネットワークを2倍に厚くせず、遅延は半分になります。 いいえ、ネットワークはまだ最初の給与と同じくらい薄くて小さいです。



結果を保存する方法は ？ Hadoopでは、グラフィックスの描画方法を理解しましたが、魔法のClickHouseでどのように描画するのですか？ 魔法の杖は含まれていません。 時系列ストレージに結果を配信する方法は ？



研究所の講師が言ったように、3つのデータスキームを検討してください：戦略的、論理的、物理的です。

戦略的ストレージスキーム

2つのデータセンターがあります。 ClickHouseはDCについて何も知らない方法を知っていることを学び、各DCでクラスターをポップしました。 これで、 データは大西洋間ケーブルを移動しなくなりました。DCで発生したすべてのデータは、そのクラスターにローカルに保存されます。 たとえば、両方のDCにいくつの登録があるかを調べるために、結合されたデータに対してリクエストを行う場合、ClickHouseはこの機会を提供します。 リクエストの低レイテンシと可用性-最高傑作！

物理ストレージスキーム

繰り返しになりますが、データはClickHouseリレーショナルモデルにどのように分類されますか。レプリケーションとシャーディングを失わないために何をすべきでしょうか。 ClickHouseのドキュメントにはすべてが詳しく説明されています。複数のサーバーがある場合は、この記事に出くわします。 したがって、マニュアルの内容、つまり、レプリケーション、シャーディング、シャード上のすべてのデータへのクエリについては詳しく説明しません。

ストレージロジック

論理図が最も興味深いです。 1つのパイプラインで、異種イベントを処理します。 これは、登録、音声、写真のアップロード、技術指標、ユーザーの行動の追跡など、異種イベントのストリームがあることを意味します 。これらのイベントはすべて完全に異なる属性を持っています 。 たとえば、携帯電話で画面を見ました-画面IDが必要です、誰かに投票しました-投票が賛成か反対かを理解する必要があります。 これらのイベントにはすべて異なる属性があり、異なるグラフが描画されますが、これらはすべて単一のパイプラインで処理する必要があります。 ClickHouseモデルに配置する方法は？



アプローチNo. 1-イベントテーブルごと。 この最初のアプローチは、MySQLで得られた経験から推定したものです。ClickHouseでイベントごとにタブレットを作成しました。 かなり論理的に聞こえますが、多くの困難に遭遇しました。



本日のビルドがリリースされたときにイベントの構造が変更されるという制限はありません。 このパッチは、どの開発者でも作成できます。 このスキームは、通常、すべての方向で変更可能です。 唯一の必須フィールドは、 タイムスタンプイベントとイベントの内容です。 他のすべてはオンザフライで変更されるため、これらのプレートを変更する必要があります。 ClickHouseにはクラスターでALTERを実行する機能がありますが、これは繊細でデリケートな手順であり、自動化が困難でスムーズに機能しません。 したがって、これはマイナスです。



1000を超えるさまざまなイベントがあるため、 マシンごとに高いINSERTレートが得られます。すべてのデータを常に1000のテーブルに記録します。 ClickHouseの場合、これはアンチパターンです。 ペプシのスローガンがあれば-「Live in big sips」、ClickHouse- 「Live in big batch」 。 これが行われないと、レプリケーションが停止し、ClickHouseは新しい挿入の受け入れを拒否します。これは不快なスキームです。



アプローチ2-広いテーブル 。 シベリアの男性は、チェーンソーをレールに滑り込ませ、別のデータモデルを使用しようとしました。 千列のテーブルを作成します。各イベントにはデータ用の列が予約されています。 巨大なスパーステーブルを取得します -幸いなことに、これは開発環境を超えませんでした。最初の挿入から、スキームが絶対に悪いことが明らかになったためです。



それでも、私はこのようなクールなソフトウェア製品を使い、もう少し仕上げたいと思っています。それがあなたが必要とするものです。



アプローチ3-一般的な表。 ClickHouseは非スカラーデータ型をサポートしているため、配列にデータを格納する1つの巨大なテーブルがあります 。 つまり、属性の名前が格納される列と、属性の値が格納される配列を持つ別の列を開始します。







ClickHouseは、ここでそのタスクを非常にうまく実行します。 データを挿入するだけであれば、おそらく現在のインストールでさらに10回絞り込みます。



ただし、軟膏のハエは、 文字列の配列を保存するためのClickHouseのアンチパターンでもあることです。 行配列はより多くのディスク容量を占有するため、これは悪いことです。単純な列よりも縮小し、処理が困難です。 しかし、私たちのタスクについては、利点を上回るため、これに目を向けます。



そのようなテーブルからSELECTを作成する方法は？ 私たちのタスクは、性別でグループ化された登録をカウントすることです。 まず、1つの配列で性別の列に対応する位置を見つけ、次にこのインデックスを使用して別の列に移動してデータを取得する必要があります。

このデータにグラフを描く方法

すべてのイベントが記述されているため、それらは厳密な構造を持ち、イベントのタイプごとに4階建てのSQLクエリを形成し、実行して、結果を別のテーブルに保存します。



問題は、グラフ上に2つの隣接する点を描くには、テーブル全体をスキャンする必要があることです。 例：1日あたりの登録を確認します。 このイベントは、一番上の行から最後から2番目の行までです。 一度スキャン-素晴らしい。 5分後、グラフ上に新しいポイントを描画します-再び、前のスキャンと交差するデータ範囲をスキャンし、各イベントについて同様に行います。 論理的に聞こえますが、見栄えはよくありません。



さらに、いくつかの行を取得する場合、集計の結果も読み取る必要があります 。 たとえば、神のしもべがスカンジナビアで登録された男性であったという事実があり、要約統計を計算する必要があります：登録数、男性数、それらの何人がノルウェー人であるか。 これは、分析データベースROLLUP、CUBE 、およびGROUPING SETSの観点から呼び出されます-1行を複数行にします。

治療方法

幸いなことに、ClickHouseには、この問題、つまり集計関数のシリアル化された状態を解決するツールがあります。 これは、データの一部を一度スキャンして、これらの結果を保存できることを意味します。 これはキラー機能です 。 3年前、SparkとHadoopでこれを正確に行いましたが、Yandexの最高のマインドがClickHouseにアナログを実装したのは素晴らしいことです。

遅いリクエスト

今日と昨日のユニークユーザー数をカウントするという、ゆっくりとしたリクエストがあります。

 SELECT uniq(user_id) FROM table WHERE dt IN (today(), yesterday())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

物理的には、昨日の状態のSELECTを作成し、そのバイナリ表現を取得して、どこかに保存できます。

 SELECT uniq(user_id), 'xxx' AS ts, uniqState(user id) AS state FROM table WHERE dt IN (today(), yesterday())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今日は、今日になるという条件を変更するだけです： 'yyy' AS ts



およびWHERE dt = today()



およびタイムスタンプ“ xxx”および“ yyy”を呼び出します。 , , 2 .

 SELECT uniqMerge(state) FROM ageagate_table WHERE ts IN ('xxx', 'yyy')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

:

• , ;
• ;
• .

, - . . , , , , ClickHouse, : «, ! , !»

, , . , . . — SQL-, . , , .







, - time series. : , , , time series.



time series : , , timestamp . , , . . , , , — , . , , ClickHouse -, , .



, , ClickHouse:

— « », — .

time series 2 , 20 20-80 . . ClickHouse GraphiteMergeTree , time series, .

8 ClickHouse , 6 - , 2 : 2 — , . 1.8 . , 500 . , 1,8 , 500 ! .

Hadoop

2 . . 3 , CPU — 4 . , .

Process

, , , . , , ClickHouse 3 000 . , , , overkill.



, , . ClickHouse, . , , , . , 8 3–4 . — .

Present —

, ? time series, time series , , , .







Drop Detect — SQL : SQL- , , .







Anomaly Detection — . , , 2% , — 40, , , , .



— , , - , Anomaly Detection.

Anomaly Detection

, time series . : , , . time series . , , . , drop detection — , .



UI.







. - , — . -, .

Present

, , . , : 1000 — alarm, 0 — alarm. .



Anomaly Detection , . Anomaly Detection Exasol , ClickHouse. Anomaly Detection 2 , .

, , 4 .



, , , . , , . , .

HighLoad++ , HighLoad++ - . , , :)



, PHP Russia , , . , , , 1,8 /, , 1 .