[2024年1月24日号]個人的に気になったModern Data Stack情報まとめ

さがらです。

Modern Data Stack関連のコンサルタントをしている私ですが、Modern Data Stack界隈は日々多くの情報が発信されております。

そんな多くの情報が発信されている中、この2週間ほどの間で私が気になったModern Data Stack関連の情報を本記事でまとめてみます。

※注意事項：記述している製品のすべての最新情報を網羅しているわけではありません。私の独断と偏見で気になった情報のみ記載しております。

Modern Data Stack全般

Data Mesh Implementation Best Practices

DATAVERSITYにおいて、「Data Mesh Implementation Best Practices」という記事が出ていました。

分散型のデータ管理を行うためのData Meshの考え方について、概要、Data Meshを実装するメリット、Data Mesh実装の際のベストプラクティス、がまとめられています。

個人的には、ベストプラクティスの中の以下の一文が特に気に入りました。「Data as productとは聞くけど、何をしていけばいいのかがピンと来ていない」という私には特に刺さった一文です。

Adopt a product mindset. Treating data as a product allows teams to focus on delivering value to their internal customers rather than just providing raw data. This includes defining clear metrics for success, establishing feedback loops with stakeholders, and continuously iterating on the quality and usability of the data products.

失敗しないData Intelligenceプロジェクト体制の考え方

Quollio Technologies社のCEOである松元氏により、「失敗しないData Intelligenceプロジェクト体制の考え方」というタイトルで、一般的に言うデータカタログの導入プロジェクトを進めるに当たりどのようなプロジェクト体制・運用体制を組めばよいかをまとめた記事が出ていました。

エンプラ企業向けの内容がメインではありますが、どのような役割の方を用意してプロジェクト体制を構築するか、運用体制とフェーズ分け、徐々に分散して管理していくための考え方とフェーズ分け、といったことが具体的に記述されており参考になります。

個人的には、以下の一文が非常に刺さりました。「データ基盤を構築したデータエンジニアが、データのことだからそのままメタデータ管理も担うことになったが上手く回っていない」ということはありがちのため、メタデータ管理とデータガバナンスに特化した役割(データスチュワード)を設けることは本当に重要だと思います。

データインテリジェンスツール（=データカタログ）は、DWHやETLツールと密接な関係にありますが、本質は業務アプリケーションであることを忘れないでください。それも、今まで業務の存在していなかったメタデータ管理・データガバナンスを対象にするものです。だからこそ、会計業務に経理が存在しているように、メタデータ管理・データガバナンスにもデータスチュワードが必要であり、組織体制の影響を真剣に考える必要があります。

PERF IS NOT ENOUGH

MotherDuck社のブログにおいて、「DB・DWHの選択をする際は速度だけでなくて、製品自体の使いやすさなど別の要素で評価すべき」ということを述べた記事を出していました。

これは私も同意で、昨今のDB・DWHは動作速度で劇的な差が生まれることはないと思っているので、「いかにパフォーマンスチューニングが楽か」、「ユースケースに沿ったデータパイプラインの構築はどのように行えるか」、「他に併用する製品との相性は良いか」、などより実際に使っていく際の観点を重視して見ていくべきだと思います。

DataOps vs DevOps: Understanding the Difference

DataOpsとDevOpsについて、具体的にDataOpsとDevOpsの違いや、お互いに保管し合うものであるということを述べた記事がCastorDoc社から出ていました。

正直私はDataOpsについて、”DevOpsをデータ基盤向けに特化させたもの”くらいの感覚だったのですが、改めてこちらの記事は上手く文章化されていて参考になりました。

Data Extract/Load

Airbyte

RAG-as-a-ServiceであるVectaraをDestinationとして設定可能に

データをアップロードするだけでRAGの構築に関する諸々の処理を行ってくれるVectaraというサービスがあり、そのVectaraにAirbyteがDestinationとして対応しました。

以下の記事では、AirbyteのGoogleドライブコネクタを用いて、Googleドライブから抽出したドキュメントをVectaraにロードし、自然言語でアップロードしたドキュメントに関する内容を得ることができるという事例について説明しています。

Data Warehouse/Data Lakehouse

Snowflake

Snowpark Model Registryがパブリックプレビュー

Snowpark MLで学習したModelを管理できるSnowpark Model Registryがパブリックプレビューとなりました。

以下の記事に実際にどのようにモデルを管理して、モデルを用いて推論するのかがコード付きで書いてあるため、こちらも併せてご覧ください。

Amazon Kinesis Data FirehoseとSnowpipe Streamingで直接Snowflakeのテーブルにストリーミングが可能に　※プレビュー

Amazon Kinesis Data FirehoseとSnowpipe Streamingで直接Snowflakeのテーブルにストリーミングが可能になる機能がプレビューとなりました。

現在はUS East、 US West、Europeと限られたリージョンでの提供となる点にだけ注意が必要ですが、これまではKinesis Data Firehoseから一度S3を介してSnowflakeへロードする方法しかなかったため、今回の新機能でSnowflakeへのストリームデータパイプラインの構築がかなり楽になることが期待されます。

海外でも本機能に関する記事が出ていました。参考になるアーキテクチャ図もあるので、ぜひご覧ください。

