2013年夏のプログラミング・シンポジウム　ビューティフルデータ(1) 午前 #spro2013

雑記

(講演者の方の氏名は敬称略)

[招待講演] パーソナルデータ保護法制に向けた最近の動向 高木浩光(産業技術総合研究所)

ここ2年ほどで急にきわどい事例が出始めた
(なんかたがが外れた感じ。技術的に実現可能になったからではない)


本人の同意があれば問題ない
ただし、真に同意があると言えるか疑わしい事例あり
契約上の同意だけでなく、自主的な同意がないとダメというのが法律家の意見
コンテキストに沿わない取得と利用(誤認誘導型)


特定の個人を識別できないデータならOKという主張
なぜそう思うの？逆になぜ特定の個人を識別できるデータはヤバいと思うの？
個人情報保護＝連絡先の保護と誤解している人も何割かいる


何をもって匿名化されていると言えるか
PPDM privacy preserving data mining などの技術を前提に制度設計してよいか否か
政治家は、こういう技術が社会的にどう影響を与えるかわからない


例: ロンドンのスマートゴミ箱
通行人を識別してた→問題とされて試験運用を中断

この半年の動き
    • 総務省　パーソナルデータの利用・流通に関する研究会
      • 情報セキュリティ対策室10月設置、6月報告書
      • 個人情報保護法を超越した保護。利活用の制度を提案
      • パーソナルデータ⊃個人情報
    • 経産省　IT融合フォーラム　パーソナルデータWG
      • 情報経済課 11月設置、5月報告書
      • 消費者と事業者の信頼関係の構築→有効な同意の確保へ
    • 内閣府　規制改革会議　創業等WG
      • 内閣総理大臣諮問　1月設置　3-5月WG、6月答申
      • 氏名住所削除で匿名データとみなそうとするが失敗
      • 現行法を無視してガイドラインで合法化を目指す方向性

6月14日 世界最先端IT国家創造宣言


国際先端テストの結論(消費者庁)
「匿名化情報の利用に関する日本と欧米の制度の比較」
特定個人を識別できるような対応表を廃棄すれば問題ない、法改正は必要ない
→そんなことはない



個人情報保護法

個人情報とは
生存する個人に関する情報であって
氏名、生年月日その他の記述等により特定の個人を識別することができるもの
(他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む)


法解釈上の論点
「識別することができる」は誰によって識別という話か？
提供者基準(政府及び消費者庁・経産省、鈴木)
受領者基準(岡村)


岡村久道 個人情報保護法　新訂版、商事法務、2009
Aにとって識別性を具備しない情報を、これを具備するBに提供するケースは実際に発生しうるか疑問
→これは誤り


X(識別性あり) → Y(識別性なし) → Z(識別性あり) を想定していない



  • 業務委託との混同に注意
  • データ分析の業務委託の場合(政府説での理解)
    • 委託契約の元で履歴データを提供(預託)する
    • データから氏名等を削除して臨時のIDを付して渡すのが通例
    • その意図は、安全管理措置として事故字の被害を軽減するためであり、個人データの提供に当たらなくする(個人情報に該当しなくする)ためではない
    • 委託先は委託元と一体であるから委託先においても個人データ


JR-日立の例
一旦JRが受け取った後の統計データであればまだよかった
業務委託した日立がデータ提供しているのが問題
似てるようで全然違う
現行法だと違法だと言っていい


現行法
提供毎にランダムIDを付与するのは合法
→提供毎に過去全部のデータを提供してしまえば無意味




データ自体による照合性
k-匿名性との関係(全データがk=1だったら？)



適切な匿名化措置
匿名化したデータを再識別化しないことを約束・好評
第三者に提供する場合は、提供先が再識別化することを禁止すること




ゲノム科学におけるビッグデータ・データマイニング 石井一夫(東京農工大学)


バイオインフォマティクス、計算機統計学、ゲノムのデータ解析が専門
「Rによる計算機統計学」


