製品間分析のためのクラウドベースのデータ処理インフラストラクチャの構築方法

Skyengでは、データ分析に多くの注意を払っています。 これにより、作業を適切に計画し、異なるタスク間でリソースを分配できます。 本日、分析開発者のGleb Sologubが、年間予算12,000ドル以内で、サービスおよびアプリケーションの全動物園のデータを収集および分析するためのインフラストラクチャをどのように収集したかを説明します。

Skyengには独自のエコシステムがあり、学校の生徒が教師とインタラクティブなレッスンを受けたり、宿題をしたり、テストを受けたりするためのWebプラットフォーム、およびさまざまな英語スキルのトレーニングに役立つiOSおよびAndroid用のモバイルアプリケーションとブラウザー拡張機能などがあります

「私たちは迅速かつ柔軟です」と、同社の創立者の一人であるハリトン・マトヴェーエフは繰り返すのが好きです。したがって、これらの製品はすべて、お気に入りの技術スタックを使用する独立した開発チームを持っています。 これらの各チームには独自のマネージャーがいます。また、彼は製品分析用の独自のツールを選択する製品でもあります。

このアプローチは非常に効果的ですが、それぞれが独自のKPIのみを測定します。 シリーズの質問が表示された場合：「英語の学習はどれくらい速くて良いですか、教師とのレッスンは別として、アプリケーションで自分で単語を学びますか？」、さまざまなソース。

Skyengは、来年の1万2千ドルの予算内で既製の有料サービスにそのようなインフラストラクチャを迅速に構築し、それを経済的に実行可能になると独自の設計に置き換えるように雇いました。

すべての製品から任意のイベントを収集し、それらを単一のリポジトリ内のさまざまなデータベースの必要なデータと組み合わせ、レポートとダッシュボードの形式でこのデータを分析および視覚化するためのインフラストラクチャを構築する必要がありました。 つまり、上の図の4つの質問を解決します。 このrebusをどのように解決しましたか？

データウェアハウスの選択方法

中心的な問題は、実際にデータを配置する場所です。 Skyeng事件の主な基準は3つでした：

• 分析クエリの実行速度。
• ソリューションコスト;
• 分析システムおよびデータ収集サービスとの統合の複雑さ。

速度の要件により、従来の文字列リレーショナルデータベースの使用が許可されず、あらゆる種類のHadoop as a ServiceおよびClickHouseやAzure SQL Data Warehouseなどのまれなオプションを放棄せざるを得なかった統合の問題が考えられました。

そのようなタスクの大企業は、データエンジニアのチームを募集し、Hadoopクラスターのパックを収集するか、Verticaにデータをアップロードしてそこのデータウェアハウスを収集する予算を割り当てますが、マネーバーはそのようなオプションをすぐに遮断します。

中小企業は 、そのようなタスクにRedshiftまたはBigQueryを使用します。 概して、私はそれらの中から選択しなければなりませんでした。 私の意見では、これらのサービスを速度の観点から比較することは意味がありません。異なる境界線の場合を除き、どちらも非常に高速です。 どちらもエコシステムが発達しており、さまざまなサービスと統合されています。

価格に関しては、一見するとBigQueryの方がずっと安いように思えるかもしれません。 最小構成では、1つのRedshiftクラスターが160GBのスペースを提供し、月額180ドルの費用がかかります。BigQueryには柔軟な価格タグがあり、月額1GBあたりわずか0.02ドルです。 ただし、Redshiftのコストは分析クエリの数と負荷に依存しませんが、BigQueryクエリでは処理されたデータ1 TBあたり5ドルで個別に請求されます-安価に思えます。

しかし、 BigQueryがデータのサイズを計算する方法を見てみましょう。これは列ベースであり、1行から1つのフィールドを取得するには、列全体を取り出す必要があることを思い出してください。 簡単な質問を考えてみましょう。たとえば、Vimboxプラットフォームの特定のページを開いたユーザーの数を日付で計算する必要があります。これはBigQueryに対するこのような典型的なクエリです。

select date(timestamp) as period, count(distinct user_id) as user_count from [vimbox.pages] where path = '/showcase' group by period;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、整数型のuser_idと文字列型のパスの2つの列からデータを取得します。 プレート、たとえば1億行の場合、そのような要求のコストは数セントになります。 たとえば、同様のリクエストを含む100のレポートがあり、それぞれが1日に2回再カウントされる場合、毎月の請求書は数百ドル単位で測定されます。

