詐欺防止の要因の計算。Yandexレポート

Antifraudは、他の公的なYandexサービスの悪用の事例を見つけて中和するためのサービスです。3年前に、社内のどこにでも不正防止を迅速かつ簡単に展開できるプラットフォームの設計を開始しました。タスクの複雑さは、多くのサービスが速度、信頼性、品質について最も厳しい保証を必要とすることです。それらのいくつかは、非常に大量のデータを操作します。一方、不正防止チームは、システムの柔軟性、サポートの容易さ、機械学習の基礎となる要素の表現力に関心を持っています。





不正防止ヘッドAndrey Popov Nox_andryこれらの矛盾する要件すべてをどのように満たすことができたかについてプレゼンテーションを行いました。レポートの中心的なトピックは、データストリームの複雑な要素を計算し、システムのフォールトトレランスを確保するためのモデルです。アンドレイはまた、現在開発中の詐欺対策の次の、より高速な反復についても簡単に説明しました。



詐欺防止チームは本質的にバイナリ分類問題を解決します。したがって、このレポートは、不正防止の専門家だけでなく、大量のデータに対して高速で信頼性が高く柔軟な要素を必要とするさまざまなシステムを作成する人にとっても興味深いものになる可能性があります。



-こんにちは、私の名前はアンドレイです。私はYandexで働いており、不正防止の開発を担当しています。人々は「機能」という言葉を使うことを好むと言われたので、話全体を通してそれを言及しますが、タイトルと紹介は「ファクター」という言葉で同じままでした。

詐欺対策とは何ですか？

とにかく詐欺対策とは何ですか？サービスへの悪影響からユーザーを保護するシステムです。マイナスの影響とは、サービスの品質を低下させ、結果としてユーザーエクスペリエンスを悪化させる可能性のある意図的なアクションを意味します。これらは、統計を悪化させるかなり単純なパーサーやロボット、または意図的に複雑な詐欺行為である可能性があります。もちろん、2番目は、定義するのがより難しく、興味深いものです。



詐欺対策は何と戦うのですか？いくつかの例。



たとえば、ユーザーアクションの模倣。これは、私たちが「ブラックSEO」と呼んでいる人たち、つまりサイトやサイトのコンテンツの品質を向上させたくない人たちによって行われます。代わりに、彼らはYandex検索に行くロボットを書き、彼らのサイトをクリックします。彼らは自分のサイトがこのように高くなることを期待しています。念のため、このような行為はユーザーの同意に反し、Yandexからの重大な制裁につながる可能性があります。







または、たとえば、不正行為のレビュー。このようなレビューは、プラスチック製の窓を設置するマップの組織から見ることができます。彼女自身がこのレビューに支払った。



トップレベルの不正防止アーキテクチャは次のようになります。特定の生のイベントセットがブラックボックスのように不正防止システム自体に分類されます。その出口で、タグ付けされたイベントが生成されます。



Yandexには多くのサービスがあります。それらすべて、特に大規模なものは、さまざまな種類の詐欺に直面しています。検索、マーケティング、マップ、その他多数。



私たちは2年か3年前にどこにいましたか？各チームは、詐欺の猛攻撃下で​​可能な限り生き残った。彼女は詐欺対策チームを作り、彼女のシステムは必ずしもうまく機能しなかったため、アナリストとのやり取りにはあまり便利ではありませんでした。そして最も重要なのは、それらが互いに十分に統合されていないことです。



単一のプラットフォームを作成することでこれをどのように解決したかをお話します。







なぜ単一のプラットフォームが必要なのですか？経験とデータの再利用。エクスペリエンスとデータを1か所に集中化すると、大規模な攻撃に迅速かつ適切に対応できます。これらは通常、クロスサービスです。



統合ツールキット。人々は使い慣れたツールを持っています。そして明らかに接続速度。現在積極的に攻撃されている新しいサービスを開始した場合、高品質の不正防止サービスを迅速に接続する必要があります。



この点で私たちはユニークではないと言えるでしょう。すべての大企業が同様の問題に直面しています。そして、私たちがコミュニケーションをとる誰もが、彼らの単一のプラットフォームを作成します。



不正防止の分類について少しお話します。







これは、複雑なクラスタリングや複雑な再トレーニングなど、時間、日、負荷の高いオフラインプロセスをカウントするオフラインシステムにすることができます。レポートではこの部分については実質的に触れません。数分で動作するほぼリアルタイムのパーツがあります。これは一種の黄金の意味であり、彼女は素早い反応と重い方法を持っています。まず、私は彼女に焦点を当てます。ただし、この段階では上の段階のデータを使用していると言うことも同様に重要です。



