はじめに

セッション情報

セッション名

スピーカー

概要

データレイクの実装

データの中から価値ある値を見つけ出す

なぜビッグデータのためにAWSを使うか

AWSのデータレイクを定義する

データの処理とクエリ実行

AWSのサービスを使用したデータレイクの実装例

なぜデータレイクにAmazon S3を使用するか

データを階層化してコストを最適化する

各データソースから素早く取り込む

入力を最適化するときの考慮点

Amazon Kinesisからリアルタイムデータを取り込む

データパイプラインの共通設定

データを即座に処理する

Amazon S3 SelectとAmazon Glacier Select

Amazon S3 Selectを使うモチベーション

Amazon S3 Select

Amazon S3 Selectを使ってサーバーレスなMapReduce

Amazon S3 Selectでビッグデータを加速させる

正しいデータ形式を選択する

データレイク構築のおよそ80%の作業がデータの準備

AWS Glue - サーバーレスなデータカタログ/ETL

Amazon Athena - インタラクティブな分析

Amazon Redshift Spectrum

Amazon SageMaker

データレイクの主要な用途

ProtectWise社による利用事例

ProtectWide社の紹介

なぜAWSか

エクスプローラとは

エクスプローラ1.0 (旧バージョン)

可能性がある方法

解決方法

隠し味：ブルームフィルタを活用する

検索可能なブルームフィルタ

クエリシステム

結果 (概要)

結果 (詳細)

- クエリサーバは負荷に応じて自動でスケールする

Amazon S3

Amazon EMR

将来のこと

セッションで学んだこと

おわりに

[レポート] STG204: データレイクの実装について #reinvent

本記事は re:Invent 2018のセッション「Data Lake Implementation: Processing and Querying Data in Place」についてのレポートです。

AWS re:Invent 2018

#AWS

#Hadoop

#Spark

yoshihitoh

2018.11.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

福岡のyoshihitohです。re:Invent 2018のセッション「Data Lake Implementation: Processing and Querying Data in Place」についてレポートします。

セッション情報

セッション名

Data Lake Implementation: Processing and Querying Data in Place

スピーカー

John Mallory - Business Development Manager
Josh Hollander - Director of Platform Engineering, ProtectWise
Gene Stevens - CTO & Co-Founder, ProtectWise

概要

原文の引用です。

Flexibility is key when building and scaling a data lake. The analytics solutions you use in the future will almost certainly be different from the ones you use today, and choosing the right storage architecture gives you the agility to quickly experiment and migrate with the latest analytics solutions. In this session, we explore best practices for building a data lake in Amazon S3 and Amazon Glacier for leveraging an entire array of AWS, open source, and third-party analytics tools. We explore use cases for traditional analytics tools, including Amazon EMR and AWS Glue, as well as query-in-place tools like Amazon Athena, Amazon Redshift Spectrum, Amazon S3 Select, and Amazon Glacier Select.

以下、意訳です。

データレイクを構築・スケールさせる際に柔軟性がとても重要になる
今使っているデータ分析手法は、ほぼ間違いなく将来的に変更が必要になる
正しいストレージ機構を設計すると、迅速に新しい分析手法を体験・移行できるようになる
このセッションではAmazon S3/Amazon S3 Glacierにデータレイクを構築する際のベストラクティスを紹介する
Amazon S3・Amazwon S3 Glacierにデータを配置することで、AWS/オープンソース/サードパーティ製の分析ツールを活用できるようにする

以降がセッション内容です。

データレイクの実装

データの中から価値ある値を見つけ出す

ビジネスのモニタリング
ビジネスインサイト
ビジネスの最適化
新しいビジネスチャンス
ビジネスの変化

なぜビッグデータのためにAWSを使うか

敏捷性
スケーラビリティ
多種多様なサービスを利用できる
低コスト
インサイトの取得が早い
データを簡単に移行できる

AWSのデータレイクを定義する

データレイクはアーキテクチャの1つで、仮想的に容量の制限が無い中央集権型のストレージプラットフォーム。カテゴリ化・加工/処理・分析・不均質なデータを消費することができる。

データレイクの主要な属性

ストレージと計算の文理
データの取り込みと変換が高速
安全なマルチテナント環境
データレイクに対してクエリを実行できる
読み込み時にスキーマを適用できる

データの処理とクエリ実行

