6つのGoogleサービスのリーンビッグデータ

こんにちは、Habr！ 独自のビッグデータをどのように作成したかをお伝えしたいと思います。



すべてのスタートアップは、安価で高品質で柔軟性のあるものを構築したいと考えています。 通常、これは起こりませんが、成功したようです！ 以下は、私たちの決定の説明と、この問題に関する私の純粋に主観的な意見です。



はい、秘密は6つのGoogleサービスが使用され、ネイティブコードがほとんど書かれていないことです。

何が必要でしたか？

私はシンガポールの楽しいスタートアップ、Bubblyで働いています。Bubblyは音声ソーシャルネットワークを作っています。 秘Theは、スマートフォンなしで使用できるということです。古き良きノキアです。 ユーザーは特別な番号を呼び出して、メッセージを聞いたり、メッセージを録音したりできます。 すべての声、あなたも使用するために読むことができる必要はありません。



東南アジアでは、数千万人のユーザーがいます。 しかし、携帯電話会社を通じて機能するため、他の国では誰も私たちについて何も知りません。 これらのユーザーは、あらゆる方法で登録および分析する膨大な量のアクティビティを生成します。

• 重要な指標をオンラインで更新して美しいダッシュボードを作成する
• サービスの操作とエラーを監視する
• A \ Bテストを実行し、ユーザーの行動を分析する
• パートナーに報告する
• ...

一般的に、誰もが必要とし、常に実用的なタスク。

なぜ車輪を再発明するのですか？

すでに既成のソリューションがあるのに、なぜ何かを構築するのでしょうか？ そのような動機は私を導きました：

1. Mixpanelを使いたくない（同性愛者の皆さん！）

• データを完全に制御できない場合、他の誰かの既製のシステムが答えないという質問が常にあります。 はい、MixpanelエクスポートAPIがあり、多くのAPIを使用できることを知っています。 しかし実際には、そのような状況に何度も何度もつまずきました。 完全に制御したい。
• あらゆる種類の「ウィッシュリスト」の束は、他の誰かの所有権のある製品にねじ込まれなければならず、これはあまり便利ではありません。 たとえば、何かが壊れている場合、サポートマネージャーへのSMSアラート。 または、サードパーティパートナーへの特別なレポート。 そして、そのような機能は事前に予測することはできません。
• 本当に高いです！ すべてのデータではなく、多くの人が何らかの方法でコストを削減するために、そこにランダムなサンプルのみをアップロードすることを知っています。 しかし、これはそれ自体が非常に疑わしい幸福です。

2.「独自の」ソリューションが本当に必要な場合は、すべてのスタッフィングでHadoopを攪拌してください。

腸が細いからです。 これは本当に難しいです！

• サーバーを上げて、すべてを構成する必要があります。 もちろん、すべてが既に「構成」されているホストされたHadoopがありますが、これらの設定に対処する必要があります。
• Hadoopは単なるストレージとクエリです。 他のすべての機能は自分で行う必要があります。

MySQLのデータが多すぎるため、MySQLは明らかにタスクに適合しません。

簡単にどのように機能するか

1. Google Big Queryのサーバーのユーザーからのすべての「イベント」を埋めます
2. Big Queryへのクエリとその後のデータ処理にはGoogleスプレッドシートを使用します。 すべてのロジックは、スプレッドシートとそれに接続されたスクリプト内にあります。
3. 次に、Google Chartを使用して受信データを視覚化します。
4. これらのグラフィックをGoogleドライブでホストする
5. これらのチャートは、単一の「ダッシュボード」でGoogleサイトに収集されます
6. 最後に、Googleサイトの一番上にあるのはGoogleアナリティクスで、このアナリティクスのすべてのユーザーを管理します。

このアプローチの利点（いいえ、お金のためにGoogleを宣伝しているわけではありません。 残念です ）

ビッグクエリ-長所

• このデータベースには、大量のデータを保存できます。 スケーラビリティの問題は価値がありません。
• 他のソリューションと比較して1ペニーの価値があります。 費用については別途記載します。
• 実際、リクエストは20秒未満で完了します。 これは、スコアがせいぜい数分間であるHadoopとは大きく異なります。 一度定義された標準クエリの場合、違いは小さいようです。 しかし、データを「フリーフライト」（アドホック）で見たり、試行錯誤で何かを修復したりすると、わずかな一時停止でもワークフロー全体が中断され、アナリストの作業の効率が低下することがあります。 しかし、人生では、そのようなタスクを終日行うだけであることがわかります。 Big Queryの非常に重要な利点。
• Webインターフェースのような小さなパンが本当に役立ちます。

改善点：

システムにイベントを追加し、何も考えないために、Big Queryでスキーマレスを実現したかったのです。 そのため、ローダーにコードの一部がねじ込まれ、Big Queryで現在のテーブルレイアウトがチェックされ、ロードするものと比較されます。 新しい列がある場合、Big Query APIを介してテーブルに追加されます。

Googleスプレッドシート-長所

