ククログ

Apache Arrow 0.3.0リリース（翻訳）

Apache Arrowの開発に参加している須藤です。Apache Arrowのコミッターにならない？と打診がきたので、そろそろコミッターになるかもしれません。最近、私以外の人がここに書くことが増えたので、わかりやすいように（？）私が書く時は記名して書くことにします。今回から。

さて、2017年5月8日にApache Arrow 0.3.0がリリースされたのでリリースアナウンスを翻訳します。翻訳記事なので、この記事のライセンスは他の記事のライセンスと違いApache License 2.0です。元の記事の著作権者はApache Software Foundation（ASF）です。リリースアナウンスを書いたのはWes McKinneyさんです。pandasの作者ですね。

Apache Arrowチームは0.3.0のリリースをアナウンスできてうれしいです。2月にリリースした0.2.0から10週間の活発な開発の結果が今回のリリースです。23人のコントリビューターが306個のJIRAのissueを解決しました。

複数のArrowの実装にたくさんの新しい機能を追加しています。2017年、特に注力して開発するのは、インメモリー用のフォーマット、型のメタデータ、メッセージング用のプロトコルです。これは、ビッグデータアプリケーションに安定していてプロダクションで使える基盤を提供するためです。高性能IOとインメモリーデータ処理にArrowを活用するために、Apache Spark・GeoMesaコミュニティーと協力していてとてもエキサイティングです。

それぞれのプラットフォームでArrowを使う方法はインストールページを見てください。（訳注：ここには載っていませんが、私が用意した非公式のAPT/YUMリポジトリーもあります。Apache ArrowだけでなくApache Parquetのパッケージもあります。リリース版ではなく未リリースの最新版のパッケージです。）

Arrowでビッグデータシステムを高速化するケースを増やすために、近いうちにApache Arrowのロードマップを公開する予定です。

Arrowの開発に参加するコントリビューターを募集中です！すでにArrowの開発に参加しているコミュニティーからのコントリビューターもそうですし、まだ参加していないGo、R、Juliaといったコミュニティーからのコントリビューターも募集中です！

ファイルフォーマットとストリーミングフォーマットの強化

0.2.0ではランダムアクセス用とストリーミング用のArrowのワイヤーフォーマット（訳注：データ交換用のフォーマット？）を導入しました。実装の詳細はIPC仕様を見てください。ユースケースは使用例を紹介したブログを見てください。これらのフォーマットを使うと低オーバーヘッド・コピーなしでArrowのレコードバッチのペイロードにアクセスできます。

0.3.0ではこのバイナリーフォマットの細かい詳細をたくさん固めました。Java、C++、Python間の連携のテストおよびそれぞれ言語での単体テストの整備も進めました。Google Flatbuffersは、前方互換性を壊さずにメタデータに新しい機能を追加するのに非常に助かりました。

まだバイナリーフォーマットの前方互換性を必ず壊さないと約束できる状態ではありませんが（もしかしたら変更する必要があるなにかが見つかるかもしれない）、メジャーリリース間では不必要に互換性を壊さないように努力するつもりです。Apache ArrowのWebサイト、各コンポーネントのユーザー向けのドキュメントおよびAPIドキュメントへのコントリビューションを非常に歓迎します。

辞書エンコーディングのサポート

GeoMesaプロジェクトのEmilio Lahr-VivazはJavaのArrow実装に辞書エンコード対応ベクターをコントリビュートしました。これを受けて、C++とPythonでもサポートしました。（pandas.Categoricalとも連携できます。）辞書エンコーディング用のインテグレーションテスト（C++とJava間でこのデータを送受信するテスト）はまだ完成していませんが、0.4.0までには完成させたいです。

これはカテゴリーデータ用の一般的なデータ表現テクニックです。これを使うと、複数のレコードバッチで共通の「辞書」を共有し、各レコードバッチの値はこの辞書を参照する整数になります。このデータは統計的言語（statistical language）の分野では「カテゴリー（categorical）」や「因子（factor）」と呼ばれています。（訳注：日本語での呼び方はあっています？）Apache Parquetのようなファイルフォーマットの分野ではデータ圧縮のためだけに使われています。

日付、時刻、固定長型の拡張

0.2.0では現実に使われている日付・時刻型をインテグレーションテスト付きで完全にサポートすることを諦めました。これらはApache ParquetとApache Sparkとの連携に必要な機能です。

日付: 32-bit（日単位）と64-bit（ミリ秒単位）
時刻: 単位付き64-bit整数（単位：秒、ミリ秒、マイクロ秒、ナノ秒）
タイムスタンプ（UNIXエポックからの経過時間）: 単位付き64-bit整数のタイムゾーン付きとタイムゾーンなし
固定長バイナリー: 決まったバイト数のプリミティブな値
固定長リスト: 各要素が同じサイズのリスト（要素のベクターとは別にオフセットのベクターを持つ必要がない）

C++のArrow実装では、Boost.Multiprecisionを使ったexactな小数のサポートを実験的に追加しました。ただし、Java実装とC++実装間での小数のメモリーフォーマットはまだ固まっていません。

C++とPythonのWindowsサポート

一般的なC++とPythonでの開発用に、パッケージ周りの改良も多数入っています。0.3.0はVisual Studio（MSVC）2015と2017を使ってWindowsを完全にサポートした最初のバージョンです。AppveyorでMSVC用のCIを実行しています。Windows上でソースからビルドするためのガイドも書きました。C++用とPython用。

conda-forgeからWindows用のArrowのPythonライブラリーをインストールできます。

conda install pyarrow -c conda-forge

C（GLib）バインディングとRuby・Lua・他のサポート

Kouhei Sutou（訳注：私です）は新しいApache Arrowのコントリビューターです。Linux用の（ArrowのC++実装の）GLibを使ったCバインディングをコントリビュートしました。GObject IntrospectionというCのミドルウェアを使うことでRuby、Lua、Goや他にも様々なプログラミング言語でシームレスにバインディングを使うことができます。これらのバインディングがどのように動いているか、これらのバインディングをどのように使うかを説明するブログ記事が別途必要な気がします。