ユーザ定義関数 (User-Defined Functions)
- AWS Lambdaで独自実装の関数を適用する
- サーバーを用意せずに実行できる(=サーバーレス)
フルマネージドな処理＆クエリ(Fully Managed Process & Query)
- データカタログ
- 変換
- Amazon S3へのクエリ
- インスタンスの管理不要
  - AWS Glue
  - Amazon Athena
  - Amazon Redshift
  - Amazon SageMaker

AWSのサービスを使用したデータレイクの実装例

様々な入力を中央ストレージに集積し、データを処理・分析する。Amazon S3はアクセスしやすく、またセキュアである

なぜデータレイクにAmazon S3を使用するか

非常に高い耐久性 (Durable)
高可用性 (Availability)
高パフォーマンス (High Performance)
安全に利用できる (Secure)
簡単に利用できる (Easy to use)
スケーラブルで手頃な価格 (Scalable & Affordable)
他のサービスと組み合わせやすい (Integrated)

データを階層化してコストを最適化する

データの利用頻度に応じてストレージを変える。利用頻度の高いものはすぐに使えるようHDFSに、利用頻度の低いものはAmazon S3(Infrequent Access)やAmazon S3 Glacierに保存する。

各データソースから素早く取り込む

Amazon Kinesis Data Firehose
- IoT
- センサーデータ
- クリックストリーム
- ソーシャルメディアのフィード
- ログ
AWS Database Migration Service
- Oracle
- MySQL
- MongoDB
- DB2
- SQL Server
- Amazon RDS
AWS Storage Gateway
- オンプレのERP
- メインフレーム
- 研究設備
- NAS
AWS Snowball Edge
- オフラインのセンサーデータ
- NAS
- オンプレのHadoop
AWS Direct Connect
- オンプレのデータレイク
- エンタープライズデータウェアハウス
- 巨大なデータコレクション

データレイクは多種多様なデータを同時に取り込めないといけない

入力を最適化するときの考慮点

入力用のバケットとデータレイク用のバケットは個別に用意する
- 直接データレイクに投入しない
- 生のデータを残しておく (利用頻度が低い場合はライフサイクルでAmazon S3 Glacierに移す)
小さいファイルが大量にある場合は、できるだけS3に保存する前に集約する
- トランザクションコストを減らす
- 秒間トランザクション数の制限を回避する
ファイルを入力する場合はAWS Storage GatewayかAWS Snowball Edgeを検討する
自動化したデータパイプラインを構築する
- AWS Lambdaを使う

Amazon Kinesisからリアルタイムデータを取り込む

簡単に収集・処理/加工でき、リアルタイムに分析できる

Kinesis Video Streams
- ビデオ用のストリーム
- キャプチャや処理/加工に加えて、分析用にビデオストリームを保存できる
Kinesis Data Streams
- データ用のストリーム
- データ分析用のカスタムアプリケーションを使う
Kinesis Data Firehose
- データストリームをAWSのデータストアにロード(≒保存)する
Kinesis Data Analytics
- データストリームをSQLで分析する

データパイプラインの共通設定

疎結合にすると以下のメリットを享受できる

より良いスケーラビリティ
耐障害性
コスト最適化

データを即座に処理する

以下のサービスを利用する

Amazon Athena
Amazon Redshift Spectrum
Amazon SageMaker
AWS Glue

Amazon S3 SelectとAmazon Glacier Select

SQLでオブジェクトの一部からデータを検索する

Amazon S3 Selectを使うモチベーション

すべてのS3オブジェクトを取得してからアプリケーションでデータを絞り込んでいる
Redshift Spectrumの例
- 利用者は5万回クエリを実行している
- S3から取得したデータの総サイズは6PB(ペタバイト)
- Redshift内で実際に利用しているデータは650TB
- S3から取得したデータのうち、 本当に必要なのは10%だけ

Amazon S3 Select

入力データ
- 形式
  - 文字区切りのテキスト(CSV, TSV)
  - JSON
  - Parquet
  - etc...
- 圧縮
  - GZIP
  - BZIP2
  - etc...
SQL
- 詳細は画像の表を参照
出力
- 文字区切りのテキスト(csv, tsv)

Amazon S3 Selectを使ってサーバーレスなMapReduce

比較結果
- 変更前: 200秒、11.2セント
- 変更後: 95秒、2.8セント
2倍早くなり、コストを5分の1に削減

変更前

# Download and process all keys
for key in src_keys:
    response = s3_client.get_object(Bucket=src_bucket, Key=key)
    contents = response['Body'].read()
    for line in contents.split('\n')[:-1]:
        line_count += 1
        try:
            data = line.split(',')
            srclp = data[0][:8]
            ...

変更後

