しばやん雑記

Azure とメイドさんが大好きなフリーランスのプログラマーのブログ

Hack Azure! #4 - Synapse と Cosmos で実現するサーバーレスデータ分析 フォローアップ

Hack Azure! #2 の Cosmos DB 回の時から何時かはやりたいと言っていた Synapse Analytics の回を開催しました。別名 Microsoft 畠山さんに何でも聞ける会という感じです。

少し前に Synapse Link for Cosmos DB を Synapse SQL Serverless で使う機能が Public Preview になったので、主にその辺りを取り上げました。名前が SQL on-demand から SQL Serverless に変わりつつあるという話もありました。

今回はやばいぐらい濃い話が多かったのでまとめるのに苦労しました。最後の方はよく分からないけどめっちゃ凄そう(こなみかん)という感じでした。

そろそろ App Service / Azure Functions の回をやりたいような気もしますが、話すネタがありそうで無い気もします。VNET 周りのアナウンスがあるまで難しそうな予感です。

Twitter まとめと YouTube アーカイブ

例によってツイートのまとめと YouTube のレコーディングは既に公開しています。今回は畠山さんのデモとトークに価値があるので、YouTube でのレコーディングは必見ですね。

今回は内容が濃かったのでツイートは少なめでしたね。自分も最後の方は「わからん」しか書いていません。

Synapse Analytics + Cosmos DB = 強い

Cosmos DB はスキーマレスで JSON での構造を持っていて、I/O に非常に強いデータストレージですが、それと引き換えにクエリには割と制約が多いです。最近は色々なクエリが使えるようになってきましたが、RDB には太刀打ちできません。

その辺りの制限を Synapse Analytics と Analytical Store を使うことで、解消できるというのが今回のメイントピックでした。Analytical Store はコストが安く、Synapse Link 経由でクエリを投げることが出来ます。

Synapse Analytics と Cosmos DB を組み合わせることで、サクッとデータ分析が行えるのはかなり強いですね。ちょまどさんのこのツイートが面白かったので貼っておきます。

Analytical Store 関連

Cosmos DB の Analytical Store は Synapse Link 経由でしか触れないのと、Analytical Store を使わないとコスト的にもやばいことになるので必須です。Cosmos DB はドキュメントがよくまとまっています。

いろいろな話が出てきましたが、気になった部分とはまりそうな部分についてピックアップしました。

データ・スキーマの自動同期

個人的に一番衝撃的だったのが Analytical Store へのデータ同期は大体 2 分以内で、特定のケースでは 5 分近く遅延が発生するということでした。大量データ分析目的では気にならない遅延だとは思いますが、てっきり数秒で同期されるものだと期待していたので少し残念でした。

Auto-sync latency is usually within 2 minutes. In cases of shared throughput database with a large number of containers, auto-sync latency of individual containers could be higher and take up to 5 minutes.

What is Azure Cosmos DB Analytical Store (Preview)? | Microsoft Docs

この後に出てくる裏側の話にもつながりますが、Cosmos DB はスキーマレスなので 1 つのドキュメントに後からプロパティが追加されることも良くあります。

そういった時に Analytical Store ではどのように扱われるのか気になりましたが、プロパティが追加された場合には自動的にスキーマを統合して更新してくれるようです。この辺りはドキュメントに詳しく書いてありますが、多少スキーマに対する制約があります。

As your schema evolves, and new properties are added over time, the analytical store automatically presents a unionized schema across all historical schemas in the transactional store.

What is Azure Cosmos DB Analytical Store (Preview)? | Microsoft Docs

スキーマレスとは言いつつも、ある程度のスキーマは必要になってくるのでデータモデリングには時間をかけたいところです。これは Analytical Store 関係なく Cosmos DB 利用時の全般に言えますが。

裏側は Azure Storage + Parquet らしい

Synapse Analytics から使うだけの場合は気にする必要はないのですが、Analytical Store の裏側は Azure Storage と Parquet 形式のファイルになっているらしいです。ライブではムッシュが実際にエラーを出して証明してくれました。

