横澤です、平素よりお世話になっております。
昨今は機械学習とか人工知能というワードがバズっている影響もあり、ビッグデータとかDWH(データウェアハウス)というワードも関連して話題に上がりますね。 ビッグデータと一口にいってもその形態やフェーズは様々で、いきなり機械学習アルゴリズムを使って分析出来る綺麗なデータもあれば、フランケンシュタインの如く継ぎ接ぎをして何とか使えるレベルのデータになるかな・・というとっちらかったデータまで様々です。そして大体の場合はビッグデータと言っても後者の場合が多く、本日はそういうお話です。(機械学習とか分析の話は出てきません)
イタンジではtoC向けサービスのノマドやVALUEを始め、toB向けにもぶっかくんやノマドクラウドと様々なサービスを展開しております。そして、開発効率を高めるために基本的にはサービス間を疎結合にするべくデータベースも分断されて設計しております。(物件のデータベースなど、当初から共有を前提としたデータも存在します)
サービスが走り出す前に整合性の取れたデータ設計を出来ていれば「データ溜まってきたね、よーしパパ分析しちゃうぞー」というテンションにもなるのですが、時系列が揃わずに走り出したサービス間で整合性が取れている事は割りと少ないのではないかと思っていたりします。当初からワンプロダクトにフォーカスしているのならば設計しやすいのですが、イタンジの様に小規模ながらも様々なサービスを展開している会社ってどうしているのでしょうね。。。そういう会社のエンジニアさんとデータ周りについてお話してみたいです。
サービスが上手くいってお金もデータも溜まってくると「あれ?このデータってどうやってあのサービスのデータと整合性取るんだっけ?」という課題が浮上してきます。データ量が少なかったり、単純に結合出来るならばどうとでもなるのですが、ログデータのように一杯溜まってるデータとかを別サービスのデータと結合してフンフンとかなるとMySQL単体ではキツイ場面も出てきてしまいます。
という訳でBigQueryです。もはやfluentdやBigQuery自体はありきたりなネタですので、個別サービスの細かい説明についてはこの記事やこの記事なんかを参考にして下さいませ。イタンジでは一手目として、日々増える物件データとぶっかくんというtoBサービスのコールログデータを集約して分析できるようにしました。具体的には下記のような構成で特に難しい事はやっていません。
実際に導入した結果、新たなサービスに繋がるかもしれないデータが取れるようになっています。当初は数千万同士のcross joinの結果を出してみようと考えていたのですが、BigQueryと言えどそれはさすがに無理ゲーだったので、バッチで回したり普通のjoinで上手いことやれる範囲を見つけています。「そもそも何をどうやったらcross joinが必要になるんだ?」という感想を抱かれるかと思いますが、かなり込み入った内部事情なので・・・詳しい事を聞きたい方は個別にご連絡下さいませ。
という訳でカジュアルに大きめのデータをぶち込んでも、分析の為に良い感じで構造化されたデータとして取得できる、という当初の目的はBigQueryである程度果たせました。また都度増えるデータについてもfluentdを使ってストリームインサートして増やし続けています。初期データ投入についてはCSVにdumpしてGoogleCloudStorageにアップしてimportしました。当初はローカルからimportしようとしてハマりました・・・BigQueryに大きめのデータをimportする場合はGCSを経由するとスムーズです。
最後にお金の話です、良いことづく目のBigQueryですが「でも、お高いのでしょう?」という疑問がわきます。ぶっちゃけ恐ろしく安いです。当然AWSのRedshiftも検討したのですが、料金面・速度要件を考えてもBigQueryが適切だったので選択しました。この辺りの技術分野も進歩が早いので、また違う構成が最適になるかもしれないですが取り敢えずはfluentd+BigQuery構成にしています。
イタンジでは「ログデータだけじゃ足りないでしょ、音声データも含めてデータレイクにぶち込みましょう!」というデータ解析基盤を進化させてくれるインフラエンジニアを募集しています!