Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Data platformdesign
Similar to Data platformdesign (20)
More from Ryoma Nagata
Recently uploaded
Recently uploaded (9)
Data platformdesign
- 1. 【中級者向け】 データ基盤の機能の考え方 Principle of Data Platform design Microsoft MVP for Data Platform 2021 永田 亮磨 Twitter:@ryomaru0825 Linkedin:ryoma-nagata-0825 Qiita:qiita.com/ryoma-nagata
- 2. 1. はじめに 2. コンポーネントごと解説 参考 • 【オンラインセミナー】無制限の統合型データ分析サービス “Azure Synapse Analytics”導入前に知っておきたい、ビッグデータ アーキテクチャの構成ポイント徹底解説セミナー （少しライト目に同じような話をしています） • 最新のDWH、ETLの技術的背景について"超ざっくり"とまとめる – Qiita • 最強のデータ分析基盤を目指して～汎用的なデータ分析基盤の選定方法の提案～ - Qiita • 分析データ ストアの選択 - Azure Architecture Center | Microsoft Docs AGENDA
- 3. 情報システムの設計は 業務システムのそれと大きく異なる 業務システム 特徴 （≒考慮事項） 情報システム 少 Volume データ量 大 単 Variety システム内で扱うデータ形式 複 短 Velocity 発生から消費まで 長 多 Concurrency 同時アクセス 少 小 Cost 費用 大 ERP CRM MES DataLake DWH いわゆるビッグデータの3V
- 4. • データアーキテクチャがどのような考え方から導き出されるのかの参考に ビッグデータ用の一般的参照アーキテクチャ • ビッグ データ アーキテクチャ - Azure Architecture Center | Microsoft Docs
- 6. データ収集
- 7. • 業務システムに負荷をかけない • 業務システム上で分析クエリを発行→業務処理に影響 • ワークロードに適したサービスは簡単にデプロイできる • ワークロードを一つのシステムで混在させないことが重要 • データのフォーマット、モデルには分析に適したものがある • Parquet:デファクトともいえるOSSフォーマット。圧縮率が高い。ちなみに列圧縮データは 行レベルの扱いは逆に苦手 • 第三正規化 vs 分析モデル（ディメンショナルモデル、フラットワイドテーブル） なぜデータを収集（移動）するのか
- 8. • 受け取る(Push) • データソース→データ基盤の方向でアクセ ス • よくある例 • IoTなどのリアルタイムメッセージ • 同期系サービス • 基盤上にレプリケート • ファイル送信 • よくある確認点 • どれくらいの頻度で送信されますか？ データ収集の考慮事項➀方式 • 取り出す(Pull) • データ基盤→データソースの方向でア クセス • よくある例 • 業務システム、DB • ファイルサーバー • よくある確認点 • どのような取得をすれば差分取得でき ますか？ • 取得していい時間帯はありますか？ ソース データ基盤 ソース データ基盤
- 9. • 品質チェックは早い段階で行う（IoTなどの品質担保の難しいデータでない場合） • 後続の処理に影響が出るものはなるべくデータを受けとったタイミングで確認をしたい。 • フォーマット、列項目（キー項目の欠如） • データオーナーが責任を持つ範囲を明確にできるように設計すべき • 基盤上の処理に責任がない場合、ソース側で確認、対応が必要。 ここで責任範囲があいまいだったり、ソース側にリソースが想定されていないとペンディングする データ収集の考慮事項②責任分界 データ基盤 取得 ソース 蓄積、処理... 品質チェック
- 10. データ蓄積
- 11. • クラウドを前提にした場合、従量課金が基本かつそのコストは安価。 したがって、現時点で必要ないデータが含まれていても生の状態でとっておくことが 一般的 • 生≠そのままのファイル • 生データとはあくまで内容を変えていないデータであり、生のファイルそのままを指すものでは ないと考える。管理、利用しやすい形式であること、コストが増えない圧縮状態であること が重要 • csvではなく、parquet • csvは可読性にすぐれていても、圧縮効率や、クエリ効率はさほど高くない データ蓄積の考慮事項
- 12. 蓄積フォーマットの特性 • OLTPシステム向けの従来のフォーマット（csvなど） • データ（ブロック）は1レコードを構成する複数列が格納さ れる • 集計クエリでは特定のカラム集計値もすべてのカラムをリード する必要がある • DBのインデックスは行を素早く特定するための仕組み • 分析システム向けのフォーマット（parquetなど） • データ（ブロック）は複数行にまたがって一つの列が格納される • 分析クエリでは通常少数の列しか利用しないため、必要なス キャンのみを実施可能 • レコード単位の処理が重要となるシステムでは逆効果 • SQLサーバーの列ストアインデックスはこちらの考え方 行指向 列指向 参考：https://www.slideshare.net/nttdata-tech/bigdata-storage-layer-software-nttdata 対象列 対象列 対象列 対象列
- 13. • 一般に圧縮効率はユニークなデータが少ないほど高効率となる • 列指向フォーマットでは列ごとのデータ形式となるため、同じ値が頻出することが 多く（カーディナリティが低い）、データ圧縮の効果が高い=低コスト化に直結 列指向フォーマットによる圧縮の効率化 ID ユーザ名 都市 性別 1 AAA Tokyo 男 2 BBB Osaka 女 3 CCC Nagoya 男 同一のデータが頻出 列のデータ型毎に最適な圧縮技法を利用可能
- 14. 補足：Synapse Linkで行われている 行→列ストア変換 • Azure Synapse Link for Azure Cosmos DB にはどのような利点があり、いつ使用するか | Microsoft Docs
- 15. スキーマオンライトとスキーマオンリード DWH時代← → データレイク以降 • ユーザによる活用 (分析) シナリオを想定し、 そこからデータ蓄積先の スキーマを設計 • 業務システムからは、 そのシナリオ実現のため にETLで「データ」抽出 • 想定に含まれなかった 「データ」の周辺データは 埋没 Schema-on-Write • 将来のあらゆる分析 要件に対応するために、 すべてのデータを、 可能な限りネイティブ フォーマットのまま蓄積 • 利用時にはじめて スキーマ・データ構造を 定義し、Read を実施 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:20:17 +0000] "GET /item/giftcards/3720 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 ~~~; 利用時にデータ構造を定義 15 ストレージ総保有コスト の低下
- 16. • ファイルに含まれる不正データ1行を修正することは困難（わらの中の針） • 非効率なデータバージョン管理・・・履歴列のような管理用列の更新運用ができない。 解決にはDelta Lakeなどのレイクハウス型ソリューションを取り入れる必要がある DWH→データレイクへの転換で起きた課題 データスワンプ（沼） 生データフォルダ/ ├ 2020-01-01/ ├ 2020-01-02/ │└ data-01.csv ├ 2020-01-03 │└ data-01.csv ・ ・ ・ DataLake ID eventtype data 1click AAA 2click BBB ID eventtype data 2click BBB' 3conversion CCC
- 17. 補足）RDBでのデータバージョン管理 製品キー 製品コード 製品名 開始日 終了日 1A001 まとまるくん 2020-01-01 9999-12-31 2B001 えんぴつ HB 2020-01-01 9999-12-31 既存行は履歴列を更新 製品キー 製品コード 製品名 開始日 終了日 1A001 まとまるくん 2020-01-01 2020-10-31 2B001 えんぴつ HB 2020-01-01 9999-12-31 3A001 まとまるさん 2020-11-01 9999-12-31 • ある時点のデータを取得するための手法
- 18. OSSプロジェクト『Delta Lake』 • Sparkに最適化されたデータレイク用 ソフトウェア • ファイルシステム上で動作しUpdate などのDML実行が可能 • 実態はparquetファイルのため高圧 縮率 • 現在version 1.0.0 • https://delta.io/
- 19. Delta Lake ベネフィット例 - CRUDオペレーション、バージョン管理 • Update、Delete、 Mergeをサポー トし、データの修正・削除Upsertを 実行 • タイムトラベルにより復元可能 • パーティションの利用により高速化が 可能 ID eventType timestamp 1 clck 2020/4/1 23:00 2 clck 2020/4/1 23:01 3 conversion 2020/4/1 23:02 UPDATE events SET eventType = 'click’ WHERE eventType = 'clck' ID eventType data 1 click AAA 2 click BBB 3 conversion CCC ID eventType data 3 conversion ccc' 4 conversion DDD MERGE INTO events USING updates ON events.eventId = updates.eventId WHEN MATCHED THEN UPDATE SET events.data = updates.data WHEN NOT MATCHED THEN INSERT (date, eventId, data) VALUES (date, eventId, data) ID eventType data 1 clck AAA 2 clck BBB 3 conversion ccc' 4 conversion DDD
- 20. データ処理
- 21. • データの処理周期に対応してコールドパス～ホットパスで整理する • コールドパス：バッチ処理の間隔内でたまったデータ（多）を一括処理 • ホットパス：発生したデータ（少）を絶え間なく処理 データ処理の考慮事項➀頻度、量 バッチ処理 (コールドパス) 例：1/d 2h処理 リアルタイム処理 (ホットパス) 例；1m処理 1/1 1/2 1/3 データ発生 表示内容 2時 1/1データ確認可能 処理 0時0分 データ発生 表示内容 処理 0時2分 0時1分 処理 処理 処理 0時3分 0分台データ確認可能 1分台データ確認可能
- 22. Big Dataの一般的なアーキテクチャ （基礎を抑えたえで、Delta アーキテクチャなど、応用を考える） ラムダ/カッパアーキテクチャ • ビッグ データ アーキテクチャ - Azure Architecture Center | Microsoft Docs Lambda アーキテクチャ Kappa アーキテクチャ • Hot（リアルタイム）とCold（バッチ）を分けてリアル タイム分析と時系列分析を両立 • データは両方に供給されて両方で処理される • クエリは両方の長所を利用 • 全てのデータが蓄積されているので再処理が容易 • ビジネスロジックの変更にも対応しやすい • Lambdaよりもシンプル • ただし全てのLambdaの代替にはならない（バッチ分析が完全に ストリーム分析の延長である場合に有効） • 再処理にはストリームログとして再生する必要がある
- 23. DB用ファイルグループ • Fast Track Data Warehouse Reference Guide for SQL Server 2012 | Microsoft Docs • 単一ファイル（＝単一ディスク）でのIOボトルネックは非常に大きく、CPUの仕事量が増えても取り出せるデータ 量がボトルネックの中心となる。SSD1本の最大IOには限界→枚数を増やすことでトータルIOを上げるのが上策 • SQL Server 時代から、複数のndfファイルを分散配置することでIOを向上する構成が存在している （FastTrack DW） データ処理の考慮事項 ②IOの分散 1_ndf 2_ndf 3_ndf 並列R/WによるIO向上
- 24. Disk 現代のDWHのアーキテクチャ • OLTP処理向けの従来のDBMS製品でのスタンダード • ディスク、メモリが複数のCPUに共有される →IOボトルネックなどの背景から、大量処理要件を満たす ことができなくなった CPU CPU CPU Shared Memory Worker Node CPU Memory Disk ・・・ Disk Worker Node CPU Memory Control Node ABC XYZ ・・・ ABC…XYZ SMP (対称型マルチプロセッシング ) MPP (超並列処理) • 超大規模データに対応可能なDWH製品でのスタンダード • ディスク、メモリは各ノードで独立(Shared Nothing)し、複 数のマシンで構成される • データは分配され、それぞれのノードで並列に処理される • Control Nodeがクエリの分配、整合性をチェック Shared Disk型の構造 Shared Nothing型の構造 データ規模増に対応
- 25. STEP1 STEP2 STEP1 STEP2 ディスクから データを読み込み 中間処理はキャッ シュを利用 →自由分析時の 待機時間が低下 Cache Driver Cache Task Cache Task Task • データ量の増大 • 非構造データ対応 • 求められる処理能力 • 言語のハードル • データ探索時のインタラク ティブ処理時のディスクIO の発生 • 機械学習への対応 • Python, SQL での利用が可能 • インメモリ分散処理による高速イン タラクティブ処理 • リアルタイム処理/機械学習に標準 で対応 ビッグデータ処理技術のトレンド変遷 HadoopとSpark
- 26. • 一括処理、大量ロード • バッチ処理回数＜クエリの回数のため,処理時間を夜間などにとり、まとめて処理する（Write Once , Many Read） • 少量データの読み込みではなく、大量データの読み込みが発生する • 後続のデータ提供部では加工ではなくクエリ応答に専念させる 分析システムのETL（ELT）処理の特徴 DataLake ファイル ファイル ファイル 生データ領域 加工データ領域 ファイル ファイル ファイル 貯める 一括処理 加工結果
- 27. • 逆に、ファイルを小さく分割しすぎると、CPUの仕事量が余ってしまうため、非効 率 • 一般に、Sparkなどの分散処理では256MB～1GBがちょうどいいとされている。 • 特にAzure Blob Storage(Data Lake Gen2を含む)は4MB以上のファイルにHTBB という性能向上機能が適用される • High-Throughput with Azure Blob Storage | Azure のブログと更新プログラム | Microsoft Azure • Synapseでは60個のディスクに分散し、列ストアインデックス（100万行単位）で分割 圧縮 • Snowflakeでは16MB前後に分割圧縮 小サイズ多数ファイル？
- 28. Partition 2 （2020-03-01～2020-03-31） • SQLにパーティション列が指定されると必要のないファイルにはアクセスが発生しない • Synapse 専用SQLの場合、60分割されるため、列ストアインデックスが断片化する100万行未満の領域が生 まれないようにする（＝月次パーティションを切る場合、6000万件/月があって有効活用できる） 補足）パーティションプルーニング SQL SELECT SUM(Quantity) FROM Sales WHERE date between ‘2020-02-01’ and ‘2020-02-28’ ID date YYYYMM 12020-02-01 202002 22020-02-02 202002 ・・・・・・ ・・・ 1012020-03-01 202003 1022020-03-02 202003 Partition 1 （2020-02-01～2020-02-28） ID 1 2 Quantity 11 23 date 2020-02-01 2020-02-02 ID 101 102 Quantity 10 20 date 2020-03-01 2020-03-02 列ストア インデックス 列ストア インデックス 列ストア インデックス 列ストア インデックス 列ストア インデックス 列ストア インデックス
- 29. • 生データ→加工済みデータの概念を拡張 • ステージ毎のデータの役割明確化による、ガバナンスへの好影響 • 利用者に必要なデータがステージとして整理されている＝責任、関心の分離 • ステージを遡れば、新たな知見を得るための元情報にアクセスできる 効果的なデータ処理ステージ メダリオンアーキテクチャ • Delta LakeとLakehouseプラットフォームによるデータウェアハウス設計 - every Engineering Blog 生データ （Bronze） データマート的特化データ （Gold） 利用可能な クレンジング済み データ （Silver） 最発明を防ぐ 共通データ加工 分析シナリオごとの データ加工
- 30. Bronzeでは差分連携(Upsert,Merge)が中心となり、履歴管理される Silver～Goldでは従来のETLと同様、一括処理（一括＝全データ～特定期間）を する＝ロジックを変更すれば全てのデータが置き換えられる データステージとETLの粒度 • Delta LakeとLakehouseプラットフォームによるデータウェアハウス設計 - every Engineering Blog 生データ （Bronze） データマート的特化データ （Gold） 利用可能な クレンジング済み データ （Silver） 最発明を防ぐ 共通データ加工 分析シナリオごとの データ加工 差分連携で履歴管理 一括処理
- 31. データ提供と利活用
- 32. • それぞれの層にアクセスする主要人物、頻度を想定する • ワークロード（利用ユーザ数、利用データ量、利用ツール）の想定が重要 • DWH(RDB)に誰もがアクセスする必要が本当にあるか？本当に性能が必要なのはどこなのか？ データ提供の考慮事項 アクセスパス Data Lake DWH セマンティック モデル、ダッシュボードのUpload データエンジニア • データパイプラインの開発 分析エンジニア • モデル、ダッシュボードの開発 • BI用データ準備 アナリスト • 対話型分析、 ダッシュボードの洞察 データサイエンティスト • データレイク上のデータ準備、 MLモデル作成 ユーザ数：少～中() データ量：中～大 ツール：SSBIツール（前処理寄り） 、SQLクライアント ユーザ数：多（全社に存在） データ量：少～中 ツール：SSBIツール（可視化寄り） 、スプレッドシート ユーザ数：少（ML人材） データ量：中～大 ツール：Python、R、統計解析ツール ユーザ数：少 データ量：特大 ツール： Spark、ETLツール、 クラウド開発ツール 分析データストア
- 33. BIへのデータ提供の基本 インポート デ ー タ 統 合 インポート 直接クエリ Semantic Layer DataLake & Data Warehouse Data Sources デ ー タ 準 備 BI Reporting Data Marts インメモリエンジン ダッシュボード 探索、発見 データ統合システム BIシステム BIシステムはSQLアクセスを基本としているために、 Data Warehouseを通すことが一般的
- 34. 利活用のためのセルフサービスデータ準備の重要性 34 • 取得できたデータで自身の業務を分析するためにはさらにデータ準備（Prep） が必要 • データ準備は分析内容と密接にむずびつくため、業務知識が必要不可欠 • 業務部門ユーザはBIツールに含まれる準備機能を活かすことが重要となる インポート デ ー タ 統 合 インポート 直接クエリ Semantic Layer Data Sources デ ー タ 準 備 ｃ Data Marts インメモリエンジン BI Reporting ダッシュボード 探索、発見 Data Lake & Data Warehouse
- 36. 「セマンティック層」の役割 36 • 整合性、一貫性の確保 • ビジネスロジック、リレーション、データモデルの公式化、共通化 • 共通モデルを利用することによる結果の保証 • 作業者によって計算結果が異なる、再発明などの問題を防ぐ • 追加のセキュリティ層としての役割 • DWHに直接アクセスさせないデータ提供 • 同レポートをユーザごとに見せる範囲を変えたいなど • ユーザーの利便性向上 • BIで扱うデータの列名を、物理名からビジネス上の名称へ変更 • インメモリエンジンにインポートする場合、OLAP操作（ダイシング、スライシング）の性能向上 Semantic Layer 分析、KPI測定用モデル Data Warehouse 未加工orディメンショナルモデル テーブル群 BI Reporting ダッシュボード 探索、発見 Fact Dimension Fact Fact F_sales Dimension Dimension D_product 売上 地域 顧客 製品 カテゴリ モデルの意味付け 利用 利用 利用 インポート/直接クエリによる データ準備
- 37. インメモリエンジンと直接クエリの併用 インポート デ ー タ 統 合 インポート 直接クエリ Semantic Layer Data Sources デ ー タ 準 備 BI Reporting Data Marts インメモリエンジン ダッシュボード 探索、発見 データ統合システム BIシステム • セマンティック層に配置された分析モデルはインポート(定期取得)/直接クエリ(都度取得)どちらか の方法でデータを取得する • ユーザは類似のデータを必要とすることが多いため、インメモリエンジンへの事前キャッシュが非 常に有効 • セマンティック層に位置づく分析用データベース製品の多くは、リレーションが張られたデー タをメモリ上に圧縮して保持（Tableau ServerやMicrostrategyなども同様）。 AzureはPaaS（Analysis Services）およびSaaS（Power BI）として分析用データベースを提供 • キャッシュしきれないorするべきでないデータはDWHに保持したまま直接クエリで都度取得する 分 析 モ デ ル キャッシュ済みデータ による高速応答 キャッシュ外データは 必要な時にクエリ Data Lake & Data Warehouse
- 38. • Power BI には、２種に大別可能なストレージモードがある • データをキャッシュする（Import） • データをキャッシュしない（Direct Query） • それぞれの特性を知るうえで下図の①、②、③の待機時間とデータの保持場所を考える Power BI Import / Direct Query データソース データセット レポート ユーザー Power BI ①データソース～データセット間 ②データセット～レポート間 ③レポート～ユーザ間 改めてPower BI データセットのストレージモードについて整理する - Qiita
- 39. • 操作時の待機時間が短く、最も推奨となる • データの保持場所はデータセット内 • データの鮮度は①のスケジュール次第（最大48回/day） • メモリへのキャッシュとなるため、サイズに上限がある インポートモード データソース データセット レポート ユーザー Power BI キャッシュ ①データソース～データセット間 頻度：定期 利用時の待機時間：なし 操作 クエリ（DAX） ②データセット～レポート間 頻度：随時（操作時） 利用時の待機時間：低 ③レポート～ユーザ間 頻度：随時（操作時） 利用時の待機時間： Power BI サービス→ユーザとクラウドの距離に依存 Power BI Desktop →低
- 40. • 操作時の待機時間が最も長く、機能にもいくつかの制限があ • データの保持場所はデータセット内 • 常にデータソースの最新の状態を取得できる • データを持たないため、サイズの上限なし Direct Queryモード データソース データセット レポート ユーザー Power BI クエリ（SQL） ①データソース～データセット間 頻度：随時（操作時） 利用時の待機時間：長 DB性能・データソースとの距離に依存 操作 クエリ（DAX） ②データセット～レポート間 頻度：随時（操作時） 利用時の待機時間：低 ③レポート～ユーザ間 頻度：随時（操作時） 利用時の待機時間： Power BI サービス→中 ユーザとクラウドの距離に依存 Power BI Desktop →低
- 41. • サーバーレスなクエリエンジンがあると、物理的なDWHを構成しなくてもデータの利用が可能。 • データレイクで統合されたデータに対するViewを論理的なDWH（レイクハウス）として扱うことができる 論理的なDWH,物理的なDWH 専用 ストレージ データレイク テーブル テーブル ファイル ファイル データレイク ファイル ファイル クエリ発行口 （URL） ＋ エンジン クエリ発行口 （URL） ＋ エンジン BI,SQL BI,SQL 論理DWH 物理DWH • 専用ストレージを利用した高 速クエリ • データコピー不要なクエリ as a Service型のデー タ提供 テーブル テーブル 仮想テーブル View ロード 都度 アクセス
- 42. • Delta Lake上はDeltaLakeで管理しMLに対応 • BIからのアクセスであるSQLを実行するエンジンとして、DWH層を設置※論理DWHであれば超低コスト DWH,Datalakeの統合 リレーショナル データベース ファイル メッセージ csv txt json parquet Landing 揮発性の生データ Bronze 蓄積用の構造化生データ Silver(クレンジング) クエリ可能 Gold (データマート相当) parquet parquet parquet parquet parquet parquet データソース データレイク層 DWH層（SQL層） セマンティック層 分 析 モ デ ル インポート 直接クエリ インメモリエンジン インポート 直接クエリ 物理DWH 論理DWH
- 43. • Delta Lake×論理DWHが万能のように見えるが、あくまでストレージベースなので、反応性（レイテンシ）はRDBには一歩譲る状況。 （夜間にBIにインポートするなど場合により十分なケースもある • 反応性が必要なのかどうかや、各所でコストも含めてインポートor直接クエリ方式化を検討する DWH,Datalakeの統合 リレーショナル データベース ファイル メッセージ csv txt json parquet Landing 揮発性の生データ Bronze 蓄積用の構造化生データ Silver(クレンジング) クエリ可能 Gold (データマート相当) parquet parquet parquet parquet parquet parquet データソース データレイク層 DWH層（SQL層） セマンティック層 分 析 モ デ ル インポート 直接クエリ インメモリエンジン インポート 直接クエリ 物理DWH 論理DWH BIアクセス可能領域 にするために インポートして 物理DWH化 or 直接クエリにより 論理DWH化
- 45. • Sparkベースのため、SQL,非SQLから同じ宛先（テーブル）に対してアクセス可能 • テーブル情報（ファイル場所などのメタデータ）は共通のメタデータAPIで管理されている • 従来では、非SQLからのアクセスはテーブル名ではなく、ファイル場所を知っていなければならなかった Delta Lake ベネフィット③ - SQL,非SQLからの透過的なアクセス • Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics (databricks.com) データレイク BI データサイエンス 機械学習 レポート ETL メタデータ、キャッシュ、および インデックス作成レイヤ OSSのデータフォーマット（Parquet トランザクション ガバナンス、バージョン管理、 補助データ構造 メタデータApi Dataframe API SQL API
- 46. データ管理＆発見
- 48. ハイブリッドな仕組みを運用するために データガバナンス統合 • データ消費者（データエンジニア、アナリスト、データサイエンティスト）が 効果的にデータを活用するために、メタデータを利用 • 発見：データソースがどこから来て、どこにあるのか • 理解：どのような使い方なのか、業務特有の用語とシステムの用語の関連性 データガバナンス データ活用 データ統合基盤 データソース システム データ準備 データ統合 データスチュアード、データセキュリティ管理者： ・データエンジニア、アナリスト、データサイエンティストのデータ利用をケア ・企業のデータを保全 スキャン 情報取得 スキャン スキャン 情報取得
- 49. • Synapse Studio、Data Factory Portalから、Purviewにアクセスし、 これから作業を行うデータの情報を検索、利用可能 Purview × Synapse(ADF) 統合
- 50. Azure Data Platform 工程別サービスマップ Azure Purview • 社内データ資産を見つけ出すための データカタログ • データの出自や、加工遍歴を確認 Mapping Dataflow Power Query Online • コードファースト、ローコード（GUI）両方 に対応したデータ統合/データ準備 • 様々なデータソースに対応可能な豊富な アダプタ • 最高クラスの エンタープライズDWH • クエリ課金の柔軟な 論理DWH 専用 SQL Pool サーバレス SQL Pool Power BI データセットハブ • ビジネスユーザ向け データセットカタログ • エンタープライズ～ セルフサービスBI に対応可能なBI データフロー • SaaS形式 セルフサービス データプレパレーション ｖ Azure Machine Learning • AIの民主化を実現する 自動機械学習 • 学習データの変動検出 Azure Synapse Analytics Spark T-SQL Azure Data Factory
- 51. ありがとうございました。