こちらはTreasure Data Advent Calendar 4日目の記事です。
データ解析を簡単に
Treasure Dataのサービスを構想した際に、データ解析をとにかく簡単に、かつスムーズに行える世界を実現するというのが根底にありました。個人的にHadoopコミュニティに関わる中で、以下の3つの大きな問題が有りました。
- 大規模な初期投資 / 特殊人材が必須
- クラウドサービスによる提供モデル
- データ収集にプロジェクトの60% 〜 70%の時間が使われる
- 様々なデータコレクタを提供、通常1〜2週間でデータの投入は完了(参考: Treasure Dataのデータインポート方法一覧)
- スキーマ管理の権限移譲問題
- 今回はこちらの話題を取り上げます。
200個の正規表現を管理するデータサイエンティスト
サービスの構想を練っている際、現在は弊社に所属している井上のスライドを片っ端からチェックしました。彼は当時ソーシャルゲームの会社に所属しており、ユーザー行動ログのデータ分析に関する様々な発表を行っていました。
色々と先進的な知見が有ったのですが、１つ根本的に問題だと感じたのは、アプリケーションから来るログのフォーマットがテキスト形式で、さらにその中の構造がマチマチであるため、彼は200個以上の正規表現を日々更新していました。
また、彼の知らない所でログのフォーマットが毎日変わるため、MySQLやPostgreSQL等のスキーマを固く管理するシステムでは毎日のようにDBメンテナンスを行う必要が有ったようです。
Treasure Dataの型システム (Implicit/Explicit Schema)
上記の問題は他の様々な人からも漏れ聞こえてきました。これは恐らくシステムとして解決しなければならないと思い、生まれたのがTDの型システムです。
Treasure Dataでは、全てのデータはJSON形式で保存します。システムは基本的にはフラットなMapを仮定するため、フィールド名ならびにデータの型自体がストレージに保存されます。これをImplicit Schemaと呼んでいます。
その上に、型システムを自分で定義できます。こちらで設定されたスキーマをExplicit Schemaと呼んでいます。
例えば "value": "120" と文字列で保存したデータに対して、 value:int というExplicit Schemaを設定すると、データアクセス時には数値型として解釈されます。
また、列志向形式フォーマットを使用し、各カラムは別々に保存されるため、単純にJSONとして保存するのと比べて劇的にパフォーマンスも良くなる工夫が有ります。
スキーマ管理の権限移譲
このアプローチ、既存のお客様からあまりにも喜ばれる機会が多ったため、その本質は何なんだろうというのは実は最初の数ヶ月は分かりませんでした。今、説明するとすればそれはスキーマ管理の"権限移譲"にあると考えています。
RDBMS(Schema-on-Write)を使用した分析業務フロー
MySQL / PostgreSQL / Netezza / Vertica / RedShift等のスキーマを予め決定するシステム場合、全てのスキーマ変更にアプリケーション開発者と分析担当者の間でのコミュニケーションが発生します。
例えばビジネス側の人間がある指標を欲しがったとします。その指標を出すには、情報が足りないため、特定のログにカラムを1つ追加する必要があります。アプリケーション開発者は分析システム担当者と打ち合わせを行い、スキーマの変更依頼を行い、スケジュールを決定、実際のメンテナンス作業を同時に行います。
頻度がそれほど多くない場合はまわるのですが、例えば25個の別々のアプリケーションの共通データ解析基盤を作る事を考えてみます。各アプリケーションが1週間(5ビジネスDayと仮定)に1回何かしらのスキーマ変更が有る事を仮定すると、分析システム側は平均1週間に5回ものメンテナンスが必要となってしまいます。
またビジネス側の人間からしても、データを貰うまでに時間がかかる、メンテナンスが頻繁に必要になるため頼みづらいという心理的障壁が増える、など多くの問題が発生し、結果的にデータを活用するまでに至らないケースが増えます。
TD(Explict/Implicit Schema)を利用した分析業務フロー
TDを利用した場合、全てのフローがアプリケーション開発者内で自己完結します。
スキーマはアプリケーション開発者側で自由なタイミングで変更が出来るため、スキーマメンテナンス作業は発生しません。また、SQLによるデータアクセスも提供されており特殊なスキルがいらないため、セルフサーブに近い形でデータの活用を行う事ができます。
実際、数十個の異なるアプリケーションからの共通ログ基盤システムとして採用頂く場合には、この点を評価頂く点が多いです。
とはいえ、結局はユースケース
とはいえ、データをカッチリ管理したいケースも少なくありません。例えば既にデータ構造が決まって何年も変わらない場合、TDの型システムによるメリットは少ないです。
また、アプリケーション側にある程度自由度を与えつつ、共通で出すべきカッチリとした指標等がある場合、TDから集計した結果をRDBMSに書き出す事が非常に多いです。そんなユースケースをサポートするため、クエリの結果書き出し機能が有ります。
知っている限り多くの会社、例えば Twitter (Hadoop + Vertica), Pinterest (Hadoop + RedShift), Dropbox (Hadoop + MySQL), Evernote (Hadoop + ParAccel) 等の会社が似通った構成を取っています。現状では組み合わせて使う、というのが最適解になりそうです。
しかし将来的には、1つのシステムで上手く扱えるようにしたいですね、という所で本稿を終わらせて頂きます。