• Q. Ethan McCallum [編], 2013: Bad Data Handbook. Sebastopol CA USA: O’Reilly Media, 245 pp. ISBN 978-4-449-32188-8.

【この本の存在は、たぶん奥村晴彦さんのtweetで知ったと思う。データ屋としては読むべき本かとも思ったが、実物を見てから決めようと思った。ところが5月3日にまた奥村さんのtweetで、O’Reilly社が電子書籍を1日だけ半額(合計額によっては6割引き)にするというニュースがはいった。電子書籍にコピー防止のしかけをしないようにしようというキャンペーンなのだそうだ。それで、この本を含めて迷っていた数冊を電子版で買ってしまうことにした。電子書籍の形式はePubが本命だと思っているのだが自分の準備ができていないのでPDFにした。】

業務データを活用しようとしている企業や、そのためにソフトウェアを開発している人たちを読者として想定した本だ。Handbookという題名からは体系的な教材を想像する。初めのほうの2-5章と終わりの19章の構成はその期待に合っていると思うが、中間は、個別の経験の話題と、総論とが入りまじっている。

以下、章ごとの覚え書き。大部分はわたしなりの要約で、少し自分の感想。

1. Setting the Pace: What Is Bad Data? /著者名なし。おそらく編者。
われわれ(著者)の目的はデータではなく、データからinsightを得ることだ。
ここでいうbad dataには技術的なもの(値の欠損、形式の正しくない記録、変な形式)もあるが、それに限らず、仕事をややこしくする要因となるデータをいう。
続いて各章の紹介がある。ここでは章のグループを特徴づけることばをそのまま紹介しておく。
Guidance for grubby, hands-on work (2-5章)
Data that does the unexpected (6,9章)
Approach (8,7,10,11章)
Data storage and infrastructure (13,14,12章)
The business side of data (16,15章)
Data policy (17-19章)

2. Is It Just Me, or Does This Data Smell Funny? /Kevin Fink
データ処理の手順を追って、どういう困りごとが起きうるか、どう対策するかを述べる。
-データ媒体が物理的に読めないという問題もあるが、ここでは深入りしない。
-データの構造を知る。縦横表型txt (csvを含む)、XML, JSON, Excelが多い。著者はExcelのファイルはタブ区切りテキストに変換して使っている。
-必要なフィールドを抽出する。PerlにはCSV, XML, JSONそれぞれを読むライブラリがあるので、それを使って切り出す例を示している。
-各フィールドの値はフィールドの定義にてらして有効なものか?
-数値フィールドの最小値・最大値などは現実的か? (このチェックは自動化可能。ただし数量の単位に注意する必要がある。)
-文字フィールドの値の統計的要約。頻度ごとのヒストグラム。sort, uniq, awkを利用する例。
-数値の頻度のヒストグラムを見る。数値を得たもとのアルゴリズムに疑問が生じることもある。
-数値の時系列グラフを見る。例としてWikipediaのpage viewのデータの場合。明らかなまちがい、現実の曜日依存性、データの重複、現実と思われるピーク、現実かデータ部分欠損か不明の谷が見える。

3. Data Intended for Human Consumption, Not Machine Consumption /Paul Murrell
データがExcelのワークシートファイルで提供される場合、それは人が見てわかりやすいように作られた表であることが多い。機械処理のためには、relational databaseでいう正規化された表にするべきだ。
また、複数のワークシートファイルに分かれているデータを扱うのはてまがかかる。
著者はRでプログラムを書いて変換処理した。
なお、日本では、Excelが罫線入りの文書を作るための道具として使われるので、本書の例よりももっと扱いにくいものがたくさんある。

4. Bad Data Lurking in Plain Text /Josh Levy
テキストファイルであっても、文字コードの問題がある。また、URL encoding, HTML encoding, SQL escapingなどが混ざることがある。著者は対策のプログラム例をPythonで書いている。

