〈開発者ブログ 連載〉Vol.11
~ データの可視化・分析について ~
開発者ブログ 一覧
- Vol.01 データの可視化は○○○○
- Vol.02 その分析に○○は含まれるか - メジャー編 -
- Vol.03 その分析に○○は含まれるか② - ディメンション編 -
- Vol.04 データの品質について考える
- Vol.05 "Analytics"から見たAWS re:Invent
- Vol.06 データ利活用におけるデータガバナンス
- Vol.07 データを分類する
- Vol.08 データレイヤーと内製化
- Vol.09 データプラットフォームとDX推進
- Vol.10 データを取り巻く言葉や概念を理解するために
- Vol.11 データを取り巻く言葉や概念 - Modern Data Stack -
- Vol.12 Single Source of Truth
- Vol.13 わくわくを忘れずに

データを取り巻く言葉や概念 - Modern Data Stack -
データ分析・可視化に関する記事の11回目です。
データを取り巻く言葉や概念について解説する、ほぼ前回の続きのような記事です。
今回と前回に共通したメッセージとしては、概念と実装を分けて考えよう、概念をちゃんと理解しようということです。
データ周辺では先進的で洗練された考えた方が次々と登場していますが、その概念の実装のために専用のツールが必要でしょうか?ということを言いたくて書いています。
ETLやiPaaS
を訴求するにあたっても理解しておくことが重要です。
前回はDataFabricを題材に、セマンティックレイヤーやデータ仮想化について書きました。
今回はModern Data Stackを題材にしようと思います。
Modern Data Stackを網羅的に伝えようと思うと膨大な分量になりますので、本記事を通じてまずは以下の概念を理解してもらえればと思います。
- Reverse ETL Tools
- Change Data Capture
Modern Data Stackとは
Modern Data Stackの説明については、IT Mediaの記事を引用します。
データ統合の根本的な新しいアプローチとして「最新のデータスタックがクラウドでホストされ、ユーザーによる技術的な設定がほとんど必要ないこと」を特徴としており、導入や利用に当たっての技術ハードルが低く、データ接続や処理に工数を割かずに使えることが条件とされています。
via モダンデータスタック(Modern Data Stack)とは? データ統合の新しいトレンド:編集部コラム - ITmedia エンタープライズ
つまり、クラウド上の最新のサービスを使って簡単にデータ分析基盤を作りましょう、という潮流です。
ただのバズワードかなと思って見ていたのですが、後発のサービスプロバイダーがどんどん乗っかていることもあり意外と盛り上がりをみせていたりもします。
具体的に何?という話を調べ始めるとプロバイダーたちによる自社寄りの説明に飲み込まれてしまいますので、まず以下のページを見てもらうとどういうカテゴリのサービスがModern Data Stackを自称しているかがわかります。
参考:Categories - Modern Data Stack | Modern Data Stack
ここには以下のカテゴリがリストされています。
- Data Workspace/ Collaboration
- Data modelling & transformation
- Data Warehouses
- Feature Store
- Event Tracking
- Metrics Store
- Business Intelligence
- No code automation
- Augmented Analytics
- Operational Analytics
- Operational analytics
- Data Cataloging
- Synthetic Data
- Data Privacy & Governance
- Spreadsheet based BI
- Reverse ETL Tools
- Data Lakes
- Workflow Orchestration
- Data Discovery
- Business Reliability/Observability
- Data Quality Monitoring
- Data Streaming
- PLG CRM
- Change Data Capture
- Data Mesh
- Managed Data Stack
- Product Analytics
- Customer Data Platforms(CDP)
- DataOps
- Data Apps
冒頭に宣言した通り、今回はこの中から以下を取り上げて詳述します。
- ※この2つを選定したのは重要度とかではなく、ETL
との関連性からの観点です。
- Reverse ETL Tools
- Change Data Capture
Reverse ETL Tools
■関連記事
2022年度、re:Inventに参加した記事の中で、Scope of Analyticsと題して以下のように書きました。
これはSoIで得られた結果をSoRやSoEにフィードバックするプロセスが自動化されているという意味です。
これをOperational Data Analyticsと呼んでおり、これがすなわちAnalyticsにあたります。
さらに、2023年度は
データ分析基盤にデータを集めて分析するだけではなく、業務システムなどに直接データをフィードバックするところまで含めて分析だよということを言っています。
このフィードバックするためのデータの流れを実現するのがReverse ETL Toolsです。
分析基盤にデータを持ってくるETLに対して、分析基盤から各システムに戻すという意味でのReverseにあたります。
Reverse ETLという表現はアーキテクチャに寄った表現なので、ユースケース軸でData activationと呼ぶこともあります。
Reverse ETLの実現のポイントは、起動制御(トリガーや頻度)と差分更新の考慮だと言われています。
この考慮は従来のETLでは実現できないために、専用のReverse ETLを使いましょうという訴求がされています。
本当にそうでしょうか?
「概念の実装のために専用のツールが必要でしょうか?」という冒頭の文章に戻ります。
Reverse ETL(Data activation)という概念は欠かせないものです。
でも、先ほどの説明をどう聞いてもETLで実装できない内容ではないですよね。
データ分析基盤の中の細かいコンポーネントを個別最適で導入していくと、どうしてもOrchestrationをどうするか、あるいは全体の俯瞰をどのようにするかという問題がつきまといます。
分析基盤に限らず、ITの歴史を見ても分散と集中やBest of BreedとMonolithicなどは行ったり来たりしますよね。
結局OrchestrationとLock-inのバランスをどこに置くかという話になってきます。
特に分析基盤の場合はデータエンジニアとデータサイエンティストという2人格が活動をしていますので、個別最適に寄っていきやすいです。
全体のOrchestration、主体性をどこに持たせていくかという観点で見たときに、ETLやiPaaS
は新しい役割を持てるのではないかと思っています。
Change Data Capture
同じくAWSの記事の中で、「A Zero ETL future…」についての解説を書いています。
AWSがKeynoteでZero ETLと言い出したのはかなりの衝撃でしたよね。
このZero ETLのメインとなるのはAmazon Aurora zero-ETL integration with Amazon Redshiftというサービスで、
このサービスの根幹をなす技術がChange Data Capture(CDC)です。
CDCはソースデータに発生した変更(主にDBへの変更)を追跡し、それをトリガーに何かしらの処理を動かすための仕組みです。
オープンソースのDebeziumがよく使われていますが、これは「ソース システムに発生した変更を追跡し」のところをカバーする仕組みになるので、「何かしらの処理を動かす」部分には多くの場合Kafkaが使われます。
ほかに例をあげると、フルマネージド分析基盤であるDatabricksの主要な機能にDelta Live tablesというものがあります。
これはデータレイヤー(Databricksではメダリオンアーキテクチャ
)の段階的精製を自動化するための機能です。
下流にあたるレイヤーのデータの更新をCDCとDDL(Create Table)によってのみ実現しています。
DatabricksはこれによりETLを無くすことが出来るというように説明をしており、実際にそのために最も洗練されたアプローチかなと思います。(AWSの記事のときにも書きましたが、それはあくまで局所的な話です。)
前回の記事の中で、"世の中には「ETL
なんて要らない!」と声高に叫んでいる人たちが居て" と書きましたが
そのうちのひとりがこのCDCを処理のトリガーとして取り込んだサービスのプロバイダーたちなのです。
ここまで読んでいただいた方はある程度理解しているかなと思うのですが、CDCで重要なのは「ソース システムに発生した変更を追跡し」の部分ですよね。というか本来のCDCのカバーする範囲はそこだけです。
このCDC契機でETLパイプラインを動かすというところを実現できれば、処理はETL
以外でもETL
でも大差はありません。
現にクラウドのETLにはCDCトリガーの機能が順次実装されてきています。
これも工夫次第で既存のETLに対しても同等の機能を持たせることはできます。
ただしイベント/メッセージをSubscribeして起動をトリガーする仕組みは実務上ネイティブで欲しいなと思うことが多いのが実情です。
※余談ですがAmazon Aurora zero-ETL integration with Amazon Redshiftが凄いのはCDCの「ソース システムに発生した変更を追跡」する仕組みと言うよりは、その後の「何かしらの処理を動かす」の部分で、ここがストレージレイヤーで最適化されていることが他の仕組みに対する優位性です。
おわりに
今回はModern Data StackからReverse ETL ToolsとChange Data Captureを取り上げました。
今後ETLやiPaaS
に対して競合とは見えない形で競合してくる可能性があるので、ぜひ知っておいて欲しいと思い記事を書いています。
繰り返しになりますが、今回紹介していないModern Data Stackのカテゴリも含めて、概念は重要なのですが、実装は専用のツールである必要はありません。
Orchestrationの観点も踏まえた上でETLやiPaaS
を訴求すれば十分に優位性があることを覚えておいてください。
ぜひ多くの人に海外イベントに参加してもらい、現地で体感してもらい、それを後に繋げてほしいなと思っています。
この記事が誰かの役に立てば幸いです。
最後まで読んでいただきありがとうございました。
執筆者プロフィール

高坂 亮多
- ・2007年 新卒で当社に入社。
- ・所属:DI本部DP統括部 DP開発1部 副部長 および DP開発1課 課長 兼務
- (所属は掲載時のものです)
- ・好きなこと:登山やキャンプなど アウトドアアクティビティ
- ~ BI基盤(分析基盤)におけるアーキテクトとして日々業務にあたっています ~
開発者ブログ 一覧
- Vol.01 データの可視化は○○○○
- Vol.02 その分析に○○は含まれるか - メジャー編 -
- Vol.03 その分析に○○は含まれるか② - ディメンション編 -
- Vol.04 データの品質について考える
- Vol.05 "Analytics"から見たAWS re:Invent
- Vol.06 データ利活用におけるデータガバナンス
- Vol.07 データを分類する
- Vol.08 データレイヤーと内製化
- Vol.09 データプラットフォームとDX推進
- Vol.10 データを取り巻く言葉や概念を理解するために
- Vol.11 データを取り巻く言葉や概念 - Modern Data Stack -
- Vol.12 Single Source of Truth
- Vol.13 わくわくを忘れずに