次世代シーケンサーとは、2005年ごろ実用化された新型分析機器。
大量拘束にDNAを解読可能で、ヒトゲノムを3時間程度で解読
個装基板上にDNA断片を子草加市、これを蛍光色素＋酵素反応などを用いて、同時並列的に解読。CCDカメラで撮影+コンピュータで処理。
1検体大体数GBで、数百GBのデータを日常的に処理する。大体1000人程度で200TB
このデータを解析していく。

1. 画像処理からDNA塩基配列を取得する。
2. 配列を集計、編集していく
3. 統計処理をしていく

分散しやすいところ(マッピングやBLAST検索)はHadoop (AWS EMR)、分散しにくいところは大量のメモリ(4TB)を積んだサーバで処理

  • Hadoop上で動作する分析ツール
    • Crossbox(ジョン・ホプキンス大学)
    • Contrail
    • Myrna
    • GATK(Genome Analysis ToolKit)


次世代シーケンサーデータの品質管理

サンプル濃度の間違いや試薬濃度の間違いなどの解析
モンテカルロを使うと精度よく品質解析可能


Q. 圧縮してないの？
してる場合もある、と回答してたのであまり圧縮してないっぽい


数式を綺麗にプログラミングするコツ 中谷秀洋(サイボウズ・ラボ)


スライド http://www.slideshare.net/shuyo/programming-based-on-formula


数式
↓
数式から行間の情報を読み解く
↓
「逐語訳」できる形に数式を書き換える
↓
実装


きちんと計算後の次元・サイズを確認する
さぼらず紙と鉛筆で確認するのが一番賢い

HBase論争に釣られてみる

翻訳

HBaseコミッター達による、NoSQLの記事への反論が面白かったので翻訳してみました。

著者の許諾取得済み。Thanks Stack and the other authors!

本文

原題: Taking the Bait


Information Weekは先日、「HBase はNoSQL を支配するのか?」という記事を掲載した。MapR の Michael Hausenblas は HBase の事例に「賛成」の論陣を張っており、Apache Cassandra の Jonathan Ellis とベンダーである DataStax は「反対」の側だった。

この「ディベート」をベンダーのセールストークとして却下し、Apache HBase に立ち戻り、HBase を使用し、改善していくのは、簡単な話である。しかし、この記事は特別に問題のある例だった。記事では、「賛成」と「反対」の双方とも、HBase コミュニティの仕事にはほんの少ししか言及していない。ここでは誤りを訂正する目的で、いくつかの点に言及したい。

まず、Michael は、Hadoop が急速に成長しており、そして、HBase は Hadoop から出てきたのであり、緊密に結びついているのであるから、HBase は上向きの上向きだ、と論じていた。HBase コミュニティの積極的な参加者でなければ、このような仮定を立てるのは容易である (HBase によって Hadoop の採用を推進されているところでは、その逆に出くわすことにもなる)。
Michael は次に、古い一貫性対 eventual-consistency の戦いに話を焼き直し、飽き飽きする HBase 対 Cassandra の機能比較に切り替えた。そして、最後には、Cassandra の源泉である Facebook がデータ保存のために、大きなサイズのいくつかのアプリの代わりに HBase を使用することにしたというだけの理由で、HBase の方が良い、と結論づけた。我々はその種の論争などしない。Apache HBase か Apache Cassandra を活用すべきであるかどうかは、多くの要因によるのであり、多くの規模の問題と同様に攻撃的な言い争いに巻き込まれすぎているといえる。


その次に Michael は、「我々は企業向けの HBase の「次のバージョン」を作り上げた・・・。我々は2013年5月に M7 のラベルの下でその新しいバージョンをGAにもたらした」と語り、おとり商法を行った。この引用での「我々」というのは、Apache HBase コミュニティのことを述べているのではなく、Michael の雇用主であるMapR Technologies のことを指している。また、Michael が言及する「企業向けの HBase」というのは Apache HBase のことではない。M7 というのは、我々が知る限り、構造上 Apache HBase とは根本的に異なっている、プロプライエタリの製品である。その製品はソースが明らかにされていないのであり、我々はこれ以上は言及できない。この話は、Apache HBase コミュニティが長年にわたり、ハードワークと、Apache HBase 以外の商業的なクローズドソースの製品への寄与を通じて築き上げてきた信用と善意をいただいてしまおうとする試みと見えた。