5. (Re)Organizing the Web’s Data /Adam Laiacano
ウェブ上のデータをどう使うか。
データはサーバー上ではrelational databaseにあるがそれは外からアクセスできないのがふつうで、頼めば提供してもらえる場合もある。すでに整理されて公開されたり売られたりしていることもある。またAPIで提供されていることもある。その出力フォーマットはJSONかXMLが多い。
しかし、ウェブページに人が読むために表示されたデータを収集しなければならないことも多い。その場合、URLを構成し、ウェブページを取得し(ローカルコピーを作り)、解読(parse)し、前からのファイルに追加する、という仕事がある。この4つのステップは区別して実行するべきである。ウェブサイトの構成が変わると取得または解読が失敗することがある。
データ取得の段階は次のような場合がある。
-単にダウンロードすればよい場合は簡単だが、ネットワークの不正利用と思われないように注意が必要なこともある。
-フォームを埋めてダウンロードを指示する必要がある場合もある。著者はブラウザのプラグインを使って自動化した。
-やっかいなのはFlashでグラフが示されているサイト。著者はAppleScriptでSafariブラウザを制御しスクリーンショット画像をとりあとで色判別解析したそうだ。

6. Detecting Liars and the Confused in Contradictory Online Reviews /Jacob Perkins
店などの紹介をするウェブサイトをやっている。ユーザーからの投稿が本気か、うそか、混乱したものかの判断をしたい。用語から、よい感情をあらわすものと、悪い感情をあらわすものを定量的に取り出し、論旨とてらしあわせることが、助けになる。
書評の場合を考えてみると、本に対する反発と、本で書かれている対象に対する反発を語彙処理だけで区別することはできないと思うが、著者は本を扱っていないらしい。

7. Will the Bad Data Please Stand Up? /Philipp K. Janert
この著者は「データが悪いのではなく、それを扱う方法が不適切なのだ」という主張を持っている。
最初の例は、品質管理の問題。まれな異常値を検出するのに確率プロットを使う。確率分布はひとまずGaussianを仮定したら、はずれと判定されることが期待に比べて多すぎた。そこで工場を見に行ったら、製造上の品質問題と別に、測定をしようとして製品をこわす事故がときどきおきていた。安上がりな自動チェックは困難であることがわかった。
2番めの例は電話着信回数のヒストグラム。Poisson分布にあてはまるかを調べた。 一連のやりとりがあったとき最初のものだけを数えればあてはまる。つまり最初のものと続きのものは別の母集団に属すると見られる。
3番めの話題は、利用頻度の統計で、平均値に対応する典型的利用者はいないことが多いということ。利用頻度がべき分布のときなど。
問題点が見落とされてしまう原因には、願望思考、じみな仕事を嫌うこと、統計的・計算的方法の前提を意識しないこと、がある。
データは目的ではないので、データ自体よりもそれをもたらしたシステムについて考えるべきだ。

8. Blood, Sweat, and Urine /Richard Cotton
同じ組織の中でも化学実験室の文化は情報処理技術者の文化と違うことが、1週間滞在してみてわかった。
化学実験室ではデータを人がチェックしていた。2人でチェックしないデータは無効とするという品質管理をしていた。ところがその手順として、まずExcelに入力し、あらためてデータベースに手入力していた。(情報処理技術者から見れば、自動化したほうがまちがいが減らせることは明らかだ。)
データベースは化学研究者自身が管理していた。(データを支配したいという思いがあるようだが、データ管理の部署にまかせたほうがよい。) そのせいで、古い設計のまま、データ量が大きくなっていた。
古い設計の問題点のひとつだが、数値と指定されたフィールドに「欠損」や「検出限界未満」を入れようとして、同じ状況が作業者によって違った値で入力されていた。データベースのデザイン時に、論理変数のフィールドを別に作り、数値フィールドでは0を禁止するのが適切だ。しかし、すでに0が入力されたデータベースで0を無効にすると検出限界未満の測定値が除かれて偏ったサンプリングになってしまう。
実験条件は文字列を各自が自由に入力したので同じ意味の表現が複数できてしまってわかりにくくなっていた。フィールドに入れることのできる値を限定すべきだ。
データのチェックは、データ取得時、データベース入力時、解析時にくりかえしすべきだ。
変数の型のチェックが自動でなされるのがよいが、そうでなければ意識してする必要がある。
数量の単位のチェックも必要。データベースの変数名に単位を組みこんでしまうと、作業する人のかんちがいが減らせる。
プログラムは一定のスタイルで書くこと。内容を表わす名前をつけよう。
表計算ソフトウェアには次のような欠点があるので頼りすぎないこと。数値計算の精度。式か数値か区別がつきにくいこと。修正後の再解析の手間。

