ELTを解体する: サイロではなくグラフが必要な場合

• ELT（Extract, Load, Transform）は、組織内のデータ分析とソフトウェア開発という「サイロ（Silo）」をつなぐために使われるが、こうしたサイロ構造そのものが問題の根源

• ELTはサイロ間のブリッジにすぎない。サイロのない世界は「グラフ（Graph）」である

ELT的な考え方の限界

• 一方のサイロにソフトウェアがあり、もう一方のサイロにデータ分析がある世界では、ELTは非常に意味がある
• ELTはサイロ構造を前提に動作する
  • ソフトウェア開発チームとデータ分析チームが分離された状況で 「抽出（Extract）」 という作業が発生する
  • ソフトウェアチームはデータチームの作業に関心がなく、データチームはデータベース権限を使って無差別にデータを抽出する
  • 抽出した後になって初めて、データ品質やモデリングといったエンジニアリング原則が適用されるが、それではすでに遅い
• Conwayの法則が働く
  • 「組織が設計するシステムは、その組織のコミュニケーション構造を写し取ったものになる」
• サイロ的な発想のために、ETL/ELT/Reverse ETLは現代のデータアーキテクチャの複雑さに対処するには不適切
  • データはもはや運用システムや分析システムにあるだけではなく、SaaSに代表される第三のデータ領域へと拡張している
  • データは地域とクラウド、バックエンドとSaaSの間を流れる
  • 今では以前より100倍も多くのアプリケーションが存在し、組織はソフトウェア化され、ソフトウェアシステム間の関係網はますます複雑になっている

グラフ的な考え方の必要性

• ソフトウェアチームとデータチームが調和して協力できるなら、ELTのようにデータを抽出して保存するモデルではなく、グラフモデル へ移行できる
  • データを 「消費（Consume）」 するノードで構成されたグラフを想像してみる
  • 各ノードはデータを生産または消費し、自然にネットワークまたはグラフを形成する
• グラフ的な考え方の利点:
  • データ抽出が減り、消費が増える
  • 高品質なデータセットを中心としたデータモデリングが増える
  • データクリーニング、ローデータの保存、パイプライン障害の修正が減る
  • バッチ処理を置き換える増分処理やストリーミングソースの活用
  • 分析が戦略的意思決定ツールにとどまらず、運用用途へと広がる
  • チーム間の協力と整合性が高まり、サイロが減る

結論

• ELT的な考え方は、ソフトウェアチームとデータチームの断絶を反映したConwayの法則の結果である
• 既存のETL/ELTツールをすべて廃棄する必要はないが、データ消費と信頼できる派生データセットの構築に焦点を当てるべき
• 現実的には、Shift Leftはまだ理想段階（aspirational）にあり、既存のレガシーインフラや統合の問題は依然として存在する
  • Shift Left : ソフトウェア開発ライフサイクル（SDLC）の初期段階に重要な開発プラクティスを統合する戦略
• グラフ的な考え方を受け入れる組織は、データ活用、AI ROI、ビジネス成果において最大の恩恵を得るだろう

「抽出（Extract）はない。あるのは消費（Consume）だけだ。」– データ・ヨーダ

[udopeanut]

『Data Mesh』という本を読んでみると、理解できる部分が多いですね。

[softer]

グラフベースの意思決定に関して継続的にアイデア出しをしているのですが、同じ考えを持つ人たちが集まれたらいいなと思います

[kimsk]

こういうときに使う用語が「アイデーション」なんですね。ひとつ学びました。個人的にとても関心のあるテーマです。集まれたら本当にいいですね。

[jwseo]

もう少し説明していただける方はいませんか？ 筆者の言うやり方は、グラフから派生するデータセットをすべて個別に保存して管理するということなのでしょうか？ そうでないなら、ETLと何が違うのかがいまひとつ理解できません。

[rlaehdus2003]

既存の運用領域と分析領域が分離されている構造には、サイロ化された構造的な問題があると述べており、データアーキテクチャを作る際にはこの2つを分離して考えるべきではなく、データの生成者と消費者に分けて考えるべきだとしています。

今では運用データと分析データの境界が曖昧になってきているため、グラフ的な思考方式（graph thinking, or the graph mindset）が必要だとしています。

私の感覚では、運用データと分析データを明示的に分離するというより、運用データの延長線上でデータの消費者と生成者を区別し、データアクセスをデータフローの観点から見ているのだと思います（役割は分かれているとしても）。

運用データを使って分析し、再び運用に戻り、それがまた分析に向かう、というようなことをデータアーキテクチャの観点から語っているように思います。