blue_field

技術的なメモとか読書記録とかいろいろ（の予定

RubyMotionが楽しい

ここ1ヶ月くらい、RubyMotionを週末にいじりながら、iOS開発の世界に入門しています。これがなかなか楽しい。 （※一応書いておくと、僕はプログラマーとして働き始めて3年目ですが、iOS開発の経験は全くありません）

2年前くらいにXcode + Objective-C を触ったこともあるのだが、Railsを少しかじった程度のエンジニアにとってあの独特な記法はどうしても馴染まず、そのまま挑戦を断念...Xcode（そしてオブシー）に対する謎の苦手意識だけが残った状態でお蔵入りとなってしまった。

で、2014年。さすがにネイティブアプリ全く開発したことないのエンジニアとしてマズいでしょ...みたいな気運が高まり、ここ最近RubyMotionをかじっているという感じです。

ひと通りチュートリアルなどをやって、とりあえず何か作ってみるかーという段階。Pocketに突っ込んだ記事を読むリーダーアプリを試しに書いています。

ysk1031/Pokebu

まだほとんど形になっていないので、リンク貼るのも恥ずかしいくらいだが...

なんでRubyMotionか

なぜObjective-C (Swift) で書いてないのかというと、RubyMotionに対して取っ付きやすさを感じたことが大きい。普段会社でRailsを書いている身としては、Rubyのシンタックスを使ってiOS書けるというのは、大きな魅力として映った。（ちと代金が高いけど、しっかり開発を続けてくれている印象だし、まあしょうがないかな...） あとは、前述の謎の苦手意識も未だにあったｗ

すごく単純な例でアレだが、例えばtableView:numberOfRowsInSection:を比較すると、こんな感じになる。

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return [items count];
}
  • RubyMotion
def tableView(tableView, numberOfRowsInSection: section)
  @items.count
end

RubyMotionしか触れていないので、一般的な開発方法と比較した時のメリット・デメリットみたいなのは良く分からない。以前Rebuildで、伊藤直也さんが「個人で週末にカジュアルな感じでiOS開発をする、というケースにはすごく合っている」みたいなことをおっしゃっていた記憶があるが、それにはすごく賛成です。人それぞれだとは思うが、僕にとってはだいぶ敷居下がる感じがあるし、楽しく書ける。Xcodeとりあえず使わなくても良いし...

Cocoa TouchのAPIは使いこなさきゃいけない

Cocoa Touchの存在は当然無視できない。いくらRuby風に書けてもここは避けて通れないので、適応するしかないようだ。いまのところ右も左も分からないので、「実現したいことをググる => コードが出てくる => ドキュメント眺めて内容を理解する => 書いてみる」、みたいなのの繰り返し。クラス名やメソッド名がいちいち長かったりして、最初はクソ...とか思いながら書いていたが、慣れてくるとそんなに嫌いじゃないことが分かってきた。

AppleのドキュメントがObjective-C (Swift) で書かれているのは当たり前だが、ググって出てくるコードも大半がオブシー。なので、苦手意識はだいぶ薄れた。書くのはまだ難しいと思うが、読むことへの抵抗（ハードルの高さ）は減ってきた気がする。。

エディタとか

RubyMotionに限らず、この数ヶ月はAtom Editorを使ってコードを書くことが多い。RubyMotion用の補完パッケージがあったので、ありがたく利用しています。Cmd + Ctrl + Spaceで補完候補が出る。補完機能ないとさすがに無理すね...

あとはDash.appが便利。RubyMotionのときに限らないが、ドキュメント見るときはこれを使って検索している。VimやEmacsはじめエディタとの連携機能もあるので、買っておいて損はないと思う。

エコシステム

まだ難しいことやってないので、RubyMotion用のgemなどはほとんど使っていない。周辺のライブラリの充実度はどうなんだろう。 また、開発者人口はそんなに多くないと思うので、こういったライブラリ群がちゃんとメンテナンスされているのかな、という疑問もある。iOSのバージョンはどんどん上がっていくし。。

チーム開発で使うという選択肢

