Amazon Web Services ブログ

Amazon Redshift を使用して、デジタルコンテンツを収益化するプロデューサーを支援している Narrativ

Narrativ は、彼ら自身の言葉によれば、「Narrativ は次世代のデジタルコンテンツプロデューサーのための収益化技術を構築しています。当社の製品ポートフォリオには、毎月数百万ドルの広告主価値と数十億データポイントを生成するリアルタイム入札プラットフォームとビジュアルストーリーツールが含まれています」ということになります。

Narrativ では、過去 15 ヶ月間に当社の製品によって生成されたデータが同様に桁違いに増加し、プラットフォームの使用量が大幅に増加しました。このブログ記事では、AWS を使用した、堅牢でスケーラブルで、パフォーマンスが高く、費用対効果の高い分析環境への進化を共有します。また、データウェアハウジングとデータレイク分析の過程で学んだベストプラクティスについても説明します。

Narrativ の継続的な成長の加速を見越して、私たちは昨年末、次の規模の計画を立て始めました。当社では Amazon Redshift をデータウェアハウスとして使用してきており、非常に役に立っています。データが増え続ける中、Amazon S3 をデータレイクとして利用し、Amazon Redshift Spectrum の外部テーブルを使用して S3 で直接データを照会しました。これにより、コストや複雑さに対するトレードオフなしで、ニーズを満たすためにストレージやコンピューティングのリソースを容易に個別に拡張できるようになったことを嬉しく思いました。

このプロセスで、Redshift Spectrum での作業を簡素化し、多数のベストプラクティスをカプセル化する Spectrify を作成しました。Spectrify は、簡単なコマンドで次の 3 つのことを実現します。まず、Amazon Redshift のテーブルをコンマ区切り値 (CSV) 形式で S3 にエクスポートします。次に、エクスポートされた CSV ファイルを並行して Apache Parquet ファイルに変換します。最後に、Amazon Redshift クラスターに外部テーブルを作成します。これで、クエリは Amazon Redshift のデータを使用して、膨大な量の Parquet データを S3 で展開し、すぐに結果を返すことができるようになりました。

 

上の図は、Amazon S3 の Parquet データと Amazon Redshift のデータ間で、Spectrify がどのようにしてクエリを簡素化し、すぐに結果を返すかを示しています。

Narrativ での Amazon Redshift

Amazon Redshift は、Narrativ の設立以来、データウェアハウスの基盤となっています。トラフィックの統計を作成し、プログラムシステムでデータ駆動アルゴリズムを提供し、データの洞察を探るウィンドウとして使用しています。Amazon Redshift は、当社のニーズをサポートできるように十分に拡張されています。当社のクラスターは 3 ノードから 36 ノードに成長しており、1 時間あたりのクエリはパフォーマンスを損なうことなく大幅に増加しています。ワークロードが統計と会計からデータ駆動型の洞察に移行する中で、Amazon Redshift は増大するクエリの複雑さに適応しています。

当社のデータ戦略の次の反復を計画する場合、要件は以下のとおりです。

  • 小規模なエンジニアリングチームでメンテナンス可能 (ほぼ手作業なしで)
  • すべての履歴データをいつでも照会できる
  • 過去 3 か月のデータをすばやく検索できる
  • 現在のデータ量の 10 倍になってもパフォーマンスを維持できる

こうした要件を満たすためにいくつかのアイデアを考えました。

  • DC2 クラスターと DS2 クラスターにアップグレードする
  • 非常に大きい DC2 クラスターにアップグレードする
  • オープンソースの代替手段に移行する (メンテナンスは困難)
  • 別のビッグデータプロバイダーに移行する (エントリ、高価、リスクの高い障壁)

そして、コンピューティングコストをストレージコストから切り離すことで状況を変えてくれる、Redshift Spectrum を見つけました。Redshift Spectrum を使用すると、適度なサイズでそれでも高速な Amazon Redshift クラスターを維持しながら、あまり使用されない古いデータを S3 にオフロードすることができます。他のソリューションと比較すると、Redshift Spectrum は、すべてのクエリに対して同じディメンションのテーブルのセットにジョインできるようにすることで、複雑さを軽減します。そして最終的に、仮に向上しないとしても、パフォーマンスを維持します (クエリに応じて)。このように私たちの要件はすべて Redshift Spectrum で満たされ、さらに実装するのが簡単で、速く、費用対効果がありました。