PySparkを使ったApache Sparkとの連携

SPARK-13534でApache Sparkコミュニティーと協力しています。PySparkでのDataFrame.toPandasをArrowを使って高速化しようとしています。効率的なデータのシリアライズにより40倍以上高速化できるケースがあります。

PySparkでArrowを使うことでこれまでできなかったパフォーマンス最適化の道が開けました。特に、UDFの評価まわりでいろいろやれることがあるでしょう。（たとえば、Pythonのラムダ関数を使ってmap・filterを実行するケース。）

Python実装での新しい機能：メモリービュー、Feather、Apache Parquetのサポート

ArrowのPythonライブラリーであるpyarrowはlibarrowとlibarrow_pythonというC++ライブラリーのCythonバインディングです。pyarrowはNumPyとpandasとPythonの標準ライブラリー間のシームレスな連携を実現します。

ArrowのC++ライブラリーで最も重要なものはarrow::Bufferオブジェクトです。これはメモリービューを管理します。コピーなしの読み込みとスライスをサポートしている点が重要です。Jeff KnuppはArrowのバッファーとPythonのバッファープロトコルとmemoryviewの連携処理をコントリビュートしました。これにより次のようなことができるようになりました。

In [6]: import pyarrow as pa

In [7]: buf = pa.frombuffer(b'foobarbaz')

In [8]: buf
Out[8]: <pyarrow._io.Buffer at 0x7f6c0a84b538>

In [9]: memoryview(buf)
Out[9]: <memory at 0x7f6c0a8c5e88>

In [10]: buf.to_pybytes()
Out[10]: b'foobarbaz'

C++でのParquet実装であるparquet-cppを使うことで大幅にApache Parquetサポートを改良しました。たとえば、ディスク上にあるかHDFS上にあるか関係なく、パーティションされたデータセットをサポートしました。DaskプロジェクトはArrowを使ったParquetサポートを実装した最初のプロジェクトです。Dask開発者とはpandsデータを分散処理する文脈でさらに協力できることを楽しみにしています。

pandasを成熟させるためにArrowを改良することもあり、Featherフォーマットの実装をマージしたのもその1つです。Featherフォーマットは本質的にはArrowのランダムアクセスフォーマットの特別なケースの1つです。ArrowのコードベースでFeatherの開発を続けます。たとえば、今のFeatherはArrowのPythonバインディングのレイヤーを使うことでPythonのファイルオブジェクトを読み書きできるようになっています。

DatetimeTZやCategoricalといったpandas固有のデータ型のちゃんとした（robust）サポートも実装しました。

C++ライブラリーでのテンソルサポート

Apache Arrowはコピーなしで共有メモリーを管理するツールという側面があります。機械学習アプリケーションの文脈でこの機能への関心が増えています。UCバークレー校のRISELabのRayプロジェクトが最初の例です。

機械学習ではは「テンソル」とも呼ばれる多次元配列というデータ構造を扱います。このようなデータ構造はArrowのカラムフォーマットがサポートしているデータ構造の範囲を超えています。今回のケースでは、arrow::TensorというC++の型を追加で実装しました。これはArrowのコピーなしの共有メモリー機能を活用して実装しました。（メモリーの生存期間の管理にarrow::Bufferを使いました。）C++実装では、これからも、共通のIO・メモリー管理ツールとしてArrowを活用できるようにするため、追加のデータ構造を提供するつもりです。

JavaScript（TypeScript）実装の開始

Brian HuletteはNodeJSとWebブラウザー上で動くアプリケーションで使うためにTypeScriptでのArrowの実装を始めました。FlatBuffersがJavaScriptをファーストクラスでサポートしているので実装が捗ります。

Webサイトと開発者用ドキュメントの改良

0.2.0をリリースしてからドキュメントとブログを公開するためにWebサイトのシステムをJekyllベースで作りました。Kouhei Sutou（訳注：私です）はJekyll Jupyter Notebookプラグインを作りました。これによりArrowのWebサイトのコンテンツを作るためにJupyterを使うことができます。

WebサイトにはC、C++、Java、PythonのAPIドキュメントを公開しました。これらの中にArrowを使い始めるための有益な情報を見つけられるでしょう。

コントリビューター

このリリースにパッチをコントリビュートしたみなさんに感謝します。（訳注：上から2番目が私です。）

$ git shortlog -sn apache-arrow-0.2.0..apache-arrow-0.3.0
    119 Wes McKinney
     55 Kouhei Sutou
     18 Uwe L. Korn
     17 Julien Le Dem
      9 Phillip Cloud
      6 Bryan Cutler
      5 Philipp Moritz
      5 Emilio Lahr-Vivaz
      4 Max Risuhin
      4 Johan Mabille
      4 Jeff Knupp
      3 Steven Phillips
      3 Miki Tebeka
      2 Leif Walsh
      2 Jeff Reback
      2 Brian Hulette
      1 Tsuyoshi Ozawa
      1 rvernica
      1 Nong Li
      1 Julien Lafaye
      1 Itai Incze
      1 Holden Karau
      1 Deepak Majeti

以上が0.3.0のリリースアナウンスです。Apache Arrowを使いたくなってきましたか？

Apache Arrowに興味が出てきた人は今月（2017年5月）次のイベントでApache Arrow関連の話題があるのでぜひ参加してください。

Apache Arrow関連のイベントを開催したい！という方は私（@ktou）に相談してください。Apache Arrowがデファクトスタンダードになって開発に参加する人がもっと増えるといいなぁと思っているので一緒に協力してやっていきたいです。

2017-05-09

redmine.tokyo第12回勉強会：GroongaでRedmineを高速全文検索 #redmineT

須藤です。開発しているRedmineのプラグインはWiki Change NotifierとJournal Change Notifierです。

2017年5月13日にredmine.tokyo第12回勉強会が開催されました。ここでGroongaを使ってRedmineを高速全文検索するプラグインを紹介しました。

