データエンジニアとデータの民主化 〜脱・神 Excel 〜

この記事は 一休.com アドベントカレンダー 2017 の 13 日目です。

一休データサイエンス部の id:kitsuyui です。データエンジニア兼データサイエンティストをやっています。 この記事はもともとアドベントカレンダー上では「脱・神 Excel (仮)」という名前で枠で取っていたのですが、 少し主語が大きすぎたかな？と反省しています。 書いているうちに全く主旨が変わってきましたので、副題とさせていただきました。

今回は一休社内でのデータエンジニアリングにまつわる負担、それらを解決する Redash, Embulk, DatabaseMEMO の導入の流れを書こうと思います。

また、その過程で副次的に発生した FLOSS へのコントリビューションなどなどについては、 14 日目のエントリで説明したいと思います。

一休とデータ活用

一休は今日まで上質な宿・レストランの予約サービスを運営してきて、今年の 7 月で創業 20 年目になりました。 Web でのサービスを提供する企業としては比較的に古参プレーヤーの方だと思います。会員数も 500 万会員を突破しています。

蓄積されてきた膨大なユーザの行動・予約データがあり、データの持つ価値が非常に大きい企業です。

• 2012 年ごろから、一休ではデータ分析を重視して施策を決定することが増えてきました。
• 2014 年ごろから、 BigQuery などの巨大データ向けのソリューションを併用することが増えてきました。
• 2015 年ごろから、基幹データベースとは独立したデータ分析のための専用のデータベースとして、データウェアハウスの構築が進んできました。

今では一休社内の様々な施策が、データドリブンまたはデータ分析にもとづいて行われるようになっています。

1. Re:dash 導入によるデータの民主化

Before

社員にデータ分析の習慣が定着していき、こぞってデータを見るようになると、データの抽出業務が大量に発生していました。 エンジニアでなくとも CSV ファイルさえあれば Excel で勝手に分析することができるのですが、その CSV ファイルこそがデータエンジニアなしでは用意できないものだったのです。

データ活用者からすると分析をしたいのにデータが手に入るまで時間がかかり、データエンジニアからすると「自分は右から左にデータを渡すだけで手一杯になってしまう」というところに負担やフラストレーションを感じるという、お互いに嬉しくない状態になっていました。

Do

そこで一休では 2016 年にデータウェアハウスと共に Re:dash を社内に導入しました。

Re:dash はデータベースへの接続機能を持っており、登録した SQL を実行することで、きれいなグラフや表を生成することができます。 また CSV や Excel ファイルを生成することができます。 Re:dash は Web アプリケーションであり URL を持つので、 URL を Slack で共有することができます 。

After

定型的なデータ抽出作業は全て Re:dash のボタンを押すだけで実行できるようになったため、データエンジニアがボトルネックとなることは減っていきました。

また、一休では Re:dash 以外にも Tableau を営業ツールとして導入しており、これもデータエンジニアの負荷を低減しています。

2. データウェアハウスと Embulk

Before

Re:dash によってデータ抽出業務の負荷は大きく下がったのですが、データを観る人が増えたことによって、ますます社内のデータ活用のモチベーションは上がりました。 そのため、基幹データベースからデータウェアハウスにロードしたり、その過程で正規化するタスクしたり、また別のデータベースに移し替えたりという、いわゆる ETL 業務の効率化と安定性が急務になっていました。

しかしながら、個々の ETL のコンフィギュレーションが分散して存在していたため、著しく可搬性・メンテナンス性が損なわれていました。

Do

そこで Embulk の出番です。 embulk では .yml ファイルで ETL (Extract, Transform, Load) の組を記述することができます。

in:
  type: sqlserver
  table: some_table
  ...

out:
  type: sqlserver
  table: some_table
  ...

素晴らしい特徴として、 input と output のインターフェースが完全に独立しているということがあります。 そのため、「データウェアハウスに入れているあのテーブルを BigQuery にもロードしたい」というようなケースでは、単に output だけ変えればそのまま動作します。

After

embulk の導入によって、いろいろなサーバに分散していた ETL 処理とそのコンフィギュレーションを 1 つのシステムとして統合することができました。 また、これらの .yml ファイルは GitHub で管理しているため、 ETL の過程がどのように変化したかを時系列で追うことができます。

3. 肥大化するテーブル定義の山と DatabaseMEMO の導入

社内でデータ分析がいよいよ活性化して、道具が整ってくると、今度はデータの文脈や名称に対しての理解が重要になってきます。

今日まで何度も改良を加えながら受け継いできた基幹のデータベースは 宿泊予約 のサービスで 500 テーブル以上、 レストラン予約のサービス で 200 テーブル以上 、その他全社の基幹システムのテーブルは合計で 1,000 テーブルを超え ます。 また、基幹システム以外にもデータ分析用に使うテーブル (500 テーブル以上) や、社内システム用のテーブル定義なども含めると、 2,000 テーブル以上 にもなります。 カラム数はさらにその 10 倍程度 でしょうか。

Before

これら基幹データベースのテーブル定義は、全て SVN 上の Excel ファイルに記述する運用をしていました。 2016 年に SVN から GitHub への切り替えを行ったのですが、 Excel によるテーブル定義は Git での差分検出・マージがしづらい という問題がありました。 また、 Excel ファイル自体の行数・列数が大きくなりすぎ、検索性が下がり開発速度が非常に低下 していました。 この Excel ファイルが含んでいた職人的なマクロはメンテナンス不可能になっていました。

一方で Redash の導入により 営業やマーケターの中にも SQL を書ける方が増え てきました。 しかし、基幹 DB の定義は GitHub に置かれていたため、正しい定義はエンジニアにしか公開されていません でした。 また、 データウェアハウスのテーブル定義がどうなっているのかは、そのテーブルを作った本人以外には誰にもわかりません でした。

Do

そこで DatabaseMEMO (dmemo) を導入しました。 DatabaseMEMO は Cookpad がつくった データベース・テーブル・カラムを Markdown 書式で記述・検索・閲覧できるデータベース専用の Wiki のようなものです。

サーバを設置し、簡単なスクリプトを書いて旧来の Excel によるテーブルの定義をインポートしました。

また、 一休独自のカスタマイズとして、テーブル説明文から GitHub へリンクも付与し、ログインなしでも閲覧までは可能に しました。

After

旧来のテーブル定義の歴史を維持しながらも、より高速に検索したり、気軽に Tips を追記したり ということができるようになりました。 テーブルが ソースコードのどこで使われているかも、瞬時に検索 することができます。

さきほど挙げた Re:dash のメリットと同じですが、 DatabaseMEMO は URL を持つので Slack 上で定義を簡単に受け渡しすることができるようになりました 。

まとめ

このようにして、データ分析業務に関わる様々なタスクの効率化・高速化・明文化を推し進めています。

世界的にデータ活用が叫ばれている時代の中で、データエンジニアは単にデータ活用の召し使いになるのではなく、だれもがデータ活用できるような風土づくりを率先して行い、社内のデータ活用のハードルを引き下げていく事が重要だと、私は考えています。