AppMetricaのLogs APIを使用した作業の自動化。 Yandexでの講義

AppMetricaが収集するデータは、分析だけでなく、好きなように機能させることができます。 ユーザーの行動に直接または間接的に関連する多くのプロセスを自動化できます。 開発者のNikolay Volosatovは、アップロードの設定方法、使用できるデータの種類、Logs APIの開発時に遭遇した落とし穴について話しました。





-私の名前はニコライ・ヴォロサトフです。Yandexモバイル開発部門で働いています。 特に、iOS SDK AppMetricaを開発しています。 私は3年以上働いています。



本日は、AppMetricaを統合していても、聞いたことがないか聞いたことがあるかもしれませんが、一度も使用したことがない機能について説明します。 このサービスはLogs APIと呼ばれ、集計されていないデータをアップロードできます。 この製品の有用性、使用方法、この製品について知っておくべきすべてのことを説明します。 また、APIデータの処理を自動化するツールの開発中に遭遇したこと、微妙な点、これらすべての背後にある困難についても説明します。 製品自体とその機能の両方に興味を持っています。これについてはお話しします。



AppMetricaは、モバイルアプリケーション向けの汎用分析ツールです。 インストールや広告キャンペーンからクラッシュログまでの分析を行うことができます。それだけです。 また、すべての主要プラットフォーム（iOS、Android、Windows Phone）のSDKとしても提供されます。 また、Unity、Cordova、Xamarinのプラグインの形で。



SDK自体について詳しく説明することはできませんが、このサイトではドキュメントやその他のレポートを見ることができます。Subbotnikiでこの製品について話しているところです。 あなたはそれを学ぶことができます-あなたのモバイルアプリケーションで役に立つかもしれません。



本日は、製品のあまり知られていない機能、つまり非集計データのアップロードについてお話します。 これは何ですか サービスによって収集されたすべてのデータを使用して、Webでレポートを作成します。これにより、傾向やアプリケーションの動作を監視、監視できます。 ただし、このすべてのデータは、データが保存されている非集計形式でアンロードし、必要に応じてユーザーに提供することもできます。



どのデータを使用できますか？ まず、広告キャンペーンに関する情報。 ユーザーはリンクをクリックし、ストアにアクセスしてアプリケーションをインストールします。すべての情報があります。たとえば、広告キャンペーンの効果を分析したり、目標を設定したり、監視したりするための内部サービスと統合したりできます。 アプリケーションがどのように正確にどこからインストールされているかに関する情報を拡張できます。これは効率的に機能します。 さらに、これが新しいかどうかに関する情報は、アプリケーションのインストールまたは再インストールです。



より広いアプリケーションは、アプリケーションコードで送信されたイベントに関する情報であり、Webでさらに分析できます。



ユーザーセッションの開始とともに、ユーザーがアプリケーションの操作を開始したとき、セッションを初めて開いたとき、またはセッションタイムアウト後に展開したとき、これらのデータはすべて、アプリケーション内でのユーザーの行動を分析し、画面をどのように歩き回るかを分析するのに便利ですそれがいかに効果的に販売につながるかについて長引く。 セールスファネル。 あなたが使用できるものに加えて、これらすべての情報は、あなたが広告キャンペーンを行うパートナーにとって有用です。



別の興味深い機能は、クラッシュとエラーのアンロードです。 ここには創造性の余地もあります。たとえば、課題トラッカーと統合したり、企業のメッセンジャーと統合したり、通知をSlackに送信したりできます。 新しいクラッシュが発生した場合は、この情報を収集し、チケットを開始し、クラッシュが発生した回数に関するレポートを週に1回そこに書き込むことができます。 また、クラッシュが修正されると、統合にも通知が届きます。



さらに、プッシュ通知をアプリケーションに送信するために必要な情報をアップロードできます。 当社のサービスでは、SDKがユーザーをフィルタリングできるすべてのセグメントにプッシュを送信できます。 しかし、これで十分でない場合、またはプッシャの送信に関して非常に具体的な好みがある場合は、自分で送信したり、自分で送信したりできます。





