【レポート】キーノート：「自動化されたデータ統合の未来」- Modern Data Stack Conference 2020

英語セッション記事を書く時の三種の神器はOtter.ai、Googleドキュメント、各種翻訳サービスだと思います

「カスタマーストーリー」を支えるツール特集

#dbt

#Fivetran

niino

2020.11.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2020年10月21日～22日にかけて、Fivetran社が主催するオンラインカンファレンスイベントであるModern Data Stack Conference 2020が開催されました。

オンラインイベントながら、かっこいいTシャツがイベント当日に間に合うよう、アメリカからはるばる送られてきました。「日本にいながらイベントに参加してるぞ！」なんて一体感を感じられますね。

本エントリでは、キーノート「The Future of Automated Data Integration（自動化されたデータ統合の未来）」についてレポートします。

セッション概要

スピーカー

Fraser Harris, VP of Product @ Fivetran
Tristan Handy, CEO & Founder @ Fishtown Analytics

内容

Fraser氏とTristan氏は、信頼性、ガバナンス、自動化に重点を置いて、最新のデータスタックの製品進化について議論しています。 Tristanはまた、負債に飛び込むことにも時間を費やしています。彼は、dbtがどのようにアナリティクスエンジニアリングのワークフローを可能にしているのか、dbtをこれほど強力なツールにしている理由は何か、そしてdbtがデータチームのコラボレーションや構築の方法をどのように変えているのかについて議論しています。

Fraser & Tristan discuss the product evolution of the modern data stack, emphasizing reliability, governance, and automation. Tristan also spends time diving into debt. He discusses how dbt enables the analytics engineering workflow, what makes it such a powerful tool, and how it's changing the way that data teams collaborate and build.

動画

セッションレポート

まずはFivetran社のFraser Harris氏の発表からセッションがスタートしました。

自動化されたデータ統合の未来についてお話する前に、まずはデータ統合について何が変わったのかお話しするところから始めます。変化をもたらした触媒が2つあります。コンピューティングとストレージの分離とクラウドサービスとアプリケーションです。

コンピューティングとストレージの分離

実際のところ、コンピューティングとストレージの分離は2005年のC-Store（列指向型データベース）から始まりました。2011年にはBigQueryが登場します。もともとはクラウド解析のためのツールとして始まりましたが、今となってはクラウドデータウェアハウスになっています。2014年にはSnowflakeが登場しました。ACIDに完全に準拠し、列指向型データストレージを備えたRDBMSです。2017年にはDatabricksのDelta Lakeがリリースされました。これは、ACIDトランザクションに準拠したスキーマ制約つきの列指向フォーマットを提供します。2019年にはAmazon Redshiftがコンピューティングとストレージを分離したRA3インスタンスを発表しました。

これらのデータウェアハウスについてコンピューティングとストレージの分離についてお話しましたが、なぜこれが重要で、なぜ同時実行性が向上するのでしょうか。同じデータセットに対して多数のクエリを同時に実行するという観点では、強力なのは管理されたメタデータストアを持つ一貫性のある分散データベースであり、ほぼ無限に拡張可能な並列処理が可能なのはBigQueryとSnowflakeだけです。かっこいいですね！したがって、完全に独立したコンピューティングワークロードを並行して実行できます。

Google Trends（※世界中の検索トレンドをチェックできるサービス）を見ると、クラウドデータウェアハウスが台頭してデータウェアハウス界隈を支配していることがわかります。(Snowflakeはデータウェアハウス以外の意味で使われているためにグラフが他の製品と違う形になっていますが、トレンドラインは一致しています。)

クラウドサービスとアプリケーション

もう一つの変化の要因として、データソースが変わったことが挙げられます。

Zendesk、Marketo、SalesforceなどといったSaaSアプリケーションの台頭
クラウドにホストされたファイルストアとデータベースの台頭
JSONなどの半構造化データの台頭

ここで重要なポイントとなるのは、データは組織内で継続的に増加しており、もう後戻りはできないということです。そして、それを処理する唯一の方法は、自動化を行うことです。

Modern Data Stackのアーキテクチャ

ここまででコンピューティングとストレージの分離、クラウドサービスとアプリケーションの台頭についてお話してきました。ここからはデータ分析のアーキテクチャについてお話します。