これもまだ分からない部分ではあるけど、デザイナーを含めた複数人でチームを組んで開発していくという状況を想定すると、やっぱりXcodeを使った標準的な環境でやっていくのがベターなんだろうな、という予想。StoryBoardもTerminalからコマンド叩けば使えると聞いたけど、ちょっとハードル高いかもしれない。

参考になった記事

読んでみて参考になったRubyMotion関連の記事とかコードとか。

全然見れてないのだが、スクリーンキャストのサイトもあった。
The RubyMotion Screencast - MotionInMotion

おわり

とりとめない感じで書いてしまったが、RubyMotion使ってみての所感でした。いつも使っているエディタで気軽に書き始められる、この点はメリットとしてやはり大きいと思っています。楽しい。

スキル的にまだまだゴミレベルなのが辛いとこだが、とりあえず飽きずに続けられそうなので引き続き学んでこうと思う。最初のうちだけかもしれないけど、rakeしてアプリが意図した動きをしてくれた時はすごく嬉しいｗ

先日Android対応も発表されていましたし、胸アツな感じですね。
Announcing the public Beta of RubyMotion for Android - RubyMotion Blog

'An Inside Look at Google BigQuery'を読んだ

Google BigQueryを使ってみようと思って、最近少し勉強している。Googleがホワイトペーパーを出していたので、読んでみた。（※2012年の文献）

BigQuery についてのホワイトペーパーを公開しました - Google Developer Relations Japan Blog

以下、内容の簡単なメモ。

もともとGoogle社内で利用されていた

Google社内で利用されてきた'Dremel'というサービスがある。巨大なデータに対してSQLライクなクエリを実行すると、数秒で結果が返ってくる。Googleでは、エンジニアだけでなくアナリストなど非エンジニアの人も利用している。

Dremelがベースとなり、外部に公開されたのがBig Query。フルマネージドなクラウドサービス。サードパーティの開発者は、REST APIやCLI, Web UIなどを利用してこのサービスにアクセスすることができる。DremelとBigQueryの根幹のアーキテクチャは同じであり、Dremelのパワーをそのまま享受できる。

とにかく速い

Googleのクラウドプラットフォームを使って、SQLを分散処理してる。数万のサーバー上で同時実行。

どれくらい速いか

具体例。以下のようなSQLを実行

  • 3億行のレコード (35GB) の入ったテーブル (Wikipediaの記事) を特定条件で絞り込み、カウント
  • 条件には正規表現を利用 (記事のタイトルに数字の含まれるもの)
  • テーブルにはインデックスなし

このクエリを10秒で実行 (COUNTの結果は、約2億)。フルスキャンなのに。

スケーラビリティーが高いので、ほとんどのクエリの実行結果を数秒 ~ 数十秒で返す。

なぜ速いのか

下記の2つがその答。

カラム型のデータストア

1行のレコードごとにデータを格納するのではなく、それぞれのレコードの列（カラム）ごとにまとめてデータを格納する。この方法には、以下のメリットがある。

  • トラフィック最小化
    • クエリの対象となるカラムにしかアクセスしないので、トラフィックが最小化できる。SELECT top(title) FROM fooというクエリであれば、titleカラムにしかアクセスしない。
  • 高圧縮率
    • 通常のデータベース (not カラム型) でのデータ圧縮率が1/3なのに対し、カラム型は1/10、という研究結果が出ている。同じカラムに入っている値は似ているケースが多く、ばらつきが小さいため。

一方で、デメリットもある。既に格納済のデータの更新には向いていない。Dremel (BigQuery) でもUPDATEの操作は用意されていない。カラム型のデータストアはread-onlyの用途が向いている。

ツリーアーキテクチャ

root serverがクライアントからクエリを受け取り、その下の多数のleaf serverが処理を実際に実行する。クエリがツリー構造に広がっていくことで、分散処理を実現。

カラム型ストレージとツリー構造については、Dremel: Interactive Analysis of Web-Scale Datasets に詳細な説明があるらしいので、ヒマなときに読む

Google社内でのDremel活用例

2006年から活用している。

  • クロールしたWebドキュメントの分析
  • Androidマーケット (Google Play) でインストールされたアプリのトラッキング
  • Google製品のクラッシュレポート
  • Googleのデータセンターのジョブのモニタリング
  • スパム分析

などなど、様々な用途で利用されている。

