この記事はdatatech-jp Advent Calendar 2021(https://qiita.com/advent-calendar/2021/datatech-jp )の15日目の記事となります。
初めての方ははじめまして。showyouと申します。フリーランスから大企業に出戻りしまして、社内のデータ活用推進を行っています。
ここからこの1～2年間行ってた仕事の話を書きますが、嘘とかぼかしを適当に混ぜますので気楽に読んでください。
小さいところから改善を図ったデータ移行プロジェクト
前提としまして、中央にデータレイクやDWHの基盤は存在しますし、管理する部隊や実装する部隊などもいました。しかし依頼側が発注の仕方をわからず独自に構築していたため、コンウェイの法則の如くチーム毎に集計システムが出来ていました。「集計システム」と言ってもプログラミングで自動化されたものではなく、Excelを駆使した黒魔術等が点在していました。この方式だと実用に耐えきれなくなって来ましたので、私が間に入ってシステム化しました。
本当は体制とか考えた方がいいのかもしれませんが、システム化にあたり、まず手をつけられそうな部分で改善して効果を実感してもらうところからはじめました。すなわちExcelで黒魔術になっているところを、PythonやPandas.Dataframe、matplotlibを使った簡易なスクリプトに置き換えました。そうやって改善できると信頼されたところで、いよいよ元データの、中央のDWHへの移行を進めました。
DWHへの移行に関しては、装置の運用を別の部隊が行っていたので、技術的な面ではそれほど辛いこともありませんでした。一方大変辛かったというか、工数の9割ぐらいかかったのがデータの整合性チェックでした。というのも、そもそも移行前後で完全に同じ元データが使えなかったため、データの差分を見ながらおおよそあっている？それともおかしい？という事を繰り返していました。
またこのフェーズでは、集計環境をSQLiteからDWHに環境を移しました。しかし完全に同じ動作を再現できない処理もあり、そこも移行前後のデータ不一致の原因になっていました。ここでは、違いの発生したレコードに関して一件ずつ計算を追って、原因を解消していきました。一番しんどかったのはSQLiteのint型に小数のデータを入れた場合はDECIMAL?として扱われ小数の計算ができるのに、整数のデータを入れたときにintegerと扱われ、小数点以下切り捨てられていたことを知ったあたりでしょうか。
-- INT_VALUEに0.8とか入れてると0.4になるのに、1を入れるとint/intとして扱われて0が返ってくる
INSERT TABLE hoge(data) AS SELECT
INT_VALUE / 2
FROM MOTO_TABLE;
また小数の計算時の桁丸めで非常に小さい値になるとき場合、誤差がとても大きくなった事も挙げられます。一例を挙げると：0.00000055 が 0.0000006と切り上げられて誤差10％以上になる場合です。
これらと似たような辛さの話はyuzutasoさんが丁寧に解説されております。https://atmarkit.itmedia.co.jp/ait/articles/1808/03/news009.html
おかげさまでデータも99％以上元データと一致、残りも違いの原因が説明できるところまで来まして、このチームでは中央のDWH基盤を使えそうというところまで来ました。同じ集計結果を使っている複数のチームにも本件が伝わり、中央のDWHへの利用申請が進んでおります。1
10年経って変わったものと変わらないもの
ここまでほとんど技術の話をせずに書いてきました。この10年くらいビックデータの業務に携わって感じたこととして、DWH相当がHadoopからBigQuery/Snowflake等に変わりました。しかし集計に取り込むための要件定義とか集計結果のチェックなど大変なところは相変わらず残っている感じはします（単に自分がそういう場所ばかり放り込まれてるのかも）。データサイエンスの方はAutoMLが頑張ってきてるので、適当にデータ取って投げ込んでくれるものとかが出てきてくれると嬉しいですね。
自分は特に技術的にものすごく尖っているわけではないのですが、ある程度現場の悩みを聴いた上で手を動かすことは得意です。そのため要件を満たす最低限のものを高速に提供する、などのことを結構行っています。
今は上記の仕事の他に、電子系の設計や開発などを行っている方々が自分たちでプログラミングする習慣をつけられるよう、レクチャーを進めています。それらの方々全員が隅々までコーディングできる必要あるのか？という質問が来たりします。その時には、"DeNAやメルカリ等は企画の方たちでも全員SQL叩いて実行する文化が根づいているので2、せめてデータマートからデータを取り出して好みの形に仕上げるぐらいまではなってほしい"と答えています。
余談ですが弊社でもまだまだデータエンジニアが足りていないので、興味のございます方はTwitter:@showyouまでお声がけください。私はこういう地味？な仕事をしていますが、他のメンバーはAWS LambdaでServerless集計環境とかもっとイケてることもしてます。
-
一件不具合を大量に報告されるのは辛いと思うかもしれません。しかし出力した結果を直後に隅々までチェックしてくれる顧客はとてもありがたいです。辛いところだとデータを出した数ヶ月後に「あれ、間違ってるよ」と言ってきたり（架空の話です） ↩
-
"DeNAに入ってびっくりしたのが、エンジニア以外のプロデューサーやプランナーがHue（Hadoop用GUIツール）を使い、HiveQLを駆使してサービスなどの分析を行っていること。" https://codezine.jp/article/detail/7678?p=2 ↩