この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
原題
ABD318 - Architecting a data lake with Amazon S3, Amazon Kinesis, AWS Glue and Amazon Athena
概要
Learn how to architect a data lake where different teams within your organization can publish and consume data in a self-service manner. As organizations aim to become more data-driven, data engineering teams have to build architectures that can cater to the needs of diverse users - from developers, to business analysts, to data scientists. Each of these user groups employs different tools, have different data needs and access data in different ways.
組織内のさまざまなチームがセルフサービス方式でデータを公開して使用できるように、データレイクを設計する方法を学びます。組織がデータ駆動型を目指すようになるにつれて、データエンジニアリングチームは、開発者からビジネスアナリスト、データサイエンティストまで、多様なユーザーのニーズに対応できるアーキテクチャを構築する必要があります。これらのユーザー・グループのそれぞれ、さまざまなツールを使用し、異なるデータニーズを持ち、異なる方法でデータにアクセスします。
In this talk, we will dive deep into assembling a data lake using Amazon S3, Amazon Kinesis, Amazon Athena, Amazon EMR, and AWS Glue. The session will feature Mohit Rao, Architect and Integration lead at Atlassian, the maker of products such as JIRA, Confluence, and Stride. First, we will look at a couple of common architectures for building a data lake. Then we will show how Atlassian built a self-service data lake, where any team within the company can publish a dataset to be consumed by a broad set of users.
この講演では、Amazon S3、Amazon Kinesis、Amazon Athena、Amazon EMR、およびAWS Glueを使用してデータレイクを組み立てることに深く関わっていきます。このセッションでは、JIRA、Confluence、Strideなどの製品を製造するAtlassianのアーキテクトとインテグレーションリーダーのMohit Rao氏が出席する予定です。最初に、データレイクを構築するための一般的なアーキテクチャーをいくつか見ていきます。次に、Atlassianがセルフサービスのデータレイクをどのように構築したかを示します。会社内のどのチームでも、幅広いユーザーによって使用されるデータセットを公開できます。
登壇
- Abhishek Sinha - Senior Product Manager, Amazon Web Services
- Rohan Dhupelia - Analytics Platform Manager, Atlassian
セッションレポート
アジェンダ
- データレイクの特徴
- データレイクを構築するための基本的な要素とそれに対応するサービス
- 例1：データレイクを構築して、リアルタイムおよびバッチ・データ処理ニーズを統一する
- 例2：Atlassianセルフサービスデータレイク
データレイクを構築するに至った理由
データはサイロ化した古いRDB、ソーシャルデータやBtoCチャネルからのリアルタイムフィード、伝統的なDWHの統合など、データサイズは飛躍的に成長しています。次に利用者の多様化です。従来のアナリストツールの他に、アプリケーションやツールからの利用、データサイエンティストによる分析・ML、分析データの提供などですが、これらで利用できるデータを用意しなければなりません。最後に様々なデータアクセス手段の提供です。BIツールからの利用、APIアクセス、Jupiter Notebookのようなツールなど、様々なアクセス方法も提供しなければなりません。
データレイクの特徴
- あらゆるデータを収集できる
- どこからでも探索できる
- 柔軟なアクセス手段を提供できる
- 将来的な拡張性
データレイクを構築するための基本的な要素とそれに対応するサービス
- Datasource: 簡略化されたアーキテクチャビュー
- Ingesion Mechanism: 多くの取り込みツールを想定する
- Process: さまざまなデータ処理ツール
- Consume: データを利用する複数の手段・方法の提供
データは決して完璧ではないので、データは完全ではない
- クリーン
- 変換
- 連結する
- より良いフォーマットに変換
- 変換をスケジュールする
- イベント駆動型変換
- コードとして表現された変換
メタデータ
AWS Glue データカタログは、AWSアカウントごとに1つ Amazon Athena、Amazon Redshift Spectrum、EMR＆JDBCソース間でメタデータを共有できます
- いくつかの拡張を追加：
- データ検出のためにメタデータを検索する
- 接続情報 - JDBC URLs、credentials
- ファイルの識別と解析のための Classification
- スキーマが進化し、他のメタデータが更新されるときのテーブルメタデータのバージョン管理
クローラ
- クローラは自動的にデータカタログを構築し、同期させます
- 新しいデータの自動検出、スキーマ定義の抽出
- スキーマの変更とバージョンテーブルの検出
- Amazon S3でHiveスタイルのパーティションを検出する
- 一般的なファイルの形式のための組み込みのclassifiersで、Grok構文を使用するカスタムclassifiers
- アドホックまたはスケジュールで実行、サーバーレスでクローラの実行時にのみ料金が発生する
AWS Glue データカタログ
クローラがファイルを識別して、自動的にテーブル定義をデータカタログに登録します。登録されると以下のようにテーブルとして参照することができます。
テーブル詳細
データカタログに登録されているテーブル定義の詳細は以下のように参照できます。
バージョンコントロール
登録済みテーブルと、新たにクロールしたテーブル定義が異なる場合にスキーマの違いをバージョン管理されます。
自動パーティション認識
カラム名ありパーティションは、パーティションを自動認識します。
構成例
データレイクのための中心的なメタストア
AWS Glue Data Catalogは Amazon Athena、EMR、Redshift spactrum間でメタデータを共有しています。
リアルタイム（入力ストリーム処理）
EMR上の Spark Streaming や Flink、もしくは、Amazon KinesisのストリームデータをS3に保管して、LambdaやGlueでETLしたデータをAmazon Athena、EMR、Redshift spactrumを通じてアプリから利用します。
一度の書き込み、一度のカタログ登録、複数の読み込み、ETLはどこからでも
一度S3にデータを登録すると、AWS Glue Data Catalogにテーブルとして登録され、Amazon Athena、EMR、Redshift spactrum等複数の手段で参照することができます。ETLはどこからでも可能になります。
例1：データレイクを構築して、リアルタイムおよびバッチ・データ処理ニーズを統一する
Sensor/IOT deviceから行毎のデータをストリームデータとして受け取るとします。
- ビジネスに関する質問
- 特定のセンサーで何が起こっているか。
- 毎日の集計（デバイス、非効率、平均温度）
- いくつのセンサーが非効率的であるかをリアルタイムで見る。
- 運用
- スケール
- 高可用性
- 管理オーバーヘッドの削減
- 私が必要なものを支払う
Kinesisにデータを書き込む
センサーデータを Kinesis Firehoseで蓄積して、一定間隔でS3にファイル出力します。AthenaからはS3のファイルに対してクエリを実行します。
Amazon Athena から日次集計をクエリできるようにする
- S3にファイルからスキーマを自動生成するクローラをGlueに作成する または Athenaコンソール/API/JDBC/ODBCドライバにDDLを書く
- データのクエリを開始する
AWS Glue Job
サーバーレス、イベント駆動型の実行。 データはS3に書き出されます。 出力テーブルはAmazon Athenaの中に自動的に作成されます。
入力ストリーム分析のための Kinesis Analytics
入力ストリームをリアルタイムに分析するには、Kinesis AnalyticsのSourceは、既存のKinesis Firehoseを指定します。Kinesis AnalyticsのDestinationは、新規のKinesis Firehoseを指定します。新規のKinesis FirehoseがKinesis Analyticsの分析結果のストリームを受取り、S3に出力する役割を担います。
特徴
- 数十万のデータソースにスケールアップする
- 事実上無限のストレージスケーラビリティ
- リアルタイムおよびバッチ処理レイヤー
- インタラクティブなクエリ
- 高可用性と耐久性
- あなたが使っているものだけを支払う
✗ 管理するサーバーがありません
最後に
最終的なバッチ・リアルタイム分析は以下の構成になります。
なお、CloudFormation template テンプレートが提供されていますので、とても簡単にお試しいただけます。以下の AWS Big Data Blog のエントリーを御覧ください。
例2：Atlassianセルフサービスデータレイク
Atlassianが提供するデータレイクサービスは、主にAmazon S3 と Athenaがバックエンドで利用されています。詳細は以下のリンクを御覧ください。
Building the Atlassian Data Lake
感想
データ分析で必要となる全ての工程を一台のサーバーも使わずに構築しています。このセッションは、サーバーレス・アナリティクスの実践編のような内容です。CloudFormation template テンプレートが提供されているので、実際に環境を構築することでさらに理解が深められるのではないでしょうか。サーバーレス・アナリティクスの設計についてのプラクティスは以下のブログを合わせてお読みください。
5
