❄️

簡単にできる非構造化データのデータパイプライン構築 with Snowflake Cortex AI

に公開
SQL
Snowflake
dataengineering
datapipeline
cortexai
tech

こんにちは。
株式会社アシストにてMDSエンジニア・Snowflakeエンジニアをしている山本です。
業務ではお客様のSnowflakeを中心としたデータ分析基盤の構築支援を行っています。

簡単にできる非構造化データのデータパイプライン構築 with Snowflake Cortex AI

企業が扱うデータには、構造化データ（もともと存在するDBソース、CSV、エクセル）だけではなく、PDF、画像、音声、動画などの非構造化データも多く存在します。これらの非構造化データをデータベース化し、分析可能な形に変換することは、多くの企業にとって大きな課題となっていました。

弊社でSnowflakeの構築支援をする際にも、非構造化データを分析できるようにすることで新たな価値を創造したいと考えているお客様がかなり多いように感じられます。

本記事では、Snowflake Cortex AIを活用することで、非構造化データをデータ分析基盤に取り込むデータパイプラインを簡単に構築できる手順について、具体的な事例を紹介していきながら行っていきます。

今まで非構造化データのデータベース化が難しいと言われていた理由

従来、非構造化データをデータベース化するには、以下のような課題があったかと思われます。

  • 前処理の複雑さ: PDFや画像からテキストを抽出し、構造化するための前処理が複雑であった。(Pythonなどを使った専門的なプログラミングスキルがあるエンジニアがいないと出来なかった。)
  • 専用ツールの必要性: OCRなどの専用ツールやライブラリが必要とされていた。(専門ツールを使いこなせる人材確保難も。)
  • データパイプライン構築の負担: 複雑な処理・複雑なツールを組み合わせたデータパイプライン自体を構築するのに工数が掛かりすぎた。
  • スケーラビリティの課題: 社内のドキュメントにはフォーマットがたくさんあり新しい仕様が出るたびにデータパイプラインを増築することに課題があった。

これらの課題により、非構造化データの活用は限定的になっていました。

AI-Readyが重要視される時代に現れたSnowflake Cortex AI

Snowflake Cortex AIは、Snowflakeプラットフォーム内で利用できるAI機能全体を指す用語です。

特に非構造化データの処理において、これらの機能が提供されています。

  • Document AI: PDFや画像からテキストを抽出し、構造化データに変換
  • Cortex AI SQL: 自然言語による処理を組み込んだSQL関数
  • Cortex Search: ベクトル化によるセマンティック検索（非構造化データの検索）

これらの機能により、従来は複雑だった非構造化データのデータパイプライン処理を、SQLベースで簡単に実現できるようになり、格納された非構造化データを自然言語で検索できるようになりました。

Cortex AIをデータパイプラインに組み込む事例

では、実際のデータパイプライン構築の事例を紹介します。
今回想定するデータパイプライン構築

  1. Bronze層(生データ状態)にあたる内部/外部ステージの作成時にディレクトリテーブルを有効化しておき、ステージへ非構造化データを格納する。(最近はOpenflowでやろうとしている方も多いのではないでしょうか)
  2. ディレクトリテーブルを有効化していることで、STREAMでステージへのファイル追加を検知できるようにする。
  3. Cortex AI SQLを使用して非構造化データをSilver層(半構造化状態)へ格納する。
  4. Silver層へ格納したデータを構造化データ/文章データに変換してGold層(AI-Ready状態)へ格納する。

AI-Readyなデータ分析基盤アーキテクチャ/データパイプライン構築についてはこちらの記事も参考になります。

【事例1】：テンプレート書類に、手書き記入・デジタル入力された値をデータ分析基盤に取り込むデータパイプライン

顧客から送られてくるPDF形式の契約書を、自動的に構造化するパイプラインを構築するケースを考えます。

Cortex Analystで分析することをスコープに構築することになるでしょう。

例として、生成AIに作ってもらったこちらの契約書を使います。
https://github.com/yamamoto10152/unstructured_data_pipeline/blob/main/sample_data/service_agreement_202507.pdf

1. 非構造データの取り込み(ステージング)

非構造化データの設置のステージの作成をします。今回は簡易的に内部ステージを作成します。

SQL後述

2. ステージのバージョン管理

ステージのバージョン変更を検知するストリームの作成

https://github.com/yamamoto10152/unstructured_data_pipeline/blob/3ec566e812a42db4b413ebb88b2e179941b53259/setup.sql

3. Cortex AI SQLを使用して非構造化データをSilver層へ格納する。

今回は契約書ということである程度フォーマットが決まっており、欲しい情報だけをPDFから抜き取る形になりますので、AI_EXTRACT関数が最適です。
ステージ内のフォルダ階層を考慮することで、柔軟な処理ができます。今回はcontractフォルダ内に契約書を格納するという形で処理しています。

SQL後述

4. Silver層へ格納したデータを構造化テーブルに変換してGold層へ格納する。

Silver層に入っている状態ではJSON形式なので構造化データへ加工します。

https://github.com/yamamoto10152/unstructured_data_pipeline/blob/4a749ca7b8036a7f01e0d2820535dbb4b5d1357f/AI_EXTRACT.sql

