データチーム一人目の私が今までデータ基盤/活用周りで行ったこと

## はじめに

この記事は[Wano Advent Calendar 2024](https://qiita.com/advent-calendar/2024/wano-group) 16日目の記事になります。

私は2023年2月に一人目のデータ部署（Team Analytics）として[TuneCore Japan](https://www.tunecore.co.jp/)に入社しました。

今回は入社してから今まで行ったデータ基盤や活用周りの事を書きたいと思います。

## 自己紹介

- TuneCore Japanのデータエンジニア/アナリティクスエンジニア
  - 2024年2月入社
  - データ周り全般やってます
      - データ基盤構築運用
      - BIツール(Tableau)のServerメンテナンスと管理
      - Tableauダッシュボード作成とコンテンツ管理
      - アドホックな抽出と分析
- 前職はデータ分析とBIツール([Looker](https://cloud.google.com/looker?hl=ja#analyze-governed-data-deliver-business-insights-and-build-ai-powered-applications))のダッシュボード作成
    - 基盤構築運用まで行うのは初
    - AWS自体はこちらでも経験あり
    - データ基盤構築やマネジメントに関する知識はほぼ無し
    - 統計検定2級 / 統計検定準1級 / 基本情報技術者資格 を持っています


## 今までの流れ

![データ基盤変遷.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/6f2e5a3d-91b1-fe5d-d711-dfa53a6637a4.png)


2023年2月入社当時はデータ活用において所謂初期フェーズであり、まずはデータパイプラインの基盤作成と社内データ理解から取り掛かりました。


そこから約1年半経過し今に至ります。同様のフェーズにある会社や、私と同じく一人でデータ周りを対応している方の参考になれば幸いです。




## やったこと

### データパイプライン構築

#### データアーキテクチャ

入社当初から「Github→CodePipelineでリソースを持ってきて自動化する」程度の事は可能だったので、まずはクエリをGitで管理し、作られたテーブルをTableauで提供する環境を作りました。

この内容については[去年のアドベントカレンダー](https://qiita.com/nijigen_plot/items/10f002a603aec559c9bd)で紹介しています。


業務に関することを調べていくうちに、[dbt](https://www.getdbt.com/)の話をやたら聞くようになり、2024年5月に[dbt-core](https://github.com/dbt-labs/dbt-core)**をStep FunctionsでラップしたAWS Batchで動かす環境を導入**しました。こちらの構成は[dbt Advent Calendar 2024](https://qiita.com/advent-calendar/2024/dbt)で記事を上げています。

dbt-core + athenaの運用環境を1から作れる記事になっていますので、気になる方は是非見てみてください。

https://qiita.com/nijigen_plot/items/83547f961b5db2d44e67

> Step FunctionsでラップしたAWS Batchで動かす

ですが、この構成についてTwitterで勉強会の画像を見たことがあり、「こういう作り方も可能なんだ」と知り作りました。

データセキュリティの方針が、できるだけAWSに集約し他には出さないスタイルなので、パイプラインの構築はAWSのサービスでほとんどを作っています。主に使っているサービスは

- Glue Job
- Glue Crawler
- Athena
- S3
- Lambda
- Batch
- Step Functions

です。

2024年あたりから、各部署ごとにAthenaのテーブルにオリジナルのラベルを付与したい～等の要望が上がるようになってきて、Google Drive/SpreadsheetからS3→Glue JObを伝ってAthenaへテーブルを作る[パイプラインも作成しています](https://qiita.com/nijigen_plot/items/83547f961b5db2d44e67#%E3%81%9D%E3%81%AE%E4%BB%96%E4%BE%BF%E5%88%A9%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88aws%E3%81%A7%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E3%82%82%E3%81%AE)。


また、外部APIのデータを取得する環境も作っています。Analytics AWS側がデータレイクになり、Product AWS側へ権限を許可して送るものもあり、徐々にデータ専用のAWSアカウントになりつつあります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/b43d675d-7db3-8e28-fa9d-b1c9415b23eb.png)


#### データモデリング

入社当初はここに対する知識が皆無でしたので、リファクタリングしつつ適用しています。
現在は[メダリオンアーキテクチャ](https://www.databricks.com/jp/glossary/medallion-architecture)の設計を取り入れつつ[スタースキーマ形式によるディメンショナルモデリング](https://www.databricks.com/jp/blog/2022/06/24/data-warehousing-modeling-techniques-and-their-implementation-on-the-databricks-lakehouse-platform.html)でのデータ提供を目指しています。

![building-data-pipelines-with-delta-lake-120823.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/2fdca378-fe99-1d1c-18af-77f5871c1f4a.png)

![db-241-blog-img-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/a0f6f90d-22c4-b613-8826-75f36978d207.png)


dbtのフォルダ毎の役割構成も[dbt best practice](https://docs.getdbt.com/best-practices)のように整然としていないので、誰が見てもいいように直しておきたいなとは思っています。

#### AWS

Tean Analytics AWSアカウントは現状実質自分だけのアカウントになっているので、コスト管理やリソース管理の為のロール・ポリシー、運用監視のためのCloudWatch Logs周りが特に身に付きました。

タグをつけて「Tableau/データパイプライン/S3/その他」別で料金を見れるようにしています。
内訳はAthenaのスキャン量課金が半分以上を占めているので、細かい原因把握のためにAthenaクエリログもS3に配置しAthenaで見れるようにしています。

![image (19).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/17d09446-13cb-54b0-4cf9-b34198eb27c1.png)

実際のクエリやスキャン量、実行時間等色々見れます。


参考にしたページかどうか曖昧ですが、やり方はほぼ下記のような形です。

https://blog.jicoman.info/2018/09/save-athena-query-history-in-s3-with-lambda/


### Tableau

#### 運用管理

弊社ではデータセキュリティの観点からTableau CloudではなくTableau Serverを使っています。

Tableau ServerはLightsailインスタンスを使っており、そちらのメンテナンスも引き継ぎました。
CloudWatch Logs/Logs Agentによる負荷の監視や機能実行の監視、プロセス構成のチェックやインスタンススペックの変更、不具合時のログチェックや再起動等行っています。

また、Tableauから接続するAWSアカウント先をProduction AWSからAnalyics AWSアカウントに変更しました。
今後データパイプラインをAnalytics AWSアカウントで構築する為です。

その為に

1. Production AWS AthenaテーブルをAnalytics AWS Athenaからクエリできるように設定
1. Production AWS Athenaへ直接接続しているTableau Workbookを全てAnalytics AWSから接続するように置換

する必要がありました。これが[今までの流れの](#今までの流れ)2023年8月~9月に記載している事柄です。

これでTableauからの接続先はAnalytics AWS一本になったわけですが、参照先のAthenaカタログが別れています。

![データ基盤変遷 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/8f82ff2e-a420-1683-729a-0c0c75ffe3c7.png)


Tableauでは、**1つの接続で2つのカタログをJOINさせることができません**。
同じ接続を2つ作ればよいのですが、**Tableau側でJOINが行われるため、パフォーマンスが圧倒的に悪い**です。

![データ基盤変遷 (3).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/72b9b8d2-4655-4950-4861-f151f4d31575.png)



ということで、2024年10月までに

1. Production AWSに配置しているMySQLからダンプされたtsvファイルをdbtでparquetに変換しつつAnalytics AWSへ作成
1. Analytics AWSのProductionテーブルからTableauへ接続しているtsvのテーブルを全てparquetに置換
1. Analytics AWS AthenaのProductionカタログをTableauから読めないように権限設定

を行い、Tableauからは完全にProduction AWSへの接続を絶ちました。



![データ基盤変遷 (4).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/8f2665bb-87a8-ac1e-9477-d037d25bc068.png)

項目でいうとあっさりですが、[Tableauの置換機能](https://help.tableau.com/current/pro/desktop/ja-jp/connect_basic_replace.htm)は並べ替えや色などがリセットされますし、操作順序も意識しないとフィルターが壊れたり、置換しきれてないカラムが残ったりとめちゃくちゃ大変でした。


AWS Athenaへの接続時、接続情報を逐一入力する手間があるため接続情報を[仮想接続](https://help.tableau.com/current/server/ja-jp/dm_vconn_create_conn.htm)機能で持ち、入力を不要にする取り組みを現在進行中です。


これによりできることはYoshitaka Arakawaさんの仮想接続についてが分かりやすいです。

https://www.yarakawa.com/single-post/virtual_connections_1

![f414ff8ee1a5-20220103.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/e207f368-c55f-9db0-5dcc-29d0dbd90fad.png)
![7cf4b5876c80-20220103.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/f835b169-3517-f820-0dfc-18243bef6a47.png)

（画像参照元 : https://zenn.dev/rsugimura/articles/89fa78951d290c#%2310-%E4%BB%AE%E6%83%B3%E6%8E%A5%E7%B6%9A)

未だ細かい不具合があったり、仮想接続で接続したテーブルのメンテナンスのオペレーションが固まり切ってないので、そこが安定してきたら差し替えたいと思います。

また、最近は利活用が進みアカウントの数とWorkbookの数が増えてきているので、アカウントの権限管理やWorkbookの編集履歴を逐一チェックしています。

![Tableau WB編集通知.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/1b0c7bff-1df7-38ec-869c-870bfd834acf.png)


#### 他部署連携

入社当初は自社のProductテーブルの構成やカラムの意味などを自分自身が知るために他部署からの依頼はSQLを書いて結果を渡すことがほとんどでした。
扱うデータの種類も多い為、把握しきるのが大変でした。（今も全部は理解しきってない）

**長期的にKPIとして使いそうな指標の依頼が来た時に、データパイプラインにSQLのコードを書き、テーブルを作りTableauワークブックとして展開を進め**ました。

今ではほとんどの部署が私の作ったTableau Workbookから指標を見ています。

集計済みのデータマートを主に作っていましたが、ある程度私がデータモデリングやパイプラインに対する知見が貯まってきた頃、**ディメンショナルモデリングを意識したテーブル群を作り、Tableau Creatorレベルの人にそのテーブルを紹介**しました。

今まではProduction AWSの正規化されたテーブルを複数JOINして作っていたものが、
少ないテーブルですぐ見れるようになった為、自分自身でWorkbookを作り数字を見れる人が少しずつ増えてきています。

![データ基盤変遷 (5).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/5f6bc388-3954-129b-0ea7-ff0e6cece92d.png)


また、**私がテーブル系の仕様を聞いた時はNotionにメモ**しています。これは開発チームもよく使っているため役に立っています。

私自身が構築しているDWHのテーブル仕様も[dbt docsを書き出しS3に配置、html埋め込みでNotionやTableauで展開](https://qiita.com/nijigen_plot/private/83547f961b5db2d44e67#dbt_batchj2yml)しています。
dbt-docsについては非開発チームである程度データが弄れる方向けなので使っている人は現状少ないですが、先々使うと思っていますので余裕があれば書いています。


最近は[dbt-osmosis](https://github.com/z3z1ma/dbt-osmosis)を駆使して、DevチームがMySQLからデータダンプ時コメント付きでAthenaに書き出すようにお願いしたおかげで、MySQLデータダンプからDWHテーブルまで、Dev Teamが記載したコメントが伝播するようになりました。


また、dbt-osmosisも--catalog-file引数を指定し、そこにdescriptionの情報が入っているcatalog.jsonを指定しても反映されなかったので、PRを出して反映していただきました。本当にありがとうございます。

https://github.com/z3z1ma/dbt-osmosis/pull/182

![データ基盤変遷 (6).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/e3def80d-aa70-08e8-e792-0b5ab482e0d0.png)


Tableau Viewerから「少し弄ってみたい」と興味を持つ方も増えてきているので、今後はそう言った方のフォローアップをしたいなと考えています。

### 勉強

入社して以降行うことがガラッと変わったので、主にデータ基盤やエンジニアリングについての本を読みました。
プログラミングについても、分析でさっとかく用途ではなくシステム設計の為に書く形になったので初歩からお作法について勉強しました。

- [実践的データ基盤への処方箋](https://gihyo.jp/book/2021/978-4-297-12445-8)
- [データマネジメント知識体系(DMBOK)ガイド第二版](https://www.dama-japan.org/)
- [データ分析基盤入門](https://bibliography.data-learning.com/book/intro-to-data-analysis-platform-for-engineer/)
- [AWS認定ソリューションアーキテクト-アソシエイト](https://book.mynavi.jp/ec/products/detail/id=135344)
    - [合格しました](https://qiita.com/nijigen_plot/items/2ac71974e5619252ef9d)
- [プリンシプルオブプログラミング](https://www.shuwasystem.co.jp/book/9784798046143.html)
- [ルールズ・オブ・プログラミング](https://www.oreilly.co.jp/books/9784814400416/)
- [データエンジニアリングの基礎](https://www.oreilly.co.jp/books/9784814400652/)
- [Linuxのしくみ](https://gihyo.jp/book/2022/978-4-297-13148-7)

基本情報技術者試験は取得していますが、ネットワーク周りが特に疎いので、Raspberry Pi 5を使って勉強したりもしました。クラウドだけでは想像しづらいのでこれはタメになりました。

https://qiita.com/nijigen_plot/items/5f5299af6aebc54b42d3

https://qiita.com/nijigen_plot/items/ccd99f72b040d1683500

通勤時間中は[Medium](https://medium.com/)や、業務中分からなかったこと、SNS経由でデータエンジニアの方の記事等見ています。



### 分析

所謂ビッグデータからのEDA→レポーティングや基盤実装は[DMBOK Aiken pyramid](https://www.linkedin.com/pulse/summarizing-dmbok-v2-data-management-part-2-manas-mishra/)で言うところのフェーズ4となっており、現状は片手で数えるくらいしか行っていないです。

![1689930842826.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/635079/26e1ab4d-095a-415b-9be6-f9b9512e811a.png)


必要とされていなければ特にやらないので問題は無いですが、前職の業務はこれに近しいものでしたので、将来的には挑戦してみたい所ではあります。



## やってきた感想

**理想はあれどこんなものなのかな**という感じです。
データ活用フェーズに則り求められているものを実装するのが良いのではないかと思っています。

ネットを見ているとどうしても他社の事例や新しいライブラリの技術検証に目が行きがちですが、そこは知識として貯めておいて、必要があれば作る形のスタンスです。

対応する業務の幅が広いので、**見通し数ヵ月~年で掛かるような実装についてはカレンダーに予定を入れてチマチマやっていくのがベスト**かなと思いました。

タスク切り替えのコストも掛かりそれぞれのタスクについて忘れやすい欠点がありますが、焦らずドキュメントに残していきつつ進めようと思います。

パイプラインについてはどこかのスライドで、「**いきなり中間層を作らず、データマートから作るのが良い**」と見た記憶がありますが、それについては私も同じく思っているのでこれからもそのスタンスで続けようと思います。

ここまで見ていただきありがとうございました。