[レポート] Snowflakeの半構造化データのネイティブサポートを利用したIoTデータの分析 #SnowflakeSummit

半構造化データ、恐るるに足らず
2021.06.23

大阪オフィスの玉井です。

日本時間の2021年6月9日~10日に、Snowflake Summit 2021が開催されました。

当記事では、Snowflake Summit 2021のセッションの中から、 Using Snowflake’s Support for Semi-Structured Data to Enable IoT Insights(Snowflakeの半構造化データサポートを利用してIoTデータを分析する)のレポートをお届けします。

概要

Today’s medical devices and therapies are increasingly digital. By centralizing device data and combining it with enterprise sources, such as SAP and Salesforce, Medtronic provides a better user experience to both patients and providers.

This presentation explains how telemetry data from Medtronic's StealthStation S8 devices paved the way for future Internet of Things use cases. Snowflake provides support for Medtronic’s キー requirements, including removing the need for capacity planning, cloud portability, diverse data sets, and varying geographic locations.

This session focuses on how Snowflake's VARIANT data type and SQL functionality for semi-structured data made this project successful and helped pave the way for supporting future data-enabled devices.

分析したい医療機器のデータがJSONだったが、Snowflakeの半構造データ用の関数を駆使すれば、構造化に変換できるぜ、という話です。

セッションレポート

※レポート本文のみ、一人称は登壇者を指します。

前段

私の名前はRyan Bossheartです。

今日はDave Reidyさんにお越しいただきました。Dave氏はMedtronic社のIntelligence and Innovation部門でシニアプログラムマネージャーを務めています。

また、本日はNick Hauschildさんにもお越しいただきました。Nick氏はphData社ata社のソリューションアーキテクトで、過去1年間Medtronic社と仕事をしてきました。

今日のセッションでは、Snowflakeに搭載されているデータエンジニアリング機能、特に半構造化データを扱う機能について説明します。私たちは、「私たちは、データエンジニアリングがコアの会社である」というphData社ata社を気に入っています。私たちの観察によると、これらの機能は非常に強力ですが、常に認識されているわけではありません。

そこで、これからお話しするのは、Snowflakeプラットフォームの中にあるデータエンジニアリング能力の一部です。データウェアハウスの機能やデータシェアリングなど、どれも非常に強力で、私たちが好んで使用する優れた機能です。しかし、ここ数年の間に、プラットフォームの機能が向上していることを実感しています。そのため、データインジェストやデータキュレーション、さらには半構造化データを扱うことがより重要になってきています。

先ほども言いましたが、phData社は、データエンジニアリングの会社です。今日のプレゼンテーションでは、ストリーミング・アプリケーションとバッチ・アプリケーションの両方を接続できるようにすることがテーマです。様々な方法でそれらを扱うことは、私たちが日々行っていることです。

それでは、本日のセッションのアジェンダをご紹介しましょう。

まず、Medtronic社についてや、Medtronic社内の機器やビジネスシステムの広範な状況について少し学び、次にこの機器、S8 StealthStationとは何か、この特定のプラットフォームとビジネス問題にどのようにアプローチしたかについて少し学びます。セールスフォース・ドットコムやSAPのような他のシステムもあります。しかし、今回のプレゼンテーションでは、何よりも半構造化データへの対応が重要になります。Nick氏はこの点にかなりの時間を割きます。そして、Medtronic社がこの半構造化データを使って得た結果や分析結果をご覧いただきます。

それでは、Dave氏に引き継いで、Medtronic社とS8 StealthStationについて、少しお話してもらいます。

Medtronic社とS8について

こんにちは。私の名前はDave Reidyです。私はMedtronic社のシニアプログラムマネージャーで、グローバルITの一部であるIntelligence and Innovation部門に所属しています。

まず最初に、Medtronic社のストーリーについて少しお話します。これはとても魅力的な話です。Earl Bakkenと義理の弟であるPalmerは、医療用電子機器を中心とした修理事業を始めました。そのため、Medtronic社という名前になったのですが、彼らは医療用電子機器を組み合わせて、今日のような世界的に知られた名前になったのです。

