注：本記事は(2021年12月7日)に公開された(Simplifying Use of External APIs with Request/Response Translators)を翻訳して公開したものです。

Snowparkはその発表以来、大きな反響と関心を集めています。Snowparkとは、データエンジニア、データサイエンティスト、データデベロッパーがそれぞれが好むプログラミング言語でコーディングできる開発者フレームワークであり、パイプライン、機械学習（ML）ワークフロー、データアプリケーションのより迅速かつより安全な実行が可能です。Snowparkの多くの部分はプレビュー段階ですが、エクスターナルファンクションは今年の初めに、一般公開に至りました。

エクスターナルファンクションにより、開発者はSnowflake SQLクエリ内から外部APIやリモートサービスを呼び出し、レスポンスをクエリ結果に取り込むことができます。データのエクスポートや再インポートが不要なため、これらはSnowflakeの内部機能であるかのように実行されます。これにより、複雑な変換を必要とするデータパイプラインの構築やカスタムコードやサードパーティサービスの使用を必要とする拡張が大幅に簡素化されます。今回は、リクエスト/レスポンストランスレーターに対するパブリックプレビュー版サポートが提供開始となったことをお知らせいたします。これにより、外部APIと連携することで、スピンアップや中間のデータトランスレーションレイヤが不要となり、エクスターナルファンクションの使用がさらに簡素化されます。

エクスターナルファンクション使用時は、リモートサービスやサードパーティAPIの呼び出しは、サポートされているクラウドネイティブのプロキシサービス（外部サービスAPIと連動するように設定されたAWS APIゲートウェイなど）を通じてリレーされます。しかし場合によっては送信されたデータを、Snowflakeデータ形式から外部サービスで求められているデータ形式へ、またはその逆方向に変換しなければならないことがあります。たとえば、感情検出のためにAmazon Comprehendのような外部サービスを使用する場合、データ形式を変換するために、AWS Lambdaのような中間コンピュートレイヤーのスピンアップが必要です。 

図1. トランスレーターを使用せず、エクスターナルファンクションを使用したサードパーティAPIを呼び出すソリューションアーキテクチャ

しかし、データのフォーマットのために中間のサードパーティのコンピュートインフラストラクチャーを設定し管理することは、コンピュートならびにネットワーク管理上のオーバーヘッドを生み出します。トランスレーター機能によってエクスターナルファンクションが使用したリモートサービスにより送受信されたデータ形式の変換が容易になることで、ソリューションアーキテクチャが簡素化され、この問題が解消されます。

本機能を使用すると、便利になる機能：

  • Snowflake形式からリモートサービスのネイティブ入力形式へのデータ変換（リクエストトランスレーター）
  • リモートサービスのネイティブ出力形式からSnowflake形式へのデータを変換（レスポンストランスレーター）

図2. トランスレーターとエクスターナルファンクションを使用したサードパーティAPIを呼び出す簡素化されたソリューションアーキテクチャ

リクエスト/レスポンストランスレーターはJavaScriptユーザ定義関数（UDF）として実装され、エクスターナルファンクションにリンクすることができます。ほとんどの場合に、一組のUDFを書き込みます。1つは送信されているリクエストを変換するためで、もう1つはレスポンスを変換するためです。Snowflakeはこれらの機能を各エクスターナルファンクションコールの一部として呼び出します。具体的には、Snowflakeはリクエストトランスレーター機能を呼び出し、それをSnowflake形式のデータに受け渡し、返されたデータを受け取ってリモートサービスに送信します。同様に、リモートサービスがデータを返した後、Snowflakeはレスポンストランスレーター機能を呼び出し、Snowflakeでの読み取りが可能な形式に変換し直します。ユーザー視点で見ると、リクエスト/レスポンストランスレーターを使用したエクスターナルファンクションの呼び出しは、他のエクスターナルファンクションの呼び出しと全く同じです。ただし、維持が必要なインフラストラクチャーやサービスの数は減少し、データパイプラインはさらに簡素化されます。より詳しい情報は機能のドキュメンテーションを参照ください。皆様からのフィードバックをお待ちしています。