アップロードインターフェイスは非常にシンプルです。 これは、開発だけでなく、一般的にコンピューターで作業することからもほど遠い人が使用できます。 単純なサイト、メトリック、データエクスポート、データタイプ、フォーマット、必要なデータ、時間間隔、フィールド、フィルターからのWebフェイス。 CSVおよびJSONアップロード形式がサポートされています。 [データの生成]をクリックし、データ処理キューが通過するまで待ちます。 回答が生成され、通常のファイルが取得されます。





フードの下には何がありますか？ 端末を介して行うことにした場合、リクエストは非常に簡単です。 サービスへの定期的なGETリクエストを作成します。 これには、認証トークン、単純なOAuthトークン、およびすべての同じフィールド（必要なデータ、フィルター、フィールド、列）が必要です。 要求を行うと、202のHTTP応答コードを受け取ります。すべてが正常であれば、要求はキューに入れられ、データの生成中に要求ごとに202を受け取ります。 または、エラーコードを含む何らかの種類の回答：403-認証エラー、200-フィールドが間違ったデータに属している場合に誤って生成されたリクエスト、239-クォータを超えました。



並行して、アプリケーションごとに3つの要求を作成できます。 複数のアプリケーションがある場合は、さらにリクエストを行うことができます。 アップロードされるデータのサイズは5 GBを超えないようにしてください。 それでも制限時間を超えることができるという事実に関連して、何らかの方法でクエリを中断し、選択を減らす方法を学ぶ必要があります。 ただし、ビッグデータを取得する必要があり、何かをフィルタリングしたりフィールドを少なくしたりできない場合は、リクエストを複数の部分に単純に分割する機能が役立ちます。 2つの新しいパラメーター、parts_countおよびpart_number。 データセット全体を1つずつ繰り返し、アップロードします。 サーバーによって応答が生成されると、200を受け取り、応答の本文に必要なすべてのデータを受け取ります。



シンプルに見えますが、自動化してみましょう。 ほとんどの場合、販売目標到達プロセスであれ、クラッシュ分析であれ、分析拡張機能を開発しているときに自動化する必要があります。





ほとんどの場合、3つの部分で構成されます。 ページングされたデータ、アップロードスクリプト自体、およびインターフェイスを保存するデータベースが必要です。 これが何らかの分析である場合、Webインターフェースです。 インスタントメッセンジャーまたは課題追跡システムとの統合が製品の仮想インターフェイスである場合、レポートおよびもちろんクエリをデータベースに送信します。



実装したアップロードスクリプトでは、データベースとして使用する最も論理的なものとして使用することにしました。 バックエンドで使用されるもの。 これはClickHouseデータベースであり、どこかで聞いたことがあるかもしれません。 おそらく本番環境で使用することもできます。 CERNでは、ある種の分析、頻繁なイベントを保存するために設計された素晴らしいデータベースも使用されています。 このデータベースにより、分散作業中にデータを挿入、選択、選択するための驚くほど高速なクエリを作成できます。



データはそれほど大きくなく、一度に5 GBしかありませんが、これらの統計を何年もアップロードした場合、最終的にはレポートを作成するために高速化が必要になります。 次に必要なのは、インターフェイスとそれにクエリを作成することです。 これについての記事が準備されており、同じ販売目標到達プロセスのツールを開発したMaria Mansurova miptgirlによってHabréでリリースされます。



今日は、この種のデータのロードの更新に関連するニュアンスに、アンロードに焦点を当てます。 オートメーションインターフェイスの開発中に発生する可能性のある問題を調べてみましょう。



最初に出会ったのは、大量のデータです。 2017年、5 GBの大容量を呼び出すことは冒aspですが、アップロード用のスクリプトを開発することは、Amazonの最小インスタンスでも、ガレージ内のマシンでも、最小環境で動作することを意味します。 どこにでも垂れ下がるのではなく、すべてをRAMに収める必要があります。 また、同じマシン上でClickHouseがまだ回転している場合、問題が発生し、データベースに一度に5 GBを挿入できません。



受け取ったデータを破壊することを学ぶ必要があります。 CSVをアンロードします。それはストリーミングであり、ラインに勝つことができます。 これを手動で行うことは非常に困難です。 CSVパーサーを作成するために書いた人は誰でも、新しい行を分割するのはそれほど簡単ではないことを理解しています。



パンダを使用します。スクリプトはPythonで記述されています。 Pythonでデータを扱う人は誰でもこのライブラリを知っています。 読み取りCSVメソッドは、この種の問題に対して十分な柔軟性を備えています。





