【レポート】データレイクのつくりかた、つかいかた、そだてかた #AWSSummit

せーのでございます。
本日は2020/09/08-2020/09/09にかけて行われたAWS Summit Onlineからライブセッション「データレイクのつくりかた、つかいかた、そだてかた」をレポートいたします。

スピーカーはアマゾン ウェブ サービス ジャパン株式会社 AWS Glue & Lake Formation Sr. Big Data Architect 関山 宜孝 氏です。

アーカイブ

動画のアーカイブはこちらになります。こちらは2020/09/30までの限定公開となっています。

レポート

データレイクとは何か

• データから大きな価値を産み出したいが実際にデータを収集・保管・分析に行き詰まっている
• 伝統的なやり方には限界がある
• データが増え、DBの数や種類が増えていくと横断分析が必要になる
• 異なるサイロ（場所）にデータを保管し、それを横断するような分析は大変
• 全てのデータを一箇所に集める、というのがデータレイクの考え方

• データレイクにはスケーラブルで可用性が高くセキュアで柔軟なデータストアが欠かせない
• あらゆるフォーマットのデータを一か所に集めてそれを管理する中央のカタログを用意する
• 集める時点では生のデータをそのままそのままの形で格納
• 必要に応じてデータを変換加工して様々な目的に使い分ける
• データを単一のリポジトリに集めて保管することが大切
• 耐障害性が高く可用性も高くスケーラブルかつ低コストで保管できる必要がある
• データをセキュアに扱う
• コンプライアンスや監査の面でも基準を満たしていく
• データストレージと活用層を分離する

データレイクのつくりかた

• データレイクを作るには「収集」「保存」「変換」「分析」の4つのステップが必要になる
• 収集: データの収集元のデータベースやファイル・センサーなどからデータを集める
• 保存: 収集したデータをデータベースのストレージに格納する
• 変換: 保存したデータを分析しやすくするために加工する
• 分析: 変換して準備できたデータを活用分析する
• それぞれのユースケースにあったAWSサービスを組み合わせていく

収集

• 収集のポイントは「対象データの選択」「収集粒度」「収集頻度」の3つ
• どのようなデータソースからどのようなデータを集めるのか
• どのような細かさで集めるのか。例えばWebサイトのアクセスはワンクリックごとなのか
• どの頻度で集めるのか。リアルタイムなのか、5分おきなのか

• ログ関係はCloudwatch Logs、センサーデータはIoT CoreからKinesisを使ってS3に集める
• アプリケーションから出力するファイルはFluentdなどを使う
• SaaSのデータはAppFlowを使う

保存

• 保存はデータ本体とそのデータの意味を扱うメタデータ、2つの観点を考える必要がある
• データ本体に関しては耐久性・可用性・スケーラビリティが高いストレージに格納することが大切
• データレイクでセンシティブなデータ機密データなども扱うのでセキュリティは最重要な観点の一つ
• メタデータに関しては汎用的・柔軟に活用できるようにデータを発見活用しやすくまとめる
• 可能な限り自動的にデータのアップデートに追従できるような仕組み

• データ本体 => S3
• メタデータ => AWS GlueのData Catalog
• S3のライフサイクルを使って、時間が経ったでーたを安いストレージに移す
• Glueを使って実際のデータに対応するテーブル定義を自動的にデータから生成する
• テーブルやカラムには任意のコメントタグを付けられる
• AWSなら Amazon ATHENAやEMR RedShiftなどから利用
• 一般的なデータもHive形式に対応している
• 暗号化にKMS、アクセスコントロールにはLake Formationを使う

変換

• データの加工にはパフォーマンス観点とビジネス観点がある
• パフォーマンス観点
  • 列志向のフォーマットに変換、圧縮をかける
  • サイズの小さいデータをある程度まとめる
  • 年月日などを元にパーティショニングする
  • 古いデータはフィルタリングして小さくする
• ビジネス観点
  • 文字列型のデータを数値型に変える
  • UTCの日付形式を分析にあったタイムゾーンに変換しておく
  • 機密情報や個人情報をマスクする
  • 必要のないデータはカットする

• 規模によってサービスを使い分ける
• 小規模ならLambda、中規模ならGlueのPython Shell、大規模ならGlueのSpark Job
• 特にSpark Jobは分散処理ができ、DPUを変えることでスケーリングするのでおすすめ

分析

• データレイクを作るときのポイントは小さく始めること、段階的に作ること
• 最初からすべてを予見することはとても難しい
• データレイクは最初に全て決めなくても使い方は後から決められる
• スモールプロジェクトをEnd to Endで動かすところから徐々にデータソースやユースケースを拡張していくことが結果としてデータ活用の近道になる

データレイクのつかいかた

• データレイクの活用法にはBI、機械学習、ストリーム分析、バッチ、アドホッククエリなどがある
• BIや可視化にはQuickSightを使うと手軽にダッシュボードができる
• 機械学習は特定の目的に使うAIサービスと汎用的に使うSagemakerがある
• ストリーム処理にはKinesis Data Streamでリアルタイム収集したデータをGlue Stream JobでETL処理し、それを分析処理するかAthenaなどを使ってリアルタイムで報告する

• データレイクを運用するには正常な状態を定義してその状態を維持することが重要
• 正常性の指標としてSLA(Service Level Agreement)のような形で定量的に定義できると良い
• SLAで定義した正常状態から逸脱したものを監視して復旧する
• 正常性をどのように定義するべきか
• 例えばデータの鮮度、信頼性、コストなどで判断する

• データの監視方法は
• 実ユーザーのアクセス記録する判定する方法
• Web システムにおける外形監視のような形でユーザーのアクセスを定期的にシミュレートする方法

データレイクのそだてかた

• データレイクは塩漬けにせずに継続的に進化させることが大切
• 利用状況を分析してユーザーのフィードバックを集める
• データや分析エンジンを増やすことで改善を進める
• ドキュメントの整備や利用ポリシーの整備
• 評価と改善を繰り返しイテレーティブに開発運用していく
• そのためには利用状況を計測することが大事
• 種別ごとの利用状況、組織ごとの利用状況を計測する
• ユーザからアンケートをとりフィードバックを得る

• フィードバックを元に拡張を進める
• 拡張には「データ」「ユースケース」「ルール」の拡張がある

まとめ

昨今のシステム構築のカギとも言える「データ」についてのセッションでした。システムが将来的にどういう方向性に進んでいくかによって、必要なデータも変わっていきます。最初はできるところから小さく初めて、改善を繰り返して拡張していくことが大事なんですね。
私も現在機械学習を扱っていますので、データ活用において大変参考になりました。