データ分析のためのスプレッドシートに勝るものはありません。 これは私の公理です。 スプレッドシートは、MS Excelよりもこのタスクに適しています（どれだけ気に入っても）。 その理由は次のとおりです。

• すぐに使用可能なBig Queryで動作します（ Goolgeチュートリアル ）
• すべてがクラウドにあり、スクリプトはスケジュールに従ってデータを更新できます
• クロスプラットフォーム！ PCとMacで等しく動作します。
• 既に便利な機能がたくさんあります-メールなど

改善点：

チュートリアルのスクリプトは少し変更されています。 今、彼はスプレッドシートで各シートをチェックします。 「SQL」がセルA1に書き込まれている場合、A2はBig Queryのクエリです。 スクリプトは、クエリ結果を同じシートに配置します。



これは、使用時にコードにまったく触れないようにするためです。 新しいシートを作成し、リクエストを作成し、結果を得ました。

Googleチャート-長所

• 視覚化ライブラリは多数ありますが、Googleの方が信頼性が高く機能的であるという感覚があります（もちろん、ChartsをReaderとして作成している場合を除きます）。
• スプレッドシートをそのまま使用できます（ Googleのチュートリアル ）
• SQLやExcelを使用していないビジネスパーソンでさえ、データを非常に深く操作できるインタラクティブなコントロールに買収されました。

Googleサイト/ Googleドライブ-長所

• Googleが開発したアクセス権のシステムを使用できます。 Dropboxに読み取り専用アクセスを与えることはできませんが、できます。
• Google Sitesにはwysiwygエディターがあり、個人的にはとても気に入っています。
• Googleサービスでシステム全体を構築した後、原則からそれらを最後まで使用することにしました。

Googleアナリティクス

再帰！ ダッシュボードには約30人のユーザーがいます。 リソース使用統計を分析するのに十分です。 驚くことではないが、Google Sitesは数回クリックするだけでGoogle Analyticsと統合されます。 ページトラフィックは、この方向でシステムを改善するために、どのデータが最も興味深いかを客観的に示します。

ソリューションコストについて

どのシステムでも、最も高価なのは開発に必要な時間と、開発とサポートに費やされる工数です。 この意味では、コードはほとんど書かれていないため、このソリューションは理想的です。 プロジェクト全体は、他のタスクと並行して1人で行われ、最初のバージョンは1か月で作成されました。



もちろん、Googleサービス間の統合が壊れる可能性があるという疑念があり（このチュートリアルではこれが既に行われていることを示しています）、サポートの努力が必要になります。 しかし、私は何も悪いことを期待していません。



直接費用については、システム全体でBig Queryのみが費用がかかります。 有料のデータストレージとデータリクエスト。 しかし、それはほんの一銭です！ 1日に6,000万件のイベントを作成し、1か月あたり200 USDを超える支払いを行ったことはありません。

Big Queryの重要なアドオン

デフォルトでは、Big Queryはテーブル全体をスキャンします。 常時イベントが1か所に保存されている場合、リクエストは時間とともに遅くなり、より高価になります。



最新のデータが常に最も興味深いので、これらのテーブルを毎月ローテーションすることになりました。 毎月、eventsテーブルはevents_201401Jan、events_201402Febなどにバックアップされます。



このような構造にクエリを便利にするために、SQL言語を少し拡張しました。 幸いなことに、すべてがスプレッドシートから独自のスクリプトを制御し、必要に応じてリクエストを解析および処理できます。 次のコマンドを追加しました。

• FROMDATASETデータセット-データセット内のすべてのテーブルを順番にクエリします。 これは、全期間にわたってデータを要求する必要がある場合です
• FROMLASTテーブル-現在のテーブルと先月のテーブルを照会します。 これは、たとえば過去7日間のデータを必要とするクエリ用です。 そのため、月の初めに、リクエストは完全な7日間を返し、現在の月のものではありません。

今後の計画：

• SQLを実行するスクリプトを見ました。 私は彼に、PIVOTなどのあらゆる種類の有用な変換を知ってほしい。
• Google Chart用のジグソーJavaScript。 理想的には、コードに触れる必要性をすべて取り除きたいです。 Excelピボットグラフのように、ワンクリックでグラフのタイプを切り替えたり、どの軸のどのシリーズに切り替えるかなど しかし、これらはグローバルな計画です。
• ネストされたデータを試してみたい。 サーバー上の個別のユーザーセッションからのすべてのイベントを1つのレコードにソートできます。 つまり、セッション内のイベント（この場合の呼び出し）は、このセッションの「子供」になります。 理論的には、これによりいくつかの混乱したクエリが簡素化されるはずです。

このすべてがどのように機能するかは、ここの例で見ることができます 。



知識のある人に意見を言ってほしい。 このため、この記事は書かれています。



PSテキストの誤りとPMの私の英語について書いてください、すべてを訂正します。



PPS私はまったくプログラマーではないので、私のコードは怖いかもしれません（しかし、うまくいきます！）。 私は建設的な批判を喜んでいます。