これは、大きなリクエストを細かく分割するコードの一部です。 ネットワークからのストリームは、入力、APIからのストリーム、および出力に供給され、n行のチャンクを持つ反復子を取得します。 非常に簡単：一度に必要なRAMの量を減らしました。



次の問題はデータの更新です。 ここでは、サービスがその構造と性質でどのようなデータを提供するかを確認する必要があります。





一時的な性質に応じて、いくつかのグループに分けることができます。 1つ目は、サーバー上で生成され、そこに保存されるサーバーデータです。 最小限の遅延が発生します。 イベントが発生し、クリックが発生し、Logs APIを介してアップロードできます。



それとは別に、プッシュトークンがあります。 3週間前にプッシュトークンをアンロードすることはできません。 それらは発行された関連性があるだけで、特別な権利についてここにあります。



そして-Logs APIからの応答の重要な部分は、クライアント、モバイルアプリケーションからのものです。これは論理的です。これはモバイル分析です。 ここで、クライアントデータが遅れて到着する可能性があるという問題に直面しています。 遅延は最大7日間です。 データは後で到着する可能性がありますが、Logs APIには提供されず、すでに古くなっていると見なされます。 これは、ユーザーが常にインターネットを持っているわけではなく、デバイスリソースとトラフィックの両方を節約するためにすぐにイベントを送信するわけではないという事実によるものです。リクエストのどこかにサービス情報があるためです。 これらはすべてデータを更新する必要があり、1週間以上前のデータはアーカイブ対象と見なしていることに留意してください。 それらはもう変更されませんが、今週は問題のあるデータであり、更新する必要があり、過去7日間で更新されます。





ClickHouseを使用していることを思い出すと、データの更新はそれほど簡単ではありません。 ClickHouseベースは、データが何らかの形で変更されるようには設計されていません。 データは分析用に設計されているため、この機能はすべての人に適しています。 変更はないはずです。





私たちに最初に起こった決定は、別のテーブルにアップロードすることでした。 ある日、別のテーブルにアップロードしてから、持っているデータを使用して差分を作成し、それをアンロードした運用データベースに追加するとします。



このソリューションは機能します。 小さなデータでも、非常に高速に動作します。 しかし、何年間データをアップロードできるかを考えると、ダウンロードしたものと持っているものとの違いを構築するためのリクエストには、かなりの時間がかかります。 ClickHouseはこれに対応できません。このような大きなデータベースを作成する場合、このソリューションはうまく拡張できません。これは基本的に問題です。



ClickHouseは、興味深い機会を提供します。次のようにデータをアップロードします-過去7日間から毎日、別のテーブルにアップロードします。 7日以上経過したすべてのデータは別のアーカイブテーブルに保存され、更新の場合は、それ以上更新されないテーブルが削除されます。



これを使いやすくするために、ClickHouseにはマージテーブルエンジンを備えた素晴らしい仮想テーブルがあります。 これは仮想テーブルであり、正規表現に基づいてテーブルのすべてのデータを結合する要求を行うときに自宅のどこかにあります。 このテーブルを再作成する必要はありません。新しいテーブルと変更中のテーブルを自動的に取得します。



さて、ある日更新するためには、古いと思われるテーブルを破棄し、再度ダウンロードするだけで十分です。 テーブルが更新されなくなった場合、古いデータをすべて破棄し、削除します。 今、ClickHouseは幸せです。 このソリューションは拡張性が高く、複雑なデータ挿入クエリを必要としません。



次の問題に進むことができます。 次の質問はステートフルでした。 これは些細なことのように思えるかもしれませんが、ツールの開発中は、スクリプトが正常に動作し、データをスキップせず、複製し、問題が発生した場合に全世界に過負荷をかけずにすべてが十分に高速に動作する必要があることに留意する必要がありました。





ここに、数か月間荷降ろしして、ほんの一週間以上離れたときの例を示します。 翌日に荷を下すと、何かがおかしくなりました。 問い合わせを行ったすべての月を過負荷にしないために、次の日ごとに個別の一時テーブルで常にアンロードすれば十分です。 したがって、古いデータはそのまま残り、スクリプトを再起動すると（ネットワークスクリプトまたはマシンがクラッシュしたかどうかにかかわらず）、複製は取得されず、ダウンロードされていないテーブルを削除して再ロードします。