9. When Data and Reality Don’t Match /Spencer Burns
現実の対象をidentifyすることのむずかしさの例。ニューヨーク証券取引所の会社コードは、現在のidentityだけを考えたもので、時系列的に使えない。過去に使われたコードが別の会社に再利用されることがある。また、合併や破綻再建でコードが変わる際に、法的継承者は追跡できるが、それが実質的業務やブランドの継承関係と違うことがよくある。
株価の数値を不連続にする要因としては合併のほか株分割もある。しかし株価は現実に奇妙な変動をすることもある。

10. Subtle Sources of Bias and Error /Jonathan A. Schwabish
著者は行政データ、とくに社会保険に関する台帳データを使ったことがある。この行政データには、個人情報保護のため解析に提供されない項目がある、所得の情報が報告・名寄せされたものに偏る、という欠点がある。しかし、社会調査(アンケート)のデータには、「思い出せない」などの理由による欠損に由来するデータの質の問題、サンプルの偏り(たとえば調査活動に関心のある人のほうが回答率が高い)の問題がある。

11. Don’t Let the Perfect Be the Enemy of the Good: Is Bad Data Really Bad? /Brett Goldstein
現実のデータはいつも完全ではない。ランダムサンプリングができないことが多い。
例として、警察が受けた通報の記録。行ってみてだれもいなかった場合、犯罪になる事件がほんとうにあったのか不確実だ。しかしそういうデータをみな無効扱いしていたのでは始まらない。不完全であることを意識しながら使う。

12. When Databases Attack: A Guide for When to Stick to Files /Tim McNamara
(著者は修士論文のためにインターネットからデータを集めて70GBのデータベースを作ったが、インデックスを作るのに時間がかかりすぎるため結局使えず、修士論文は別の材料で書いた、という経験があるそうだ。)
データベースというべき内容であっても、データベースソフトウェアを使わずにファイルで扱ったほうが安全なこともある。
そこで利用可能ないろいろなデータフォーマットを概説している。
とくに、インターネット上の情報交換ではJSONというフォーマットが使われることが多いが、人が読み書きするには、JSONはまちがえやすく、YAMLのほうがよいそうだ。

13. Crouching Table, Hidden Network /Bobby Norton
課題は企業のコスト配分。支出と予算の事業項目とを関係づけるのだが、関係は直列ばかりとは限らず、「グラフ」構造がある。こういうものをrelational databaseでは扱えなくはないがややこしくなる。Graph databaseという形で扱うのがよい。それを操作するソフトウェアに Gremlinというものがある。

14. Myths of Cloud Computing /Steve Francia
クラウドは有用だが、万能であるかのような宣伝はまちがいだ。専用サーバーのほうが得なこともある。著者が経験したさまざまな例を、急成長する一つの企業にたとえて論じている。
データ量が多くなると入出力がネット越しでは遅くなる。停電などによるシステム故障からの復帰にvirtual machine再構築が必要なことがある。地理的分散は、停電などの対策としては望ましいが、情報伝達時間の問題がある。statelessのサービスは分散しやすいがstatefulなデータベースは分散しにくい。時間あたりのサービス件数がふえるとデータのコピーを持って分散処理をする必要が生じるが、データ内容の整合をとる負担がふえる。この規模になると、同じperformanceを得るのに専用サーバーよりもクラウドのほうが費用がかかる。(設備費用から運転費用に移るのが企業としてはうれしい場合もあるが。) 今後の技術の発達で事情が変わる可能性はある。

15. The Dark Side of Data Science /Marck Vaisman
データを扱う技術や体制に関するべからず集。原文では見出しが「べし」の形で書いてあるが、著者が言いたいのはその否定だ。ここでは著者が望ましいと考えていることを「べし」の形で紹介する。
-データ取りこみの際に一貫した処理をすること。発見しにくい例として、スペースとタブの混在があげられている。
-データの欠損はないものと仮定せず初めから考えておくこと。
-データが日付ごとに分類されているように見えても、前後の日のデータが含まれることがよくある。
-実運用と研究開発は期待される確実性が違うので計算機システムを分けたほうがよい。研究開発用のシステムでは研究者にツールを追加できる権限が必要。
-解析のための解析ではなく、目的を考えた解析をする。
-知識を共有する。
-データサイエンスは強力ではあるが万能な人はいない。
-データサイエンティストがいる場所はまちまち。ともかく会社全体の中での位置づけが必要。

