AWS Data Wranglerを触ってみた
つい先々週Amazon Web Services ブログで紹介されていたAWS Data Wranglerを触ってみたので、その感想などを書きます。
AWS Data WranglerはAWSの各サービス上にあるデータを操作するためのPythonライブラリです(つまりサービスではない)。Python環境においてメモリ上にあるpandasのDataFrameや、PySparkのセッションで捕捉しているデータをAWSの各種リソース(S3, Redshiftなど)へとアップロードすること、またその逆の作業が行えます。
元来このような操作は各チームでライブラリを用意するか、個々のデベロッパーが都度開発することで実現されることが多かったでしょう。今回AWS Data Wranglerが提供されたことにより、そのような手間を省くのに加え、データのやり取りを行う際のベストプラクティスに沿った実装を利用できる様になることが期待できます。
基本的な使い方はリポジトリの利用例に十分に紹介されているので、S3とDataFrameをやり取りする際の細かい挙動について気になる点を1つだけ紹介します。
基本のpandas => S3 => Athena => pandas
pandasとS3のやり取りとして、実験の途中や、バッチの実行結果として生じたDataFrameをS3に保存する(したい)というケースは多いかと思います。AWS Data Wranglerはこれをサポートしています。
この結果は少々直感とは異なり、以下のようになります。
$ aws s3 ls s3://BUCKET/PREFIX/ 2019-10-03 22:07:32 3436 29db73219ba048648b9ae0286c3b6747.parquet.snappy 2019-10-03 22:07:32 3457 2ada1fe72e1044a4a01d3b03c46ae558.parquet.snappy 2019-10-03 22:07:32 3436 3ea443453f7b4e37b6ceb51a06aa0c95.parquet.snappy 2019-10-03 22:07:32 3454 68a737bf6ca04d60a6cd9f16f5f3d00f.parquet.snappy 2019-10-03 22:07:32 3436 754e5d5d8f594ce7bdaf9bf42488837f.parquet.snappy 2019-10-03 22:07:32 3436 91fafdee0ea341ba8b03193b3a6bac9c.parquet.snappy 2019-10-03 22:07:32 3456 9a63221332544d5c8a8e7adbdcd6eb54.parquet.snappy 2019-10-03 22:07:32 3438 9c0b3ab83e824c74ba177f38241828d9.parquet.snappy 2019-10-03 22:07:32 3456 b55e7e25325e47a083198432bf37e5ad.parquet.snappy 2019-10-03 22:07:32 3436 d1a728e140a84d1e84572c8b54bc78a6.parquet.snappy 2019-10-03 22:07:32 3438 f39464920ee1443a84151860561b115c.parquet.snappy 2019-10-03 22:07:32 3438 fff9fe7a86644e7886b63df513599189.parquet.snappy
AWS Data WranglerはデフォルトでS3へのアップロードを実行環境のCPUのコア数分だけ並列で行います。これらのObjectのKeyは session.pandas.to_parquet の返り値として得ることができますが、別の文脈(別のプログラムやNotebook)からアクセスし直すのはやや煩雑でしょう。
代わりにAWS環境では、AWS Glueを利用して s3://BUCKET/PREFIIX/
をテーブル化し、即座にAthenaでクエリをすることが可能です。テーブルの作成はもちろん手動でも可能ですが、AWS Data Wranglerに任せることができます。
session.pandas.to_parquest
に table=
database=
(予めAWS GlueのDatabaseを作成しておく必要があります)の引数を与えることで、AWS Glue データカタログに所望のテーブルが自動で作成されます。そして次のようにしてAthenaにクエリを発行することができます。
またAthenaで扱うデータにとってはほぼ必須となるパーティションの制御もお手の物です。DataFrameをアップロードする際に、パーティションのキーとしたい列をDataFrameに予め用意してやることで、Hive式の配置でデータを格納することができます。(このような処理を自分で実装したことが何度かあるので、ライブラリ化されて嬉しい)
$ aws s3 ls s3://BUCKET/PREFIX/ PRE year=2015/ PRE year=2016/ PRE year=2017/ $ aws s3 ls s3://BUCKET/PREFIX/year=2015/ PRE month=1/ PRE month=10/ PRE month=11/ PRE month=12/ PRE month=2/ PRE month=3/ PRE month=4/ PRE month=5/ PRE month=6/ PRE month=7/ PRE month=8/ PRE month=9/
うーん素晴らしい。これこれ。
まとめ
プログラムやNotebookで出来上がった有益ぽいDataFrameは、ローカルのファイルシステムではなくAWS Data Wranglerを使って即クラウド、再利用する際は同じ名前(パス、database、table)で呼び出して使う。AWS Data Wranglerが提案するプラクティスはこのようなものではないでしょうか。
AWS Data Wranglerを利用することによって、これまで実験の中間データが迷子になってしまっていたような環境では、実験の再現性などの質を高めることに つながるでしょう。(一方で依然データの名前の管理、データのドキュメンテーションなど、データの管理に必要な作業はまだまだ残っていますが…)
またpandasにはもともと pandas.io という、データソースとのやり取りをサポートする機能が備わっているのですが、AWS Data WranglerはAWS環境を前提とすることでより強力な機能を提供できたとも捉えられるでしょう。
最後にこれは余談ですが、クックパッドにいたころに作った、各種データソース(Redshift、MySQL、PostgreSQL、S3など)からデータを読み出す作業をライブラリ化したものがあります。
最近は殆ど手を付けていなかったのですが、AWS Data Wranglerの登場によって、ほぼ完全に「しょぼい版」になってしまいましたね。さよならakagi。