データの更新、追加、最初のアップロード、初期化の場合、常に一貫した状態を維持する必要があることを常に念頭に置く必要がありました。 さらに、いくつかのフィールドを変換して生成する必要がありました。 ここで、Logs APIが私たちを欺くわけでも、データを提供しないわけでもありません。 彼は、私たちがすでに知っていることをただ明け渡しません-特に、2つの生成されたフィールド：AppID、現在データを受信して​​いるアプリケーションの識別子、およびデータを受信した時間。





これはすでにわかっている情報です。 Logs APIから取得する必要はありません。データ処理中に完了するのに十分です。





多くのフィールドでは、日付は文字列形式またはUnix時間のいずれかです。 たとえば、異なる形式でアンロードしないように、常にUnix Timeをアンロードして、ClickHouseネイティブ形式のDateとDateTimeで2つの新しいフィールドを生成できます。 そして、そのデータと共に生きます。 原則として、不要なデータをアンロードしてトラフィックを節約する必要はありません。



これをすべて便利に提供するために、Dockerを使用できます。これは、ホストマシンの他のコンテナや他の環境から隔離されたコンテナでアプリケーションを非表示にできるツールです。 同時に、Ubuntu 17.04、およびWindowsまたはmacOSで動作します。 そして、アプリケーションは気にしません、正しく動作します。



Dockerの使用を開始し、アプリケーションをコンテナに入れて出荷するには、Dockerfileを作成するだけです。







Dockerで作業した人は、ほぼ標準のPython Dockerfileを認識します。これは、ONBUILDイメージでも使用されます。 ファイル構造は単純です。 あなたはこれをしたいイメージに基づいて言います。 特に、ここではPython 3.6.2が必要です。 次に、必要な環境、必要なディレクトリを作成し、pip要件を介してすべての依存関係をインポートし、状態を保存するために必要な永続データを保存する場所と、スクリプトの実行方法を示します。 それだけです



さらに、いくつかの操作の後、2つのコマンドですべてを開始できます。 開始するには、ClickHouseを起動します。これは通常、単純なコマンドです。



次に、アップロードスクリプトを実行し、ClickHouseが配置されている場所をスクリプトに伝え、コンテナに対して認証する必要があります。 これは認証トークンであり、ダウンロードするアプリケーション識別子のリストであり、それだけです。 その後、2つのコマンドを実行すると、すべてのデータについて先月のデータのアップロードが開始されます。 これらはすべてカスタマイズできますが、これは実行する必要があるものの最小限のセットです。





また、docker-composeツール用のファイルを追加することにより、これら2つのコマンドを単純化することができます。これにより、複数のコンテナーを一度に持ち上げて、何らかの方法で相互に接続できます。 必要なものを示します：ClickHouseの上昇、アップロードスクリプトの上昇。 私たちは、彼らがお互いについて知っている必要があることを示します。あるいは、ClickHouseアップロードスクリプトを指定します。 どのデータが永続的で、どこに保存されるかを示します。 この例では、トークンとアプリケーションのリストを指定せずに、変数環境を介して渡します。 したがって、必要なデータ、認証トークン、アプリケーションのリスト、およびdocker-compose up –dを環境変数として指定して、1つのコマンドですべてを上げることができます。 スクリプトの使用を開始するのに必要なことはそれだけです。 簡単です。 すでにオープンソースになっています。



すべてはどうでしたか？ これはペットプロジェクトであり、基本的なプロジェクトではありません。 Pythonで練習する機会であり、データをどのように使用できるかを見ることが私のイニシアチブです。 約1か月の作業、64のコミット、1.5行でした。 単純なアップロードスクリプトとしてはそれほど小さくないようです。





すべてのデータはGitHubにあり、製品のドキュメントに表示されます。 突然AppMetricaを使用していて、特定の好みで提供する分析機能を拡張したい場合は、それを手に取り、データを試してください。 おそらく、あなたは自分にとって興味深い何かを発見するでしょう。



まとめます。 Logs APIとは何かを説明し、使用するのがいかに便利か、どのような目的のために使用するかの例を示し、Logs APIをアンロードすることのニュアンスについて話しました。LogsAPIは、一般にネットワークから更新されたデータをアンロードするために外挿できます。 質問があれば書いてください。 よろしくお願いします！