BigQuery vs MapReduce

Googleでは長い間、巨大なデータ処理にMapReduceも使っている。（2004年には研究論文も出している）

MapReduceとDremel (BigQuery) の違いは何か。それぞれ以下のようにデザインされている。

MapReduceのメリット

MapReduceでは、'mapper'と'reducer'を実装して分散処理を行い、数百 ~ 数千のサーバ上で同時にバッチ処理を実行できる。スケーラビリティが高く、コスト効率も良い。オープンソース実装であるHadoopは、ログ解析、ユーザー行動分析、レコメンドエンジンやデータマイニングなど様々なケースで利用されている。

MapReduceの制約

巨大なデータの格納されたtableをJOINしてフィルタリング、のような処理を、ある程度の時間で終わらせることのできるMapReduce。従来のRDBで、高いコスト+膨大な実行時間のかかっていた（or そもそも処理できなかった）クエリを、実行可能にした。

しかし、「すぐに実行結果が欲しい」といったユースケースには向いていない。長い処理は数日かかるものもあるし、書いた処理が間違っていたら、それを初めからやり直すことになる。先にも書いたとおり、バッチ処理などに適した形でデザインされているので、アドホックにトライアンドエラーしながらクエリを書いていくのには適していない。

MapReduceとDremel (BigQuery) は同じ分散処理を用いた技術ではあるが、同じ処理でも実行時間に数桁の差異が生まれることがある。

BigQuery, MapReduceそれぞれに適したユースケース

p.8-9の表参照。

BigQueryは、構造化データをSQLを用いて操作するようにデザインされている。カラムの定義や、Google Cloud Storage経由でBigQueryへのデータインポートが必要。SQLの文法が利用でき、シンプルなクエリを実行するのに適している。

MapReduceは、非構造化データをプログラムで処理する際のベターチョイス。どんな種類のデータも扱え、複雑なロジックも適用できる。データマイニングなどに向いてる。

BigQueryに適したユースケース

  • 特定条件のレコード抽出（特定IDユーザーのリクエストログなど）
  • 動的な条件下における統計の素早い集計（サイトの昨晩のトラフィックをサッと出してそれをグラフ化、みたいな使い方）
  • トライアンドエラーを前提としたデータ分析（トラブルの分析や、日次や月次など様々な条件でのデータ集計）

MapReduceに適したユースケース

BigQueryはフルスキャンでがんばる

従来のROLAPやMOLAPと比較して、BigQueryは扱いが楽。インデックスを利用してチューニングをする必要もないし、多次元データベースの設計も不要なので、アドホックにクエリを実行できる。フルスキャンで基本頑張る。

フルスキャンのパフォーマンスは、ディスクI/Oのスループットがキーとなる。スループットの向上にはディスクI/Oの並列化が必要となるが、Googleは、所有するクラウドプラットフォームの規模の経済を効かせて、これを実現している。（身も蓋もない。。。）

例えば、1TBのデータのフルスキャンを1秒以内に終わらせるには、10,000のディスクドライブと5,000のプロセッサが必要だが、Googleさんが持ってるデータセンター使えばそういうのも可能やで、とのこと

値段が安い

クエリ単位の課金 + ストレージの料金。 詳細は公式ページで。

フルマネージドなサービス

Google Cloud Platformを利用するので、運用面はGoogleにお任せ。利用者は、データのインポートだけして、あとは本質的な部分（データの解析etc.）に集中できる。

メモは以上。

おわり

読んでみて、Googleの力技が半端ないことを思い知らされた。完全な力押しサービスである。クエリごとに課金されるので利用料金が予想しにくい点はあるが、相当大きなサービス（データ量）でなければ破産しないはず。。。アクセスログとかアプリケーションのログの解析は、これ使うと楽そうだなと思った。

fluentdのプラグインもあるみたい。
kaizenplatform/fluent-plugin-bigquery

あとは、MapReduceとのユースケースの違いが書かれていて良かった。Hadoop周りも仕事で利用する可能性ありなので、もう少し理解深めねば。Amazon Redshiftも含むユースケースの違いに関しては、以下のブログでまとめてくれていて分かりやすい。
MPP on Hadoop, Redshift, BigQuery - Go ahead!