他の多くの大企業と変わらない感じですが、1949年、彼らはミネソタ州ミネアポリスにあるガレージで会社を立ち上げました。1957年、Medtronic社は初の電池式ペースメーカーを開発しました。残念ながら、1957年から今日までのすべての出来事を説明する時間は、あいにくありません。

しかし現在では、医療機器の中でも最大級の規模を誇っています。当社の製品ラインは、インスリンポンプ、心臓ステント、脳深部刺激システム、StealthStationなど多岐にわたっています。つまり、ほんの一例です。

今日、私たちの治療法は、年間7200万人以上の人々を助け、痛みを和らげ、健康を回復し、寿命を延ばすという私たちの使命を支えています。今日、Medtronic社は150カ国以上で世界中の人々の生活を向上させるために活動しています。 私たちは9万人以上の従業員がいます。

Medtronic社は、治療の手順やシステムレベルでのイノベーションを生み出し続けています。私たちは、データの多様性のために、全体のモダナイゼーションに取り組んでいます。私たちはクラウドに移行しています。それは、(システムの)スケーラビリティ、拡張性、回復力を向上させ、そして、データ消費能力を拡大することができるでしょう。

今日の技術的な議論の焦点は、StealthStation S8や、他のソースからのデータをSnowflake環境で結合させることにあります。

このStealthStation手術用ナビゲーションシステムは、手技中の手術器具の位置を正確に追跡することができます。このプロジェクトでは、現場で運用されている機器のデータを配信し、他のデータソースと組み合わせて、説明的分析と可視化を行います。

また、このプロジェクトは、将来的に他のデバイスからデータを取り込むためのフレームワークを構築する予定です。phData社ata社は、長い間Medtronic社と一緒に仕事をしてきました。特に、Snowflakeプロジェクトでは、Nickが具体的に説明するStealthStationのプロジェクトとしてだけでなく、Snowflakeの組織基盤の重要な部分を担ってきました。

データ分析基盤とS8の目標

私はphData社のソリューションアーキテクト、Nick Hauschildです。

このスライドにはphData社の詳細が記載されていますが、これを要約するとちょっと面白いかもしれません。 phData社はクラウドデータプラットフォームに特化したデータプロダクトサービス会社です。そして、SnowflakeのプロフェッショナルサービスプロバイダーとしてSnowflakeと提携しています。

それでは、そろそろS8アナリティクスプロジェクトの技術的な詳細をご紹介しましょう。

Medtronic社の事業では、現場でのS8デバイスの使用状況を知りたいと考えていました。

  • どのような手術が行われているのか?
  • 顧客はどのようなパターンでデバイスを使用しているのか?
  • どのようなライセンスが使用され、どのように使用されているのか?
  • そこに他の販売機会はあるのか?

これらの質問に答えるためには、S8のデバイスデータが必要であり、SalesforceやSAPからのビジネスデータと一緒にしたいと考えていました。ここでの目標は、phData社がデータパイプラインをエンジニアリングして、これらのデータをSnowflakeに取り込み、結合し、ディメンジョナルモデルに変換し、BIチームに提供して、さらなるビジュアライゼーションやダッシュボードの開発を行うことでした。

S8デバイスのデータをSnowflakeに取り込むことは、このプロジェクトで最もユニークな課題でした。各IoTデバイスは、手術や計画的な手順に使用されると、IoTプラットフォームの保存場所にステージングされたデータを書き出していました。私たちが行ったデータエンジニアリング作業では、このデータをSnowflake環境の外部ステージとして設定されたS3バケットに複製しました。この外部ステージに入ったデータは、Snowpipeがデータをロードするきっかけとなり、ニアリアルタイムにインジェストされます。このニアリアルタイムの取り込みプロセスは、今後のMedtronic社のIoT対応デバイスのデータ取り込みの基礎となるものです。

このような、デバイスデータの分析と変換は、彼らのプロジェクト内で方法を確立する必要があります。しかし、少なくとも、これらのデータを取り込むためのプロセスはすでに考えられていました。

これらのIoTデバイスは構造化されたデータを生成しているわけではなく、半構造化されたJSONファイルや、スキーマ定義が公開されていないJSONファイルを生成しています。このデータをビジネス要件に合わせて変換するには、その作業に適したツールを見つける必要があるかもしれませんし、そうでないかもしれません。