次は、Jonathan の「反対」の論に言及してみたい。Jonathan の主張のいくつかは今はもう真実ではないか、大いに主観的である。真実でないというのは、「RegionServer のフェイルオーバーは10分ないし15分かかる」という箇所である (HDFS-3703 および HDFS-3912 を見てほしい)。主観的であるというのは、「HBase をもとに開発を行うのは苦痛だ」という箇所である (我々の意見では、我々のクライアントAPIは、一般的に使用されているCassandra クライアントライブラリよりも簡単で使いやすい)。これら以外のものについては、どれもメーリングリストから Quora に至るフォーラムで何年にもわたり論議・再論議してきたものばかりだった。Jonathan の論は大部分は、我々が Apache Hadoop の HDFS ファイルシステムと緊密に結びついていることと、 Google BigTable アーキテクチャの輪郭をなぞっていることから来るものを、列挙しているだけである。HBase は HDFS の多くの機能を利用し、BigTable からは着想を得ている。その結果として、Cassandra にとっては問題となるユースケースのいくつかを、我々は得意としている。逆もまた真である。我々のユーザーが使用するハードウェアは進化するのであり、あるいは、新たなユーザーが新しいユースケースをもとにした経験をもたらすのであり、我々も HDFS もじっとその場に立ち止まったままではいない。


彼は、アプローチの違いを強調している。


我々は協調させるために、Apache HDFS の採用、Apache Hadoop MapReduce の統合、および、Apache ZooKeeper の使用を選んだことを、健全な関心の分離と見なしている。HBase は歴戦のコンポーネントで構築されている。これは特徴であり、バグではない。


Jonathan が組み込まれたクエリ言語やセカンダリインデックス機能をコア Cassandra に必要な複雑化と見なすのに対し、我々は、Salesforce の Phoenix のようなプロジェクトを、Apache HBase を中心とするより大きなエコシステムの一部である見なし、支援する。Phoenix の人たちは問題のその部分にドメインの専門知識をもたらすことができるが、我々 (HBase) は、安定したパフォーマンスの高いストレージエンジンコアを提供することに焦点を当てることができる。Apache Hadoop をここまで成功させてきたものの一部は、プロジェクトを支援し豊かにするそのエコシステム、HBase を含むエコシステム、である。そのようなエコシステムが、HBase の周囲で発展してきた。


Jonathan が、HBase コミュニティのことを「リーダーシップ」が分散されているために「断片化」されていると評する方向へとそれていくのに対し、我々は、そこで言及されているのはたぶん、Apache HBase プロジェクトは「所有」されたプロジェクト、つまりたった1人のベンダーに導かれたプロジェクト、ではないという事実であるのだろうと考えている。むしろそれは、多くの組織、ほんの数例をあげれば、Cloudera、Hortonworks、Salesforce、Facebook、Yahoo、Intel、Twitter、および Taobao ということになるが、それらの多くの組織からの多くのチームがみな協力してそのプロジェクトを推進していこうとしている、そのようなプロジェクトなのである。Apache HBase コミュニティのほとんどは、2つのブランチでの共同作業に参加している。ブランチの1つは新規の0.96のリリースに関するものであり、もう1つは現在の安定したリリースである0.94に関するものである。Facebook もまた、共有されているソース管理リポジトリにおいて、Facebook 独自の Apache HBase のブランチをもっている。このブランチはインスピレーションの源泉になっており、ときに他のブランチへの直接的な寄与となっている。我々のコミュニティのニーズと要望に応じた便利で効率的な協力モデルを発見したことについて、我々は謝罪するつもりなどない。たった1人のベンダーに導かれた他のプロジェクトにとっては、このことは完全に最適化されていないか、場合によっては混沌 (「断片化」) とすら見えることだろう。


我々はこれはそのまま残しておく。

