Q.Ethan McCallum「バッドデータ ハンドブック データにまつわる問題への19の処方箋」オライリージャパン 磯蘭水監訳 笹井崇司訳

要するに、バッドデータとは邪魔になるデータのことです。
　　――はじめに：バッドデータとは何か？

「バッドデータ」であったからこそ、私たちは新しいことを学べたのです。
　　――７章　バッドデータは起立して

私たちのお粗末な仮説が、データを「バッドデータ」にしているのです。
　　――７章　バッドデータは起立して

早く失敗しよう、たくさん失敗しよう（Fail early, Fail often）
　　――８章　血と汗と尿

経験によれば、分析プロジェクトに費やす時間の80％は、クリーニング、改変、変換などのタスクに費やされるそうです。
　　――15章　データサイエンスのダークサイド

私たちの戦略の中心にあるのが不変性です。私たちの処理のパイプラインがデータを何度も変換しても、私たちはもとのデータを決して変えませんでした(上書きしませんでした)。
　　――17章　データ追跡可能性

【どんな本？】

　必須のはずの項目がない。数字だけのはずなのにテキストが入っている。一部のデータがない。逆に重複している。値が大きすぎる。文字化けする。対応するデータがない。フォーマットが違う。特定範囲の値がない。データが分散している。

　仕事でプログラミングをした事があれば、誰もがこんなデータで困った経験があるだろう。サーバ管理やネットワーク管理などでログを集め分析する際に、ちょっとした道具が欲しくなることもある。ソフトウェアを開発する際には、テストデータも必要だ。最近流行の機械学習も、しつけ方・使い方次第で性能は大きく異なる。

　データの集め方・困ったデータの処理方法・手に入れたデータの検証方法・テストデータの扱い方など、データにまつわる失敗談や成功例を集めた、ソフトウェア・エンジニア向けの濃いエッセイ集。　

【いつ出たの？分量は？読みやすい？】

　原書は Bad Data Handbook : Mapping the World of Data Problems, by Q. Ethan McCallum, 2013。日本語版は2013年９月25日初版第１刷発行。単行本ソフトカバー横一段組みで本文約280頁。8.5ポイント38字×32行×280頁＝340480字、400字詰め原稿用紙で約852枚。文庫本なら厚い一冊分。

　文章はオライリーの標準的な水準。察してください。サンプル・ブログラムも幾つか載っていて、使っているプログラム言語は awk, perl, R, Python, SQL など。でも私は大半のソースをトバして読んだ。それぞれの言語を知らなくても、プログラミング経験者なら、地の文を読めばだいたい分かります。そもそもプログラムに関する本じゃなくて、データに関する本だし。

【構成は？】

　各章はほぼ独立しているので、気になった所だけを拾い読みしていい。

• 監訳者まえがき／著者について／まえがき
• １章　はじめに　バッドデータとは何か？
• ２章　気のせいかな。このデータ、何かおかしくないか？
• 2.1 データ構造を理解する
• 2.2 フィールドの検証
• 2.3 値の検証
• 2.4 単純な統計による物理的解釈
• 2.5 可視化
• 2.6 キーワードPPCの例
• 2.7 検索参照の例
• 2.8 推薦分析
• 2.9 時系列データ
• 2.10 まとめ

• ３章　機械ではなく人間が使う事を意図したデータ
• 3.1 データ
• 3.2 問題：人間が使うためにフォーマットされたデータ
  
  • 3.2.1 データの配置
  • 3.2.2 複数ファイルにわたるデータ
• 3.3 解決策：コードを書く
  
  • 3.3.1 扱いにくいフォーマットからデータを読み込む
  • 3.3.2 複数のファイルにわたるデータを読み込む
• 3.4 あとがき
• 3.5 ほかのフォーマット
• 3.6 まとめ

• ４章　プレーンテキストに潜むバッドデータ
• 4.1 プレーンテキストのエンコーディング
• 4.2 テキストエンコーディングの推測
• 4.3 テキストの正規化
• 4.4 問題：アプリケーション固有文字のプレーンテキストへの漏れ出し
• 4.5 Python を使ったテキスト処理
• 4.6 練習問題