もちろん、さまざまなトリックを使用して、処理されるデータの数を最小限に抑えることができます。 たとえば、すべてをパーティションテーブルに配置し、すべてのレポートで短期間のデータのみを取得できます。 しかし、BigQueryを使用すると、刺激を受ける代わりに、このビッグデータや非常に大きなデータを使用することができなくなります。 洞察を求めてあらゆる種類のクエリを実行しようとする代わりに、あなたはそれらを制限する方法を考えます-これは悲しい話です。

一般に、BigQueryでさらに最適な構成があれば、それを使用できることを念頭に置いて、Redshiftに決めました。

イベントコレクションサービスの選択方法

製品分析の基本要素はイベントであることを思い出させてください。 サイトのページまたはアプリケーションの画面の表示、ボタンのクリック、認証の成功、システムエラー、製品の購入はすべて異なるイベントです。

従来のWeb分析では、サイトのすべてのページの表示イベントを追跡するようにカウンターを設定するのが一般的です。 MixpanelやHeapなどのサービスも、すべてのクリックを自動的に追跡できます（GAには、このための特別な自動追跡プラグインがあります）。 すべてのイベントは念のため事前に収集され、必要な場合にのみレポートで使用されるため、このアプローチは遡及分析と呼ばれます。 ヒープとセグメントは、モバイルアプリケーションの画面の切り替えを自動的に監視できますが、Webページとは異なり、画面は通常、Table7、SEStart、UIAlertControllerなどのあまり意味のない名前を取得するため、これはほとんど役に立ちません。

当然、これらすべてのサービスには、ランダムに定義されたイベントを送信するためのAPIもあります。 そして、分析への製品アプローチは、列イベントですべてを収集することは意味がないという事実に正確にあり、最初に、例えばオンボーディング、登録、アクティベーション、および基本的なプロセスにおける新人の最初のステップを含む少数の主要なアクションを意識的に追跡することを学ぶ必要があります通常のユーザーのアクション。

Skyengの同僚と私はこのアプローチが気に入っています。10種類の製品がある場合にのみ、各開発チームにイベントを送信するための仕様を作成し、すべてのイベントが正しく送信されることを確認する方法が実際の頭痛の種になります。 したがって、すべてのプラットフォーム（Web、iOS、Android）およびHTTP（ブラウザー拡張機能とサーバー用）からイベントを収集できるサービスを1つ選択し、自動ではない場合は少なくとも何らかの方法でこれを実行することを本当に望んでいました。

さらに、イベントを収集できるだけでなく、データウェアハウスに保存できるサービスも必要でした。 何らかの形でイベントを生でエクスポートする機能は、すべてのサービスにあります。 GAの無料版でも、通常のReporting APIを使用して単一のイベントをアップロードするのは難しい方法のようです。 しかし、定期的に生ログを取得し、それらを処理し、必要なフィールドを取り出して、構造化された形式でストレージに配置することを忘れずに-タスク自体は簡単なタスクではなく、サードパーティの開発者のサーバーと肩にプッシュしたかったです。

私たちの要件に準拠するために、いくつかのクロスプラットフォームサービスを試し、比較しましたが、このタブレットは次のようになりました。

	Web	iOS	Android	HTTP	遡及的なイベント収集	データウェアハウスアップロードサービス	年間費用
ミックスパネル	+	+	+	+	制限付き	-	〜5万ドル
振幅	+	+	+	+	-	+	〜5万ドル
ヒープ	+	+	-	+	+	+	31,000ドル
Localytics	+	+	+	+	-	+	$ 15.5K
Facebook分析	+	+	+	-	-	-	無料で
devtodev	+	+	+	+	-	-	90万ドル
Amazonモバイル分析	+	+	+	+	-	制限付き	〜$ 0.1K
セグメント	+	+	+	+	制限付き	+	$ 3.6K
mParticle	+	+	+	+	-	+	36,000ドル

このプレートの年間のコストは、3万人のアクティブユーザー、60万セッション、1億イベントの月次追跡と、ストレージ内のデータアップロードサービス（存在する場合）を前提として計算されます。 これらの数値は、Skyengの年間成長計画に沿ったものでした。

学校の特色は、アクティブユーザーのコアがまだそれほど大きくないことです（2017年2月に約1万2千人の学生）が、年に3回年に3回成長し、既に学校の各製品で週に数時間を費やしています。現在、毎日何百万ものさまざまなアクションを実行しています。 したがって、ユーザー数がはるかに多く、LTVがはるかに少ない他のサイトやアプリケーションとは異なり、ユーザー数に依存する支払いモデルでサービスを使用する方が収益性が高くなります。

