BigQuery に JSON を読み込ませて Query 投げようとしてどうしてもうまくいかなくて泣いていたんだけど、何を勘違いしていたか分かったのでまとめておく。¹

一応全部

Google Cloud Storage から JSON データを読み込む  |  BigQuery  |  Google Cloud

に書いてある。分かりにくいけど。

まとめ

• BigQuery は SQL
• SQL はテーブル、言い方を変えると行指向

もともと1行1レコードのデータ（例えばログ）に向いている。ドキュメント指向な複雑な構造の JSON データはそもそも向いていない。

ndjson(NEWLINE_DELIMITED_JSON)にしろ

• ndjson
• Newline delimited JSON is awesome – Jaga Santagostino – Medium

BigQuery は読み込める JSON 形式を Newline Delimited JSON と名乗っている。これは複数レコードに渡る JSON データを [] と , で区切るのではなく、改行で区切ってしまおうというもの。

NG

[
  {"key1": "val1", "key2": "val2"},
  {"key1": "val2", "key2": "val2"},
  ..
]

OK

{"key1": "val1", "key2": "val2"}
{"key1": "val2", "key2": "val2"}

まぁここはそんなに難しくないと思う。

nested and repeated JSONの意味

BigQuery は 1レコード内に object をそのまま含むことはできない。これをやりたい場合は nested and repeated JSON にするとよい。

ここは日本語訳が恐らく間違っているので英語の方を載せておくと

Loading nested and repeated JSON data

BigQuery supports loading nested and repeated data from source formats that support object-based schemas, such as JSON, Avro, Cloud Firestore, and Cloud Datastore.

Loading JSON Data from Google Cloud Storage  |  BigQuery  |  Google Cloud

どういうことかというと、以下のような話。

NG

{
  "key1": "val1",
  "parent": {
    "childkey1": "val1",
    "chidlkey2": "val2"
  }
}

OK

{
  "key1": "val1",
  "children": [
    {"childkey1": "val1"},
    {"childkey2": "val2"}
  ]
}

or

{
  "key1": "val1",
  "children": [
    {"childkey1": "val1"},
    {"childkey1": "val2"}
  ]
}

これは JSON だけでなく、複雑な構造を扱えるデータソースならすべて同様になるらしい。

ただしこれがクセモノで、ややこしいのは、この NG のケースのデータ、実は data load もできるし、レコードが一つしかない場合は query 実行もできる。レコードが複数になった途端、dataset が not found と言われたり、JSON table encountered too many errors と言われる。これらの現象から原因を推測するのは正直厳しい。

それでも以下のおまけにあるような形式にするよりはややこしくなさそうなので、nested and repeated JSON にする、という方針がよさそうだと思っている。

ということで API のレスポンスなんかの JSON の形式とは別に、分析用のデータ（ログとか）に関しては nested and repeated つまり

{
  key: val,
  key2: val2,
  items: [
    {},
    {}
  ]
}

みたいな形式を採用しよう！と思いましたとさ。

おまけ

制限事項には以下のように書いてあって、

制限事項

Cloud Storage から BigQuery に JSON データを読み込む際は、以下の点に注意してください。

BigQuery では JSON のマップや辞書がサポートされません。たとえば、"product_categories": {"my_product": 40.0} は無効ですが、"product_categories": {"column1": "my_product" , "column2": 40.0} は有効です。

同じことやんけ！という気がするが、column1, column2, … という名前は予約されている、と解釈すると BigQuery 向けに column1, column2 と key を名付けて構造を repeated and nested にしない、という選択もあり得るが、ややこしすぎるし、BigQuery 経由ではなく生でデータを見たときに意味が分からないのでこの案は捨てた方がよいように思う。

Meetup #12 - Kanazawarb

最近まともに参加できてません。というかこの日記も一ヶ月後に書いているありさま。

というわけで参加表明なしにmeetupに遅刻して途中から参観してる感じだった。

• MC、書記ともにうまく機能していた
• みんなスクリーンに向かいながらやいのやいのとふり返っていた
  • 付箋とホワイトボードのワークショップ形式はリード経験のある人がいないので採用しなかったのかな？
• 他の勉強会などで「動いている」人がいるので積極的にノウハウを教わっていた

Meetup #12 report - KPT log - Kanazawarb

思っていたよりはずっと元気な感じでやれていたのはよかった。「RailsGirlsとか」「Girls !?」とコテンパンにツッコまれて楽しかった。

個人的な成果

個人的には「そろそろ思いっきりRubyやりたい」という話を切り出せたのはよかった。あと、

• meetupのリズムが浸透してきている
• 一応何人かで作業を分担できている

