### 主な経験
```
プロダクトの機能開発
フロントエンド（2018/07~2018/09）
セグメントの作成画面の開発
バックエンド（データ基盤）（2018/10~2019/03）
各カスタマーの状態（購買意欲）を追跡するレポート機能の開発
→ 集計の規模が大きかったため限られたリソースの中で集計処理を早く終えるように設計開発する必要があった（定常集計に影響出ないようにするため）。
今のところ集計遅延を起こさずに他のjobと同居できており定常集計が行えている。
```

```
Hadoop集計基盤移行（2019/02~2019/04）
Hadoopクラスタの集計jobを稼働しているもう片方のHadooopクラスタへ移行
移行先サーバ（オンプレサーバ）は集計を停止せずに移行実施（無停止移行）
→ クラスタを2つから1つにする、かつ移行先のクラスタのサーバ台数を増やす予定はなかったため、事前に移行先のクラスタのリソース（各集計jobが使用するリソースと集計が生成するデータのサイズ）を見積り、不要な集計jobの停止を行った。事前にリソースの見積りを行ったため移行後もクラスタを安定的に運用することが出来ている。
```

```
ClouderaのClientサーバ移行（2019/05~2019/08）
Clientサーバとは各エコシステム（HDFS、HBase）へアクセスする踏み台サーバのこと
Clientサーバで動作している集計jobを新Clientサーバへ移行していく
集計は停止せずに移行実施予定（無停止移行）
→ Clientサーバは集計jobを動かしているサーバになるため、無停止移行を行う予定。また新サーバのOSのメジャーバージョンが異なるのと、集計jobを動かすための環境（ライブラリや言語の依存関係）をクリアしなければ集計を動作できないため、現在ローカル上に仮想マシンを立て調査/検証を行っている。
```

### 検索クエリログ
* サービスのページを訪問する際にURLに付与されるクエリパラメータを分解し格納する処理/テーブルの作成

#### 開発する中で行った作業
```
事業部のクエリパラメータの仕様把握
プランナーなどが検索クエリログテーブルをどのように使うのかの把握（ヒアリング）
要件の把握、すり合わせ
使用者が分析しやすいテーブル設計の提案、すり合わせ
実装
エンジニアテスト
プランナーに使い勝手（使用感）を確認
リリース
```

### Github移行
* gitのホスティングサービスとしてオンプレのbitbucketを使用していた
* そのホスティングをgithubへ移行する作業

#### やったこと
```
githubでrepositoryを運用していく中で必要なポリシーをチーム内で決める（議論、合意形成）
策定したポリシーに合わせてrepositoryを修正、移行
今までのチームにおけるプロジェクト運用の仕方が個人単位で行われていたため、可読性も悪いrepositoryになっていたり、保守は殆どされていないが運用されているrepositoryが存在していた
上記のような問題のあるrepositoryの洗い出しと移行方法を考えるのが苦労点
```

### メディア譲渡対応
```
自社サービスを譲渡することに伴い、メディア側のビジネスやエンジニアと連携しながら譲渡作業を進めた
データ基盤側へ様々方法でデータが送られていた
送られているデータソースを1つ1つ洗い出してメディア側と足並みを揃えながら譲渡ができるようにサービスから連携している部分を外していった
```

### 改善業務
#### メディアDB同期高速化（digdag+embulk）
```
同期対象テーブルが多くなってきたため、それに比例して同期完了時刻が遅くなっていた
元のdigdagが逐次実行をしていたのを並列化実行するようにして対応
オンプレのVMで動作していたので動作元のサーバ負荷とデータを投入する先のredshift負荷を上手くバランスを取りながら並列実行の設定を行った
```