[レポート] ARC302 – Architecting a Serverless Data Lake（サーバーレスデータレイクの設計） #reinvent

こんにちは。池田です。本記事は現地時間2018/11/26-30で行われた re:Invent 2018 のセッション ARC302 - Architecting a Serverless Data Lake（サーバーレスデータレイクの設計）のレポートです。

概要

In this workshop, learn how to create a serverless data lake architecture. Understand how to ingest data at scale from multiple data sources, how to transform the data, and how to catalog it to make it available for querying using a variety of tools. Also, learn how to set up governance and data quality controls. All attendees must bring their own laptop (Windows, macOS, and Linux are all supported). Tablets are not appropriate. We recommend having the current version of Chrome or Firefox installed. Also, participants must have their own AWS account and administrator permission for AWS services within their accounts.

資料

セッション資料は以下に公開されています。

登壇者

Amardeep Chudda - Solutions Architecture, Amazon Web Services
Mike Gillespie - Solutions Architect, Amazon Web Services

Agenda

• Development Environment Setup
• Review Data Lake Architecture
• Why Serverless?
• Glue Extract Transform Load (ETL)
• Data Governance
• Bonus Content

Scenario

残念ながら現地で参加したわけではないのですが、re:Invent で行われるワークショップはどういうものなのか知りたかったので読み進めてみたいと思います。

workshop summary

• Ingest data from various data sources and join them together
  • シナリオにある「Data Sources include weblogs, NoSQL databases and other datasources」ですね。
• Enrich raw data
  • 後々目的に適した利用が可能になるよう生データで残しておきたい。ということでしょうか。
• Convert data to parquet for efficient querying
  • 「parquet」は翻訳すると「寄せ木細工」となりますが、ここでは「efficient querying」とのことですから Amazon Athena のカラムナフォーマット Parquet を指しています。

Amazon Athena: カラムナフォーマット『Parquet』でクエリを試してみた #reinvent

• Grant access to roles based on the data classification
  • ecommerce website で顧客の購買活動を分析しているわけですから、分析に必要な情報のみにアクセス可能であることが望ましいですよね。
• SQL Access for Data Scientists
  • こちらも分析を行う上で必要となりますので、適切な権限での利用環境を整えるべきです。
• Data Visualization with charts and graphs
  • 「goal of helping business teams」ですから、視覚化は専門部署ではないビジネスチームのメンバーと分析結果を共有するために大切な要素だと思います。

Architecture overview

セッション資料では実際に環境を構築して色々と操作をしたようですが、トラブルシュートなど相談できるメンターが近くに居ないことから今回は見送ることにします（休み明けたら石川センパイに教えてもらおうかな...）。

High-level architecture として全体像が紹介されています。
続いて、今回利用されている AWS の各サービスについておさらいしていきます。

Amazon Kinesis Data Firehose

• Serverless, easy to use
• Seamless integration with AWS data stores
• Support for serverless transformation
• Near real-time ingestion
• Pay only for what you use

Amazon Kinesis Data Firehose は、ストリーミングデータをデータストアや分析ツールに確実にロードする最も簡単な方法です。
Amazon Kinesis Data Firehose

ほぼリアルタイムにストリーミングデータの分析が行えるフルマネージドサービスです。ベストプラクティスが解説されたセッションレポートがありますのでご紹介します。

[レポート]ANT322 – 「Amazon Kinesisによるハイパフォーマンスデータストリーミング: ベストプラクティス」 #reinvent

Amazon Simple Storage Service (Amazon S3)

• Object store
• Highly durable
• Limitless scalability
• Pay for what you use
• Comprehensive security & compliance capabilities
• Support for query in place

Amazon Simple Storage Service (Amazon S3) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。
Amazon Simple Storage Service (Amazon S3)

99.999999999%の耐久性を誇る堅牢なストレージサービスです。S3 を利用する上で非常に大切なセキュリティの確保について解説されたセッションレポートをご紹介します。

[レポート]STG303:Deep Dive on Amazon S3 セキュリティーとマネージメント #reinvent

AWS Glue

• Serverless ETL
• Universal Data Catalog
• Open source Apache Spark environment
• DynamicFrame – Built in functions
• Seamless integration with AWS services
• Support for on-premises data stores

AWS Glue は抽出、変換、ロード (ETL) を行う完全マネージド型のサービスで、お客様の分析用データの準備とロードを簡単にします。
AWS Glue

外部からデータの抽出（ Extract ）、データの変換や加工（ Transform ）、最終的なデータを分析を行うデータウェアハウスなどへ渡す（ Load ）を行う仕組みで、ETL と表します。
関連するメタデータが AWS Glue データカタログに保存されるとすぐに活用できる仕組みです。データレイクを効率的に行うためのデザインパターンに関するセッションのレポートがありますのでご紹介します。

[レポート] ANT316 : 効率的なデータレイク: データレイクデザインパターン #reinvent

Amazon Athena

• Serverless interactive query service
• Integrated with AWS Glue Data Catalog
• Open source, built on Presto, query with standard SQL
• Pay per query
• Support for standard formats like CSV, JSON, ORC, Avro and Parquet
• Fast parallel query execution

Amazon Athena はインタラクティブなクエリサービスで、Amazon S3 内のデータを標準 SQL を使用して簡単に分析できます。
Amazon Athena