ので、自分がいなくてもちゃんと回っている感じが何よりよかった。Kanazawa.rbとしての成果でもあるけど、一人の人間が動けなくなってもコミュニティが継続できるところまできたんだなーと思うと、とても感慨深い。

Kanazawa.rbがなくなってしまうのはもったいない、と思える人が増えたってことだと思っている。とても嬉しい。

Kanazawa.rbとしての新たなチャレンジ

1. 開催は毎月。3ヶ月に一度程度テーマを決めて作り込む形にする。
   • 基本の日程は決まっているのでまずカレンダーに入れてみる
2. ネタ帳作りをWikiで

毎月開催は従来通りなんだけど、毎回毎回テーマに悩むのはやめることにした。これはいい。これでさらに継続しやすくなった。また、その悩ましいテーマについては、テーマを設定するのは3ヶ月に一度¹とし、その日程も先々までスケジュールをとりあえず組んだ。

やりやすくなったと同時に先々の仮決めのスケジュールを公表できるようになった。これで解決できたのは以下の二点。

• 他の勉強会との日程被りを気にして日程がブレる
• テーマが決まらなくてオタオタする

そして最大のメリットは 日程発表の遅れを避けられるようになった。²

楽しみが増えてきた感じだ。

ネタ帳と先々のカレンダーのGithub Pages上での確認しやすさは今後の課題です。

ネタ帳について

meetup #12 時点ではネタ帳はまだただの単語の羅列で、実現可能性はこれから盛り込んで上げていく感じ。ネタ貯金をみんなに意識してもらえたのは大きな成果かな。割と毎月テーマが後手に回っていろいろ困っていたので。³

自分も手元にはメモがあったりたびたびGistに上げて流したりしてたけど、Wikiを使うという共通理解ができたので今後はそっちにまとめていくつもり。まずはパターン化できるようにいくつかは上げていかないとな。

個人的なチャレンジ

2年目からはもっとコードと内容でリードできるようにしたい。少なくとも

• Rubyらしいコード
• コードリーディング

については

自分でそういうコード書いて公開しちゃえば、ネタには困らない

と思っているし、それが自分には楽しそうなので、もっとコード書きたい。

ちなみに懇親会は

4次会だけ参加した。ひどい。まだもうちょっとこんな感じかなー。

2009-08-24 時点で

• 最新の CentOS 5
• 最新の pecl zip パッケージ 1.10.2

の組み合わせだと build に失敗する。1.8 系の最新である 1.8.10 なら動くのでこれで ok ということにしよう。

※ 2010-06-22 に feed 生成をやめました。今は blog の feed を購読してます。

FreeNAS

先日からちょっと気になっていたことがありまして。それは何かというと、なんでオレ FreeNAS の情報に疎いんだろう？ということなんですが、はたと気づきました。

Feed 購読してねぇ！ てゆーか News の Feed がねぇ！

で、ないものは作ろうと。

ブツはこの上の階層にあります。

FreeNAS News unofficial feed

ここの日記データは毎日昼過ぎくらいにバックアップしてるんですけど、そのとき同時にこの feed を更新することにしました。つまり1日1回。まぁそんなもんでいいかなーと。

※ 本当は最初は Yahoo! Pipes で作ろうと思ったんですよ。自分で feed を更新し続けるのもだるいし、Yahoo! に任せちゃえと思ったんですが、なぜか Fetch Page しても failed to parse non HTML page と怒られまして。試しに validate サービスに掛けると怒られるんで、なんか途中に utf-8 じゃないコードが混ざってるんだろうなぁと思って¹ 自分の手元でやってみることにしました。

で、これの作成に先日から入れ込んでいる yapra を使いました。YAML ファイル（これなんて呼ぶの？）は以下のようになります。

- module: Feed::Custom
  config:
    base_url: http://www.freenas.org/
    url: http://www.freenas.org/index.php?option=com_content&task=category&sectionid=1&id=1&Itemid=24
    extract_xpath:
      capture: //table[@class="contentpane"]
      split: //tr
      raw_date: /td[1]/text()
      title: /td[2]/a/text()
      link:
        first_node: /td[2]/a
        attr: :href
    apply_template_after_extracted:
      title: <%= item.title.strip %>
#      link: <%= (@plugin_config["base_url"] + item.raw_link) if item.raw_link %>
      date: '<%= ( item.link ) ? DateTime.parse( item.raw_date ) : DateTime.now %>'
- module: Filter::grep
  config:
    regex: '[^\s]'
    attribute: link