# Select IP Address and Keys
for key in src_keys:
    response = s3_client.select_object_content
        (Bucket=src_bucket, Key=key, expression= 
         'SELECT SUBSTR(obj._1, 1, 8), obj._2 FROM s3object as obj')
    contents = response['Body'].read()
    for line in contents:
        line_count += 1
        try:
            ...

Amazon S3 Selectでビッグデータを加速させる

EMR5.18.0 から利用可能
この例の場合、CPUコア数を40分の1にしても5倍早く処理が完了した

正しいデータ形式を選択する

常にベストとなるデータ形式は存在しない
- どの形式もトレードオフがある
- CSV・TSV・JSONは簡単に扱えるがあまり効率的でない
  - 生データの保存に使う、圧縮して保存・アーカイブ化など
- カラム指向での圧縮が一般的に好まれる
  - Parquet か ORC
  - 容量が小さくなり、低コスト化できる
  - 効率的にスキャン・クエリ実行できる
- AVROなどの行指向はデータのフルスキャンに向いている
主要な考慮点
- コスト
- パフォーマンス
- サポート
クエリ単位でスキャンした総データ量に応じて料金が発生する
カラム指向の圧縮フォーマットを使用する
- Parquet
- ORC
多種多様なツールと統合しやすくなる

データレイク構築のおよそ80%の作業がデータの準備

AWS Glue - サーバーレスなデータカタログ/ETL

自動でデータを見つけてスキーマを保存する
データは検索可能でETLで利用できる
カスタマイズ可能なコードを生成する
ETLジョブをスケジュール実行できる
サーバーレス

Amazon Athena - インタラクティブな分析

標準SQLを使ってAmazon S3のデータをインタラクティブに分析するためのツール
インフラの構築・管理が不要で、データのロードも不要
複数のデータ形式に対応しており、必要に応じてスキーマを定義できる

Amazon Redshift Spectrum

S3に構築したエクサバイト単位のデータを使ってデータウェアハウスを拡張する - S3上のデータを対象にRedshiftのクエリを利用できる (Redshiftのクエリはエクサバイト単位のデータも扱える) - RedshiftのデータとS3のデータを結合できる - 計算リソースとストレージを個別にスケールさせることができる - 安定したクエリパフォーマンスを発揮し、並列性の制限も無い - 多用なデータ形式に対応している - CSV - ORD - Grok - Avro - Parquet - スキャンしたデータの総量に対してのみ料金が発生する

Amazon SageMaker

MLモデル(機械学習モデル)を入手するための高速かつ簡単なサービス
エンドツーエンドの機械学習プラットフォーム
セットアップ不要
柔軟なモデルトレーニング
- mxnet
- Gluon
- TensorFlow
秒単位で料金が発生する

データレイクの主要な用途

データウェアハウスのモダン化
オンプレ環境のデータレイクを保護する
リアルタイムな分析
ビジネスインテリジェンス・データ探索
AI・機械学習

ProtectWise社による利用事例

ProtectWide社の紹介

クラウド環境で配信する Network Detection & Response(NDR) プラットフォーム
毎日500テラバイトのデータを分析している
秒間トランザクション数が1000万を超える

なぜAWSか

革新を最優先するため
主要な戦略 (原文を引用)
- 市場投入までの時間
- 売上原価の革新を基礎とする
- 革新的なアーキテクチャ
- 継続して学んでいく
- 人間の時間が最も重要
- 産業の前にAWSのロードマップ
自社専用のインフラストラクチャを構築するのはリスクになる

エクスプローラとは

ネットワークのタイムラインにしたがってインタラクティブに検索する(ツール)
- 例) 直近の30日以内で特定のIPアドレスがBitTorrentを使用した際の詳細を確認する
脅威に対処する
- 特定のデバイスが既知のマルウェアのUser-Agentを使ってHTTP通信していないか確認する

エクスプローラ1.0 (旧バージョン)

エクスプローラ開発以前
- Apache Cassandraを使っていた
- キー/値の検索でのみ利用していた
エクスプローラに必要な機能
- 検索
- ソート
- ファセット化
DataStaxのエンタープライズエディションに決めた
- 既にCassandraを利用している
- 検索できるようにしたい
- 変更可能なデータが存在する
- 市場投入にあたってコストよりも時間を優先する
最初のソリューションでの挑戦
- 操作しやすい
  - パフォーマンスチューニング
  - スケールできる
  - データを残せる
- コスト
  - ライセンス
  - (仮想サーバの?)インスタンス数
  - ストレージ
  - 調整できる