タブレットの最初の7つのサービスは、視覚化、レポート、マーケティングコミュニケーションなどのさまざまなツールを備えた本格的な分析プラットフォームです。最後の2つは、さまざまなソースからイベントを収集し、さまざまなCRMおよびマーケティングサービスからのデータを充実させ、データウェアハウス。

7つのオプションすべてのうち、予算に収まるのは4つだけであり、これらのうち、データウェアハウスにイベントを自動的にアップロードする機能を提供したのは、セグメントとAmazon Mobile Analyticsのみです。 ただし、Amazonのソリューションにはかなりばかげた制限があります。イベントに新しいプロパティを追加するたびに、自動エクスポートスキームを再作成する必要があります。これにより、 すでにRedshiftにエクスポートされたすべてのデータが失われます。 通常、S3でのイベントの自動アンロードのみが機能しますが、Redshiftにイベントを詰め込むには、 データパイプラインを自分でプログラミングする必要があります。これは、給与とは別の作業です。

その結果、セグメントを選択しました。 必要なすべてのプラットフォームのイベントを収集するためのSDKとAPIがあり、BigQueryとRedshiftのすべてのデータを自動的にアップロードできます。 遡及的に、 モバイルアプリケーションでイベントを収集できるのは一部だけですが、リポジトリにイベントを記録するための十分に考え抜かれたシステムと 、 イベントを収集するための十分に 開発されたアプローチがあり 、リアルタイムでイベントを監視するのに便利なデバッガーもあります。

Skyengの場合に特に成功したのは、セグメントが収集されたイベントの数ではなく、1か月あたりのユニークユーザーの数にお金をかけることです。

データベースからデータダウンロードサービスを選択する方法

製品からイベントを直接収集することに加えて、データベースからデータをアンロードする必要があります。Skyengには、動物園全体があります。MySQLとPostgreSQLの異なるバージョンの異なるインスタンス（クラウドと自社サーバーの両方）です。 両方を行うソリューションがあります。たとえば、 Treasure DataとAloomaです。 ただし、そのコストは非常に不透明で、割り当てられた予算に明確に収まりません（アプリケーションからの1億イベントとデータベースからの1億行が毎月送信される場合、Aloomaで年間3万ドル、Treasure Dataで6万ドル）。

ここでも、 LuigiやAirflowなどの既存のフレームワークに基づいてETLソリューションを記述したり、パイプラインをプログラムしたりするためのオプションは、プログラマーから少なくとももう1組の手とそれに対応する給与の増加が必要なため、すぐに破棄されることを明確にします。

自動サービスの中で、私はFlyData 、 Fivetran 、 Xplenty 、およびStitchのみを知っていましたが、最も安いものを選択しました-Stitchは1か月間の無料トライアルを提供します。その間、すべての履歴データをアップロードし、新しいデータの増分レプリケーションを構成できます（最大1億行） 1か月あたり500ドル）。

本質的にさまざまなデータ変換をサポートする本格的なETLサービスであるXplentyとは異なり、Stitchにはかなり原始的なインターフェイスがあり、どのテーブルとそれらのフィールド（またはすべて）をどの周波数で、どの周波数で複製するかを簡単にチェックできます方法。

Stitchは、完全な書き換えと増分キーレプリケーションをサポートしています。これは、ソーステーブルの行が追加されただけで変更されていない場合は主キー、たとえば、このフィールドに行が最後に変更された日付が格納されている場合はupdated_atです。 ストレージに転送する前にデータを変換する必要がある場合、必要なデータを含むビューをソースデータベースに直接作成し、同じ方法でこのビューを複製する必要があります。

ほとんどの場合、このような単純なソリューションで十分であると言わなければなりません。

Stitchはさまざまなリポジトリをサポートし、リポジトリに応じてデータ型変換を実行し（たとえば、jsonとenumはRedshiftの場合はvarcharに変換されます）、ソースデータベースの構造とテーブルの変更も監視します-新しい列が自動的に選択されます。 また、インテリジェントなサポートサービスも提供されており、チャットウィンドウでさまざまな問題を何度も解決できました。

複製されたテーブルの数が増えると、別のETL開発者がいるだけですぐに利益が出るため、選択されたアーキテクチャでの代替の最初の候補はまだお金のためです。

どの分析システムを選択しますか？

