この記事は公開されてから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を利用している
- 検索できるようにしたい
- 変更可能なデータが存在する
- 市場投入にあたってコストよりも時間を優先する
- 最初のソリューションでの挑戦
- 操作しやすい
- パフォーマンスチューニング
- スケールできる
- データを残せる
- コスト
- ライセンス
- (仮想サーバの?)インスタンス数
- ストレージ
- 調整できる
- 操作しやすい
可能性がある方法
- Cassandra + Elasticsearch
- NoSQL solution "X"
- Hive
- Presto
S3ぐらいのコストのデータウェアハウスにしたいが、同等程度のクエリパフォーマンスがほしい
解決方法
- HiveやPrestoからヒントを得た
- 既存のツールを活用する
後述する隠し味を使って連携させる
隠し味：ブルームフィルタを活用する
- Hiveは既にブルームフィルタに対応しており、ORCのブロック単位で利用できる
- ProtectWise社の隠し味として、メタストアをブルームフィルタにしている
検索可能なブルームフィルタ
クエリシステム
- SparkのPAIを活用する
PrunedFilterScan
手順
1. Spark SQLでクエリを分析する
2. メタインデックスがクエリされる
3. 結果のファイル一覧を FileScanRDD でSparkに返す
結果 (概要)
- HiveやPrestoのようなクエリシステムができた
- ブルームフィルタを活用したメタストア
結果 (詳細)
- 以前のエクスプローラと比べて95%の費用を削減した
- クエリ実行で必要となるS3データのダウンロードを最小化した
- パフォーマンス
- 秒単位のクエリ
- キー/値形式の検索は1秒もかからない
- 手軽にスケールアウトできる
- ストレージのスケールアウトは不要
- クエリサーバは負荷に応じて自動でスケールする
Amazon S3
- 安い
- スケーラブル
- ストレージと計算を分離できる
- 何もしないでもストレージがスケールしてくれる
- 計算リソースとは独立してスケールできる
- 信頼性
- 早い
Amazon EMR
必要なときに構築できるSpark環境
- スケーラビリティ
- クラスタ間
- クラスタ内
- 簡単に自動スケールできる
- 用途
- 入力
- 出力
将来のこと
- S3 Selectを活用する
- クエリの実行時間と料金をさらに減らす
- 対応を進めているところ
- Kinesis Data Firehoseを活用する
- 入力データのパイプラインを単純化する
- 操作の複雑性を減らす
- サーバーレス化する
- メタストア
- クエリ処理
- 入力
セッションで学んだこと
- 最初に機能を実現し、コスト最適化は後回しにする
- 自前でのシステム構築とサードパーティ製品を組み合わせると効率化できることがある
- オープンソースのエコシステムはとても良くできている
- AWSを活用すると柔軟にシステムを構築できる
- AWSのロードマップは革新に導いてくれる
S3に構築した高速なデータレイクはシステムの基礎となっている
おわりに
分析用のデータに柔軟性が求められるというのが、まさにその通りだなと感じていて共感することの多いセッションでした。また、データ形式の調整やS3 Selectの活用など試してみたいと思わせる素晴らしいセッションでした。
今後の業務でぜひ挑戦してみたいと思います！
4