いつもと同じように、我々は、我々のコミュニティと Apache HBase プロジェクトへのあなたの参加と寄与を歓迎する。我々には、偉大な製品と、特定の商業体への恩義がなく、エゴのない、摩擦の少ない意思決定プロセスとがある。もしあなたがかかなければならない痒みがあって、Apache HBase が解決策ではないかと思うのなら、あるいは、あなたが Apache HBase を使用していて、もっといい改善案があるはずだと感じるのなら、我々のところにやってきて、大いに話をしましょう。

Hadoopのディスクあふれ対策(補足)

雑記


最近流行りのディスク容量があふれたときの挙動、Hadoop編を書こうと思ったらwyukawaさんが既に書いてくださったのでやめました。
……と思ったのですが、せっかくなので id:wyukawa さんが書いてない箇所を補足してみようと思います。

( この記事は @ にレビューしてもらっています。ありがとうございます )

wyukawaさんの記事へのコメント

まずHBaseを使っている場合はcompactionがある関係上Disk使用率は50%以内に抑えておくのが無難だと思います。この辺はCassandraと同じですね。


全データを同時にコンパクションするケースはまずないので無理に50%以下に抑えなくていいとは思いますが、意識はしておいた方がいいですね。
私は60%での警告を推奨しますが、この辺はケースバイケースです。
MapReduce の出力結果など、いきなり容量増える場合もありますし、サーバが飛べば総容量は減りますから、HBase を使っていない場合でも容量ぎりぎりに使うことは推奨しません。

次にNameNodeの場合はdfs.name.dirで指定したディレクトリにメタデータを書くわけですが、このパーティションがDisk Fullになった場合はNameNodeがdownします。大変危険ですので注意しましょう。


dfs.name.dir は CDH3 / Hadoop 1.x 系のプロパティです。CDH4 / Hadoop 2.x 系だと dfs.namenode.name.dir になります。
dfs.namenode.name.dir を複数指定している場合、いずれか一つに書き込みが成功すれば警告のみでダウンしません。
WebUIからは、メタデータを書き込めないディレクトリは failed と表示されます。
edits の書き込みは、QJMベースにしていれば複数台中過半数に書き込めていれば大丈夫です。
例えば3台のジャーナルノード(JN)があれば、1台のディスクがあふれてもサービス継続します。

hadoop fs -rmで削除してもTrashが有効になっている（fs.trash.intervalが設定されている）場合は.Trashにmvするだけなのでそこも消しましょう。


hdfs dfs -expunge で Trash を空に出来ます。

Hadoop のデータ使用量


大体以下のような感じで容量を食います。

  • NN
  • 2NN 及びスタンバイNN
    • NNと同じだけのデータ及びバックアップのメタデータ(デフォルト2世代、dfs.namenode.num.checkpoints.retainedで調整可能)
    • つまり(アクティブ)NNより容量が多いので注意！
  • ジャーナルノード(JN)
    • edits
    • ログ
  • DN
    • 実データ
    • ログ
NN


そもそもメタデータ(fsimage)はメモリ上にロードしなければいけないのでせいぜい数十GBが限界。
editsは処理内容によりますが、きちんとチェックポイントが稼動していれば数GBも見ておけば十分かと。大抵の場合100GBもいくことはないと思います。
問題はログで、数百ノード〜1000ノードクラスになると数分あたり1GBなんていう恐ろしいスピードで生成されていきます。
あっという間にパンクするので注意しましょう。
ログの管理については後述。


NNについて重要なのは、100GBぐらいの容量は割と普通に使うということです。
DNに比べてディスク容量少なくていいからといって、133GB の HDD とかで RAID1 組んだりしてるとディスクあふれて落ちる場合がありますのでご注意ください。

DN


ディスク内バランシングについては wyukawa さんが書いた通り。
一時データのつもりでレプリカファクター1とかで書き込んだりしているとあっさり偏りますので、ディスク監視とこまめなバランサー稼働をこころがけましょう。

5ブロック分の書き込み容量を確保できないDNは、NNから書き込み不能DNとみなされますので、HDFSの書き込みであふれることはないです。