redmine.tokyoのこれまでの勉強会の資料を見てもわかるとおり、Redmineはよく作られたプロダクトです。ただ、全文検索処理には速度面・制度面で課題があり、それを解決し、Redmineの弱点を克服するのがこのプラグインです。今回の発表では、現在のRedmineの弱点を克服するだけでなく、むしろ検索を強みにするにはどうすればよいかという話もしました。たとえば、Redmine内の情報から機械学習で有用な情報を抽出し、それを活かした検索をすることでこれまでより効率よくRedmineを使えるようにする、といった具合です。このあたりに取り組むためには検索技術・データ分析技術・分析対象のデータ・開発費用などが必要です。すでにRedmineを活用していて大量の情報を保存している方で、Redmineをさらに活用することに興味のある方はご連絡ください。一緒にRedmineのさらなる活用に取り組みましょう。

GroongaでRedmineを高速全文検索

関連リンク：

内容

この発表では次のことを紹介しました。

Redmineの全文検索をマイナスから少しプラスへ
Redmineの全文検索を少しプラスからすごくプラスへ
Redmineの開発に参加しよう

Redmineの全文検索をマイナスから少しプラスへ

Redmineはプロジェクト管理に使われるため、Redmineにはプロジェクトの情報がたくさん入っています。Redmineを活用し続ければ続けるほど増えていきます。Redmine内の情報を有効活用できればさらに効率よくプロジェクトに取り組めます。たとえば、過去の類似のバグレポートを参照することで新規のバグをすぐに解決できる、といった具合です。Redmineの情報を有効活用するために重要なのが全文検索です。

たくさんの情報の中には、重要な情報もありますが、雑多な情報もあります。そのため、単に全文検索しただけで重要な情報が見つかるわけではありません。雑多な情報もヒットしてしまい、それが重要な情報を隠してしまうからです。現在のRedmineの全文検索は重要な情報も雑多な情報も一緒くたに扱っているため、重要な情報を見つけにくくなっています。これが課題の1つです。

重要な情報を見つけやすいかどうか以前にそもそも速く検索できるかどうかも重要です。重要な情報を見つけやすかったとしても検索結果を表示するまでに時間がかかっていれば（たとえば10秒とか）使いやすくありません。検索キーワードを試行錯誤することも難しいですし、同時に複数の人が検索することもままなりません。これが現在のRedmineの全文検索のもう1つの課題です。

Redmineを高速全文検索するプラグインを使うと、大量のデータが入っていても高速（1秒以内）に重要なものを見つけやすくなります。

速度面においては、200万チケットがあるRedmineでも380msで検索できます。（従来は1時間以上かかっていたケース。）

重要なものを見つけやすくするという観点では、ヒットした内容それぞれにどれだけキーワードにマッチしていそうかの度合いをつけて、それを使ってマッチしていそうなものから提示します。これにより最初の10件程度を確認するだけで重要なものを見つけることができます。

実は、このような全文検索機能は「全文検索システム」という文脈では普通のことです。そのため、これらを実現したのはRedmineの全文検索機能をマイナスから少しプラスにした、という程度のことです。しかし、これだけでもずいぶんRedmineの検索は使いやすくなります。検索が使い物にならなくて使っていなかったという方は、ぜひこのプラグインをインストールして検索してみてください。今度はもっと活用したくなるはずですよ。

Redmineの全文検索を少しプラスからすごくプラスへ

高速・高精度の全文検索を実現するために全文検索エンジンという専用のモジュールがあります。全文検索エンジンというと「キーワードを入力して検索する」ことだけを頑張っていると思っている人が多いかもしれません。しかし、実は、検索を軸にしてもっとたくさん便利にできます。

現在のプラグインは、まだ単に高速・高精度で全文検索できるようにしているだけですが、今後はもっとRedmineを活用できるように育てていきたいです。いくつかそのアイディアを紹介します。クリアコードだけでなく、もっとRedmineを活用したい人たちと協力しながら実現したいです。実現した成果はRedmineと同じくフリーソフトウェアとして多くのRedmineユーザーが利用できるようにします。実現案も簡単に説明するので、興味のある方（実装したい方、データを持っている方、開発費を払ってでも実現したい方）はぜひご連絡ください。

類似issue検索

1つめのアイディアはissue作成時・閲覧時に自動で類似issueを提示する機能です。新しい問題が発生したときに、プラグインが類似issueを提示することで既存のノウハウを活用して早期に問題を解決できます。

類似issue検索の実現案を説明します。issueのテキストを使った類似文書検索（全文検索エンジンGroongaの標準機能）を軸に、Redmine内のメタデータを活用することで精度をあげます。メタデータとは手動で設定した関連issue情報やWiki内のテキストから機械学習した類義語情報などです。

入力補完

2つめのアイディアは入力時に適切な値を随時ユーザーに提示する機能です。たとえば、検索ボックスでキーワードの一部を入力するだけでキーワード全体の補完候補を提示します。これにより、ユーザーの入力コストを下げるだけでなく、適切なキーワードに自然と誘導することになるので、より見つかりやすい検索を実行できます。Groongaは日本語に特化した機能を組み込みで提供しており、ローマ字から日本語を入力補完することもできます。これを使うと「tok」（日本語入力OFFの状態で入力）から「東京都」を補完候補に出すこともでき、よりユーザーの入力コストを下げることができます。

検索というと見つけるためだけに使うというイメージがあるかもしれませんが、入力時にも有用です。タイトルやバージョンなどの入力欄で入力候補を提示することにより、入力内容の表記揺れ・表現の揺れが自然と少なくなります。表記揺れ・表現の揺れが少ないと全文検索エンジンもうれしいですが、理解しやすくなるので読む人もうれしいです。より活用しやすいデータということです。

