この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どうも！DA部の春田です。
本記事は、AWS re:Invent 2020のセッション動画、「ANT308: How FINRA operates PB-scale analytics on data lakes with Amazon Athena」のレポート記事です。
English version is here.
個人的に長いこと業務でAthenaを使ってますが、ペタバイト級のデータをAthenaで扱っている事例は珍しく感じました。データを配置するS3側をしっかりチューニングしておけば、DWHとしても問題なく運用できるみたいです。
先日、様々なアップデートが詰め込まれたAthena engine 2.0が発表され、最近ついに東京リージョンでもGAとなりました。ビッグデータ分析基盤の選択肢に、コスパの高いAthenaも敵うようになってきましたね。
概要
FINRA社は、米国でビジネスを展開する全てのセキュリティ企業のための自主規制機関であり、自己資本や社債、セキュリティの未来や選択肢の取引を制御している。セキュリティやSLAはFINRAにとって重要であり、規制の要件を満たすために追求している。このセッションではFINRAがどのようにして、1500以上のアナリストとビジネスパートナーが、1日で数TBずつ増加し続けている金融取引データをクエリできるAmazon Athena上のアプリケーションを開発したかをご紹介していきます。Amazon S3ベースのデータレイクと、オープンソーステクノロジー、Amazon Athenaを使って、どのように大規模分析基盤を運用しているのかについてや、パフォーマンスや運用効率・コストを改善するためのテクニックについても解説しています。
スピーカー
- Janak Agarwal
- AWS Speaker
- Alain Menguy
- Systems Director - FINRA
How FINRA operates PB-scale analytics on data lakes with Amazon Athena - AWS re:Invent 2020
内容
- Amazon Athenaの概要
- FINRAとは？FINRAのミッションは？
- アプリケーション要件
- なぜAmazon Athenaにトライしたのか？
- Amazon Athenaを既存のシステムにどう導入したか？
- 今後のAthenaに期待する改善点
- 将来の展望 - ユニバーサル・データアクセス
Amazon Athenaの概要
- Amazon Athena
- S3ベースのデータレイクのための、サーバレスでオープンソース互換のクエリサービス
- Amazon S3のデータに直接クエリ
- インフラ、オペレーション、アプリケーションログの分析
- BIツールを使用して、インタラクティブに分析
- データサイエンティストのためのデータ探索も
- 分析機能をアプリケーションに埋め込むことができる
- サーバレス： インフラの管理が不要
- JDBC・ODBCで接続
- シンプルなコンソールから即座にクエリ実行
- スキャンしたデータ量に対してのみ課金
- 圧縮データに対してクエリすれば、30~90%のコスト削減が可能
- Federated Queryを用いれば、RedshiftやRDSといったデータソースに対してもクエリ可能
- Parquet、Avro、ORCに対応
- データをat restとin transitで暗号化
- AWS Private Linkを使用すれば、IGWが不要に
- 1年半で100以上の機能を追加
- Federated Query
- 機械学習インターフェイス
- Workgroupによるコストコントロール
FINRAとは？FINRAのミッションは？
- ミッション
- セキュリティ市場を規制し、投資家を改ざんやインサイダー取引から守る
- 企業や為替取引からデータを収集している
- ビジネス的なデータの流れ
- データプロバイダーが為替情報を保存し、SFTPやHTTPS経由でFINRAへ転送する
- FINRAは1日あたり10~20TBのデータを受信している
- 仕様や要件を満たしているか、ファイルのバリデーションを行う
- ファイルをデータカタログに登録する
- 1日あたり数千のETLジョブが実行され、分析用の前処理を行う
- アノマリーを検知しアラート出すための、自動検知モデルが実行される
- データレイク・アーキテクチャ
- 全てのデータをAmazon S3に保存し、どの過去データにもアクセスできるようにする
- 自社製のOSSデータカタログ、HERDを開発
- ストレージとコンピュートの分離
- データを保護する
- at restで暗号化
- Amazon S3上のデータに対してAmazon KMS SSEを使用
- Amazon EMRで使用しているephemeralやAmazon EBSのボリュームは、LUKSで暗号化
- in transitで暗号化
- HTTPS、SSL
- S3バージョニング
- 更新や消去される前の古いバージョンのファイルも取っておく
- 他のリージョンやアカウントへバックアップ
- 主要AWSリージョンやアカウント障害に備えて
- Amazon S3 Glacierに保存し、コスト削減
- at restで暗号化
- 技術スタック
- ECS, EC2: Webアプリケーション、SFTPレイヤ
- S3: 全データを保管
- HERD: 全データを登録するFINRA製のデータカタログ
- EMR: HiveやSparkを使ったETL処理、HBaseやPrestoのリアルタイム分析
- Redshift, Athena: データ分析
- Databricks, SageMaker: RやPython、Scalaを用いた機械学習ワークロード
アプリケーション要件
- CATFOLA Viewer
- 注文ライフサイクル組み立てツール（The order lifecycle assembly tool）
- CAT Lifecycle IDか数種のキーで使用可能
- ライフサイクルに関与した全てのイベントを即座に動的に返す
- 1500~2000億レコードを抽出（日次）
- 推定ボリューム10~20TB（日次）
- 保持期間6年
- 最大300兆のレコード
- 最大25PBのAmazon S3ストレージ
- HERD（Hive metastore）の導入
- 1500以上のアナリスト（最大300の同時実行ユーザー）
- リクエスト全体のうち90%が1分（60秒）以内に完了する
なぜAmazon Athenaにトライしたのか？
- Amazon S3上のEMR HBase
- 運用のしやすさ
- 長期稼働するEMRクラスタ
- メンテナンスやアップグレードに多大なエンジニアリング・運用負荷が発生
- 複雑性
- HBaseの内部ノードを暗号化するためのKerberos
- 専門性
- HBaseの知識がある人材を見つけるのが困難
- 価格
- なぜ使ってない分にも払わないといけないのか？
- 運用のしやすさ
- Amazon DynamoDB
- 大規模なパフォーマンスは素晴らしいが、価格が高い
- 25PBを保管するにはストレージコストが高価
- ディザスタリカバリ用にもう一つのリージョンにコピーするとさらに課金発生
- データ抽出に課題： どうやって1日で2500億（20TB）のレコードをロードするのか？
- Amazon Redshift
- Redshift + Spectrum： クエリするためには、Redshiftのクラスタを立ち上げる必要がある
- Amazon Athena
- インフラのプロビジョニング不要
- インフラのお世話より、もっとビジネスのコア的なタスクに時間がさけるようになる
- 自動スケーリング
- ピーク時に追加でビルドする必要がない
- 高可用性、セキュア
- 内部ノードの暗号化、AWS KMSによる暗号化
- 料金
- 1TBのデータスキャンに$5
- インフラのプロビジョニング不要
- Athenaの価格は非常に魅力的
- 実行したクエリに対してのみ支払う vs クラスタを長期化動作させるコスト
- $5でできること：
- 平均10MBのデータスキャンでは、100,000クエリ
- 平均100MBのデータスキャンでは、10,000クエリ
- 平均1GBのデータスキャンでは、1,000クエリ
- FINRAは1パーティションあたり2500億のレコードをロード済みで、合計20TBになっている
- しかし必要なデータを全て抽出するのに、クエリはわずか10MBのデータしかスキャンしていなかった
Amazon Athenaを既存のシステムにどう導入したか？
- FINRAはHive Metastoreを使用した自社のデータカタログ（HERD）を保有しており、テーブル定義やスキーマを保存している
- HERDは、信頼できる唯一の情報源（Single Source of Truth）としている
- Hive metastoreをAthenaに統合することが、アーキテクチャの重要なコンポーネントの一つ
- 完全なサーバレスインテグレーション vs EMRの倹約なソリューション
- Glue CatalogとHERD間にパフォーマンスの差はなかった
- → Athena導入が決定
- 大規模パフォーマンス検証
- ゴール： Athenaで同時100リクエストを90%の割合で処理できることを証明
- 各処理時間は1分以内
- 最大3分のレイテンシ
- テストの流れ
- 2PBのデータをS3にロード
- 1時間のテストと30分の100同時リクエストの検証
- オレンジのグラフ
- 5万以上のクエリを飛ばしたが、観測できた失敗数は17のみ
- 成功率99.9%
- → Athenaは負荷がかかっていても信頼性が高い
- クエリのレスポンスタイム
- 平均17秒
- 95パーセンタイルで32秒、要件をクリアしている
- ゴール： Athenaで同時100リクエストを90%の割合で処理できることを証明
- パフォーマンスチューニングTips
- クエリパフォーマンスは、Amazon S3内のデータがどう整理されているかに強く依存する
- パーティショニング・バケッティング
- よく使われるクエリのフィルタに沿ってパーティション・バケットを選ぶ
- 高パフォーマンスの列志向ストレージ
- Apache ORCを使用して、
- 大きめのstripe sizeでApache ORC fileを使用
- ファイルサイズ
- ファイルサイズを最適（256MB~1GB）にし、S3データの反復（roundtrips）を減らす
- “S3 Pre-partitioning”
- パフォーマンス改善のため、Amazon S3チームと共同
- 運用の準備
- ワークロードをWorkgroupで分割
- データやログをアプリケーションごとに分離する
- 一時データに対してのみGlue Catalogを活用
- 保持期間を定めて削除する
- CloudWatchでモニタリング
- クエリに関するメトリクス、カスタムダッシュボード、リアルタイム通知
- アプリケーションの特定の箇所のモニタリング（Nagios）
- クエリのキュー時間、実行時間、計画時間などをモニタリング
- JDBC・ODBCドライバ
- ワークロードをWorkgroupで分割
今後のAthenaに期待する改善点
- Hiveバケッティングにしかサポートしていない
- Hiveを使ってAthenaのデータセットを作成するのが遅い
- → Sparkで作成したい
- バケット一つに1ファイルの制約を除外したい
- Athenaはファイルの数がバケット数と合っていないテーブルをサポートしていない
- これによってデータが偏る（data skew）
- SQLのクエリ計画がない
- Presto engineをアップグレードして欲しい
- 動的フィルタリングがない
- PIIやPCI改訂機能がない
将来の展望 - ユニバーサル・データアクセス
- Federated queryとAWS Glue
- FINRAのエンタープライズワイドの哲学
- 適切なアクセスコントロールの元、全ての構造化データにアクセスできるようにする
- 一つのSQLベースのインターフェイスから、複数のストレージ（Amazon S3やAmazon RDS）へアクセス
- 中央集権化されたポリシーの元、テーブル、カラム、行単位でのアクセスコントロール
- 複数のストレージプラットフォームをまたいで、フィルタリングや結合
- FINRAのエンタープライズワイドの哲学
AWS re:Invent 2020絶賛開催中！
ぜひ本編のセッション動画もご覧ください！サインアップがまだの方は以下のリンクからどうぞ。
18
