分析基盤の誤ったデータの対処法

誤ったデータが混入する主な原因

データ入力プロセスで発生する問題

皆さんもご存知の通り、入力時点で誤ったデータが混入することは多々あります。リストエントリーやフィールドの影響や業務プロセスの変更、一貫していない業務プロセス等があります。

データ処理機能の稼働中に発生する問題

入力以外にもデータソースの仕様の誤認識だったり、送られてくるデータ構造の変更等もよくあるケースになります。ベンダーツールや他の部署が扱っているサーバー等、自分が把握できていないところから発生します。
また、どこかしらのシステムで障害が発生しており、ある時間帯はデータが入っていない等もあります。

システム設計が原因で起きる問題

こちらもよく発生することですが、参照整合制制約、一意性制約の不備等が挙げられます。一意性を想定しているが重複してデータが入っていたり、未入力カラムに初期値がいつからか設定されていたりします。
どこかでデータエンジニアが介入しないといけません。

その他の原因やそもそもの原因の特定、データの品質については下記の記事に詳しく記載しています。

データの修正方法

データの修正には、主に2パターンあります。
更新と挿入です。

ポイントは、「データ修正や更新の理由や説明を記録する」カラムに修正理由が掲載されたURLだったりRedmineのようなサービスのチケット番号を入力することです。
こうすることで分析者が除外するべきレコードなのかどうかを確認することができます。

1. データの更新(UPDATE)

対象の既存のレコードを変更する場合は、UPDATEを使用します。

UPDATEを使用する場面としては対象レコードが分析基盤に残っていると不都合があるようなケースです。

ポイントとしては、過去の修正理由(patch_reason)を引き継ぐ対応をすることです。
何故かというと、同一レコードを複数回UPDATEかけてしまうと過去の修正理由が消えてしまい、UPDATEがかかったレコードなのかどうか不明になってしまうからです。

UPDATE orders
SET patch_reason = 2233, //もしくはconcat(patch_reason, ", 2233")
    total_amount = 23123
WHERE order_id = 12345
  AND customer_id = 67890;

2. データの挿入(INSERT, INSERT SELECT)

新しいレコードを追加する場合は、INSERTまたはINSERT SELECTを使用します。

挿入する場面としては対象レコードが分析基盤に残っていて欲しい、つまり履歴として保管したいケースです。

▼INSERTの場合

INSERT INTO orders (order_id, customer_id, patch_reason, total_amount)
VALUES (12345, 67890, 2233, 23123);

▼INSERT SELECTの場合

INSERT INTO orders (order_id, customer_id, store_id, patch_reason, total_amount, store_id)
SELECT o.order_id, o.customer_id, s.store_id, 2233 AS patch_reason, 23123 AS total_amount, store_id
FROM orders o
WHERE o.order_id = 12345 AND o.customer_id = 67890;

分析基盤のDB設計の方法

上記では、「データ修正や更新の理由や説明を記録する」カラムについて述べました。

データの修正理由を記録するためのカラムを追加すると対象レコードの除外処理を集計時に行うことができます。
例えば、下記のようなカラムになります。

• patch_reason

• update_reason

• update_user_id

これらはデータソースで管理する必要はありません。
しかし、データレイク層でカラム追加することで後続のデータマート層で除外処理を入れて集計対象から外すことができます。

まとめ

データ入力プロセスやデータ処理機能の稼働中、システム設計の不備などが主な原因です

データの修正方法としては、主に「更新」と「挿入」の2つのパターンがあります。それぞれの方法において、修正理由を記録することが重要です。これにより、分析時に正確なデータ処理が可能となり、不必要なデータを除外することができます。

もちろん上記の作業で更に誤ったデータが混入することがあるので、自動化することを推奨します。