[日本語訳＆まとめ]How we reduced a 6-hour runtime in Alteryx to 9 minutes with dbt and Snowflake

さがらです。

先日dbt Labs社のDeveloper Blogにおいて、「How we reduced a 6-hour runtime in Alteryx to 9 minutes with dbt and Snowflake」という記事が公開されました。

Alteryxからdbtへの移行というのは非常に珍しい話だなと思い、こちらの記事の内容を日本語訳してまとめてみます。

※日本語訳しての記事投稿についてはdbt Labs社に事前に許可を頂きました。dbt Labs社の皆様、ありがとうございます。

概要

Alteryxは、ユーザーフレンドリーなインターフェイスとドラッグアンドドロップツールを備えたビジュアルデータ変換プラットフォームです。

しかし、Alteryxは組織のデータパイプライン内の複雑性の増加に対処することが困難な場合があり、企業が大規模で複雑なデータ変換を扱うようになると、最適なツールではなくなる可能性があります。

dbtは、複雑なデータ変換パイプラインをスケーラブルかつ効率的に、そしてより明示的に管理できるように設計されているため、このような場合、dbtへの移行は自然な流れであると言えます。 また、今回の移行では、オンプレミスのSQL ServerからSnowflakeへの移行も併せて行いました。

本記事では、まずAlteryxとdbtの違いを説明します。その後、Indicium Tech社のクライアントにおいて、AlteryxとSQL Serverで6時間かかっていた処理を、dbtとSnowflakeで9分まで短縮した方法について紹介します。

Introduction

企業が収集するデータ量が増加しているため、ビジネスルールに従ったデータ変換は複雑な作業となる可能性があります。

このような複雑な作業を軽減するために、ドラッグ＆ドロップツールとして設計されたデータ変換ソリューションは、アナリストがデータ変換にかかるステップを視覚化できるため、直感的な操作でデータ変換処理が開発可能です。

一般的なドラッグ＆ドロップを変換ツールの一例はAlteryxで、ビジネスアナリストはキャンバス内で各ツールをドラッグ＆ドロップすることでデータを変換することができます。

（下図が実際のAlteryxの画面イメージです）

しかし、ワークフローがより複雑になるにつれて、Alteryxはこれらのフローが必要とするモジュール性、ドキュメント化、バージョン管理、といった機能が不足している所があります。

この点について、dbtはデータモデリングに焦点を当てているため、レジリエンスに優れモジュール化されたデータパイプラインを構築するためにより適切なソリューションであるかもしれません。

この記事では、大規模なクライアントのワークフローを3ヶ月かけてAlteryxからdbtに移行した経験を報告しています。リファクタリング後、dbtではモデルの実行時間が6時間から9分に短縮され、各モデルの依存関係もリネージにより明確になり、ドキュメント化やバージョン管理の点でも改善されました。

私達(Indicium Tech社)が行ったことをまとめると、以下4点になります。

• どのデータモデル(Alteryxのワークフロー)を優先的に移行するか、優先順位をクライアントと共に決定
• Alteryxのワークフローをdbtのモデルにリファクタリングするために、どのようなアプローチを使用するかを定義
• リファクタリングしたモデルが元のAlteryxワークフローからの出力と一致していることを確認するために監査
• クライアントが参照するデータソースをdbtでリファクタリングしたデータに置き換え

Alteryxのワークフローからdbtへの移行に際して、ハイレベルなフレームワークを求めているアナリティクスエンジニアの方にとって、今回の私達の経験がモデルリファクタリングにおける一助となれば幸いです。

Who isn't this post for?

ほとんどのユースケースにおいて、dbtはAlteryxよりも優れた変換ツールであると感じていますが、Alteryxからdbtへの移行がすべての人にとって適切ではないことは認識しています。

Alteryxはデータアナリスト向けに設計されていますが、その機能はマーケティング、セールス、会計、人事などのビジネスユーザーにも適しています。Alteryxは、以下のような場合に十分なツールになるかもしれません。

