第12回「エンジニアのための「データ可視化」入門」では、データの可視化の理論・実戦まで網羅的な内容が紹介されました。
今回の勉強会では、「ELT・データモデリング」を実践するツールについて学んでいきます。
データモデリングやELTの基本的な概念について触れた後、それを実際に実現するためのツールをご紹介します。ツールとしては「dbt」と「Dataform」をピックアップし、それらを本番環境で運用されている方にご登壇いただきます。
第13回は「ELT・データモデリングツール特集回」と題し、3名の方からデータ利活用にあたってのELTを行なっていく際のメリットと、直面した問題に対しての改善策についてを学んでいきます。
1つ目の講演は株式会社10Xの方をお呼びし、dbtを導入したメリットと直面した課題点を、そして2つ目の講演では株式会社TimeTreeの方をお呼びし、ELTのTransformを行う上での工夫をお話しいただきました。
そして、3つ目の講演では株式会社メルカリの方をお呼びし、Dataformを導入するに至った経緯とDataformとdbtの選び方についてお話しいただきました。
当日の発表内容はこちらになります。
講演「dbtを使ったELTデータパイプライン構築と運用事例」
出典：株式会社10x（10xinc）、「dbtを使ったELTデータパイプライン構築と運用事例」、https://speakerdeck.comより
瀧本 晋也 氏
10X社におけるdbtとELTアプローチを採用し、DWHの構築やサービス開発におけるデータ変換処理の実装事例についてご紹介します。dbt導入に至った背景や運用時における工夫に関してもお話します。
株式会社10X
Twitterアカウントはこちら
瀧本 晋也氏：「dbtを活用した事例を紹介し、dbtは小さいチームでも高度なデータモデリングとチームでの開発体制を整えられる良いツールだという点をお話しします。
dbtは主にDWHやデータマートを経て作るためのデータ変換ツールとして活用されますが、DWHを作るだけじゃない形でも使うことができるという点も触れていきたいと思います。最後に自分がオーガナイザーをやっているコミュニティが盛んなので紹介します。」
株式会社10X とは
瀧本 晋也氏：「株式会社10XはStailerと呼ばれる小売りエンタープライズに特化したECプラットフォームを作成している会社です。
小売事業者さんが実際デジタル化を目指すにあたって、ネットスーパーや商品配達などの顧客に商品を届ける際のネットスーパーのアプリや小売事業者向けのアプリ・管理画面・配送スタッフ向けのアプリ等を作成しています。またパートナー企業やお客様双方のタッチポイントをカバーするシステムを作っていて、開発運営をしております。」
まず、データマネジメントやデータを取り扱う業務をする中で、よく直面する3つの課題についてお話しいただきました。
dbtを取り巻く3つの課題
瀧本 晋也氏：「1つ目は影響範囲がわからない改修が難しいクエリです。例えば、BigQueryのコンソールから作られた秘伝のビューテーブルがあって、その依存関係がよくわからないであったり、クエリの中で見てもドキュメントに残ってなくて、なぜこのロジックになっているかわからない処理や、カラムやドキュメントはあるものの入っているデータが違うといった、カラムが扱う正常系がどういうデータなのかが分からないといったものです。
2つ目がデータ基盤を開発するメンバーの長期的な確保や採用の難しさです。データパイプラインツールを運用すると、OPSまで含めた運用ができるデータエンジニアの採用をしなければなりませんが、市場全体における採用の難易度が上がっています。事業やプロジェクトのフェーズが変わることでデータのユースケースの要求が変化する場面があると思います。しかし、DWHやソースデータに対しての処理の部分を修正をしたいチームがあっても、修正するためには別のチームに依頼しなければならず、社内の調整やリソースの確保が難しいなど組織的な問題もあると思います。
3つ目の課題は、チームで品質を担保しながら開発・デプロイの体制を作っていく難しさです。例えばGithub等のコードを管理するツールを導入しながら、事前に修正差分を確認して動作に問題がないことをチェックして反映するといったCI/CDを導入するためには、ワークフローのツールの知識・実際運用の経験そしてGithubを使った開発の知識・デプロイする為の仕組みまでを理解する必要があります。また、CIの部分でデータをテストする処理を入れようとした時に、統一された仕組みの選択肢は少なく、導入にしても知識やエンジニアリングの部分が必要になります。」
dbt・dbt Cloud IDEを通じた課題解決
瀧本 晋也氏：「データ基盤整備のリソースや採用の難しさといった所は、dbtのselect文で作れるモデル開発で解決できると考えています。
また、影響範囲が分からないパイプラインでの開発の難しさについては、テストやドキュメントを作る機能であったり、Githubの連携やCI/CDの機能、dbtを統合したクラウドの開発環境等を通じて、データを使いたい人が高速に、楽しくデータモデリングできる状態を作っていけないかという話もします。」
そもそもdbtとはどういったものなのかをお話しいただきました。
dbtとは何か
瀧本 晋也氏：「dbtの正式名称は「Data Build Tool」と呼ばれる製品です。どのようなものかというと、拡張されたSQLを使い、ソフトウェアエンジニアリングのベストプラクティスを取り入れて開発を行うツールで、データモデリングを信頼性高く、高速に、楽しくしてくれるものです。また、ELTのT（データ変換）を担当する処理のものになります。」
ELTとdotの関係
瀧本 晋也氏：「ELTとはExtractとLordとTransformの略です。高速でかつ安価で運用ができるデータ基盤が台頭してきて、データ変換をロードしてから行うアプローチです。データエンジニアリングの領域からアナリストが管理しているDWH等の領域にデータの管理や処理が染み出すような流れになっています。」
dbtの導入事例を紹介していただきました。
10Xのdbtの導入事例1
瀧本 晋也氏：「10Xでは2系統でdbtを導入しています。1点目はDWHやデータマートを構築するためのデータパイプラインを作るためで、2点目は前述のStailerのサービスが処理する外部データのデータ変換処理のデータパイプラインで導入しています。
1点目のDWHやデータマートの構築用のデータパイプラインは、外部や自社で管理した注文データや行動データをBigQueryに載せてクレンジングを行い、そこからDWHを作ってマート層のデータでユースケースに落とし込み、それをBIツールで利用する流れになっています。」
10Xのdbtの導入事例2
瀧本 晋也氏：「2点目はStailerが処理する外部データのデータ変換です。流れとしては1点目と似ていて、Stailerはネットスーパーのプラットフォームなので、在庫のデータを作る必要があります。そのデータをパートナーの会社から連携した発注のデータ等をベースにソースデータで格納し、キャストやモデリング処理をして在庫データのモデルが作成されるようになっています。」
10Xでdbtが10Xしてくれた事例1
瀧本 晋也氏：「dbt runをコマンドするだけでデータパイプラインが自動で組み上がる安心感があります 。優れている点の1つ目として、dbt自体はCLIやdbt Cloud IDE上でのデプロイが可能です。dbt run とコマンドを打つことで、定義したモデルやデータが依存関係を考慮してデプロイが可能なので、作っている中でデータがおかしくなったり、作り直したい時にコマンドに任せれば、考慮しながら0の状態から作り直すことができます。
2つ目 は、Jinjaと呼ばれるテンプレートエンジンをSQLと一緒に使用でき、SQLを拡張したような形で処理をすることができます。Jinjaのテンプレート機能を使うことで、 冗長な処理をきれいに書いたり、処理においてマクロを使ってコンポーネント化することも可能です。また、それらの処理をパッケージにして提供しているような方々もいるので、そういうパッケージを使って処理を自社のモデルに組み込むようなことも可能になります。
3つ目として、ドキュメントをデータリネージして確認できる機能があります。ドキュメント自体はYAMLでテーブルやカラムベースで定義することが可能です。それをドキュメント化すると、デプロイされたモデルに紐づいて、ドキュメントをホスティングしてくるようなサービスがあるので、リネージを見ながらこのデータはどういう流れでできたデータなのかや、カラムベースでどういうカラムがあるのかを確認することが可能になります。」
10Xでdbtが10Xしてくれた事例2
瀧本 晋也氏：「クエリをGithubで管理して、レビューを通ったものだけをデプロイできるCI/CD環境を簡単に構築することができます。
dbtはCLIのオープンソースのツールで、クラウドサービスがdbt Cloudと呼ばれるものになります。dbt Cloudでdbtの開発を行うと、統合的なweb環境でのIDE機能とGithub・GitLabのレポジトリにソースコードの管理を委譲できます。
一般的なインターフェースの中で開発をしていると、勝手にGithubフローでコード管理をしている状態になります。その状態でやってると、プルリクエストを作ったり、プルリクエストが作成されたときに、モデルとして正しくコンパイル・ビルドできるとかを合わせてCIとして導入できる機能が備わっています。そういった機能を入れることによって、開発が回しやすくなります。」
10Xでdbtが10Xしてくれた事例3
瀧本 晋也氏：「3点目はモデル処理のSSOT化がしやすいという点です。dbt自体はselect文を書くことで、データモデリングができるという強みがありつつ、データをどういう粒度で管理していくかの設計は必要だと考えています。その上で基本的には、例えばBigQueryのビューのテーブルで、ウェアハウスに保存する形式を指定することができます。
さらに、ビューとテーブルの兄弟に当たる「ephemeral」という一時処理の形式で定義可能です。これによって、ビューやtableはある程度実際のテーブルとして定義されますが、ephemeralのモデルとして定義されたものに関しては組み込んだモデルに対して、定義したSQLをインジェクションして、それをコンパイルされて実行されるような流れになります。」
10Xでdbtが10Xしてくれた事例4
瀧本 晋也氏：「さらに、データの品質を自動チェックしてくれるツールはYAMLで、このカラムはこの値でしか供用しないなどの設定をすることができます。 dbt testというコマンドをすることによって、このカラムのデータが定義に沿っているデータなのかをチェックすることができるようになります。」
10Xでdbtが10Xしてくれた事例5
瀧本 晋也氏：「また10Xとしてデータモデリングの人材の採用がしやすくなったと考えています。SQLがベースのスキルセットなので、その他にGithubの利用経験があれば、ある程度のワークができると考えています。また、昨今ナリストやデータ分析 ・SQLを使う方がデータマネジメントのスキル向上に意欲が高い方が多いので、この領域に対してアプローチしていただける方々が結構多くなっていると考えています。」
dbtを運用して困っている点についてもお話しを伺いました。
dbtを運用して困っていること
瀧本 晋也氏：「dbtを運用して困っている点は、自由度の高さや敷居の低さの一方で、無計画で守られる状態がない中で突き進むと、それ自体が負債になる可能性があると考えています。そういった場合は、コーディングガイドラインやレビュー、そしてlintチェック等の導入を推奨したいと考えています。
また、dbt Cloud IDEに載ってるGithubのフローに関しては、標準的なGithubフローでしかブランチ戦略が取れません。そのため、ブランチを切りながら開発するのが難しい場面があったりするので、ブランチ戦略を取りたい場合はdbt Cloud IDE自体はジョブやデプロイのCI/CDのツールでありながら、Visual Studioといった手元の開発環境でdbtを使ってデプロイすることを検討するのがいいと考えています。」
最後に、盛んなコミュニティである「dbt tokyo」について紹介していただきました。
コミュニティの紹介
瀧本 晋也氏：「日本にもdbtのコミュニティがあり、ローカル東京というチャンネルが日本語で話せるチャンネルとして存在します。また、「dbt Tokyo Meetup」というdbtに関する勉強会も開催しています。さらに、日本語のドキュメントをまとめているのでご覧ください。」
講演「Data Transformation in Digdag – 小さな会社でデータ基盤を運用する」
出典：大政勇作氏（Yusaku Omasa）、「Data Transformation in Digdag – 小さな会社でデータ基盤を運用する」、https://speakerdeck.comより
大政 勇作 氏
ワークフローエンジンのDigdagを使ったELT、特にT(Transform)に関する問題について、Digdagのジョブ定義をうまく活用しながら解決する方法について、TimeTree社の取り組みをご紹介します。
株式会社TimeTree
また、弊社のようにデータ基盤チームがまだないスタートアップでのTransfomの難しさとの向き合い方も、一例としてお話しします。
Twitterのアカウントはこちら
まずは、TimeTreeの紹介をしていただきました。
TimeTreeとは
大政 勇作氏：「TimeTreeは共有とコミュニケーションを前提に作られたカレンダーサービスです。現在、リリースから7年が経ち、3500万ユーザーの皆様にご利用いただいているという状況です。シェアは半数が日本ですが、残りの約半数は日本国外の方々に利用していただいて、アメリカ・韓国・台湾・ドイツといった国々で利用してもらっています。」
TimeTreeのデータ基盤
大政 勇作氏：「TimeTreeはデータ基盤を運用しており、データの基盤そのものはBigQueryで運用していますが、データをロード・加工する際にDigdagを使って運用しています。
Digdagは分散ワークフローエンジンと呼ばれていて、ジョブのスケジュールを実行時間になったら情報をキックしたり、複数のジョブを並列実行したり、ジョブのステータスのモニタリングし、失敗したらリトライできるツールになっています。
特徴としては、YAMLに似たDSLを使ったワークフロー定義ができ、Dagで書かれているので定義した実行順序をうまく並列化してくれて、 高速かつ安全にジョブが実行できます。dbtやDataformと比較すると、ELTの処理全てをDiddagというツールの中で管理できるのが大きな特徴として言えます。」
Transformの利点
大政 勇作氏：「ELTのTransform（データの加工・変形）についてを中心に話していきます。Transformはデータ基盤におけるデータレイク・DWH・データマートの三層構造のうちのDWHとデータマートを作るところにTransformが必要になってきます。
データレイクは直接SQLを書いて分析・活用できますが、そもそも分析を意図していないデータが元になっていいます。そのため非常に使いにくかったり、データが非常に多くてSQLを実行するのに時間がかかり、コンピューティングリソースを使うのでコストがかかる、といった問題が生じます。
そういったものに対処するためにTransformをしてきます。今回はDWHとデータマートを例にあげましたが、それらを作る時に、よく使われるSQLパターンを参考に作成したり、データマートの場合はBIやアプリケーションに合わせたデータ変形を行っていく場合が多いです。」
TimeTreeにおけるTransformの事例を2つ紹介していただきました。
サーバーログからアプリの起動ログだけを抽出するパターン
大政 勇作氏：「1つはサーバーログからアプリの起動ログだけを抽出するパターンです。課題としては、サーバーログは非常にデータ量が多く、DAUのSQLを叩くだけで、サーバーログを毎回全件スキャンし、非常に時間がかかります。そしてサービスにおけるユーザー数が増加していくと、BigQueryのデータの処理量・金額・実行時間がユーザー数の伸びに比例して増えていってしまいます。
そこで、DAUやセッション数でよく使われるSQLパターンを元に、必要なカラムや行だけを取り出してテーブルを作成し、日次で更新するテーブルを作成しています。」
広告レポート用に集計したテーブルを作成するパターン
大政 勇作氏：「2つ目の事例として、データマートの事例を取り上げます。弊社は広告事業をやっており、広告主にTableauを使って広告レポートを提供しており、広告レポートを表示させる際に集計済みのテーブルを生成しています。
この課題としては、TableauはGUIで自由にデータを加工・集計してグラフを作成できますが、GUI上で処理を設定すると、毎回表示するタイミングで集計処理が走ってしまい、レポートの表示までに非常に時間がかかってしまいます。その対処法としてTableau上で行っていた集計処理をSQLであらかじめを行い、新しくレポート用のテーブルを作成してからロードする形をとっています。
さらに利点として、レポート用のテーブルを作っておくと集計処理の仕様が変わったり、何らかのイベントによって途中で変えないといけない際に、変更した後のデータは正しく集計できていても、その前のデータに関しては実績値が意図せず変わってしまうことがあります。それを防ぐためにレポート用テーブルを作っておくと、表示もすぐにでき、意図した通りの数字でレポートが表示できます。」
Transformにおけるよくある課題の傾向と対策をDigdagを用いてお話しいただきました。
データ依存環境の複雑化
大政 勇作氏：「TransformをDigdagでやる際の基本的なアプローチとしては、BQオペレーターを利用してSQLを実行し、結果をテーブルに書き込んでいきます。Transformがもたらすものとして、データの依存環境複雑化していくことが挙げられます。
トランスフォームのデータフローは図のようになっていて、最終的にBIに表示したいテーブルDがあって、それに依存するテーブルAとテーブルCがあって、テーブルCはテーブルBから生成されています。つまりテーブルDを作る時はテーブルABC全て依存関係を持つことになります。そのため、Transformで使うデータはどうしても依存関係が複雑になりやすいです。
もう1つの問題として、ユーザーの属性で購買データといったよく使うデータは、よくジョインされて密結合になっていきます。使いやすいデータを提供しようとすると密結合になってしまい、保守の観点から重要である疎結合の維持が難しくなります。Transformの中心課題として、依存関係の複雑化にどう対処していくかが1つポイントになってきます。」
依存関係が複雑化していく事例についてお話ししていただきました。
ジョブを継ぎ足しによる依存関係の複雑化
大政 勇作氏：「データレイクのテーブルをワークフローで作って、その後DWHのテーブルを作りたいと思った時に別のワークフローを作っていくことがよくあります。後ろのワークフローは前のワークフローの処理時間を考えて、スケジュールを調整して運用していきます。
この状況でよくあるのが、稀に前提となるワークフローが遅延して、後続のDWHやデータマートのテーブルが生成されない問題が発生します。 ここにおけるアンチパターンが、そのデータの依存関係をデータの関連をジョブの表現ではなく、開始のスケジュールを使って暗黙的に表現してしまうことです。これに関しては、データ依存のあるジョブを同一のワークフローで実行させれば解決します。
またジョブの継ぎ足しが増えていくと、ワークフロー定義が肥大化していきます。Digdagの場合だとDigファイルにワークフロー定義を書いていきますが、それが大きくなってメンテナンスが難しくなってくきます。これに関しては、ワークフローの定義ファイルを分割して肥大化をを防ぎつつ、関心の分離を保つことでうまく管理できると考えています。Digdagにおいては、ワークフローから別のワークフロー呼び出す「コールオペレーター」を活用していくことで改善できると思います。」
解決策にも限界がある
大政 勇作氏：「この改善案にも限界があり、これらはあくまでも関心を分離できるだけで、依存関係の複雑化は解消できません。また、Digdagのコールオペレーターでも表現しきれないケースもあり、全ての問題を解決できるわけではありません。」
テーブル設計変更による後続ジョブへの影響
大政 勇作氏：「2つ目のケースはテーブル設計変更が後続ジョブに影響するケースです。データレイクを作るワークフローとそれの後続になるDWHのテーブルを作るワークフローがあったとします。この時に、BigQueryのスキーマ自動判別機能を使って、生成元データであるテーブルビューを作ることがあります。
こういった場合によく発生する問題として、生成元テーブルはBigQueryのスキーマ自動判別機能を使ってテーブルが更新された時も新しいもので作っていけるが、後続データで不具合が出る問題が生じることがあります。これは生成元テーブルのデータにどのようなデータが入るかを想定した上でSQLを組んでジョブを作っていることが多いので、後続ジョブが失敗します。
怖いケースとしては、エラーがないけれど後続ジョブで気づいたらデータが欠損しているケースとかもよくあります。これはBigQueryのスキーマ自動判別機能を使うことで問題が発生している部分があるので、テーブル作成・ロードする際には必ずスキーマを指定して運用していくことが大切だと考えています。」
スキーマを指定することでデータロードの安全性を保つ
大政 勇作氏：「Digdagに関しては、オペレータを使用して上でスキーマを指定してテーブルを作成することで、安全にデータをロードできます。bq_ddlとbq_loadは同じテーブルのスキーマを指定しますが、dq_ddlはDigファイルに記載する都合上、YAMLで書く必要があります。一方でbq_loadはBigQueryのJSONのファイルを用いるので、スキーマの二重管理が発生しがちです。弊社だとjson2yamlコマンドを使って自動生成し、二重管理を防ぐ工夫をしています。」
改善案の限界
大政 勇作氏：「こちらにも改善の限界があります。テーブルの設計変更を行なってエラーになって問題に気付いても、手動オぺレーションが必要になります。また、いらなくなったカラムかどうかはツールがわからないので、その都度手動オペレーションで対応していく必要があります。
別の改善案の限界としては、データの質の変更には対応できないという問題があります。例えば、コンバージョンのタイミングが仕様変更で変わったり列挙データの種類が追加されたときに、Digdag上では対応するのは難しいです。これはDWHやデータマートを作る際に、個別に対処して行く問題になっていきます。
この問題はデータ基盤はそもそもデータを参照する側であるためであり、データを生成するプロダクトや外部APIはデータ基盤に配慮して元データを生み出すわけではないので、泥臭く対応する必要があります。」
最後に、小さな会社でTransformを運用する際に気を付けている点をお話しいただきました。
問題を起こさないような工夫
大政 勇作氏：「Transformの守備は非常に大変であると話しましたが、データ基盤専属チームがないTimeTreeにおいてもデータを運用しています。そういった中で、大切にしていることを4つ共有します。
1つ目は、「問題はできるだけ事前に防ぐ」です。問題が起きてからデータを復旧していくと、オペレーションが非常に煩雑になるので問題発生前の兆候をつかむことが大事です。Digdagだとslaのような想定実行時間を設定するものがあります。それを超えると、ジョブが遅延していたり、そのロードしているデータ量が増えてきているといった、想定時間を超えるような何かが起きていることに気づくことができます。そもそもDigdagが動いていない問題もあると思いますが、そういった時にHealthchecks.ioなど外径監視を行い、正しくデータが入っているかを監視することが大事です。」
DWHデーブルの設計は変更しない
大政 勇作氏：「2つ目はDWHテーブルの変更が非常に難しいため、設計変更は極力しないことです。この要因としては、データを管理する場所と使う場所が異なるためです。
Webアプリケーションの場合、データベースの管理とウェブアプリケーションの開発は同様に行い、テーブルのマイグレーションをしながらアプリケーションの開発・修正していきます。こういったDWH・データマートはデータを使う場所が多岐に渡り、全容の把握が非常に難しく、把握できたとしても修正コストを払うことは現実的ではありません。結果として、公開APIのように後方互換をサポートし続ける問題になりがちです。」
テーブルを作る条件を決めておく
大政 勇作氏：「3つ目は、2つ目に関連してテーブルを作る条件を決めておくことです。DWHの場合だと集計パターンが決めたり、コスト・集計の実行時間でどうしても持っておきたいパターンしか作らないといったような条件を決めます。また、データマートの場合はアプリケーション・BIで使う形式が決まっていて、それに合わせて作っていくといった条件を決めておくと、複雑な管理による問題が防ぐことができます。」
データを遡るのではなく取りに行く
大政 勇作氏：ログデータは過去に遡って取得できないことが多く、データを取りに行く指針にする方がいいと考えています。Transformをするにしてもデータの品質はデータレイクやデータソースの品質が最終的な品質にもつながるので、ログの使用作成から動作チェックまでデータエンジニアが開発を並走して分析しやすいログを作れると、後々Transformがうまくできていきます。」
講演「Dataformとdbtで楽するデータモデリング」
出典：山田直史氏（Nao）、「Dataform とdbtで楽するデータモデリング」、https://speakerdeck.comより
山田 直史 氏
データを使ってもらうためのデータモデリングと、そのうちDataformやdbtに振り分けた領域について紹介します。Dataformが解禁された時に、対等に検討できるようにDataformとdbtをそれぞれ利用した体験をお話しします。
株式会社メルカリ
Twitterのアカウントはこちら
まず初めに、ビジネスシーンにおけるデータの品質に関しお話しいただきました。
ビジネスにおけるデータの品質
山田 直史氏：「様々なビジネスのシーンで使われるデータは幅広い品質のデータが利用されていて、噂レベルの情報を使って意思決定するケースもあれば、速報性・信用性の高い厳格なデータを使って意思決定するケースがあります。高品質なデータを使うことによって、様々なビジネス上の恩恵を受けられます。
例えば、問題を早期に発見したり、様々な属性のデータの収集することでより最もらしい仮説を導き出せたり、高品質なデータを使うことで定量的に評価をすることができます。
このような恩恵を受ける反面、低品質なデータが紛れ込んでくると様々なビジネス上のリスクがあります。低品質なデータによって意思決定を遅れてしまったり、意思決定しないという間違った意思決定を導いてしまったりします。 このような事例は、自動化を通じてデータを利用している機械学習のような場合は顧客体験に直結する恐れがあります。」
低品質なデータの例
山田 直史氏：「低品質なデータの項目には、データによってビジネスに様々なリスクを生じさせるものを並べています。例えば適時性においては、更新頻度が不足しているデータがあった時に、今日出せるはずプレスリリース遅れて、他社の方が先にプレスリリースを出してしまい、そのプレスを出す有効性が弱くなるケースが往々にあるかと思います。
低品質なデータを定めるのはニーズから決まっており、何らかのプレスリリースを送りたいであったり、クーポンを配布したいなどのニーズに対して合わないデータを使っているから起こる問題だと考えています。そのため、ニーズとデータをくっつける作業は重要で、ニーズから高品質なデータを定義することが望ましいです。」
データ活用の1つであるデータモデリングについてお話しいただきました。
データモデリングを行う利点
山田 直史氏：「データを洗練し続けるプロセスのデータモデリングを行うことで、次のニーズを明らかにすることができます。ニーズを満たさないことには次のニーズは明らかにならないので、目先の真に求めているニーズを正しく解消してあげることが重要です。ニーズを満たすところをデータの品質保証という形で継続して、ファーストニーズに応え続けていくことが重要になります。
データの品質保証について2つの観点からお話しします。データの品質保証のスタンダードなやり方として、ルールを用いてデータがそのルールを満たしているかどうか検証するものです。そのデータが値域の中に入っていたり、NULLでないことを確認するプロセスが一般的です。
こういった形でデータが正しいことを確認すると同時にデータが正しくなかった場合、品質の低いデータが最終的に使われないようにする必要があります。後続のデータを汚染しないためにパイプラインを止めることで、データの品質保証をすることができます。
これらの2つをデータの品質保証において意識をし、最終的にはニーズを解消するのを繰り返すことがデータのモデリングになります。」
Dataformやdbt Cloudを導入するメリット
山田 直史氏：「データのモデリングにおいて、データの品質保証に関する関心ごとを可能な限り減らして、ニーズとデータの整合性を担保できるような余裕を作れるのが、ツールの導入による恩恵だと考えています。
エンジニアリングリソースを必要とせずスケジュール・ログ・通知の機能を実現できます。 これらのツールはニーズに合っているかを定期的に検証するスケジュールを内包しているので、事前にルールを定義することとニーズから新しいデータを作ることに注力することができます。」
Dataformについて
山田 直史氏：「Datafromのダッシュボードは、画面中央にSQLの拡張構文として説明をかける欄があります。SQLXというファイルを書くと、ファイル名に従ってデータをテーブルをパブリッシュしたり、ビューの形でパブリッシュすることがGUI 上でできます。
また、Gitと連携しているので、デベロップブランチを切ってデベロップブランチにプッシュしたり、デベロップデータセットに対してデータの配置するなど基本的な機能を備えています。」
Dataform CLIについて
山田 直史氏：「Dataform CLIは登録不要で利用可能で、実行環境を用意すればDatafromに比べて柔軟に実行でき、リポジトリの中でプロジェクトを管理する際は実行環境を用意する必要はありますが、Datafrom CLIは有効な手段になります。
ただ、CLIでは機能が不足しているところがあり、Gitの総合・データリネージのドキュメントの生成あるいは定期実行・スラック通知・ログ機能は落ちているので自前で管理する必要が出てきます。」
実際に導入するにあたっての感じたことを中心にお話しいただきました。
Dataformを導入するに至った動機
山田 直史氏：「Datafromを導入した時のモチベーションとして関心ごとを減らしたいということがありました。DWH上でSQLを使ってデータを綺麗にして提供したいだけなのに、Apache Airflowなどの多機能ツールはSQLを使ってデータを捏ねたいだけのニーズに対して、関心ごとを増やしすぎるツールになってしまうと考えました。
DataformのWebサービスの方だと、定期実行と通知とログが実現できるので非常に有効的です。データの実行関係の順に実行できたり、依存関係を見れる点はメリットですが、データリネージの観点だと、全てのデータリネージ自体が各個別のツールの責任領域じゃないと考えていて、依存関係自体はツールの中とどめる使い方が良いと思っています。」
Dataformを導入して起こったこと
山田 直史氏：「Dataformの導入によってデータのモデリングに専念できたり、データ品質を監視できたり、参画しているメンバーが意識的に改善できる点がメリットとしてありました。Airflowに比べて運用が楽で、データリネージを見て達成感あり、SQLを知っていれば新データの定義ができるといったようにモデリングに非常に専念できました。
またニーズとテストとデータと3つのシートだけ埋めておけば、Dataformを利用するに十分な点や、テストをSQL文と同じ1つのファイルで管理できる点も魅力的です。さらに、テストを満たさないデータが次の依存関係に流れていかないように、止める機能が実装されているのでルールを満たさないものが下流のデータを汚染しないで通知が来て直せる状態を作りやすいのもメリットです。」
導入による更なる利点
山田 直史氏：「またCLIを使うことでプルリクエストレビューを利用者に強制できるので、ニーズとデータの定義の関係を浸透させることができます。
データのニーズに応え続ける意識はすごく重要で、データのに対するニーズを満たしたら次のニーズに応えていく必要があり、それを短い時間で行なえるのがDataformのいいところだと考えています。
データモデリングを行なっていて学びになったことはニーズが異なるなら別のテーブルを用意しなければならないことです。異なるニーズが同じテーブル間にあると、洗練された際に異なるテーブルを用意しないと両方のニーズを満たすことができなくなります。」
Dataform/Dataform CLIにも欠点がある
山田 直史氏：「Datafrom /Datafrom CLIの良し悪しは様々あります。Dataformの方はエンジニアが不在でも使いやすいツールになっています。また初期設定の時間も短く、webサービスが無料なのも非常にポイントが高いです。
dbtに比べるとカスタマイズせずに使うことを前提としているので、アナリストだけのチームでは向いていると考えています。そういった背景もあってAPIがデータホームを持っていますが、モダンなデータ製品との連携が控えめな点が懸念事項となります。」
dbt Cloud/dbtの良し悪し
山田 直史氏：「dbtは初期設定のコストはかかる一方で、非常に良いツールで、エンジニアがいれば自由度の高いカスタマイズが可能です。スクリプトで動作を調整できるのが優秀なところで、連携も充実していて、FivetranやAirbyteといったELTツールから呼び出せるような連携が含まれているのもいい点です。」
どちらを選べばいいのか
山田 直史氏：「どちらを選ぶかはデータのニーズを考える余裕が生まれるかが重要なポイントで、CLIツールよりもGUIツールを前提として選定することが望ましいと考えています。規模が増えてきたらCLIツールを使ってブランチ戦略を練る観点も重要になりますが、最初はどれだけデータニーズを考える余裕を生み出せるかの観点で選定することを推奨します。
データエンジニアリングのリソースがどれだけあるかにもよるので、すぐに余裕を作りたいのであればdbt Cloudがおすすめです。 一方でDataformが利用可能になったら再評価の機会があっても良いと考えています。」
最後に、本日のお話をまとめていただきました。
山田 直史氏：「データモデリングを回すことで、より良い意思決定をサポートでき、ニーズとデータをしっかり組み合わせる活動が重要になってきます。そして、ニーズとデータを組み合わせる活動をDataformやdbt Cloudを使うことで他のことを考えなくて済むので、こういったツールを積極的に採用してニーズやデータと向き合う時間を増やせるといいと思います。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/@dataengineeringstudy6866/featured