また、迅速な対応が必要で、イベントを受け取ってユーザーに渡す前であっても、不正を排除することが重要な場所で必要となるオンラインのパーツもあります。ここでは、より高いレベルで計算されたデータと機械学習アルゴリズムを再利用します。



この統合プラットフォームのしくみ、機能を説明しシステムと対話するための言語、速度を上げるための私たちの道、つまり、第2段階から第3段階への移行についてお話します。



MLメソッド自体についてはほとんど触れません。基本的には、トレーニングで使用する機能を作成するプラットフォームについて説明します。



誰がこれに興味がありますか？明らかに、詐欺​​対策を書いたり、詐欺師と戦ったりする人にとっては。しかし、データストリームを開始して機能を読み取るだけの人にも、MLは検討しています。私たちはかなり一般的なシステムを作成したので、多分あなたはこれのいくつかに興味を持つでしょう。



システム要件は何ですか？それらのかなりの数があります、それらのいくつかはここにあります：

• 大きなデータストリーム。何億ものイベントを5分で処理します。
• 完全に構成可能な機能。
• .
• , - exactly-once- , . — , , , , .
• , , .

さらに、これらの各ポイントについて個別に説明します。



セキュリティ上の理由から実際のサービスについて話すことができないので、新しいYandexサービスを紹介しましょう。実はそうではありません。これは、例を示すために思いついた架空のサービスです。既存のすべての本のデータベースを人々に提供するサービスとしましょう。彼らは入ってきて、1から10までの評価を与え、攻撃者は彼らの本が購入されるように最終的な評価に影響を与えたいと考えています。



もちろん、実際のサービスとの偶然はすべてランダムです。ここでは最初の概算ではオンラインは特に必要ないため、まずリアルタイムに近いバージョンを検討してみましょう。

ビッグデータ

Yandexには、ビッグデータの問題を解決する古典的な方法があります。MapReduceを使用します。YTと呼ばれる独自のMapReduce実装を使用します。ところで、マキシムアフメドフは今夜彼女についての話をしています。実装またはHadoopのようなオープンソース実装を使用できます。



すぐにオンライン版を使用しないのはなぜですか？これは常に必要なわけではなく、過去の再計算を複雑にする可能性があります。新しいアルゴリズム、新しい機能を追加した場合、そのデータの判定を変更するために、過去のデータを再計算することがよくあります。ヘビーウェイトメソッドを使用するのは困難です。その理由は明らかです。そして、オンライン版は、多くの理由で、リソースの面でより厳しい場合があります。



MapReduceを使用すると、次のようになります。一種のミニバッチ処理を使用します。つまり、バッチを可能な限り最小の部分に分割します。この場合は1分です。しかし、MapReduceを使用するユーザーは、おそらくこのサイズよりも小さいため、システム自体のオーバーヘッド（オーバーヘッド）がすでに大きすぎることを知っています。従来1分での処理には対応できません。



次に、この一連のバッチに対してReduceセットを実行し、マークアップされたバッチを取得します。







私たちのタスクでは、機能の正確な値を計算する必要があることがよくあります。たとえば、ユーザーが先月読んだ本の正確な数を計算する場合は、バッチごとにこの値を計算し、収集したすべての統計を1か所に保存する必要があります。そして、古い値を削除して新しい値を追加します。



大まかなカウント方法を使用しないのはなぜですか？短い答え：私たちはそれらも使用しますが、不正防止の問題では、いくつかの間隔で正確な値を持つことが重要な場合があります。たとえば、2冊の本と3冊の本の違いは、特定の方法では非常に重要です。



結果として、これらの統計を保存する大量のデータ履歴が必要になります。







「真正面から」やってみよう。 1分と大きな古い話があります。それを削減入力に入れ、更新された履歴とマークアップされたログ、データを出力します。



MapReduceを使用したことがある人は、おそらくこれがかなりうまく機能しないことを知っているでしょう。履歴がバッチ自体よりも数百倍、さらには数千倍、数万倍大きくなる可能性がある場合、そのような処理は、バッチのサイズではなく、履歴のサイズに比例して機能します。







これをいくつかのKey-Valueストアに置き換えましょう。これもまた、独自の実装であるKey-Valueストレージですが、データをメモリに格納します。おそらく最も近いアナログは、ある種のRedisです。ただし、ここでは若干の利点があります。Key-Valueストアの実装は、MapReduceと、それが実行されるMapReduceクラスタと緊密に統合されています。便利なトランザクション性、それらの間の便利なデータ転送がわかります。



