Amazon Web Services ブログ

AWS Glue and SneaQLを使ったAmazon Redshift へのUpsert

この記事は、Full 360 のソリューションアーキテクトである Jeremy Winters と Ritu Mishra によるゲスト投稿です。2 人によると、「Full 360 はクラウドファースト、クラウドネイティブのインテグレーターで、2007 年の創立以来の忠実なクラウド信者です。私たちの焦点は、クラウドへの旅におけるお客様の援助であり続けています。ビッグデータとウェアハウジング、アプリケーション近代化、そして Cloud Ops/戦略といった私たちの業務分野は、深いだけではなく、明確な専門知識を表しています。」

AWS Glue は、簡単でコスト効果の高い方法でデータの分類、消去、強化、およびさまざまなデータストア間を確実に移動することができる、完全マネージド型 ETL (抽出、変換、ロード) サービスです。 10年もの間クラウド内にデータウェアハウスソリューションを構築してきた企業として、Full 360 はカスタマーソリューションで AWS Glue をどのように活用できるかについて興味を持っていました。この記事では、当社が Amazon Redshift データ統合ユースケースのための AWS Glue の使用からの得た経験と教訓について詳しく説明していきます。

UI ベースの ETL ツール

当社では、re:Invent 2016 で AWS Glue が発表された当時からそのリリースを心待ちにしていました。私たちの顧客の多くは、データ変換パイプラインを管理するための使いやすい UI ベースのツールを探しています。しかし当社の経験では、どの生産パイプラインの複雑性も、それらを作成するために使われたテクノロジーに関わらず、解消しづらい傾向にあります。Full 360 では, データ統合を処理するためにコンテナにデプロイされたクラウドネイティブなスクリプトベースのアプリケーションを構築しており、スクリプトベースの変換は、発生するデータ問題に対応するために必要なロバスト性と柔軟性のバランスを提供すると考えています。

AWS Glue は、スクリプトを記述することを好む開発者と、UI ベースのインタラクションを望むユーザー両方の要望に応えます。データのソースとターゲットを選択することにより、UI を使ってジョブを初期に作成することが可能です。AWS Glue は内部で Python コードを生成してくれて、コードも必要に応じて編集することができますが、これはほとんどのユースケースにとって必要ではありません。

もちろん、UI に全く頼らないことも可能です。独自の Python スクリプトを記述し、それらを依存するライブラリと共に Amazon S3 に保存して、AWS Glue にインポートするだけです。 AWS Glue は、PyCharm、そして興味深いことに Zeppelin ノートブックなどのツールを使った IDE 統合もサポートしています。これらの統合は、自分自身で Python を記述することを好み、よりクリーンな開発/テストサイクルを求める開発者をターゲットにしたものです。

すでに ETL をスクリプト記述する業務に携わっている開発者は、ソースコントロールと継続的インテグレーション/継続的デリバリーのための既存のワークフローを使用して AWS Glue で Python スクリプトを簡単にデプロイし、それらを AWS によって完全に管理された方法でデプロイして実行する機能を大歓迎するでしょう。 AWS Glueの UI エクスペリエンスは非常に良好ですが、このツールが従来のコーディングを好むユーザーにも対応することを知っておくとよいでしょう。UI では不十分なデータ処理のための複雑なエッジケースを掘り下げることもできます。

サーバーレス !

AWS Lambda がリリースされた時、当社の ELT プロセスをホストするその可能性に心が躍りました。Lambda では、関数の実行は最大 5 分間に限定されています。当社では、顧客の長期間実行されるタスクの多くを調整するために、Docker コンテナと Amazon ECS を実行する手段を取りました。このアプローチでも、まだ基礎的なインフラストラクチャを管理する必要がありました。

AWS Glue をよく調べたところ、これが Apache Hive メタストア対応の Catalog as a Service を伴う完全なサーバーレス PySpark ランタイムであることに気が付きました。これは、単にシングルコアでスクリプトを実行するだけではなく、複数ワーカーの Spark 環境の全機能が利用できることを意味します。Spark フレームワークをよく知らないなら、これは分散されたインメモリデータセットの処理を可能にする新たなパラダイムをもたらすものです。Spark には、データ変換から機械学習まで、多くの用途があります。

AWS Glue では、データベースに到達する前にデータを変換するために、PySpark データフレームを使用します。データフレームはリレーショナルデータベースに似た方法でデータを管理するため、このメソッドは大抵の SQL ユーザーにとってなじみのあるものだと思われます。さらに、データを操作するために PySpark コード内で SQL を使うこともできます。

また AWS Glue は、ジョブを実行するために使用されるコンピューティングリソースの量を増減させることができる DPU 設定を提供することによって、ランタイム環境の管理をシンプル化します。ひとつの DPU は vCPU 4 個、メモリ 16 GB に相当します。

一般的なユースケース

