この記事は GiXo アドベントカレンダー の 10 日目の記事です。
昨日は、GiXoの成長を支える制度についてでした。
Design & Science Div. の堀川です。Design & Science Div. では、今年1月から Dataform を分析業務で用いるワークフローエンジンとして採用し、運用を続けてきました。
そこでこの記事では、Dataform を実際に運用して感じたありがたみをお伝えしたいと思います。
同じような問題に悩まれている皆さんが「Dataform やってみるか！」となれば幸いです。
（え、Dataform をご存じない？是非昨年の弊社アドベントカレンダーをご覧ください！）
目次
Design & Science Div. が直面していた課題
皆さんに Datafrom のありがたみを伝える前に、私の所属するDesign & Science Div.（以下、D&S Div.）がどんな課題に直面していたのかについて、お話しさせていただければと思います。以下課題に当てはまる組織の皆さん、Dataform 使ってみませんか？救われますよ。
複雑化した SQL フローのオペレーション
弊社が数多くのクライアントにご支持を頂いている理由の一つが、スピードです。D&S Div. における1案件の期間は平均2~3か月ほどでして、この短期間で分析結果をまとめ上げ、クライアントの利益に貢献する提言を行う必要があります。したがって、分析における試行錯誤の密度は高くなりますし、複数の分析テーマが同時に走ることも日常茶飯事です。
この状況が何を意味するかと言いますと、うまくやらないと以下の流れで地獄が発生します。。。
- 複数の分析テーマが同時並行で進行することで SQL フローが複雑化し、依存関係の把握が困難になる。
- 修正による影響範囲の把握に時間がかかり、試行錯誤のスピードが低下する。
- 遅れを取り戻そうと焦った結果、影響範囲の把握が漏れ、手戻りが発生する。
・・・思い出すと辛くなってきますね。心当たりのある方もおられるのではないでしょうか？胸が痛くなった人は一度別のタブを開いて猫の画像でも検索して心を落ち着けてください。
重い引継ぎコスト
データ分析のスキルを磨くためには、様々なデータに触れ、データの特徴にあった手法を選択できるようになることが重要です。そこでD&S Div. では、メンバーが様々なデータや案件を経験できるようにアサインを調整しています。
つまり、案件の引継ぎが多く発生するわけでして、当然、上で述べたように複雑化した SQL フローも引き継がねばなりません。短期集中で案件を駆け抜けたメンバーに、十分なドキュメントを準備する余裕がなく、 SQL そのものを読み解くしかない場合もありました。・・・また胸が痛くなってきましたね。。。
構築・運用コスト上の制約
ここまで読んでくださった方の中には、「いや、Airflow うまいこと使えばええんちゃうん？」と思われた方もいらっしゃるかもしれません。それには訳が2つほどありましてね。
その一つが、D&S Div. が非エンジニア組織であることです。実は、D&S Div. には生粋のエンジニアは一人もいません。殆どのメンバーは右手に SQL、左手に Tableau を携え、この2本の刀のみで怒涛の如く押し寄せる案件と日々戦っております。もちろん、予測モデルの構築やクラスタリング等、プログラミング技術を要する高度な分析を実施することもありますが、 弊社機械学習基盤である Refeed を利用したり、Technology Div. と協力することで乗り越えています。要するに、D&S Div.にとって、（SQL 以外の）コーディングが発生しないツールはそれだけでありがたいのです。（dbt の採用を見送ったのもこの理由が大きいです。）
2つ目は、上でも述べた通り短期案件が怒涛の如く押し寄せてくるため、1案件に対して構築コストや運用コストをかけづらいという事情があります。案件ごとに Airflow を立てるとなると、構築自体を自動化しないと大変だし、そもそも環境そのものにかかるお金が。。。えらいことに。。。構築コストや運用コストは何も Airflow に限った話ではありません。引継ぎや、複雑化する処理フローをすっきりさせるためのリファクタリングも運用コストに含まれます。特にリファクタリングは、短期案件であるが故に SQL が再利用されることは比較的少ないため、モチベーションを抱きづらいという問題もあります。
非エンジニア組織が使ってみて感じた Dataform のありがたみ
お待たせしました、本題です。Dataform を使うことで何が変わったのか、何がありがたかったのか、皆さんにお伝えできればと思います。
Dataform のありがたい機能はいくつもあるのですが、私が特にありがたみを感じているのは以下の3つです。これらのありがたい機能によって、我々は救われたのです。（以下の文章は Dataform の基本的な機能をご存じであるという前提で書いています。ご存じない方は昨年の弊社アドベントカレンダーや、他の紹介記事がございますので、そちらをご覧になってから以下を読んでいただくことをお勧めします。）
- Dataform が良しなに依存関係を可視化してくれる。（Airflow でいうところの DAG を Datafrom が作ってくれる。）
- ボタン一つで依存関係がある SQL 群を一括で更新してくれる。
- 構築と運用が GUI と SQL のみで完結する。
では、具体的にどのような形で救われたのか、ご紹介します。
SQL フローのオペレーションが、楽
そうなんです。もう、複雑化した SQL フローを読み解くために個々の SQL とにらめっこする時間も、影響範囲の把握漏れに戦々恐々としながら SQL を順番に実行するストレスもない世界があるのです。
見てください、きれいに依存関係が可視化されています。ちょっと特殊な SQL を書くだけで、Dataform が良しなに作ってくれるのです。楽ちんです。
特定の SQL を修正した際の影響範囲を知りたい場合は、修正対象の SQL を選択すると・・・
こんな感じで、影響範囲も一目瞭然です。これで影響範囲の把握も随分と楽になりました。
もちろん、SQL フローの実行制御も随分と楽になりました。修正対象だけでなく、その影響範囲まで含めてボタン一つで同時に更新できちゃいます。影響範囲全体は更新したくない場合でも、実行対象とする SQL を一つ一つ選択したり、予め SQL にタグを打っておくことでタグの範囲内のみを更新することもできます。
さらにさらに、「実行して結果を確かめたいけど、自分だけの検証環境を作るのが面倒」という場合でも、ボタン一つで検証用のデータセットを作成してそこにテーブルを作成したり、テーブル名に prefix や suffix を付与して別テーブルとして作成することも可能です。
もうこれで、多少処理フローが複雑になろうと大丈夫ですね。ほんと、救われますね。（決して、リファクタリングしない言い訳じゃありませんよ、決して。）
引継ぎが、楽
依存関係が可視化されてるので、Dataform がそのまま引継ぎ用のドキュメントとしても機能するのです。SQL のちょっとした説明であれば、依存関係の可視化画面上でも確認できるので、「大まかな流れは依存関係の可視化を、細かい処理の内容は SQL 中のコメントを見てください！」といった感じで、引継ぎ用のドキュメントを必要としない運用が可能になります。もちろん、引継ぎ用のドキュメントが充実してる方が望ましいのですが、専用のドキュメントを作成しなくても最低限のラインを担保できると考えると、気持ちが楽になりますよね。
構築・運用が、楽
Dataform の環境構築は極めて簡単です。予め DB との接続キー（BQ なら、BigQuery 管理者権限を持ったサービスアカウントの Json キー）を準備しておけば、GUI でちょこっとポチポチするだけで環境構築と DB への接続まで完了します。また、最近 Git リポジトリから Import する機能が追加されたため、予め標準的なフォルダ構造や処理をテンプレート化し、使いまわすことも可能になりました。
運用コストもほとんどかかりません。Dataform の諸機能を利用するために必要なのはちょっと特殊な SQL（SQLX 形式）のみなので、これまで SQL 以外の言語を触ったことがない方でも簡単に運用できます。また、依存関係を Dataform 側で良しなに読み取ってくれるので、Airflow で言う DAG を自前で生成する必要もなく、開発作業のみに集中できます。実際、D&S Div. でもすぐに定着し、特段のサポートなく個々人が使いこなしています。
ありがとう、Dataform
Dataform のおかげで、私は胸の痛い思いをすることがぐっと減りました。残念ながらこの場で紹介することはできませんが、ここでご紹介した内容以外にも、Dataform には様々な便利機能があります。同じような課題でお悩みの皆さんにも、是非 Dataform を使いこなしていただき、QOL が向上すれば幸いでございます。
明日は「プログラミング歴40年のおじさんが初めて本格的なPythonプログラムを書いてみた」を公開予定です。
Hiromu Horikawa
Data-Informed 事業本部 / Design & Science Div. 所属
Heavy Metal とロードバイク（乗るのも見るのも）にはまってます。
年末年始の期間を利用したロングライドを画策中