- module: Filter::EntryFullText
  config:
    extract_xpath:
      raw_content: //table[@class="contentpaneopen"][2]//tr[2]/td/*
    apply_template_after_extracted:
      content_encoded: '<%= ele = Hpricot( item.raw_content ); ele.search( "script" ).remove(); ele.to_html() %>'
- module: RSS::save
  config:
    title: FreeNAS News unofficial feed
    about: http://www.freenas.org/
    link: http://aligach.net/diary/
    filename: /PATH/TO/FEED

ぼくにも EFT できたよ！

でも実は不満があって、気づいた人は気づいたと思いますが、date がうまくセットできんのです。何かの拍子にうまくセットできたときがあったように思うのですが、なんかアレコレいじってるうちに二度とうまくいかなくなってしまいました;_;（レベル低すぎ） 結構いろんなパターンで試したのですが。

いい加減イヤになって、date 待ちで公開しないよりはできた分で公開しちゃうことにしました。

で、これに関係して不安があって。というのも date がセットできない状態で1日1回更新してたら毎回全 item 更新扱いにならんかな？と。ということでまず自分でこの feed を購読して確認してみます。大丈夫そうなら報告します。

こうすれば date セットできるよ！という情報もお待ちしております。というか直したついでに代わりに feed をホストしてくれると大喜びします。

あー疲れた。もっとサクっと作れるようになりたいよ。

[2008-06-25 追記] なんか最新の item が問答無用で更新されたことになってしまう感じがしますね。やっぱちゃんと date 入れないとまずいなー。

できました。しごく単純な話で date に空のもの入れちゃダメってことでした。

今回 Feed::Custom の capture で抜き取った中身（tr, td）には News とそうでないものが混ざっています。だからこそ link と date をいったん別な変数に保存して改めて apply_template_after_extracted で正しい値をセットしているのですが、このとき毎回呼び出される date: <%= %> の中で空のデータをセットしようとする場合があり、そこでコケていました。うーん。

※ これ実は extract_xpath が今の形でなければもっと簡単に書けるんですけど、その話は次回にします。

[2008-09-03 追記]

いつの間にか link に絶対 URI がはまるようになっていたので対応。

[2008-09-06 追記]

content から <script> を除去。どうも spam 対策に script に毎回違うパラメータを埋め込んでメールアドレスを表示していたらしく、その部分の HTML が毎回変化していっつも新着情報として表示されていた模様。

奥が深い。

でも Yapra::Plugin::MechanizeBase を積んだ Yapra は Hpricot でグリグリし放題だから楽ちんだね！ （正規表現だけで正確に <script> だけ除去しろと言われたらイヤだ。）

ECB - Emacs Code Browser

speedbar って初めて使った。

んー。これはー。マウスが使えないとあんまり便利じゃないかも知んない。-nw で使ってると単に複雑な keybind が増えただけで、さほど嬉しくないなぁ。methods のリストアップなんかも、言語の対応具合によって違うような？ 少なくとも手元の PHP のコードは class の中は無視されちゃって使いものにならなかった。mode の問題なのか？ なんかサイトを見てもその辺の理屈がよく分からないんだなぁ。

低価格35mmフルサイズ一眼デジカメ

フルサイズってのは CCD や CMOS などの受光部のサイズが、35mmフィルム1コマのサイズと同じものを言う¹のだが、私はデジタルの一眼はこのフルサイズじゃないと認めないという方針を掲げている。

※ 受光部が大きいと何が嬉しいのかは各自調べるように。

で、Canon から 35万くらいでそんなやつが出たと。今までフルサイズでほしいーーーって思ってた CONTAX のものは 80万以上するので半額以下。が、さすがにまだ高い。許せるのはボディ20万くらいか。もう少し、もう少しだ！

米ソフトメーカー、MS Officeメタデータの危険性を警告 (CNET Japan)

先日も Javaの導師がオブジェクトの所有権について提言 (ITmedia) なんて話があったけど、ファイルの中に余計なデータが入っているのはやっぱ危険だと思うんだなぁ。確かに便利なんだけど、Microsoft はユーザーに意識させない下手な自動化で IE, OE を始め数々のアプリを使いにくく、危険なものにしているって、自覚ないのかな。

もちろん便利なものは嬉しいですけど、メタデータはファイルではなくリポジトリにためる方式を採るべきだったんじゃないかな。リポジトリっていうのは一般には分かりにくいけど、そこをうまく隠蔽するのがソフトメーカーのうまさでしょ。

検索サイト「Ask.jp」β版がオープン (ITmedia)

本家と違って Jeeves(?) の顔色がいいけど、さすがにサービスが全然ないですな。早速試してみると見慣れない検索結果が次々見つかって面白い。