入力補完の実現案を説明します。Groongaに前方一致検索（ローマ字変換対応）があるので、それを活用します。単に候補を提示するだけでは使いやすいものになりません。候補の最初の方に必要なものが提示されている必要があります。精度も大事ということです。精度をあげるために、全文検索用のインデックスの統計情報を活用します。たとえば、あまりにもヒットしすぎるようなキーワード（たとえば「です」とか）は適切ではありません。統計情報を活用してそのような不要なキーワードを除去します。また、ログやメタデータも活用します。文脈（プロジェクトやトラッカーなど）毎に候補に提示するリストを調整し、より精度の高い候補を提示します。

同義語展開

3つめのアイディアは同義語管理を支援する機能です。日本語では同じものをいろんな呼び方で示すことができます。たとえば、「ネジ」も「ねじ」も「ボルト」も同じものを指します。検索精度を高めるにはこのような同義語に関する情報が必要です。しかし、同義語の管理は大変です。たくさんありますし、文脈が違えば同義語のリストも変わるため共有することが難しいからです。

同義語のリストがあればGroongaが組み込み機能で提供している同義語展開機能を利用できます。検索部分に問題はありません。同義語管理がネックなのです。

同義語管理支援の実現案を説明します。同義語を自動で完璧に整備するのは難しいですが、人の作業を大幅に削減する支援ならできます。そこを狙います。Redmine内には大量のテキストデータがあるはずなので、機械学習で同義語候補を自動で抽出します。また、同義語を管理するUIも実装し、より人の作業を減らします。

スマートナビ（仮）

4つめは「言わなくても欲しいものを提示する機能」です。駅の近くでスマートフォンを見ると、その駅の時刻表を「自動で」表示していませんか？そのように、現在のユーザーの状況から欲しそうなものを自動で検索して提示する機能です。

共同開発者募集

もっとRedmineを活用できるようなアイディアをいくつか紹介しました。クリアコードだけでなく、もっとRedmineを活用したい人たちと協力しながら実現したいです。実現した成果はRedmineと同じくフリーソフトウェアとして多くのRedmineユーザーが利用できるようにします。実現案も簡単に説明するので、興味のある方（実装したい方、データを持っている方、開発費を払ってでも実現したい方）はぜひご連絡ください。

Redmineの開発に参加しよう

Redmineの開発に参加したいとは思っているけどなかなか実現できていない、という方はいませんか？そんな方にオススメなのがOSS Gateが開催しているイベントです。OSS Gateは「OSSの開発に参加する人を継続的に増やす取り組み」です。OSS GateではOSSの開発に参加する人をサポートするイベントを開催しています。RedmineもOSSなのでこのイベントでサポートしてもらいながらRedmineの開発に参加できます。最初の一歩をなかなか踏み出せていない、という人は活用してください。

東京では5月は22日（月）と27日（土）にイベントが開催されます。

大阪と札幌でも開催しています。（redmine.tokyo第12回勉強会には日本各地から参加者がいたので東京以外の情報も紹介しました。）

まとめ

redmine.tokyo第12回勉強会で、Groongaを使ってRedmineの全文検索機能を高速化するプラグインを紹介しました。現時点でできることだけでなく、今後の野望とRedmineの開発に参加したい人向けの情報も紹介しました。

Redmineのデータをもっと活用してより効率的に仕事を進めたくて、検索技術・データ分析技術・分析対象のデータ・開発費用を持っている方はご連絡ください。一緒に実現しましょう。

この記事の続き

2017-08-27: Redmine大阪第17回勉強会 - 全文検索でRedmineをさらに活用！ #RedmineOsaka

2017-05-15

OSS開発支援サービス事例：SpeeeさんのWebapp Revieee

OSS開発支援サービスの主な担当者の須藤です。クリアコードではOSS開発支援サービスを提供しています。2017年の1月から4月までSpeeeさんが開発しているOSS「Webapp Revieee」の開発を支援していました。すごくよい時間になったと思っているので、支援の中で得られた知見を紹介します。「自分たちも支援して欲しい！」と思った人はご相談ください。「支援して欲しいけど自分たちはまだ力不足な気が…」と思った人はOSS Gateを見てみてください。Speeeさんも最初はOSS Gateワークショップに参加しました。

Webapp Revieeは開発支援ツールです。GitHubにpull requestを作るとそのpull requestをレビューするためのWebアプリケーションを自動で用意します。pull request毎に手元に動作確認用の環境を用意する必要がないのでレビューが捗ります。詳細はSpeeeさんのWebapp Revieeeの解説記事を参照してください。来週火曜日（5月23日）開催のSpeee Cafe Meetup #07でもWebapp Revieeeの話があるので、興味のある方はこちらのイベントに参加してみてください。私も参加してOSS Gateの紹介をする予定です。

支援内容

支援にあたり、最初にどういうことを大事にしていきたいかを話し合いました。組織によって大事にしたいポイントは異なるので、より充実した支援内容にするための大事なステップです。Speeeさんの場合は次の2つの両立を大事にすることになりました。

Webapp Revieeeの開発スケジュールを守る
OSSのエコシステムに参加する

両立が大事なので、たとえば、「OSSのエコシステムにたくさん参加したけどその分開発が遅れた」はダメですし、「開発は順調に進んだけど、OSSのエコシステムには全然参加できなかったね」もダメです。

「OSSのエコシステムに参加する」ってどういうことだろう？ということも最初に話し合いました。曖昧なままだと進めていく中で判断基準に使えないからです。話を聞いてみると「自分たちが開発したものをOSSとして公開するとか？他はどういうことがあるだろう。」という感じでなんとなくイメージはあるけど説明しようとするともやっとする感じでした。そこで、私ならどう説明するかを紹介しました。

私なら「OSSのエコシステムに参加する」は「自分たちが開発したソフトウェアもオープンソースのソフトウェアも同じように扱う」と説明します。問題があったら直すし、気になったことがあったらフィードバックします。そっちのソフトウェアに問題があるけど自分たちが開発していないソフトウェアだから自分たちが開発しているソフトウェアの方に回避策を入れてしのごう、といったことを「しない」ということです。

今回は私の説明をベースに私たちのイメージを固めました。