Snowflakeで半構造データのサポートについて

Snowflakeには、半構造化データのサポートが組み込まれています。Snowflakeの半構造化データのサポートは、データベース内で半構造化データを表現するためのデータ型から始まります。

VARIANT型は、オブジェクトや配列を含むあらゆる値を格納できるユニバーサルな型です。Objectは、キーと値(値)のペアのコレクションで、キーは文字列、値はそれ自体がVARIANTです。また、Array(配列)はVARIANTの順序付きコレクションです。JSONを知っている人であれば、これらはおなじみのアイデアに聞こえるはずです。ObjectはJSONオブジェクトに、ArrayはJSONのArrayに非常によく似ています。

半構造化データは、ファイルとしてSnowflakeにインジェストされることが多いようです。Snowflakeはファイルの取り込みをサポートしています。S3等にファイルをステージングする機能があります。

この例では、COPYコマンドで、VARIANT型を使用してデータをSnowflakeデータベースに取り込みます。左側のテーブルのDDL文はVARIANT型を使用していますが、ファイル名とファイル行のカラムも含まれています。これらの2つのフィールドを合わせると、VARIANT型の主キーのようなものになり、VARIANT構造を含むファイルの名前と、そのファイル内のVARIANT構造のインデックスになります。

複数のファイルがある場合は、copy intoコマンドで、ステージオブジェクトからクエリを実行して、このデータベースに適合するレコードを作成するための特別な構文の一部を示しています。ステージは、ステージの名前を識別するために先頭にアプリの記号を付けて参照します。そしてパディングは、そのオブジェクトストレージ内のどのファイルに対してクエリを実行するかを示します。そして、metadata$は、各ファイルのファイル名と行番号をテーブルに取得するために利用できます。

Snowflakeには、Objectや配列を移動するための演算子があります。

図では、最初のカラムの定義で、オブジェクトを移動するために一般的なドット表記を利用しています。その下では、ブラケット表記を使用したトラバーサルを示しており、引用されたフィールド名を提供しています。

また、コメントで、配列のインデックス演算子の例を示しています。もちろん、その式は配列を扱うものではないので、コメントアウトして、より説明的な目的のために置いておきました。これらのトラバーサル演算子は、よく知られたJSON構造をナビゲートする際に、簡潔な変換を行うのに非常に便利です。

右側には、さまざまな具体的な関数や関数のカテゴリーも並んでいます。配列やオブジェクトを複数の行に分解するFlatten関数(例では最後の行にあります)、文字列を分散に変換するPARSE関数、分散から特定の値を取り出すEXTRACT系関数、さまざまなデータ型を作成・変更するManipulation系関数。また、キャストや型チェックのための関数もたくさんあります。

S8のJSONデータを扱う

半構造化データ→構造化データ

ここからが本題です。

具体的には、Snowflakeで利用可能な半構造化データ用の関数を使用して、いくつかの自明でないJSONデータを、より構造化された形に変換します。どうすればいいでしょうか。

ここで注意していただきたいのは、このプレゼンテーションで見られる一日はすべて純粋なフィクションであり、データを処理する際に遭遇した状況の構造とほぼ一致しているということです。しかし、データの中の用語や値は完全に捏造されたものです。

前述したように、私たちが扱っているJSONファイルにはスキーマがなく、その過程では多くの発見がありました。

左図は、キーの種類が異なるオブジェクトの配列の例です。しかし、これらの多様なオブジェクトには、ある程度標準化されたサブオブジェクトが含まれています。しかしその中のサブオブジェクトにはすべてExitViewEnterViewフィールドがあります。これらをトラバーサル演算子で取得することは可能でしょうか?

もう一つの例は、キーが大きく変化するが、特定のフォーマットに従っているいくつかのオブジェクトです。具体的には、オブジェクトのキーは事実上、右のタイムスタンプになっています。タイムスタンプのキーの中には、オブジェクトの値を持つものと、文字列の値を持つものがあることに気づくでしょう。これらの例では、キーが既知ではなく可変であるため、一般的なパスを指定するためにVARIANTトラバーサル演算子を使用して処理するための些細な方法はありません。