すべてのデータが保存された後、それを分析して視覚化する方法の問題が生じます。 マネーバーは再び決定的な役割を果たしました。LookerやChartioのような美しくて非常に高価なビジュアルBI分析ツールと、 Periscope Dataのような非常に高価なSQL専用ソリューションをすぐに廃棄せざるを得ませんでした。

選択肢は、 Mode 、 Redash 、 Plotlyのいずれかでした 。 これらのすべてのサービスを使用すると、さまざまなデータウェアハウスに接続し、SQLクエリを作成してさまざまな方法で視覚化し、レポートとダッシュボードを作成し、他のユーザーにそれらへのアクセスを許可できます。

さらに、Modeを使用すると、Pythonライブラリを使用してデータの後処理を実行したり、さまざまなライブラリを接続してカスタムの視覚化を行ったり、パラメータ付きのレポートを作成したり、リクエストの変更履歴をリポジトリに保存したりできます。 より高いサブスクリプションレベルでは、選択クエリを定義として保存する機能を使用できます。

Redashでは、2種類のパラメーターを使用してレポートを作成できます。既に受信したクエリ結果の表示に影響するフィルターと、リクエスト自体に置き換えられるパラメーターのみです。

Redashでは、すでに記述されたSQLコードを再利用して、スニペットとして保存できます。 他のオプションとは異なり、Redashには、スケジュールに基づいて要求を自動的に再計算する優れた機能と、クエリ結果の設定値を変更するトリガーであるSlackまたはメールによる通知メカニズムがあります。 Redashとモードの両方のサブスクリプションのより高いレベルでは、ユーザーグループのレポートへのアクセスを管理する可能性があります。

PlotlyはもともとオープンソースのJavaScript視覚化ライブラリでしたが、現在では最も洗練されたデータ視覚化ツールと、Python、R、Juliaなどの複数の言語用のAPIを備えています。 ダッシュボードを作成する機能が比較的最近登場しました。 RedashやModeとは異なり、Plotlyにはシンプルなアクセス制御システムがあります。スケジュールまたはダッシュボードは、参照またはパブリックアクセスでのみ共有できます。

お金の場合、状況は次のとおりです。Plotlyのコストはアナリストの数に依存し、1人あたり年間0.4Kドルです。既製のレポートを表示するにはサブスクリプションは不要です。 モードの最も安価なプランには、10個のアカウントと5,000個のSQLクエリが含まれ、年間300万ドルの費用がかかります。 レポートを表示するユーザー数に制限のないRedashの最小コストは年間1.2Kドルであり、レポートレベルでのアクセス権の違いは年間5.4Kドルですが、サーバー上で無料で引き上げることができます。

タスクでは、最も高価なサービスを独自の開発に徐々に置き換えることが想定されていたため、Redashのこの機能が最も魅力的でした。 私はすでに彼と多くの経験をしたことを考慮して、私は彼を選びました。

結果

4か月でこのインフラストラクチャをすべて収集し、すべての製品とそのデータベースからのデータを接続して、さまざまなKPIとメトリックの約90のレポートとダッシュボードを作成し、たった約$ 2Kを費やしました（3か月間の無料のRedshiftトライアル、毎月のプログレッシブ料金ステッチとセグメントの支払い、および現在最も高価ではないRedashプランに登録されているという事実）。

特に、各製品に使用する学校のアクティブな生徒のシェアを計算することができました。

これは単純なタスクのように思えるかもしれませんが、実際にはこれらの製品からデータを収集する必要がありました（たとえば、Wordsアプリケーションからのトレーニングイベント）および学校の​​ベースからクラスのデータ。

構築されたインフラストラクチャは、処理されるデータの量を増やすことで簡単に水平にスケーリングできます。また、使用されるサービススタックは、機械学習サービスとしてのAmazon Machine Learningや個別のデータソースとしてのさまざまなCRMおよびマーケティングプラットフォームなど、他の要素によってさまざまな側面から修正および補完できます

クラウドアナリティクスインフラストラクチャの構築を長年望んでいたが、1ペンスを飛ぶことを恐れているすべての企業にとって、恐れることをやめて、それを始めてください。数年前よりもはるかに簡単で安価になりました。

PSこの出版物の直前に、レポートを作成し、データベースからデータを複製するために使用できる別の安価なホリスティックサービスを見つけましたが、まだテストする時間がありませんでした。

PPS Glebからのジョブをここに追加するのはクールですが、彼はすでに正常に終了していました。 したがって、私たちは単にあなたに思い出させます：私たちは興味深い人々のために多くの興味深い仕事をしています。 今すぐ参加しよう！