経緯
今のプロジェクトでデータを整形して扱いやすくする必要が出てきたため、ETLツールを導入しようと検討していたのですが、調査を兼ねて各社がどんなデータ基盤を構築しているかを求人票から抜き出してみました。
求人票はindeedを使い「データ分析基盤エンジニア」で検索した結果を参考にしています。
ちなみに、今のプロジェクトのデータボリュームと欲しいETLツールの要件は以下です。
データボリューム
- 対象のデータはECサイトのデータ
- 購入テーブルの総件数は100万件、500MB（月6万件増える）
- 一番大きいテーブルはimpressionテーブルの総件数は1億件、25GB
ETLの要件
- エンジニアの数が少ないので運用負荷が低い必要がある
- 処理時間を短くしたいので、データは差分更新したい
- タスクの並列実行ができる
- リトライ、再実行が簡単にできる
- エンジニアの運用工数を低くする為に、データ定義の追加・変更が簡単にできるといい（非エンジニアでもできると最高)
ソフトバンクテクノロジー
【必須要件】
- テーブル設計からSQL開発経験3年以上
- talend、商用ETLツールなどを用いてデータ変換やデータ最適化
作業を行った経験がある方
【歓迎要件】
- データ基盤および関連ミドルウェアの経験
（fluentD, Hadoop/Spark, ElasticSearch, Kafka, etc）
- NoSQLデータベースの経験（SQL, Oracle, MongoDB, Cassandra, etc）
- パブリッククラウドサービスの経験（Azure, AWS）
- アプリケーションの経験（Pyshon, C#, Ruby, etc）
Fluentd→Kafka→Hadoop/Spark→DBという流れでデータが処理されているようです。
Fluentdで収集されたログデータは、分散メッセージフレームワークのKafkaに流された後、分散処理フレームワークのHadoopやSparkで処理されます。
Kafkaを挟むことであらゆる種類のデータを統一的に扱うことができ、バッチ/ストリーム処理のシステムから同じでデータが読み込めるようになるそうです。
ElasticSearchはリアルタイムなログの解析で使用しているのだと思います。
またtalendは無償で使えるETLツールのようです。
GUIでジョブが作れるので非エンジニアでもデータ変換の定義が作れそうでした。
また、出力先に指定できるストレージも多く、BigqueryやRedshift、S3への出力も可能だそうです。
リクルートテクノロジーズ
【技術要素】
- Spark／Storm／Prestoなどリアルタイムテクノロジー実装のご経験
- MesosなどApacheトップレベルプロジェクト製品の導入のご経験
- ITIL／EA／TOGAFなどのフレームワークの導入・運用のご経験
- MDM（マスターデータマネジメント）導入・運用のご経験
- R/SAS/SPSSなどの分析ツールのご経験
【望ましい要件】
- DWH製品やHadoopなどビッグデータ処理製品の経験
- Webシステムなどのプログラム開発経験
- システムの企画、営業、プリセールス経験
データのバッチ処理にはHadoopとSparkを使用しており、Sparkのクラスタ管理にはYARNではなくMesosを使用しているようです。
リアルタイムにデータを扱うユースケースでは、ストリームデータを並列分散処理できるStormを使っています。
データ取得部分では、SQLライクなクエリで高速にデータを取得できるPrestoを使っているようです。
大規模なデータ処理を高速に、かつ高可用性を意識したデータ基盤を作っている印象です。
リクルートライフスタイル
【必須要件】
- ビッグデータ基盤(RedShift、BigQuery、Hadoop等)の経験がある方
- AWS/GCPを用いた環境構築の経験
【歓迎要件】
- dockerなどコンテナを用いた開発経験
- terraform，ansibleなど構成管理ツールの使用経験
データストレージにRedshiftも使っているところがリクルートテクノロジーズとの違いです。
ZOZO
＜利用技術＞
Java / Ruby / AWS / Aurora / Fargate / Lambda / ECR / CloudFormation / OpsWorks / DirectConnect / GCP / BigQuery / PostgreSQL / SQL Server / Netezza / Fluentd / Embulk / Digdag / JBoss EAP / JBoss Data Grid / JBoss Decision Manager / Elasticsearch / LogStash / Chef / CircleCI / Datadog
Fluentd→LogStash→Elasticsearch
Fluentd→??→Embulk→BigqueryやPostgresQL
上記の2つのパターンがあり、ストリーム処理とバッチ処理のユースケースがあるようです。
リアルタイムなデータ解析をElasticsearchで行い、大量データ分析をBigqueryなどで行なっているのだと思います。
また、Embulkのバッチ実行はDigdagで管理しているようです。
感想
データ収集
ログの収集にFluentdを使用している点は共通していました。
FluentdとHadoop/Spark/Stormの間にKafkaを挟み、バッチ処理/ストリーム処理のデータを統一的に扱えるようにしているケースもありました。
Kinesis Data Streamを使うことでKafkaと同様のことをクラウドサービスを使って実現できます。
データ処理
データを処理する部分ですが、ユースケースの違い（バッチ処理なのかストリーム処理なのか）で選択する技術が変わってきます。
バッチ処理の場合、HadoopやSpark、Embulkを使用している企業が多かったです。
Sparkはデータの共有部分をインメモリで処理する為Hadoopより高速らしいので、これから導入する場合はSparkを使う選択になるのでしょう。
Embulkは並列のデータ転送ツールです。
SparkとEmbulkの使い分け方は分かっていないので、実際に採用する場合は調査が必要です。
クラスタ間に認証が必要な場合はKerberos認証でシングルサインオンを実現する方法をとる例もありました。
またストリーム処理の場合はStormで集計して保存したり、Elasticsearchにデータを保存して解析するケースが多かったです。
参考
Apache Kafkaに入門した
https://deeeet.com/writing/2015/09/01/apache-kafka/
ログ収集プラットフォーム開発におけるElasticsearchの運用
https://logmi.jp/tech/articles/286011
Apache Spark で分散処理入門
https://qiita.com/Hiroki11x/items/4f5129094da4c91955bc
Apache Storm Vs Apache Spark [Comparison]
https://www.whizlabs.com/blog/apache-storm-vs-apache-spark/
ストリームデータ分散処理基盤Storm
https://www.slideshare.net/hadoopxnttdata/storm-19536843
ログ分析基盤のアーキテクチャを振り返る
https://qiita.com/behiron/items/fe7168430e68118c1f0c
Kafka/Fluentd/Sparkを用いたデータ分析基盤の運用話
https://speakerdeck.com/kimutansk/sparkwoyong-itadetafen-xi-ji-pan-falseyun-yong-hua
SparkやBigQueryなどを用いたモバイルゲーム分析環境
https://www.slideshare.net/yuichi_komatsu/sparkbigquery