Ask.jp　クイック&スマート検索

from 窓の杜

へー。

Mozilla 関係アプリ伸びてるんだ。でもこの日本語版て、今と同じペースでリリースできるかどうか、Mozilla Japan の方針によって微妙なんじゃないっけ。日本での普及・浸透にはタイムラグのない日本語版のリリースは不可欠だと思うので、日本語版リリースだけを専門に行う人を囲い込んでおくくらいのことをしておいた方がいいと思うなぁ。なんにせよ、ユーザーにようやく認知されつつある Mozilla の今後に少し期待しよう。

逆に Netscape は本家でのリリースを各ニュースサイトが伝えたのが 18, 19日辺り。でも今日現在日本語版はない様子。これが Mozilla なら待ってみるかという気にもなるが、Netscape だと何しとんじゃという気になるから不思議。もう Netscape は少なくとも日本では出る幕ないんじゃないかなぁ。まぁ旧バージョンの価値を下げる意味では新バージョン出てほしいんだけどね。

from CNET Japan

メールだけだとトラブルになりかねないので、対面のコミュニケーションも取ろうね、って話だと思うけど政府が企業に義務付けってのが面白い。ある程度以上の規模の企業は ITC 講習必須にしておかないと業務に支障出まくる可能性もある。そう考えるとこういう措置は有用なのかも。IT 講習免除テストを実施して、免除対象者に臨時ボーナスとかあったらみんな頑張るかも。

個人的にもメールに痛い思い出あります。メールってのは怖いですな。もっとメールソフトにご送信を防ぐ機能を盛り込むべきだと思う。電八にある、送信時にダイアログを表示してアドレスチェック、って機能を搭載しているメールソフトって、他に見たことないんだよなぁ。ああいうのもっと採用されるといいと思うんだけど。

from CNET Japan

一般家庭ユーザーを狙うって。。。家庭で使うには柔軟で使いやすい開発環境（というか設計ツールというか）が要るんじゃないかな。企業ユースよりデータの件数は少ないが分類しにくいデータが増えそうな気がするし、それをあとから変更したい、って事態が多発すると思う。そのとき、現状の PostgreSQL で対応するのは無理があるんじゃないかなぁというのが正直な感想。

SecuLog 経由

SecuLog のこの近辺には PHP カンファレンスネタがちりばめられているので PHP 使いには有用。

個人的には Flash にこんな使い方があったってことが驚き。テキストのコピーができないっぽいけど、この辺までくると PDF 要らないんじゃないかって感じになっちゃうな。

from asahi.com

デジカメより規模がでかいってちょっとすごいのかもしれないと思う反面、本当はもっとでかいんじゃないかという気もしないではない。

自分はもともとこの4分野は漫画以外お金を掛けていないし、その漫画も全然買わなくなったので、消費行動的にはオタクではないのだな。

Rollei MiniDigi だめですわ。。。

完全におもちゃです。いや、スペック的におもちゃだってのは分かってましたが、ツクリもおもちゃです。やはりミニチュアなのです。確かに大きさの割にディティールにこだわっていると思います。でも、

使う道具としてはまったく考えられていません。

あーーーー。ショックだ。。。例えおもちゃのようなスペックでも楽しく撮れるカメラだと思っていたのに。このカメラはまともに使おうとするとソッコー壊れます。間違いありません。飾っておいてたまに遊ぶためのカメラなんてオレは認めねー。これはコレクターと、なんかかわいいしカメラにもなるアクセサリとして捉える人のためのモノです。”道具好き”には向きません。

ちくしょーっ。

しかし今回は自分という人間を知る機会にもなりました。いくらあこがれのブランドでもダメなものはダメとはっきり感じる人間だということが分かりました。特定のブランドを好んでいる自覚はあったのですが、そのブランドならなんでもいいというわけではないようです。まー、その方が自分としては嬉しいんですが。

写りもゆるゆる orz

まーこういう写りを極めればいいのかもしれないし、最初っから割り切れると思っていたのですが…。ニッコール + Tri-X / T-Max で育った自分にはやはりこの緩さはなかなか切ないわけでして。画角が狭いくせにどこにもピントの山がないっていうか、パンフォーカスじゃないよね、これ？ ってゆーなんかスペックと実写のギャップが…。やっぱ写りを期待するにはちっちゃすぎるよな、いくらなんでも。

慣れればかわいいと思えるようになるんだろうけど、もともとアクセサリー好きじゃないので、アクセサリー感覚のカメラが好きになれるかどうか…。遠い道のりを歩む前に売り飛ばすのが賢明だろうか。話のネタには間違いなくなるんだけどねぇ。