課題その1

最初の課題である、VARIANTトラバーサル演算子を使わずに、ある程度標準化されたオブジェクトのセットを取得するには、いくつかのJSON関数を連結する必要があります。Flatten関数は、配列が与えられると、データセットを分解し、VARIANTのJSON配列の各行を、配列内の各要素に対応する0行以上の行に変換します。

このビューの例では、行を区切るために配列のインデックスを入れているのがわかります。つまり、この最初の行は、左の例の配列の最初のオブジェクトに対応しています。そして、明らかに、2番目はこれに対応し、残りはカットされています。

ここから、object_キーs関数で、提供されたJSONオブジェクトのキーの配列を返します。

これらのオブジェクトは、それぞれ1つのキーしか持っていません。ですから、このJSONオブジェクトにobject_キーs関数を適用すると、その1つのキーから始まる手続きだけの配列を得ることができます。Configureもそうです。イメージの読み込みも同様です。

get関数は、やや標準化されたサブオブジェクトの値を抽出するために使用することができます。

このケースでは、get 関数に VIEW_WRAPPERStartProcedure の最初の値、またはVIEW_キーの最初の値を指定して、そのキーにあるオブジェクトを取得します。ここから、VARIANTトラバーサル演算子を使って、EnterViewExitViewを別の列に抽出することができます。

課題その2

2つ目の課題である、タイムスタンプをキーにした値を取得するためには、WHERE句でデータをフィルタリングすることが必要でした。しかしその前に、Flatten関数を使って、データをもう一度分解する必要がありました。これは、JSONオブジェクトの観点から、1つの行を、オブジェクト内のキーと値のペアごとに1つずつ、0個以上の行に変えるものです。

KEYVALUEというカラムには、左の例のオブジェクトからのペアが含まれているのがわかります。ここではスペースを確保するために値は表示していませんが、大体こんな感じになっていると思います。他の2つの関数は、どちらもWHERE句で使用することができ、特定のタイプの値で行をフィルタリングすることができます。

今回のケースでは、try_to_timestamp関数は、データ型の違いに特化した関数ではありません。しかし、このような状況では、NULLチェックと組み合わせて使用すると便利です。

この関数をKEYカラムに適用すると、タイムスタンプを解析するキーを持つ行のみが表示されます。EnterViewExitViewSuccess、これらのキーはすべてタイムスタンプを解析していないので、WHERE句に基づく検索から除外されます。

残りの行の中には、オブジェクトの値を持つものと、文字列の値を持つものがあることに気づきます。つまり、is_object関数は、このデータセットをさらにフィルタリングして、オブジェクト値を持つキーと値のペアに絞り込むために使用されています。しかし、ここで私がしたことは実際にはそうではありません。

代わりに、SELECT文の式の中でオブジェクトを使って、PREPARE_ACTIONattemptでなければならないオブジェクトをハードコードし、オブジェクトでないものは文字列の値を報告しています。つまり、この場合、値のオブジェクトチェックはここでtrueを返すことになります。そして、実際のシナリオでは、これらの値はハードコードされて試行されます。3行目も4行目も同じです。しかし、2行目はオブジェクトがtrueではなく、文字列です。そのような状況では、そのツリーの値を報告するだけです。

色々な半構造化データ用の関数

JSONデータを必要な方法で処理するために、これらの関数をさまざまな方法で組み合わせれば、できることは多岐にわたります。また、これらの機能の一部を利用して、VARIANTデータ型の作成や操作を行うことも可能です。

ここでは、array_agg関数を使って、グループ毎に配列を作ることができます。この例では、ファイル名のviews1views2views3が何度も繰り返されているのがわかります。これをグループ化して、配列のarray_agg関数を適用します。

同じようなグループごとにマッピングされた値の配列が生成されます。 これは、object_agg関数でもできます。この場合も同様の結果が得られます。私が提供した例では、同じビュー、同じビュー名を利用していますが、代わりにインデックスをキーとして含んでいます。

今回はは紹介していませんが、他にも、配列に値を追加するarray_apend、2つの配列の交点を求めるarray_intersection、オブジェクトに新しいキーを追加するobject_insert、与えられたオブジェクトからサブオブジェクトを作成するobject_picなど、様々なデータ型を操作するために使用できる関数があります。