ただし、一般的なスキームでは、このReduceの各ジョブで、このキーと値のストレージに移動し、データを更新して、判定を行った後で書き戻します。



最終的には、必要なキーのみを処理し、簡単に拡張できるストーリーになります。

構成可能な機能

機能の設定方法について少し。多くの場合、単純なカウンターでは不十分です。詐欺師を検索するには、さまざまな機能が必要です。詐欺師を設定するためのスマートで便利なシステムが必要です。



それを3つのステップに分解しましょう：

• 抽出。ここでは、指定されたキーのデータをログから抽出します。
• マージ。このデータを履歴にある統計とマージします。
• ビルド。機能の最終的な値を形成します。

たとえば、ユーザーが読んだ探偵小説の割合を計算してみましょう。







ユーザーがあまりにも多くの探偵小説を読んだ場合、彼は余りに不審です。彼に何を期待するかははっきりしない。次に、Extractは、ユーザーがこのバッチで読み取った探偵の数を削除します。マージ-すべての探偵、1か月間のバッチからのこのすべてのデータを取得します。そしてビルドはある程度です。



次に、彼が読んだすべての本の価値についても同じことを行い、最終的には除算を行います。



たとえば、ユーザーが読むさまざまな著者の数など、さまざまな値をカウントしたい場合はどうでしょうか。











次に、ユーザーがこのバッチで読んださまざまな著者の数を取得できます。さらに、ユーザーが読んだときに著者の関連付けを最近行う場所の構造を保存します。したがって、ユーザーでこの作成者に再度会った場合は、今回更新します。古いイベントを削除する必要がある場合は、何を削除するかがわかっています。最終的な特徴を計算するには、その中のキーの数を数えるだけです。







しかし、ノイズの多い信号では、そのようなフィーチャは1つのカットには不十分です。結合を接着し、異なるカットからこれらのフィーチャを接着するためのシステムが必要です。



たとえば、そのようなカットを紹介しましょう-ユーザー、作者、ジャンル。







難しいことを計算してみましょう。たとえば、平均的な作者の忠誠心。忠誠心によって、私はその作者を読んだユーザーを意味します-彼らはほとんどそれだけを読みました。さらに、この平均値は、それを読んだユーザーが読んだ作家の平均数に対して非常に低くなっています。



これは潜在的なシグナルである可能性があります。もちろん、彼は作者がそのとおりであることを意味する可能性があります。彼の周りにはファンだけがいて、彼を読む人はすべて彼だけを読んでいます。しかし、それは、作者自身がシステムをだまして、おそらくそれを読むこれらの偽のユーザーを作成しようとしていることも意味します。



計算してみましょう。長い間隔で異なる作者の数を数える機能を数えましょう。たとえば、ここでは2番目と3番目の値が疑わしいと思われますが、それらの数は少なすぎます。







次に、長い間隔で関連している著者の平均値を計算します。そして、ここでも平均値は非常に低いです：3.何らかの理由で、この著者は私たちに疑わしいようです。







そして、この特定のユーザーが作成者との関係を持っていることを理解するために、それをユーザーに戻すことができます。



これ自体は、ユーザーをフィルターする必要があるという明確な基準にすることはできないことは明らかです。しかし、これは私たちが使用できる信号の1つかもしれません。



MapReduceパラダイムでこれを行う方法は？いくつかの連続した削減とそれらの間の依存関係を作ってみましょう。







削減のグラフが表示されます。これは、どのスライスをカウントするか、どの結合が一般的に許可されるか、消費されるリソースの量に影響します。明らかに、削減が増えるほど、リソースも増えます。レイテンシ、スループット。



たとえば、このようなグラフを作成してみましょう。







つまり、削減を2つの段階に分割します。最初の段階では、ユーザー、著者、ジャンルなど、セクションごとに異なる削減を並行して計算します。そして、これらのさまざまな削減から機能を収集し、最終的な評決を受け入れる、何らかの第2段階が必要です。



次のバッチでも同じことを行います。また、各バッチの第1ステージは過去の第1ステージに依存し、第2ステージは過去の第2ステージに依存しています。



ここでは、そのような依存関係がないことが重要です。







つまり、実際にはコンベヤーを取得します。つまり、次のバッチの最初のステージは、最初のバッチの2番目のステージと並行して動作できます。