• ５章　Webにあるデータの(再)構成
• 5.1 データを直接入手できないか？
• 5.2 一般的なワークフロー
  
  • 5.2.1 robots.txt
  • 5.2.2 パターンの特定
  • 5.2.3 パースのためにオフライン版を保存する
  • 5.2.4 ページから情報をスクレイプする
• 5.3 現実の難しさ
  
  • 5.3.1 できるだけ生のコンテンツをダウンロードする
  • 5.3.2 フォーム、ダイアログボックス、新規ウィンドウ
  • 5.3.3 Flash
• 5.4 ダークサイド
• 5.5 まとめ

• ６章　オンラインレビューから嘘つきと混乱した人を発見する
• 6.1 Weotta
• 6.2 レビューの入手
• 6.3 センチメント分類
• 6.4 極性のある言葉
• 6.5 コーパス生成
• 6.6 分類器のトレーニング
• 6.7 分類器の検証
• 6.8 データによる設計
• 6.9 学んだこと
• 6.10 まとめ
• 6.11 リソース

• ７章　バッドデータは起立して
• 7.1 例題１：製造時の欠損削減
• 7.2 例題２：だれが電話をかけたのか？
• 7.3 例題３：「平均値」が「標準的な値」とみなせないとき
• 7.4 学んだこと
• 7.5 これはテストに出ますか？

• ８章　血と汗と尿
• 8.1 とってもオタクな入れ替わりコメディ
• 8.2 化学者による数値の作り方
• 8.3 All Your Database are Belong to Us
• 8.4 チェックしよう
• 8.5 人生は太く短く、見栄えの良いコードを残すべし
• 8.6 化学者とスプレッドシート乱用者のためのリハビリ
• 8.7 まとめ

• ９章　データと現実が一致しないとき
• 9.1 それは何のティッカー？
• 9.2 分割、配当、単位変更
• 9.3 バッドリアリティ
• 9.4 まとめ

• 10章　バイアスとエラーの源
• 10.1 補完バイアス
• 10.2 報告エラー
• 10.3 その他のバイアス源
  
  • 10.3.1 トップコーディング、ボトムコーディング
  • 10.3.2 継ぎ目バイアス
  • 10.3.3 代理報告
  • 10.3.4 サンプル選択
• 10.4 まとめ
• 10.5 参考文献

• 11章　最善は善の敵、バッドデータは本当にバッドなのか？
• 11.1 大学院時代
• 11.2 プロフェッショナルな世界へ
• 11.3 政府の仕事へ
• 11.4 行政データという現実
• 11.5 911緊急通報データ
• 11.6 さらに先へ
• 11.7 学んだこと、そして今後の展望

• 12章　ファイルにこだわる
• 12.1 昔のはなし
  
  • 12.1.1 ツールセットの構築
  • 12.1.2 データストアという障害
• 12.2 ファールをデータベースと見なす
  
  • 12.2.1 ファイルはシンプル
  • 12.2.2 ファイルは何にでも使える
  • 12.2.3 ファイルには何でも入れられる
  • 12.2.4 データ破損が局所的である
  • 12.2.5 すばらしいツールがある
  • 12.2.6 導入コストがかからない
• 12.3 ファイルの概念
  
  • 12.3.1 エンコーディング
  • 12.3.2 テキストファイル
  • 12.3.3 バイナリデータ
  • 12.3.4 メモリマップドファイル
  • 12.3.5 ファイルフォーマット
  • 12.3.6 区切り文字
• 12.4 ファイルに基づいたWebフレームワーク
  
  • 12.4.1 モチベーション
  • 12.4.2 実装
• 12.5 考察

• 13章　Crouching Table, Hidden Network
• 13.1 リレーショナルなコスト配分モデル
• 13.2 組み合わせ爆発という繊細な響き
• 13.3 隠れたネットワークが現れる
• 13.4 グラフを格納する
• 13.5 Gremlinを使ったグラフのナビゲート
• 13.6 ネットワークプロパティに価値を見いだす
• 13.7 複数のデータモデルから、仕事にふさわしいツールを使う
• 13.8 謝辞