• データ変換処理のボリュームが少ない
• データ変換のプロセスが比較的単純である
• 頻繁にデータ変換処理を実行する必要がない
• 技術者でないユーザーにプロセスを管理させたい

データパイプラインの可視性とよりフレンドリーなユーザーエクスペリエンスに焦点を当て、Alteryxは「より小さく、より理解しやすい」データフローで作業する際に優れており、データがソースから各出力までのすべての下流で変換されている方法を視覚化できます。

一方で、複雑なデータ構造を扱う場合、dbtはAlteryxよりも優れているいくつかの機能を持っています。長くて複雑なデータフローが一般的なデータスタック移行のコンテキストでは、dbtはAlteryxよりも高速であることが多いです。

以下、dbtとAlteryxについて比較表です。

※さがらの所感ですが、この表だけ見るとdbtが良くてAlteryxが悪い製品のように見えてしまいます。しかしAlteryxはデータの前処理と分析に特化した製品なので、そもそも製品のスコープ（下表でいう”ゴール”）がdbtとAlteryxで異なることを理解することが重要だと思います。

観点	dbt	Alteryx
開発方法	CLIとIDE	GUI
ゴール	データ変換とモデリング	データの操作と分析
処理の最適化	クエリの最適化の恩恵を受けれる	既に実行された同じソースを再利用して実行することはない
実行ロジック	全件更新or差分更新(Incremental Model)	実行のたびに都度対象となる全データを処理

A step-by-step guide on how we moved Alteryx workflows into dbt models

Case description

この記事は、Indicium Tech社の主要なクライアントに対するコンサルティング・プロジェクトを報告するもので、クライアント名は匿名とさせていただきます。

このクライアントは、エンタープライズコンテンツ管理および自動化ソリューションの提供を専門とするグローバルテクノロジー企業です。

このクライアントでは、データの保存と分析のために、いくつかのデータ分析ソフトウェアが導入されています。データ変換のステップが1つのソフトウェアに集約されていないため、データの分析と変換は時間の経過とともにますます複雑でハイコストになってきました。

特に、同社は多くのデータ変換ツール（Alteryx、Tableau Prep、Power BI、SQL Server Stored Proceduresなど）を購入し、異なるチーム間で使用したためです。これは、SSOTと一元化されたデータ変換プラットフォームを持つことを妨げていました。

クライアントがIndicium Tech社と契約したとき、彼らはプロジェクトの焦点であるマーケティングチームだけのために数十のAlteryxワークフローを構築し、毎日実行していました。

マーケティングチームにとって、Alteryxワークフローは、あるAlteryxワークフローが前のワークフローの結果を使用するというような相互依存関係にあるため、正しい順序で実行する必要がありました。マーケティングチームが毎日実行する主なAlteryxワークフローは、実行に約6時間かかりました。

考慮すべきもう1つの重要な点は、下流の次のデータモデルが実行を開始したときに、上流に位置するデータモデルの実行が終了していない場合、データが不完全になり、ワークフローを再度実行する必要があることでした。

通常、すべてのワークフローの実行は夜から早朝にかけて行われるため、翌日にはデータが最新の状態になるようスケジュールされていました。しかし、前夜にエラーが発生した場合、データは不正確または古いままとなっていました。（下図はAlteryxでのスケジュール画面サンプル）

またデータリネージの観点でも、Alteryxのワークフローが多く構築されている中で、どのデータモデルが他のデータモデルに依存しているのかを特定することが難しく、余計な労力がかかっていました。

ワークフローの数が増えると、そのワークフローの依存関係を見るためのリネージのビューを別のソフトウェアで作成しているため長い時間が必要でした。そのため、データモデルのソースの変更により、あるデータモデルでカラムの名前が変わった場合、マーケティングアナリストは、その変更によって影響を受ける下流のデータモデルをマッピングして、必要な修正を行わなければなりませんでした。