ステージが2つしかない場合、上記で示した3段階の統計をどのように作成できますか？とても簡単です。バッチN







の最初のステージで最初の値を読み取ることができます。バッチの最初のステージで2番目の値はN + 1であり、最終値はバッチN + 1の2番目のステージで読み取る必要があります。したがって、第1ステージと第2ステージの間の移行中に、N + 1バッチの統計がおそらく正確ではない可能性があります。しかし、通常、このような計算にはこれで十分です。







これらすべてを備えているため、キューブからより複雑な機能を構築できます。たとえば、ユーザーの平均評価からの本の現在の評価の偏差。または、非常に肯定的または非常に否定的に本を評価するユーザーの割合。また、疑わしい。または、異なる本に対してNを超える評価を持つユーザーによる平均の本の評価。これはおそらく、ある観点からはより正確で公正な評価です。







これに追加されるのが、イベント間の関係です。多くの場合、私たちに送信されるログまたはデータに重複が表示されます。これらは、技術的なイベントまたはロボットの動作のいずれかです。このような重複も検出されます。または、たとえば、いくつかの関連イベント。システムが書籍の推奨事項を表示し、ユーザーがこれらの推奨事項をクリックするとします。ランキングに影響を与える最終的な統計情報が損なわれないように、インプレッションをフィルタリングする場合は、現在の推奨事項のクリックもフィルタリングする必要があることを確認する必要があります。



しかし、フローが不均一になる可能性があるため、最初にクリックすると、ショーが表示されるまでフローを延期し、それに基づいて評決を受け入れる必要があります。

機能説明言語

このすべてを説明するために使用される言語について少しお話します。







あなたはそれを読む必要はありません、これは例えばです。 3つの主要コンポーネントから始めました。 1つ目は、一般的に言えば、任意のタイプの履歴内のデータ単位の説明です。







これは、ある種の機能であり、null許容値です。







そして、ある種のルール。ルールとは何ですか？これは、これらの機能やその他の条件のセットです。 3つの別々のファイルがありました。



問題は、ここでは一連のアクションが異なるファイルに分散していることです。多くのアナリストが私たちのシステムで作業する必要があります。彼らは不快でした。



言語は必須であることがわかります。データを計算する方法を説明します。計算する必要があるものを説明するときは、宣言型ではありません。これもあまり便利ではありません。間違いを犯しやすく、エントリのしきい値が高くなります。新しい人がやって来るが、彼らはどうやってそれを扱うのか全く理解していない。



解決策-独自のDSLを作成しましょう。それは私たちのシナリオをより明確に説明し、新しい人にとってはより簡単で、より高レベルです。 SQLAlchemy、C＃Linqなどからインスピレーションを得ました。



上記と同様の例をいくつか挙げます。







読んだ探偵小説の割合。読んだ本の数、つまりユーザーごとにグループ化します。この条件にフィルターを追加し、最終的なパーセンテージを計算したい場合は、評価を計算します。すべてがシンプルで明確で直感的です。







異なる著者の数を数える場合、ユーザーごとにグループ化し、個別の著者を設定します。これに、いくつかの条件、たとえば、計算ウィンドウや、メモリの制約のために保存する値の数の制限などを追加できます。結果として、count、その中のキーの数を数えます。







または私が話していた平均的な忠誠心。つまり、上から計算されたある種の式があります。著者ごとにグループ化し、これらの式の平均値を設定します。次に、ユーザーに絞り込みます。







これにフィルター条件を追加できます。つまり、たとえば次のようなフィルターを使用できます。忠誠度が高すぎず、探偵のパーセンテージが100のうち80の範囲にある。



これを内部で何に使用するか。







内部では、フレックス、バイソンなど、70年代の最新テクノロジーを直接使用しています。多分あなたは聞いた。彼らはコードを生成します。コードファイルは、Flexで生成されたレクサーと、Bisonで生成されたパーサーを通過します。レクサーは言語の終端記号または単語を生成し、パーサーは構文式を生成します。



これから、すでに構文変換を実行できる抽象構文ツリーを取得します。そして最終的には、システムが理解できる低レベルのファイルに変換します。



結果はどうですか？これは、一見したところよりも複雑です。運用の優先順位やエッジケースなどの小さなことを考えるには、多くのリソースが必要です。もちろん、コンパイラーを書かない限り、実際に役立つとは思えないまれなテクノロジーを学ぶ必要があります。しかし、結局それは価値があります。つまり、私たちのように、他のチームから頻繁に来るアナリストが多数いる場合は、結局、作業しやすくなるため、これは大きな利点になります。