• 14章　クラウドコンピューティングの神話
• 14.1 クラウド入門
• 14.2 「クラウド」とは何か？
• 14.3 クラウドとビッグデータ
• 14.4 フレッドについて
• 14.5 最初はすべてがうまくいっている
• 14.6 すべてをクラウドのインフラに任せる
• 14.7 成長に合わせて、最初は簡単にスケールする
• 14.8 やがて問題が起こり始める
• 14.9 パフォーマンスを改善する必要がある
• 14.10 高速なI/Oが必要になる
• 14.11 局所的な機能停止が大規模なサービス停止を引き起こす
• 14.12 高速なI/Oは高くつく
• 14.13 データサイズが増加する
• 14.14 地理的冗長性が最優先になる
• 14.15 水平方向のスケールは思っていたほど簡単ではない
• 14.16 コストは劇的に増加する
• 14.17 フレッドの愚かさ
• 14.18 神話１：クラウドはあらゆるインフラ構成要素にとって、素晴らしい解決策である
  
  • 14.18.1 この神話はフレッドの話にどう関係するのか
• 14.19 神話２：クラウドはお金を節約する
  
  • 14.19.1 この神話はフレッドの話にどう関係するのか
• 14.20 神話３：クラウドのI/Oパフォーマンスは、ソフトウェアRAIDによって許容できるレベルにまで改善される
  
  • 14.20.1 この神話はフレッドの話にどう関係するのか
• 14.21 神話４：クラウドコンピューティングは水平方向のスケールを簡単にする
• 14.21.1 この神話はフレッドの話にどう関係するのか
• 14.22 まとめ

• 15章　データサイエンスのダークサイド
• 15.1 落とし穴を避ける
• 15.2 汝、データについて知るべからず
  
  • 15.2.1 データをきれいにしてまとめる際には一貫性を持つべからず
  • 15.2.2 データは正しく完全だと思え
  • 15.2.3 時間区切りデータのあふれ
• 15.3 汝、データサイエンティストにあらゆるタスクのための単一ツールを与えよ
  
  • 15.3.1 アドホックな分析のためにプロダクション環境を使う
  • 15.3.2 理想的なデータサイエンス環境
• 15.4 汝、分析のために分析せよ
• 15.5 汝、学びを共有するべからず
• 15.6 汝、データサイエンティストに全能を期待せよ
  
  • 15.6.1 データサイエンティストは組織のどこにいるのか？
• 15.7 最後に

• 16章　機械学習の専門家の手なづけ方
• 16.1 問題を定義する
• 16.2 作る前に、うまくいっているふりをする
• 16.3 トレーニングセットを作成する
• 16.4 特徴を選び出す
• 16.5 データをエンコードする
• 16.6 トレーニングセット、テキストセット、ソリューションセットに分ける
• 16.7 問題を説明する
• 16.8 質問に答える
• 16.9 解決策を統合する
• 16.10 まとめ

• 17章　データ追跡可能性
• 17.1 なぜ？
• 17.2 個人的経験
  
  • 17.2.1 スナップショット
  • 17.2.2 情報源の保存
  • 17.2.3 情報源の重み付け
  • 17.2.4 データを元に戻す
  • 17.2.5 フェーズを分ける(そしてフェーズを純粋に保つ)
  • 17.2.6 根本原因を特定する
  • 17.2.7 改善領域を見つける
• 17.3 不変性：関数型プログラミングからアイデアを拝借する
• 17.4 例題
• 17.4.1 クローラー
• 17.4.2 変更
• 17.4.3 クラスタリング
• 17.4.4 人気
• 17.5 まとめ