Alteryxで定義したデータモデルのリネージは手作業でマッピングされていたため、それを常に最新の状態に保つのは大変なことでした。

私たちの主な目的の1つは、マーケティングチームが毎日利用しているAlteryxワークフローをリファクタリングすることでした。すでにお気づきかもしれませんが、このリファクタリングはdbtでモデルを作成することによって行いました。このリファクタリングがどのように行われたのか、次の章で紹介します。

How we refactored (a step-by-step guide based on our experience)

以下では、Alteryxのワークフローをdbtにリファクタリングするために私たちが辿ったステップとハイレベルなフレームワークを提供します。

Step 1: Start by refactoring smaller Alteryx workflows and then move on to more complex ones

リファクタリングプロセスをどこから始めるかを理解することは、私達が提供する価値に対するクライアントの認識に直接影響するため、非常に重要です。

クライアントによっては、モデルのリファクタリングへの最適なアプローチを理解するために、マイナーなモデルから始める方が良い場合があります。より短く、より複雑でないAlteryxワークフローから始めることは、小さな/迅速な勝利を得るための方法となり得ます。またこのアプローチは、懐疑的なクライアントに対して、dbtの優れた実行性能の証拠を提供するために使用することができます。

一方、クライアントによっては、最も重要なデータモデルや最も使用頻度の高いデータモデルから始め、BIツールの主要なレポートが参照するデータモデルをできるだけ早くdbt上で実行させることを希望する場合もあります。このアプローチでは、より大きな価値を提供することができますが、ワークフローに含まれる変換やステップが複雑なため、これらのワークフローをリファクタリングするのに時間がかかると思われます。

私たちは、リファクタリングプロセスの経験と自信を得るために、1つか2つの簡単なワークフローから始め、その後、お客様の最も重要なワークフローのリファクタリングに移行するという、混合アプローチを採用しました。このアプローチにより、時間と価値の提供のバランスをうまくとることができました。

Step 2: Identify the source models and refactor the Alteryx from left to right

最初のステップは、すべてのデータソースを検証し、リファクタリングされる特定のAlteryxワークフローで参照される各ソースに対して1つのcommon table expression (CTE)を作成し、モデル全体でそれらを簡単に再利用できるようにすることです。

各データソース（下図の左端にある緑色の本のアイコン）をクリックし、そのデータソースクエリ内で何らかの変換が行われているかどうかを調べることが不可欠です。ソースアイコンに複数のデータソースやフィルターが含まれていることはよくあることで、このステップが重要なのはそのためです。

次のステップは、ワークフローに従って、Alteryxワークフローと同じデータ変換を再現するために、dbtモデルのSQLクエリに変換を転記することです。

このステップでは、データソースでどの演算子が使用されているかを確認しました（例：データの結合、列の順序、group byなど）。通常、Alteryxの演算子はかなり自明であり、理解に必要なすべての情報がメニューの左側に表示されます。また、各Alteryx演算子が裏でどのように動作しているかを理解するために、Alteryxのドキュメントを確認しました。

私たちはdbt Labsのガイドに従って、dbtでレガシーなSQLクエリをリファクタリングを行いました。

すべてのAlteryxワークフローのリファクタリングを終えた後、Alteryxの出力がdbt上で構築されたリファクタリングされたモデルの出力と一致しているかどうかを確認しました。

Step 3: Use the audit_helper package to audit refactored data models

数十のカラムと数百万の行を持つ大規模なモデルの監査は、手作業で行うには本当に大変な作業となります。カラムを1つずつ検証し、プライマリキーでテーブルを結合し、手作りのSQLで互換性を測定することは、人間には不可能です。幸い、このプロセスを自動化するために作られたdbtパッケージがいくつかあります！

このプロジェクトでは、より堅牢な監査マクロを提供し、私たちのユースケースに対してより多くの自動化の可能性を提供するため、audit_helperパッケージを使用しました。そのため、レガシーなAlteryxワークフロー出力テーブルとリファクタリングされたdbtモデルの両方をデータウェアハウス上でで実体化させる必要がありました。