半構造化データを使用したビジュアライズ

最後に、これらの変換に使用された分析製品の一部をお見せしたいと思います。Snowflakeのパワーと様々なデータタイプのサポートにより、S8のデータやデバイスのデータを、複数のビジネスニーズを満たす数十のダッシュボードに変換することができました。このダッシュボードは、S8デバイスを使用して行われた外科手術の情報をまとめたもので、ビジネスで求められていた数多くのダッシュボードの一つです。もちろん、これはMedtronic社のデータであり、社内のダッシュボードです。

大きなグレーのボックスは、ビジネスオーナーが共有したくないアカウント情報やその他のビジネスデータを隠すためのものです。

これは、私たちがMedtronic社をどのように支援したかを示すものです。そして、これは私たちがあなたを助けたいということです。Snowflakeを使ったJSONの処理については、ここでたくさんお話しましたが、自分で学んだほうがいいでしょう。私たちはGitHubにリポジトリを構築し、自分のペースでこのデータを探索できるようにしました。下記には入門編があり、Snowflakeアカウントを取得して起動し、利用可能なデータのいくつかを見てみることができます。

これは、世の中にあるものの一部を示すものです。さらに、半構造化データに関してSnowflakeが提供しているリソースにもリンクしています。スライドにはいくつかのリンクがありますが、半構造化データのクエリについては、先ほど述べたトラバーサル演算子、ドット記法、ブラケット記法などについて説明しています。また、データタイプについても少し触れ、半構造化データの処理に利用できる関数の全リストを紹介しています。

以上、紹介してくれたDave氏に感謝するとともに、ここで皆さんと話をする機会を与えてくれたことに感謝します。

まとめ

Nickさん、Medtronic社との仕事や、Snowflake内の半構造化データの機能について、素晴らしい紹介をありがとうございました。

覚えておいていただきたいのですが、phData社では、データと機械学習のプロジェクトのみを行っています。その中でSnowflakeは非常に重要な役割を果たしており、私たちのサービスは主に4つのことを行っています。

まず、実用的なデータ戦略を立てることから始まります。これは、プロジェクトへの取り組み方を最初から設定し、適切な人材、適切なプロセス、適切な技術を前もって用意しておくことであり、その後、データエンジニアリングのワークストリームに移行することが多いです。

データエンジニアリングは、データをどのように取り込むか、ということです。最近では、コアデータプラットフォームにデータを取り込む際に、何百、何千ものデータパイプライン、何百、何千ものユーザーがデータエンジニアリング機能を構築しているお客様が増えています。この分野では、戦略面と実行面の両方で私たちがお手伝いできることがあります。

また、Snowflakeに搭載されている機械学習機能も成熟してきています。そのため、データサイエンティストや機械学習エンジニアが、機械学習モデルを効果的に開発できるようにしています。また、機械学習エンジニアリングとMLOps側では、データの取り込み、モデルの再構築、モデルの監視などの方法が規定されていることを確認しています。

また、ソフトウェアやプラットフォームは生きているものです。phData社は、クラウド環境を管理するマネージドサービスも提供しており、Snowflake上のユーザーをサポートするロールベースのアクセスコントロールを継続的に管理しています。これらのデータ・パイプラインがしっかりしていることを確認します。弊社がお手伝いできることがあれば、phdata.ioまでご連絡ください。

おわりに

Snowflakeの半構造化データ関連の機能の強さを思い知らされるセッションでした。Flatten関数だけでも、最初使った時は感動したものですが、他の関数も使うと、Snowflake上だけでJSONファイルの整形が完了できそうです。SQLでJSONファイルの整形が完結できるということは、Snowflakeと連携するツール(dbtやLooker)からでも、同様の操作ができるということで、半構造化データの整形のために、DWHにロードする前に色々処理を行う時代はそろそろ終わるかもしれません。

ちなみに、Medtronic社は、日本語のページもあったので、医療関係者の方には、よく知られている企業なのかもしれません(私は知りませんでした)。こういう医療機器が吐き出すデータも半構造データなんですね。