サーバー分析システム

これは、分析システムに関する一連の記事の第 XNUMX 部です (パート 1 へのリンク).

今日では、慎重なデータ処理と結果の解釈が、ほぼすべての種類のビジネスに役立つことは、もはや疑いの余地がありません。 この点で、分析システムにはパラメータがますますロードされるようになり、アプリケーション内のトリガーとユーザー イベントの数が増加しています。
このため、企業は分析して健全な意思決定を行うための生の情報をアナリストにますます提供しています。 企業にとっての分析システムの重要性を過小評価すべきではなく、システム自体が信頼性があり安定している必要があります。

クライアントアナリスト

顧客分析は、企業が公式 SDK を通じて自社の Web サイトまたはアプリケーションに接続し、独自のコードベースに統合してイベント トリガーを選択するサービスです。 このアプローチには明らかな欠点があります。選択したサービスの制限により、収集されたすべてのデータが希望どおりに処理されない可能性があります。 たとえば、あるシステムでは MapReduce タスクを実行するのは簡単ではありませんが、別のシステムではモデルを実行できません。 もう XNUMX つの欠点は、サービスの定期的な (高額な) 請求額です。
市場には多くの顧客分析ソリューションがありますが、アナリストは遅かれ早かれ、あらゆるタスクに適した単一のユニバーサル サービスが存在しないという事実に直面することになります (これらすべてのサービスの価格は常に上昇しています)。 このような状況では、多くの企業は、必要なカスタム設定と機能をすべて備えた独自の分析システムを作成することを決定します。

サーバーアナリスト

サーバーサイド分析は、企業内で自社のサーバー上に (通常は) 独自の努力で導入できるサービスです。 このモデルでは、すべてのユーザー イベントが内部サーバーに保存されるため、開発者はさまざまなストレージ データベースを試して、最も便利なアーキテクチャを選択できます。 また、一部のタスクでサードパーティのクライアント分析を使用したい場合でも、それは可能です。
サーバー側分析は XNUMX つの方法で展開できます。 まず、オープンソース ユーティリティをいくつか選択し、マシンに展開してビジネス ロジックを開発します。

プロたち
コンズ

必要なものは何でもカスタマイズできます
これは多くの場合非常に困難であり、別の開発者が必要になります。

XNUMX 番目: 自分でデプロイするのではなく、SaaS サービス (Amazon、Google、Azure) を利用します。 SaaS については、第 XNUMX 回で詳しく説明します。

プロたち
コンズ

中程度の量では安くなるかもしれませんが、大幅な成長では依然として高くなりすぎるでしょう
すべてのパラメータを制御することはできません

管理は完全にサービスプロバイダーの肩に移管されます
サービスの内部に何があるかは常に知られているわけではありません (必要ない場合もあります)

サーバー分析を収集する方法

クライアント分析の使用をやめて独自の分析を構築したい場合は、まず新しいシステムのアーキテクチャをよく考える必要があります。 以下では、何を考慮する必要があるか、各ステップが必要な理由、および使用できるツールを段階的に説明します。

1. データの受信

顧客分析の場合と同様に、企業のアナリストはまず、今後調査したいイベントの種類を選択し、リストに収集します。 通常、これらのイベントは「イベント パターン」と呼ばれる特定の順序で発生します。
次に、モバイル アプリケーション (Web サイト) に通常のユーザー (デバイス) と多数のサーバーがあると想像してください。 イベントをデバイスからサーバーに安全に転送するには、中間層が必要です。 アーキテクチャによっては、複数の異なるイベント キューが存在する場合があります。
アパッチカフカ - です パブ/サブキュー、イベントを収集するためのキューとして使用されます。

による Quoraに投稿する 2014 年、Apache Kafka の作成者は、「執筆に最適化されたシステム」であることと、カフカの作品が好きだったことから、このソフトウェアにフランツ カフカにちなんで名前を付けることにしました。 — ウィキペディア

この例では、多くのデータ プロデューサーとデータ コンシューマー (デバイスとサーバー) があり、Kafka はそれらを相互に接続するのに役立ちます。 消費者については、主な主題として次のステップでさらに詳しく説明します。 ここでは、データプロデューサー (イベント) のみを考慮します。
Kafka はキューとパーティションの概念をカプセル化しています。これについては、他の場所 (たとえば、 ドキュメンテーション）。 詳細には立ち入りませんが、モバイル アプリケーションが XNUMX つの異なる OS で起動されると想像してみましょう。 次に、各バージョンが独自の個別のイベント ストリームを作成します。 プロデューサーはイベントを Kafka に送信し、イベントは適切なキューに記録されます。

（写真 故に)

同時に、Kafka を使用すると、チャンクで読み取り、イベントのストリームをミニバッチで処理できます。 Kafka は、増大するニーズ (イベントの地理位置情報など) に合わせて適切に拡張できる、非常に便利なツールです。
通常は XNUMX つのシャードで十分ですが、スケーリングすると (いつものように) 状況はさらに複雑になります。 アーキテクチャはフォールトトレラントである必要があるため、運用環境で物理シャードを XNUMX つだけ使用したいと思う人はおそらくいないでしょう。 Kafka に加えて、もう XNUMX つのよく知られたソリューションとして RabbitMQ があります。 実稼働環境ではイベント分析用のキューとして使用しませんでした (そのような経験がある場合は、コメントで教えてください!)。 ただし、AWS Kinesis を使用しました。

