What's Data Lake ? Azure Data Lake best practice

1st Microsoft Data Analytics Day(Online)
https://sqlserver.connpass.com/event/237577/

発表資料

6/25改訂

Transcript

1. What’s Data Lake Azure Data Lake best practice Microsoft MVP for Data Platform 2021 永田 亮磨 Twitter:@ryomaru0825 Linkedin:ryoma-nagata-0825 Qiita:qiita.com/ryoma-nagata
2. • 対象者 • データレイク、データウェアハウス（DWH）というキーワードに興味のある方々 • ゴール • データレイクに関するキーワードを理解すること • 最新のデータレイクおよびデータ基盤の全体像をつかむこと • 【Stretch!】本日学んだ内容を皆様のデータ活用に活かせるようになること 本セッションについて
3. 1. データレイクの背景と需要、未来 ※初級～中級者向け 2. データレイクの論理構成 ※中級～上級者向け 3. データレイクの詳細構成 ※中級～上級者向け AGENDA
4. データレイク 背景と需要、未来 モチベーションと基礎概念
5. • DWH:データを集約し、保管するデータの倉庫 • データマート:分析に適した形式に整えられたデータ群(Curate Data) • ディメンショナルモデルや、ワイドテーブル、サマリーテーブルなど • データマートのためのBIサーバーで保持することもある 従来のDWH,データマート構成 *ETL : Extract・Transform・Load デ ー タ 抽 出 ・ 変 換 ・ 取 込 Data Warehouse Data Sources Data Marts (Curate) BI Dashboard Explorer 分 析 ETL*と呼ばれるプロセス
6. • ETL:DWHに保管する前に変換をかける • ELT:未加工のデータを保管した後で変換をかける • 未加工データをDWHで提供することで、より柔軟な分析ユースケースに対応 • 未加工データがあることで、後続データを再生成可能（壊滅的なロジック変更にも対応できる） • ただし、現在一般的なELTはDWHでは行わないことが多い（理由は後述） ETLからELTへ Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Raw デ ー タ 変 換 Data Sources デ ー タ 抽 出 ・ 取 込
7. • ELT自体は新しい考えではないが、生データに対する柔軟性の欠如という問題がある • DWHはデータベースであるため、“テーブル”として、列、型を定義する必要がある • DWHでは、jsonフォーマットなどの非構造化データの保持が難しい DWHでのELTの限界 { "name" : "cat", "count" : 105, “owner”:{“name”:”abe”} } { "name" : "dog", "count" : 81 } abe, 95, 46, 85, 85 itoh, 89, 72, 46, 76, 34 5列のデータ 4列のDWHテーブル フラット構造、定型のDWHテーブル 不定形、ネスト構造のデータ 余分列の削除 ネスト構造の 排除など 改修コスト Json格納列など 無理のある実装
8. • スキーマの定義や、ファイル形式の制限なく、自由に低コストで多様データを保管可能に • ELTというと、データレイクを前提とした構成を指すことが多い • Machine Learning分野においてもデータレイクの利用が好まれた データレイクの登場 デ ー タ 抽 出 ・ 取 込 Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Raw デ ー タ 抽 出 ・ 取 込 ・ 変 換 Data Lake ML Model 解 析 ML Data Sources
9. データレイクの考え方「Schema-on-Read」 abe, 95, 46, 85, 85 itoh, 89, 72, 46, 76, 34 ueda, 95, 13, 57, 63, 87 emoto, 50, 68, 38, 85, 98 otsuka, 13, 16, 67, 100, 7 katase, 42, 61, 90, 11, 33 {"name" : "cat", "count" : 105} {"name" : "dog", "count" : 81} {"name" : "rabbit", "count" : 2030} {"name" : "turtle", "count" : 1550} {"name" : "tiger", "count" : 300} {"name" : "lion", "count" : 533} {"name" : "whale", "count" : 2934} xxx.xxx.xxx.xxx - - [27/Jan/2018:14:2 0:17 +0000] "GET /item/giftcards/372 0 HTTP/1.1" 200 70 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1" ネイティブフォーマットを、そのまま蓄積 SELECT ~~~ FROM ~~~ WHERE ~~~ ORDER BY ~~~; 利用時にスキーマ（データ構造）を定義 Schema-on- Write • あらかじめスキーマ （データ構造）を定義 した場所に書き込む Pros • 確実なデータ型 • ユーザー利便性 Cons • データ型に準拠しない データの埋没、柔軟性 欠如 Schema-on- Read • 保存時にはスキーマ （データ構造）を定義し ない • 利用時にはじめて スキーマ・データ構造を定 義し、Read を実施 Pros • 将来の分析需要への対 応 • 保持データの柔軟性 Cons • 利用の際にデータ型を定 義する必要があり、データ 利用のハードル増
10. • データレイクで、本当の意味での生データを保持できる一方で、型、列定義の適用されないデータは扱いずらい • →”ほぼ”未加工でありながらクレンジング済みとなる、利用可能データ（Enrich Data）を提供する仕組みも求められた • Enrich Dataでは、Curate同様、スキーマを定義することで利便性を向上する 生データ、未加工データに対する考え方 デ ー タ 抽 出 ・ 取 込 Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Raw Data Lake ML Model ML Enrich デ ー タ 抽 出 ・ 変 換 ・ 取 込 デ ー タ 変 換 解 析 Data Sources
11. • 従来のDWH中心の世界 • ストレージとコンピューティングが一体化されており、変換処理の性能限界＝DWHのエンジンの限界であった • データレイクの世界 • 単なるストレージのため、コンピューティングが分離され、複数台、様々なスペック、様々な製品で処理が可能であり拡張性に優れる ※最新のDWH製品でもこのようなアーキテクチャがとられているものがあるが、データレイクはよりアクセス手段が多くなる 補足） ストレージとコンピューティングエンジンの分離 11 エンジン ストレージ ストレージ エンジン エンジン 製品A 製品B Data Lake Data Warehouse
12. • データレイク上で変換用に分散処理フレームワーク（Hadoop,Spark）を利用することによるスケーラビリティ向上 • 分析クエリ処理性能（DWH）とデータ変換処理性能（データレイク）で異なるリソースを利用して適材適所化 • データレイク上にデータがあることで、複数種のシステムへの展開が可能＝ベンダーフリー Modern Data Warehouse デ ー タ 抽 出 ・ 取 込 Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Raw Data Lake ML Model ML Enrich Enrich Curate 解 析 デ ー タ 変 換 デ ー タ 変 換 データ抽出・取込 データ抽出・取込 Data Sources
13. 適材適所化を考えるうえでのDWH/データレイクの強み、弱み • 強み • SQLでのアクセス利便性 • スキーマ（テーブル、列、データ型、制約）が適用さ れていることによる、データ品質の担保 • 弱み • 非構造化データ対応が困難 • データべース専用ストレージに保管されることにより • コスト増 • 処理性能はDWHのコンピューティング性能に依存する • SQLを発行するツールでしかアクセスできない • 強み • 非構造データへの対応によるデータサイエンス対応 • 汎用的なストレージに保管されることにより、 • 低コスト保管 • 多用な製品からアクセス可能 • 性能はアクセスする側のコンピューティング性能によって決まる • 弱み • スキーマを強制できないため、データの整理や、品質を 担保することが難しい • ファイルでの運用となるため、DWH時代で実行できた SQLで更新削除するなどのメンテナンス作業が困難 DWH データレイク BIツールからのアクセスや、 分析SQL処理に専念させる データサイエンスや、 保管と事前の変換処理層 として扱う
14. • 性能やユースケース対応などを拡張可能な状態になったが、課題も発生 • アクセス先がわかれることによるユーザビリティの低下 • システム構成の複雑さによる運用性（バッチとストリーム処理への対応など） 適材適所の功罪 14
15. • 性能やユースケース対応などを拡張可能な状態になったが、課題も発生 • アクセス先がわかれることによるユーザビリティの低下 • システム構成の複雑さによる運用性 適材適所の功罪 15 シンプルな方式で 実現できないのか？
16. Data Sources Delta LakeによるData Lakehouse 16 • ストレージ層にDWH機能＋αをSWレベルで構成し、DWHとデータレイクのいいとこどりを実現する • DWHライクなデータ管理性 • データレイク譲りのコスト効率、柔軟性 • ストレージとコンピューティングの分離によるスケーラビリティ • SQL / Python双方のAPIをもつことによる透過的なデータアクセス ストレージ層 BI Dashboard Explorer SQL Lakehouse ML Model ML Pythn コンピューティングエンジン API Raw Enrich Curate
17. • データ分析基盤における米ユニコーン企業であるDatabricks社が開発した、 データレイクハウスの中核を担うOSS 次世代データ基盤むけOSS Delta Lake メリット • オープン性： ベンダーロックインなく、あらゆるツールからアクセス可能 • レイク上でのDWH機能の実現： • UPDATE,MERGEを含むトランザクション処理 • SQL 、Python 双方での共通データアクセス • タイムトラベル機能による過去データの遡り • データレイクの長所を維持： • 実態はparquetファイルのため高圧縮率→コスト効率大 • json、バイナリなどの非構造化データに対応 https://delta.io/
18. データレイクの論理構成 データレイクの構成単位について
19. • メダリオンアーキテクチャ（別名：マルチステージアーキテクチャ） • ステージ毎のデータの役割明確化による、ガバナンスへの好影響 • Bronze (Raw)データ： • 後続を再生成可能にする生データ • 構造化の欠如、重複などの品質不足を受け入れるため、公開されるべきではない状態となる • Silver(Enrich)データ： • データ構造を適用し、品質チェックを適用された、公開すべき状態の利用可能データ（Single Source of Truth） • Gold(Curate)データ： • データマートとも呼ばれる状態。シナリオに適合した変換を加えた調整済みデータ データレイク内のゾーン Bronzeデータ （Raw） Goldデータ （ Curate ） Silverデータ （ Enrich ） データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ
20. • より実践的には追加の３つのゾーンが考えられる • Ingest (アップロード)： • データソースからの取得方法にはPullか被Push型があり、被Pushの際にはこちらを利用してソースシステム主体でアップロードする。 • Landing（着陸）: • 取得したデータをそのままファイル配置する。バックアップ的な意味合いが強い。 • Workspace（分析サンドボックス）： • Curate の処理や分析を試行錯誤する作業環境 • 成熟した処理はCurateのために昇格される データレイクゾーンの実践
21. • The Hitchhiker's Guide to the Data Lake | Azure Storage • Shaping The Lake: Data Lake Framework – Adatis • Zones in a Data Lake — SQL Chick • How to structure the Data Lake | The Digital Talk • The Fundamentals of Data Warehouse + Data Lake = Lake House | by Garrett R Peternel | Towards Data Science その他データレイクゾーンの参考
22. • 全社で一つのデータレイクを利用 • Pros • 完全な中央統制 • Cons • 物理的にも一つのデータレイクである場 合、アクセスが集中し、スケーラビリティに 制限 • 各個社がグローバルに散在している場合、 リージョン間の距離による遅延の増大 全社共通データレイク 全社 Data Lake 各個社、拠点 各個社、拠点
23. • リージョン用のデータレイクを構成し、地 理的に近い場所でレイクを利用する • リージョン専用データ、グローバルに展開 が必要なデータを区分けし、グローバル に展開するデータは各リージョンレイクに レプリケーションする • Pros • 地理的な近さによる待機時間の低減 • GDPRなどのデータ持ち出し要件への対応 • 複数ストレージによるスケーラビリティ • Cons • 構成の複雑さ • データの複製による各種コスト リージョン、グローバルレイク Global Data Lake Region(JP) Data Lake Region(US) Data Lake
24. • データストアをドメイン毎に構成すること で、データの所有を組織で分散する。 データのマイクロサービス化 • 各ドメインで昇華されたデータは データ製品とされ、他ドメインと共有規 約に基づき再利用される • データガバナンスの体制は中央に単 一集約することで統制を維持すること がトレンド • 各ドメインにおいて同じ手法、構成をと ることで技術サイロをなくすことを推奨 • ※ただし、異なる手法でも共有の仕組 みがあれば各ドメインがどのクラウドサービ スを利用するなどは自由度を確保できる Data Mesh アーキテクチャ • https://docs.microsoft.com/ja-jp/azure/cloud-adoption-framework/scenarios/data- management/architectures/reference-architecture-data-mesh#data-management-and-analytics-scenario
25. • Data Meshの代表的な記事では以下のように差異が示される Data Meshとモノリスデータ基盤 • https://martinfowler.com/articles/data-monolith-to-mesh.html • 消費パターン（ユースケース）が少ない組織では機能するが、 拡大しにくい • データのユースケースは組織が成熟するにつれて増大する • 本来の所有者と中央組織のドメイン知識のギャップ モノリスデータ基盤 データメッシュによるデータ基盤 • 対象のデータの専門家によりデータは製品化され、所有される。 セルフサービスデータ活用をうながす • ※無秩序にDWHを点在させることを促しているわけではない
26. • データメッシュの概念について理解する - connecting the dots (hatenablog.com) • Data Mesh: Centralized ownership vs decentralized ownership | James Serra's Blog • 成功するデータメッシュの構築 – 単なるテクノロジーイニシアチブ以上のもの|リン クトイン (linkedin.com) • Data Trends: Comparing Data Fabrics, Data Meshes, And Knowledge Graphs – Diffblog (diffbot.com) • Data Mesh: The Balancing Act of Centralization and Decentralization | by Piethein Strengholt | Mar, 2022 | Towards Data Science Data Mesh その他参考
27. データレイクの詳細構成 Azure Blob Storage/Data Lake Storage Gen2でのベストプラクティス
28. • Azureの標準的なオブジェクトストレージサービスである、 Blob Storageをデータレイクのワークロードに最適化し、拡張したサービス • 最大5PiBのデータ容量（ストレージアカウント準拠） Azure Data Lake Storage Gen2の特徴 • https://docs.microsoft.com/ja-jp/azure/storage/blobs/data-lake-storage-introduction#designed-for-enterprise-big- data-analytics Blob Storage Data Lake Storage Gen 2 ライフサイクルポリシー管理 によるデータガバナンス (Hot / Cool / Archive) ACL
29. • データ沼を避け、データレイクを整理する • Storage Accountの制限をふまえて、性能を保ちながら大規模なデータレイク へ進化する • ガバナンス、セキュリティを最適化する 重要な検討事項
30. • 以降はCAFとして提供される 「データ管理と分析のシナリオ用のランディングゾーン*」 がベースの内容となります。 • Azure データ管理と分析のシナリオの概要 - Cloud Adoption Framework | Microsoft Docs • ハイブリッドデータメッシュ型の思想で設計されており、 デプロイテンプレートや、チーム構成のガイダンスなど、データ 基盤を構成するためのナレッジとコードが提供されています。 データランディングゾーンから学ぶデータレイク *ランディングゾーン：Azure上のシステム構成パターン
31. • ランディングゾーンごとに計3～4つのストレージアカウントを用いる • Data Lake Storage Gen2×3 • Landing & Raw用 • Enrich & Curate用 • Workspace用(Synapseにつき一つ） ストレージアカウントの種類と数 • データ管理および分析シナリオの Azure Data Lake Storage の概要 - Cloud Adoption Framework | Microsoft Docs • Blob Storage×1～(必要な数を構成) • Ingest用
32. • 一般的な懸念 • 複数のアカウントを利用することによるコスト →Azure Storageは完全な従量課金制となり、複数のアカウントを利用することは余分なコスト 増にはつながらない • データサイロの形成 →Azure上のデータサービスは権限さえ構成すればアカウントが異なっていても簡単にアクセスが可 能 ※サイロの観点は重要なので、共有が難しい設計とならないように注意 • 複数構成が推奨される理由 • リージョン/グローバルレイク構成をとることによるコンプライアンス対応、待機時間低減 • データのステージにより冗長構成を変えることでコストを最適化 • RAW=RA-GRS、Enrich/Curate=ZRS、Workspace=LRSなど • ACLの上限を回避しやすくなる Data Lake Storage Gen 2を3つ構成する理由 • データ管理と分析のシナリオに関してよく寄せられる質問 - Cloud Adoption Framework | Microsoft Docs
33. • データレイク用途ではZRS以上の利用が推奨されている • RA-GRSかGRSか • GRSは障害時にフェールオーバーを必要とするが、Data Lake Storage Gen2では現在顧客によるフェー ルオーバーをサポートしていないため、データレイクにはGRSではなく、RA-GRSが推奨と考えられる • ディザスター リカバリーとストレージ アカウントのフェールオーバー - Azure Storage | Microsoft Docs • 冗長性オプションの代表的なイメージ 補足：ストレージ冗長性 • データの冗長性 - Azure Storage | Microsoft Docs ZRS（ゾーン冗長） GRS（リージョン間冗長） LRS（ローカル冗長） ZGRS（ゾーン×リージョン間冗長）
34. • 利点： • DMZとしての役割： • 特定のソースシステムへのネットワーク開放が必要な場合、Ingestストレージ側でネットワーク開放をすることで、 Landing/Raw領域のセキュリティを維持する ことが可能 • 3rdパーティ対応： • blobストレージは一般的であり、3rdパーティ製品でのサポートされることが多い • 注意事項： • Blobストレージを用いた場合に階層空間ではない保持形式となるため、空フォルダは作成できない • Data LakeはBlob Storage互換APIを利用可能であるため、Data Lakeを利用するのも手 データのIngest領域として 個別のストレージアカウントを構成する利点 • アップロードインジェストストレージ
35. • Data Landing Zoneでは データ製品の種類に基づいたコンテナ+既定１として指針が示されている • 既定用（下記のdata）は共通ファイルなどに利用可能 • データ製品（統合）： • Landing～Enrich作成までを担当する。データ統合を目的としたアプリケーション開発チームが主管する • コンテナ名の例）di001-raw（data integration） • データ製品（活用）： • Enrichを参照し、Workspaceで作業、Curateを作成する。分析エンジニア、データサイエンティストなど • コンテナ名の例）dp001（data product) コンテナ数（ファイルシステム数） di001-raw Landin/Raw di001-enrich Enrich/Curate dp001-curate data data dp001-work Workspace data di001-landing
36. • データを製品とみなす考え方 • データ製品は多種多様であり、 その実像となるのはアプリケーションである場合 はもちろん、 データ自体がデータ製品となる場合がある • アプリケーションとしての製品例 • BIによる分析アプリケーション • MLによる需要予測アプリケーション • データ価値を高めるデータ統合アプリケーション • データ自体としての製品例 • クレンジングされたEnrichデータ • 価値向上のために結合変換されたデータ • ML,BIのために生成された二次利用可能なCurate データ • データ製品はそれぞれがデータを受け渡しあい 構成される データ製品について • Azure でのクラウド規模の分析のデータ製品 - Cloud Adoption Framework | Microsoft Docs データ製品は異なる製品に消費される 製品の姿はさまざま
37. • データ製品（統合）はEnrichクレ ンジングまでを担当する • Enrichは場合によってはソースから もってくるのみで、 加工していないにもかかわらず（むし ろそれが有用） 後続の製品に利用される価値ある 製品とみなされる • データのEnrichまでは 完全にデータソースと対になる領域 であるため、 データソースの属する事業ドメインの エキスパートにて管理され、データを 連携・クレンジングするアプリケーショ ンが開発される データ製品（統合）について 各事業領域のデータ製品がドメインごとに所有され、 開発するチームは品質を製品として担保する 新たな データ製品 （活用） 消費
38. • 組織の方向性により、複数の事業データの統合を同じチームがインフラ的に行う場合が ある（割と多い印象 • それ自体はよいが、自動化するなどスケールする仕組みが必要 • データメッシュの設計に基づき、各事業領域のドメインエキスパートを含むデータチチーム が製品を作り上げるのが理想的 補足） データ製品（統合）用アプリケーションの責務範囲 • Azure でのデータ管理と分析のための Adatum Corporation のシナリオ - Cloud Adoption Framework | Microsoft Docs
39. • 共通原則 • 異なるデータを同じフォルダに配置しない • 上位は荒くわける（日付のフォルダを上にもってこない • 以下のように紹介されているものがあるが、各方針を要約し、筆者の考えを取り入れて例を説明します。 • データ ランディング ゾーンごとに 3 つの Azure Data Lake Storage Gen2 アカウントをプロビジョニングする - Cloud Adoption Framework | Microsoft Docs ディレクトリ構成について Raw Enrich Curate Landing
40. • 上位階層 • データ種別/ソース名/テーブル名 ディレクトリ構成例 Landing Landingコンテナ LandingRawストレージ transactional source table table rundate=YYYYMMDD （時間パーティション） コンテナ master- reference telemetry log rundate=YYYYMMDD （時間パーティション） version full • 中位 • /バージョン/連携種別 • バージョン：APIのように維持しなが ら変化する＝耐変更性を確保 • 連携種別：全件/差分連携がフォ ルダからわかるようになる • 下位階層 • 取り込み日付でのパーティションを構 成する • スキャン範囲を常に意識する delta version
41. • 大量データを保持するストレージでは適切なフォルダ、ファイル分割により、W/Rを効率化することが重要 • 単一ファイルに対するRead/Write速度は限界がある。 • 大量の細かいファイル（many tiny files）は余分にプロセスを消費する（一般に100MB～1GB程度で分割が好ましい • プロセスはファイル単位でデータにアクセスする（レコード単位でアクセスされるわけではないイメージ 補足）データレイクのパーティショニング tableA year=2022 month=1 month=2 tableA 2022/01/01,10 2022/01/02,20 ・・・ 2022/01/31,10 2022/02/01,10 2022/02/02,20 ・・・ 2022/02/28,10 2022/01/01,10 2022/01/02,20 ・・・ 2022/12/31,10 適切なパーティション設計 →必要な範囲でアクセスしフィルタ処理不要 パーティションがないと →全範囲アクセスしてからフィルタ処理 例②特定月のデータを取り出すとき スキャン対象 スキャン対象 例①大きなデータを読み書きするとき 適切なパーティション設計 →プロセスが並列で仕事 1GB 1GB 1GB 3GB 大きなファイルor細かすぎるファイル →一つのプロセスに仕事が集中/プロセスが大量回数必要 1KB ・・・ 1KB ・・・ もしくは
42. 補足）ファイル形式について • OLTPシステム向けの従来のフォーマット（csv,avroなど） • データ（ブロック）は1レコードを構成する複数列が格納さ れる • 集計クエリでは特定のカラム集計値もすべてのカラムをリード する必要がある • ストリーム処理などでは行指向のavroが一般的 • 分析システム向けのフォーマット（parquetなど） ※Delta Lake はParquetを採用 • データ（ブロック）は複数行にまたがって一つの列が格納さ れる • 分析クエリでは通常少数の列しか利用しないため、必要な スキャンのみを実施可能 • レコード単位の処理が重要となるシステムでは逆効果 行指向 列指向 参考：https://www.slideshare.net/nttdata-tech/bigdata-storage-layer-software-nttdata 対象列 対象列 対象列 対象列
43. • 一般に圧縮効率はユニークなデータが少ないほど高効率となる • 列指向フォーマットでは列ごとのデータ形式となるため、同じ値が頻出することが 多く（カーディナリティが低い）、データ圧縮の効果が高い=低コスト化に直結 補足） データレイク上でのフォーマット選択の重要性 ID ユーザ名 都市 性別 1 AAA Tokyo 男 2 BBB Osaka 女 3 CCC Nagoya 男 同一のデータが頻出 列のデータ型毎に最適な圧縮技法を利用可能
44. • 上位階層 • データ種別/ソース名/テーブル名 ディレクトリ構成例 Raw • 中位 • /バージョン/連携種別/InOutError • 下位階層 • 取り込み日付でのパーティションを構 成する • スキャン範囲を常に意識する • ファイルフォーマットは管理可能な Delta Lakeなどに変換する Rawコンテナ transactional source table table rundate=YYYYMMDD （時間パーティション） コンテナ master- reference telemetry log rundate=YYYYMMDD （時間パーティション） version full input output error LandingRawストレージ
45. • 上位階層 • データ種別/ソース名/テーブル名 ディレクトリ構成例 Enrich • 中位 • /バージョン/プライバシーレベル • 同テーブルに対してプライバシー要件 に応じた二つに複製される • ①機微データを含む ②機微データを含まない • 下位階層 • クエリに適したパーティションを構成す る • スキャン範囲を常に意識する • クエリ効率に優れたDelta Lakeな どの列指向フォーマットを採用する • Azure でのクラウド規模の分析のデータ プライバシー - Cloud Adoption Framework | Microsoft Docs Enrichコンテナ transactional source table table 読み取りに最適なパー ティション コンテナ master- reference telemetry log 読み取りに最適なパー ティション version general sensitive EnrichCurateストレージ
46. • Input • LandingからDelta Lakeにフォーマット変換し、管理性を向上させる • ただし、すべて文字型でいれるなどして型の適用を行わない • Output • Inputされたデータに対して品質（型、範囲、制約など）を適用する。この時点では何の変換も適用しない • 合格データはEnrichに連携される • Error • 品質の適用時に不合格となったレコードを連携する Rawとの入出力 Input Output Error rundate=YYYYMMDD （時間パーティション） エラー行を振り分け データ品質を適用 Raw Landing 機微含む Enrich 機微含まない 機微削除されたデータ
47. • 上位階層 • データ製品名/テーブル名 • ソースシステムに依存しないため、独自の名 称を名付ける （ 例：sales_analytics） ディレクトリ構成例 Curate • 中位 • /バージョン/プライバシーレベル • 下位階層 • クエリに適したパーティションを構成す る • スキャン範囲を常に意識する • 用途に応じたフォーマットを選択。水 量はParquetもしくはDelta Lake • Azure でのクラウド規模の分析のデータ プライバシー - Cloud Adoption Framework | Microsoft Docs Curateコンテナ データ製品名 table table 読み取りに最適なパー ティション コンテナ 読み取りに最適なパー ティション version general sensitive EnrichCurateストレージ
48. • Azure Data Lake Storage Gen2では、二通りの権限管理方法がある 1. Azure RBACによる制御 1. アカウントキーの利用によるデータアクセス 1. 所有者ロール、共同作成者ロールにはデータに関する操作権限はないが、キーの使用権が付随している。 アカウントキーはアクセス者を特定できずストレージ全体の操作権限をもつため、利用は非推奨 2. データ操作用ロールによるデータアクセス 1. ストレージ Blob データ xx(所有者/共同作成者/閲覧者)は、ストレージ上のデータに関する操作権 限を持つロール 。この方式でのアクセスは誰がアクセスしたかが特定されるため、推奨となるが、 権限制御はコンテナの粒度までとなるため、小規模限定 2. ACLによる制御 • コンテナを含むディレクトリ上で設定し、Azure RBACの閲覧者（リソース表示のため）などと組 み合わせて利用する • ファイル、フォルダレベルでの制御および継承設定も可能のため、推奨 • ただし、ACLの設定数には32の上限があるため、セキュリティグループと組み合わせるなどの工夫が 必須 アクセス制御について • https://docs.microsoft.com/ja-jp/azure/cloud-adoption-framework/scenarios/data-management/best-practices/data-lake-access
49. • Azureサービスからのアクセスとユー ザーからのアクセスを考える。 • Raw/Landing： • Read/Write：Azureサービスのみ • Enrich/Curate ： • Read : Azureサービスおよびユーザー • Write : Azureサービス • Workspace: • Read : Azureサービスおよびユーザー • Write : Azureサービスおよびユーザー 推奨されるアクセス制御 • https://docs.microsoft.com/ja-jp/azure/cloud-adoption- framework/scenarios/data-management/best-practices/data-lake- services#alignment-of-personas-to-write-and-reading-of-data
50. Raw Enrich Curate Azure Synapse and Power BI Analytics solution overview Azure Data Lake Storage Process Ingest Azure Blob Storage Cosmos DB Dataverse Microsoft SQL Event Hubs Pipelines Streaming Operational system Azure Data Landing Analytical sandbox Serve Consume Enrich Azure Machine Learning Azure Cognitive Service Azure Synapse Analytics Power BI Service Azure Stream Analytics Data Explorer Pool Serverless SQL Pool Dedicated SQL Pool Streaming Dataset Dataflow Datamart Dataset Reports Managed Online Endpoint Streaming data Predict Model train and MLOps Self-service Preparation(s) Cache/Query for enterprise data model Streaming Ingest Near real-time Analytics (Warm path) Stream Processing (Hot path) Streaming Ingest Store historical data (Cold path) Data warehousing Lakehouse view Big data Processing Data Integration Upload Extract Prediction with custom ML model Prediction with built-In AI model Deploy custom ML model Model Specific business data Cache/Query No-ETL data integration and HTAP with Synapse Link Visualize Analyze in Excel Extract subjective data /Preparation/Model Excel Application Push Movement Store Spark Pool Experiments ,models
51. Enrich Azure Machine Learning Managed Online Endpoint Deploy custom ML model Raw Enrich Curate Databricks and Power BI Analytics solution overview Azure Data Lake Storage Process Ingest Azure Blob Storage Event Hubs Pipelines (Synapse/Data Factory) Streaming Operational system Landing Analytical sandbox Serve Consume Power BI Service Dataflow Datamart Reports Streaming data Prediction with built-In AI model MLOps Self-service Preparation(s) Cache/Query for enterprise data model Data Integration with auto loader Upload Extract Prediction with custom ML model Prediction with built-In AI model Model Specific business data Cache/Query Visualize Analyze in Excel Extract subjective data /Preparation/Model Excel Push Movement Store Azure ML Integration with mlflow Azure Databricks Data Science /Data Engineering Stream processing with Spark streaming SQL Analytics Lakehouse SQL workload Application Dataset Azure Cognitive Service
52. Azure Databricks を使用した 最新の分析アーキテクチャ • https://docs.microsoft.com/ja-jp/azure/architecture/solution-ideas/articles/azure-databricks-modern-analytics-architecture
53. Azure Synapse を使用した分析のエンド ツー エンド • https://docs.microsoft.com/ja-jp/azure/architecture/example-scenario/dataplate2e/data-platform-end-to-end?tabs=portal