Recommended
More Related Content
What's hot
What's hot (20)
Similar to BigData-JAWS#16 Lake House Architecture
Similar to BigData-JAWS#16 Lake House Architecture (20)
More from Satoru Ishikawa
More from Satoru Ishikawa (11)
BigData-JAWS#16 Lake House Architecture
- 1. Lake House Architecture Pattern 2021/03/01 BigData-JAWS 勉強会#16 データアナリティクス事業本部 ⽯川 覚 1
- 2. 2 ⾃⼰紹介 • ⽒名 - ⽯川 覚 (いしかわ さとる) • 所属 - データアナリティクス事業本部 (DA事業本部) - コンサルティングチーム - 札幌オフィス勤務（最近はリモートワークが多いです） • 略歴 - メーカー系SIer、ITベンチャー企業、現在に⾄る • 担当業務 - データ分析基盤の設計・開発、コンサルティング • 好きなサービス - Amazon Redshift/Athena、Snowflake 、Google BigQuery
- 3. 3 本⽇の流れ • Lake House Architecture • DWHのトレンドの変化 • データ分析サービスの進化 • データ分析基盤に求められる要件 • Lake House Architecture Pattern • 最後に
- 5. 5 Lake House Architecture とは Lake House Architectureは、DWH（Redshift）からデータレイク （S3）や運⽤データベース（PostgreSQLやMySQL）のデータを統合して、 分析することでより速くより深い洞察を得るためのアーキテクチャ Redshift Spectrum • S3データレイクにオープンフォーマットデータを直接クエリする Data Lake Export • S3データレイクにオープンフォーマットデータでエクスポートする • Athena、EMR、Glue（Spark）、SageMakerにデータの連携する Federated Query • AWS環境のPostgreSQLやMySQLに直接クエリする
- 7. 7 最近のクラウドDWHの傾向 「アーキテクチャはデータレイクで、データ構造とデータ管理 機能はDWHと類似したサービス」 • スキーマバリデーション • データはクラウド上のオブジェクトストレージにカラムナファイル フォーマットで格納 • ストレージとコンピューティングが分離 • 動的にコンピューティングリソースを割り当て並列分散処理
- 8. 8 企業BIからセルスサービスBIへアクセス特性の変化 従来 • 企業のIT部⾨がトップダウンでデータ分析を主導 • データエンジニアがネストの深い分析クエリ作成、必要に応じて チューニング 現在 • ビジネスユニットがボトムアップでセルフサービスBI • 業務ドメインを活かし、アドホックな結合や定型的な集計分析、 チューニングレス
- 9. 9 企業BIからセルスサービスBIへアクセス特性の変化 従来 • 企業のIT部⾨がトップダウンでデータ分析を主導 • データエンジニアがネストの深い分析クエリ作成、必要に応じて チューニング 現在 • ビジネスユニットがボトムアップでセルフサービスBI • 業務ドメインを活かし、アドホックな結合や定型的な集計分析、 チューニングレス Redshiftがノードにストレージを持つ強みが活かせず、ス トレージとコンピューティングの分離にニーズがシフト
- 10. 10 Amazon Redshift RA3インスタンスの登場 Amazon Redshift（RA3インスタンス） ホットデータはシェアードナッシ ング、コールドデータは、シェ アードストレージ（S3） 双⽅の⻑所を活かし、ストレージ とコンピューティングを分離した アーキテクチャを採⽤している
- 11. 11 データ分析サービスの進化
- 12. 12 2017年︓データレイク関連サービスの登場 2016/11︓Amazon Athena • サーバレス、完全従量課⾦ 2017/04︓Amazon Redshift Spectrum • Redshiftの拡張機能、従量課⾦ • ローカルのテーブルとデータレイクを結合できる 2017/08︓AWS Glue • メタデータ管理やETLのサービス
- 13. 13 2019年︓RedshiftやData Lakeの進化 2019/01︓AWS Glue Python Shell • Pythonスクリプトの実⾏サービス 2019/03︓Redshift Concurrency Scaling • Redshiftクラスタのオートスケール 2019/08︓Lake Formation • データレイクの管理、ガバナンスの強化 2019/12︓Redshift RA3インスタンス • ストレージとコンピューティングの分離 2019/12︓Redshift Data Lake Export • Redshiftのクエリ結果がデータレイクにエクスポートする機能
- 14. 14 2020年︓Lake House Architrecture 2020/04︓Redshift Frederated Query（RDS/Aurora PostgreSQL） 2020/10︓Lake Formation Cross account database sharing 2020/12︓Athena Frederated Query • Athena経由で様々なデータベースやデータソースにクエリが実⾏できる
- 15. 15 2021年︓Data SharingとData Lakeの進化 2021/??︓Redshift AQUA 2021/??︓Redshift Data Shares 2021/??︓Redshift Frederated Query（RDS/Aurora MySQL） 2021/??︓Lake Formation 3 Features • ACIDトランザクション • ⾏レベルセキュリティ • アクセラレーション 2021/??︓Redshift ML 2021/??︓Athena ML
- 18. 企業BI セルフサービスBI 部⾨ IT部⾨が主導 ビジネスユニットによって推進 重視 定型化、安定稼働 スピード、⾃由、創造性 アクセス特性 決まった曜⽇・時間などにアクセス が集中 アドホック 18 データの共有・アクセス特性 サイロ化したデータを統合して分析 • データのゼロコピーでデータ統合したい • マルチクラウドでデータを共有したい BIツールによる可視化ワークロード • 企業BI︓トップダウンで提供する定形ダッシュボードを多数のユーザーが利⽤ • セルフサービスBI︓ボトムアップでビジネス要件に応じてデータ探索
- 19. 19 ETL・機械学習ワークロード ETLワークロード • CRMデータや基幹システムデータのロード、集計 • DWHからデータレイクへデータ共有 • DWHはただの最新データ置き場と化している 機械学習ワークロード • データをファイルとして取り出すならデータレイクでファイルとして提供 • DBの強みを活かすなら、ML連携機能（RedshiftML、AthenaML）
- 20. 20 Lake House Architecture Pattern
- 22. 22 データのロード Redshift Data API IoT CoreからKinesis Firehose経由でS3にPUT、そのイベントでLambda Function を起動してRedshiftにロードする場合、従来だとJDBCドライバ経由でRedshiftに接 続してデータをロードしていました。Redshift Data APIを⽤いれば、JDBCドライ バ準備不要、Redshiftにインバウンド接続なしでロードできるようになります。 SQLクライアント接続 データマート作成や分析⽤クエリは、従来通りODBC/JDBCドライバや接続クライ アントを⽤いてSQLを実⾏するのが良いでしょう。
- 23. 23 データのアンロード（Data Lake Export） Data Lake Export + SQLによるデータレイクの構築 RedshiftのData Lake Exportを利⽤すると、Glue ETLジョブを使うことなくSQL だけでデータレイクが構築できます。S3に対してパーティションを指定やカラムナ ファイル（Parquet）出⼒も可能です。 データはスライスごとに出⼒されるので、必要に応じてPARALLEL OFF指定するこ とで、パーティション内のファイルを１つのファイルにまとめることが可能です。 さらにRedshift Data APIを⽤いれば、AWSCLIからデータレイクを構築できます。 Concurrency ScalingによるUNLOADのスケーリング RedshiftのUNLOADリクエストは、 Scaling ClusterにオフロードできるのでMain Clusterの負荷を気にせず、データレイクが構築できます。
- 24. 24 Load less ELT(not ETL) ロード不要なELT データソースがデータレイクのテーブルとして参照できるのならデータファイルを ロードすることなく直接、結合・集計してターゲットテーブル（データマート）に CTASやUPSERTできます。ロード時間が不要になり、Redshift Spectrumレイヤに 処理をオフロードでき、ワークフローが簡潔になります。 引⽤︓https://aws.amazon.com/jp/blogs/news/etl-and-elt-design-patterns-for-lake-house-architecture-using-amazon-redshift-part-1/ ※ 従来のロードは、スキーマバリデーションが利⽤できるので、従来どおりCOPYコマンドによる実⾏が良いです。
- 25. 25 Federated Query Redshift Federated Query RedshiftからRDSとAurora PostgreSQL のテーブルに直接アクセスできる機能で す。 Federated Queryは、運⽤データベース （PostgreSQLやMySQL）のデータを統 合して、分析することでより速くより深 い洞察を得るため 今後、RDSとAurora MySQLへの接続も サポートされる予定です。 引⽤︓https://aws.amazon.com/jp/blogs/aws/new-for-amazon-redshift-data-lake-export-and-federated-queries/
- 26. 26 Data Sharing Lake Formation Cross account database sharing データレイクのDBをクロスアカウントアクセスするさせる機能で、別のアカウント がデータレイクのDBをアクセスできるようにする。 Amazon Redshift data sharing（RA3のみ） クラスタ間でデータのコピーや移動することなくデータを共有するサービスで、 Amazon Redshiftクラスタ間でライブデータを素早くデータアクセスが可能になり ます。data sharingはデータへのライブアクセスを提供するため、データが更新さ れてもユーザーは常に最新の⼀貫性のある情報を⾒ることができます。
- 27. 27 Amazon Redshift data sharing Pattern hub-spoke Architecture 中央のETLクラスタ（プロデューサークラスタ）か ら複数のクラスタ（コンシューマークラスタ）と共 有して、読み取りワークロードの分離する構成。 Multi Shere Architecture 複数のクラスタ間で互いにデータを共有する構成。 各クラスターは、⼀部のデータのプロデューサーで もあり他のクラスタのコンシューマーでもある。 引⽤︓https://aws.amazon.com/jp/blogs/big-data/announcing-amazon-redshift-data-sharing-preview/
- 28. 28 Amazon Redshift data sharing Pattern Data Provider Architecture 全てのデータを保持するクラスタと、その⼀部を共 有する複数のクラスタの構成。 Development/Staging/Production Data Share Architecture 開発環境、テスト環境、本番環境の間で、データを共 有する構成。 引⽤︓https://aws.amazon.com/jp/blogs/big-data/announcing-amazon-redshift-data-sharing-preview/
- 29. 29 最後に
- 30. 30 最後に • Lake House Architectureは、DWH（Redshift）からデータレイク （S3）や運⽤データベース（PostgreSQLやMySQL）のデータを統合 して、分析することでより速くより深い洞察を得るためのアーキテク チャ • データレイクといえば、Glue CrawlerやETLジョブと考えがちですが、 Redshift SpectrumとData Lake Exportを⽤いれば、SQLのみで データを加⼯し、Parquet出⼒可能です • 今後、データレイクやRedshiftデータのシェアリングを通じて、さら にライブデータを統合、横断的な分析が可能になります