今後は、Redshift Spectrum が AWS のデータ機能を次の規模に拡大するための重要なツールであると見なしています。Redshift Spectrum では、Amazon S3 に保存されているデータに基づいて Amazon Redshift のテーブルを定義することができます。このようにして、Redshift Spectrum は Amazon Redshift をハイブリッドデータウェアハウス/データレイクに変えます。両方の世界のベストを提供してくれます—無制限のストレージのコンピューティングコストからの分離に加えて、Amazon Redshift 自体のパフォーマンスと収束したワークフロー。

Redshift Spectrum の解放

ベストプラクティスを活用すると、Redshift Spectrum で大幅なパフォーマンスの向上が得られます。他の人たちも同じ成果を得られるように、私たちは GitHub のオープンソースの Python ライブラリで Spectrify の実装についてのベストプラクティスを共有しました。以下は、Spectrifyに組み込まれていることが分かる、Redshift Spectrum を最適化するために最も推奨されるポイントについての詳細です。

Apache Parquet の使用

Apache Parquet は、カラムナファイル形式です。Parquet にデータを保存すると、Redshift Spectrum はクエリに関連する列データだけをスキャンできます。対照的に、CSV や JSON のような行指向の形式では、クエリに関係なく、すべての列のスキャンが必要です。Narrativ のワークロードで Parquet を使用すると、パフォーマンスが大幅に向上し、請求が劇的に減少しました。

カラムナ形式では、より効率的なデータ圧縮も可能になります。類似したデータをグループ化すると、データ圧縮が向上します。この場合、gzip で圧縮した Parquetファイルは gzip で圧縮した CSV に対して約 80% 減少しました。この減少は、データの取り込み、スキャンがより高速になることを意味します。

最初にデータの Parquet への変換を調査したところ、私たちのニーズに合った選択肢は見つけられませんでした。Parquet ファイルを作成するための最も一般的なツールセットである Spark や Hadoop エコシステムからのその他のプロジェクトは使用しません。いくつかの Python プロジェクトでは、Parquet の書き込みがサポートされていました。ただし、特に null 許容列に関連して、データの一貫性に関する警告を留保しました。さらに、正しいタイムスタンプ形式をサポートするライブラリが見つかりませんでした。

これらの問題をすべて解決するために Spectrify を構築しました。Apache Arrow プロジェクトと協力して、Redshift Spectrum と、Spectrify で生成された Parquet ファイルの完全な互換性を確保しました。

データの分割

Narrativ は、タイムスタンプ付きイベントデータを Redshift Spectrum に保存します。イベント作成日にデータを分割し、Redshift Spectrum がクエリの多くについてデータファイルの大部分を調べるのをスキップできるようにします。一般に、私たちのクエリは 1 月やわずか 1 日といった時間領域の小さなサブセットに関係しています (例えば、2017 年のブラックフライデーに関する特定の質問に答える、など)。数年に渡る出来事に関するクエリなどはほとんどありません。

これにより、スキャンされるデータ量が大幅に削減され、ほとんどのクエリは 10 分の 1 の時間で完了します。また、請求もはるかに下がります。パーティショニングだけで、クエリあたりの平均コストが 20 分の 1 に低下しました。

まとめ

データ量の大幅な増加を見込んで、Amazon Redshift と Redshift Spectrum を使用して Amazon S3 に構築されるデータレイク戦略に転じるようになりました。Redshift Spectrum により、S3 および Amazon Redshift 全体でデータを照会し、クエリのパフォーマンスを維持または向上させ、簡単かつコスト効率よく実行することができました。その過程で、ベストプラクティスを学び、Spectrify を構築して、データの準備と分析をさらに効率化しました。コードの例と私たちが学んだことを共有することが、増大するデータを抱えている他の人の場合でも同様の結果を達成するのに役立つことを願っています。

詳細については、Spectrify の使用方法のドキュメントやコードの例、そして GitHub にある詳しい説明を参照してください。

 

その他の参考資料

この投稿が参考になった場合は、「Using Amazon Redshift Spectrum, Amazon Athena, and AWS Glue with Node.js in Production」および「How I built a data warehouse using Amazon Redshift and AWS services in record time」もぜひご覧ください。

 

今回のブログ投稿者について

Colin Nichols 氏は、Narrativ でのビッグデータイニシアティブのリーダーです。 彼はシステムの交点で働くことを楽しんでおり、品質、自動化、継続学習などのテーマで強固なエンジニアリング文化を形成してきています。 余暇には、Colin は自分の犬である MacGyver に新しいトリックを教えることを楽しんでいます。