Amazon S3 内のデータを直接、簡単に分析できるサーバーレスなクエリサービスです。Athena に限った内容ではありませんが、データレイク全般におけるセキュリティに関するベストプラクティスをまとめたセッションレポートをご紹介します。

[レポート] ANT327 : AWSにおけるセキュアなデータレイクのベストプラクティス #reinvent

Amazon QuickSight

• Serverless, end to end BI solution
• Built-in SPICE engine
• Smart visualizations
• Seamless integration with AWS services
• On-premises database support
• Pay only for what you use
• Multiple device support
• Share and collaborate

Amazon QuickSight は高速なクラウド対応の BI サービスです。
Amazon QuickSight

BI（ビジネス・インテリジェンス）サービスとは、企業が持つデータをビジネスに活用できるよう分析する仕組みです。AWS CLI による API 操作でユーザー管理を行なった記事がありますのでご紹介します。

Amazon QuickSightがAPI操作できるようになりました #reinvent

Data governance

顧客に関する様々なデータを収集、分析するのですから当然その安全な管理についても考慮する必要があります。ここからはそれらについて整理されています。

Data classification and security

• Grant S3 access by role to bucket / prefix
  • データは S3 へ格納しますからそれらへのアクセスは対象バケットやプレフィックスに対し IAM Role によって適切に定める必要があります
• Approaches to segment data
  • 部分的なデータについてもその扱いやアクセス権を考慮しておくことは大切です　　
• Multiple copies of the data in different buckets　　
  • 保管データを他の S3 バケットへ複製する行為も慎重に検討した上で許可する対象を決定する必要があります
• Tokenization, join to tokenized tables, and views to resolve them
  • （この表現に対する日本語表現がわかりませんでした...）

Duplication

この図ではデータを採集したバケットから二種類のバケットへデータが生成された結果を表しています。Secure Bucket にある SSN （米国の社会保障番号）が Tier 1 Bucket にはありません。スライドには詳細な解説がありませんが、どのような状態を表しているのかを次ページに記載されている内容から考察してみたいと思います。

• No access to unauthorized data
  • まずは Data classification and security の項で触れているアクセス制限によって、重要なデータが含まれる Secure Bucket への不正なアクセスはできない状態となっていることが推測できます
• Efficient for queries
  • 元々、保存するデータは Parquet のために変換されていることを示しているものと思います
• Inefficient for storage
  • このようなデータの保管方法は非効率であるということを表現しているのかと思います
• Use tables in glue data catalog
  • AWS Glue データカタログのテーブルを利用する必要があるということでしょうか
• Object tagging / bucket & prefix
  • バケットとプレフィックスをタグで管理する必要があるということを示しているのかと思います

Tokenization

今度はバケットに保存されている内容が異なり、SSN がトークンを用いることで個人の情報と分離され Secure Bucket には SSN と個人を紐づけるトークンのみが保管されています。これも Duplication と同様、次ページに記載されている内容から考察してみたいと思います。

• No access to unauthorized data
  • この場合も、重要なデータが含まれる Secure Bucket への不正なアクセスはできない状態となっていることが推測できます　　
• Efficient for storage　　
  • ストレージに対するデータ保管方法としては効率的になったということと思います
• Less effcient queries as join is required
  • トークンによって個人の情報と SNS 番号が分離されているためこれを結合する必要があり、クエリの視点では効率が悪いということと思います
• Use views in data catalog to simplify data access
  • Glue Data Catalog のビューを利用することでデータアクセスが簡素化されることを示しているものと思います

Redshift Spectrum

最後は Duplication での例と同じ内容の Secure Bucket が生成されているだけです。状況を以下に整理して考察してみます。

• Redshift Spectrum が Secure Bucket へアクセスする構成になっている
  • 分析作業担当者がオブジェクトへ直接アクセスする必要もなくなっている
  • Redshift Spectrum を操作する作業者へは Amazon Redshift IAM Authentication による許可を与えている
  • Redshift Spectrum には Amazon Redshift IAM Role による Secure Bucket へのアクセスを許可している
  • Redshift Spectrum が直接バケットのデータに対してクエリを実行する
• S3 バケットは一つになっている
  • バケットの管理はシンプルになり、データ保管方法としても効率的である

Amazon Redshift Spectrum を紹介したAmazon Web Services ブログはこちらです。

つまり、今回のワークショップでは Redshift Spectrum によるクエリ実行が可能となる仕組みを構築することが、適切なゴールであると設定されていたのだと考えます。たしかに、他に例示されていた方法と比較すると、担当者が直接バケット内の重要な情報にアクセスしたり、複雑なクエリ操作を行なったり、データの保管に関する手間が少なく、セキュアな仕組みに落ち着いたと思います。

おわりに

ワークショップセッションの雰囲気と一緒に、担当している業務では縁のないデータ分析について、まだ自信はないですが今までよりは理解を深めた気がしています。冬休みということもあって腰を据えて実験をする時間の確保が難しいこともあって実際の操作は行いませんでしたが、このワークショップの内容で発生するコストも考慮した上でやってみたいと考えています。英語力に自信がなくても、実際に操作をしながらアドバイスをもらえるのだから、思い切ってこのようなワークショップに参加してみるのもアリなのかな。と思ってきました。