Snowpark Container ServicesがTokyoリージョンでパブリックプレビュー

前回のまとめ記事でも書いたSnowpark Container Servicesですが、Tokyoリージョンでもパブリックプレビューとなりました。これで日本のユーザーも気軽に試せるようになりましたね。（検証時は利用費用にご注意ください…）

バッチ処理でデータロードを行う際のベストプラクティス

SELECT社により、Snowflakeでバッチ処理でデータロードを行う際のベストプラクティスをまとめた記事が出ていました。

大まかに、以下の内容がポイントと感じました。

• ロード元のストレージでのファイルは日付などに沿って整理すること
• ロード対象のファイルは圧縮後で100～250MBが望ましい
• ロード時のファイルの仕様は、FILE FORMATを用いて独立させて管理することが望ましい
• ステージは外部ステージを使い、資格情報の保持にはSTORAGE INTEGRATIONを使うこと
• ウェアハウスのサイズ選択に関する実例と考え方（詳細は以下の記事をご覧ください）

検索最適化サービスを使う際のベストプラクティス

Snowflakeの検索最適化サービスを使う際のベストプラクティスをまとめた記事が出ていました。

結論からの引用ですが、以下が検索最適化サービスを適用する際のポイントになります。詳細は記事をご覧ください。

• 非常に多数のマイクロパーティションがある (最低でも1000以上)
• 指定されたテーブルに対して、WHERE句に「=」の等価フィルターを使用したクエリを実行している
• テーブル内のマイクロパーティションの数に応じて、結果セット内の数行だけを返す必要がある
• UPDATEやDELTEの操作がほとんどない
• 非常に高速なクエリパフォーマンスが必要

BigQuery

cross-cloud joinsがプレビュー

Google CloudリージョンとBigQuery Omniリージョンの両方にまたがるクエリを実行できる「cross-cloud joins」がプレビューとなりました。

現在はリージョンや転送サイズなどで一部制限もあるようですので、詳しくは以下のドキュメントをご覧ください

Data Transform

dbt

公式によるdbt Semantic Layerの解説記事

dbt Labs社の公式ブログにおいて、dbt Semantic Layerの解説記事が出ていました。

MetricFlowとは、Semantic modelsとMetricsとは、どのような集計方法をMetricsで定義できるか、APIを介してどのように参照するか、MetricFlowのクエリ生成に関するアーキテクチャ、といった内容が書かれています。

ディメンショナルモデリングのチュートリアル

私の記事で恐縮ですが、昨年dbt Labs社のブログで公開されていたBuilding a Kimball dimensional model with dbtについて、dbt CloudとSnowflakeを用いて試してみました。

私も実際にやってみた感想として、ディメンショナルモデリングを学ぶ取っ掛かりとしては非常によいチュートリアルだと感じました。

Semantic Layer

Cube

BIライクのUIで開発したSemantic Layerを検証できる「Playground 2.0」を発表

Cubeが、BIライクのUIで開発したSemantic Layerを検証できる「Playground 2.0」を発表しました。

Lookerを使ったことがある方ならわかると思いますが、開発してさっと試したいときにLookerは開発中のコードでExploreでグラフを作って検証できるのですごい便利なのです。これと同じような開発体験が出来るのかなと期待しています。

LLM

Delphi

Semantic Layerに対して自然言語で問いあわせて関連するフィールドを抽出する機能を発表

DelphiがdbtなどのSemantic Layerに対して自然言語で問いあわせて関連するフィールドを抽出する機能を発表しました。

下記のリンク先にデモ動画もあるので、こちらも併せてご覧ください。

Data Application

Streamlit

Streamlitを用いたダッシュボードの構築例

Streamlitの公式ブログにおいて、Streamlitを用いたダッシュボードの構築例がコード付きで出ていました。私見強めですが、思っていた以上に多彩な表現ができることに驚きました。

Business Intelligence

Looker

「Looker Vision, Strategy, and Roadmap for 2024」が1月26日に開催

Lookerについて、最新機能や今後のロードマップなどについて説明するウェビナーが2024年1月26日3時～4時(日本時間)で開催予定です。

Looker 24.0がリリース

Looker 24.0について、リリースノートが公開されました。

Exploreでフィルタを作成するときにAND/ORフィルタリングの一般提供など、細かな機能がアップデートされています。

Steep

Semantic Layerで定義されたMetricsの利用に特化したBIツール「Steep」

Cube社のブログで偶然見つけた製品ではあるのですが、dbtやCubeなどのSemantic Layerで定義されたMetricsの利用に特化したBIツールとして「Steep」という製品を知りました。

2022年10月に発表されていた新興の製品ですが、気になるので今後も情報をチェックしていきます！

Data Catalog

Secoda

リネージの表示やAI機能を搭載したChrome拡張機能を発表

Secodaが、閲覧しているダッシュボードのリネージを確認したり、SecodaのAIに問い合わせできる機能を搭載したChrome拡張機能を発表しました。

Data Orchestration

Dagster

Dagster 1.6のリリース

Dagster 1.6がリリースされました。UIのダークモード、リネージグラフの改善、などUI周りのアップデートが多いようです。