大事にすることを共有した後は支援方法を決めました。次の2つで支援することになりました。

Webapp Revieeeのpull requestのレビュー（随時・オンライン）
月に1度のふりかえり（オフライン）

pull requestのレビューは、一般的な目的であるコードや設計の品質向上もそうですが、それだけでなく、OSSとして開発するならこういうことを考えて開発するといいですよ、ということを具体的な事例付きで紹介することも狙って実施しました。

月に1度のふりかえりは、この1ヶ月で得られたことをより定着させることと見つかっている課題に早めに対策を実施することを狙って実施しました。

支援結果

支援した結果、支援した側の私からはすごくよい時間になったと感じているので、私視点でどう感じたかをまとめます。

Webapp Revieee開発中に利用しているOSSを改良した。
- 「OSSのエコシステムに参加する」の実践。
- これにより開発スケジュールが遅れるということなかった。
  - 補足：バランスをとれたという事実を体験できたことがよかった。ケースによっては遅れてしまうような進め方になってしまうこともあるだろうけど、バランスをとれることもあることを知っていれば、「OSSのエコシステムに参加しながら開発を進めるにはするにはどうしたらよいか？」を考えていけるはず。
Webapp RevieeeをOSSとして開発することで開発者（天野さんと森岡さん）の開発力があがった。
- 要因1：いろいろな人から見られる可能性を考慮することがよいプレッシャーとなりよいコード・コミットにつながった。
  - 補足：最初は「こんなコミットメッセージで十分？もっと書いた方よい？」などと迷っていた部分もあったが、何度か具体的に「今回のコミットはこのコミットメッセージで十分！」などと一緒に確認していったことで自信につながった。
  - 補足：「ちゃんとレビューする人」として私がレビューしていたので「見られている感」を維持できたのもよいプレッシャーにつながった。
- 要因2：私のレビューにより、よいコード・よい設計・よいコミットの基準が言語化され開発しやすくなった。
  - 補足：単に「いいですね！」とか「なんかもやっとしますね…」だけを伝えるだけでなく、「○○で△△なのでいいですね！」とか「××なケースでこうなるのでもやっとするんですよねぇ…」というように具体的になにがよいか、なにがもやっとするかを説明した。
  - 補足：実際の私のコメント内容はクローズされたpull requestのやりとりを参照。
- 要因3：よいコード・よいコミットを意識して開発しても開発速度は落ちないことがわかった。
  - 補足：落ちそうなイメージがあるが、実際にやってそんなことはないと経験できたことがよかった。落ちないので今後も継続していける。
私のコードレビューのやり方からよいところを学び、業務の開発に活かせた。
- よいところ1：よいところをよいと明言する。
  - 補足：よいところは問題がないのでコメントしない、ではなく、よいと認識してもらって強化する。
- よいところ2：言葉での説明だけでなく具体的なコードもつける。
  - 補足：意図が伝わりやすくなる。
- よいところ3：「もやっと」したことも伝える。
  - 補足：「もやっと」は使いやすいフレーズだそう。私はあまり意識せずに「もやっと」を使っていたので、ふりかえりのときにこの話を聞いて「そうだったの！？」とびっくりした。
- ↑を業務での開発でのレビュー時に実践したところ、開発メンバーがよいコード・よいコミットを書くようになってきたとのこと。
- この「OSSを開発することで業務の開発もよくなる」状態はSpeeeさんが目指している状態の1つだと思うので、すごくよかった。
OSSを新規に開発してリリースする、という一連の流れを体験したことで、自分たちでOSSを開発することの流れがわかった。
- 言葉での説明ではなんとなくしかわかっていなかったとのこと。
- 体験したことでぐっと敷居がさがったとのこと。
  - 補足：「体験することで敷居がさがる」はOSS Gateワークショップで実践している知見だったのに、「OSSを新規に開発してリリースする」ときにも効くとは気づいていなかったので勉強になった。

月に1回オフラインのふりかえりを設定したのは私にとってもすごくよかったです。Webapp Revieeeを開発していたおふたり（天野さんと森岡さん）からすごくよいフィードバックをもらえました。ふたりとも自分がどう考えているか、どう感じているか、これからどうしたらよさそうかをすごくよく話してくれるので、すごくやりやすかったですし、話を聞いて気づいたことがたくさんありました。ありがとうございました。

まとめ

OSS開発支援サービスの事例として2017年1月から4月に支援したSpeeeさんの事例を紹介しました。私はすごくよい時間になったと思っているので、私視点でどこがよかったかをまとめました。Speeeさんにとってもよい時間になったことを期待しています。

今回の支援中に開発していたWebapp RevieeeはOSSとして公開されています。詳細はSpeeeさんのWebapp Revieeeの解説記事を参照してください。来週火曜日（5月23日）開催のSpeee Cafe Meetup #07でもWebapp Revieeeの話があるので、興味のある方はこちらのイベントに参加してみてください。

今後もOSS開発支援をしていきたいので、「自分たちも支援して欲しい！」と思った人はご相談ください。「支援して欲しいけど自分たちはまだ力不足な気が…」と思った人はOSS Gateを見てみてください。

この記事の続き

2017-05-17

DataScience.rb ワークショップ〜ここまでできる Rubyでデータサイエンス〜：RubyもApache Arrowでデータ処理言語の仲間入り #datasciencerb

須藤です。最近気になるApache Arrowのissueは[ARROW-1055] [C++] Create add-on library for CUDA / GPU integrationです。

2017年5月19日に開催されたDataScience.rb ワークショップ〜ここまでできる Rubyでデータサイエンス〜で「RubyもApache Arrowでデータ処理言語の仲間入り」という話をしました。このイベントはしまねソフト研究開発センタースポンサーのプロジェクトとRubyアソシエーションスポンサーのプロジェクトの成果発表会のような位置付けだと思うのですが、私がApache Arrowの紹介をしたいと言ったので、それらとまったく関係のないApache Arrowの話をねじ込んでもらいました。ありがとうございます。

