TreasureDataとの関わりと転職
吉田健太郎氏（以下、吉田）：よろしくお願いいたします。
Treasure Dataが持つテクノロジーのエコシステムを組み合わせたビジネスとして、CDP（カスタマーデータプラットフォーム）が登場しました。これらは、TreasureDataによって開発された様々なソフトウェアを組み合わせてTreasureDataのプラットフォームで動く、とても強力なサービスです。私は現在、それと多少似たような形で、TreasureData社内向けのデータ分析基盤を、TreasureDataのプラットフォームの上で作っております。
自社のシステムやオープンソースプロダクトを活用・拡張しながらさらなる別のシステムを作ることは大変面白いです。その中で気づいた点を、本日お話ししたいと思います。
TreasureDataへ転職したばかりなので、まずは私の紹介をさせてください。
@yoshi_kenさんこと、吉田と申します。Treasure Dataとの関わりについてはだいたい2012年ぐらいからです。PFI所属でHadoopユーザ会の太田さんや芳川さん、古橋さんなどの創業メンバーが集まり、ビッグデータビジネス始めるぞというニュースをFluentdの登場とともに耳にしました。Fluentdというログデータコレクターを使うとログが大変簡単に集められるという手軽さにとても興味を持ち、可視化を行う上で欠かせない重要なものになると確信しました。
さらにHadoop基盤をβオープンするというので即座にコンタクトを取り、翌週にはすべての100台程度のサーバにtd-agent、……Fluentdのミドルウェアパッケージ版ですね、そちらをデプロイして全力で使い始めることにしました。
そうこうしているうちにいろいろ足りないことも見つけて、多くのプラグインを世に送り出しました。
もしかしたらこの会場にも、rewrite-tag-filterやgeoip、twitterプラグインを聞いたことがある、もしくは使ったことがある方もいらっしゃるかもしれません。ありがとうございます。
このようにさまざまなプラグインを出しながらログ収集基盤を整備して、事業成長のためのログ活用を模索しておりました。
Fluentdに続いて、EmbulkやDigdag、Hivemallが登場しました。その頃は不動産関連のビッグデータを活用した事業起ち上げを進めており、かゆいところに手が届くデータ処理ツールとSQLで扱える機械学習ライブラリはニーズど真ん中で、大変に嬉しいものでした。そのサービスは、東京近郊の中古マンション価格を査定する機械学習システムです。
Fluentdのプラグインリリースから書籍の出版まで
私の社外的な活動としては、Fluentdのプラグインをリリースしたり、twitterやブログ、勉強会で「こんなふうに活用するとデータ収集基盤がうまく作れるぞ」といったノウハウをいろいろ出していました。しかしやはりノウハウは書籍にまとめて広めた方がよいだろうと考え、技術評論社の方と執筆プロジェクトを始め、2014年8月に1冊目を出しました。
その後にFluentdもだんだん安定運用フェーズになりつつあり、Fluentdが適する使い方、適さない使い方、そこらへんもかなりはっきりしてきました。そのため、最初の1冊目のほうではかなりのやんちゃな使い方も許用するような、いわゆる2006年頃に流行ったPlaggerのようなちょっとしたミニバッチシステム的な使い方もあったんですけれども、それはFluentdの安定性を損なうということで、なるべくFluentdらしい使い方とはなにかということを踏まえたノウハウ本となっています。
そういうこともあって2冊目の『データ分析基盤構築入門』では、ページ数が164ページから400ページという、専門書としてはかなり分厚い部類になってしまい、こちらは一応共著なんですけれども、自身が書いたページが200ページと、けっこう書き過ぎてしまいました。
しかし、かなり人気な書籍となりました。出版してからしばらく新着ランク上位10位ぐらいです。。タイミングによってはこのように新着ランク1位であったり、ほしいものランク1位、売れ筋ランク1位をデータベース処理のジャンルで取らせていただいたりしております。
意外なことに、FluentdやEmbulk、Digdagについて書かれた本はけっこう少ないんですね。もちろんブログやQiita記事はいっぱいあるんですけれども、Fluentdで調べてもわりと数冊くらい。しかし2017年に刊行した本書籍以降に出ている本はまだありません。そしてEmbulkに関しては2冊ですね。Digdagに関してはこの1冊しかありません。これからデータ処理基盤をつくり始めてみようという方にも大変おすすめできる、唯一の本になっております。
Fluentdプラグイン事典の作り方
簡単に目次などを紹介させてください。私が担当したのが第2部と、付録のFluentdプラグイン事典と、Embulk＆Digdag入門の記事、そしてEmbulkのプラグイン事典です。
「事典？ どうやって？」と思われることでしょう。プラグインの一覧をスクレイピングして、手元にgit cloneして、コードを読んで解説を書いています。あと、ダウンロード数、利用者数なども軸に入れた、殿堂入りプラグインの判定ロジックも作りました。2冊目では改訂もしているわけで、このパートだけでも、本当に大変な労力がかかりました。
改訂時にはFluentdプラグインがおよそ680個ほどありましたが、利用者が比較的多い328プラグインを紹介。さらに新登場のEmbulk版プラグイン辞典に関しても300少々くらい確認できた中から202プラグインを紹介しております。
Treasure Dataにジョインした理由
ふと未来を考えたとき、オープンソースを活用したデータプラットフォーム基盤作りの仕事をもっとしていきたいという思いから、この春よりTreasure Dataにジョインしました。
2012年頃からずっと関わりはあり、社内には顔見知りの方々ばかりですが、社員としてはまだ数ヶ月という新米TD社員です。
これは米国本社オフィスをGoogle Earthで見た写真です。
元倉庫だったところで天井高が3、4メートル以上あり、全部丸ごとTreasure Dataのスタッフが使っているという、かなり広いところで、すごく働きやすいです。新人恒例の米国出張では、この写真にあるオフィスで勤務し、タクシーでほど近いコーポレートアパートに滞在し、自炊生活を楽しんでいました。
デスク脇のビリヤード台で、プロジェクトの方向性について雑談しながらナインボールをしたり、キッチンのところでカルフォルニアワインを飲みながらカジュアルにディスカッションもできる環境です。
自律的にそれぞれのプロ意識で作り上げていく風土がとても良く、みんなすごく話しやすく熱量があり、家庭を大事にしながら楽しそうに仕事をする人たちにあふれていました。そんなところで働きたいという方であったり、話を聞いてみたいという方がいらっしゃれば、お声がけいただけると大変嬉しいです。
マイクロバッチ時代に欠かせないワークフロー管理ツール
前置きがいろいろ長くなりましたが、ここから本日の本題の「Treasure Dataのエコシステムで作るロバストなETLデータ処理基盤の作り方」についてお話ししたいと思います。
ETLという言葉はわりとここ数年で広まってきているような言葉な気がします。これの本質というのは、いわゆる多段のバッチ処理ですね。
バッチ処理というともう昔から、それこそ何十年も前からあります。「なにか新しいものがあるか？」と思う方もいらっしゃるかもしれませんが、進化は続いています。
明らかに違うところはリアルタイムなデータ処理。データができあがってから活用できるようになるまでの時間がとても短くなります。一晩明けてからではなく、もう本当に数分から15分程度の短い時間でマイクロバッチを回して整合性を取りながら処理を進めていくような仕組み作りには、1日に1回の実行を想定するスクリプトは異なる、様々なエラー処理周りのテクニックが必要です。
あとは取って来るデータソースですね。APIを叩いたり、単にデータベースから取ってくればいいというわけでもなく、さまざまなところから取り、そして出力先も各種存在するので。
最近はさまざまなSaaSもありますし、昔であればFTPだけやればよかったところが、いろいろな便利なものが増えて、たくさん使いたいところが増えて。それに伴い機能をいちいち1から開発していては開発者のリソースが足りなくなってしまうわけですね。
そういった、効率の悪いと言いますか、同じような車輪の再発明的なことはなるべくしないで、本質的な業務に集中できるようにしようよというところで、Treasure DataのEmbulkであったりDigdag、こういうのがあります。
ETLの基本としては、先ほども話した通り、どこかしらでデータを取ってきて、そのあと中間処理ということでさまざまな編集を行ない、場合によっては表記の名寄せであったり、そういうこともしつつ、最後どこかしらに書き出す。
BI Toolであったり、S3経由からKinesisに流したり、いろいろできます。
データの利活用を支えるデータ基盤
次に、データの活用方法として、どのようなものがあるかいくつか紹介したいと思います。例えばKPIの計測や課金計算などを速やかにダッシュボードに出すことで、「なにかリリースしたことでいきなりなにかの率が下がったぞ」となったときにすぐ気づけるようにするために使われるようなものですね。
あとは、原価率を見るためのダッシュボードであったり。速報値的なKPI、月次的に見るためのKPI。これが日々成果としてわかるようにするためのCRMであったり、データウェアハウスであったり、さまざまなグラフ表示をしたりすることで自動化できるような、そういうときに使う構成ですね。
ユーザーの行動ログであったり、課金ログ、お金周りのものであったり、あとユーザー情報であったり。そこらへんは一気に集めてどんどん結合していって、その結果必要なデータをどんどん出していく。そんなイメージです。
ほかにCDPやレコメンドエンジン、価格指数算出など、その場合にはこのようなかたちで1段増えます。
一旦データを集めて来たうえで、データ算出、スコア付与というかたちですね。
例えばレコメンドエンジン、価格指数であれば、ある入力データをもとに機械学習するためのモデルがあるので、そこにデータを食わせるとパラメータがいろいろ出てきます。
それも使ってスコアを出していったりするわけです。その結果をいろんなところへ書き出す。そういうのもTreasure Dataのシステムを使うと簡単にできます。
ここでちょっとしたTipsなんですけども、Treasure DataがJavaScript SDKを出しているんですが、これ単体でそのまま生で使っちゃうともったいないところがあります。
そもそもTreasure DataSDKというのは、Googleアナリティクスみたいなデータ収集をTreasure Dataの中に保存していく。ユーザーがどこのページにアクセスしたかであったり、そのユーザーのIPがなにで、ユーザーエージェントがなにで、といったさまざまな情報を集めています。
Googleタグマネージャ経由で呼ぶと、どこをクリックしたかというところも取れるので、どこの外部サイトのリンクを押して出ていったか、そういうのも取れるんですね。そうするとそのユーザーがどのページを訪れて、そしてどのリンクを押して外に出たか、そういったところまで全部追えるデータは価値があるでしょう。
Digdag Workflowでオートメーション化
ユニークな使い方としては、Webクロール結果の前処理にもかなり便利に使えたケースがあります。
例えばWebクロールするためのエージェントを100個くらい立ち上げて、それぞれのところでWebクロールを行い、その結果をFluentdに投げて、そこからバッファリングした結果をS3に一旦保存する。そこに貯まってきたら、定期的に次の処理を走らせるイメージです。処理の段数がある程度の規模になったときには、Digdag Workflowの出番ですね。
書き足されているクロール対象のURLリストを呼び出して、Embulkのマルチコア性能を活かした効率の良いスクレイピング処理、HTMLからこの中の必要なところを抜き出す的な処理をして、またS3に保管することも容易です。規模が中規模以下ならジョブキューやAWS Kinesisをあえて使わずにシンプルに稼働させることも可能です。
その次にTDに取り込んで、また次に必要なデータを付加したりしながら、最終的なきれいな表のデータに、営業さんとかがエクセルで使いやすいような感じのきれいな表データに変換し、それをどこか、Googleスプレッドシートなんかに出すと。そういったところでも使えます。
もしこれを愚直にRubyのプログラムでやったりPythonでやったり、なんでもいいですがそういうもので書くと相当なコード量を書くことになると思います。
もしこれをDigdag、Embulk、Fluentdで扱うとすれば、パースするところの処理、もちろんこれもテストも書きやすいようにできているんですけども、そこを書くぐらいで。あとは設定ファイルぐらいでできあがってしまいます。
あとテストするうえでも一旦S3にファイルがあるので、開発者とかがそこにアクセスしてどんな挙動になるか単体テストもしやすい。そういった特徴がこの一旦S3をチェックポイントとして使うというおすすめの使い方の1つです。