次のステップに進む前に、システムのもう XNUMX つの追加レイヤーである生のログ ストレージについて言及する必要があります。 これは必須のレイヤーではありませんが、何か問題が発生して Kafka のイベント キューがリセットされた場合に役立ちます。 生のログを保存するには、複雑で高価なソリューションは必要なく、正しい順序でどこか (ハード ドライブ上であっても) に書き込むだけで済みます。

2. イベントストリームの処理

すべてのイベントを準備し、適切なキューに配置した後、処理ステップに進みます。 ここでは、最も一般的な XNUMX つの処理オプションについて説明します。
最初のオプションは、Apache システムで Spark ストリーミングを有効にすることです。 すべての Apache 製品は、ファイル レプリカを備えた安全なファイル システムである HDFS 上に存在します。 Spark Streaming は、ストリーミング データを処理し、適切に拡張できる使いやすいツールです。 ただし、維持するのが難しい場合があります。
もう XNUMX つのオプションは、独自のイベント ハンドラーを構築することです。 これを行うには、たとえば、Python アプリケーションを作成し、Docker でビルドして、Kafka キューにサブスクライブする必要があります。 トリガーが Docker ハンドラーに到着すると、処理が開始されます。 この方法では、アプリケーションを常に実行しておく必要があります。
上記のオプションのいずれかを選択したと仮定して、処理自体に進みましょう。 プロセッサは、データの有効性をチェックし、ガベージや「壊れた」イベントをフィルタリングすることから始める必要があります。 検証には通常使用します ケルベロス。 この後、データ マッピングを行うことができます。異なるソースからのデータは、共通のテーブルに追加するために正規化および標準化されます。

3. データベース

XNUMX 番目のステップは、正規化されたイベントを維持することです。 既製の分析システムを使用する場合は、頻繁にアクセスする必要があるため、便利なデータベースを選択することが重要です。
データが固定スキームにうまく適合する場合は、次のいずれかを選択できます。 クリックハウス または他の列型データベース。 このようにして、集計は非常に迅速に機能します。 欠点は、スキームが厳密に固定されているため、変更せずに任意のオブジェクトを追加できないことです (たとえば、非標準のイベントが発生した場合)。 しかし、本当にすぐに数えることができます。
非構造化データの場合は、たとえば、NoSQL を使用できます。 Apache Cassandra。 HDFS 上で実行され、レプリケーションが適切に行われ、多くのインスタンスを起動でき、フォールト トレラントです。
たとえば、もっと単純なものを作成することもできます。 MongoDBの。 非常に遅く、少量の場合に適しています。 ただし、非常にシンプルであるため、始めるのに適しているという利点があります。

4. 集計

すべてのイベントを慎重に保存したら、到着したバッチからすべての重要な情報を収集し、データベースを更新します。 私たちは世界的に、関連するダッシュボードと指標を取得したいと考えています。 たとえば、イベントからユーザー プロファイルを収集し、何らかの方法で行動を測定します。 イベントは集約、収集され、(ユーザー テーブルに) 再度保存されます。 同時に、アグリゲーターコーディネーターにフィルターを接続して、特定の種類のイベントからのみユーザーを収集できるようにシステムを構築することもできます。
その後、チーム内の誰かが高度な分析のみを必要とする場合は、外部分析システムを接続できます。 ミックスパネルをもう一度受講できます。 ただし、非常に高価であるため、すべてのユーザー イベントがそこに送信されるわけではなく、必要なものだけが送信されます。 これを行うには、生のイベントや私たち自身が以前に集約したものを外部システム、API、または広告プラットフォームに転送するコーディネーターを作成する必要があります。

5. フロントエンド

作成したシステムにフロントエンドを接続する必要があります。 良い例はサービスです リダッシュは、ダッシュボードの構築に役立つデータベース GUI です。 インタラクションの仕組み:

1. ユーザーは SQL クエリを作成します。
2. それに応じて彼はサインを受け取ります。
3. それに対して「新しい視覚化」が作成され、自分用に保存できる美しいグラフが得られます。

サービス内のビジュアライゼーションは自動更新され、モニタリングをカスタマイズして追跡できます。 Redash は自己ホスト型の場合は無料ですが、SaaS の場合は月額 50 ドルかかります。

まとめ

上記の手順をすべて完了したら、サーバー分析を作成します。 すべてを自分で構成する必要があるため、これは単に顧客分析を接続するほど単純ではないことに注意してください。 したがって、独自のシステムを作成する前に、本格的な分析システムの必要性と、それに割り当てられるリソースを比較する価値があります。
計算を行った結果、コストが高すぎることがわかった場合は、次のパートで、サーバー側分析の安価なバージョンを作成する方法について説明します。

読んでくれてありがとう！ コメントでご質問いただければ幸いです。

出所： habr.com