RubyもApache Arrowでデータ処理言語の仲間入り

関連リンク：

内容

Ruby界隈ではApache Arrowのことを知っている人はあまりいないはずです。その前提で、私の発表ではApache Arrowがなにを目指しているプロジェクトで、現状はどうなっていて、今後はどうなる予定か、ということを紹介しました。

詳細はスライドを参照してもらうとして、ざっくりいうと次のような感じです。

Apache Arrowが目指していること：
- 低いデータ交換コスト
- 最適化されたデータ処理実装の共有
Apache Arrowの現状：
- 「低いデータ交換コスト」の方はプロダクションで使えそうなくらいになっている
- 「最適化されたデータ処理実装の共有」の方はこれから
- Java、C++、Python、Ruby、Lua、Go、JavaScript間で低コストでデータ交換できる
Apache Arrowの今後：
- Apache Arrowを使ったデータ交換の推進（たとえば、SparkとPySpark間でのデータ交換にApache Arrowを使う変更がマージされて現実に使っていく。似たようなことをいろいろなプロジェクトで進めていく。）
- 最適化されたデータ処理実装の提供
- Apache Arrow対応言語の増加

どうしてRubyがApache Arrowに対応するとデータ処理できるようになるかを説明するために、まず、Apache Arrowがでてきた背景を説明します。

現在の（ビッグデータの）データ分析システムは1つの大きなソフトウェアでなんでもかんでも全部やるというやり方ではなく、複数のシステムが協調してデータ分析するというやり方になっています。たとえば、データの管理はHadoopでデータの分散処理基盤はSparkでユーザーがカスタマイズする部分はPythonで、といった具合です。

複数のシステムが協調するためには分析対象のデータを相互にやりとりする必要があります。データが大量にあるのでデータ交換のコストがどのくらいかは重要です。コストが高いと本来やりたかったデータ分析処理に時間を使えずにデータ交換ばかりに時間を使ってしまうからです。現状はコストが高くてそのような状況になりがちでした。それを解決するためにでてきたのがApache Arrowです。

Apache Arrowはデータのシリアライズ・デシリアライズコストをほぼ0にします。そのため、データ交換のコストの多くはデータの送受信くらいになります。別マシン間でのやりとりであればネットワーク上での通信処理、同一マシン間でのやり取りであればメモリー上へのデータの読み書き処理が主なコストになるので、かなり高速です。

データ交換コストが低くなると、データ分析システムの一部にRubyを使いやすくなります。これまでは、データ交換コストが高いので、できるだけサブシステム間でのデータ交換を減らしたくなりましたが、コストが低いとカジュアルにデータ交換できます。そうすると、「この処理はRubyが得意だからこの処理だけRubyでやろう」ということがしやすくなります。Rubyでできることが増えていくともっとRubyの活躍の場が増えます。

RubyがApache Arrowに対応するとRubyにデータが回ってくるようになるのでデータ処理できるようになるということです。

というのが私の目論見ですが、このようになるといいなぁと思ってRubyでApache Arrowを使えるようにする作業を進めています。現在の状況は次の通りです。

Apache ArrowはRubyを公式サポート
- 私が開発した成果はApache Arrow本家に取り込まれました。継続的な活動を認められてコミッターにもなりました。
RubyからApache Parquet・Apache Arrow・Feather形式のデータを読み書き可能
- Apache ParquetはHadoop界隈でよく使われている形式です。Hdoop方面のデータを読み書きできるということです。Apache ArrowのC++実装とApache ParquetのC++実装が連携しているので、それらの成果を利用しています。
- FeatherはR界隈でよく使われている形式です。Rで処理したデータをRubyで読み込んだり、Rubyで収集・加工したデータをRに渡したりできます。
Apache Parquet・Apache Arrow・Feather形式のデータとRuby/GSL、NMatrix、Numo::NArrayのデータを相互変換可能
- Ruby/GSL、NMatrix、Numo::NArrayはRuby用の行列演算ライブラリーです。読み込んだデータをこれらのライブラリーのオブジェクトに変換すればそれらの機能でデータを処理できます。
- サンプルコードはkou/rabbit-slide-kou-data-science-rb/sample/にあります。
Apache Arrow形式のデータとGroongaのデータを相互変換可能
- Groongaは集計機能も得意な全文検索ライブラリーです。RubyにはよくできたGroongaのバインディングがあるので、Groongaを使って高速にデータ処理することができます。たとえば、ログメッセージを全文検索して対象のログを絞り込んだり、全文検索インデックス内の統計情報を活用して重要語のみを抽出したりできます。
- GroongaはApache Arrowに対応している（Groonga自体にApache Arrow形式のデータを読み書きする機能がある）ので、Rubyを経由せずに相互変換できて高速です。

今後ですが、1人でやっていては限界があるので、Red Data Toolsプロジェクトとして「Rubyでデータ処理したい！」という人たちと一緒に活動していく予定です。このプロジェクトは次のようなポリシーで活動していくので、賛同できる人はぜひ一緒にRubyでデータ処理できるようにしていきましょう！参加する人はチャットで参加表明してください。なにから着手するか相談しましょう。

Rubyコミュニティーを超えて協力する

私たちはRubyコミュニティーとも他のコミュニティーとも協力します。たとえば、私たちは多くの言語が共通で使っているApache Arrowを使いますし、Apache Arrowの開発に参加して開発成果を共有します。

非難することよりも手を動かすことが大事

私たちは現状（RubyよりもPythonの方がたくさんよいツールが揃っているかもしれません）や既存ライブラリーの実装を非難することなどに時間を使うよりも、コードを書いたりテストをしたりドキュメントを書いたり私たちの活動を紹介したり他のプロジェクトにフィードバックをしたりといったことに時間を使います。

一回だけの活発な活動よりも小さくてもいいので継続的に活動することが大事

Rubyでたくさんのデータ処理をできるようになるために私たちはたくさんやることがあるかもしれません。データ処理のためのすばらしいツール群一式を揃えるために継続的に活動する必要があります。そのため、1回だけの活発な活動よりも継続的な活動の方が大事です。