そして、audit_helperで利用できるマクロを使って、クエリ結果、データ型、列値、行番号、その他パッケージ内で利用できる多くのものを比較しました。audit_helperパッケージの使用方法に関する詳細な説明とチュートリアルについては、このブログ記事をご覧ください。

下図は、audit_helperの背後にある検証ロジックをグラフィカルに示しています。

Step 4: Duplicate reports and connect them to the dbt refactored models

データモデルのリファクタリングと監査が完了したら、いよいよBIツールのレポートと連携します。リファクタリングしたモデルを元のBIレポートに直接差し込む勇気のある人もいるでしょうが、BIレポートを複製して、この複製したBIレポートに新しくリファクタリングしたdbtモデルに接続することをお勧めします。

この方法では、2つのレポートを並べて比較し、作成されたビジュアライゼーションでデータがどのように動作するかを確認することができます。また、リファクタリングしたテーブルとレガシーテーブルで値が一致しているかどうかをダブルチェックするステップとしても機能します。そのため、時には変換ステップに戻り、カラムタイプのキャストやビジネスルールの変更などが必要になる場合があります。

The gains of the refactoring process

Alteryxエンジンからdbtへのデータワークフローのリファクタリングを成功させることは、決して簡単なことではありませんが、チームの試行錯誤の結果、このフレームワークを導入することで、このプロセスを加速させることができ、データ監査のフォーカスにより、品質を保持したデータを提供することができました。

このリファクタリングにより、dbtベースのデータスタックの3つの主要な側面によって、クライアントにとって大きな価値があることが証明されました

• 驚くほど短縮された実行時間最も印象的だったのは、マーケティングチームのデータワークフローの総実行時間が、6時間以上からわずか9分に短縮されたことです。
  • これは、40倍以上の実行時間の短縮になります。これは、SQL Server のオンプレミスコンピューティングから Snowflake のクラウドコンピューティングへの移行、dbt のアジャイルなSQLコンパイルとIncremental ModelなどのMaterializeの提供、などに起因しています。

• ワークフローの可視性の向上：dbt Cloudに関連するドキュメント化とテストのサポートにより、ワークフローの実行プロセスが可視化され、エラーやデータの不整合の特定とトラブルシューティングを加速させることができました。私たちのチームは、Alteryxモデルよりもずっと早く、下流のモデルで1つの列のロジック変更の影響を特定することができたことが何回もありました。

• ワークフローの簡素化：dbtのデータモデリングのモジュール化アプローチは、データワークフローの総実行時間を短縮するだけでなく、既存のモジュールに基づく新しいテーブルの構築を簡素化し、コードの可読性を向上させました。

このように、Alteryxをdbtにリファクタリングすることは、データの可用性を高めるための重要なステップであり、クライアントのデータチームにとってより俊敏なプロセスを実現することができました。何時間もかかるAlteryxのワークフローを手動で実行したり、個々のファイルのエラーを検索したりする時間が減ったことで、アナリストはデータから洞察を得て、そこから価値を生み出すという、最も得意とすることに集中することができました。

References

所感

Alteryxからdbtへの移行ということで、事例としては珍しい記事でした。記事上では実際のリファクタリングのプロセスの概要にとどまらず、具体的に使用した手法（CTEへの分解）やdbt package（autdit_helper）などについても触れられており、他者が参考にする際にも非常に役立つ事例だと感じました。

実際、Alteryxを用いてデータ変換・データモデリングを行っている企業は多くいるのでは、と予想しています。もちろんdbt単体ではローカルのCSVファイルやExcelファイルを処理できないという問題があるため、この記事の事例でも採用されていたSnowflakeのようなDWHと併せてdbtを導入する必要は出てくるのですが、Alteryxのワークフローが複雑になって管理が大変になったり、ワークフロー間の連携に困っていたり、という課題がある方にはぜひdbtを検討して頂きたいですね。