概要
先日 Data Engineering Study #11「6社のデータエンジニアが振り返る2021」 において、タイミーのデータ品質における振り返りをさせていただきました。(以下発表スライド)
こちらの発表の最初の方でデータの品質として 適時性 というものをSLIとして定義し、分析者とSLAを契約し、DRE (Data Reliability Engineering) チームでSLOを保守するための監視システムについて紹介しました。
ここでは 適時性 を
転送元データソースの更新からどのくらい遅れて転送先で実用可能か
と定義しました。
ここでの定義は一般的なものではなく、タイミーの今のデータ基盤フェーズにおいて最低限の保守に基づいた定義になっています。
適時性 という言葉は、データエンジニアのバイブルであるDMBOK1で定義されているものとなり、一般的に使用される言葉であると認識しています。
この記事では、DMBOKと日本のデジタル庁のデータ品質における評価指標・定義を洗い出し、次に保守していくべき品質指標を自分なりに決めていきたいと思います。
背景
DMBOKとデジタル庁のデータ品質定義について紹介します。
DMBOK
DMBOKは国際的なデータ専門家で組織された非営利団体DAMA Internationalによって策定された、データマネジメントに関する知識を体系的にまとめられた書籍です。
DMBOKについては多くの記事や参考書籍が出ているので、そちらを参考にしてもらうのが良さそうです。
個人的には @yuzutas0 さんが出されている データマネジメントが30分でわかる本 がおすすめです。 (kindle unlimitedで0円だと...!!)
DMBOKの13章ではデータ品質の指標についてまとめられており、DAMA UKが2013年に発表したホワイトペーパーでは代表的な指標として以下の6種が定義されています。
| 指標 | 定義 |
|---|---|
| 完全性 | 完全な状態である100%に対する保存されたデータの割合。 |
| 一意性 | 物事の識別方法が同じであれば一度しか記録されない。。 |
| 適時性 | 要求された時点とデータが現実を反映した時点との差。 |
| 有効性 | データはその定義が要求する構文 (フォーマット、タイプ、範囲) に準拠する場合に有効である。 |
| 正確性 | 表現すべき「現実世界」の対象や事象をデータが正しく表す度合い。 |
| 一貫性 | ある物事に対して異なった表現が使われても定義上同等である。 |
定義の内容はいまいち理解が難しいですが、細かい説明がDMBOKに書いてあるのでここでは説明を省かせてください。
デジタル庁
今回はデジタル庁から発表されている データ品質管理ガイドブック（β版) 23 を参考にしてデータ品質の指標について見ていこうと思います。
このガイドブックでは、データ品質の指標を ISO/IEC 25012 に沿って定義しています。
ガイドブック内では15種類のデータ品質についての評価項目、問題となる例などが紹介されており、とてもわかりやすく説明されてます。
ここでは指標と評価項目だけを載せておきます。
| 指標 | 評価項目 |
|---|---|
| 正確性 | 書式が正しいか。誤字脱字などはないか。意味的な誤りがないか。データに誤りはないか。 |
| 完全性 | 用途に応じて必要な項目が網羅されているか。必須項目に空欄が含まれていないか。 |
| 一貫性 | データセット内でデータに矛盾はないか。データセット間でデータに矛盾はないか。 |
| 信憑性 | データの出所が明示されているか。データの更新日が明示されているか。改ざん防止策が施してあるか。 |
| 最新性 | 公開データの更新サイクルは元データの更新サイクルに対して適切か。データは収集時から十分に短い期間で公開されているか。など |
| アクセシビリティ | ファイルで提供している場合、データの使用権を持つ全ての人が利用できるようになっているか。など |
| 標準適合性 | 使用している文字セットは正しいか。選択項目に、指定された選択肢以外のデータが入っていないか。など |
| 機密性 | データにアクセスできるのは、アクセスを許可された者に限定されているか。利用者を制限する場合、暗号化やハッキング対策などが行われているか。 |
| 効率性 | データの内容に重複などがないか。データは効率的に処理できるようになっているか。 など |
| 精度 | データの精度は適正に設定されているか。データの精度がそろっているか。データの精度が示されているか。 |
| 追跡可能性 | 外部データが明確になっているか。データの変更の際に、変更者、変更日などを記録しているか。 |
| 理解性 | データ全体及びその各項目が意味するものを利用者が理解できるようになっているか。データ全体や必要に応じてその各項目にメタデータが提供されているか。 |
| 可用性 | 必要な時にいつでもデータにアクセスできるようになっているか。データを公開するシステムは常時稼働しているか。 |
| 移植性 | 標準的なフォーマットで出力できないソフトウェアに依存していないか。など |
| 回復性 | データのバックアップが保存されているか。システム障害が発生した場合であっても、継続してデータを提供するバックアップシステムが存在するか。 |
多いですね〜。こちらは可用性、回復性などのシステムに関する品質の指標もいくつかありますね。
この辺りはBigQueryの可用性などに依存しますね。
それにしてもどれから守っていけば良いのか迷いますね！
保守する品質指標の選定
定義を洗い出したところで、タイミーでは次にどの指標を守るべきなのかを最後に個人的に考察します。
弊社ではとりあえず、適時性を保守できているのでその次に保守すべき指標を選んでいきます。
まずDREチームと分析者とで現在起こっている問題についていくつか洗い出します。
- BigQueryで集計した結果が間違っている場合がある
- あるテーブルのレコード数が一致していないことが原因であることが多い。
- 集計結果が重くて、可視化や結果が表示できないことがある。
- テーブルが増えてきて、どのテーブルがどんな意味を持つテーブルなのかが分からない。 (特にDWHにおいて)
他にもいろいろと課題はありますが、緊急度高いものをざっとあげるとこんな感じです。
課題感としては上2つが重めなので上2つに絞ってみると、2つ目の集計結果が重いことに関しては、dbt Cloud, LookerなどでDWH, データマートなどを用意してあげることがとりあえず必要なので、品質の問題とは外れそうです。
となると、1番上の集計した結果が間違っている課題を品質を管理することで解決していくのが良さそうです。
これに相応しそうな定義はいくつかありますが、テーブルのレコード数などが原因であることが多いので、
- 完全性 (DMBOK, デジタル庁)
- 一意性 (DMBOK)
- 正確性 (デジタル庁)
とかが候補になってきそうです。
DMBOKの完全性がデジタル庁の正確性を包含してそうなので、DMBOKでいう完全性、一意性が保守すべき指標になりそうです。
品質の監視について
完全性と一意性を選定したのでこれらをどう監視して保守していくか考えていきます。
一意性に関しては弊社はdbt Cloudを採用しているので、各テーブルのprimary_keyに対してdbtのtestで用意されているuniqueを用いれば良さそうです。
参考: https://docs.getdbt.com/docs/building-a-dbt-project/tests
難しいのは完全性です。
これはレコード数が正しくて、重複がなくてもレコードの一部がnullだったり、異なる値が入っていた場合、完全性の品質が低いことになりますし、集計結果に影響が出ます。
ここに関してはいい方法がわからないのでぜひ皆さんの監視方法について教えていただきたいです...!
各テーブルの全データとかテーブルの列ごとのデータを全部くっつけて、ハッシュ化することでデータの中身の正確性を監視するとか...?
最後まで読んでいただいてありがとうございました。
発表スライド