こんにちは、株式会社タイミー データエンジニアの土川です。
この記事はdatatech-jpアドベントカレンダー21日目の記事になります。
以前登壇させていただいた「データマネジメントチームのマネジメントの方が難しかった話」のイベントでDMBOKを元にしたデータ品質と、タイミーでの取り組みについてお話しさせていただきました。
登壇では話せなかった実際に運用している品質定義について紹介できたらと思います。
これからデータ品質を実装しようとしている方々の参考になれば嬉しいです。
イベント概要とスライド
データ品質
イベントの中では以下のような6種類のデータ品質について紹介させていただきました。
タイミーでは 適時性、一意性、完全性の3つのデータ品質の定義、監視をしていて、それぞれ以下のような定義になります。
特に完全性に関しては、欠損に対して色々な解釈ができると思っており、タイミーでの解釈について紹介したいと思います。
完全性について
DMBOKの中でも紹介されているDAMA UKの完全性の定義は
完全な状態である 100%に対する保存されたデータの割合。
と定義されています。つまり、転送元データを真とした場合に、転送先DWHに対して欠損なくデータが転送できていると完全性は100%となります。
ただ、完全な状態のということは、最低限すべてのデータの中身が一致していることが必要なので、単純に完全性を比較しようとすると、
データ転送元がA行×B列のデータ量とした場合、転送先のA行×B列と1セルごとの比較を行い、一致している数を数えれば良いことになります。
式にすると以下のようになるかと思います。
完全性[％] = (一致しているセル数) / A×B × 100
これを実現しようと思うと、A×Bの計算をすることになります。
これらを各テーブル、データセットで行う必要があることになります。
日々膨大な量のデータを転送している中で、この比較のための計算量はあまり現実的ではなく、タイミーでは完全性を抽象化して捉えることで、代替しようとしました。
タイミーでの完全性定義について
タイミーでは、以下の3つの条件を満たすことで、あるデータセットに対する完全性を満たしていると定義しました。
1. レコード数が一致している。
2. レコードの中身があっている
3. テーブル数が一致している
1のレコード数に対しては、転送元と転送先の同期間 (created_atを参照する) を比較し、一致しているレコード数を計測します。
物理削除とかが入ってくる転送元データセットに関しては、転送元のcreated_atと転送先のupdated_atなどを組み合わせてうまく比較する必要があります。
2のレコードの中身に関しては、先ほど説明した通り、転送元、転送先の2つの全データを比較する必要があるため、計算速度やコストの観点から現実的ではないです。
そこで、全レコードが一致しているかを 近似的に 判定するため、列ごとの統計量を比較することにしました。
統計量としては、とりあえず null_count を利用しました。
採用理由としては、
- データの中身が欠落することは考えられるが、nullではない値が変わってしまう事象は今まで観測されていないため、nullの数を数えれば十分
- string, integer問わず判定可能
となっていますが、ここは会社ごとに変わるかなと思っています。
こちらも同じように物理削除や、差分更新などのデータベースのCRUDや転送手段によって、単純なcreated_atをもとにした比較をするとidの数などがズレることがあるので、updated_atなどを使って、うまく同じ期間のidを引っ張ってくる必要があります。
3は単純なので、説明を省きます。
振り返りと今後
完全性の定義の抽象化により、現実的な計算量で完全性を保守できるようになりました。
完全性は1年くらいこの運用を続けているんですが、とりあえずデータの障害への素早い対応や、利用ユーザーへの品質担保はできるようになっています。
ただ、最近またデータ品質周りでの技術アップデートも多いので、データオブザーバビリティツール、dbtのテストなどを含めて品質監視周りのアップデートの改善をしていきたいと思っています。
最後まで読んでいただきありがとうございました。
終わりに
タイミーのデータ基盤はまだまだ課題も多く、一緒に開発してくださる方を募集しています!
やりたいこと・やるべきことに対して全く人が足りないのでご興味ある方はぜひお話できると嬉しいです！
X(Twitter)のDMなどでカジュアルにお話しすることもできるので連絡お待ちしております。