• 18章　ソーシャルメディア：消去可能インク？
• 18.1 ソーシャルメディア：これはだれのデータか？
• 18.2 コントロール
• 18.3 商用再配信
• 18.4 コミュニケーションと表現に関する期待
• 18.5 新しいユーザが抱く期待の技術的影響
• 18.6 業界は何をするのか？
  
  • 18.6.1 検証API
  • 18.6.2 更新通知API
• 18.7 エンドユーザは何をすべきか？
• 18.8 どのように協業するのか？

• 19章　データ品質分析の解明：データが十分良いときを知る
• 19.1 フレームワークの紹介：データ品質分析の四つのC
• 19.2 完全である
• 19.3 一貫している
• 19.4 正しさ
• 19.5 説明責任
• 19.6 まとめ
• 索引

【感想は？】

　ベテラン・プログラマの「あるある」集。

　多少なりとも仕事でプログラムを作った経験があるなら、一度は変なデータに手ひどく痛めつけられた経験があるだろう。特に、人間が入力したデータは危ない。数字のカラムのはずなのに、atoi() で変換できないとか。

　原因は位取りのカンマだったり、全角の数字だったり。酷いのになると、漢数字なんてのもある。そういうので苦労した経験がある人には、特に前半じゃ苦笑いが止まらない。そういえば日本のプログラマなら、みんな苦しむ「住所を都道府県・市町村・所番地に分割する」なんて問題もあるね。

　やはり日本のプログラマが昔から悩んでいた問題を扱ったのが、「４章　プレーンテキストに潜むバッドデータ」。要は文字コードの問題だ。最近は「とりあえず Unicode でいいじゃん」的な風潮になりつつあるが、古いデータだと姓名とかに外字が入ってたりするからタチが悪い。まあ、ここではそこまで突っ込んだ話はなく、HTTP や URL などの独自エンコーディングぐらいに留めてある。

　最近になると Web が流行って、様々なデータを集めやすくはなったけど、それをプログラムに食わせるとなると、これまた一筋縄じゃ行かない。各自治体が発表している統計データも、自治体ごとにサイトの構成もデータ形式も違う。Excel なら可愛い方で、中には PDF や Flash なんて凶悪な奴も。ほんと、皆さん一度はこう叫んだことがある筈だ。

最初から人間ではなくコンピュータが使えるようなフォーマットにしておけばよかったのに。
　　――３章　機械ではなく人間が使う事を意図したデータ

いやホント、政府が主導して XML の標準形式を定めてくれればいいのに。いまだに発想が紙ベースなんだよなあブツブツ。

そんな風に Web 経由でデータを集めようとすると、他にも色々と困ることがある。なにせ相手は「人に見せる」ために作っているので…

以前、何日か実行していたWebスクレイピングのスクリプトが突然エラーを吐き始めたことがありました。問題は、Webサイトがまったく違うデザインになったことでした。
　　――５章　Webにあるデータの(再)構成

　ああ、あるねえ。まあ、人様のデータを勝手に頂いてるんだから、文句も言えないシクシク。酷いのになると、訴訟沙汰になったり(→Wikipedia)。もっとも、中には Facebook や Twitter みたく親切な所もあって…

スクレイピングを最小限にするためによく利用されているのは、スクレイパーが実際に欲しがっているデータのための公式チャンネルを提供することです。
　　――18章　ソーシャルメディア：消去可能インク？

　ほんと、先の事件も全国の図書館が協力して蔵書 XML の標準形式を…って、もうあるみたいだ。おかげでカーリルなんて嬉しいサービスも始まった。ラッキー。

　データが集まったからといって安心しちゃいけない、と教えてくれる「７章　バッドデータは起立して」「９章　データと現実が一致しないとき」「10章　バイアスとエラーの源」「11章　最善は善の敵、バッドデータは本当にバッドなのか？」は、コードが少ない分、コラムとして面白かった。

　また「６章　オンラインレビューから嘘つきと混乱した人を発見する」は、自然言語処理ネタとして楽しめる。うん、確かにお気に入りを自分だけのモノにしたいって気持ちはわかるｗ　終盤では「14章　クラウドコンピューティングの神話」や「16章　機械学習の専門家の手なづけ方」など、大規模データにまつわる話も出てくる。案外と機械学習って、根気のいる地道な繰り返し作業も多いのね。