従来のアーキテクチャでは、運用しているデータベースからステージング環境、メインとなるデータウェアハウス、データマートへのデータ投入で何回もETL処理を通します。エンドユーザーが確認するダッシュボードへ到達するまでにこのようなたくさんのステップがあり、ETL処理も独自のコードで記述されています。

一方、MDS（Modern Data Stack）アーキテクチャは従来のものに比べて大幅に簡素化されています。これはコンピューティングとストレージの分離、およびそれらの標準化されたソースで得られるものです。多くのレイヤーを排除してデータのサイロを排除しました。まずはETLを完全に抽出とロード（図中のEL）に置き換えます。そして、変換（図中のT）はデータウェアハウス内でのSQL実行により処理されます。これにより、すべてのアナリストはデータの変換処理が可能となります。次に、データの物理的な分離をデータの論理的な分離に置き換えました。従来のアーキテクチャと違って、データストアは一つだけです。最後に、データマートはデータモデルに置き換えられます。これは変換処理されたマテリアライズドビューであり、アナリストは継続的に最新のデータにアクセス可能となります。MDSアーキテクチャではデータガバナンスも容易になります。データモデルでの権限設定を変更するだけです。

この新しいアーキテクチャの良いところは大きくわけて2つあります。

稼働時間（変換処理が壊れてしまった場合でも、アナリストがSQLを再実行すれば即座に結果が修正される）
スピード（要件が変更された場合でもデータモデルを即座に変更してSQLを再実行すればすぐに新しい結果が得られる）

この利点により、データを実際に分析するまでの時間を短縮することができます。

抽出・ロードのレイヤーで必要な要素

抽出・ロードのレイヤーに欲しい要素として、簡単・信頼性・安全性・速い・規模の大きさの5つが挙げられるでしょう。これらの要素はFivetranが提供しています。

型検出の自動化
フィールドマッピングの自動化
スキーマ作成の自動化
変更されたデータキャプチャの自動化
エンドツーエンドの冪等性（何度処理を実行しても同じ結果が担保されること）
障害リカバリの自動化
完全なスキーマレプリケーション
キュレートされたスキーマの事前構築

データパイプラインと市民データインテグレータ

組織のデータリーダーたちからよく聞くのは、データの統合に関するリクエストに苦労していることです。データエンジニアリングの40%の時間は既存のデータの保守に費やされています。何よりも悪いことは、影響力の大きなプロジェクトを引き受けることができず、新しい価値を提供するかわりにメンテナンスに時間を費やしてしまうことです。

では、どのように急速に増加するデータ量に対応し、アーキテクチャをスケーリングし、データエンジニアリングチームを拡大していくのでしょうか。10000ものデータパイプラインがある世界を想像してみてください。頭が痛くなったり心が爆発したりして、どうしていいかわからなくなりますね。幸いなことに答えはあります。市民データインテグレータと呼ばれる人々です。

Fivetran社には部署ごとに14人のデータアナリストが在籍していて、全員が彼ら自身のデータパイプラインを管理しています。このデータ戦略は、データアナリスト、またはデータインテグレーターなど、多くのFivetranの顧客に採用されています。アナリストたちは利用したいデータを待つことで業務がブロックされることなく、自分たちでデータパイプラインを実行できます。それ以上にデータアナリストを幸せにするものはありません。

このデータ戦略を実現するアーキテクチャは上記の通り。この例では、データアナリストのチームがそれぞれの部署（セールス、マーケティング、プロダクト）に基づいて編成されており、それぞれに独自のデータベース、つまりデータを取り込むことができるセルフサービスのサンドボックスデータベースがあります。コア分析チームは高度に管理されたデータモデルを備えた独自のデータベースを持っています。アナリストは権限それぞれの権限に応じてこれらのモデルにアクセスできます。これらのほかに、人事部が管理する独自の非常に機密性の高い従業員データを保持するデータベースがあります。これらのデータをサニタイズしたものをコア分析チームは権限に応じてアクセス可能です。