「Hadoop はDN 1台死んだって問題ないからそんなに心配しなくてもいいんじゃね？」
と思う人がいるかもしれませんが、もしうまいことばらけて書き込んでる場合は他のDNもディスクがいっぱいになってるはずなのでわりと状況は深刻です。
HDFSの総容量は常にチェックしておきましょう。

ログ


Hadoop 1.x 及び CDH3 系はデフォルトが DRFA です。
つまり、1日ごとにローテーションしていく形式です。
これにより、ある日のログだけ異様に膨らむということが起こりえます。
CDH4 / Hadoop 2.x 系はデフォルトが RFA でサイズ固定になっています。(デフォルト 256MB * 20ファイル = 5GB)
ログあふれが起こりにくくなっている反面、ログが流れやすいので注意が必要です。


CDH4 で MapReduce1 を使っている人は、MR1だけがデフォルト CDH3 準拠、つまり DRFA になっていることに注意してください。

参考


捕捉

よく考えたらオリジナルは「容量が少ないというアラートが飛んできたときにどうするか」なので、上記の内容だとただの予防ですね。
とりあえず思いつくのを二つ。

ログ消しましょう

RFA だと昔よりログあふれしにくくなったとはいえ、緊急事態のときには真っ先に削除する対象なのは変わらないでしょう。
クラスタ内に入って Hive を起動している場合、ローカルファイルシステムの /tmp/${ユーザ名}/ 以下に hive.log などのログ一式が収まっていますので、パーティション分けていない場合はこれも消しましょう(微々たるものですが)

HDFS

ゴミ箱ディレクトリ ~/.Trash の削除は前述の通り。
/tmp も消せるものは消しましょう。MapReduceなどのジョブの実行情報などが格納されているのでジョブの再実行ができないかもしれませんが、緊急事態なのでクラスタがダウンするよりマシです。一時しのぎしつつ根本的な対応を急ぎましょう。

MacOSXにnumpy, scipy, matplotlibをインストール

雑記

西尾さんの記事を試したかったので、必要なパッケージをインストールしました。

手順

gfortran を入れる→ pip install で必要なものを突っ込む、の順。
コンパイルする必要があるので XCode 必須。

まずは gfortran をインストール。

$ brew install gfortran

次に pip install でパッケージをインストール。

$ pip install numpy
$ pip install scipy
$ pip install matplotlib

  • warning がたくさん出るけど気にしない
  • easy_install だとうまく入らなかった。原因不明だし本当に easy_install に問題があるのかも未検証

勝ち続ける意志力

雑記

勝ち続ける意志力 (小学館101新書)

勝ち続ける意志力 (小学館101新書)


プロゲーマー、梅原大吾の本。
ゲームに限らず、一つの道に真摯に向き合うための心構えについて教えてくれる、素晴らしい本でした。
特に心に残った箇所をまとめてみました。

勝つことに執着している人間は、勝ち続けることができない
(p.14)

100回や200回かつくらいでは、全然足りない
(p.14)

ほとんどの人は、実力がつけばつくほどに自分なりのスタイルというものを確立してしまう。
…さらに危険なのが、自己分析して自分のスタイルを決めるのではなく、他人の評価を鵜呑みにしてしまうことだ。
(p.55-56)

センスや運、一夜漬けで勝利を手にしてきた人間は勝負弱い。
(p.59)

自分の好きなジャンルで安易な道を選ぶことは考えられない。
(p.62)

便利な技を使えばコンスタントに80点は出せるかもしれないが、100点には届かない。
(p.64)

弱点を突いて勝つ戦法は、勝負の質を落とすような気さえする。
その対戦相手は自分を成長させてくれる存在なのに、その相手との対戦をムダにすると感じるのだ。
だから、弱点を突かず、むしろ相手の長所となる部分に挑みたい。
(p.68)

必勝法はないと確信しているからこそ、次から次へと手を替え品を替える。
……とにかく、できることを片っ端から試していくのだ。
隅から隅まで徹底的につぶしていくので、どれが良くてどれがダメなのか、自分の経験として身体が覚えていてくれる。
(p.73-74)

生み出した特許よりも、新しい特許を生み出す力の方が遥かに重要なのだ。
(p.77)

考えることをやめなければ出口は見つかる。
(p.95)