16. How to Feed and Care for Your Machine-Learning Experts /Pete Warden
機械学習のプログラム開発を専門家にアウトソーシングした事例だというのだが、懸賞の形をとって、プログラム発注より安くすませている。これは同じことをまねするところがふえるとできなくなるだろうと思う。なお、機械学習のトレーニングセットとテストセットを作る段階は作業者を雇って手間をかけている。
事例の課題は写真が旅行雑誌向けに「よい」かどうかの判断なのだが、写真を見た評価と写真の説明文にあることばによる評価との相関が高かったので、説明文の用語から「よさ」を判断する問題にしてしまっている。

17. Data Traceability /Reid Draper
あちこちから集めた情報で構築したデータベースの質をよくするためには、データを情報源にさかのぼれる形で持つべきだ。音楽の購入を勧めるためのデータベースについての経験に基づいて、注意すべき点を述べている。
-情報源のサイトの内容が変化する。手もとに変化しないコピーを持つことにする。取得した日付をつけて区別して管理する。
-加工結果データに材料データのsource情報を引き継ぐ。
-情報源に信頼度などによる重みづけをする。
-まちがっている材料データを除いて加工しなおす。
-問題が起きたら原因が情報源にあるのか加工にあるのかをはっきりさせる。
-データ処理の問題点を見つける。

18. Social Media: Erasable Ink? /Jud Valeski
FacebookやTwitterなどのsocial mediaは、書きこんだ利用者が書きこみを取り消す機能を持つようになった。しかし、そのデータは再利用されている。もとが消えているのに先が残っているbad dataができる。
書きこんだデータはだれのものかという権利問題もあるが、サービスプロバイダには利用者の希望にそいたいという動機はある。しかし、上流から変更通知をしただけでは、下流で受けて対応するかどうかが不確実だ。下流の応用プログラムが上流に記録の存在を問い合わせてからデータを使うように作ってくれればよいが、常にそうできるとは限らない。利用者は取り消しが完全にはできないことを覚悟する必要がありそうだ。

19. Data Quality Analysis Demystified: Knowing When Your Data Is Good Enough /Ken Gleason and Q. Ethan McCallum
Bad dataを捨てるのか、受け入れるのかの決断が必要になる。
直観に頼ったのでは、微妙な問題をとらえきれない。まちがうこともある。過去の経験に依存する。
「data quality」のわくぐみで考えよう。
“Complete” … 問いに対して必要なものがそろっていること。これから問いそうなことを含む。
-総数がわかっている場合とそうでない場合
-数量の完全さと構造情報の完全さ
-完全なチェックが現実的にできないこともある。その場合はサンプリングによるチェックになる。
-不完全なデータをどう使うかの選択をせまられることがある。
“Coherent”
-Relational databaseではreferential integrity checkが可能だが、データ入力時にははずすこともある。
-値のintegrityの問題。具体的に満たすべき条件は対象依存。
“Correct”
-数値の確認は実利用段階かもしれないが、
-たとえば時刻の順序が正しいかの確認は先にやっておいたほうがよい。(時計修正が必要なことも。)
“aCcountable” … データの責任者はだれか?
-取得-加工-利用の鎖がトレーサブルになっていること。
-意思決定に使う人から、あるいは監査者から、問われる。
-個人情報のビジネス利用については、たとえばカリフォルニア州では州法によって追跡可能にする義務がある。
-問いに答える際に人がボトルネックにならないように構造を設計しておくべき。
-データ源、使用条件を記録する。
-オリジナルデータと変更記録を保存する。
-自分がどんな変更をしたか確認する。
-監査資料を提供できるようにしておく。
-Supply chainを認識し、もとデータが変更されたら派生物も変更できるようにする。
-だれがどのようなアクセスができるか理解する。理想的には、アクセス方法を限定し監査可能にする。少なくともだれが書いたか記録する。
本来の仕事とは区別して、データの質のチェックを考えよう。
まだチェックされていない(目標が決まっていないのでできない)データを、それと意識しよう。

自分の仕事をふりかえってみると、データの問題点にはいつも注意しているつもりだが、系統的な対策はほとんど実践できていない。目標が決まっていない試行錯誤的なデータ観察が多いのでしかたがない面もあると思う。データを発信する場合や、作業をほかの人に引き継いでもらう場合には、トレーサブルな体制を組むべきなのだが、その道のプロに頼んで組んでもらうしかないかもしれない。