#バッドデータに関する背景ときっかけ
データ分析や
機械学習の訓練用データを準備する際、
データ量だけでなく、
データそのものの質が問われます。
もし、
質の良いデータであれば、
余計な前処理をする必要はなく、
分析や学習のアルゴリズム構築に注力できます。
もし、
質の悪いデータであれば、
質の良いデータに変換や整形などする
前処理が必要となり、
適切に前処理をしなければ、
期待していない結果を評価する際に困ります。
つまり、
期待していない結果を生み出した原因が、
データの問題なのか、
アルゴリズムの問題なのか、
切り分けることができなくなります。
そこで、
質の悪い「バッドデータ」を
適切に質の良い「グッドデータ」に
前処理するための方法は
どのようなものがあるでしょうか。
今回の書籍『バッドデータハンドブック』では、
さまざまな立場の著者が考える
バッドデータの取り扱い方法について
記述されています。
なお、
以下の研究会に参加した際に、
書籍『バッドデータハンドブック』
を思い出しましたので、
今回の書籍レビューを書いてみました。
データ前処理研究会 by Team AI 10/31(火) - connpass
https://teamai.connpass.com/event/69714/
#書誌情報
書誌情報は以下の通りです。
https://www.oreilly.co.jp/books/9784873116402/
バッドデータハンドブック
――データにまつわる問題への19の処方箋
Q. Ethan McCallum 著、磯 蘭水 監訳、笹井 崇司 訳
2013年09月 発行
310ページ
ISBN978-4-87311-640-2
フォーマット Print PDF
原書: Bad Data Handbook
#主な読者層と読み方
Webプログラマである自分が考える
主な読者層は、
はじめてデータ処理をする際に、
バッドデータに悩まされている方向けの本です。
コード主体ではなく、
考え方がメインです。
本書では、
具体的な処理コードは少なく、
主に、
そもそもバッドデータとは何か、
バッドデータに対してどのような
方針で対処すればよいか、など
考え方に焦点があてられています。
そのため、
具体的なプログラミング処理について知りたい場合は、
別途それぞれの問題ごとに別資料にあたる必要があります。
実務で、
かなり汚いバッドデータを処理した経験がある方にとっては、
基本的なことが多くなります。
正規表現、コマンド、プログラミング言語による
文字列操作に慣れている方にとっては、
基本的な考え方の再確認としては使えます。
また、著者が２０名弱いますので、
各担当のテーマに
かなりばらつきがあります。
自分にとって必要な章だけ参照すればよいと思います。
#バッドデータ処理に取り組む前に
まず、
「データポリシー」を決めます。
つまり、
「どんなデータを入力したいのか」
というビジネス要件を確定します。
入力データの要件を明確に確定できれば、
要件に合致したデータだけ入力できるように、
バリデーションを作成できます。
一方で、
要件が曖昧だと、
良質なデータと、
悪質なデータを区別する基準が明確ではないので、
悪質なデータが混在しがちになります。
一番重要なのは、データポリシーを決めることです。
#バッドデータの定義と種類
まず、
「バッドデータ」の定義は、
一様ではありませんが、
「邪魔なデータ」であることは
共通しています。
バッドデータには、
さまざまな種類があります。
たとえば、
欠損値、
不正なレコードフォーマット、
（１行で入力されるはずなのに、なぜか複数行で入力される、など）
不正なレコード値、
不正なファイル形式、
処理に時間のかかるデータ、
アクセスできなくなるデータ、
突然異なる種類に変わるデータ、
・・・など
これらのバッドデータが原因で、
異常な結果になったり、
システム自体が停止したりするので、
入力させる前の段階で、
前処理をしておく必要があります。
#以下、気になった箇所の抜粋
実務でかなり泥臭い実装をした経験を踏まえて、
気になった箇所を、
適宜抜粋して要約します。
２章
データフォーマット
・カラム型（タブやカンマで区切られる）
カラム型では、区切り文字がデータに混在している可能性を想定して、適切に変換や区切りパターンを決める
場合によっては、区切り文字を１つではなく、
複数の文字から構成される文字列にすることもあります。
例）
区切り文字列「__SEP__」など
データ内に、区切り文字列が混在しないという
前提です。
各フィールドの検証
データフォーマットが確定したら、
データ内の各フィールド（カラム）内容について
精査が必要です。
例えば、
為替データのフィールドにおいて、
ドルやセントの場合もあったり、
円やユーロだった場合、バラバラに
データが格納されてしまいます。
あらかじめ通貨を統一するか、リージョンデータとの
突き合わせをしてプログラムで通貨変換する
必要があります。
数値は最大値、最小値、平均値、最頻値など
に着目して、仕様上ありえないデータを除外します。
文字列など非数値は、
ヒストグラムで多い順ソートしたり、
扱いやすいデータに変換してチェックします。
sort, uniq, awk, といった
いわゆるコマンドや、
perl, python,Rといったプログラミング言語
がよく使われています。
３章
・人間が見るために使うデータと
機械が処理するために使うデータは異なる。
・人間用にレイアウトされたデータは、
バッドデータになりがち。
・データのレイアウト、配置を機械に
教えることは難しい。
・複数のファイルにまたがるデータを処理するためには、
コードを書く必要がある。
４章
・よくある問題
・不明な文字エンコーディング
・不明確な文字エンコーディング
・プレーンテキストに漏れ出すアプリケーション固有文字
いわゆるプレーンなASCII文字だけでなく
Unicodeといった非ASCII文字を
適切に取り扱う必要がある
例）
日本であれば、
SJIS,EUC,UTF-8,など
さまざまな文字コードが混在している
（最近のWeb系はUTF-8に統一されつつある）
Python, iconv, file, Unicode, UTF-8, UTF-16, …
サードパーティ製Pythonライブラリは
充実している
例）NLTK, BeautifulSoup, gensim, jellyfish
５章
・ウェブデータは、
クローリングとスクレイピングが両方とも厄介なので
最後の手段
・あらかじめ準備されたデータそのものを
入手できないか調査する
例）
Infochimps Data Marketplace
ScraperWiki
www.data.gov.ukなど政府系Web
準備されたAPI経由
管理者にコンタクトして特別に入手
・クローリング、スクレイピングする際は、
相手のサーバ負荷に配慮しよう
robots.txt
規約
キャッシュ
クロール間隔
７章
問題なのはデータではない
問題は、
実データと
データに対する考え方の不一致
データやデータ分析は単なる手段にすぎない。
目的は、検討対象を理解すること
その他、
医療関係や
行政データ関係、
リレーショナルデータベースや
クラウドに関連した
事例が掲載されていました。
#プログラマの視点
プログラマの視点から、
バッドデータ対処法について
ランダムに記載します。
・そもそも期待通りの「グッドデータ」は入力されないと考える。入力データは信用しない。
・入力データは、すべてデータ型についてバリデーションにかける
・例えば、NULLなのか、空なのか、数値なのか、文字列なのか、日付なのか、バイナリなのか、など
・また、ビジネスルールのバリデーションにもかける
・例えば、何文字から何文字までの長さなのか、郵便番号か、電話番号か、日本語か英語か、など
・Webアプリケーションなら、
「意図的に攻撃目的で入力されたデータ」もバッドデータ。
エスケープやサニタイジングで、セキュリティ対策も必須。
evil data?
#その他バッドデータに関する補足情報やポエム
"Dirty Data"とも呼ぶらしい。
https://en.wikipedia.org/wiki/Dirty_data
・シグナルとノイズのあいだについて
・シグナル：意味のあるデータ
・ノイズ：意味のないデータ
・意味の有無は何で決まるか
＝発生確率？
例）
「犬が人に噛みついた」・・・普通にありうる事象
「人が犬に噛みついた」・・・普通はありえない事象
・エントロピー
キーワード「エントロピー」について関連するらしいが、
別途まとめる必要あり。
#結論
書籍『バッドデータハンドブック』は、
データに関わるエンジニア、プロデューサーは、
読んで損はない書籍かと思います。