このアーキテクチャの面白い部分についてお話します。データソースからデータ分析に至るまで完全にセルフサービス化されており、非常に高速に実行可能です。みなさんの中には、「データガバナンスが複雑になるんじゃないの？」と考える方もいると思います。しかし実際にはガバナンスを非常にシンプルにするショートカットがあります。例えば、マーケティングアナリストは広告システムとその中にあるデータへアクセス可能で、同様にEメールマーケティングシステムとその中にあるデータにもアクセス可能です。これらのデータをマーケティングアナリスト自身が持つサンドボックスデータベースへ取り込むことができますが、実際には追加での権限設定はされていません。これを推移的アクセス許可（transitive permissions）と呼んでいます。例えば、システムAへのアクセス許可がある場合、データウェアハウス内の同じシステムAのデータへのアクセス許可も必要であるはずです。データガバナンスのための質問は非常にシンプルで、デフォルトでアクセスを許可するか、それともブロックするかのどちらかを選ぶだけです。それ以外のケースはすべて特別なケースとなります。

Fivetranとdbt

では、データアナリストがどのようにしてデータのモデリングや変換を行っているのでしょうか。Fivetranは、dbt（データビルドツール）と連携することを発表します。 これにより、バージョン管理の再利用可能なコード、コードのピアレビュー、テストなど、最新のソフトウェア開発の多くのベストプラクティスがデータアナリストにもたらされてます。

Fivetranではソリューションアナリティクスチームを立ち上げ、Fivetranのスキーマごとにdbtパッケージを構築しています。これらのパッケージはオープンソースです。Fivetranのコネクタとdbtパッケージ、および1行のインストールで、ゼロから洞察の時間を得ることができます。

また、Fivetranはdbtプロジェクトをオーケストレーション（設定や運用を自動で実行）可能です。セットアップも非常に簡単で、Gitのようなバージョン管理リポジトリに接続したFivetranダッシュボードから実行可能です。必要となるのはdbtジョブを実行するためのスケジュール設定やコードを含むdeployment.yamlファイルぐらいです。ここからすべてが自動化され、すべてのアナリストが事前に構築された変換処理とパッケージを利用できるようになります。

そもそもdbtとは？

いろいろdbtの魅力を説明したところで、「そもそもdbtって何？」というテーマが上がってきました。ここでスピーカーはFishtown Analytics社のTristan Handy氏にバトンタッチ。

dbtは左の生テーブルから右の変換済みテーブルの間に位置します。SQLを使い、データウェアハウスの中で派生データセットを生成するのに役立ちます。SQLに加えて、特定のデータパイプライン固有の構文を表現できるため、生のSQLを使用する場合よりも、そのタイプのロジックの記述がはるかに簡潔になります。

これは分析エンジニアリングワークフローと呼んでいるものです。左側から、Fivetranで生データをデータウェアハウスにロードします。dbtは、データが変更されたときにスナップショットを作成し、データを変換し、変換したデータと生データをテストし、そのコードをすべて本番環境に展開し、ドキュメント化します。これにより組織全体でどのようなデータセットが利用可能であるかの共通理解が得られるようにし、共通の基礎となるバージョン管理の上で、最新のアプリケーションに期待されるすべてのプロセスが行われます。

かつての方法とは違い、最初から最後までのワークフローを所有するのはデータアナリストです。データアナリストの数はデータエンジニアの数よりも多いので、これは重要なことです。もしデータエンジニアがこの仕事を迅速かつ機敏に行ってほしいと思っているのであれば、その仕事をデータアナリストの手に委ねたいと思うでしょう。2016年に"Engineers shouldn't write ETL"というブログがありました。そこでは「エンジニアはテクノロジーやプラットフォームの構築が大好きではあるが、年間を通じて利益をどうやって償却していくかを考えていくことを必ずしも望んでいるわけではない」と語られています。どのようにして販売された商品の原価を分割し、販売されている製品に関連しているかどうかを考える…アナリストがすべての時間を費やして行うこうした作業は、データ変換の中核的な作業です。このような作業に関心を持っている人たちが、自分たちで作業を行えるようにしたいのです。SQLを知っている人なら誰でも自分のデータパイプラインを構築できるはずだし、ツールを使えばソフトウェアエンジニアのように仕事ができるはずです。

まとめ

Modern Data Stackの利点や、それを実現するFivetranやdbtの良さを紹介するキーノートでした。データの内容に対して深い知識を持ち、実際に分析を行うアナリスト自身がデータパイプラインを管理できるようになれば、今までデータエンジニアの作業を待っていた時間を短縮でき、いち早く分析に取り掛かれる利点がありますね。dbtやFivetranについてもっと知りたい方は以下のエントリもあわせてご参照ください。