　そんな大容量データとくればデータ・マイニング。私も名前は知ってるけど中身はよくわからない。これは私だけじゃなく経営者も同じで、中にはこんな無茶ぶりする人も。

「データのところへ行って、価値を見つけてこい！」
　　――15章　データサイエンスのダークサイド

　わはは。コンピュータ絡みの世界って、昔から変わんないなあ。そこのシステム屋さん、似たような事を言われた経験、ありませんか？

　などと無駄口を叩いてなんとか記事をデッチあげたけど、実は記事を書いてるよりアクセス・ログを眺めている時間の方が多かったりする。そんなヒマがあったら、もっと面白い記事をかけよ、などと思ったりもするけど、この本は心強い言葉で締めくくられている。

データを調べている時間は必ず有意義である。
　　――19章　データ品質分析の解明：データが十分良いときを知る

　うん、そうだよね、きっと私がログを眺めている時間だって無駄じゃないはずだ←をい

【関連記事】

• 2016.07.08 Diomidis Spinellis, Georgios Gousios編「ビューティフルアーキテクチャ」オライリージャパン 久野禎子・久野靖訳 1
• 2016.04.25 Raffaele Cecco「JavaScriptグラフィックス ゲーム・スマートフォン・ウェブで使う最新テクニック」オライリージャパン 相川愛三訳 1
• 2015.02.27 John Whitington「PDF構造解説」オライリージャパン 村上雅章訳
• 2014.11.21 Andy Oram, Greg Wilson編 Brian Kerninghan, Jon Bentry, まつもとゆきひろ他著「ビューティフルコード」オライリージャパン 久野禎子,久野靖訳 1
• 2013.06.24 David Flanagan「JavaScript 第六版」オライリージャパン 村上列訳
• 2010.11.14 Eric.A.Meyer「CSS完全ガイド第2版 CSS2&CSS2.1対応」オライリージャパン 株式会社クイープ訳
• 書評一覧：科学/技術

【おまけ：バッドデータの例】

　なんて言うほどでもないけど。このブログ、ときおり「著者別の書評一覧」が欲しくなったりする。「書評一覧」なんて記事があるぐらいだから、簡単そうに思えるけど、実は意外と手ごわい。というのも、他でもない、バッドデータがうじゃうじゃあるからだ。

　基本的に、記事タイトルはこんな形になっている。

著者名「書名」出版社 [ 訳者 ]

　ところが、こうなってない記事が幾つもあるのだ。例えば…

1. SFマガジン編集部編「SFが読みたい！2019年版」早川書房
2. 宮内悠介短編集「超動く家にて」東京創元社
3. 日下三蔵編「日本SF傑作選４ 平井和正 虎は目覚める／サイボーグ・ブルース」ハヤカワ文庫JA
4. 大森望・日下三蔵編「年刊日本SF傑作選2013 さよならの儀式」創元SF文庫
5. C.L.アンダースン(サラ・ゼッテル)「エラスムスの迷宮」ハヤカワ文庫SF 小野田和子訳
6. ギレルモ・デル・トロ＆チャック・ホーガン「ストレイン 永遠の夜 上･下」ハヤカワ文庫NV 嶋田洋一訳

　また、表記の「ゆれ」もある。カート・ヴォネガットとカート・ヴォネガット・ジュニア、ベルナール・ウェルベルとベルナール・ウエルベルとベルナール・ヴェルベールとか。

　加えて、「スタートボタンを押してください」みたくアンソロジーになると、多数の著者が寄稿してて、かつ著者名は記事本文の中に埋もれてたり。

　この程度のブログでさえ、書籍データをキチンと定型化できてない。となると、すべての書籍のメタデータを規格化しようとしたら、どれほどの「想定外のパターン」が出てくることか。これをすべて洗い出すってのは、かなりシンドい仕事になるはずだ。モノゴトをコンピュータが扱えるようにデータ化するってのは、そういう事なんです。