AWS などのクラウドサービスは多くのサービスが提供されているので、それを組み合わせるだけで目的のシステムが構築できるかというと、似たようなサービスがあってどちらを使うべきか判断に迷う場面も多く、調査に時間を要すると感じます。今は ETL 処理に何を使ったら良いか調査していますが、AWS の方にも尋ねたりして、AWS では Athena(Presto), Glue Job(Spark), Redshift, あとは EMR などで Hadoop クラスタを構築してその上でジョブを走らせる、など様々な方法があることが分かりました。
大規模データが扱えるマネージドサービスに絞ると Athena か Glue Job となりますが、Athena はあくまでも分析をインタラクティブに行えるサービスで、中小規模の ETL には耐えますが大規模となると厳しいようです。パフォーマンスはともかく、1アカウントあたり同時実行数が20に限定されているので立ち行かなくなる画面も出てくるかと思います。
一方 Glue は「完全マネージド型 ETL」と謳っていることから、大規模データに対する ETL も実用的です。色々なリソース制限はありますが必要に応じて緩和が可能なようです。この比較は裏の中心となるアプリケーションが Presto か Spark か、というところでも納得できます。
ということで先日は Athena について色々調べていましたが、今後は Glue を中心に調査する予定です。Athena はすぐにクエリが書けるし、分析用の環境と ETL でデータ生成する環境が同じになると運用上便利かなと思っていたのですが、用途に適したサービスとして Glue 選び、運用を Glue に寄せた方がスケーラビリティ・コスト面で利が大きそうです。
ただ私の探し方が悪かったのか、Glue の活用事例があまり見つからなかったので AWS の方に教えていただきました。ETL 祭り（すごい名前）というイベントが2018年にあったようで、そちらの資料から。
AWS ETL祭り - AWS Glue活用事例@primeNumber
Glue を使って、現 Hadoop 環境（on EC2）のリプレイスをされています。Lambda Architecture に沿って Glue を実装しているのが簡潔で分かりやすい説明でした。コスト面も Hadoop クラスタを EC2 上に構築している状態からは75%カットと、かなり削減できたとのことです。
以前は Hadoop 専属エンジニアがいて運用・管理していたようなのですが、Glue を使ったアーキテクチャではこの「問題」が解決されたと紹介されています。「Hadoop エンジニアに頼らない開発ができるように」とまとめられています。資料からはスケールアウト性において Hadoop エンジニアの負荷が高そうだったり、リアルタイムデータの活用に着手できていないといった課題が挙げられていて、Hadoop エンジニアは数も少ないでしょうし開発リソースがボトルネックになっていたのかなと見受けられます。それを Glue などのマネージドサービスを利用することで回避したのかと思いました。
Architecting a data lake with Amazon S3, Amazon Kinesis, AWS Glue and Amazon Athena
こちらは Atlassian 社の事例です。Atlassian 社は自社のデータレイクのことを Socrates と呼んでいて、そのアーキテクチャの紹介がされています。ただプレゼンテーション用の資料なので、資料だけだとよく分かりません。Youtube に発表動画も上がっていたので合わせて見ると分かりやすいです：
スライド
動画
雑記
動画が1時間もあるので、私なりに要点をまとめました。飛ばし飛ばしだったり、興味あるところは戻ってじっくりみている箇所もあったりして、包括的ではないのでご了承ください。
発表は2人の登壇者が行なっていて、前半の一人はデータレイクやETL処理の大枠について、後半の一人は Atlassian 社の実際の具体例について説明しています。
前半は DataCatalog についてわりと時間を割いて説明しています。DataCatalog は Hive Metastore の拡張として提供されているメタデータ管理システムです。S3 に溜めたデータをさまさまなサービス（Athena, EMR, Redshift, etc）から利用できますが、中央集権的に管理されている DataCatalog を参照することでデータを扱いやすくしているとのことです。S3, DataCatalog の2つはデータレイク構築に必須で、他のデータ処理サービスは必要に応じて使い分けると説明されています（22ページ目、発表だと13分過ぎ）
後半は具体例です。Atlassian 社が2017年末時点で約2年間運用してきた社内向けのデータレイク Socrates についての紹介で、エンジニアは9名おり、ウィークリーアクティブユーザーで1000人（ユーザ自体は2000人前後）いるということで、かなり多くのユーザが利用しているデータレイクのようです。発表は Ingest, Prepare, Organize, Discover の4つに分け、それぞれの課題が3つずつと、その解決方法を紹介しています。
Ingest のところでは、当初は REST API でデータをデータレイクに入れていた方法から、"Stream Hub" を構築した流れが紹介されています。また、Kinesis を利用したデータ検証(validation) と、最初に入ってきた(landed)データを圧縮、データフォーマット変換する流れを EMR で構築しています。
Prepare の課題の1つにデータエンジニアへの依存が問題として上がっています。テーブル作成、データ作成のスケジューリングなど、アナリストもデータサイエンティストも、その他データを扱う人々が様々なことをデータエンジニアに依存するようになり、次第にボトルネックとなっていきます。
Discover の課題は分かりやすくて、用途に適した可視化ツールが要望されていること、突発的な高負荷クエリでデータ分析が行えなくなること、どのテーブルが信頼できるものかというデータの信頼性を担保したい、という3つです。2つめは Presto クラスタを廃止して Athena へ移行することで、使用していないリソースに対してコストを払う必要がなくなりました。高負荷クエリが他のクエリ実行に影響を及ぼすことも Athena なら無くなるでしょうし、運用負荷も下がったようです。Athena に対しては課題も3つ紹介されていて、"Early Adopter" だったので Presto との比較情報がなかったこと、鍵認証を利用した JDBC 接続しか対応していないこと（すみませんあまり理解していないです、、）、コスト管理が手間であることが挙げられています。
EMR や Presto などを AWS 上でクラスタ構築している状態から、AWS が同等のマネージドサービスを提供した段階で移行を検討し、それを実行しているんだなという印象です。質疑応答の質問は動画だと聞こえないのですが、、受け答えの中では、実際の運用では理想通りではなくてクラスタ平行稼働したりしている、というような答えがあります。
