見出し画像

データ基盤のアーキテクチャ進化を追っていく。

分析屋の下滝です。

データ基盤(データ分析基盤、データプラットフォーム)、あるいは、データエンジニアリングの技術的な動向に興味が出てきました。

特にデータ基盤のアーキテクチャの構成要素、パターン、それらの進化について興味があります。

進化に興味があるのは、ちょっと前にデータレイクハウスという概念に興味を持ったことに関係があります。社内で少しだけ話題に出しました。

以下の論文だけ少し真面目に読んだ(読んでから結構たつのでもう忘れた)のですが、面白そうだなと思えました。

Lakehouse: A New Generation of Open Platforms that Unify DataWarehousing and Advanced Analytics (PDF)

面白そうだなと思ったのは、データレイクハウスがアーキテクチャパターンとして定義されている点と、これまでのアーキテクチャを含めて3つのアーキテクチャが紹介されている点です(図は論文より)。

左が昔からあるデータウェアハウスのアーキテクチャ、真ん中がデータレイクとデータウェアハウスを連携するようなアーキテクチャで現在の主流のもの、右がレイクハウスアーキテクチャです。

この論文によれば、レイクハウスは次のように特徴づけられるアーキテクチャとされます。
(i) オープンなダイレクトアクセス・データフォーマット(Apache ParquetやORCなど)
(ii) 機械学習やデータサイエンスワークロードのファーストクラスサポート 
(iii) 最新鋭のパフォーマンス

レイクハウス自体にも興味はありますが、アーキテクチャのバリエーションが出てくる可能性があるのかもしれない、という点に興味があります。Data Meshなんかもバリエーションレベルではない気もしますが、アーキテクチャパターンの一種となりそうです(Data Meshは勉強中)。

アーキテクチャの進化を追いかける

本題です。

私は直接関わってないのですが、少し前に、提案が必要な案件として、データ基盤の保守をして欲しいという守りのだけではなく、GCP等のクラウドプラットフォームで新サービスが出るたびに、現状のアーキテクチャを最適化していくような攻めの提案が欲しいというものがありました。

もちろん、どんな状況(コンテキスト)でも最適となるアーキテクチャは存在しないと思います。ただし、新サービスで何が新たに満たせるようになるかという視点で、現時点のアーキテクチャから、その新サービスを組み込めるとして、最適となるようにアーキテクチャを変更していく、というプロセスは考えられます。

このような変更の過程をリファクタリングと呼ぶのが適切かは不明ですが(振る舞いは保たれてそうな気がしますが)、アーキテクチャのリファクタリングといっても良さそうです。

課題となるのは恐らく、通常、アーキテクチャレベルの構造的な変更は、簡単ではないということです。さらには、場合によっては、全く異なるプラットフォームに移行するということも考えられます(BigQueryからSnowflakeへの移行など)。

では、既存のアーキテクチャが最適になるように変更し続けるためには、どのような組織的な活動を行えば良いでしょうか。何となく考えてみました。

・アーキテクチャのアセスメント手法の確立
これは、単純に表せば、現状のアーキテクチャは最適か? という問いに答えるものかもしれません。アセスメントを書いていますが、特にこだわりはなく、評価という意味です。

・アーキテクチャの継続的なリファクタリング
これは、現状のアーキテクチャは最適ではないとするなら、どのような手順で最適なものに向けてアーキテクチャを変更していくのかということです。

・クラウドプラットフォームでの各サービスのアーキテクチャへの適用の体系的な評価
これは、特定のプラットフォームでの知識の収集といえそうです。特に解決策の印象が強いかもしれません。

・データレイクハウスなど、新たなアーキテクチャパターンの適用と発見
これは、知識の収集といえそうです。ただし、一定の抽象化するようなイメージです。

・海外/国内事例のアーキテクチャの調査と評価
これは、実践の知識の収集と言えそうです。

・アーキテクチャと関わる部門・部署からの要件の吸い上げと実現のロードマップの作成
これは、運用の視点です。利用者の視点から、アーキテクチャへの要件が何かを特定するとともに、実現していくプロセスです。

・足りないアーキテクチャ要素の独自開発とオープンソースでの公開
これは、判明した課題に対する既存の解決策が不十分だと判明したときのプロセスです。

少し雑ですが、関係図です。

最近の例

基礎知識不足なので、まずは、具体的な単純な事例をもとに考えていきたいと思います。

AWS re:Invent 2022 で、Amazon Redshift auto-copy from S3 というサービスが発表されました。

これは、オブジェクトストレージのAmazon S3にファイルが保存されると自動的にそのファイル内のデータがAmazon Redshiftへロードされる、という機能です。

これによりETLやデータロードのためのツールなどを用いることなく、Redshiftへデータを流し込めるようになるそうです。

具体的には、COPY JOB コマンドを使うようです。

COPY JOBを使用して、Amazon S3に保存されているファイルからAmazon Redshiftのテーブルにデータをロードすることができます。Amazon Redshiftは、新しいAmazon S3ファイルがCOPYコマンドで指定されたパスに追加されると検出します。そして、外部データ取り込みパイプラインを作成することなく、自動的にCOPYコマンドが実行されます。Amazon Redshiftは、どのファイルがロードされたかを追跡します。Amazon Redshiftは、COPYコマンドごとにバッチ化されたファイルの数を決定します。システムビューで結果のCOPYコマンドを確認することができます。

https://docs.aws.amazon.com/redshift/latest/dg/loading-data-copy-job.html

実際に試された方の記事はこちら。

進化の過程は次のようになります。これまでETLの要素(コンポーネント)が必要だったアーキテクチャ(上)が、そのコンポーネントがないアーキテクチャ(下)となります。

実務的には、この進化を行うことのメリット・デメリットを明確にする必要が出てきます。

まとめ

データ基盤の技術的な動向に興味が出てきたので、どのように考えていくかを書いてみました。

データレイクハウスの論文

ついでに、google scholar で見つけた、データレイクハウスの最新の気になる論文です。ちゃんとは読んでないです。

Shared Foundations: Modernizing Meta's Data Lakehouse [PDF], CIDR 2023

From Data Warehouse to Lakehouse: A Comparative [PDF], Big Data 2022

株式会社分析屋について

ホームページはこちら。

noteでの会社紹介記事はこちら。

【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします!
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。