求人票からみた各社のデータ基盤

## 経緯
今のプロジェクトでデータを整形して扱いやすくする必要が出てきたため、ETLツールを導入しようと検討していたのですが、調査を兼ねて各社がどんなデータ基盤を構築しているかを求人票から抜き出してみました。
求人票はindeedを使い「データ分析基盤エンジニア」で検索した結果を参考にしています。

ちなみに、今のプロジェクトのデータボリュームと欲しいETLツールの要件は以下です。

データボリューム

- 対象のデータはECサイトのデータ
- 購入テーブルの総件数は100万件、500MB（月6万件増える）
- 一番大きいテーブルはimpressionテーブルの総件数は1億件、25GB

ETLの要件

- エンジニアの数が少ないので運用負荷が低い必要がある
- 処理時間を短くしたいので、データは差分更新したい
- タスクの並列実行ができる
- リトライ、再実行が簡単にできる
- エンジニアの運用工数を低くする為に、データ定義の追加・変更が簡単にできるといい（非エンジニアでもできると最高)


## ソフトバンクテクノロジー

https://career.signate.jp/job_offers/308

```
【必須要件】

- テーブル設計から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への出力も可能だそうです。


## リクルートテクノロジーズ

https://job.careerconnection.jp/job-offer/4156/8374?utm_source=Indeed&utm_medium=listing&utm_campaign=signup&dmai=CCT_Indeed

```
【技術要素】

- Spark／Storm／Prestoなどリアルタイムテクノロジー実装のご経験
- MesosなどApacheトップレベルプロジェクト製品の導入のご経験
- ITIL／EA／TOGAFなどのフレームワークの導入・運用のご経験
- MDM（マスターデータマネジメント）導入・運用のご経験
- R/SAS/SPSSなどの分析ツールのご経験

【望ましい要件】

- DWH製品やHadoopなどビッグデータ処理製品の経験
- Webシステムなどのプログラム開発経験
- システムの企画、営業、プリセールス経験
```

データのバッチ処理にはHadoopとSparkを使用しており、Sparkのクラスタ管理にはYARNではなくMesosを使用しているようです。
リアルタイムにデータを扱うユースケースでは、ストリームデータを並列分散処理できるStormを使っています。
データ取得部分では、SQLライクなクエリで高速にデータを取得できるPrestoを使っているようです。

大規模なデータ処理を高速に、かつ高可用性を意識したデータ基盤を作っている印象です。

## リクルートライフスタイル

https://career.saiyo-dr.jp/rls-ge/Entry/select_job.do?prefId=0&agendaId=0&seminarPageId=0&jobId=164&bunruiId=0&from=job&to=job_view

```
【必須要件】

- ビッグデータ基盤(RedShift、BigQuery、Hadoop等)の経験がある方
- AWS/GCPを用いた環境構築の経験

【歓迎要件】

- dockerなどコンテナを用いた開発経験
- terraform，ansibleなど構成管理ツールの使用経験
```

データストレージにRedshiftも使っているところがリクルートテクノロジーズとの違いです。


## ZOZO
https://tech.zozo.com/recruit/mid-career/detail54/

```
＜利用技術＞
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で管理しているようです。

<!-- 
ユナイテッド

https://jp.indeed.com/viewjob?jk=2e0322489b3f21b4&tk=1dflhfuei0tjk002&from=serp&vjs=3

```
【利用している言語、技術、ツールなど】
プロダクションはAWS上に構築されていますが分析データベースはGCPのBigQuery上に構築されております。
AWSからGCPへの転送はembulkで行われており、分析自体は128GBのメモリを搭載したサーバ上で行われております。
また必要に応じてHadoop, Sparkでデータ処理を行っております。
```
AWS→？？→Hadoop/Spark→embulk→BigQuery

メルペイ

https://www.green-japan.com/job/80356?argument=sRrG93Nh&dmai=indeed_eng-sys_tok&utm_source=Indeed&utm_medium=cpc&utm_campaign=Indeed

```
インフラ： Google Cloud Platform
(Cloud SQL, Datastore, Spanner, Storage, Stackdriver Logging, Dataflow, Pub/Sub, etc.)
分析基盤：BigQuery / Data Studio / MySQL / Looker
```
GCPのサービスを活用いているようです。

リブセンス

https://recruit.livesense.co.jp/job/career_data-engineer/

```
開発環境
Ruby, Python, Scala, node.js, SQL,
Linux (CentOS, Amazon Linux), MySQL, PostgreSQL, Fluentd, Docker, Apache Spark
AWS (Redshift, EC2, S3, ElasticBeanstalk, EMR, Glue, Athena, SQS, Lambda, Kinesis, Route 53),
Ansible, Mackerel, Airflow, Digdag, Embulk, ConcourseCI
```

redshift, Athena, EMR, S3, Kinesis, Digdag, Embulk, airflow, glue, spark, fluentd
-->

## 感想



### データ収集
ログの収集にFluentdを使用している点は共通していました。

FluentdとHadoop/Spark/Stormの間にKafkaを挟み、バッチ処理/ストリーム処理のデータを統一的に扱えるようにしているケースもありました。
Kinesis Data Streamを使うことでKafkaと同様のことをクラウドサービスを使って実現できます。

### データ処理
データを処理する部分ですが、ユースケースの違い（バッチ処理なのかストリーム処理なのか）で選択する技術が変わってきます。

バッチ処理の場合、HadoopやSpark、Embulkを使用している企業が多かったです。
Sparkはデータの共有部分をインメモリで処理する為Hadoopより高速らしいので、これから導入する場合はSparkを使う選択になるのでしょう。
Embulkは並列のデータ転送ツールです。
SparkとEmbulkの使い分け方は分かっていないので、実際に採用する場合は調査が必要です。

クラスタ間に認証が必要な場合はKerberos認証でシングルサインオンを実現する方法をとる例もありました。

またストリーム処理の場合はStormで集計して保存したり、Elasticsearchにデータを保存して解析するケースが多かったです。

<!---
データ保存
データの保存先はHadoopならHDFSにおくことになります。
Bigqueryに保存
-->

## 参考

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