はじめに
この記事はWano Advent Calendar 2024 16日目の記事になります。
私は2023年2月に一人目のデータ部署（Team Analytics）としてTuneCore Japanに入社しました。
今回は入社してから今まで行ったデータ基盤や活用周りの事を書きたいと思います。
自己紹介
- TuneCore Japanのデータエンジニア/アナリティクスエンジニア
- 2024年2月入社
- データ周り全般やってます
- データ基盤構築運用
- BIツール(Tableau)のServerメンテナンスと管理
- Tableauダッシュボード作成とコンテンツ管理
- アドホックな抽出と分析
- 前職はデータ分析とBIツール(Looker)のダッシュボード作成
- 基盤構築運用まで行うのは初
- AWS自体はこちらでも経験あり
- データ基盤構築やマネジメントに関する知識はほぼ無し
- 統計検定2級 / 統計検定準1級 / 基本情報技術者資格 を持っています
今までの流れ
2023年2月入社当時はデータ活用において所謂初期フェーズであり、まずはデータパイプラインの基盤作成と社内データ理解から取り掛かりました。
そこから約1年半経過し今に至ります。同様のフェーズにある会社や、私と同じく一人でデータ周りを対応している方の参考になれば幸いです。
やったこと
データパイプライン構築
データアーキテクチャ
入社当初から「Github→CodePipelineでリソースを持ってきて自動化する」程度の事は可能だったので、まずはクエリをGitで管理し、作られたテーブルをTableauで提供する環境を作りました。
この内容については去年のアドベントカレンダーで紹介しています。
業務に関することを調べていくうちに、dbtの話をやたら聞くようになり、2024年5月にdbt-coreをStep FunctionsでラップしたAWS Batchで動かす環境を導入しました。こちらの構成はdbt Advent Calendar 2024で記事を上げています。
dbt-core + athenaの運用環境を1から作れる記事になっていますので、気になる方は是非見てみてください。
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へテーブルを作るパイプラインも作成しています。
また、外部APIのデータを取得する環境も作っています。Analytics AWS側がデータレイクになり、Product AWS側へ権限を許可して送るものもあり、徐々にデータ専用のAWSアカウントになりつつあります。
データモデリング
入社当初はここに対する知識が皆無でしたので、リファクタリングしつつ適用しています。
現在はメダリオンアーキテクチャの設計を取り入れつつスタースキーマ形式によるディメンショナルモデリングでのデータ提供を目指しています。
dbtのフォルダ毎の役割構成もdbt best practiceのように整然としていないので、誰が見てもいいように直しておきたいなとは思っています。
AWS
Tean Analytics AWSアカウントは現状実質自分だけのアカウントになっているので、コスト管理やリソース管理の為のロール・ポリシー、運用監視のためのCloudWatch Logs周りが特に身に付きました。
タグをつけて「Tableau/データパイプライン/S3/その他」別で料金を見れるようにしています。
内訳はAthenaのスキャン量課金が半分以上を占めているので、細かい原因把握のためにAthenaクエリログもS3に配置しAthenaで見れるようにしています。
実際のクエリやスキャン量、実行時間等色々見れます。
参考にしたページかどうか曖昧ですが、やり方はほぼ下記のような形です。
Tableau
運用管理
弊社ではデータセキュリティの観点からTableau CloudではなくTableau Serverを使っています。
Tableau ServerはLightsailインスタンスを使っており、そちらのメンテナンスも引き継ぎました。
CloudWatch Logs/Logs Agentによる負荷の監視や機能実行の監視、プロセス構成のチェックやインスタンススペックの変更、不具合時のログチェックや再起動等行っています。
また、Tableauから接続するAWSアカウント先をProduction AWSからAnalyics AWSアカウントに変更しました。
今後データパイプラインをAnalytics AWSアカウントで構築する為です。
その為に
- Production AWS AthenaテーブルをAnalytics AWS Athenaからクエリできるように設定
- Production AWS Athenaへ直接接続しているTableau Workbookを全てAnalytics AWSから接続するように置換
する必要がありました。これが今までの流れの2023年8月~9月に記載している事柄です。
これでTableauからの接続先はAnalytics AWS一本になったわけですが、参照先のAthenaカタログが別れています。
Tableauでは、1つの接続で2つのカタログをJOINさせることができません。
同じ接続を2つ作ればよいのですが、Tableau側でJOINが行われるため、パフォーマンスが圧倒的に悪いです。
ということで、2024年10月までに
- Production AWSに配置しているMySQLからダンプされたtsvファイルをdbtでparquetに変換しつつAnalytics AWSへ作成
- Analytics AWSのProductionテーブルからTableauへ接続しているtsvのテーブルを全てparquetに置換
- Analytics AWS AthenaのProductionカタログをTableauから読めないように権限設定
を行い、Tableauからは完全にProduction AWSへの接続を絶ちました。
項目でいうとあっさりですが、Tableauの置換機能は並べ替えや色などがリセットされますし、操作順序も意識しないとフィルターが壊れたり、置換しきれてないカラムが残ったりとめちゃくちゃ大変でした。
AWS Athenaへの接続時、接続情報を逐一入力する手間があるため接続情報を仮想接続機能で持ち、入力を不要にする取り組みを現在進行中です。
これによりできることはYoshitaka Arakawaさんの仮想接続についてが分かりやすいです。
（画像参照元 : https://zenn.dev/rsugimura/articles/89fa78951d290c#%2310-%E4%BB%AE%E6%83%B3%E6%8E%A5%E7%B6%9A)
未だ細かい不具合があったり、仮想接続で接続したテーブルのメンテナンスのオペレーションが固まり切ってないので、そこが安定してきたら差し替えたいと思います。
また、最近は利活用が進みアカウントの数とWorkbookの数が増えてきているので、アカウントの権限管理やWorkbookの編集履歴を逐一チェックしています。
他部署連携
入社当初は自社のProductテーブルの構成やカラムの意味などを自分自身が知るために他部署からの依頼はSQLを書いて結果を渡すことがほとんどでした。
扱うデータの種類も多い為、把握しきるのが大変でした。（今も全部は理解しきってない）
長期的にKPIとして使いそうな指標の依頼が来た時に、データパイプラインにSQLのコードを書き、テーブルを作りTableauワークブックとして展開を進めました。
今ではほとんどの部署が私の作ったTableau Workbookから指標を見ています。
集計済みのデータマートを主に作っていましたが、ある程度私がデータモデリングやパイプラインに対する知見が貯まってきた頃、ディメンショナルモデリングを意識したテーブル群を作り、Tableau Creatorレベルの人にそのテーブルを紹介しました。
今まではProduction AWSの正規化されたテーブルを複数JOINして作っていたものが、
少ないテーブルですぐ見れるようになった為、自分自身でWorkbookを作り数字を見れる人が少しずつ増えてきています。
また、私がテーブル系の仕様を聞いた時はNotionにメモしています。これは開発チームもよく使っているため役に立っています。
私自身が構築しているDWHのテーブル仕様もdbt docsを書き出しS3に配置、html埋め込みでNotionやTableauで展開しています。
dbt-docsについては非開発チームである程度データが弄れる方向けなので使っている人は現状少ないですが、先々使うと思っていますので余裕があれば書いています。
最近はdbt-osmosisを駆使して、DevチームがMySQLからデータダンプ時コメント付きでAthenaに書き出すようにお願いしたおかげで、MySQLデータダンプからDWHテーブルまで、Dev Teamが記載したコメントが伝播するようになりました。
また、dbt-osmosisも--catalog-file引数を指定し、そこにdescriptionの情報が入っているcatalog.jsonを指定しても反映されなかったので、PRを出して反映していただきました。本当にありがとうございます。
Tableau Viewerから「少し弄ってみたい」と興味を持つ方も増えてきているので、今後はそう言った方のフォローアップをしたいなと考えています。
勉強
入社して以降行うことがガラッと変わったので、主にデータ基盤やエンジニアリングについての本を読みました。
プログラミングについても、分析でさっとかく用途ではなくシステム設計の為に書く形になったので初歩からお作法について勉強しました。
- 実践的データ基盤への処方箋
- データマネジメント知識体系(DMBOK)ガイド第二版
- データ分析基盤入門
- AWS認定ソリューションアーキテクト-アソシエイト
- プリンシプルオブプログラミング
- ルールズ・オブ・プログラミング
- データエンジニアリングの基礎
- Linuxのしくみ
基本情報技術者試験は取得していますが、ネットワーク周りが特に疎いので、Raspberry Pi 5を使って勉強したりもしました。クラウドだけでは想像しづらいのでこれはタメになりました。
通勤時間中はMediumや、業務中分からなかったこと、SNS経由でデータエンジニアの方の記事等見ています。
分析
所謂ビッグデータからのEDA→レポーティングや基盤実装はDMBOK Aiken pyramidで言うところのフェーズ4となっており、現状は片手で数えるくらいしか行っていないです。
必要とされていなければ特にやらないので問題は無いですが、前職の業務はこれに近しいものでしたので、将来的には挑戦してみたい所ではあります。
やってきた感想
理想はあれどこんなものなのかなという感じです。
データ活用フェーズに則り求められているものを実装するのが良いのではないかと思っています。
ネットを見ているとどうしても他社の事例や新しいライブラリの技術検証に目が行きがちですが、そこは知識として貯めておいて、必要があれば作る形のスタンスです。
対応する業務の幅が広いので、見通し数ヵ月~年で掛かるような実装についてはカレンダーに予定を入れてチマチマやっていくのがベストかなと思いました。
タスク切り替えのコストも掛かりそれぞれのタスクについて忘れやすい欠点がありますが、焦らずドキュメントに残していきつつ進めようと思います。
パイプラインについてはどこかのスライドで、「いきなり中間層を作らず、データマートから作るのが良い」と見た記憶がありますが、それについては私も同じく思っているのでこれからもそのスタンスで続けようと思います。
ここまで見ていただきありがとうございました。