当社では、ほとんどの顧客がひとつ、または複数のファイルを S3 から Amazon Redshift にロードするために AWS Glue を活用すると見込んでいます。このプロセスを迅速化するためには、データがファイルまたはデータベースのどちらに置かれているかに関わらず、AWS のコンソールベースのユーティリティであるクローラーを使って、データのスキーマを検出し、AWS Glue データカタログに保存することができます。当社では、ソースファイルとターゲットテーブルのスキーマを検出し、AWS Glue に ETL ジョブを構築して実行させることができました。大成功です! 当社の上級チューニングクラスで使用した JSON ファイルのビール愛飲家データセットを Amazon Redshift に上手くロードできました!

当社のユースケース

当社のユースケースでは、AWS Glue と Amazon Redshift Spectrum を、当社が開始した SneaQL と呼ばれるオープンソースプロジェクトに統合しました。SneaQL は、静的 SQL にインタラクティブに潜入するためのオープンソースのコンテナ化されたフレームワークです。SneaQL は、スクリプトにループ、変数、条件付き実行、およびエラーハンドリングなどの機能を提供するコマンドタグで ANSI SQL に拡張機能を提供します。AWS CodeCommit Git リポジトリでのスクリプトの管理を可能にし、これはその後コンテナにデプロイされて実行されます。

当社では、データがデータベースにロードされてから、パラメータ化された SQL を使ってファクトテーブルに変換されるという、通常 ELT モデルを伴う複雑なデータ統合に SneaQL を使用します。SneaQL は、複数のデータソースを同じファクトテーブルにマージできるデータの部分的なアップサート集約などの高度なユースケースを可能にします。

当社では、AWS Glue、Redshift Spectrum、および SneaQL が、Hive、Presto、Spark、および Redshift Spectrum などの様々なツールを使ってすべてのメタデータにアクセスできるデータレイクを S3 に構築する強力な手段を提供すると考えています。ダッシュボード、またはその他高機能分析を実行するために、Amazon Redshift で集約テーブルを構築してください。

以下のビデオでは、S3 データレイク内のパーティション分割されたストレージのために AWS Glue を使って JSON ドキュメントを Parquet に変換するデモをご覧いただけます。その後、Redshift Spectrum 経由で S3 から Amazon Redshift へのデータにアクセスします。AWS Glue ジョブの終了間近になったら、AWS boto3 を呼び出して、ファクトテーブルへのデータのアップサートを実行するための Amazon ECS SneaQL タスクをトリガーします。このデモに必要であったサンプルアーティファクトは、すべて Full360/Sneaql Github リポジトリで取得できます。

 

このシナリオで、AWS Glue はデータウェアハウス外のデータを操作して Amazon Redshift にロードし、SneaQL は Amazon Redshift 内のデータを操作します。

当社では、複雑な統合を行うときに AWS Glue と SneaQL がお互いを上手く補完し合うと考えています。

当社のパイプラインの流れは以下の通りです。

  • 新しいファイルが JSON 形式で S3 に到着する。
  • AWS Glue が JSON ファイルを Parquet 形式に変換し、別の S3 バケットに保存する。
  • AWS Glue スクリプトの終わりに、AWS SDK for Python (Boto) が SneaQL を実行する Amazon ECS タスクをトリガーするために使用される。
  • SneaQL コンテナが S3 から認証ファイルを取得し、それを Biscuit または AWS KMS で複合化する。
  • SneaQL が AWS CodeCommit Git リポジトリから適切なブランチをクローンする。
  • Amazon Redshift 内のデータがリポジトリに格納された SneaQL ステートメントによって変換される。

AWS Glue チームは、ジョブを分割して、互いに依存し合うようにすることを可能にする条件付きトリガーもサポートします。

結論

原則として、当社ではソースコントロール内でのスキーマ定義の管理を信頼していますが、クローラー機能に魅力的なメリットがあることは間違いないと考えています。クローラーは、アドホックジョブに便利であること以外に、パーティション認識でもあります。これは、どのデータがすでに処理されているかを心配することなくデータ移動を実行できることを意味しており、管理する事柄がひとつ減ることになります。当社では、クローラーの使用を中心に誕生する設計パターンを目にすることを楽しみにしています。

PySpark の自由さも、高度なユースケースの実装を可能にしてくれます。すべての AWS Glue ジョブには Boto3 ライブラリを使用できますが、Python スクリプトと共に他のライブラリや追加の JAR ファイルを含めることも可能です。

当社は、多くの顧客が AWS Glue に価値を見いだすと考えます。データ処理パイプラインのコーディングを好むユーザーは、特に複雑なデータクレンジング問題の解決において、これがどれほど強力かをすぐに認識するでしょう。PySpark には学ばなければならない事柄が数多くあります。そこで、良い出発点としてデータフレームを検討することをお勧めします。長い目で見ると、AWS Glue がサーバーレスであるという事実は、その努力をそれ以上に価値あるものにしてくれるでしょう。