信頼性

一部のサービスは、フォールトトレランスを必要とします：クロスDCおよび1回限りの処理違反は、金銭的損失を含む統計と損失の不一致を引き起こす可能性があります。 MapReduceのソリューションでは、一度に1つのクラスターでのみデータを読み取り、2番目のクラスターで同期します。







たとえば、ここではどのように動作しますか？リーダー、フォロワー、メッセージブローカーがいます。これは条件付きのカフカであると考えることができますが、ここではもちろん、それ自体が実装されています。







バッチを両方のクラスターに配信し、同じリーダーで一連の削減を開始し、最終的な判定を受け入れ、履歴を更新して、結果をサービスに送信し、メッセージブローカーに送信します。



たまに、私たちは自然に複製を行わなければなりません。つまり、スナップショットを収集し、変更を収集します-各バッチの変更。両方を2番目のクラスターフォロワーに同期させます。そして、とても熱い物語を育てる。ここで履歴が記憶されていることを思い出させてください。



したがって、何らかの理由で1つのDCが使用できなくなった場合は、遅延を最小限に抑えて2番目のクラスターに切り替えることができます。



2つのクラスターを並行して数えるのはどうですか？外部データは2つのクラスターで異なる可能性があり、外部サービスによって提供できます。とにかく外部データとは何ですか？これは、この高いレベルから立ち上がるものです。つまり、複雑なクラスタリングなどです。または、計算のための単なるデータ補助です。



合意されたソリューションが必要です。異なるデータを使用して判定を並行してカウントし、2つの異なるクラスターからの結果を定期的に切り替えると、それらの間の一貫性は劇的に低下します。そしてもちろん、資源を節約します。一度に1つのクラスターでのみCPUリソースを使用するため。



2番目のクラスターはどうですか？私たちが働いているとき、彼は実質的にアイドル状態です。彼のリソースを本格的なプリプロダクションに使用しましょう。本格的なプリプロダクションとは、ここでは、同じデータストリームを受け入れ、同じデータボリュームで動作する本格的なインストールなどを意味します。







クラスターが利用できない場合、これらのインストールをセールからプリプロダクションに変更します。したがって、しばらくの間はpreprodがありますが、それでも問題ありません。



利点は、前処理でより多くの機能をカウントできることです。なぜこれが必要なのですか？大量の機能を数えたい場合、販売されているすべての機能を数える必要がないことは明らかです。そこでは、最終的な評決を得るために必要なものだけを数えます。



（00:25:12）



しかし、同時に、前処理には、さまざまな機能を備えた一種のホットキャッシュがあります。攻撃の場合は、それを使用して問題を閉じ、これらの機能を本番環境に転送できます。



これに加えて、B2Bテストの利点があります。つまり、私たちは皆、もちろん最初にプレセールを開始します。違いを完全に比較するため、間違いを犯すことはなく、販売のために展開するときに間違いを犯す可能性を最小限に抑えます。



スケジューラについて少し。 MapReduceでタスクを実行するマシンの種類があることは明らかです。これらはある種の労働者です。彼らは定期的にデータをCross-DCデータベースに同期します。これは、彼らが現時点で何とか計算した状態です。







ワーカーが利用できなくなった場合、別のワーカーがログをキャプチャしようとし、状態を取得します。







それから立ち上がって働き続けます。このMapReduceでタスクの設定を続けます。







これらのタスクをオーバーライドする場合、一部のタスクが再起動される可能性があることは明らかです。したがって、ここで私たちにとって非常に重要な特性があります。べき等性、影響なしに各操作を再開できることです。



つまり、すべてのコードは、これが適切に機能するように記述する必要があります。







正確に1回について少しお話します。私たちは協調して評決に達していますが、これは非常に重要です。私たちはそのような保証を与えるテクノロジーを使用しており、当然、すべての差異を監視してゼロにまで減らします。これがすでに削減されているように見えても、時折、考慮に入れなかった非常にトリッキーな問題が発生します。

楽器

使用するツールについて簡単に説明します。さまざまなシステムで複数の不正対策を維持することは困難な作業です。私たちは文字通り数十の異なるサービスを持っています、私たちはあなたが現在彼らの仕事の状態を見ることができるある種の単一の場所が必要です。







これがコマンドポストです。ここでは、現在作業しているクラスターのステータスを確認できます。それらを相互に切り替えたり、リリースを公開したりすることができます。







