米Amazon Web Services(AWS)が2017年4月に一般提供を始めた、ビッグデータ分析の新サービス「Amazon Redshift Spectrum」。リクルートテクノロジーズは2017年にAWSの協力を得て、このサービスの検証をいち早く進めた。今回はリクルートテクノロジーズが実施した検証内容と、検証結果から分かった活用ノウハウや落とし穴を紹介する。

 検証に使うデータは、リクルートテクノロジーズがデータウエアハウス(DWH)サービス「Amazon Redshift」で利用していたものだ。データ形式はTSV(タブ区切り)形式で、約6億行。データ量は約50GBあり、gzip圧縮時は約25GBになる。以後のデータサイズはgzip圧縮時のものだ。

 Redshift Spectrumで使用するため、Redshiftからオブジェクトストレージサービス「Amazon S3」にアンロード(出力)した。その際、データは6ファイルに自動分割され、1ファイルの最大サイズは6GBになった。新しいデータをS3に用意するのではなく、RedshiftのデータをS3にアンロードしたのは理由がある。RedshiftのデータをS3に切り出し、Redshift Spectrumで処理することによって、Redshiftに保有できるデータ容量の上限などといった課題を解消できないかと考えているからだ。

1ファイルのデータ量は小さくする

 最初の検証項目は、データのファイル分割の度合いによって、処理速度がどのように変わるかである。まず、Redshiftクラスターで計算処理を担うCompute Nodeが1個の場合に、アンロードによって自動分割したケースを考える。この場合、6ファイル、1ファイル当たり最大で6GBである。

 比較対象として、同じデータを20個のCompute Nodeからアンロードで自動分割したケースを取り上げる。この場合は、40ファイルに自動分割された。Redshift Spectrumの活用に関するAWSの公式ドキュメントには、1ファイルのデータ量は100MBから1GBまでで同等にするとよい、との記載がある。40ファイルに自動分割することで、1ファイルのサイズは最大で600MBほどになり、AWSの推奨範囲に収まった。

1ファイルのデータ量の大小と、RedshiftのCompute Node数による性能比較
1ファイルのデータ量の大小と、RedshiftのCompute Node数による性能比較
(出所:リクルートテクノロジーズ)
[画像のクリックで拡大表示]

 上述のようなRedshift Spectrumの環境を作り、フルスキャンを伴うクエリーを実行したところ、6ファイルに分割したケースは合計111秒、40ファイルに分割したケースは合計29秒掛かった。

 この検証結果から、1ファイルのデータ量は100MBから1GBまでで同等にするとよい、というAWSの公式ドキュメントの記載は妥当だと分かった。

 もう一ついえるのは、Redshiftから巨大なデータをS3にアンロードするとき、適切に自動分割されるとは限らないことだ。これは、RedshiftのデータをS3にアンロードしてRedshift Spectrumで分析するという使い方をする際の落とし穴になる。

 リクルートテクノロジーズ 金融データプラットフォームグループの河野愛樹氏は、「Redshiftからデータをアンロードする際は、自動分割後にさらに分割して1ファイルのデータサイズを推奨サイズにするのが重要」と語る。

 なお、Redshift SpectrumではなくRedshiftを使って同じ処理をした場合の所要時間は3秒だった。Redshift Spectrumを使うとこれよりも大幅に時間が掛かるのは、S3からデータを読み込むのに時間が掛かるためと考えられる。