Secret Ninja Blog

Customer Experience Senior Directorしてます

ELT時代のワークフローにはData Lineage Trackerが重要になりそう

TreasureWorkflow

ELT(Extract Load Transformation)が一般的になり、データの整形を行ったり、名寄せをしたり、非正規化をしたり、といったことをクラウドのSQLエンジン（BigQuery, Redshift, TreasureData, EMRなど）上で行うことも普通になってきた。 このときにSQLで冪等にワークフローを組むことを考えると、中間テーブルをReplaceしつつ色んな処理をするのが手っ取り早い。そのため、テンポラリの中間テーブルを大量に作られていき、最終的には数十テーブルといった単位でテンポラリテーブルが作られるようになってきた。 また、データ分析も1つのサービスの分析だけでなく、複数のサービスを横断して分析する必要が出ており、またその時のログを集めるにも多種多様なSaaSを用いて収集するのが一般的になってきている。

ETL vs ELTのイメージ図（SAP Hanaの資料だけれども。） f:id:toru-takahashi:20171123125128p:plain

Ref. https://blogs.sap.com/wp-content/uploads/2013/06/elt_229764.png

こうして、複数サービスのデータベースを横断した中間テーブルが増えてきて、SQLの複雑さというのが増してきているように思う。 上図では、HANAという分析エンジンの上で、JOIN/Filter/Transformといった処理を多段で行なっているが、最近はこれが全てSQLで実現されているわけで、しかもこんなシンプルではなく、複数のデータベースの数十のテーブルからなる数百のクエリだったりするわけだ。

このときの課題としては、複雑なSQLがどのテーブルを参照しているのか？という情報を視覚的に見る方法がないことが一つある（トラディショナルなエンプラのツールにはあるかもしれないが、ここ最近のOSSではないと思う）。 つまり、基本的には1SQLを逐次的に流したり、並列に流したりといったことをワークフロー全体としては整理させることができるが、そのタスク一つ一つのSQLがデータベース上のどのテーブルを参照し、どこに書き出すのか。といったSQL自体の処理の流れを把握することまでは考慮されていないようにおもう。

もちろんワークフローを記述する際に、ワークフローの依存関係とSQLの依存関係が完璧にマッチするように作ればよいのだけれども、SQLによってデータ分析の敷居が下がったことにより、そこまで考慮しないで作られたワークフローも増えているのではないかと予想している。

さて、こうしたときに、ワークフローの依存関係とSQLの依存関係がマッチしていないワークフローを改善する。というのがELTを改善する際の辛みの一つであり、これを解決するためにはData Lineage Trackerが重要になってくる。

このData Lineageという言葉自体は以前からあり、例えば富士通の用語集では下記の様に定義されている。

情報トレーサビリティには、一般的にはデータ系列やデータ来歴がある。データ系列（data lineage）とはデータの経路を追跡することであり、監査評価に必要とされている。データ来歴（data provenance）とは、データの完全性（不正に変更されていないこと）を証明するだけでなく、具体的なデータの来歴（起源、正確に計算されたこと）も証明するものである。 Ref. http://www.fujitsu.com/jp/group/fip/words/traceability.html

つまり、Data Lineage Trackerとはデータの経路を追跡するツールのことであり、ここではSQLの処理の流れを追跡するツールを指す。 このツールで何ができるかというと、基本的にはSQLの構文解析をして、どのテーブルからデータを取得して、どこに書き出しているのかを可視化して閲覧できるようにすることだ。 こうしたツールの中で個人的に良いなと思ったのが、

というサービスだ。

f:id:toru-takahashi:20171123125445p:plain

SQLのファイルをzipに圧縮してアップロードすると、自動でSQLの構文解析をして可視化してくれるのだが、この可視化がなかなかいけている。 （他にも色んな機能があるっぽいが、個人的にはこれだけでいいから欲しい。）

f:id:toru-takahashi:20171123125454p:plain

どこが嬉しいかというと、

  • 処理の流れを上から下に向かって記述してくれている
  • 依存関係のないSQLを並列に記述してくれている。

シンプルにこの２点。 これだけで全体のフローを知ることができるし、どこを並列にすれば良いかが簡単にわかる。

例えば、digdagでTreasureDataにsqlを流すワークフローがあったとき、下の二つのタスクを_parallel: trueで並列に書いていいかどうかを知りたいときに、二つくらいなら簡単だが、これが数十のSQLが直列になってくると心が折れてくる。しかし、SQLdepにsqlファイルをアップロードするだけでこの依存関係をまとめてくれるのだから助かる。

+task01:
  td>: step1.sql

+task02:
  td>: step2.sql

+task...

例えば、SQLdepのデモから作られた処理フローが下図。 水色がテーブル名で灰色がSQLになる。ここでいうと、上から２段目の3つの灰色(Query1, Query17, Query3)は並列に位置しているので、依存関係がなく並列に処理しても問題ない。つまり、_parallelをつければ良い。 こうしたことが簡単にわかる。

f:id:toru-takahashi:20171123125519p:plain

今後こうしたツールが最近のクラウドの分析エンジンに対応してきてくれることで、SQLで作られたワークフローの管理が容易になってくる気がする。