実践！Azure Synapse を使用した分析のエンド ツーエンド「データ分析基盤構築 ~ 運用 編」

2nd Microsoft Data Analytics Day 発表資料

Transcript

1. 実践！Azure Synapse を使用した分析のエンド ツーエンド データ分析基盤構築 ~ 運用 編 2st Microsoft Data Analytics Day 2022/8/6 黒田 啓太
2. 2 アジェンダ 1 . は じ め に ( 5 m i n ) 1 . 検 証 目 的 ・ 発 表 目 的 に つ い て 2 . 前 回 の セ ッ シ ョ ン 内 容 振 り 返 り 3 . 今 回 の セ ッ シ ョ ン 内 容 に つ い て 2 . 本 題 ( 2 0 m i n ) 1 . 本 検 証 前 提 条 件 説 明 1 . 検 証 シ ナ リ オ 2 . ソ ー ス デ ー タ 1 . S h i f t 1 5 M ( 初 期 デ ー タ ・ 日 次 デ ー タ ) 2 . 天 気 デ ー タ ( o p e n w e a t h e r ) 2 . ア ー キ テ ク チ ャ 概 要 説 明 1 . ア ー キ テ ク チ ャ 全 体 像 2 . ア ー キ テ ク チ ャ 概 要 ( デ ー タ レ イ ク ) 3 . ア ー キ テ ク チ ャ 概 要 ( S t r e a m i n g ) 4 . 参 考 文 献 紹 介 3 . ア ー キ テ ク チ ャ 詳 細 説 明 ( デ ー タ 蓄 積 【 B a t c h レ イ ヤ 】 ) 1 . S o u r c e t o r a w ( L a n d i n g ) 2 . r a w ( L a n d i n g t o C o n f o r m a n c e ) 3 . r a w ( C o n f o r m a n c e ) t o e n r i c h e d / c u r a t e d ( S t a n d a r i z e d ) 4 . e n r i c h e d / c u r a t e d ( S t a n d a r i z e d t o c u r a t e d ) 4 . ア ー キ テ ク チ ャ 詳 細 説 明 ( デ ー タ 蓄 積 【 S p e e d レ イ ヤ 】 ) 1 . S o u r c e t o E v e n t H u b 2 . E v e n t H u b t o D a t a E x p l o e r 5 . T i p s ( 実 際 に 実 装 し て 困 っ た と こ ろ ・ う ま く い っ た と こ ろ ) 3 . 運 用 し て み て ( 5 m i n ) 1 . B a t c h レ イ ヤ 1 . 初 期 移 行 時 の 各 パ フ ォ ー マ ン ス 2 . 日 次 デ ー タ の 各 パ フ ォ ー マ ン ス 2 . S p e e d レ イ ヤ 1 . 天 気 デ ー タ の 各 パ フ ォ ー マ ン ス 4 . ご 相 談 ( 時 間 が 余 れ ば 、 、 ) 1 . デ ー タ レ イ ク の パ ー テ ィ シ ョ ン の 分 割 に つ い て
3. 3 はじめに
4. 4 検証目的・発表目的について 1.1 検証目的） 普段の仕事ではデータ分析基盤の開発フェーズから携わることが多いため、 設計フェーズから自分で実施して、データ分析基盤への理解を深める 発表目的） ・検証内で知りえた情報の共有をする ・他者の設計思想を取り入れ、より良い設計を目指す
5. 5 前回のセッション内容振り返り 1.2 前回のセッションでは、下図の赤枠の設計・実装について講演 出典：Azure Synapse を使用した分析のエンド ツー エンド|Microsoft Docs
6. 6 前回のセッション内容振り返り 1.2 Azure Files Azure Data Lake Storage Gen2 Serverless SQL pool (データモデリング) Spark pools (データクレンジング) Raw Data (履歴) Azure Synapse Analytics workspace Landing Bronze Silver Gold Managed Virtual Network Virtual Network Azure Virtual Machine (Ubuntu 18.04 LTS) Managed Private Endpoint 出典：Analytics end-to-end with Azure Synapse - Speaker Deck メダリオンアーキテクチャを使用したデータ分析基盤構築(Batch レイヤ)を説明
7. 7 今回のセッション内容について 1.3 今回のセッション内容） ・データレイクのレイヤーに沿って再設計したデータ分析基盤(Batch レイヤ) ・Speed レイヤで設計したデータ分析基盤 出典：Azure Synapse を使用した分析のエンド ツー エンド|Microsoft Docs
8. 8 本題
9. 9 本検証前提条件説明
10. 10 検証シナリオ 2.1.1 分析シナリオ：顧客が自身のコーディネートを投稿できるシステムを運用しており、 日次更新されるファッションコーディネートデータを取り込んで分析できる 分析基盤を構築したい • 分析要件：200万人のユーザーのうち、アクティブユーザー* を20万人と仮定 →日次データは20万件(年間7,200万件想定) 平日の20:00 ~ 22:00 に1日のデータの8割が連携されている ビジネス内容：ファッションのEC サイト運営 * アクティブユーザーは毎日コーディネートを投稿する • 顧客要件：瞬間のトレンドと、一定期間のトレンド両方が見たい 天気とトレンドがどう影響するか見てみたい レポートには画像も含めてほしい
11. 11 ソースデータ(Shift15M) 2.1.2 Shift15M） ・Transaction データ(JSON 形式) 項目名 サブ項目名 概要 set_id - 投稿された衣装を識別するID item item_id アイテムを識別するID category_id1 アイテムのカテゴリを示すID(アウター、トップスなど) category_id2 アイテムのサブカテゴリを示すID(Tシャツ、ブラウスなど) price 商品の価格(日本円) user user_id 衣装を投稿したユーザーを識別するID fav_brand_ids ユーザーがお気に入りとして投票したブランドIDのリスト like_num - この衣装が他のユーザーにお気に入りとして追加された回数 publish_date - 衣装が投稿された日付 Shift15M） ・Master データ(txt 形式) 項目名 概要 item_id アイテムを識別するID category_id1 アイテムのカテゴリを示すID(アウター、トップスなど) category_id2 アイテムのサブカテゴリを示すID(Tシャツ、ブラウスなど) Year アイテムが登録された年度 出典：ZOZO, Inc./zozo-shift15m/README.md|GitHub
12. 12 ソースデータ(天気データ【OpenWeatherMap】) 2.1.2 OpenWeatherMap） ・天気 データ(JSON 形式) 出典：現在の気象データ-OpenWeatherMap 項目名 サブ項目名 概要 coord lon 都市の地理的位置(緯度) lat 都市の地理的位置(経度) weather id 気象状態ID main 気象パラメータのグループ(雨、雪 等) description 気象パラメータのグループの詳細説明 icon 天気アイコンID base - 内部パラメータ main temp 温度(単位：K) feels_like 体感温度(単位：K) pressure 大気圧(単位：hPa) humidity 湿度(単位：%) temp_min API レスポンス取得時の最低気温(単位：K) temp_max API レスポンス取得時の最高気温(単位：K) sea_level 海面の大気圧(単位：hPa) grnd_level 地上の大気圧(単位：hPa) visibility - 視程 wind speed 風速(単位：m/s) deg 風向 clouds all 曇り(単位：%) rain 1h 過去1時間の雨量(mm) 3h 過去3時間の雨量(mm) snow 1h 過去1時間の積雪量(mm) 3h 過去3時間の積雪量(mm) dt - データ計算の時間 sys type 内部パラメータ id 内部パラメータ message 内部パラメータ country 国コード sunrise 日の出時刻(UNIX, UTC) sunset 日没時刻(UNIX, UTC) timezone - UTCから秒単位で遷移 id - 都市ID name - 都市名 cod - 内部パラメータ
13. 13 アーキテクチャ概要説明
14. 14 今回作成したアーキテクチャ全体像 2.2.1 本検証で構築したアーキテクチャは以下の通り
15. 15 アーキテクチャ概要(データレイク) 2.2.2 データレイクの 3領域(raw, enriched/curated, workspace)の用途・アクセスが想定されるユーザー は以下の通り Raw ： 生データを保管する ※メダリオンアーキテクチャでは Bronze に相当 Enriched/Curated：Enriched はデータクレンジングを実施する Curated はデータ分析用の加工を実施する ※メダリオンアーキテクチャでは Silver / Gold に相当 Workspace ：データエンジニア・データサイエンティスト・データアナリスト 等 各担当者の検証環境として使用する ※メダリオンアーキテクチャでは想定されていない データレイクレイヤ 履歴データ 日次データ 天気データ Raw データプロバイダー (standarized レイヤーへの連携処理作成担当者) データプロバイダー (standarized レイヤーへの連携処理作成担当者) (データプロバイダー)* Enriche / curated データコンシューマ (curated レイヤーへの連携処理作成担当者) データコンシューマ (curated レイヤーへの連携処理作成担当者) - Workspace データプロバイダー データコンシューマ (各レイヤーへの連携検証用) データプロバイダー データコンシューマ (各レイヤーへの連携検証用) - *バックアップデータのため、ユーザーアクセスは想定外
16. 16 アーキテクチャ概要(データレイク) 2.2.2 Azure Data Lake Storage Gen2 (raw) Landing Conformance Azure Data Lake Storage Gen2 (enriched/curated) Standardized Curated Azure Data Lake Storage Gen2 (workspace) Sandbox 1 Sandbox n Data Lake 出典：Azure Data Lake Storage - Cloud Adoption Framework | Microsoft Docs Delta Lake コンテナ区分 raw 領域： Landing(ソースからデータを読み込む) Conformance(データ品質チェックに合格したデータを格納) enriched / curated 領域： Standardized (分析に適したデータに加工する前のデータを格納) Curated(データコンシューマがアクセスし分析するデータを格納) Workspace 領域： Sandbox (データプロバイダーによる新しいデータの取り込み仕様 の検討、データコンシューマによる新しい分析切り口の検討) デルタレイクアーキテクチャ 利点 ・ACID特製を持つ(従来のデータレイクだと、管理できなかった トランザクション管理が可能) ・スキーマを持つため、データを高品質に保つことができる
17. 17 アーキテクチャ概要(Streaming) 2.2.3 Streaming 処理は以下のアーキテクチャの設計を実施 Azure Event Hub Azure Data Explorer Azure Functions HTTP Response HTTP Request Azure Stream Analytics 各 サービスの機能は以下の通り Azure Functions：API(Open Weather Map)へ HTTP Request送信・Azure Event Hub へのHTTP Response 送信 Azure Event Hub： API(Open Weather Map) の Response 受信 Azure Stream Analytics：データ加工 Azure Data Exploer：データ蓄積
18. 18 参考文献紹介(データレイク) 2.2.4 DataLake） 出典： Azure Data Lake Storage - Cloud Adoption Framework | Microsoft Docs データ レイクのゾーンとコンテナー - Cloud Adoption Framework | Microsoft Docs DeltaLake） 出典： Delta Lake on Databricks – Databricks
19. 19 参考文献紹介(Streaming) 2.2.4 Azure Functions） 出典： Azure Functions の開発 - Learn | Microsoft Docs Azure Functions の開発に関するガイダンス | Microsoft Docs Azure Functions のトリガーとバインド | Microsoft Docs Azure Event Hub） 出典： Azure Functions の Azure Event Hubs 出力バインディング | Microsoft Docs Python を使用して Azure Event Hubs との間でイベントを送受信する (最新) - Azure Event Hubs | Microsoft Docs Azure Stream Analytics） 出典： Azure に Stream Analytics を使用して Event Hubs からのデータを処理する - Azure Event Hubs | Microsoft Docs Azure Data Exploer） 出典：クイック スタート:Azure Data Explorer クラスターとデータベースを作成する | Microsoft Docs Azure Data Explorer のデータ インジェスト概要 | Microsoft Docs イベント ハブから Azure Data Explorer にデータを取り込む | Microsoft Docs
20. 20 アーキテクチャ詳細説明 データ蓄積【Batch レイヤ】
21. 21 Source to raw(Landing) 2.3.1 処理目的） データソースからデータ分析基盤へデータを連携する 移行場所は一時領域として定義している Landing への連携
22. 22 Source to raw(Landing) 2.3.1 実装） 履歴データ 1．Azure Files を Azure Virtual Machine にマウント 2．Azure Synapse Analytics の Data Copy Tool を使用して Azure Files から Azure Data Lake Storage Gen2 (Landing コンテナ)へデータ連携 日次データ 1．blobfuse を使用して、Azure Data Lake Storage Gen2(Landing コンテナ)をAzure Virtual Machine にマウント 2．Azure Virtual Machine 上でデータ連携 Azure Files Azure Data Lake Storage Gen2 (raw) Raw Data (履歴データ) Landing Azure Virtual Machine (Ubuntu 20.04 LTS) Raw Data (日次データ) blobfuse 以下の2つの連携方式でソースデータを データレイクに連携 Data copy tool ※履歴データ：データ基盤構築前に存在していた過去データ 日次データ：データ基盤構築後に連携されるデータ Raw Data (履歴データ) Raw Data (日次データ)
23. 23 Source to raw(Landing) 2.3.1 Azure Files と blobfuse を使用してみての利点・懸念点 Azrure Files ・手間がかかる(ファイル共有をマウントしたのちに データ移行処理を作成する必要がある) ・POSIX に準拠しているためセキュリティの担保ができる blobfuse ・簡単にデータ連携できる ・POSIX に準拠していない可能性があり、セキュリティに懸念(要検証) 出典：Linux 上で Azure Blob Storage をファイル システムとしてマウントする方法 | Microsoft Docs
24. 24 raw(Landing to Conformance) 2.3.2 処理目的） データの品質を担保する
25. 25 raw(Landing to Conformance) 2.3.2 実装） 履歴データ：Synapse notebook にて、Landing レイヤから Conformanceレイヤまでデータを連携 日次データ：Landing レイヤから Conformance レイヤまで Databricks のnotebook, Conformance レイヤ内で Synapse notebook で データを連携 以下の2つの連携方式でソースデータを データレイクに連携 ※履歴データ：データ基盤構築前に存在していた過去データ 日次データ：データ基盤構築後に連携されるデータ Azure Data Lake Storage Gen2 (raw) Landing Conformance Raw Data (履歴データ) Input Output Error Raw Data (delta 形式) Cleansed Data (delta 形式・データ品質担保) Defect Data (delta 形式 ・データ不良) Synapse notebook Synapse notebook Raw Data (日次データ) Databricks notebook
26. 26 raw(Landing to Conformance) 2.3.2 日次データにて Databricks notebook を使用している理由 連携されてきたそばからデータを取得したい(増分更新)ため →Databricks には Autoloader という機能が存在 Landing Conformance Azure Databricks Autoloader and Structured Streaming API Read Load Write ほぼリアルタイムでのデータ増分処理、集約が可能 出典：自動ローダー - Azure Databricks | Microsoft Docs
27. 27 raw(Conformance) to enriched/curated(Standarized) 2.3.3 処理目的） 品質の担保されたデータをデータ活用チームが使用できるようにする
28. 28 raw(Conformance) to enriched/curated(Standarized) 2.3.3 実装） Cleansed Data を Synapse notebook 使用して、 enriched/curated レイヤにデータ連携 enriched/curated レイヤには、データ活用チームのみがアクセスできるようにアクセス制御を実施 品質の担保されたデータをデータ活用チームが使用できるように enriched/curated レイヤに連携 ※履歴データ：データ基盤構築前に存在していた過去データ 日次データ：データ基盤構築後に連携されるデータ Azure Data Lake Storage Gen2 (raw) Conformance Output Cleansed Data (delta 形式・データ品質担保) Synapse notebook Standarized Azure Data Lake Storage Gen2 (enriched/curated) Cleansed Data (delta 形式・データ品質担保)
29. 29 enriched/curated(Standarized to Curated) 2.3.4 処理目的） データを加工し、活用できる形に変換する
30. 30 enriched/curated(Standarized to Curated) 2.3.4 実装） Cleansed Data を Synapse notebook 使用して、活用できる形に加工(集計等) 本検証では、ファッションコーディネートが登録された年月単位で、衣類価格の集計を実施 データ活用チームが品質の担保されたデータを活用できるデータに加工(集計 等) ※履歴データ：データ基盤構築前に存在していた過去データ 日次データ：データ基盤構築後に連携されるデータ Azure Data Lake Storage Gen2 (enriched/curated) Standarized Cleansed Data (delta 形式・データ品質担保) Synapse notebook Curated Curated Data (delta 形式・データ集計済み)
31. 31 アーキテクチャ詳細説明 データ蓄積【Speed レイヤ】
32. 32 Source to Event Hub 2.4.1 処理目的） データを加工し、活用できる形に変換する
33. 33 Source to Event Hub 2.4.1 Streaming 処理は以下のアーキテクチャの設計を実施 Azure Event Hub Azure Functions HTTP Response HTTP Request Virtual Network Azure Data Lake Storage Gen2 (raw) Landing 実装） HTTP Request：ps1 ファイルを使用して Open Weather Map へ リクエストを送信 HTTP Response：json 形式で応答を Event Hub にて受信 Backup：Event Hub のキャプチャ機能を使用して、受信した応答を avro 形式で格納 ※Event Hub のキャプチャ機能は現在 avro か parquet 形式での格納しかサポートしていない Json 形式 avro 形式
34. 34 Event Hub to Data Exploer 2.4.2 処理目的） データを活用できる形に加工し、蓄積する
35. 35 Event Hub to Data Exploer 2.4.2 Streaming 処理は以下のアーキテクチャの設計を実施 Azure Event Hub Virtual Network 実装） １．Azure Event Hub にて受信した json 形式のファイルを Azure Stream Analytics で読み取り、フラット化を実施 ２．フラット化したデータを Azure Data Exploer に格納し、データの蓄積を実施 Json 形式 Azure Stream Analytics Azure Data Exploer Json 形式 フラット化 DBへ格納
36. 36 Tips 実際に実装して困ったところ・うまくいったところ
37. 37 Tips 2.5 Data Exploer へ 構造化したJson ファイルを読み込む際の注意点 ファイル形式を JSON から MULTILINE JSON に 変更すると取り込めるようになる
38. 38 運用してみて Batch レイヤ
39. 39 履歴データ処理時の各パフォーマンス 3.1.1 Executor の使用率が 40％台なので、 もう少し効率を上げることが できるか？ 出典：拡張された Spark 履歴サーバーを使用してアプリをデバッグする - Azure Synapse Analytics | Microsoft Docs
40. 40 日次データ処理時の各パフォーマンス 3.1.2 検証結果） メモリ 126GB(14GB/1 executor * 9) , CPU 4 core のスペックで、 処理できる日次データは、100 ~ 110 record / sec (１batch では 4,000レコード) ※Executor はすべて稼働している
41. 41 運用してみて Speed レイヤ
42. 42 天気データ時の各パフォーマンス 3.2.1 前提条件） 毎分 Http Request を OpenWeatherMap に投げている Event Hub 出典：Azure Event Hubs データの監視のリファレンス - Azure Event Hubs | Microsoft Docs
43. 43 天気データ時の各パフォーマンス 3.2.1 前提条件） 毎分 Http Request を Open Weather Map に投げている Stream Analytics 出典：Azure Stream Analytics のジョブ メトリック | Microsoft Docs
44. 44 天気データ時の各パフォーマンス 3.2.1 前提条件） 毎分 Http Request を Open Weather Map に投げている Azure Data Explorer 出典：メトリックを使用した Azure Data Explorer のパフォーマンス、正常性、および使用状況の監視 | Microsoft Docs
45. 45 ご相談
46. 46 データレイクのパーティションの分割について 4.1 相談事項） 今の仕様だと、delta log が パーティション(日付)ごとに作成されてしまっている。 現状だとdelta lake の強みであるトランザクションの履歴を保持できるという強みが生かせて いないのではと思っている。 （日単位で、トランザクションログが出来上がるため。。 トランザクションログはより上位のほうが操作履歴を確認するときに生かせると思っている 下記の例でいうと Input フォルダ配下に delta log がある必要があるのでは？） 後ほどご意見を伺いたいです。 現状） 下図のように runDate=yyyyMMdd の配下に delta log フォルダができている
47. 47 終わり
48. 48 Appendix(検証に使用したフォルダ構成)
49. 49 Azure Virtual Machine フォルダ構成 2.4 Azure Virtual Machine <user ディレクトリ> adlsourcevm fs-source iqon_outfits.json item_catalog.txt … mycontainer scripts 00_exec createcsv.py cron.sh csv adlsfs-source to/ fuse_connection.cfg 1st 2nd 3rd adlsourcevm fs-source - 初期移行用データ を格納 adlsfs-source to - blobfuse　使用時の構成ファイルを格納 mycontainer - - blobfuse 使用時のmount 用フォルダ scripts 00_exec csv createcsv.py にて作成された日次データを格納 - 日次データを作成するスクリプトファイルを格納 フォルダ階層 用途説明 初期移行(履歴データ)用 日次データ用
50. 50 Azure Data Lake Storage Gen2 (raw) 2.4 Azure Data Lake Storage Gen2 (straw001) landing General Transactional Shift15M iqon_outfits Version Delta runDate=yyyyMMdd Full openweather weather Version Version は実際は “1”
51. 51 Azure Data Lake Storage Gen2 (raw) 2.4 Master and Reference Shift15M item_catalog Version Delta runDate=yyyyMMdd Full Delta runDate=yyyyMMdd Full Version は実際は “1” {EventHub Namespace名} {EventHub名} {PartitionId} {Hour}/ {Minute}/ {Second}
52. 52 Azure Data Lake Storage Gen2 (raw) 2.4 Shift15M Sensitive
53. 53 Azure Data Lake Storage Gen2 (raw) 2.4 Azure Data Lake Storage Gen2 (straw001) conformance General Transactional Shift15M iqon_outfits Version Input runDate=yyyyMMdd Output runDate=yyyyMMdd Error runDate=yyyyMMdd Delta Version は実際は “1”
54. 54 Azure Data Lake Storage Gen2 (raw) 2.4 Input runDate=yyyyMMdd Output runDate=yyyyMMdd Error runDate=yyyyMMdd Full MasterandReference Shift15M item_catalog Version Delta Input runDate=yyyyMMdd Version は実際は “1”
55. 55 Azure Data Lake Storage Gen2 (raw) 2.4 Output runDate=yyyyMMdd Error runDate=yyyyMMdd Input runDate=yyyyMMdd Output runDate=yyyyMMdd Error runDate=yyyyMMdd Full Version は実際は “1”
56. 56 Azure Data Lake Storage Gen2 (Enriched/Curated) 2.4 Azure Data Lake Storage Gen2 (Enriched/Curated) Standardrized General Transactional Shift15M iqon_outfits Version createDate=yyyyMMdd item_catalog Version createDate=yyyyMMdd Shift15M MasterandReference Version は実際は “1”
57. 57 Azure Data Lake Storage Gen2 (Enriched/Curated) 2.4 Azure Data Lake Storage Gen2 (Enriched/Curated) Curated AnalyticsTeam dimention item_catalog Version aggDate=yyyyMMdd iqon_outfits Version aggDate=yyyyMMdd fact Version は実際は “1”
58. 58 Azure Data Lake Storage Gen2 (workspace) 2.4 Azure Data Lake Storage Gen2 (workspace) AnalyticsSandbox <任意のフォルダ階層> Cleansing Sandbox <任意のフォルダ階層>