自分を痛めつけていると、努力しているような気になる。しかし、そんな努力からは痛みと傷以外の何も生まれてこない。
(p.185)

自分にとっての適量を考えるなら、
「その努力は10年続けられるものなのか？」
自問自答してみるのがいい。
(p.194)

勝った翌日ほど対戦する
(p.240)

Fabric の run() メソッドと sudo() メソッド

雑記


この記事では、Fabricの主要メソッドである run() と sudo() について解説します。

サンプルコードは https://github.com/shiumachi/fabric-sample にあります。

run() と sudo() の基本


読みやすくするため、以後は必要がない限り run() メソッドのみを取り上げます。run() で出来ることはほぼ全て sudo() でも出来ます。断りが無い限り、run() は sudo() と読み替えることができます。

  • from fabric.api import run でインポート可能
  • run([コマンド文字列]) で、任意のコマンド文字列を実行可能
  • sudo([コマンド文字列]) とすれば、任意のコマンド文字列を sudo できる

エラーハンドリング


run() で実行したコマンドが失敗した場合、fab コマンド自体がその場で中断(abort)されます。

もしそのまま処理を続行したい場合は warn_only=True という引数を追加します。

def run_error_warn_only():
    run("hoge", warn_only=True)


warn_only=True だけだと、処理は続行できますがエラー出力はそのまま行われます。
エラー出力も抑制したい場合は quiet=True を追加します。

def run_error_warn_only_with_quiet():
    run("hoge", warn_only=True, quiet=True)

出力内容やリターンコードを使う


run() コマンドの返り値には、出力内容とリターンコードなどの情報が含まれています。

この返り値、公式ドキュメントでさえ使い方がきちんと整理されて書かれていないので、ここにまとめておきます。

res = run() としたとき、

  • print res
    • 実行したコマンドの出力内容を出力する
  • res.return_code
    • リターンコードを返す
  • res.succeeded
    • コマンドが成功していたら True、失敗していたら False を返す
  • res.failed
    • コマンドが失敗していたら True、成功していたら False を返す。succeeded の逆。


となります。

def succeeded_sample():
    res = run("hostname", warn_only=True)
    if res.succeeded is True:
        puts("succeeded!")
        return

sudo() で、リモートサーバ上で別のユーザとしてコマンドを実行


リモートサーバで、現在実行しているユーザとは別のユーザでコマンドを実行したいときがあります。

例えば、Hadoop HDFS の管理コマンドは hdfs ユーザしか扱えません。

そういうときは、user='ユーザ名' を使います。

def sudo_user_sample():
    print sudo("id", user='sho')


ユーザ名は、既に存在する別のユーザがあればそのユーザと置き換えてください。

関連記事

zsh による Fabric コマンドのタブ補完

雑記


Fabricは便利ですが、コマンドが多くなると管理が大変になり、いちいちコピペするのが面倒になります。

zsh を使えば、Fabric のタブ補完をすることが可能です。
ここでは、oh-my-zsh を使ったタブ補完の設定方法を紹介します。

oh-my-zsh のインストール


id:mollifier さんがインストール方法についてまとめてくれていますので、こちらを参考にしてインストールしてみてください。

http://mollifier.hatenablog.com/entry/20101009/p1

Fabric 用タブ補完プラグインの導入


残念ながら、Fabric 用タブ補完プラグインは oh-my-zsh のアップストリームにマージされていません。

santiycr 氏が補完プラグインを書いていますのでそれを使ってください。


~/.oh-my-zsh/plugins/fabric というディレクトリを作成し、以下のファイルを置いてください。


https://github.com/santiycr/oh-my-zsh/blob/master/plugins/fabric/fabric.plugin.zsh


やり方が分かる人は、santiycr 氏のリポジトリを fetch して必要なパッチのみを cherry-pick するといいでしょう。

一応こんな感じにすればうまくいくはずです。
細かい説明は省略します。

使い方


fabfile.py のあるディレクトリで fab と入力した後、タブを押すだけです。

コマンドを補完するか、補完対象のコマンド一覧を表示してくれます。