モダンデータスタックは素晴らしいものだが、それほどモダンというわけではない。MDSは基本的に古いDWHの慣習をクラウドやSaaSを用いてリパッケージしたものである。つまり次世代を担う可能性があるリアルタイムのデータアプリケーションと比べると重大な制約がある。
多くの場合ではBIや定型分析は自動化されていくだろう。現在では、多くのダッシュボードやレポートではWhatとWhenにたいして答えを提示している。
いつ何をするのか、そして次のアクションとしてなにをするのか？このアクションが繰り返しならば自動化の候補となる。イベントに対してアクションを自動化できるなら、なぜレポートをみてアクションを意思決定しないといけないのだろうか？
TikTok, Uber, Google, DoorDashのような製品を使うと魔法のように感じるのはなぜか？私たちはボタンを押して動画を見ているだけのように見えるが、システムの裏側では多くの処理が行われている。これらは真のリアルタイムアプリケーションの例である。アクションの裏側では高度なデータ処理と低遅延なML処理を行っている。このようなリアルタイムアプリケーションは民主化されるであろうし、データの世界はすぐにliveになるであろう。
リアルタイムテクノロジーの民主化はMDSへの後継であるlive data stackへと導くだろう
図で示すようなライブデータスタックはアプリケーションからML処理、そしてその逆までもカバーしている。MDSがそうであったように、live data stackはエリート企業で使われているリアルタイム技術を使いやすいクラウド製品として利用可能にすることで、すべての企業が利用可能になる。
MDSは基本的にバッチでデータを扱う。一方リアルタイムデータアプリケーションはデータを連続したストリームとしてあつかう。ストリームのパイプラインとリアルタイム分析データベースはMDSからの移行にあたって2つのコア技術である。技術的には従前から存在していたがクラウドサービスにより広く使われるようになるだろう。
ストリーミング技術はこれまでは高価なおもちゃや、データをAからBへと送るだけの頭のわるいパイプとして使われてきた。(がこれからは変わるはずである)
リアルデータ分析データベースは、高速なデータ取り込みや1秒以内のクエリを可能にする。これらのデータはほかのデータとも連携が可能です。ストリーミングとリアルタイム分析が可能になれば、まったく新しい体験が可能になる。
遅いELTのプロセスや15分おきのデータ更新がボトルネックなることがなくなる。ワークフローの起点となるデータ取り込みの部分においてなぜ、ボトルネックとなるバッチ処理をする必要があるのか？これからはデータは連続的なフローで処理される。これからのデータの処理はstreaming, transform, load(ETLではなく)というかたちになるだろう。もちろんバッチ処理自体はモデルの訓練などで生き残り続けるだろう
DWHやDataLakeは大量のデータを管理することやアドホックなクエリを行うことにたけているが、一方で低遅延のデータ取り込みや高速に変動するデータに対するクエリには最適化されていない。そのため専用のOLAPデータベースが必要になる。
Druid
ClickHouse
Fast Open-Source OLAP DBMS - ClickHouse
Rockset
Rockset: Search and analytics database
Firebolt