最初に載せた契約書の非構造化データがこの様な形で格納されます。

自動パイプライン化については後述

【事例2】： 社内ドキュメントをデータ分析基盤に取り込むデータパイプライン

就業規則や社内ドキュメントを自動的に構造化するパイプラインを構築するケースを考えます。

Cortex Searchで分析することをスコープに構築することになるでしょう。

サンプルデータとして架空の企業の就業規則を使います。（生成AI製）
https://github.com/yamamoto10152/unstructured_data_pipeline/blob/main/sample_data/就業規則_Katsuaki_Yamamoto.pdf

1. 非構造データの取り込み＆ステージのバージョン管理

こちらは先の工程で作成していると仮定して、省略します。
社内ドキュメントはステージ内のdocumentフォルダに格納すると想定します。

2. Cortex AI SQLを使用して非構造化データをSilver層へ格納する。

今回は社内ドキュメントということで、PDFに書かれている文章の構造をそのまま抜き出す必要があるため、AI_PARSE_DOCUMENT関数が最適です。
先に述べたように、ステージ内のフォルダ階層を考慮することで、柔軟な処理ができます。

SQL後述

3. Silver層へ格納したデータを構造化テーブルに変換してGold層へ格納する。

Silver層に入っている状態ではJSON形式なので構造化データへ加工します。今回はSearchで使うことを想定しているため文章化します。
オプションとして構造化した文章データに対してセマンティック検索をするCortex Searchを作成するSQLも記載しています。

https://github.com/yamamoto10152/unstructured_data_pipeline/blob/33494479a6d71df259c422d0969c02978a8fa82a/AI_PARSE_DOCUMENT.sql

最初に載せた就業規則ドキュメントの非構造化データがこの様な形で格納されます。

自動パイプライン化については後述

上記の2つの事例を自動パイプライン化する。

自動パイプライン化する上では以下の処理工程になるかと思います。

  1. ステージに非構造化データが入ってくる。
  2. ストリームに新しいデータのメタデータレコードが入ってくる。
  3. ストリームにレコードが入ってきたことをトリガーにタスクが実行される。
  4. 実行されるタスクの中で事例１，２の処理を行うストアドプロシージャが実行される。
  5. すべての処理が行われ、非構造化データが構造化データとして格納される。
  6. (オプション) 文章データを参照するCortex Searchが更新される

これら一連の処理が実行されるのがこのようなプロシージャとタスクになります。
https://github.com/yamamoto10152/unstructured_data_pipeline/blob/33494479a6d71df259c422d0969c02978a8fa82a/main_pipeline.sql

TEMPORARYテーブルを作成する理由は、STREAMは一度DMLを実行するとリセットされる仕様で、1タスクのトランザクション内でレコードを保持しておくためです。

こちらのタスクを起動しておくことで、ステージに非構造化データが置かれると同時に、その非構造化データにあったパイプライン処理が行われ、Cortex SearchやCortex Analystで利用できるようになります。

Snowflakeで非構造化データを扱えることの役立ちポイント

以上のことからも、最初にあげていた課題感を解決できるようになります。

  • 前処理の複雑さ: AI SQLを使うことで複雑な前処理もできる簡単さに。
  • 専用ツールの必要性: Snowflakeだけで非構造化データの活用もできる簡単さに。
  • データパイプライン構築の負担: いくつかのSQLを設計するだけで構築できるくらいの簡単さに。
  • スケーラビリティの課題: データパイプラインをフォーマット化することで、途中のプロンプトエンジニアリングを工夫する程度の簡単さに。

小ネタ

この記事で作成した非構造化データのデータパイプラインで作られるデータ基盤からは、Cortex SearchとCortex Analystの２つが作ることができ、それらを組み合わせることで社内データ×社内ドキュメントで多角的な分析を行ってくれるCortex Agentを作ることができます。

数値だけを見た分析
社内ドキュメント(ドメイン知識)も見た分析

Cortex Analystでは数値だけのデータで分析するしかできないところを、Cortex Searchでの社内ドキュメント(ドメイン知識)の探索も組み合わせた思考結果を返してくれるCortex Agentになりました。

個人的には、数値だけでは見えなかったところに、テキストデータから抽出した文脈情報(ドメイン知識)を数値分析の解釈に加えた上で、もっとも確率の高いデータの予測や出力結果を導き出しているというのが凄いと感じました。

ドメイン知識をすべてSnowflakeに入れれば、ドメイン知識が欠如していることで機械学習モデルの出力に説明ができない状態に悩まされるデータサイエンティストが救われますね。

まとめ

Snowflake Cortex AIを活用することで、従来は複雑だった非構造化データのデータパイプラインを、SQLベースで簡単に構築できるようになりました。これにより、企業は非構造化データも含めた包括的なデータ分析基盤をより簡単に構築・運用できるようになります。

この簡単さ・単純さ(SIMPLICITY)こそが、登壇イベントのみん強のテーマとも関係する、Snowflakeが最強のデータ分析基盤のアーキテクチャに選ばれる理由の一つだと私は思っています。

Discussion