始めに：pandasの作者であるWes McKinneyさんがPythonのデータツール関連でとても興味深いblogを書かれているので、翻訳して日本のPyDataコミュニティに公開してもいいでしょうか、とお聞きしたところ、快諾をいただきましたので少しずつ訳して公開していこうと思っています。
2017年の展望: pandas, Arrow, Feather, Parquet, Spark, Ibis
（原文：http://wesmckinney.com/blog/outlook-for-2017/ ）
2016/12/27
Python dataの開発に関して、2017はエキサイティングな年になりそうです。このポストでは、私から提供できそうなものについて書いていきます。それぞれのピースを全体としてどうまとめていくつもりなのか、詳しくは今後のポストで書いていきます。2016年は開発とPython for Data Analysisの第2版の作業で完全に手一杯でblogはあまり書けませんでした。2017年はもっと書けるようがんばるつもりです。
新しいポジション
Clouderaで生産的な2年間を過ごしたあと、私は数ヶ月前にTwo Sigma Investmentsのソフトウェアアーキテクトの役職に移籍しました。2010年に計量ファイナンスの世界を離れてから、私は金融業界でオープンソースのツールが大きなインパクトを与えてきたのを見てきました。Two Sigmaのような先進的な考え方の組織がオープンソースエコシステムへの関わりを強め、内部で開発したツールをリリースし、成果を既存のOSSプロジェクトにコントリビュートしているのを見て、あらためて元気づけられました。
仕事としては、私はこの10年間にわたって開発してきたオープンソースソフトウェアにぴったりのデータ分析の問題の解決に取り組んで言います。
- ユーザーフレンドリーなAPI設計
- 高パフォーマンスなI/Oとデータアクセス
- 高速で表現力に富む演算エンジン
オープンソースとビジネスに関しては、私としてはいくつかの面白いトレンドが今立ち上がり始めていると思います。
- オープンソースに参加していない（ユーザーや開発者として）企業は取り残され始めている
- 最高のソフトウェアエンジニアたちの多くは、オープンソースプロジェクトへの関わりを禁じる企業では働こうとしなくなっている（私は間違いなくそうです）。
pandas 2.0
昨年、私たちは今日のデータの問題に対する要求にもっと適したものになるようpandasの内部を改善するための計画について公に議論をしてきました。私は最近のプレゼンテーションでこのことについて少し話をしました。
大まかに言って、pandas 2.0が目標としているのは以下のようなことです。
- 設計上の欠点と9年前から蓄積された技術的負債の修正
- シングルスレッドのパフォーマンス向上
- メモリ管理効率の向上、メモリ使用量の削減
- 本物のマルチスレッド実行によるパフォーマンスとスケーラビリティの改善
私が目標としているのは、現在のpandasのユーザー体験の質を変えることなく、扱えるデータの量を10倍にすることです。pandasは1GBのデータならうまく動作しますが、10GBだとうまく行かなくなってきます。これは、将来にわたってpandasが使われ続けるために必要な変化です。
それまでの間、pandasのチームはメジャーリリースの0.20の作業中であり、そしてそのあとにはAPIが安定する1.0が続きます。APIが安定している間に、pandasコアのリファクタリングを行います。
Apache Arrow
2016年2月にApache Arrowをアナウンスしました。Apache Arrowはオープンソースのデータプロジェクト群が協力し、高パフォーマンスのインメモリ列指向データ構造及びI/Oの標準を確立しようとするものです。
それ以来、Arrowの開発はうまく進んでいます。最近では、初期のJava及びC++ライブラリの実装間で完全なバイナリの互換性を実現したことによって、開発の大きなマイルストーンに到達しました。これは、JVM（そしてSparkのようなシステム）とC++あるいはPythonベースのシステムとの間で高パフォーマンスのI/Oを提供するための重要なステップです。
ArrowのC++ライブラリを構築する上で私が目標としていることの１つは、オーバーヘッドの少ない列指向のメモリ管理と、高パフォーマンスのマルチスレッドI/Oをpandas 2.0で使えるようにすることでした。準備ができれば、これらのツールとそれらがどのように役立つのかということについてもポストします。
pandas 2.0の開発をしながら、私たちはArrowを現在のpandasのプロダクションバージョンとの間でデータをやりとりするための高速な「データパイプ」にするための作業を続けます。
Apache Parquet for Python
2016年に、私たちはApache Parquetファイルフォーマットの読み書きのためのプロダクション品質のC++ライブラリを作成するための作業を行いました。その過程で、私はApache Parquetのコミッタ、そしてPMCメンバーになりました。また、Blue YonderのUwe KornもParquetのコミッタになりました。
Parquetは、サイズの縮小と効率的なi/Oを念頭に置いて設計された列指向のファイルフォーマットです。Arrowは、Parquetとのやりとりをするための転送レイヤーとして理想的なインメモリの列指向コンテナです。
PythonでArrowとparquet-cppを使ってParquetを読み書きするには、conda-forgeからpyarrowをインストールします。
conda install pyarrow -c conda-forge
そして、読み取りのコードは以下のようになります。
import pyarrow.parquet as pq
arrow_table = pq.read_table('path-to-data/0.parquet')
df = arrow_table.to_pandas()
この数ヶ月間の間に、Parquetについてはもっとドキュメンテーションやblogポストを書いていきます。
最近、Continuum AnalyticsはPython用のParquetの別の実装を開発し始めました。これはエンコードとデコードのルーチンの高速化のためにNumbaを使っています。これらの問題に取り組むPythonの開発者が増えていることをうれしく思います。
Featherファイルフォーマット
2016年の始めに、私はHadley WickhamとともにRとPython用にFeatherファイルフォーマットを設計し、提供しました。FeatherはApache Arrowの列指向の表現形式を使い、RとPythonの主なデータ型を扱えるシンプルなメタデータの仕様を持っています。
時間が経つにつれ、予想できる通りにFeatherのC++とPythonのコンポーネント、そしてApache Arrowの対応するC++及びPythonライブラリとの間でオーバーラップしているコードがかなり出てきました。この問題に対処するために、私はFeatherの実装をArrowのコードベースにマージすることを計画しています。こうすれば、より優れたパフォーマンスと新しい機能をFeatherのユーザーに提供できるようになるはずです。
PySparkの改善
Apache SparkのためのPython APIであるPySparkには、データのシリアライゼーション（SparkのDataFrame.toPandasとsqlContext.createDataFrame）と、それに関連してUDFの評価（rdd.map、rdd.mapPartition、sqlContext.registerFunction）に関して（Scalaと比べると）パフォーマンスの問題があることはよく知られています。
Arrowを利用したPython及びJVMのための高速な列指向I/Oの作業と並んで、Two Sigmaの私の同僚たちと私はIBM及びSparkコミュニティと共同で、これらの新しいテクノロジーを利用してPySparkの高速化に取り組んでいます。この動きに参加したい方は、私に連絡をいただければと思います。
PySpark-Arrowの作業は順調に進んでおり、2月のSpark Summit East Conferenceで興味深いアップデートを紹介できるはずです。
（訳注：これがSpark Summit East ConferenceでのWesさんのスライドです。 https://www.slideshare.net/wesm/improving-python-and-spark-pyspark-performance-and-interoperability ）
Ibisのアップデート
最後に大事なことを。私はIbisのメンテナンスを続けており、できる範囲でユーザーの支援も続けています。私は、Ibisがユーザーに提供しているSQL構文のサポートレベルの深さを誇りに思っています。pandasのようなPythonのコードで非常に複雑なクエリを書くことができ、それらは合成したり再利用したりすることができます。
pandas 2.0の作業が進むにつれ、私はIbis用のインメモリバックエンドの構築に興味を持つようになってきました。これは過去にも考えたことがありましたが、その時点では待ったほうがいいと考えたことでした。