Synapse Link for Cosmos DB では、Cosmos DB の分析ストアにアクセスされますが、このストアは BLOB 上に保存されている snappy の圧縮形式が使用された Parquet ファイルのようです。

Synapse Analytics の Serverless SQL Pool (SQL on-demand) でテキストを参照する際の文字コードの設定 (おまけで Synapse Link for Cosmos DB) at SE の雑記

Parquet はスキーマを持ったカラムナフォーマットなので、前述したとおり Cosmos DB から Parquet を作成する場合には何らか方法でスキーマを作る必要があります。そして追記も基本は難しいので、2 分間の遅延というのはバッファリングしているということなのでしょう。

これでストレージ容量が安い理由は納得できました。Change Feed 至上主義者なので、場合によっては独自に ADLS に書き込む処理を書いた方が良い気もしています。ユースケースに合わせて選択しましょう。

照合順序には要注意

今のところ Synapse Link for Cosmos DB を触った人の 100% がはまっている気がする文字化け問題ですが、畠山さんの記事とムッシュのブログを読んでおけば完璧に理解できるはずです。

デフォルトを UTF-8 対応にしておいて欲しさしかないですが、歴史的経緯がありそうな気がします。

Spark pool も結構良さそうな話

Synapse SQL Serverless で Analytical Store を触れるようになった関係上多く取り上げましたが、後半では Spark pool を立ち上げて Notebook からクエリを書いてメタデータテーブルを作成していました。

専用の Pool を立ち上げるのは微妙だと思っていましたが、必要な時だけ立ち上げて自動で落とせるらしいので、割とありかなと思い始めました。

Notebook 上で Python ではなくて C# と LINQ で書きたい気持ちが高まってますが、今のところは出来なさそうです。この辺りは MS と .NET for Apache Spark の頑張り次第な気がします。*1

Query Acceleration との関係

Ignite 2020 のセッションでは Synapse Analytics と Deeply integrated と言われていた Query Acceleration との関連も少し話題に出ました。Synapse Analytics はブラウザからサクサク弄るのがメインですが、Query Acceleration はアプリケーションから使う前提になっています。

対応するファイルフォーマットは CSV / JSON で、単一の Blob に対してしかクエリを書けないですがアプリケーションから使う分にはこれで十分だと思います。Blob Index Tags と組み合わせて検索出来ればかなり強いと思っています。

共有メタデータと仮想 DWH の話

この辺りから理解が追いつかなくなってきましたが、頑張って適当にまとめます。Synapse SQL Serverless で扱われるテーブルはデータ自体は持っておらず、必要なメタデータだけを保持しているらしいです。

そして Spark もテーブルを作成出来ますが SQL Serverless から利用することが出来るので、1 つのクエリ内で複数データベースを同時に参照できるようです。正直 Spark 力が無さ過ぎて混乱の極みです。

畠山さんは最後の方で Power BI と Synapse SQL Serverless を使って、DWH を用意するのではなくオンデマンドで利用する仮想 DWH という話をされていました。この辺りも理解が正しいのか不安です。

Power BI から利用する場合には Import と DirectQuery の 2 つのモードがあるようですが、まずは Import を使うのが良いそうです。Power BI 力も低いので混乱の極みです。

個人的には SQL pool ってほとんど必要ないのだなぁという感想でした。ML 周りでは必要らしいですが。

Synapse で使われている分散 SQL エンジンの論文

最後の最後で英語の論文が出てくるとは完全に思っていませんでしたが、きっとムッシュが詳しい解説をしてくれると信じて論文のリンクだけを貼っておきます。

POLARIS: The Distributed SQL Engine in Azure Synapse

色んなソースからのデータをハッシュで分散して 1 つの Data Cell として扱うことで、効率的かつデータソースに寄らない分散クエリを実現しているっぽいのですが、正直よくわかりませんでした。