現時点での知識不足は問題ではない

私たちは高速なツールを実装するために数学や統計学や線形代数学などの知識が必要かもしれません。しかし、このプロジェクトに参加する時点でそれらの知識は必須ではありません。なぜなら活動をしていく中で学んでいくことができるからです。私たちは既存の高速な実装を使ったり、既存の高速な実装から学んだりすることができます。

部外者からの非難は気にしない

私たちがデータ処理のためのすばらしいツール群一式を揃えるまでに時間がかかるかもしれません。そうなるまでは部外者が私たちの活動を非難するかもしれません。私たちはそれらを気にしません。私たちにはそれらを処理している時間はありません。 :-)

楽しくやろう！

Rubyを使っているんですから！

まとめ

Rubyでデータ処理できるようになるために役立ちそうなApache Arrowの紹介と現在できることを紹介しました。また、これからさらにRubyでデータ処理できる状況を推進していくために、Red Data Toolsプロジェクトを立ち上げました。Red Data Toolsプロジェクトに参加する人はチャットで参加表明してください。

「Rubyでデータ処理できるようにしよう！」活動を推進するために、開発費を提供するという方法もあります。手は動かせないけどお金は出せるという方はご連絡ください。

Apache Arrowは去年のはじめに始まったばかりの新しいプロジェクトなので、まだまだ知らない人も多いはずです。Apache Arrowが早く広まってデファクトスタンダードになると「Rubyでデータ処理」という文脈でもうれしいので、Rubyに関係あろうがなかろうが、Apache Arrowのイベントを開催したい場合はぜひお声がけください。日本でのApache Arrowの第一人者（？少なくともApache Arrowの日本人コミッター第1号）として協力できるはずです。

ちなみに、今度の日曜日（2017年5月28日）に大阪でApache Arrowオンリーイベントがあります。関西在住の方はぜひお越しください。現時点で定員オーバーですが、これからキャンセルが増えると思うので参加できるのではないかと思います。

この記事の続き

2017-06-12: データ分析用次世代データフォーマットApache Arrow勉強会（大阪） #osaka_arrow

2017-05-22

Fluentd v0.14 API移行のすすめ

クリアコードではFluentd本体の開発だけでなくFluentdの600以上あるプラグインの開発にも参加しています*1。具体的にどういうことをやっているかは過去の記事を参照してください。

FluentdのプラグインをFluentd v0.14 APIに移行するための記事がいくつかあります。

具体的な移行方法についてはそれぞれの記事で解説しましたが、肝心のFluentd v0.14 API移行のPros/Consを説明していませんでした。この記事ではプラグイン開発者視点でFluentd v0.14 APIへの移行について扱います。既に稼働しているFluentdをv0.14へ移行することについては扱いません。

Pros

洗練されたプラグインAPIを使うことでメンテナンスしやすいプラグインを開発することが可能
non-buffered/buffered/async な output プラグインを1つのファイルで開発できる
non-buffered/buffered/async な output プラグインを設定ファイルで切り替えできる
便利なプラグインヘルパーによってコードの見通しがよくなる
簡単に使える本物のテストドライバーによって、メンテナンスしやすいテストコードを書くことができる
組み込みのマルチプロセスサポート
bufferのchunkの分け方を柔軟に指定できる
- タグごとにchunkを分ける
- 時間ごとにchunkを分ける
- chunkに含まれる任意のレコードごとにチャンクを分ける
storageプラグインのAPIが追加され、プラグインの状態を管理する汎用的な機構が備わった

Cons

新APIは後方互換性がないので、基本的には全部書き直しが必要
- ただし、Fluentd v0.14には互換レイヤーがあるので、移行しなくても基本的にはそのままで動作する
テストコードは全面的に書き直しが必要
- Fluentd本体ではtest-unitを使用してテストコードを書いているので本体のテストコードを見ればどう書けばよいかわかる
Fluentd v0.14 API に移行すると Fluentd v0.12 以前でも動くようにするのは不可能*2

まとめ

Fluentd v0.14 APIに移行するPros/Consをまとめてみました。既に多くのプラグインがFluentd v0.14のAPIに移行済みです。最近は、最初からFluentd v0.14のAPIを使用している3rdパーティのプラグインも見かけるようになりました。

まだ移行していないプラグイン作者の方はtd-agent3が正式リリースされる前に、自分たちのプラグインをFluentd v0.14 APIに移行するとよいのではないでしょうか。

*1 すべてではありません

*2 Fluentd v0.10.x と Fluentd v0.12.x はプラグイン開発者が少しコードを追加することでFluentd v0.10.xとFluentd v0.12.xのどちらでも動くようにできた

2017-05-23

Fluentd v0.14のEventTimeに関する話

はじめに

Fluentd v0.14ではログをmsgpackでエンコードし、新たに時間をForwardプロトコルで送る際に時間をEventTimeへエンコードして送信することができるようになりました。このエンコード形式を用いて時間をForwardプロトコルで送るようにすると、秒よりもさらに細かな精度でログのやりとりができるようになります。 Fluent Loggerでログを送る際に、一秒間に２つ以上のログが発生する環境で秒精度までのログ転送を行った場合、Fluentdが扱うログの順番が送り先で発生した順ではなくなることがあります。そのため、ログの順番をより正確に時刻でソートするために考えられたv0.14で新たにログの時刻の形式として秒精度以下も扱えるEventTimeが追加されました。

EventTime

Forwardプロトコルのv1の仕様にEventTimeについての解説があります。

仕様を見ると、EventTimeはmsgpackの拡張型として表されることがわかります。また、fixext8とext8のどちらの場合でも秒とナノ秒は32bit integerで表し、msgpackへエンコードする必要があります。 fixext8形式は実行時に長さを取る必要がないので、構造体を直にEventTimeへエンコードする使い方をすると実行時のことを考えなくてもよくなります。

fruentlyではfixext8を使ったEventTime対応を行いました。