または、たとえば、問題のダッシュボードでは、接続されているさまざまなサービスのすべての不正防止に関するすべての問題が1ページにすぐに表示されます。ここで、現時点でBookサービスに明らかに問題があることがわかります。しかし、監視は機能し、担当者はそれを確認します。







私たちは何を監視していますか？明らかに、システムラグは非常に重要です。もちろん、個々のステージの実行時間、そしてもちろん、個々のルールのフィルタリング。これはビジネス要件です。



何百ものグラフとダッシュボードが表示されます。たとえば、このダッシュボードでは、かなりの遅れが生じたため、輪郭が十分に悪いことがわかります。

速度

オンライン部分への移行についてお話します。ここでの問題は、回路全体の遅延が数分に達する可能性があることです。それはMapReduceの概要にあります。場合によっては、私たちは禁止し、詐欺師をより早く検出する必要があります。



どうなり得るか？たとえば、私たちのサービスは現在、本を購入する機能を備えています。同時に、新しいタイプの支払い詐欺も登場しています。もっと早く反応する必要があります。問題が発生します-理想的にはアナリストに馴染みのあるインタラクションの言語を可能な限り維持しながら、このスキーム全体をどのように転送するのですか？ 「おでこ」に転送してみましょう。







サービスからのデータを含むバランサーと、バランサーからのデータをシャーディングする特定の数のワーカーがあるとします。ここで使用する外部データがあり、それらは非常に重要であり、これらのストーリーのセットです。キーが異なるため、このようなストーリーは削減ごとに異なります。



このようなスキームでは、以下の問題が発生する可能性があります。







ワーカーで2つのイベントがあるとします。この場合、これらのワーカーのシャーディングにより、1つのキーが別のワーカーに渡される場合があります。この場合、これは作者Tolkienです。彼は2人の労働者に入りました。



次に、このKey-Valueストレージから履歴から両方のワーカーにデータを読み取り、さまざまな方法で更新します。書き戻しを試みると競合が発生します。



解決策：読み取りと書き込みを分離でき、書き込みは少し遅れて発生する可能性があると仮定します。これは通常、あまり重要ではありません。ここでの遅延とは、秒単位を意味します。このKey-Valueストアの実装では、データの読み取りよりもデータの書き込みに時間がかかるため、これは特に重要です。



ラグを付けて統計を更新します。マシン上でキャッシュされた状態を維持するという事実を考えると、平均して、これは多かれ少なかれうまく機能します。







そしてもう一つ。簡単にするために、これらのストーリーを1つにマージして、カットのタイプとキーでメモしてみましょう。ある種の共通の歴史があります。



次に、バランサーを再度追加し、リーダーのマシンを追加します。これは、たとえば、単に負荷によってシャーディングすることができます。彼らは単にこのデータを読み取り、最終的な判定を受け入れ、それらをバランサーに返します。



この場合、このデータが直接送信されるライターマシンのセットが必要です。作家はそれに応じて物語を更新します。しかし、ここでも問題が発生します。これについては、上記で説明しました。では、ライターの構成を少し変えてみましょう。







キーのタイプと値によって、履歴と同じ方法で分割されるようにします。この場合、そのシャーディングが履歴と同じであれば、上記の問題は発生しません。



ここで彼の使命が変わります。彼はもはや評決を受け入れません。代わりに、リーダーからの更新を受け入れ、それらを混合し、履歴に正しく適用します。



ここでコンポーネントが必要であることは明らかです。コンポーネントは、リーダーとライターの間でこれらの更新を配布するコーディネーターです。



もちろん、これには、ワーカーが最新のキャッシュを維持する必要があるという事実が追加されます。その結果、私たちは数百ミリ秒、場合によってはそれ以下の時間を担当していることがわかり、統計情報を1秒で更新しています。一般的には十分に機能しますが、サービスには十分です。







何を手に入れましたか？アナリストは、すべてのサービスについて同じように、より速く仕事を始めました。これにより、すべてのシステムの品質と接続性が向上しました。さまざまなサービスの不正防止の間でデータを再利用でき、新しいサービスは高品質の不正防止をすばやく実現します。







最後にいくつかの考え。そのようなものを書いたら、これらのシステムのサポートと拡張性の観点から、アナリストの便利さをすぐに考えてください。すべてを構成可能にしてください。必要です。場合によっては、DC間および1回限りのプロパティを実現することは困難ですが、実現することはできます。すでに達成していると思われる場合は、再確認してください。ご清聴ありがとうございました。