この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS re:Invent 2015においてビッグデータ周りのセッションは数多くありました(私も色々参加しました)が、ビッグデータのワークフローを構成、管理する為のサービスはプラクティスも同様に重要な部分です。
当レポートではそのデータフローを管理するAWSのサービスである『AWS Data Pipeline』をラップしたオープンソースサービス『DataDuct』に関する解説セッションの内容をご紹介してみたいと思います。
当セッションのスライド資料は以下となります。
このセッションで紹介する内容
- Coursera社でのETLを管理するためのAWS Data Pipelineの活用方法について学ぶ
- なぜ、Pipelineを実行するためのOSSフレームワーク:Dataductを作ったのか
- どうやって開発者がDataductを使い、ETLパイプラインを作成出来るようになるか
- パイプライン管理のベストプラクティス
- Dataductをどうやって使いはじめるか
Coursera(コーセラ)
- スタンフォード大学コンピュータサイエンス教授Andrew NgとDaphne Kollerによって創立された教育技術の営利団体。界中の多くの大学と協力し、それらの大学のコースのいくつかを無償でオンライン上に提供している。
- コーセラ - Wikipedia
- 世界中に1500万人の生徒
- 1300の学習コース
- 120のパートナー
- 卒業生は250万人
CourseraでのDWH
Amazon Redshiftを活用している。
- ユーザー数：167人
- 1200テーブル
- システム数：22
- dc1.8xlarge 6ノード
- 3000万のクエリを実行
データフロー
CourseraでのETL
- 150のアクティブなパイプライン
- Dataductの開発者は44人
ETLシステムに求められるもの
- フォールトトレランス(Fault tolerant system：障害発生時の被害を最小限度に抑える能力)
- スケジューリング機能
- 依存管理
- リソース管理
- 監視機能
- 構築が容易である事
Dataductについて
- coursera/dataduct · GitHub
- Creating an ETL — dataduct 0.1.0 documentation
- インストールはpipコマンド一発で可能。
$ pip install dataductDataductを使ったパイプラインの作成1: Amazon RDSからAmazon Redshiftへのデータ移行
- パイプライン定義の作成
- YAMLで定義
- ステップごとに定義
- 設定の共有
- 可視化
- 上書き
- コードの再利用
パイプライン詳解
- extract_rds (RDSの抽出)
- Amazon RDSからデータを取り出し、Amazon S3へ出力
- create-load-redshift (Redshiftのテーブル作成＆データロード)
- Redshiftへのテーブル作成(無かった場合)とデータのCOPY
- upsert
- ステージングテーブルから本番テーブルへのUPDATE及びINSERT
タスク: Bootstrap
- フル自動化
- Amazon EC2/Amaozn EMRの最新のバイナリをAmazon S3から取得
- リソース上で依存関係をインストール＆アップデート
- コード上で最新バージョンのパイプラインが稼働するかを確認
品質保証
- DWH内のプライマリーキー違反
- 削除行：行数比較により確認
- 破損行：行のサンプルセットの比較により確認
- UPSERT処理内で自動的に実施
取り壊し(Teardown)
- タスク失敗時にはAmazon SNSでアラート
- タスク失敗に関するログ出力
- 監視
- 実行時間/リトライ回数/マシンステータス
- 可視化
- Dataductによって自動的に生成され、デバッグが容易に。
設定の共有
- IAM Role
- AMI
- セキュリティグループ
- リトライ回数
- リソースパス
- カスタムな手順
- OSSな手順は複数のパイプライン間で容易に共有可能。
- また、設定を活用して新しい手順を作成する事も出来る。
CLI使用例
dataduct pipeline activate [-h] [-m MODE] [-f] [-t TIME_DELTA] [-b]
pipeline_definitions
[pipeline_definitions...]Dataductを使ったパイプラインの作成2: CassandraからAmazon Redshift
- シェルコマンドアクティビティを活用。
パイプライン詳解
- CassandraからAmazon S3へのバックアップにはPriamを活用
- Netflix/Priam · GitHub
- SSTableの解析とAvroダンプはAegisthusを活用
- Netflix/aegisthus · GitHub
- Aegisthus出力処理のためのScaldingの活用
- twitter/scalding · GitHub
- より多くのパターンを生成する為の基本ステップの拡張
-
カスタムステップ：Aegisthus、Scalding
- EMR設定はデフォルト値を上書き／変換ステップから複数のノードへアウトプット
- BootStrap
- パイプライン定義毎に保存
- Amazon EMRジョブ用に新しいjarを取得
- 同じHadoop/Hiveメタストアのインストールを指定
Data Products
- 我々はウェアハウス内部のデータについて語ってきた。
- 共通パターン
- 依存タスクの待機
- 分割テーブル作成の為にRedshift内部での計算
- より複雑な処理のためのAmazon EMRアクティビティ
- MySQL/Cassandraへのロードバック
- MySQL/Cassandraへのクエリ
- レコメンデーション、ダッシュボード、検索で使用されている
生徒を正しいコンテンツに繋げる
- ユースケース
- レコメンデーションのメール
- コースの発見
- ユーザーの再生・活性化
オススメ
- Co-enrollments(二重登録者)用に分割テーブルを作成するためのAmazon Redshift内部の計算
- モデルトレーニングのためのAmazon EMRジョブ
- Amaon S3にファイルをアップロード
- 予測APIがアップロードされたファイルを使用
- 予測と訓練レイヤー間の連携はモデル定義経由で
データドリブンな文化を作成するために内部ダッシュボードを用意 + ユースケース + 会社のKPI(Key Performance Indicator) + A/Bテストの結果を確認
学び
やるべきポイント
- 監視(実行時間、リトライ回数、デプロイ、クエリ実行時間)
- コードはパイプライン毎にスクリプトを渡すのでは無く、ライブラリの内部に管理しておく
- ステージングのテスト環境は本番環境に似せたもの・同じものにすべき
- ETL作成を民主化(一般化？)するための共有ライブラリ
- リードレプリカとバックアップの活用
べからず集
- 同じコードをスクリプトとして複数のパイプラインに渡す
- バージョン管理されていないパイプライン
- 依存関係を持った小さいパイプラインを使わずに、本当に大きいパイプラインを構築する事(1つの大きいパイプラインファイルは作らない事、の意味でしょうか)
- リソースタイムアウトやロード遅延の事象を捕捉しない事
さいごに
AWS Data PipelineとDataDuctに関する解説セッションのレポートでした。DataDuctについては私自身使った事は無いので是非触ってみたいと思います。ETLは欠かせない作業でありながら、割と煩雑かつ大変な部分でもありますので、DataDuctを使ってこの辺の作業効率を改善させる事が出来ると良さそうですね。以上、サンフランシスコ(明日改めてラスベガスへ移動します)からお送り致しました。
14