fixext8を用いたEventTime拡張型の場合もext8を用いたEventTime拡張型も秒とナノ秒を表す32bit Integerをエンコードする際にはBig Endianでエンコードする必要があることに注意してください。

fixext8

+-------+----+----+----+----+----+----+----+----+----+
|     1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 | 10 |
+-------+----+----+----+----+----+----+----+----+----+
|    D7 | 00 | second from epoch |     nanosecond    |
+-------+----+----+----+----+----+----+----+----+----+
|fixext8|type| 32bits integer BE | 32bits integer BE |
+-------+----+----+----+----+----+----+----+----+----+

ext8

+--------+----+----+----+----+----+----+----+----+----+----+
|      1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9 | 10 | 11 |
+--------+----+----+----+----+----+----+----+----+----+----+
|     C7 | 08 | 00 | second from epoch |     nanosecond    |
+--------+----+----+----+----+----+----+----+----+----+----+
|   ext8 | len|type| 32bits integer BE | 32bits integer BE |
+--------+----+----+----+----+----+----+----+----+----+----+

例

Unix epoch時間(v0.12互換)

EventTimeなしでFluent Loggerを動かす場合は、秒精度までのログしか送ることができません。Unix epochで表現が可能な精度の時刻がログに含まれます。

2017-05-17 17:29:57.000000000 +0900 test: {"name":"fruently"}

EventTime(v0.14から)

EventTime形式にエンコードして時間をログに含めた際には、処理系がサポートする秒以下の精度の時間も含めてログに含めることができます。

2017-05-17 17:29:57.587226000 +0900 test: {"name":"fruently"}

まとめ

Fluent LoggerのEventTime対応をする際に参照する必要になったEventTimeの仕様を解説しました。 EventTimeを用いてエンコードされた時刻はこれまでのものよりもさらに精度の高い時刻情報を持てるようになります。 1秒に1つ以上のログをFluent Loggerに送る必要がある際にFluent LoggerがEventTime対応をしているかどうかを調べて、未対応であればバグ報告やプルリクエストをしてみるのはいかがでしょうか。

2017-05-24

Speee Cafe Meetup #07：OSSの開発に参加しよう！ - OSS Gate #speee_lounge #oss_gate

須藤です。今月はあと2つ発表があります。（関西Ruby会議2017とApache Arrow勉強会。）

2017年5月23日にSpeee Cafe Meetup #07が開催されました。「OSS開発」がテーマということだったので、「OSSの開発に参加しよう！」という話をしました。

OSSの開発に参加しよう！ - OSS Gate

関連リンク：

内容

この発表では次のことを紹介しました。

「OSSの開発に参加」というとガリガリ難しいコードを書くというイメージがあるかもしれないけど、こんなことやあんなことも「OSSの開発に参加」だよ。
「OSSの開発に参加したい！」という気持ちはあるけどまだ行動できていない人のために、「OSSの開発に参加」をサポートする仕組みがあるよ。

こんなことやあんなことも「OSSの開発に参加」だよ、の具体例として次の例を紹介しました。

gemのインストールが失敗したとき：それを開発元にフィードバックする
ドキュメントにtypoがあった：それを開発元にフィードバックする
使っているgemに機能が足りない：それを開発元にフィードバックする

関連しそうな話として「OSSのエコシステムに参加」ってどういうことだろう？という話もしました。「OSSのエコシステムに参加」の私の説明はこうです。

自分たちのソフトウェアもオープンソースのソフトウェアも同じように扱うこと

問題があれば直すし、気になることがあれば共有する。つまり、いつも自分たちのソフトウェアでやっているようにオープンソースのソフトウェアでのやればいいんです。

「OSSの開発に参加したい！」という気持ちはあるけどまだ行動できていない人のために、OSS GateとOSS開発支援サービスを紹介しました。個人的にOSSの開発に参加したいという方はOSS Gateの方が向いています。業務の中でOSSの開発に参加したいという方はOSS開発支援サービスの方が向いています。（あるいは、個人的にOSS Gateに参加して、そこで得た知見を業務に活かす、というやり方もあります。）

OSS Gateの方に興味がある人は今週の土曜日（5月27日）にOSS Gate東京ワークショップ2017-05-27があるのでそれに参加することをオススメします。

OSS開発支援サービスの方に興味がある人は、Speeeさんでの事例を参考にしつつ、お問い合わせください。

まとめ

2017年5月23日開催のSpeee Cafe Meetup #07でOSSの開発に参加しよう！という話をしてきました。業務でOSSの開発に参加したい、という方には、私の話以外の話も興味深いと思います。すでにいくつか資料が公開されているのでそちらも見てみてください。

マイクロサービスとOSSのおいしい関係 by FiNKのshinofumijpさん
OSS開発が業務にもたらす恩恵 by Speeeの[@pataiji]さん
クローズドソースから始めるオープンソース by ドリコムの@onkさん

2017-05-25

関西Ruby会議2017：株式会社クリアコード #kanrk2017

須藤です。今年2回目の大阪です。（今年1回目の大阪はOSS Gate大阪ワークショップ2017-02-25でした。）

2017年5月27日に関西Ruby会議2017が開催されました。「Ruby Community and Ruby Business」がテーマということだったので、会社の話をするのがいいだろうなぁと思い、「株式会社クリアコード」というタイトルで基調講演をしました。

株式会社クリアコード

関連リンク：

内容

「Ruby Community and Ruby Business」というテーマなので、クリアコードは「Ruby Community」と「Ruby Business」を相互に活かしながらクリアコードが大事にしていることを実現している、という話をしました。クリアコードでの「Ruby Community」は「Ruby関連のフリーソフトウェア開発活動」、「Ruby Business」は「クリアコードでの仕事の仕方・作り方」です。クリアコードが大事にしていることは「フリーソフトウェアの推進と稼ぐことの両立」です。

1つのストーリーになった話ではなく、関連する話をたくさん集めた話にしました。具体的には次の話をしました。