この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Summit Day2 始まりましたね。天気予報とは裏腹に晴天に恵まれている中皆様はいかがお過ごしでしょうか。
私は Day2のセッション「【初級】AWSで構築するデータレイク基盤概要とアーキテクチャ例のご紹介」を受講したのでレポートを書いていきます。
セッション概要
企業内外で発生する大量のデータを管理するためのデータレイクとは何か。そして、データレイクをどのように構築するか。
登壇者
丹羽 勝久 様
データレイクとは
企業では想像する以上のデータを抱えており、あるリサーチ会社のデータによると、データの量は5年で10倍以上に増えるが、データの保管期間は15年と比較的長い。
そんな大量のデータを保管するための基盤としてデータレイクが存在する。
データレイクは通常のデータストアと下記の点で大きく異なる。
- システムからの生データのコピー、レポート、可視化、分析、機械学習などで利用するために変換したデータを保管するシングルデータストア
- 構造データ、半構造データ(csv, json...)、非構造データ(Eメール、PDF...)、バイナリデータを保管可能
オンプレミスと比較したクラウドのデータウェアハウスのメリット
- 膨大な初期コスト、年間維持コストが不要
- ストレージなどの拡張性が高い
2つの推論方法
今まで大量のデータを扱う話をしており、大量のデータを分析するにはデータウェアハウスが一般的である。
しかしデータウェアハウスのみを使用するより、データレイクと組み合わせる方がより良いアーキテクチャになる。
その理由を理解するために、まずは2つの推論方法を理解する。
- 演繹法: 一般論やルールに観察事項を加えて必然的な結論を導く思考方法
ex) 「人間はいつか死ぬ」 -> 「ソクラテスは人間である」 -> 「ソクラテスはいつか死ぬ(結論)」 -
帰納法: 多くの観察軸おから類似点をまとめ上げることで結論を出す思考方法
ex) 「人であるソクラテスは死んだ」、「人であるプラトンは死んだ」、「人であるアリストテレスは死んだ」 -> 「したがって人はいつか死ぬ(結論)」
演繹法(ボトムアップ)
必要なデータを元に分析を初めていく手法である。このような順序でビッグデータを分析していく。
- 分析の要件、目的を明確化
- データモデリング
- ETL(データ収集、変換、ロード)
- 分析の実行
帰納法(ボトムダウン)
データをまずは集めてデータのパターン化をし、分析をしていく。機械学習や高度な統計に関してはこのような手法で行われる。 このような順序でビッグデータを解析していく。
- 関連データの収集
- データの観察とパターン化
- 分析に対する仮説立て
- 分析
- 分析の可視化
ビックデータ分析基盤
データレイクとデータウェアハウスを用いて分析用のアーキテクチャを構築する必要がある。
データレイク基盤としてS3やGlue、データウェアハウスとしてRedshiftなどのAWSサービスを活用することでフルマネージドなビックデータ分析基盤を作り上げられる。
データレイクとしてのS3
S3はデータレイクとしてAWSサービスの中でもっとも適している。
- フルマネージドで管理コストが低い
- 実質的に容量制限がない 拡張が容易
- 大容量でも安価なコスト
- イレブンナインを誇る耐久性
- IAM、バケットポリシーを使用してセキュリティを一貫して細かく設定できる
- ストレージクラスが6つありストレージの用途に応じて柔軟に変更できる
AWS Glue
- データレイクのデータカタログ(データの構造(列、型…)、アクセス方法を定義して他機能からの検索を可能にするもの)とETL処理をおこなう
- Athena、RedshiftなどのAWSサービスとのシームレスな連携が可能
- Hiveメタストア互換の形式でデータが管理されている
- クローラ機能でデータカタログへのデータ自動登録が可能(Hiveパーティションを認識する)
- クラスタを自動で構成して自動でスケールしてくれるフルマネージドサービス
Amazon Redshift
- フルマネージドのクラウド型データウェアハウスサービス
- 最大2PBまで拡張可能
- PostgreSQLとの互換性がある
- MPPで列指向DBエンジンによる高速なSQL処理が可能
- 従量課金制で、オンプレミスと比べた時に1/10のコストにすることが可能
Redshift Spectrum
- Redshiftが拡張されてS3上に置いたファイルを外部デーブルとして直接参照して分析処理が可能
- Redshift内のDBの内部デーブルト組み合わせてクエリ可能
- 多様なフォーマット(csv, tsv, parquet…)に対応
データレイクとデータウェアハウスの連携
- データレイクにデータを投入する
- データの構造化を行い、DWHに投入する
- データウェアハウスでの古くなったが保存したいデータをデータレイクに再度移動してアーカイブする
ビッグデータの処理
AWS上ではAthenaやEMRといったサービスが活用される
Amazon EMR
Hadoop/Sparkなどの大規模分散処理環境のマネージドサービス。簡単にクラスタの構築が可能。
S3との連携が可能で、EMRFSを使用すると、S3をHDFSのように扱うことが可能になる。
そのことで下記のようなことが実現できる
* 計算ノードとストレージの分離
* クラスタのシャットダウン
* 複数クラスタ間でのデータ共有
* データの耐久性の向上
Amazon Athena
- S3に保存した半構造ファイル(csv, tsv)をSQLを用いて分析できる
- フルマネージドなので管理が不要
- 自動で並列クエリをするのでクエリが早い
- クエリの結果をコンソールに出力したり、S3に対してストリーミングすることが可能
- 他の分析ツールとの連携も容易
ラムダアーキテクチャ
データレイクでは、IoTデバイスや、Webサイトからの高速なストリームデータを扱うのにも長けている。
そのような高速データ処理を実装するためのデザインパターンの1つがラムダアーキテクチャ。
Nathan Marz氏が2012年に提唱している。
データを複数のレイヤに分けて処理を実施する。
- Speed Layer: リアルタイムにデータを処理して結果を提供するレイヤ
- batch Layer: 全データの制度の高い集計を担当するレイヤ
Lambadに沿ったデータレイクの実装例
AWSサービスでラムダアーキテクチャのレイヤを実施することが可能
- speed Layer: Kinesis StreamやAnalyticsを利用することで実現が可能。リアルタイムデータを即時に活用できる(速報値の表示や警告通知など)。
- batch Layer: Kinesis Firehoseでデータを受け取りS3にデータを保管する。その後にGlueを使ってデータカタログの作成などで実現できる。
データレイクの事例
出荷倉庫で日々集まるデータを収集し、分析する基盤をAWS上でAmazon.comが構築している。
データレイクがなかった頃は50PBのデータを600,000分析ジョブを用いて分析していた。
しかしそれ以上の量のデータを分析し、分析事項も増やしたかったためS3にデータレイクを作成し、Redshift、Spectrum、EMRを用いたソリューションを構築した。
付加価値としてコストが1/2に減った。
AWS Lake Formation
プレビュー中のサービスなのでリリース時にサービス内容などが変更する可能性があります。
今までのデータレイクの構築には数ヶ月要していた。Lake Formationを用いることで数日でセキュアなデータレイクを構築することができる。
なので機能としてはデータレイクの構築と、Glueで実現していた機能の構築がLake Formationの機能となる。
そして今までS3で権限設定をしていたのが下記のようにシンプルに設定できるようになる。
- Lake Formationのコンソール上でのとシンプルな権限のGrant/Revokeによるアクセス制限
- バケットレベルのみならず、テーブル、カラムレベルでの権限設定が可能
- 全てのデータアクセスの設定がLake Formation上で可能
さいごに
データレイクといえばS3みたいなことは耳に挟んだことはありましたが、なぜS3が良いのかや、周辺のサービスを知るきっかけとなりよかったです。
0
