(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-02
(45)【発行日】2023-08-10
(54)【発明の名称】リアルタイム視覚シミュレーション内における動的インクリメンタルレコメンデーションのためのシステムおよび方法
(51)【国際特許分類】
G06F 16/25 20190101AFI20230803BHJP
G06F 16/17 20190101ALI20230803BHJP
G06N 5/04 20230101ALI20230803BHJP
【FI】
G06F16/25
G06F16/17 100
G06N5/04
【外国語出願】
(21)【出願番号】P 2021198486
(22)【出願日】2021-12-07
(62)【分割の表示】P 2018543176の分割
【原出願日】2017-08-22
【審査請求日】2021-12-13
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】アラン,デイビッド
(72)【発明者】
【氏名】ストジャノビク,アレクサンダー・サシャ
(72)【発明者】
【氏名】ナマルバー,ハッサン・ヘイダリ
(72)【発明者】
【氏名】シーサラマン,ガネーシュ
【審査官】甲斐 哲雄
(56)【参考文献】
【文献】特表2008-511935(JP,A)
【文献】国際公開第2016/049460(WO,A1)
【文献】特表2013-533995(JP,A)
【文献】特開2006-350464(JP,A)
【文献】米国特許出願公開第2008/0133768(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
G06N 5/00- 5/04
(57)【特許請求の範囲】
【請求項1】
データ統合またはその他のコンピューティング環境で使用される方法であって、前記方法は、
プロセッサを含むコンピュータが、データフローパイプラインの設計または管理のためのグラフィカルユーザインターフェイスを提供するステップを含み、前記データフローパイプラインは、
第1のデータセットを含む1つ以上のデータソースからのデータにアクセスしまたは前記データを受信し、
前記データを、第2のデータセットを含む1つ以上のデータターゲットに与えるように適合され、前記方法はさらに、
システムのナレッジソースと、前記ナレッジソースに格納され前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットを記述するメタデータとを参照することにより、1つ以上のデータ変換を決定するステップを含み、前記1つ以上のデータ変換は、前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットをマッピングし、前記第1のデータセットから前記データを入力として受信し、前記データを前記第2のデータセットに出力するように適合され、前記方法はさらに、
アクセスされた前記データの処理中に、前記データフローパイプラインの前記設計または管理に、選択して組み込むために、前記1つ以上のデータ変換の表示を、前記グラフィカルユーザインターフェイスに表示するステップ
と、
イベントコーディネータを提供するステップとを含み、前記イベントコーディネータは、前記1つ以上のデータソースから受信し前記データフローパイプラインおよび前記1つ以上のデータターゲットに与えた前記データの通知を含む、前記データフローパイプラインの前記設計または管理に対応付けられたイベントを、コーディネートするように動作する、方法。
【請求項2】
前記ナレッジソースに格納され前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットを記述する前記メタデータは、前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットをマッピングするために前記データフローパイプラインにおいて使用することが許可された前記1つ以上のデータ変換を決定する、請求項
1に記載の方法。
【請求項3】
前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットのうちの各々にアクセスし、
前記1つ以上のデータソースに含まれる前記
第1のデータセット
および前記1つ以上のデータターゲットに含まれる前記第2のデータセットをプロファイリングすることにより、前記ナレッジソースおよび前記1つ以上のデータ変換を修正するステップをさらに含み、前記ナレッジソースに示される前記1つ以上のデータ変換は、前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットをマッピングするように適合されている、請求項1
または2に記載の方法。
【請求項4】
前記データは、前記1つ以上のデータソースから、データのストリームとして受信される、請求項1~
3のいずれか1項に記載の方法。
【請求項5】
前記データは、前記1つ以上のデータソースから、データのバッチとして受信される、請求項1~
3のいずれか1項に記載の方法。
【請求項6】
前記方法は、クラウドコンピューティング環境において、クラウドサービスとして提供された前記1つ以上のデータソースから前記データを受信すること、または前記クラウドコンピューティング環境においてクラウドサービスとして提供された前記1つ以上のデータターゲットに前記データを出力することのうちの、少なくとも一方を行うために実行される、請求項1~
5のいずれか1項に記載の方法。
【請求項7】
データ統合またはその他のコンピューティング環境で使用されるソフトウェア開発コンポーネントを提供するためのシステムであって、前記システムは、
1つ以上のプロセッサを備え、前記1つ以上のプロセッサは、
データフローパイプラインの設計または管理のためのグラフィカルユーザインターフェイスを提供するように動作可能であり、前記データフローパイプラインは、
第1のデータセットを含む1つ以上のデータソースからのデータにアクセスしまたは前記データを受信し、
前記データを、第2のデータセットを含む1つ以上のデータターゲットに与えるように適合され、前記1つ以上のプロセッサはさらに、
前記システムのナレッジソースと、前記ナレッジソースに格納され前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットを記述するメタデータとを参照することにより、1つ以上のデータ変換を決定するように動作可能であり、前記1つ以上のデータ変換は、前記1つ以上のデータソースおよび
前記1つ以上のデータターゲットをマッピングし、前記第1のデータセットから前記データを入力として受信し、前記データを前記第2のデータセットに出力するように適合され、前記1つ以上のプロセッサはさらに、
アクセスされた前記データの処理中に、前記データフローパイプラインの前記設計または管理に、選択して組み込むために、前記1つ以上のデータ変換の表示を、前記グラフィカルユーザインターフェイスに表示
し、
イベントコーディネータを提供するように動作可能であり、前記イベントコーディネータは、前記1つ以上のデータソースから受信し前記データフローパイプラインおよび前記1つ以上のデータターゲットに与えた前記データの通知を含む、前記データフローパイプラインの前記設計または管理に対応付けられたイベントを、コーディネートするように動作する、システム。
【請求項8】
1つ以上のコンピュータに請求項1~
6のいずれか1項に記載の方法を実行させる、コンピュータ読取可能なプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
著作権に関する注意
本特許文献の開示の一部には、著作権保護の対象となるものが含まれている。著作権者は、この特許文献または特許開示の何者かによる複製が、特許商標庁の特許ファイルまたは記録にある限り、それに対して異議を唱えないが、そうでなければ、いかなる場合もすべての著作権を留保する。
【0002】
優先権の主張
本願は、2016年8月22日に出願され「SYSTEM AND METHOD FOR AUTOMATED MAPPING OF DATA TYPES BETWEEN CLOUD AND DATABASE SERVICES」と題された米国仮特許出願第
62/378,143号、2016年8月22日に出願され「SYSTEM AND METHOD FOR DYNAMIC, INCREMENTAL RECOMMENDATIONS WITHIN REAL-TIME VISUAL SIMULATION」と題され
た米国仮特許出願第62/378,146号、2016年8月22日に出願され「SYSTEM
AND METHOD FOR INFERENCING OF DATA TRANSFORMATIONS THROUGH PATTERN DECOMPOSITION」と題された米国仮特許出願第62/378,147号、2016年8月22日に出願
され「SYSTEM AND METHOD FOR ONTOLOGY INDUCTION THROUGH STATISTICAL PROFILING AND
REFERENCE SCHEMA MATCHING」と題された米国仮特許出願第62/378,150号、2016年8月22日に出願され「SYSTEM AND METHOD FOR METADATA-DRIVEN EXTERNAL INTERFACE GENERATION OF APPLICATION PROGRAMMING INTERFACES」と題された米国仮特許出
願第62/378,151号、および、2016年8月22日に出願され「SYSTEM AND METHOD FOR DYNAMIC LINEAGE TRACKING AND RECONSTRUCTION OF COMPLEX BUSINESS ENTITIES WITH HIGH-LEVEL POLICIES」と題された米国仮特許出願第62/378,152号に
基づく優先権を主張し、上記出願各々を本明細書に引用により援用する。
【0003】
発明の分野
本発明の実施形態は、概して各種ソースから得たデータを統合する方法に関し、具体的にはリアルタイム視覚シミュレーション内において動的インクリメンタルレコメンデーションを提供することに関する。
【背景技術】
【0004】
背景
現代のコンピューティング環境の多くは、大量のデータをさまざまなタイプのソフトウェアアプリケーション間で共有する機能を必要とする。しかしながら、分散アプリケーションは、たとえばサポートされるそれぞれのデータ型またはそれぞれの実行環境の相違のために、その構成が大幅に異なっている場合がある。アプリケーションの構成は、たとえば、そのアプリケーションプログラミングインターフェイス、ランタイム環境、デプロイ手法、ライフサイクル管理、またはセキュリティ管理に応じて異なり得る。
【0005】
このような分散アプリケーションの開発に使用されることを目的とするソフトウェアデザインツールは、リソース集中型の傾向があり、アプリケーションおよびデータ統合を管理するためにドメインモデル専門家のサービスを必要とすることが多い。その結果、さまざまな種類の実行環境の中でさまざまな種類のデータを統合するのに使用される複雑でスケーラブルな分散アプリケーションを構築するという課題に取り組むアプリケーション開発者は、一般的に、これらのアプリケーションの設計、構築、および構成のために多大な労力を費やさねばならない。
【発明の概要】
【0006】
概要
各種実施形態に従い、本明細書では、データの流れ(データフロー(dataflow)、DF)の管理および複合データフローソフトウェアアプリケーション(データフローアプリケーション、パイプライン)の構築に使用される機械学習(machine learning:ML、データフロー機械学習、DFML)を活用する、データ統合またはその他のコンピューティング環境において使用されるシステム(データ人工知能(Artificial Intelligence)システ
ム、データAIシステム)について説明する。ある実施形態に従うと、本システムは、本明細書においていくつかの実施形態ではパイプラインエディタまたはLambda Studio IDE
と呼ぶ、本システムで使用される視覚環境を提供するグラフィカルユーザインターフェイスとソフトウェア開発コンポーネントとを含み得る。これは、入力HUBからアクセスされたデータに対するセマンティックアクションの実行のために、上記データに対応付けられた意味またはセマンティクスの理解に基づいてリアルタイムレコメンデーションを提供することを含む。
【図面の簡単な説明】
【0007】
【
図1】ある実施形態に係る、データフロー人工知能を提供するシステムを示す図である。
【
図2】ある実施形態に係る、システムに使用するイベントコーディネータを含むイベント駆動型アーキテクチャを示す図である。
【
図3】ある実施形態に係る、データフロー内のステップを示す図である。
【
図4】ある実施形態に係る、複数のソースを含むデータフローの一例を示す図である。
【
図5】ある実施形態に係る、データフローをパイプラインとともに使用する例を示す図である。
【
図6】ある実施形態に係る、インジェスト/パブリッシュエンジンおよびインジェスト/パブリッシュサービスをパイプラインとともに使用する例を示す図である。
【
図7】ある実施形態に係る、HUBからのインジェストおよびトレーニングのプロセスを示す図である。
【
図8】ある実施形態に係る、モデルを構築するプロセスを示す図である。
【
図9】ある実施形態に係る、新たに追加されたHUBからのデータセットまたはエンティティを分類するプロセスを示す図である。
【
図10】ある実施形態に係る、新たに追加されたHUBからのデータセットまたはエンティティを分類するプロセスをさらに示す図である。
【
図11】ある実施形態に係る、新たに追加されたHUBからのデータセットまたはエンティティを分類するプロセスをさらに示す図である。
【
図12】ある実施形態に係る、関数型分類に使用するオブジェクト図を示す図である。
【
図13】ある実施形態に係る、ディメンション関数型分類の一例を示す図である。
【
図14】ある実施形態に係る、キューブ関数型分類の一例を示す図である。
【
図15】ある実施形態に係る、ビジネスエンティティの関数型を評価するための関数型分類の使用の一例を示す図である。
【
図16】ある実施形態に係る、関数変換に使用するオブジェクト図を示す図である。
【
図17】ある実施形態に係る、レコメンデーションエンジンの動作を示す図である。
【
図18】ある実施形態に係る、データレイクの使用を示す図である。
【
図19】ある実施形態に係る、データ駆動型戦略を使用してデータレイクを管理することを示す図である。
【
図20】ある実施形態に係る、プロセス駆動型戦略を使用してデータレイクを管理することを示す図である。
【
図21】ある実施形態に係る、パイプラインコンパイラの使用を示す図である。
【
図22】ある実施形態に係る、パイプライングラフの一例を示す図である。
【
図23】ある実施形態に係る、データパイプラインの一例を示す図である。
【
図24】ある実施形態に係る、データパイプラインの別の例を示す図である。
【
図25】ある実施形態に係る、オーケストレーションパイプラインの一例を示す図である。
【
図26】ある実施形態に係る、オーケストレーションパイプラインの一例をさらに示す図である。
【
図27】ある実施形態に係る、メッセージングシステムを含むコーディネーションファブリックの使用を示す図である。
【
図28】ある実施形態に係る、メッセージングシステムを含むコーディネーションファブリックの使用をさらに示す図である。
【
図29】ある実施形態に係る、システムに使用するオンプレミスエージェントを示す図である。
【
図30】ある実施形態に係る、データフロープロセスを示す図である。
【
図31】ある実施形態に係る、データ型の自動マッピングを示す図である。
【
図32】ある実施形態に係る、マッピングの生成のための自動マップサービスを示す図である。
【
図33】ある実施形態に係る、ソーススキーマとターゲットスキーマとの間のマッピングの一例を示す図である。
【
図34】ある実施形態に係る、ソーススキーマとターゲットスキーマとの間のマッピングの別の例を示す図である。
【
図35】ある実施形態に係る、データ型の自動マッピングを提供するプロセスを示す図である。
【
図36】ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するシステムを示す図である。
【
図37】ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するグラフィカルユーザインターフェイスを示す図である。
【
図38】ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するグラフィカルユーザインターフェイスをさらに示す図である。
【
図39】ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するプロセスを示す図である。
【
図40】ある実施形態に係る、1つ以上のアプリケーション各々ごとに生成された1つ以上の関数式(functional expression)についてデータフロー内の変換のパターンを特定する手段を示す図である。
【
図41】ある実施形態に係る、1つ以上の関数式についてデータフロー内の変換のパターンを特定する例を示す図である。
【
図42】ある実施形態に係る、1つ以上のアプリケーション各々ごとに生成された1つ以上の関数式についてデータフロー内の変換のパターンを特定する際に使用するオブジェクト図を示す図である。
【
図43】ある実施形態に係る、1つ以上のアプリケーション各々ごとに生成された1つ以上の関数式についてデータフロー内の変換のパターンを特定するプロセスを示す図である。
【
図44】ある実施形態に係る、関数型ルールを生成するシステムを示す図である。
【
図45】ある実施形態に係る、関数型ルールを生成するシステムをさらに示す図である。
【
図46】ある実施形態に係る、関数型ルールの生成に使用するオブジェクト図を示す図である。
【
図47】ある実施形態に係る、生成された1つ以上のルールに基づいて関数型システムを生成するプロセスを示す図である。
【
図48】ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定するためのシステムを示す図である。
【
図49】ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定することを示す図である。
【
図50】ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定することをさらに示す図である。
【
図51】ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定するプロセスを示す図である。
【
図52】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理を示す図である。
【
図53】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
【
図54】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
【
図55】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
【
図56】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
【
図57】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
【
図58】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
【
図59】ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理のプロセスを示す図である。
【発明を実施するための形態】
【0008】
詳細な説明
これまでの説明は、他の実施形態およびその特徴とともに、明細書および請求項を含む以下の記載ならびに添付の図面を参照することによって明らかになるであろう。以下の記載では、説明を目的とする具体的な詳細事項が、本発明のさまざまな実施形態の十分な理解を得るために記載されている。しかしながら、さまざまな実施形態はこれらの具体的な詳細事項なしで実施できることは明らかであろう。明細書および請求項を含む以下の記載ならびに添付の図面は、限定することを意図したものではない。
【0009】
はじめに
各種実施形態に従い、本明細書では、データの流れ(データフロー、DF)の管理およ
び複合データフローソフトウェアアプリケーション(データフローアプリケーション、パイプライン)の構築に使用される機械学習(ML、データフロー機械学習、DFML)を活用する、データ統合またはその他のコンピューティング環境において使用されるシステム(データ人工知能システム、データAIシステム)について説明する。
【0010】
ある実施形態に従うと、このシステムは、本明細書においていくつかの実施形態ではHUBと呼ぶ1つ以上のデータソースまたはデータターゲット間における、複合データ構造、データセットまたはエンティティの自動マッピングに対するサポートを提供することができる。自動マッピングは、メタデータ、スキーマ、およびデータセットの統計プロファイリングによって駆動することができ、自動マッピングを使用することにより、入力HUBに対応付けられたソースデータセットまたはエンティティを、ターゲットデータセットまたはエンティティに、またはその逆にマッピングして、1つ以上の出力HUBで使用されるフォーマットまたは組織(プロジェクション)で準備された出力データを生成することができる。
【0011】
ある実施形態に従うと、このシステムは、本明細書においていくつかの実施形態ではパイプラインエディタまたはLambda Studio IDEと呼ぶ、上記システムで使用される視覚環
境を提供するグラフィカルユーザインターフェイスと、ソフトウェア開発コンポーネントとを含み得る。これは、入力HUBからアクセスされたデータに対するセマンティックアクションの実行のために、当該データに対応付けられた意味またはセマンティクスの理解に基づいてリアルタイムレコメンデーションを提供することを含む。
【0012】
ある実施形態に従うと、このシステムは、ソフトウェアアプリケーションのデータフローの関数分解から特定されたパターンに基づいて、入力データに対するアクションおよび変換をレコメンドするためのサービスを提供することができ、これは、後のアプリケーションにおいて上記データフローに可能な変換を判定することを含む。データフローは、データの変換、述語、およびデータに適用されるビジネスルールを記述するモデルと、データフロー内で使用される属性とに分解することができる。
【0013】
ある実施形態に従うと、このシステムは、スキーマ定義のオントロジー解析を実行することにより、このスキーマに対応付けられたデータおよびデータセットまたはエンティティそれぞれのタイプを判別し、データセットまたはエンティティとそれらの属性との関係に基づいて規定されたオントロジーを含むリファレンススキーマからモデルを生成またはアップデートすることができる。1つ以上のスキーマを含むリファレンスHUBを用いてデータフローを解析し、さらに、分類する、または、たとえば、入力データの変換、エンリッチ化、フィルタリング、もしくはクロスエンティティデータ融合等の、レコメンデーションを行うことができる。
【0014】
ある実施形態に従うと、このシステムは、本明細書においていくつかの実施形態では他言語関数インターフェイスと呼ぶプログラマティックインターフェイスを提供する。このインターフェイスにより、ユーザまたは第三者は、サービス、関数型およびビジネス型、セマンティックアクション、ならびに関数型およびビジネス型に基づくパターンまたは予め定められた複合データフローを、宣言的に規定することにより、システムの機能を拡張することができる。
【0015】
ある実施形態に従うと、このシステムはデータガバナンス機能を提供することができる。これはたとえば、特定のスナップショットに時間的に関連するデータのスライスごとの、履歴情報(provenance)(特定のデータはどこから来たデータか)、系統(lineage)
(このデータはどのようにして取得/処理されたか)、セキュリティ(誰がこのデータの責任者だったか)、分類(このデータは何に関連するデータか)、影響力(impact)(こ
のデータがビジネスにどれほどの影響があるか)、保持時間(retention)(このデータ
はどれだけの時間存続すべきか)、および有効性(このデータは解析/処理のために除外される/含まれるべきか否か)である。よって、これらはライフサイクルの決定およびデータフローのレコメンデーションにおいて使用することができる。
【0016】
ある実施形態に従うと、このシステムは、サービスとして、たとえばクラウドベースのコンピューティング環境内で提供されるクラウドサービスとして実現することができ、設計、シミュレーション、デプロイ、開発、オペレーション、およびソフトウェアアプリケーションに使用するデータの解析のための単一のコントロールポイントの役割を果たすことができる。これは、1つ以上のデータソース(たとえばある実施形態では入力HUB)からのデータ入力を有効にすること、このデータ用のアプリケーションをユーザが指定できるようにするグラフィカルユーザインターフェイスを提供すること、および、目的とするデータの宛先、用途、またはターゲット(たとえばある実施形態では出力HUB)に応じてデータをスケーリングすることを含む。
【0017】
ある実施形態に従うと、本明細書において、特定のHUBとの関連で使用されるときの「入力」および「出力」という用語は、特定のユースケースまたは例におけるデータの明白な流れを反映するラベルとしてのみ提供されるのであって、特定のHUBの種類または機能を制限することを意図している訳ではない。
【0018】
たとえば、ある実施形態に従うと、データのソースとして機能する入力HUBは、同時にまたは別の時に、出力HUBとしてまたはこのデータもしくは別のデータを受信するターゲットとしても機能することができ、その逆も可能である。
【0019】
加えて、例示のために本明細書に記載の例のうちのいくつかは入力HUBおよび出力HUBの使用を示しているが、ある実施形態に従うと、実際の実装例においてデータ統合またはその他のコンピューティング環境はこのようなHUBを複数含み得る。これらのうちの少なくともいくつかは、入力HUBおよび/または出力HUB双方として機能する。
【0020】
ある実施形態に従うと、このシステムにより、大規模な、たとえばクラウドベースのコンピューティング環境において、ソフトウェアアプリケーションを急速に開発することができる。このような環境において、データモデルは急速に発展するであろう。また、たとえばサーチ、レコメンデーション、または提案等の特徴は有用なビジネス条件である。このような環境において、人工知能(AI)とセマンティックサーチとを組合わせることにより、ユーザに対して、彼らの既存のシステムを用いてより多くを達成する権限を与える。たとえば、属性レベルマッピング等の統合インタラクションを、メタデータ、データ、およびシステムとのユーザのやり取りの理解に基づいてレコメンドすることができる。
【0021】
ある実施形態に従うと、このシステムを用いることにより、複雑なケースを提案することもできる。それはたとえば、情報解析に使用することができ、かつ、それらのデータ内の今まで知られていなかった事実をユーザが発見できるようにする、興味深いディメンションエッジ(dimensional edge)である。
【0022】
いくつかの実施形態において、このシステムはグラフィカルユーザインターフェイスを提供する。このグラフィカルユーザインターフェイスは、マニュアルタスク(たとえばレコメンデーションまたは提案)の自動化を可能にし、機械学習および確率的な知識の統合を活用することにより、ユーザにとって有用なコンテキストを提供するとともに、発見およびセマンティック駆動型のソリューションを可能にすることができる。それはたとえば、データウェアハウスの作成、サービスのスケーリング、データの作成およびエンリッチ化、ならびにソフトウェアアプリケーションの設計およびモニタリングである。
【0023】
各種実施形態に従うと、本システムは、以下の特徴のうちの一部またはすべてを含むまたは利用することができる。
【0024】
設計時システム:ある実施形態に係る、たとえば機械学習機能を提供するデータAIサブシステムの使用を含む、ソフトウェアアプリケーション(たとえばデータフローアプリケーション、パイプライン、またはLambdaアプリケーション)の設計、作成、モニタリング、および管理を可能にする計算環境。
【0025】
実行時システム:ある実施形態に係る、ソフトウェアアプリケーション(たとえばデータフローアプリケーション、パイプライン、またはLambdaアプリケーション)の実行を可能にし、入力を設計時システムから受けてレコメンデーションを設計時システムに提供する計算環境。
【0026】
パイプライン:ある実施形態に係る、複数の段またはセマンティックアクションを有する処理パイプラインを規定する宣言手段。複数の段またはセマンティックアクションは各々、出力データとして作成するための、入力データのたとえばフィルタリング、結合、エンリッチ化、変換、またはフュージョンのうちの1つ以上等の機能に対応する。たとえばDFMLにおけるデータフローを表すデータフローソフトウェアアプリケーションまたはデータフローアプリケーション。ある実施形態に従うと、システムは、バッチ(履歴)データ処理にもリアルタイム(ストリーミング)データ処理にも同一のコードベースを(たとえばSpark実行時プラットフォームとともに)使用できる宣言型パイプライン設計をサ
ポートし、また、リアルタイムデータ解析のためにリアルタイムデータストリームに対して作業することができるパイプラインまたはアプリケーションの構築もサポートする。パイプラインの設計変更に伴うデータの再処理は、デプロイされたパイプラインのアップグレードのローリングを通して処理することができる。ある実施形態に従うと、パイプラインは、異なるバッチレイヤおよびリアルタイムレイヤ内のリアルタイムデータとバッチデータの処理に対応することができるLambdaアプリケーションとして提供することができる。
【0027】
HUB:ある実施形態に係る、データセットまたはエンティティを含むデータソースまたはターゲット(クラウドまたはオンプレミス)。イントロスペクトすることができるデータソースであって、このデータソースからデータを消費することができる、または、データをこのデータソースに対してパブリッシュすることができる。データソースはデータセットまたはエンティティを含み、これは属性、セマンティクス、またはその他のデータセットまたはエンティティとの関係を有する。HUBの例は、ストリーミングデータ、遠隔測定、バッチベース、構造化もしくは非構造化、またはその他のタイプのデータソースを含む。データは、ソースデータセットまたはエンティティに対応付けられたHUBから受信することができ、同じまたは別のHUBのターゲットデータセットまたはエンティティにマッピングすることができる。
【0028】
システムHUB:ある実施形態に従うと、システムHUBは、他のHUBに対応付けることができる他のメタデータおよびプロファイル情報ならびにデータセットまたはエンティティを上記他のメタデータに格納するナレッジソースとして機能することができ、また、処理対象のデータのソースまたは受信者としてのレギュラーHUBのように機能することもできる。たとえばDFMLにおける、メタデータおよびシステムの状態が管理される中央リポジトリである。
【0029】
データセット(エンティティ):ある実施形態に係る、属性(たとえばカラム)を含むデータ構造。これは、1つ以上のHUBによって所有されるまたは1つ以上のHUBに対
応付けることができる、たとえばデータベーステーブル、ビュー、ファイル、またはAPIである。ある実施形態に従うと、1つ以上のビジネスエンティティ、たとえば顧客記録であり、セマンティックビジネス型として機能することができ、データコンポーネントとして格納される、たとえばHUB内のテーブルである。データセットまたはエンティティは、属性たとえばテーブル内のカラム、および、データ型たとえばストリングまたは整数とともに、その他のデータセットまたはエンティティとの関係を有することができる。ある実施形態に従うと、当該システムは、たとえばエンリッチ化、準備、変換、モデルトレーニング、またはスコアリング動作中、すべてのタイプのデータ(たとえば構造化、半構造化、または非構造化データ)の、スキーマに依存しない処理をサポートする。
【0030】
データAIサブシステム:ある実施形態に係る、たとえばデータAIシステム等のシステムのコンポーネントであり、機械学習およびセマンティック関連機能を担う。これは、サーチ、プロファイリング、レコメンデーションエンジンの提供、または自動マッピングのサポートのうちの1つ以上を含む。データAIサブシステムは、イベントコーディネータを介して、設計時システムたとえばLambda Studio等のソフトウェア開発コンポーネン
トの動作をサポートすることができ、データフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)によるデータの連続処理に基づいてレコメンデーションを提供することにより、たとえば、既存のたとえばパイプラインの修正をレコメンドして処理中のデータを活用することができる。データAIサブシステムは、入力データの量を解析し連続的にドメインナレッジモデルをアップデートすることができる。データフローアプリケーション(たとえばパイプライン)の処理中、たとえばパイプラインの各段は、データAIサブシステムが提供するレコメンドされた代案または選択肢に基づいて、アップデートされたドメインモデルおよびユーザからの入力を処理することにより、たとえば、レコメンドされたセマンティックアクションを受容または拒否することができる。
【0031】
イベントコーディネータ:ある実施形態に係る、設計時システムと実行時システムとの間で動作するイベント駆動型アーキテクチャ(event-driven architecture:EDA)コ
ンポーネントであり、データフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)の設計、作成、モニタリング、および管理に関連するイベントをコーディネートする。たとえば、イベントコーディネータは、HUBからデータ(たとえば既知のデータ型に従う新たなデータ)のパブリッシュされた通知を受信し、このHUBからのデータを正規化し、正規化したデータを、サブスクライバのセットに対し、たとえばパイプラインまたはその他の下流のコンシューマによる使用のために、提供する。また、イベントコーディネータは、システム内の状態トランザクションの通知を、一時スライスの作成およびスキーマ進化を含む、系統トラッキングまたはロギングに使用するために、受信することもできる。
【0032】
プロファイリング:ある実施形態に係る、HUBからデータのサンプルを抽出し、このHUBから提供されたデータ、ならびにこのHUB内のデータセットまたはエンティティおよび属性をプロファイリングするとともに、HUBのサンプリングに関連するメトリクスを決定し、HUBに関連するメタデータをアップデートすることによりデータのプロファイルをこのHUBに反映させる動作。
【0033】
ソフトウェア開発コンポーネント(Lambda Studio):ある実施形態に係る、グラフィ
カルユーザインターフェイスを提供することにより、セマンティックアクションのパイプラインとしてのLambdaアプリケーションまたはパイプラインのライフサイクルをユーザが作成、モニタリング、および管理できるようにする、設計時システムツール。たとえばパイプラインやLambdaアプリケーションをユーザが設計できるようにするグラフィカルユーザインターフェイス(UI、GUI)またはスタジオ。
【0034】
セマンティックアクション:ある実施形態に係る、データ変換関数、たとえば関係代数演算。データフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)が、HUB内のデータセットまたはエンティティに対し、別のエンティティへのプロジェクションのために実行できるアクション。セマンティックアクションは、データセット入力を受信しデータセット出力を生成できる異なるモデルまたはHUBに使用可能な高次関数として機能する。セマンティックアクションはマッピングを含み得る。セマンティックアクションは、たとえばパイプラインまたはLambdaアプリケーションの一部としてのデータの処理に応じて、たとえばデータAIサブシステムによって連続的にアップデート可能なマッピングを含み得る。
【0035】
マッピング:ある実施形態に係る、たとえばデータAIサブシステムによって提供され、設計時システムを通して、たとえばソフトウェア開発コンポーネントであるLambda Studioを介してアクセス可能にされた、第1の(たとえばソース)データセットまたはエン
ティティと別の(たとえばターゲット)データセットまたはエンティティとの間のセマンティックアクションのリコメンドされるマッピングである。たとえば、データAIサブシステムはサービスとして自動マッピングを提供することができる。自動マッピングは、HUBに対応付けられたメタデータまたはデータ入力の機械学習解析に基づいて、メタデータ、スキーマ、およびデータセットの統計プロファイリングにより駆動することができる。
【0036】
パターン:ある実施形態に係る、データフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)が実行できるセマンティックアクションのパターン。テンプレートを使用することにより、他のアプリケーションが再利用できるパターンの定義を提供することができる。通常ビジネスセマンティクスおよびプロセスに関連付けられるデータおよび関連する変換の論理フロー。
【0037】
ポリシー:ある実施形態に係る、データフローアプリケーション、たとえばパイプライン、Lambdaアプリケーションが如何にしてスケジュールされるか、どのユーザまたはコンポーネントがどのHUBおよびセマンティックアクションにアクセスできるか、ならびにデータは如何にしてエージングされるべきか、またはその他の検討事項を制御する一組のポリシー。如何にしてたとえばパイプラインがたとえばスケジュール、実行、またはアクセスされるべきかを規定するコンフィギュレーション設定。
【0038】
アプリケーション設計サービス:ある実施形態に従うと、データフローたとえばパイプライン、Lambdaアプリケーション向けのサービスたとえば検証、コンパイル、パッケージング、その他のたとえばDFMLサービス(たとえばUI、システムファサード)へのデプロイ等を提供する。ソフトウェア開発コンポーネントたとえばLambda Studio(たとえ
ばその入力および出力)におけるパイプラインたとえばLambdaアプリケーションを検証し、パイプラインを永続化(persist)し、パイプライン、Lambdaアプリケーションを実行
のためにシステムに(たとえばSparkクラスタに)デプロイすることを制御し、その後、
アプリケーションのライフサイクルまたは状態の管理に使用できる、設計時システムコンポーネント。
【0039】
エッジレイヤ:ある実施形態に係る、データを収集したとえば格納および転送レイヤとしてスケーラブル入出力レイヤにデータを転送するレイヤ。インターネットにアクセス可能なたとえばゲートウェイを介してデータを受信することができ、たとえばデータAIシステムへの安全なアクセスをサポートするセキュリティおよびその他の特徴を含む1つ以上のノードを含む実行時システムコンポーネント。
【0040】
計算レイヤ:ある実施形態に係る、アプリケーション実行およびデータ処理レイヤ(例
:Spark)。分散処理コンポーネント、たとえばSparkクラウドサービス、計算ノードのクラスタ、仮想マシンの集合体、またはその他のコンポーネントもしくはノードとして機能し、例としてパイプライン、Lambdaアプリケーションの実行に使用される、実行時システムコンポーネント。マルチテナント環境において、計算レイヤ内のノードは、テナントに対して、これらのテナントによるパイプラインまたはLambdaアプリケーションの実行において使用されるために、割り当てることができる。
【0041】
スケーラブル入出力(I/O)レイヤ:ある実施形態に従うと、トピックおよびパーティションとして構成されたスケーラブルデータパーシステンスおよびアクセスレイヤを提供する(例:Kafka)。データを、システム内で移動できるようにし、システムのさまざ
まなコンポーネント間で共有できるようにする、キューまたはその他論理ストレージを提供する実行時システムコンポーネント、たとえばKafka環境。マルチテナント環境におい
て、スケーラブルI/Oレイヤは複数のテナント間で共有できる。
【0042】
データレイク:ある実施形態に係る、システムHUBまたはその他のコンポーネントからの情報のパーシステンスのリポジトリ。通常は、例としてパイプライン、Lambdaアプリケーションによって正規化または処理され、その他のパイプライン、Lambdaアプリケーションまたはパブリッシュレイヤによって消費される、例としてDFMLにおけるデータのリポジトリ。
【0043】
レジストリ:ある実施形態に係る、例としてパイプライン、Lambdaアプリケーションをそれらの関数コンポーネントに分解するのに使用される、例として関数型およびビジネス型の格納のための、1つ以上の情報リポジトリ。
【0044】
データフロー機械学習(DFML):ある実施形態に係る、機械学習(ML)を活用することにより複合データフローアプリケーションの構築を支援する、データ統合、データフロー管理システム。
【0045】
メタデータ:ある実施形態に係る、データセットまたはエンティティおよび属性ならびにそれらの関係の、根底にある定義、記述。例としてDFMLにおけるアーティファクトに関する記述データでもあり得る。
【0046】
データ:ある実施形態に係る、データセットまたはエンティティによって表されるアプリケーションデータ。これらはバッチでもストリームでもよい。たとえば、顧客、オーダー、または製品。
【0047】
システムファサード:ある実施形態に係る、例としてDFMLイベント駆動型アーキテクチャの機能にアクセスするための統一APIレイヤ。
【0048】
データAIサブシステム:ある実施形態に従うと、限定されないがたとえばサーチ、自動マップ、レコメンデーション、またはプロファイリングを含む人工知能(AI)サービスを提供する。
【0049】
ストリーミングエンティティ:ある実施形態に係る、データの速度の強調をサポートし得る、データおよび準リアルタイム処理および出力条件の連続入力。
【0050】
バッチエンティティ:ある実施形態に係る、ボリュームの強調によって特徴付けることができる、スケジュールされたまたはリクエストに応じて実施されるデータのインジェスチョン。
【0051】
データスライス:ある実施形態に係る、通常は時間によってマークされるデータのパーティション。
【0052】
ルール:ある実施形態に従うと、例としてDFMLにおけるアーティファクトを左右するディレクティブを表し、たとえば、データルール、関係ルール、メタデータルール、および複合またはハイブリッドルールである。
【0053】
レコメンデーション(データAI):ある実施形態に係る、例としてパイプライン、Lambdaアプリケーションの設計を支援するための1つ以上のセマンティックアクションまたはきめ細かいディレクティブによって通常表される、推奨される一連のアクション。
【0054】
サーチ(データAI):ある実施形態に係る、関連するアーティファクトを返すための、コンテキストおよびユーザの意図によって特徴付けられる、例としてDFMLにおけるセマンティックサーチ。
【0055】
自動マップ(データAI):ある実施形態に係る、データフローで試用されることになる候補ソースまたはターゲットデータセットもしくはエンティティをショートリストに入れるある種のリコメンデーション。
【0056】
データプロファイリング(データAI):ある実施形態に係る、データセットまたはエンティティに属する属性におけるデータを特徴付けるいくつかのメトリクスの、たとえば最小値、最大値、四分位数間領域、または散在度の、集合体。
【0057】
アクションパラメータ:ある実施形態に係る、セマンティックアクションの実行対象であるデータセットに対するリファレンス。たとえば、例としてパイプライン、Lambdaアプリケーションにおける等価結合(equi-join)に対するパラメータ。
【0058】
他言語関数インターフェイス:ある実施形態に係る、例としてDFML Lambdaアプリケーションフレームワークの一部としてサービス(およびセマンティックアクション)を登録し呼び出すメカニズム。例としてDFMLにおける機能または変換語彙を拡張するのに使用できる。
【0059】
サービス:ある実施形態に係る、データ統合段(たとえば準備、発見、変換、または視覚化)によって特徴付けることができるセマンティックアクションの集合体の、例としてDFMLにおける未対応のアーティファクト。
【0060】
サービスレジストリ:ある実施形態に係る、サービス、それらのセマンティックアクションおよびその他のインスタンス情報のリポジトリ。
【0061】
データライフサイクル:ある実施形態に係る、インジェスチョンで始まりパブリッシュで終わる、例としてDFML内のデータの使用における段。
【0062】
メタデータハーベスティング:ある実施形態に係る、通常はHUBの登録後に、プロファイリングのためにメタデータおよびサンプルデータを収集すること。
【0063】
パイプライン正規化:ある実施形態に係る、例としてパイプライン、Lambdaアプリケーションによる消費を容易にする特定のフォーマットでデータを標準化すること。
【0064】
モニタリング:ある実施形態に係る、例としてパイプライン、Lambdaアプリケーションの実行を、特定、測定、および評価すること。
【0065】
インジェスト:ある実施形態に係る、例としてDFMLにエッジレイヤを通してデータを取り込むこと。
【0066】
パブリッシュ:ある実施形態に係る、例としてDFMLからデータをターゲットエンドポイントに書き込むこと。
【0067】
データAIシステム
図1は、ある実施形態に係る、データフロー人工知能を提供するためのシステムを示す図である。
【0068】
図1に示すように、ある実施形態に従うと、システム、たとえばデータAIシステム150は、たとえばビジネスデータ、消費者データ、および企業データ等のデータを処理および変換するための1つ以上のサービスを提供することができ、これは、たとえばデータベース、クラウドデータウェアハウス、ストレージシステム、またはストレージサービス等の多様な計算アセットとともに使用される機械学習処理の使用を含む。
【0069】
ある実施形態に従うと、計算アセットは、クラウドベースであっても企業ベースであってもオンプレミスもしくはエージェントベースであってもよい。このシステムのさまざまな要素は1つ以上のネットワーク130によって接続することができる。
【0070】
ある実施形態に従うと、このシステムは、1つ以上の入力HUB110(たとえばデータのソース、データソース)と、出力HUB180(たとえばデータのターゲット、データターゲット)とを含み得る。
【0071】
ある実施形態に従うと、各入力HUB、たとえばHUB111は、複数の(ソース)データセットまたはエンティティ192を含み得る。
【0072】
ある実施形態に従うと、入力HUBの例は、データベース管理システム(DB、DBMS)112(たとえばオンライントランザクション処理システム(on-line transaction processing system:OLTP)、ビジネスインテリジェンスシステム、またはオンライ
ン解析処理システム(on-line analytical processing system:OLAP))を含み得る。このような例において、たとえばデータ管理システム等のソースが提供するデータは、構造化データであっても半構造化データであってもよい。
【0073】
ある実施形態に従うと、入力HUBの他の例は、非構造化データを有するオブジェクトバケットまたはクリックストリームソースであってもよいクラウドストア/オブジェクトストア114(たとえばAWS S3または別のオブジェクトストア)、データクラウド116(たとえば第三者クラウド)、ストリーミングデータソース118(たとえばAWSキネティックスまたは別のストリーミングデータソース)、またはその他入力ソース119を含み得る。
【0074】
ある実施形態に従うと、入力HUBはデータソースを含み得る。データソースは、たとえばOracle Big Data Prep (BDP)サービスからデータを受ける。
【0075】
ある実施形態に従うと、このシステムは1つ以上の出力HUB180(たとえば出力宛先)を含み得る。各出力HUB、たとえばHUB181は、複数の(ターゲット)データセットまたはエンティティ194を含み得る。
【0076】
ある実施形態に従うと、出力HUBの例は、パブリッククラウド182、データクラウ
ド184(たとえばAWSおよびAzure)、オンプレミスクラウド186、またはその他
の出力ターゲット187を含み得る。このシステムが提供するデータ出力は、出力HUBにおいてアクセス可能なデータフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)のために生成することができる。
【0077】
ある実施形態に従うと、パブリッククラウドの例として、たとえばOracle Public Cloudを挙げることができる。これは、たとえば、Big Data Prepクラウドサービス、Exadata
クラウドサービス、Big Data Discoveryクラウドサービス、およびBusiness Intelligenceクラウドサービスを含み得る。
【0078】
ある実施形態に従うと、このシステムは、サービスとして(たとえばサービスとしてのソフトウェアとして)ユーザに配信される、ストリーミングおよびオンデマンド(バッチ)データ処理のための統一されたプラットフォームとして実現することができ、複数の入力HUBのためのスケーラブルなマルチテナントデータ処理を提供する。データは、機械学習技術と、サービスの一部としてグラフィカルユーザインターフェイスによって提供される視覚的洞察およびモニタリングとを用いて、リアルタイムで解析される。データセットは、出力HUBへの出力のために複数の入力HUBからフュージングすることができる。たとえば、このシステムが提供するデータ処理サービスを通して、データをデータウェアハウス用に生成し1つ以上の出力HUBにポピュレートすることができる。
【0079】
ある実施形態に従うと、このシステムは、データの変換、エンリッチ化、ルーティング、分類、およびブレンドのために宣言型およびプログラミングトポロジを提供し、設計時システム160と実行時システム170とを含み得る。ユーザは、データ処理の実行用に設計された、たとえばデータフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)190等のアプリケーションを作成することができる。
【0080】
ある実施形態に従うと、設計時システムは、ユーザが、データフロー処理用に、データフローアプリケーションを設計し、データフローを規定し、データを規定できるようにすることができる。たとえば、設計時システムは、データフローアプリケーションの作成のためにグラフィカルユーザインターフェイスを提供するソフトウェア開発コンポーネント162(本明細書ではある実施形態においてLambda Studioと呼ぶ)を提供することがで
きる。
【0081】
たとえば、ある実施形態に従うと、ユーザは、ソフトウェア開発コンポーネントを用いて、アプリケーション用のデータフローを作成するために入力HUBおよび出力HUBを指定することができる。グラフィカルユーザインターフェイスは、データ統合用のサービスのためのインターフェイスを示すことができる。これにより、ユーザは、アプリケーション用のデータフローを作成、操作、および管理することができる。これはデータフローパイプラインを動的にモニタリングおよび管理する機能を含み、それはたとえばデータ系統を観察することおよび法解析を実行すること等である。
【0082】
ある実施形態に従うと、設計時システムはまた、データフローアプリケーションを実行時システムにデプロイするためのアプリケーション設計サービス164を含み得る。
【0083】
ある実施形態に従うと、設計時システムはまた、データフローを処理するためにメタデータを格納するための1つ以上のシステムHUB166(たとえばメタデータリポジトリ)を含み得る。1つ以上のシステムHUBは、データのサンプル、たとえば関数型およびビジネスデータ型を含むデータ型等のデータのサンプルを格納することができる。システムHUB内の情報を用いることにより、本明細書に開示する技術のうちの1つ以上を実行することができる。データレイク167コンポーネントは、システムHUBからの情報の
パーシステンスのためにリポジトリとして動作することができる。
【0084】
ある実施形態に従うと、設計時システムはまた、データ人工知能処理のための動作を実行するデータ人工知能(AI)サブシステム168を含み得る。上記動作は、ML技術、たとえばサーチおよび取出を使用することを含み得る。データAIサブシステムは、システムHUB用のメタデータを生成するためにデータをサンプリングすることができる。
【0085】
ある実施形態に従うと、データAIサブシステムは、入力HUBごとに、スキーマオブジェクト解析、メタデータ解析、サンプルデータ、相関解析、および分類解析を実行することができる。データAIサブシステムは、入力されたデータに対して連続的に実行することにより、リッチデータをデータフローアプリケーションに提供することができ、かつ、たとえばパイプライン、Lambdaアプリケーションに、レコメンデーション、洞察、およびタイプ誘導を提供することができる。
【0086】
ある実施形態に従うと、設計時システムにより、ユーザは、ユースケースの機能的要求を規定するポリシー、アーティファクト、およびフローを作成することができる。
【0087】
たとえば、ある実施形態に従うと、設計時システムは、グラフィカルユーザインターフェイスを提供することにより、HUBを作成してデータをインジェストしインジェストポリシーを規定することができる。インジェストポリシーは、時間ベースであってもよく、または、関連するデータフローからの要求に応じたものであってもよい。入力HUBが選択されると、データをこの入力HUBからサンプリングすることにより、ソースをプロファイリングすることができる。これはたとえば、メタデータクエリを実行すること、サンプルを取得すること、およびユーザ定義入力を取得すること等である。プロファイルはシステムHUBに格納することができる。グラフィカルユーザインターフェイスは、データフローパイプラインを規定するために複数のソースを結合できるようにする。これは、スクリプトを作成することによって、または、ガイドされたエディタを用いることによって行うことができる。ガイドされたエディタによりデータを各ステップで視覚化することができる。グラフィカルユーザインターフェイスは、データクラウドを如何にしてたとえば修正、エンリッチ化、または結合し得るかを示唆するレコメンデーションサービスへのアクセスを提供することができる。
【0088】
ある実施形態に従うと、設計時間中、アプリケーション設計サービスは、得られたコンテンツを解析するのに適した構造を示唆することができる。アプリケーション設計サービスは、ナレッジサービス(関数型分類)を用いることにより、処置および関連するディメンション階層を示唆することができる。これが完了すると、設計時システムは、先のパイプラインからのブレンドされたデータを取得しディメンションターゲット構造をポピュレートするのに必要なデータフローをレコメンドすることができる。依存性解析に基づいて、オーケストレーションフローを導き出して生成することにより、ターゲットスキーマをロード/リフレッシュすることもできる。フォワードエンジニアリングユースケースの場合、設計時システムは、HUBを生成することにより、ターゲット構造をホストしターゲットスキーマを作成することもできる。
【0089】
ある実施形態に従うと、実行時システムは、データ処理のためのサービスの実行時間中に処理を実行することができる。
【0090】
ある実施形態に従うと、実行時または動作モードにおいて、ユーザが作成したポリシーおよびフローの規定が適用および/または実行される。たとえば、このような処理は、インジェスト、変換、モデル、およびパブリッシュサービスを呼び出してパイプライン内でデータを処理することを含み得る。
【0091】
ある実施形態に従うと、実行時システムは、エッジレイヤ172と、スケーラブル入出力(I/O)レイヤ174と、分散処理システムまたは計算レイヤ176とを含み得る。実行時において(たとえば1つ以上の入力HUB110からデータがインジェストされたときに)、イベントのためにエッジレイヤがデータを受けることができる。このイベントによってデータは生成される。
【0092】
ある実施形態に従うと、イベントコーディネータ165は、設計時システムと実行時システムとの間で動作して、データフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)の設計、作成、モニタリング、および管理に関連するイベントを調整する。
【0093】
ある実施形態に従うと、エッジレイヤは、データをスケーラブル入出力レイヤに送る。スケーラブル入出力レイヤはこのデータを分散処理システムまたは計算レイヤにルーティングする。
【0094】
ある実施形態に従うと、分散処理システムまたは計算レイヤは、パイプラインプロセスを(テナント毎に)実現することにより、データを出力のために処理することができる。分散処理システムは、たとえばApache SparkおよびAlluxioを用いて実現することができ
、データをデータレイクにサンプリングしその後このデータを出力HUBに出力することができる。分散処理システムは、データを起動して処理するためにスケーラブル入出力レイヤと通信することができる。
【0095】
ある実施形態に従うと、上記コンポーネントのうちのいくつかまたはすべてを含むデータAIシステムは、たとえば1つ以上のプロセッサ(CPU)とメモリとパーシステント記憶装置(198)とを含む1つ以上のコンピュータに提供することができる、またはこのコンピュータによって実行されることができる。
【0096】
イベント駆動型アーキテクチャ
先に述べたように、ある実施形態に従うと、このシステムは、イベント駆動型アーキテクチャ(EDA)コンポーネントまたはイベントコーディネータを含み得る。これは、設計時システムと実行時システムとの間で動作することにより、データフローアプリケーション(たとえばパイプライン、Lambdaアプリケーション)の設計、作成、モニタリング、および管理に関連するイベントを調整する。
【0097】
図2は、ある実施形態に係る、システムで使用するイベントコーディネータを含むイベント駆動型アーキテクチャを示す図である。
【0098】
図2に示すように、ある実施形態に従うと、イベントコーディネータは、イベントキュー202(たとえばKafka)と、イベントブートストラッパサービス204(たとえばExecutorService)と、イベントコンフィギュレーションパブリッシャ/イベントコンシューマ206(たとえばDBCS)とを含み得る。
【0099】
ある実施形態に従うと、システムファサード208(たとえばイベントAPI拡張)で受信したイベントは、1つ以上のイベントブローカー210、たとえばKafkaコンシュー
マによって、システムのさまざまなコンポーネントに伝達することができる。たとえば、例として外部データ212(たとえばS3、OSCS、またはOGGデータ)等のデータおよび/またはイベント、または、グラフィカルユーザインターフェイス214(たとえばブラウザまたはDFML UI)からの入力は、イベントコーディネータを介して、その他のコンポーネント、たとえば上述のアプリケーション実行時216、データレイク、
システムHUB、データAIサブシステム、アプリケーション設計サービス、および/またはインジェスト220、パブリッシュ230、スケジューリング240、またはその他のコンポーネントに、伝達することができる。
【0100】
ある実施形態に従うと、イベントブローカーを、ストリームイベントのコンシューマとして構成してもよい。イベントブートストラッパは、複数の構成されたイベントブローカーを開始させることにより、登録されたサブスクライバに代わってイベントを処理することができる。所定のイベントの処理のために、各イベントブローカーは、イベントの処理を、登録されたコールバックエンドポイントに委任する。イベントコーディネータは、イベントタイプの登録、イベンティングエンティティの登録、イベントの登録、およびサブスクライバの登録を可能にする。表1は、パブリッシュイベントおよびサブスクライブイベントを含むさまざまなイベントオブジェクトの一例を提供する。
【0101】
【0102】
イベントタイプ
ある実施形態に従うと、イベントタイプは、システムにとって重要なイベントの状態変化を規定する。それはたとえば、HUBの作成、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションの修正、データセットまたはエンティティのためのデータのインジェスト、またはターゲットHUBに対するデータのパブリッシュ等である。データフォーマットの一例と、さまざまなイベントタイプの例を、以下と表2に示す。
【0103】
【0104】
イベンティングエンティティ
ある実施形態に従うと、イベンティングエンティティは、イベントのパブリッシャおよび/またはサブスクライバであってもよい。たとえば、イベンティングエンティティは、1つ以上のイベントをパブリッシュするために登録することができる、および/または1つ以上のイベントのコンシューマとなることができる。これは、パブリッシュに対するアクノレッジを通知または送信しサブスクライブされたイベントの処理を委任するのに使用される、エンドポイントまたはコールバックURLの登録を含む。イベンティングエンティティの例は、メタデータサービス、インジェストサービス、システムHUBアーティファクト、およびパイプライン、Lambdaアプリケーションを含み得る。データフォーマットの一例と、さまざまなイベンティングエンティティの例を、以下と表3に示す。
【0105】
【0106】
イベント
ある実施形態に従うと、イベントは、パブリッシャとして登録されたイベンティングエンティティに対応付けられたイベントタイプのインスタンスであり、サブスクライバ(イベンティングエンティティ)を有し得る。たとえば、メタデータサービスは、パブリッシュのためにHUB作成イベントを登録することができ、このイベント用のイベントインスタンス(作成したHUB1つ当たり1つのインスタンス)のうち1つ以上をパブリッシュすることができる。さまざまなイベントの例が表4に示される。
【0107】
【0108】
例
ある実施形態に従うと、以下の例は、イベントタイプの作成、パブリッシュイベントの登録、サブスクライバの登録、イベントのパブリッシュ、イベントタイプの取得、イベントタイプのためのパブリッシャの取得、およびイベントタイプのためのサブスクライバの取得を示す。
【0109】
【0110】
これは、ユニバーサル一意ID(universally unique ID:UUID)、たとえば「8e8
7039b-a8b7-4512-862c-fdb05b9b8888」を返す。イベンティングオブジェクトは、システ
ム内のイベントをパブリッシュまたはサブスクライブすることができる。たとえばインジェストサービス、メタデータサービス、およびアプリケーション設計サービス等のサービスエンドポイントは、アクノレッジ、通知、エラー、または処理のためにスタティックなエンドポイントとともに、パブリッシュまたはサブスクライブイベントであってもよい。DFMLアーティファクト(たとえばDFMLEntity, DFMLLambdaApp, DFMLHub)も、イベンティングオブジェクトとして登録することができ、これらのタイプのインスタンスは、イベンティングオブジェクトとしての登録なしでイベントをパブリッシュまたはサブスクライブすることができる。
【0111】
【0112】
以下の例は、DFMLLambdaApps(タイプ)をイベンティングオブジェクトとして登録する。
【0113】
【0114】
HUB、EntityおよびLambdaAppタイプのイベンティングエンティティの場合、<publisherURL>をRESTエンドポイントURLにアノテートすることができ、イベント駆動型
アーキテクチャは、実際のURLを、DFMLアーティファクトインスタンスURLを置換することによって導き出す。たとえば、notificationEndpointURLが、http://den00tnk:9021/<publisherURL>/notificationとして登録され、メッセージの一部として特定され
たパブリッシャURLがhubs/1234/entities/3456である場合、通知のために呼び出され
るURLは、http://den00tnk:9021/ hubs/1234/entities/3456 /notificationであろう
。POSTはUUID、たとえば「185cb819-7599-475b-99a7-65e0bd2ab947」を返す。
【0115】
パブリッシュイベントの登録
ある実施形態に従うと、パブリッシュイベントは次のように登録できる。
【0116】
【0117】
上記eventTypeは、イベントタイプDATA_INGESTEDの登録のために返されるUUIDであり、上記publishingEntityは、イベンティングオブジェクトとして登録されるDFMLEntityタイプである。この登録は、UUID、たとえば「2c7a4b6f-73ba-4247-a07a-806ef659def5」を返す。
【0118】
サブスクライバの登録
ある実施形態に従うと、サブスクライバは次のように登録できる。
【0119】
【0120】
パブリッシュイベント登録から返されたUUIDは、サブスクライバの登録のための経路セグメントとして使用される。
【0121】
【0122】
上記publisherURLおよびpublishingObjectTypeは、パブリッシャオブジェクトのインスタンスおよびタイプである。ここで、データフロー(たとえばLambda)アプリケーションは、URI /lambdaApps/123456の特定において、エンティティ /hubs/1234/entities/3456からのDATA_INGESTEDイベントへのサブスクライブに注目する。この登録はUUID
、たとえば「1d542da1-e18e-4590-82c0-7fe1c55c5bc8」を返す。
【0123】
イベントのパブリッシュ
ある実施形態に従うと、イベントは以下のようにパブリッシュすることができる。
【0124】
【0125】
上記publisherURLは、パブリッシュオブジェクトが、DFMLEntity、DFMLHubまたはDFMLLambdaAppsのうちの1つである場合に使用され、サブスクライバが参加するメッセージを
パブリッシュするイベンティングオブジェクトのインスタンスをチェックするために使用される。また、パブリッシャURLは、サブスクライバがメッセージの処理に成功したときに通知URLを導き出すために使用される。このパブリッシュは、パブリッシュされたイベントの一部であったメッセージ本体を返す。
【0126】
イベントタイプの取得
ある実施形態に従うと、イベントタイプは以下のように求めることができる。
【0127】
【0128】
イベントタイプ用のパブリッシャを取得
【0129】
【0130】
イベントタイプ用のサブスクライバを取得
ある実施形態に従うと、イベントタイプ用のサブスクライバは以下のように求めることができる。
【0131】
【0132】
上記説明は、イベントコーディネータ、イベントタイプ、イベンティングエンティティ、およびイベントの特定の実施形態を説明するために、一例として示したものである。他の実施形態に従うと、他の種類のEDAを用いて、設計時システムと実行時システムとの間で機能するシステム内における通信を提供することにより、データフローアプリケーションの設計、作成、モニタリング、および管理に関するイベントを調整することができ、他の種類のイベントタイプ、イベンティングエンティティ、およびイベントをサポートすることができる。
【0133】
データフロー機械学習(DFML)のフロー
先に述べたように、各種実施形態に従うと、本システムは、データのフロー(データフロー、DF)の管理および複合データフローソフトウェアアプリケーション(たとえばデータフローアプリケーション、パイプライン、Lambdaアプリケーション)の構築に用いられる機械学習(ML、データフロー機械学習、DFML)を活用する、データ統合またはその他のコンピューティング環境で使用することができる。
【0134】
図3は、ある実施形態に係る、データフロー内のステップを示す図である。
図3に示すように、ある実施形態に従うと、DFMLデータフロー260の処理は、インジェストステップ262を含む複数のステップを含み得る。インジェストステッにおいて、データを、さまざまなソース、たとえばSalesforce(SFDC)、S3、またはDBaaSから、インジェストすることができる。
【0135】
データ準備ステップ264において、インジェストされたデータを、たとえば、重複排除、標準化、またはエンリッチ化することによって準備することができる。
【0136】
変換ステップ266において、本システムは、1以上のマージ、フィルタ、またはデータセットのルックアップを実行することにより、データを変換することができる。
【0137】
モデルステップ268において、1つ以上のモデルが、当該モデルに対するマッピングとともに生成される。
【0138】
パブリッシュステップ270において、本システムは、モデルをパブリッシュし、ポリシーおよびスケジュールを特定し、ターゲットデータ構造をポピュレートすることができる。
【0139】
ある実施形態に従うと、本システムは、そのデータ準備ステップ、変換ステップ、およびモデルステップ各々の全体を通して、サーチ/レコメンド機能272の使用をサポートする。ユーザは、データ統合フレームワーク内に機能の幅が封じ込められた一組の明確に規定されたサービスを通して、システムとのやり取りを行うことができる。この一組のサービスは、システムの論理ビューを規定する。たとえば、設計モードにおいて、ユーザは、特定のユースケースの機能的要求を規定するフロー、アーティファクト、およびポリシーを作成することができる。
【0140】
図4は、ある実施形態に係る、複数のソースを含むデータフローの一例を示す図である。
【0141】
図4に示す一例としてのデータフロー280に示されるように、ある実施形態に従うと、必要なのは、ここではSFDCおよびFACS(Fusion Apps Cloud Service)として
示されている複数のソース282からのコンテンツを、OSCS(Oracle Storage Cloud
Service)内のいくつかのファイルとともに取り込んで、この情報を、所望のコンテンツの解析に使用できるようにブレンドし、ターゲットキューブおよびディメンションを導き出し、ブレンドしたコンテンツをターゲット構造にマッピングし、このコンテンツがディメンションモデルとともにオラクル・ビジネス・インテリジェンス・クラウドサービス(Oracle Business Intelligence Cloud Service:BICS)環境で使用できるようにすることであり、これは、インジェスト、変換266A/266B、モデル、オーケストレート292、およびデプロイ294ステップを含む。
【0142】
示されている例は、本明細書に記載の技術を説明するために提供され、本明細書に記載の機能は、これら特定のデータソースとともに使用することに限定されない。
【0143】
ある実施形態に従うと、インジェストステップにおいて、SFDCコンテンツにアクセスしこれをインジェストするために、HUBがデータレイクにおいて作成されてこのコンテンツを受ける。これは、たとえば、関連するアクセスモード(JDBC、REST、SOAP)のSFDCアダプタを選択し、HUBを作成し、名称を与え、時間ベースの、または関連するデータフローの要求に応じたインジェストポリシーを規定することによって、実施することができる。
【0144】
ある実施形態に従うと、その他2つのソースについて同様のプロセスを実行することができる。違いは、OSCSソースの場合、スキーマは、開始時点でわかっていない場合があり、代わりに何らかの手段(たとえばメタデータクエリ、サンプリング、またはユーザ規定)によって取得できる点である。
【0145】
ある実施形態に従うと、データのソースを、任意でプロファイリングすることにより、さらに調査することができる。これは、統合フローにおいて後にレコメンデーションを導き出すのに役立ち得る。
【0146】
ある実施形態に従うと、次のステップは、如何にして別々のソースを中心アイテムの周りで結合するかを規定することである。これは、典型的には解析の基礎(ファクト)であり、データフローパイプラインを規定することによって実現できる。これは、直接、パイプラインドメイン固有言語(DSL)スクリプトを作成することによって、または、ガイドされたエディタを用いて、行うことができる。ガイドされたエディタの場合、ユーザは、各ステップでデータに対する効果を知ることができ、データを如何にしてたとえば修正、エンリッチ化、結合できるかを示唆するレコメンデーションサービスを使用することができる。
【0147】
この時点で、ユーザは、システムが、得られたコンテンツを解析するのに適した構造を示唆することを、要求できる。たとえば、ある実施形態に従うと、システムは、ナレッジサービス(関数型分類)を用いることにより、対策および関連するディメンション階層を示唆することができる。これが完了すると、システムは、先のパイプラインからのブレンドされたデータを取得しディメンションターゲット構造をポピュレートするのに必要なデータフローをレコメンドすることができる。これはまた、依存性解析に基づいて、オーケストレーションフローを導き出して生成することにより、ターゲットスキーマをロード/リフレッシュする。
【0148】
ある実施形態に従い、本システムは次に、ターゲット構造をホストするHUBを生成し、これを、アダプタを介して、ターゲットスキーマを作成するのに必要なデータ定義言語(data definition language:DDL)を生成するDBCSに対応付け、たとえば、新たに作成されたスキーマにアクセスするのに必要なモデルを生成するのにBICSが使用できるXDMLまたは何らかの形態をデプロイすることができる。これは、オーケストレーションフローを実行し排出(exhaust)サービスをトリガすることによってポピュレート
することができる。
【0149】
図5は、ある実施形態に係る、パイプラインを有するデータフローの使用の一例を示す図である。
【0150】
図5に示すように、ある実施形態に従うと、本システムにより、ユーザは、この例ではパイプラインステップS1~S5を含むデータフローを表すパイプライン302を規定することにより、アプリケーションとして構築/実行304されるときのデータの処理を記述することができる。
【0151】
たとえば、ある実施形態に従うと、ユーザは、インジェスト、変換、モデル、およびパブリッシュサービス、またはその他のサービスたとえばポリシー306、実行310、またはパーシステンスサービス312を呼び出して、パイプライン内のデータを処理することができる。また、ユーザは、ソリューション(すなわちコントロールフロー)を規定することにより、関連するパイプラインを統合することができる統一フローを特定することもできる。典型的に、ソリューションは、完全なユースケースたとえば売上キューブおよび関連するディメンションのローディングをモデル化する。
【0152】
データAIシステムコンポーネント
ある実施形態に従うと、アダプタは、さまざまなエンドポイントへの接続およびさまざまなエンドポイントからのデータのインジェストを可能にし、アプリケーションまたはソースタイプに固有である。
【0153】
ある実施形態に従うと、本システムは、予め定められたアダプタのセットを含み得る。これらのアダプタのうちのいくつかは、他のSOAアダプタを活用することができ、追加のアダプタをフレームワークに登録できるようにする。所定の接続タイプに対して2つ以上のアダプタがあってもよい。その場合、インジェストエンジンは、HUBの接続タイプ構成に基づいて最も適したアダプタを選択する。
【0154】
図6は、ある実施形態に係る、インジェスト/パブリッシュエンジンおよびインジェスト/パブリッシュサービスの使用の一例を示す図である。
【0155】
図6に示すように、ある実施形態に従うと、パイプライン334は、インジェスト/パブリッシュエンジン330に、インジェスト/パブリッシュサービス332を介してアクセスすることができる。パイプライン334は、この例において、データ(たとえば売上データ)を入力HUB(たとえばSFDC HUB1)からインジェストし336、インジェストしたデータを変換し338、このデータを出力HUB(たとえばOracle HUB)に対してパブリッシュする340ように、設計されている。
【0156】
ある実施形態に従うと、インジェスト/パブリッシュエンジンは、複数の接続タイプ331をサポートする。これらのタイプの1つである接続タイプ342は、HUBへのアクセスを提供する1つ以上のアダプタ344に対応付けられている。
【0157】
たとえば、
図6の例に示されるように、ある実施形態に従うと、SFDC接続タイプ352は、SFDC HUB358および359へのアクセスを提供するSFDC-Adp1アダプタ354およびSFDC-Adp2アダプタ356に対応付けることができ、ExDaaS接続タイプ362は、ExDaas HUB366へのアクセスを提供するExDaaS-Adpアダプタ364に対応付けることができ、Oracle接続タイプ372は、Oracle HUB376へのアクセスを提供するOracle Adpアダプタ374に対応付けることができる。
【0158】
レコメンデーションエンジン
ある実施形態に従うと、本システムは、データに対して実行できる可能ないくつかのアクションの中から最も関連性が高いものを予測/示唆する専門フィルタリングシステムとして動作するレコメンデーションエンジンまたはナレッジサービスを含み得る。
【0159】
ある実施形態に従うと、レコメンデーションを連結することにより、ユーザが所定の最終ゴールを達成するためにこれらのレコメンデーションを辿り易くすることができる。たとえば、レコメンデーションエンジンは、データセットをデータキューブに変換してターゲットBIシステムに対してパブリッシュするときの一組のステップを通してユーザを案内することができる。
【0160】
ある実施形態に従うと、レコメンデーションエンジンは、(A)ビジネス型分類、(B)関数型分類、および(C)ナレッジベースという3つの側面を利用する。データセットまたはエンティティに対するオントロジー管理およびクエリ/サーチ機能は、たとえば、クエリAPI、MRSおよび監査リポジトリとの、YAGO3に由来する共有オントロジーによって、提供することができる。ビジネスエンティティ分類は、たとえば、ビジネス型を識別するMLパイプラインベースの分類によって提供することができる。関数型分類は、たとえば、演繹的なルールベースの関数型分類によって提供することができる。アクションレコメンデーションは、たとえば、帰納的なルールベースのデータ準備、変換、モデル、依存性、および関連するレコメンデーションによって提供することができる。
【0161】
分類サービス
ある実施形態に従うと、本システムは、ビジネス型分類と関数型分類とにカテゴライズできる分類サービスを提供する。各々について以下でさらに説明する。
【0162】
ビジネス型分類
ある実施形態に従うと、エンティティのビジネス型はその表現型(phenotype)である
。エンティティ内の個々の属性の観測可能な特性は、エンティティのビジネス型の特定において、定義と同様に重要である。分類アルゴリズムは、データセットまたはエンティティの概略的定義を使用するが、データを用いて構築したモデルを利用してデータセットまたはエンティティのビジネス型を分類することもできる。
【0163】
たとえば、ある実施形態に従うと、HUBからインジェストされたデータセットは、システムが知っている既存のビジネス型(メインHUBからシードされたもの)のうちの1つとして分類することができる、または、既存のビジネス型に分類できない場合は新たな型として追加することができる。
【0164】
ある実施形態に従うと、ビジネス型分類は、レコメンデーションを行う際に、帰納的推論(パイプライン内の類似するビジネス型に対して規定された変換からの)、または、分類ルートエンティティから導出された単純な命題に基づいて、利用される。
【0165】
概要を述べる。ある実施形態に従うと、分類プロセスは以下の一組のステップによって説明される。これらのステップは、メイン(トレーニング)hubからインジェストしシードするステップ、モデルを構築しカラム統計を計算しこれらを分類に使用するために登録するステップ、プロファイルの作成/カラム統計の計算を含む、新たに追加されたhubからのデータセットまたはエンティティを分類するステップ、データセットまたはエンティティを分類して、構造およびカラム統計に基づき、使用するエンティティモデルのショートリストを提供するステップ、ならびに、マルチクラス分類を含むデータセットまたはエンティティを分類し、モデルを用いて計算/予測するステップである。
【0166】
図7は、ある実施形態に従う、HUBからのインジェストおよびトレーニングのプロセスを示す図である。
【0167】
図7に示すように、ある実施形態に従うと、HUB382(たとえばこの例ではRelatedIQソース)からのデータは、レコメンデーションエンジン380が、データセット390(たとえばレジリエント分散データセット(Resilient Distributed Dataset
:RDD)として読み出すことができる。このデータセットは、この例では、アカウントデータセット391、イベントデータセット392、コンタクトデータセット393、リストデータセット394、およびユーザデータセット395を含む。
【0168】
ある実施形態に従うと、複数の型分類ツール400を、MLパイプライン402とともに使用することができる。たとえば、GraphX404、Wolfram/Yago406、および/またはMLlib統計408は、HUBが最初に登録されたときにナレッジグラフ440にエンティティメタデータ(トレーニングまたはシードデータ)をシードする際に使用することができる。
【0169】
ある実施形態に従うと、データセットまたはエンティティメタデータおよびデータは、ソースHUBからインジェストされデータレイクに格納される。モデル生成410中、エンティティメタデータ(属性および他のエンティティとの関係)は、たとえばFP-growthロジスティック回帰412を通して、モデル420およびナレッジグラフの生成に使用される。ナレッジグラフは、すべてのデータセットまたはエンティティ、この例で
はイベント422、アカウント424、コンタクト426、およびユーザ428を表す。シードの一部として、回帰モデルをデータセットまたはエンティティデータを用いて構築し、属性統計(最小値、最大値、平均値、または確率密度)を計算する。
【0170】
図8は、ある実施形態に係る、モデル構築プロセスを示す図である。
図8に示すように、ある実施形態に従うと、たとえばSpark環境430内で実行する場合、Spark MLlib統計を用いて、ナレッジグラフに属性プロパティとして追加されたカラム統計を計算することができる。計算したカラム統計を、他のデータセットまたはエンティティメタデータとともに用いて、その回帰モデルが分類の新たなエンティティのテストにおいて使用されるエンティティを、ショートリストに入れることができる。
【0171】
図9は、ある実施形態に係る、新たに追加されたHUBからのデータセットまたはエンティティを分類するプロセスを示す図である。
【0172】
図9に示すように、ある実施形態に従うと、新たなHUB、この例ではOracle HUB442が追加されると、このHUBから提供されたデータセットまたはエンティティ、たとえば当事者情報444および顧客情報446が、モデルにより、先に作成されたトレーニングまたはシードデータに基づいて、当事者448として分類される。
【0173】
たとえば、ある実施形態に従うと、カラム統計を、新たなデータセットまたはエンティティのデータから計算し、エンティティのサブグラフを表す一組の述語(predicate)を
、この情報を、インジェストの一部として利用できる他のメタデータとともに用いて、作成する。
【0174】
ある実施形態に従うと、カラム統計の計算は、最尤推定(maximum likelihood estimation:MLE)法において有用であり、一方、サブグラフはデータセットの回帰モデルに
おいて有用である。新たなエンティティのために生成された一組のグラフ述語を用いて、新たなエンティティのテストおよび分類のために、候補エンティティモデルをショートリストに入れる。
【0175】
図10は、ある実施形態に係る、新たに追加されたHUBからのデータセットまたはエンティティを分類するプロセスをさらに示す図である。
【0176】
図10に示すように、ある実施形態に従うと、分類対象である、新たなデータセットまたはエンティティのサブグラフを表す述語を、既にナレッジグラフの一部であるデータセットまたはエンティティを表す同様のサブグラフと比較する450。一致の確率に基づく一致するエンティティのランキングを、新たなエンティティの分類のためのテストで使用するエンティティモデルをショートリストに入れる際に使用する。
【0177】
図11は、ある実施形態に係る、新たに追加されたHUBからのデータセットまたはエンティティを分類するプロセスをさらに示す図である。
【0178】
図11に示すように、ある実施形態に従うと、ショートリストに入れた一致するデータセットまたはエンティティの回帰モデルを、新たなデータセットまたはエンティティからのデータのテストに使用する。MLパイプラインを拡張して追加の分類方法/モデルを包含することにより、プロセスの精度を改善することができる。分類サービスは、許容可能な閾値、たとえばこの例では0.8よりも高い確率以内に一致がある場合、新たなエントリを分類する452。そうでなければ、このデータセットまたはエンティティを新たなビジネス型としてナレッジグラフに追加することができる。また、ユーザは、結果を受容ま
たは拒否することによって分類を検証することができる。
【0179】
関数型分類
ある実施形態に従うと、エンティティの関数型はその遺伝子型(genotype)である。関数型は、それを通して変換アクションが規定されるインターフェイスとして説明することもできる。たとえば、結合変換またはフィルタは、この場合はリレーショナルエンティティ等の関数型で規定される。要約すると、すべての変換は、パラメータとしての関数型で規定される。
【0180】
図12は、ある実施形態に係る、関数型分類に使用するオブジェクト図を示す図である。
【0181】
オブジェクト
図460による
図12に示すように、ある実施形態に従うと、本システムは、データセットまたはエンティティを評価してその関数型を特定するときの基準となる一組のルールを通して、一般的なケース(この例ではディメンション、レベル、またはキューブ)を説明することができる。
【0182】
たとえば、ある実施形態に従うと、多次元キューブは、その測定属性および次元によって説明することができる。これらは各々それ自体それらのタイプおよびその他の特性によって規定できる。ルールエンジンは、ビジネス型エンティティを評価しその関数型を評価に基づいてアノテートする。
【0183】
図13は、ある実施形態に係る、ディメンション関数型分類の一例を示す図である。
図13に示す一例としての関数型分類470の階層に示すように、ある実施形態に従うと、レベルは、たとえばそのディメンションおよびレベル属性によって規定することができる。
【0184】
図14は、ある実施形態に係る、キューブ関数型分類の一例を示す図である。
図14に示す一例としての関数型分類480の階層に示すように、ある実施形態に従うと、キューブは、たとえばその測定属性および次元によって規定することができる。
【0185】
図15は、ある実施形態に係る、ビジネスエンティティの関数型を評価するための関数型分類の使用の一例を示す図である。
【0186】
図15に示すように、この例490において、ある実施形態に従うと、売上データセットは、ルールエンジンによって、キューブ関数型として評価されねばならない。同様に、製品、顧客、および時間は、ディメンションおよびレベル(たとえば年齢グループ、性別)として評価されねばならない。
【0187】
ある実施形態に従うと、この具体例におけるエンティティの関数型およびデータセットまたはエンティティ要素を特定するルールが以下に示される。これは、同じ関数型の評価のために指定できるいくつかのルールを含む。たとえば、タイプ「Date」のカラムは、親レベルのエンティティに対するリファレンスがあるか否かに関わらず、ディメンションとして考慮することができる。同様に、郵便番号、性別、および年齢は、これらをディメンションとして特定するのにデータルールしか必要としない場合がある。
【0188】
【0189】
図16は、ある実施形態に係る、関数変換に使用するオブジェクト図を示す図である。
図15に示すように、この例500において、ある実施形態に従うと、変換関数は関数型で規定することができる。ビジネスエンティティ(ビジネス型)は関数型としてアノテートされ、これは、デフォルトで、複合ビジネス型は関数型「エンティティ」であることを含む。
【0190】
図17は、ある実施形態に係る、レコメンデーションエンジンの動作を示す図である。
図17に示すように、ある実施形態に従うと、レコメンデーションエンジンは、ビジネス型で規定された一組のアクションであるレコメンデーションを生成する。各アクションは、データセットに対する変換を適用することを要求する指令である。
【0191】
ある実施形態に従うと、レコメンデーションコンテキスト530は、レコメンデーションのソースを抽出し、レコメンデーションを生成した一組の命題を特定するメタデータを含む。このコンテキストにより、レコメンデーションエンジンは、ユーザのレスポンスに基づいてレコメンデーションを学習しそれに優先順位を付けることができる。
【0192】
ある実施形態に従うと、ターゲットエンティティ演繹/マッピング部512は、ターゲットの定義(およびデータセットまたはエンティティおよび属性ビジネス型をアノテートする分類サービス)を用いて、現在のデータセットをターゲットにマッピングすることを容易にする変換レコメンデーションを行う。これは、ユーザが、わかっているターゲットオブジェクト(たとえば売上キューブ)で開始し、パイプラインを構築してキューブをインスタンス化するときに、よくあることである。
【0193】
ある実施形態に従うと、テンプレート(パイプライン/ソリューション)514は、再使用可能な一組のパイプラインステップおよび変換を規定して所望の最終結果を得る。たとえば、テンプレートがステップを含むことにより、エンリッチ化し、変換し、データマートに対してパブリッシュしてもよい。この場合の一組のレコメンデーションは、テンプレート設計を反映する。
【0194】
ある実施形態に従うと、分類サービス516は、HUBからデータレイクにインジェストしたデータセットまたはエンティティのビジネス型を特定する。エンティティに対する
レコメンデーションは、同様のエンティティ(ビジネス型)に適用された変換に基づいて、または、ターゲットエンティティ演繹/マッピング部に関連して行うことができる。
【0195】
ある実施形態に従うと、関数型サービス518は、規定されたルールに基づいてデータセットまたはエンティティが持つことができる関数型をアノテートする。たとえば、所定のデータセットからキューブを生成するためまたはそれをディメンションテーブルに結合するためには、キューブの関数型を規定するルールにデータセットが適合するか否かを評価することが重要である。
【0196】
ある実施形態に従うと、パイプラインコンポーネント520からのパターン推論により、レコメンデーションエンジンは、類似するコンテキストの既存のパイプライン定義における所定のビジネス型に基づいて実行された変換をサマライズし、類似する変換を現在のコンテキストのレコメンデーションとして提案することができる。
【0197】
ある実施形態に従うと、レコメンデーションコンテキストを用いて、レコメンデーション532を処理することができ、これは、アクション534、変換関数535、アクションパラメータ536、関数パラメータ537、およびビジネス型538を含む。
【0198】
データレイク/データ管理戦略
先に述べたように、ある実施形態に従うと、データレイクは、システムHUBまたはその他のコンポーネントからの情報のパーシステンスのリポジトリを提供する。
【0199】
図18は、ある実施形態に係るデータレイクの使用を示す図である。
図18に示すように、ある実施形態に従うと、データレイクは、1つ以上のデータアクセスAPI540、キャッシュ542、およびパーシステンスストア544に対応付けることができる。これらは共に動作することにより、正規化されているインジェストされたデータを、複数のパイプライン552、554、556で使用するために受ける。
【0200】
ある実施形態に従うと、多種多様なデータ管理戦略を用いてデータ(パフォーマンス、スケーラビリティ)を管理するとともにデータレイクにおけるそのライフサイクルを管理することができる。これは、大まかにデータ駆動型またはプロセス駆動型に分類できる。
【0201】
図19は、ある実施形態に係る、データ駆動型戦略を使用してデータレイクを管理することを示す図である。
【0202】
図19に示すように、ある実施形態に従うと、データ駆動型アプローチでは、管理単位がHUBまたはデータサーバ規定に基づいて導出される。たとえば、このアプローチにおいて、Oracle1 HUBからのデータは、このHUBに対応付けられた第1のデータセンター560に格納することができ、SFHUB1からのデータは、このHUBに対応付けられた第2のデータセンター562に格納することができる。
【0203】
図20は、ある実施形態に係る、プロセス駆動型戦略を使用してデータレイクを管理することを示す図である。
【0204】
図20に示すように、ある実施形態に従うと、プロセス駆動型アプローチでは、管理単位がデータにアクセスする関連のパイプラインに基づいて導出される。たとえば、このアプローチにおいて、売上パイプラインに対応付けられたデータは、このパイプラインに対応付けられた第1のデータセンター564に格納することができ、他のパイプライン(たとえばパイプライン1、2、3)からのデータは、これら他のパイプラインに対応付けられた第2のデータセンター566に対応付けることができる。
【0205】
パイプライン
ある実施形態に従うと、パイプラインは、インジェストされたデータに対して実行すべき変換または処理を規定する。処理済みのデータは、データレイクに格納されてもよく、または、たとえばDBCSのような別のエンドポイントに対してパブリッシュされてもよい。
【0206】
図21は、ある実施形態に係るパイプラインコンパイラの使用を示す図である。
図21に示すように、ある実施形態に従うと、パイプラインコンパイラ582は、設計環境570と実行環境580との間で動作する。これは、1つ以上のパイプラインメタデータ572およびDSL、たとえばJava(登録商標) DSL574、JSON DSL576、Scala DSL578を受け取ることと、実行環境で使用される出力を、たとえばSparkアプリケーション584および/またはSQLステートメント586として与えることとを含む。
【0207】
図22は、ある実施形態に係る、パイプライングラフの一例を示す図である。
図22に示すように、ある実施形態に従うと、パイプライン588はパイプラインステップのリスト含む。異なる種類のパイプラインステップは、このパイプライン内で実行できる異なる種類の動作を表している。各パイプラインステップは、一般的にパイプラインステップパラメータによって記述される、複数の入力データセットと複数の出力データセットとを含み得る。パイプライン内における動作の処理順序は、前のパイプラインステップからの出力パイプラインステップパラメータを、次のパイプラインステップに結合することによって規定される。このようにして、パイプラインステップと、パイプラインステップパラメータ間の関係とが、有向非巡回グラフ(directed acyclic graph:DAG)を形成する。
【0208】
ある実施形態に従うと、パイプラインは、パイプラインの入力および出力パイプラインステップパラメータを表す1つ以上の固有パイプラインステップ(シグネチャパイプライン)をパイプラインが含む場合、別のパイプラインで再使用することができる。囲んでいるパイプラインは、(パイプライン使用(pipeline usage))パイプラインステップで再使用されるパイプラインである。
【0209】
図23は、ある実施形態に係る、データパイプラインの一例を示す図である。
図23に示す一例としてのデータパイプライン600に示されるように、ある実施形態に従うと、データパイプラインはデータ変換を実行する。パイプライン内におけるデータの流れは、パイプラインステップパラメータの結合として表される。さまざまな種類のパイプラインステップが、異なる変換動作のためにサポートされる。これはたとえば、エンティティ(データをデータレイクから取り出す、または処理済みのデータをデータレイク/他のHBUに対してパブリッシュする)、および結合(複数のソースの融合)を含む。
【0210】
図24は、ある実施形態に係る、データパイプラインの別の例を示す図である。
図24に示す一例としてのデータパイプライン610に示されるように、ある実施形態に従うと、データパイプラインP1は、別のデータパイプラインP2で再使用することができる。
【0211】
図25は、ある実施形態に係る、オーケストレーションパイプラインの一例を示す図である。
【0212】
図25に示す一例としてのオーケストレーションパイプライン620に示されるように、ある実施形態に従うと、オーケストレーションパイプラインを使用した場合、パイプラ
インステップを用いて、オーケストレーションフロー全体において実行する必要があるタスクまたはジョブを表すことができる。オーケストレーションパイプライン内のパイプラインステップはすべて、1つの入力パイプラインステップパラメータと1つの出力パイプラインステップパラメータとを有するものとする。タスク間の実行依存性は、パイプラインステップパラメータ間の結合として表すことができる。
【0213】
ある実施形態に従うと、タスクの並列実行は、パイプラインステップが、条件なしで、前にある同じパイプラインステップに依存している場合(すなわちフォーク(fork))、スケジュールすることができる。あるパイプラインステップが、前にある複数のパスに依存している場合、このパイプラインステップは、それ自体の実行に先立って複数のパスすべてが完了するのを待つ(すなわち結合(join))。しかしながら、これは、タスクが並列に実行されることを常に意味する訳ではない。オーケストレーションエンジンは、利用できるリソースに応じて、タスクを直列で実行するか並列で実行するか否かを判定することができる。
【0214】
図25に示す例において、ある実施形態に従うと、パイプラインステップ1が最初に実行される。パイプラインステップ2およびパイプラインステップ3が並列で実行される場合、パイプラインステップ4は、パイプラインステップ2およびパイプラインステップ3がいずれも完了してから実行される。オーケストレーションエンジンはまた、このオーケストレーションパイプラインを、パイプラインステップ間の依存性を満たしている限り、直列に(パイプラインステップ1、パイプラインステップ2、パイプラインステップ3、パイプラインステップ4)または(パイプラインステップ1、パイプラインステップ3、パイプラインステップ2、パイプラインステップ4)として実行することができる。
【0215】
図26は、ある実施形態に係る、オーケストレーションパイプラインの一例をさらに示す図である。
【0216】
図26に示す一例としてのパイプライン625に示されるように、ある実施形態に従うと、各パイプラインステップは、自身のセマンティクスに応じて、たとえば成功またはエラーステータス等のステータス630をリターンすることができる。2つのパイプラインステップ間の依存性は、パイプラインステップのリターンステータスに基づいて条件付きであってもよい。示されている例では、パイプラインステップ1が最初に実行され、首尾よく終了した場合はパイプラインステップ2が実行され、そうでなければパイプラインステップ3が実行される。パイプラインステップ2またはパイプライン3いずれかが実行された後に、パイプラインステップ4が実行される。
【0217】
ある実施形態に従うと、オーケストレーションパイプラインを入れ子にすることにより、あるオーケストレーションパイプラインが別のオーケストレーションパイプラインをパイプライン使用(pipeline usage)を通して参照できるようにしてもよい。オーケストレーションパイプラインは、パイプライン使用(pipeline usage)としてのデータパイプラインを参照することもできる。オーケストレーションパイプラインとデータパイプラインとの相違は、オーケストレーションパイプラインが、シグネチャパイプラインステップを含まないデータパイプラインを参照するのに対し、データパイプラインは、シグナチャパイプラインステップを含む別のデータパイプラインを再使用できる点にある。
【0218】
ある実施形態に従うと、パイプラインステップの種類およびコード最適化に応じて、データパイプラインを、Sparkクラスタ内で実行する単一のSparkアプリケーションとして、または、DBCS内で実行される複数のSQLステートメントとして、または、SQLおよびSparkコードの混合として、生成することができる。オーケストレーションパイプラインの場合、下にある実行エンジン内、またはたとえばOozie等のワ
ークフロースケジュールコンポーネント内で実行するために生成することができる。
【0219】
コーディネーションファブリック
ある実施形態に従うと、コーディネーションファブリックまたはファブリックコントローラは、フレームワークコンポーネント(サービスプロバイダ)をデプロイし管理するのに必要なツールと、(ユーザ設計)アプリケーションとを提供し、アプリケーションの実行とリソース要求/割当を管理し、統合フレームワーク(メッセージングバス)を提供することにより、各種コンポーネント間のやり取りを容易にする。
【0220】
図27は、ある実施形態に係る、メッセージングシステムを含むコーディネーションファブリックの使用を示す図である。
【0221】
図27に示すように、ある実施形態に従うと、メッセージングシステム(たとえばKafka)650は、リソースマネージャ660(たとえばYarn/Mesos)と、スケジューラ662(たとえばChronos)と、アプリケーションスケジューラ664(たとえばSpark)と、ここではノード652、654、656、658として示さ
れている複数のノードとの間のインタラクションを調整する。
【0222】
ある実施形態に従うと、リソースマネージャを用いてデータ計算タスク/アプリケーションのライフサイクルを管理する。これは、スケジューリング、モニタリング、アプリケーション実行、リソース調停および割当、ロードバランシングを含み、メッセージ駆動型コンポーネント統合フレームワーク内における(メッセージの作成者および消費者である)コンポーネントの構成およびデプロイを管理すること、ダウンタイムなしでコンポーネント(サービス)をアップグレードすること、および、サービスの混乱を最小にまたはなくした状態でインフラストラクチャをアップグレードすることを含む。
【0223】
図28は、ある実施形態に係る、メッセージングシステムを含むコーディネーションファブリックの使用をさらに示す図である。
【0224】
図28に示すように、ある実施形態に従うと、コーディネーションファブリック内のコンポーネント間の依存性が、簡単なデータ駆動型パイプライン実行ユースケースによって示されている。(c)は消費者(consumer)、(p)は生産者(producer)を示す。
【0225】
図28に示す実施形態に従うと、スケジューラ(p)が、HUBへのデータのインジェストを開始することにより、プロセスを開始する(1)。インジェストエンジン(c)は、要求を処理し(2)、データをHUBからデータレイクにインジェストする。インジェストプロセスの終了後、インジェストエンジン(p)は、終了ステータスを伝達する(3)ことにより、パイプライン処理を開始する。スケジューラがデータ駆動型の実行をサポートする場合、実行するパイプラインプロセスを自動的に開始する(3a)ことができる。パイプラインエンジン(c)は、データの実行を待っているパイプラインを計算する(4)。パイプラインエンジン(p)は、実行のためにスケジューリングするパイプラインアプリケーションのリストを伝える(5)。スケジューラは、パイプラインのための実行スケジュール要求を取得し(6)、パイプラインの実行を開始する(6a)。アプリケーションスケジューラ(たとえばSpark)は、リソース割当についてリソースマネージャとの調停を行い(7)パイプラインを実行する。アプリケーションスケジューラは、割り当てられたノード内の実行部に、パイプラインを実行のために送る(8)。
【0226】
オンプレミスエージェント
ある実施形態に従うと、オンプレミスエージェントは、ローカルデータへのアクセスを容易にし、かつ、限られたやり方で、分散型パイプライン実行を容易にする。オンプレミ
スエージェントは、たとえばクラウドDIサービスと通信するようにプロビジョニングおよび構成され、データアクセスおよび遠隔パイプライン実行要求を処理する。
【0227】
図29は、ある実施形態に係る、システムで使用するオンプレミスエージェントを示す図である。
【0228】
図29に示すように、ある実施形態に従うと、クラウドエージェントアダプタ682は、オンプレミスエージェント680をプロビジョニングし(1)、通信のためにエージェントアダプタエンドポイントを構成する。
【0229】
インジェストサービスは、メッセージングシステムを通して、HUB1に対するローカルデータアクセス要求を開始する(2)。クラウドエージェントアダプタは、インジェストサービスを通して開始された要求へのアクセスを提供することにより、オンプレミスエージェントとメッセージングシステムとの間の仲介として動作し(3)、オンプレミスエージェントからのデータをデータレイクに書き込み、メッセージングシステムを通してタスクの終了を通知する。
【0230】
プレミスエージェントは、データアクセス要求の処理のためにクラウドエージェントアダプタをポーリングする(4)またはデータをクラウドにアップロードする。クラウドエージェントアダプタは、データをデータレイクに書き込み(5)、メッセージングシステムを通してパイプラインに通知する。
【0231】
DFMLフロープロセス
図30は、ある実施形態に係るデータフロープロセスを示す図である。
【0232】
図30に示すように、ある実施形態に従うと、インジェストステップ692において、データは、さまざまなソースたとえばSFDC、S3、またはDBaaSからインジェストされる。
【0233】
データ準備ステップ693において、インジェストされたデータは、たとえば重複排除、標準化、またはエンリッチ化によって準備される。
【0234】
変換ステップ694において、システムは、マージ、フィルタ、またはデータセットのルックアップを実行することにより、データを変換する。
【0235】
モデルステップ695において、1つ以上のモデルが、当該モデルに対するマッピングとともに生成される。
【0236】
パブリッシュステップ696において、システムは、モデルをパブリッシュし、ポリシーおよびスケジュールを指定し、ターゲットデータ構造をポピュレートすることができる。
【0237】
メタデータおよびデータ駆動型自動マッピング
ある実施形態に従うと、このシステムは、1つ以上のデータソースまたはターゲット(本明細書においていくつかの実施形態ではHUBと呼ぶ)間における、複合データ構造、データセット、またはエンティティの自動マッピングのサポートを提供することができる。自動マッピングは、メタデータ、スキーマ、およびデータセットの統計プロファイリングによって駆動することができる。自動マッピングを使用することにより、入力HUBに対応付けられたソースデータセットまたはエンティティを、ターゲットデータセットまたはエンティティに、またはその逆にマッピングすることにより、1つ以上の出力HUBで
使用されるフォーマットまたは組織(プロジェクション)で準備された出力データを生成することができる。
【0238】
たとえば、ある実施形態に従うと、ユーザは、データフロー、パイプライン、またはLambdaアプリケーションを実装(たとえば構築)するために、入力HUB内のソースまたは入力データセットまたはエンティティから、出力HUB内のターゲットまたは出力データセットまたはエンティティにマッピングされるデータを選択することを所望する場合がある。
【0239】
ある実施形態に従うと、HUBおよびデータセットまたはエンティティの、非常に大きな組について、入力HUBから出力HUBへのデータのマップを手作業で作成することは、極めて長い時間を要する非効率的なタスクとなり得るので、自動マッピングにより、データのマッピングのためのレコメンデーションをユーザに提供することによって、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションの単純化にユーザが集中できるようにする。
【0240】
ある実施形態に従うと、データAIサブシステムは、グラフィカルユーザインターフェイス(たとえばLambda Studio統合開発環境(Lambda Studio Integrated Development Environment)(IDE))を介して、自動マップサービスを求める自動マップ要求を受け
ることができる。
【0241】
ある実施形態に従うと、この要求は、自動マップサービスの実行対象であるアプリケーションに対して指定されたファイルを、入力HUBを特定する情報、データセットまたはエンティティ、および1つ以上の属性とともに、含み得る。アプリケーションファイルは、アプリケーションのためのデータに関する情報を含み得る。データAIサブシステムは、アプリケーションファイルを処理することにより、属性名およびデータ型を含む、エンティティ名とエンティティの他の形状特性とを抽出することができる。自動マップサービスは、これを、マッピングのための可能な候補セットを発見するためのサーチにおいて使用することができる。
【0242】
ある実施形態に従うと、本システムは、たとえばデータウェアハウス等のHUBへの変換のために、データにアクセスすることができる。アクセスされたデータは、半構造化および構造化データを含むさまざまな種類のデータを含み得る。データAIサブシステムは、アクセスされたデータに対し、データの1つ以上の形状、特徴、または構造を判別することを含む、メタデータ解析を実行することができる。たとえば、メタデータ解析により、データ型(たとえばビジネス型および関数型)、およびデータのカラム形状を判別することができる。
【0243】
ある実施形態に従うと、データのメタデータ解析に基づいて、データの1つ以上のサンプルを特定することができ、サンプリングされたデータに機械学習プロセスを適用することにより、アクセスされたデータ内のデータのカテゴリを判別し、モデルをアップデートすることができる。データのカテゴリは、たとえば、データ内のファクトテーブル等のデータの関連部分を示し得る。
【0244】
ある実施形態に従うと、機械学習は、たとえばロジスティック回帰モデルまたは機械学習のために実装できる他の種類の機械学習モデルを用いて、実装することができる。ある実施形態に従うと、データAIサブシステムは、データ内の1つ以上のデータアイテムの関係を、データのカテゴリに基づいて解析することができる。この関係は、データのカテゴリについて、データ内の1つ以上のフィールド示す。
【0245】
ある実施形態に従うと、データAIサブシステムは、特徴抽出のためのプロセスを実行することができ、これは、アクセスされたデータの属性についてランダムにサンプリングされたデータの統計プロファイル、データ型、および1つ以上のメタデータを判別することを含む。
【0246】
たとえば、ある実施形態に従うと、データAIサブシステムは、アクセスされたデータのプロファイルを、そのデータのカテゴリに基づいて生成することができる。このプロファイルは、データを出力HUBに変換するために生成することができ、たとえばグラフィカルユーザインターフェイスに表示できる。
【0247】
ある実施形態に従うと、このようなプロファイルを作成した結果、このモデルは、入力データセットまたはエンティティに対する候補データセットまたはエンティティの類似度に関するある程度の信頼度で、レコメンデーションをサポートすることができる。レコメンデーションは、フィルタリングしソートした後に、グラフィカルユーザインターフェイスを介してユーザに提供することができる。
【0248】
ある実施形態に従うと、自動マップサービスは、ユーザがデータフローアプリケーションたとえばパイプライン、Lambdaアプリケーションを構築しているステージに基づいて、レコメンデーションを動的に示唆することができる。
【0249】
エンティティレベルにおけるレコメンデーションの一例は、ある実施形態に従うと、属性のレコメンデーション、たとえば別の属性または別のエンティティに自動的にマッピングされるエンティティのカラムを、含み得る。サービスは、ユーザの過去の活動に基づいて、継続的にレコメンデーションを提供しユーザを案内することができる。
【0250】
ある実施形態に従うと、レコメンデーションは、たとえば入力HUBに対応付けられたソースデータセットまたはエンティティから、出力HUBに対応付けられたターゲットデータセットまたはエンティティに、自動マップサービスから提供されたアプリケーションプログラミングインターフェイス(API)(たとえばREST API)を用いて、マッピングすることができる。レコメンデーションは、たとえば属性、データ型、および表現等のデータのプロジェクションを示すことができ、上記表現は、データ型に関する属性のマッピングであってもよい。
【0251】
ある実施形態に従うと、本システムは、レコメンデーションに基づいてアクセスされたデータの変換のための出力HUBを選択するために、グラフィカルユーザインターフェイスを提供することができる。たとえば、グラフィカルユーザインターフェイスにより、ユーザは、データを出力HUBに変換するためのレコメンデーションを選択することができる。
【0252】
自動マッピング
ある実施形態に従うと、自動マッピング機能は数学的に定義することができ、エンティティ集合Eは次のように定義される。
【0253】
【0254】
式中、形状(shape)集合Sは、メタデータ(metadata)、データ型(data type)および統計プロファイリングディメンション(statistical profiling dimension)を含む。
目的は、eiとejとの間の類似度の確率が最大になるjを見出すことである。
【0255】
【0256】
データセットまたはエンティティレベルにおいて、問題はバイナリ問題である。すなわち、データセットまたはエンティティが類似しているか類似していないかである。fs、ft、h(fs,ft)がソース、ターゲットの特徴、およびソースとターゲットとの間のインタラクティブ特徴のセットを表すとする。したがって、目的は類似度の確率を推定することである。
【0257】
【0258】
対数尤度関数は次のように定義される
【0259】
【0260】
したがって、ロジスティック回帰モデルにおいて、未知の係数は次のように推定できる。
【0261】
【0262】
ある実施形態に従うと、自動マップサービスは、たとえば、システムファサードサービスからHTTP POST要求を受けたことにより、トリガすることができる。システムファサードAPIは、データフローアプリケーションたとえばパイプライン、LambdaアプリケーションJSONファイルを、UIから自動マップREST APIに送り、パーサモジュールは、アプリケーションJSONファイルを処理し、属性名およびデータ型を含むデータセットまたはエンティティのエンティティ名および形状を抽出する。
【0263】
ある実施形態に従うと、自動マップサービスは、サーチを利用することにより、マッピングのための有力候補セットを素早く発見する。候補セットは関連性が高いセットである
必要があるので、特別なインデックスおよびクエリを用いてこれを実現することができる。この特別なインデックスは、エンティティのすべての属性が格納されすべてがN-gramのコンビネーションでトークン化されている特別なサーチフィールドを取り入れる。クエリ時に、サーチクエリビルダモジュールは、たとえばレーベンシュタイン距離に基づいてファジーサーチ特徴を活用することにより、所定のエンティティのエンティティ名と属性名との両方を用いて特別なクエリを構成し、サーチブースト機能を活用することにより、結果を、ストリング類似度という点における関連性によってソートする。
【0264】
ある実施形態に従うと、レコメンデーションエンジンは、複数の関連結果、たとえば多くの場合は上位Nの結果の選択を、ユーザに対して示す。
【0265】
ある実施形態に従うと、高い精度を得るために、機械学習モデルは、ソースとターゲットを比較し、抽出された特徴に基づいてエンティティの類似度のスコアを求める。特徴抽出は、各属性についてランダムにサンプリングされたデータの統計プロファイル、データ型、およびメタデータを含む。
【0266】
ある実施形態に従うと、本明細書の記載は概してロジスティック回帰モデルを用いてOracle Business Intelligence(OBI)系統マッピングデータから得た自動マッピングの例を学習することを説明しているが、その他のスーパーバイズされる機械学習モデルを代わりに使用することができる。
【0267】
ある実施形態に従うと、ロジスティック回帰モデルの出力は、統計的な意味において、候補データセットまたはエンティティの、入力データセットまたはエンティティに対する類似の程度の総信頼度を表す。的確なマッピングを発見するために、その他1つ以上のモデルを用いて、類似する特徴を使用してソース属性とターゲット属性との類似度を計算することができる。
【0268】
最後に、ある実施形態に従うと、レコメンデーションがフィルタリングおよびソートされてシステムファサードに送り返されユーザインターフェイスに送られる。自動マップサービスは、データフローアプリケーションたとえばパイプラインまたはLambdaアプリケーション設計中に、ユーザがどのステージにいるかに基づいて、レコメンデーションを動的に提示する。サービスは、ユーザの過去の活動に基づいて、継続的にレコメンデーションを提供しユーザをガイドすることができる。自動マッピングは、フォワード・エンジニアリング方向またはリバースエンジニアリング方向いずれかで実施することができる。
【0269】
図31は、ある実施形態に係る、データ型の自動マッピングを示す図である。
図31に示すように、ある実施形態に従うと、システムファサード701および自動マップAPI702により、データフローアプリケーションたとえばパイプラインまたはLambdaアプリケーションを、ソフトウェア開発コンポーネントたとえばLambda Studioから
受けることができる。パーサ704は、アプリケーションのJSONファイルを処理し、属性名およびデータ型を含むエンティティ名および形状を抽出する。
【0270】
ある実施形態に従うと、サーチインデックス708を用いてプライマリサーチ710をサポートすることにより、マッピングのためのデータセットまたはエンティティの有力候補セットを発見する。サーチクエリビルダモジュール706は、所定のエンティティのエンティティ名および属性名の両方を用いてクエリを構成することにより、選択データセットまたはエンティティ712を求める。
【0271】
ある実施形態に従うと、機械学習(ML)モデルを用いてソースとターゲットの対を比較し、抽出された特徴に基づいて、データセットまたはエンティティの類似度のスコアを
求める。特徴抽出714は、各属性についてランダムにサンプリングされたデータの統計プロファイル、データ型、およびメタデータを含む。
【0272】
ある実施形態に従うと、ロジスティック回帰モデル716は、出力として、入力エンティティに対する候補エンティティの類似の程度の総信頼度を提供する。より正確なマッピングを発見するために、カラムマッピングモデル718を用いてソース属性とターゲット属性との類似度をさらに評価する。
【0273】
ある実施形態に従うと、次に、自動マッピング720として、レコメンデーションを、ソフトウェア開発コンポーネントたとえばLambda Studioに返すために、ソートする。自
動マップサービスは、データフローアプリケーションたとえばパイプラインまたはLambdaアプリケーション設計中に、ユーザがどのステージにいるかに基づいて、レコメンデーションを動的に提示する。サービスは、ユーザの過去の活動に基づいて、継続的にレコメンデーションを提供しユーザをガイドすることができる。
【0274】
図32は、ある実施形態に係る、マッピングの生成のための自動マップサービスを示す図である。
【0275】
図32に示すように、ある実施形態に従うと、自動マップサービスを、マッピングの生成のために提供することができる。これは、UIクエリ728を受け、クエリ理解エンジン729に送り、その後クエリ分解730コンポーネントに送ることを含む。
【0276】
ある実施形態に従うと、プライマリサーチ710をデータHUB722を用いて実行することにより、後のメタデータおよび統計プロファイル処理732で使用する候補データセットまたはエンティティ731を求める。
【0277】
ある実施形態に従うと、結果は、Get Statsプロファイル734コンポーネント、デー
タAIシステム724、および特徴抽出735に送られる。結果は、合成736、モデル723に従う最終信頼度マージおよびランキング739に使用され、レコメンデーションおよび関連信頼度740に与えられる。
【0278】
自動マップの例
図33は、ある実施形態に係る、ソーススキーマとターゲットスキーマとの間のマッピングの一例を示す図である。
【0279】
図33に示すように、この例741は、ある実施形態に従い、たとえば(a)上位語(hypernym)、(b)同義語(synonym)、(c)相等性(equality)、(d)Soundex、および(e)ファジーマッチングに基づく、単純な自動マッピングの例を示す。
【0280】
図34は、ある実施形態に係る、ソーススキーマとターゲットスキーマとの間のマッピングの別の例を示す図である。
【0281】
図34に示すように、専らメタデータに基づくアプローチは、この情報が無関係の場合、失敗する。ある実施形態に従い、
図34は、ソース属性名およびターゲット属性名に全く情報がない場合の例742を示す。メタデータ特徴がないとき、本システムは、特徴の統計プロファイリングを含むモデルを用いて類似するエンティティを発見することができる。
【0282】
自動マッププロセス
図35は、ある実施形態に係る、自動化されたデータ型のマッピングを提供するプロセ
スを示す図である。
【0283】
図35に示すように、ステップ744で、ある実施形態に従うと、アクセスされたデータを処理することにより、アクセスされたデータのメタデータ解析を実行する。
【0284】
ステップ745において、アクセスされたデータの1つ以上のサンプルを特定する。
ステップ746において、機械学習プロセスを適用することにより、アクセスされたデータ内のデータのカテゴリを判別する。
【0285】
ステップ748において、アクセスされたデータの自動マッピングに使用するために、判別したデータのカテゴリに基づいて、アクセスされたデータのプロファイルを生成する。
【0286】
動的レコメンデーションおよびシミュレーション
ある実施形態に従うと、このシステムは、(本明細書においていくつかの実施形態ではLambda Studioと呼ぶ)ソフトウェア開発コンポーネントと、上記システムで使用される
視覚環境を提供する(本明細書においていくつかの実施形態ではパイプラインエディタまたはLambda Studio IDEと呼ぶ)グラフィカルユーザインターフェイスとを含み得る。こ
れは、入力HUBからアクセスされたデータに対するセマンティックアクションの実行のために、当該データに対応付けられた意味またはセマンティクスの理解に基づいてリアルタイムレコメンデーションを提供することを含む。
【0287】
たとえば、ある実施形態に従うと、グラフィカルユーザインターフェイスは、入力HUBからアクセスされたデータに対する動作(セマンティックアクションとも呼ぶ)を実行するためにリアルタイムレコメンデーションを提供することができる。これは、部分データおよびこのデータの形状またはその他の特性を含む。セマンティックアクションは、データに対し、このデータに対応付けられた意味またはセマンティクスに基づいて実行することができる。データの意味を用いて、このデータに対して実行できるセマンティックアクションを選択することができる。
【0288】
ある実施形態に従うと、セマンティックアクションは、1つ以上のデータセットに対するオペレータを表し得るものであり、システム内で宣言的に規定されたベースセマンティックアクションまたは関数を参照することができる。処理済みの1つ以上のデータセットは、セマンティックアクションを実行することによって生成できる。セマンティックアクションは、特定の関数型またはビジネス型に対応付けられたパラメータによって規定することができる。これらは、処理対象の特定のアップストリームデータセットを表す。グラフィカルユーザインターフェイスをメタデータ駆動型とし、グラフィカルユーザインターフェイスが動的に生成されてレコメンデーションをデータ内で特定されたメタデータに基づいて動的に提供するようにしてもよい。
【0289】
図36は、ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するシステムを示す図である。
【0290】
図36に示すように、ある実施形態に従うと、ユーザ入力エリア752を有するグラフィカルユーザインターフェイス750を用いて、アクセスされたデータに対して有効にされたセマンティックアクションに対するクエリが、システムのナレッジソースに送られる。このクエリは、アクセスされたデータの分類を示す。
【0291】
ある実施形態に従うと、クエリに対するレスポンスをナレッジソースから受ける。このレスポンスは、アクセスされたデータに対して有効にされ、データの分類に基づいて特定
された、1つ以上のセマンティックアクションを示す。
【0292】
ある実施形態に従うと、アクセスされたデータに対して有効にされたセマンティックアクションのうち選択されたセマンティックアクションが、選択のためおよびアクセスされたデータとともに使用するために表示される。これは、アクセスされたデータの処理中に、アクセスされたデータに対して有効にされたセマンティックアクション756のうち選択されたセマンティックアクションまたはレコメンデーション758のリストを、自動的に提供またはアップデートすることを含む。
【0293】
ある実施形態に従うと、レコメンデーションは、静的データに基づいて予め計算するのではなく、動的に提供することができる。たとえば、システムは、たとえばユーザプロファイルまたはユーザの経験レベル等の情報を考慮して、リアルタイムでアクセスされるデータに基づき、リアルタイムでレコメンデーションを提供することができる。リアルタイムデータに対してシステムが提供するレコメンデーションは、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションを生成するために、注目すべき、関連する、正確なものであってもよい。レコメンデーションは、特定のメタデータに対応付けられたデータに関して、ユーザの行動に基づいて提供することができる。システムは、情報に対するセマンティックアクションをレコメンドすることができる。
【0294】
たとえば、ある実施形態に従うと、システムは、データをインジェストし、変換し、統合し、任意のシステムに対してパブリッシュすることができる。システムは、エンティティを用いてその数値基準のうちのいくつかを興味深い解析手法で解析することをレコメンドすることができ、このデータをさまざまなディメンションでピボットし、どれが興味深いディメンションであるかを示し、ディメンション階層に関してデータを要約し、より多くのインサイトでデータをエンリッチ化する。
【0295】
ある実施形態に従うと、レコメンデーションは、たとえばデータのメタデータ解析のような技術を用いるデータの解析に基づいて、提供することができる。
【0296】
ある実施形態に従うと、メタデータ解析は、たとえばデータの形状、特徴、および構造等のデータの分類を判別することを含み得る。メタデータ解析は、データ型(たとえばビジネス型および関数型)を判別することができる。メタデータ解析は、データのカラム形状を示すこともできる。ある実施形態に従うと、データを、メタデータ構造(たとえば形状および特徴)と比較することにより、データ型およびデータに対応付けられた属性を判別することができる。メタデータ構造は、システムのシステムHUB(たとえばナレッジソース)で規定することができる。
【0297】
ある実施形態に従うと、システムは、メタデータ解析を用いて、システムHUBにクエリすることにより、メタデータに基づいてセマンティックアクションを特定することができる。レコメンデーションは、入力HUBからアクセスされたデータのメタデータの解析に基づいて決定されたセマンティックアクションであってもよい。具体的には、セマンティックアクションは、メタデータにマッピングすることができる。たとえば、セマンティックアクションは、これらのアクションが許可されたおよび/または適用可能なメタデータにマッピングすることができる。セマンティックアクションは、ユーザによって規定されてもよく、および/またはデータの構造に基づいて規定されてもよい。
【0298】
ある実施形態に従うと、セマンティックアクションは、メタデータに対応付けられた条件に基づいて規定することができる。システムHUBは、セマンティックアクションが修正、削除、または増補されるように、修正することができる。
【0299】
ある実施形態に従うと、セマンティックアクションの例は、キューブの構築、データのフィルタリング、データのグループ分け、データの集約、または、データに対して実行できるその他のアクションを含み得る。メタデータに基づいてセマンティックアクションを規定することにより、データに対して許可されるセマンティックアクションを決定するのにマッピングまたはスキームは不要になる。セマンティックアクションは、新たな異なるメタデータ構造が発見されたときに規定してもよい。よって、システムは、入力として受けたデータについて解析されたメタデータを用いて、セマンティックアクションの特定に基づき、レコメンデーションを動的に求めることができる。
【0300】
ある実施形態に従うと、セマンティックアクションを第三者が規定し、この第三者がデータを、たとえばメタデータに対応付けられた1つ以上のセマンティックアクションを規定するデータを、供給できるようにすることができる。システムは、システムHUBに動的にクエリすることにより、メタデータに対して利用できるセマンティックアクションを決定することができる。よって、システムHUBを修正し、その時点でこのような修正に基づいて許可されるセマンティックアクションをシステムが決定するようにしてもよい。システムは、動作(たとえばフィルタリング、検出、および登録)を実行することにより、第三者から取得したデータを処理することができる。このとき、データは、セマンティックアクションを規定し、上記処理によって特定されたセマンティックアクションに基づいてセマンティックアクションが利用できるようにすることができる。
【0301】
図37および
図38は、ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するグラフィカルユーザインターフェイスを示す図である。
【0302】
図37に示すように、ある実施形態に従うと、ソフトウェア開発コンポーネント(たとえばLambda Studio)は、グラフィカルユーザインターフェイス(たとえばパイプライン
エディタまたはLambda Studio IDE)750を提供することができる。これは、出力HU
Bへのプロジェクションのために入力データを処理するまたは入力データの処理をシミュレートする際に使用するレコメンデーションセマンティックアクションを表示することができる。
【0303】
たとえば、ある実施形態に従うと、
図37のインターフェイスによって、ユーザは、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションに対応付けられたオプション752を表示することができる。これは、たとえば入力HUB規定754を含む。
【0304】
ある実施形態に従うと、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションの作成中、または、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションの、入力データに対するシミュレーション中に、1つ以上のセマンティックアクション756またはその他のレコメンデーション758を、ユーザによる検討用にグラフィカルユーザインターフェイスに表示することができる。
【0305】
ある実施形態に従うと、シミュレーションモードにおいて、ソフトウェア開発コンポーネント(たとえばLambda Studio)は、サンドボックス(sandbox)環境を提供する。この環境によって、ユーザは、出力に対するさまざまなセマンティックアクションの実行の結果を即時見ることができる。これは、アクセスされたデータの処理中に、アクセスされたデータに適したセマンティックアクションのリストを自動的にアップデートすることを含む。
【0306】
たとえば、
図38に示すように、ある実施形態に従うと、何らかの情報を探しているユ
ーザの開始点から、システムは、情報に対する動作760をレコメンドすることができる。たとえば、エンティティを用いてその数値基準のうちのいくつかを興味深い解析手法で解析することを推奨し、このデータをさまざまなディメンションでピボットし、どれが興味深いディメンションであるかを示し、ディメンション階層に関してデータを要約し、より多くのインサイトでデータをエンリッチ化する。
【0307】
ある実施形態に従うと、示されている例では、ソースおよびディメンションの双方が、システム内の解析可能なエンティティに対して推奨され、多次元キューブを構築するタスクを、概ねポイントおよびクリックのうちの一方にする。
【0308】
典型的には、このような作業には多くの経験とドメイン専用知識が必要である。機械学習を用いてデータ特性と一般的な統合パターンに対するユーザの行動パターンとの両方を、セマンティックサーチと機械学習からのレコメンデーションとの組み合わせとともに解析することにより、ビジネス専用アプリケーションの構築のためにアプリケーションを開発するための先端ツーリング(tooling)を可能にする。
【0309】
図39は、ある実施形態に係る、アクセスされたデータに対して有効にされた1つ以上のセマンティックアクションを表示するプロセスを示す図である。
【0310】
図39に示すように、ステップ772で、ある実施形態に従い、アクセスされたデータを処理することにより、アクセスされたデータのメタデータ解析を実行する。メタデータ解析は、アクセスされたデータの分類を判別することを含む。
【0311】
ステップ774で、システムのナレッジソースに、アクセスされたデータに対して有効にされたセマンティックアクションのクエリを送信する。このクエリはアクセスされたデータの分類を示す。
【0312】
ステップ775で、ナレッジソースから、上記クエリに対するレスポンスを受信する。このレスポンスは、アクセスされたデータに対して有効にされ上記データの分類に基づいて特定された1つ以上のセマンティックアクションを示す。
【0313】
ステップ776で、アクセスされたデータに対して有効にされたセマンティックアクションの中から選択されたセマンティックアクションを、選択のためかつアクセスされたデータに対して使用するために、グラフィカルユーザインターフェイスに表示する。これは、アクセスされたデータの処理中に、アクセスされたデータに対して有効にされたセマンティックアクションの中から選択されたセマンティックアクションのリストを自動的に提供またはアップデートすることを含む。
【0314】
データフローの関数分解
ある実施形態に従うと、このシステムは、ソフトウェアアプリケーションのデータフローの関数分解から特定されたパターンに基づいて、入力データに対するアクションおよび変換をレコメンドするためのサービスを提供することができ、これは、後のアプリケーションにおいて上記データフローに可能な変換を判定することを含む。データフローは、データの変換、述語、およびデータに適用されるビジネスルールを記述するモデルと、データフロー内で使用される属性とに分解することができる。
【0315】
図40は、ある実施形態に係る、パイプライン、Lambdaアプリケーションを評価してその構成要素を求めることにより、パターン検出および帰納的学習を容易にすることをサポートすることを示す。
【0316】
図40に示すように、ある実施形態に従うと、関数分解ロジック800すなわちソフトウェアコンポーネントは、コンピュータシステムまたはその他の処理デバイスによって実行可能なソフトウェアまたはプログラムコードとして提供することができ、(たとえばパイプラインエディタまたはLambda Studio IDE内の)ディスプレイ805に対し、関数分
解802およびレコメンデーション804を提供するために使用することができる。たとえば、このシステムは、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションのデータフローの関数分解から特定されたパターン/テンプレートに基づいて、データに対するアクションおよび変換をレコメンドするためのサービスを提供することができる、すなわち、データフローの関数分解を通して、後のアプリケーションにおいてデータフローに可能な変換を判定するためのパターンを観察することができる。
【0317】
ある実施形態に従うと、このサービスは、データフローを、データの変換、述語、およびデータに適用されるビジネスルールを記述するモデルと、データフローで使用される属性とに分解または分類することができるフレームワークによって実現できる。
【0318】
従来、アプリケーションのデータフローは、データに対する一連の変換を表すことができ、データに適用される変換のタイプは、コンテキスト性が高い。大抵のデータ統合フレームワークにおいて、通常、プロセスの系統は、データフローが如何にして永続化され、解析され、生成されるかに関しては、限定的であるまたは存在しない。ある実施形態に従うと、このシステムによって、セマンティックリッチエンティティタイプに基づいてフローまたはグラフからコンテキストが関連するパターンを導出することができ、さらにデータフロー文法およびモデルを学習し、これを用いて、所定の類似するコンテキストが与えられたときに複合データフローグラフを生成することができる。
【0319】
ある実施形態に従うと、システムは、データフローの設計仕様に基づいて、パターンおよびテンプレートを規定する1つ以上のデータ構造を生成することができる。データフローを分解して、関数式を規定するデータ構造にすることにより、パターンおよびテンプレートを決定することができる。データフローを用いて、データ変換のレコメンデーションのためのパターンを決定するための関数式を予測し生成することができる。レコメンデーションは、分解されたデータフローおよび固有パターンの帰納的学習によって導出されたモデルに基づいており、粒度を細かくすることができる(たとえば、特定の属性に対するスカラー変換をレコメンド、または、1つ以上の属性をフィルタリングまたは結合のために述語において使用)。
【0320】
ある実施形態に従うと、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションにより、ユーザは、データに対するセマンティックアクションに基づいて複雑なデータ変換を生成することができる。このシステムは、データ変換を、パイプライン、Lambdaアプリケーションのためのデータのフローを規定する1つ以上のデータ構造として、格納することができる。
【0321】
ある実施形態に従うと、データフローアプリケーション、たとえばパイプライン、Lambdaアプリケーションのデータフローの分解を利用することにより、データのパターン解析を判断し、関数式を生成することができる。分解は、セマンティックアクションと、変換および述語、またはビジネスルールに対して実行することができる。先のアプリケーションのセマンティックアクション各々は、分解を通じて特定することができる。帰納のプロセスを用いて、ビジネスロジックを、そのコンテキスト要素(ビジネス型および関数型)を含むデータフローから、抽出することができる。
【0322】
ある実施形態に従い、プロセスに対してモデルを生成することができ、帰納に基づいて、コンテキストがリッチな規範データフロー設計レコメンデーションを生成することがで
きる。これらのレコメンデーションは、モデルから推論されたパターンに基づいていてもよく、各レコメンデーションは、アプリケーションのためのデータに対して実行できるセマンティックアクションに対応し得る。
【0323】
ある実施形態に従い、システムは、関数分解に基づいてデータ変換のパターンを推論するプロセスを実行することができる。システムは、1つ以上のデータフローアプリケーションたとえばパイプライン、Lambdaアプリケーションのデータフローにアクセスすることができる。データフローを処理することにより、1つ以上の関数式を求めることができる。関数式は、データフロー内で特定されたアクション、述語、またはビジネスルールに基づいて生成することができる。アクション、述語、またはビジネスルールを用いることにより、データフローに対する変換のパターンを特定(たとえば推論)することができる。変換のパターンの推論は、受動プロセスであってもよい。
【0324】
ある実施形態に従うと、変換のパターンは、異なるアプリケーションのデータフローの受動解析に基づいて、クラウドソーシング法で決定することができる。このパターンは、機械学習(たとえば深層強化学習)を用いて決定することができる。
【0325】
ある実施形態に従うと、変換のパターンは、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションに対して生成された関数式について特定することができる。1つ以上のデータフローを分解することにより、データ変換のパターンを推論することができる。
【0326】
ある実施形態に従うと、システムは、このパターンを用いて、新たなデータフローアプリケーションたとえばパイプライン、Lambdaアプリケーションのデータフローに対する1つ以上のデータ変換をレコメンドすることができる。貨幣交換のためのデータに対する処理のデータフローの例において、このシステムは、データに対する変換のパターンを特定することができる。また、このシステムは、アプリケーションの新たなデータフローに対する1つ以上の変換をレコメンドすることができ、このデータフローは、同様の貨幣交換のためのデータを含む。変換は、新たなデータフローを変換に従って修正することにより同様の貨幣交換を生み出すように、パターンに従って同様のやり方で実行することができる。
【0327】
図41は、ある実施形態に係る、1つ以上のアプリケーション各々ごとに生成された1つ以上の関数式についてデータフロー内の変換のパターンを特定する手段を示す図である。
【0328】
先に述べたように、ある実施形態に従うと、パイプラインたとえばLambdaアプリケーションにより、ユーザは、関係演算法におけるオペレータに対応するセマンティックアクションに基づいて、複雑なデータ変換を規定することができる。データ変換は通常、有向非巡回グラフもしくはクエリとして、または、DFMLの場合は入れ子関数として、永続化される。データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションを分解し入れ子関数としてシリアライズすることにより、データフローのパターン解析を可能にし、同様のコンテキストにおいてデータセットに対する複雑な変換を抽出する関数式を生成するのに使用することができるデータフローモデルを帰納する。
【0329】
ある実施形態に従うと、入れ子関数分解を、セマンティックアクション(行またはデータセットオペレータ)のレベルだけでなく、スカラー変換および述語構造でも実行する。これにより、複合データフローの深い系統機能を可能にする。帰納モデルに基づくレコメンデーションは、高粒度にすることができる(たとえば、特定の属性に対するスカラー変換をレコメンド、またはフィルタリングまたは結合のために述語における1つ以上の属性
を使用)。
【0330】
ある実施形態に従うと、関数分解に含まれる要素は概ね以下の通りである。
アプリケーションは、トップレベルデータフロー変換を表す。
【0331】
アクションは、1つ以上のデータセット(固有のデータフレーム)に対するオペレータを表す。
【0332】
アクションは、システムにおいて宣言的に規定されたベースセマンティックアクションまたは関数を参照する。アクションは、1つ以上のアクションパラメータを有することができ、各アクションパラメータは、特定の役割(イン、アウト、イン/アウト)およびタイプを有することができ、1つ以上の処理済みのデータセットを返すことができ、数レベルの深さに埋め込むまたは入れ子にすることができる。
【0333】
アクションパラメータは、アクションによって所有され、特定の関数型またはビジネス型を有し、処理対象の特定のアップストリームデータセットを表す。結合パラメータは、変換に使用されるHUB内のデータセットまたはエンティティを表す。値パラメータは、現在の変換のコンテキストにおいて処理される中間または一時データ構造を表す。
【0334】
スコープリゾルバにより、全体のデータフローにおいて使用されるデータセットまたはデータセット内の要素に対し、プロセス系統を導出することができる。
【0335】
図42は、ある実施形態に係る、1つ以上のアプリケーション各々ごとに生成された1つ以上の関数式についてデータフロー内の変換のパターンを特定する際に使用するオブジェクト図を示す図である。
【0336】
図42に示すように、ある実施形態に従うと、関数分解ロジックを用いて、データフローアプリケーションの、たとえばパイプライン、Lambdaアプリケーションの、データフローを、データの変換、述語、およびデータに適用されるビジネスルールを記述するモデルと、データフロー内で使用される属性とに分解または分類することができる。これは、たとえば、パターンまたはテンプレート812(テンプレートがLambdaアプリケーションに対応付けられている場合はパイプライン)、サービス814、関数816、関数パラメータ818、および関数型820に分解することができる。
【0337】
ある実施形態に従うと、これらの関数コンポーネント各々は、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションを反映する、たとえばタスク822またはアクション824に、さらに分解することができる。
【0338】
ある実施形態に従うと、スコープリゾルバ826を用いて、特定の属性または埋め込まれたオブジェクトに対するリファレンスを、そのスコープを通してリゾルブすることができる。たとえば、
図42に示すように、スコープリゾルバは、属性または埋め込まれたオブジェクトに対するリファレンスを、その隣接スコープを通してリゾルブする。たとえば、フィルタおよび別のテーブルの出力を用いる結合関数は、そのスコープリゾルバへのリファレンスを有し、InScopeOf動作と組合わせて使用することにより、リーフノードその
ルートノードにリゾルブすることができる。
【0339】
図43は、ある実施形態に係る、1つ以上のアプリケーション各々ごとに生成された1つ以上の関数式についてデータフロー内の変換のパターンを特定するプロセスを示す図である。
【0340】
図43に示すように、ある実施形態に従うと、ステップ842において、1つ以上のソフトウェアアプリケーション各々について、データフローにアクセスする。
【0341】
ステップ844において、1つ以上のソフトウェアアプリケーションのデータフローを処理することにより、このデータフローを表す1つ以上の関数式を生成する。この1つ以上の関数式は、データフロー内で特定されたセマンティックアクションおよびビジネスルールに基づいて生成される。
【0342】
ステップ845において、1つ以上のソフトウェアアプリケーション各々について生成した1つ以上の関数式に対し、データフロー内の変換のパターンを特定する。セマンティックアクションおよびビジネスルールを用いて、データフロー内の変換のパターンを特定する。
【0343】
ステップ847において、データフロー内で特定された変換のパターンを用いて、1つ以上のデータ変換のレコメンデーションを、別のソフトウェアアプリケーションのデータフローに対して提供する。
【0344】
オントロジー学習
ある実施形態に従うと、このシステムは、スキーマ定義のオントロジー解析を実行することにより、このスキーマに対応付けられたデータおよびデータセットまたはエンティティのタイプを判別し、エンティティとそれらの属性との関係に基づいて規定されたオントロジーを含むリファレンススキーマからモデルを生成またはアップデートすることができる。1つ以上のスキーマを含むリファレンスHUBを用いてデータフローを解析し、さらに、分類する、または、たとえば入力データの変換、エンリッチ化、フィルタリング、もしくはクロスエンティティデータ融合等の、レコメンデーションを行うことができる。
【0345】
ある実施形態に従うと、本システムは、スキーマ定義のオントロジー解析を実行することにより、リファレンススキーマ内のデータおよびエンティティのタイプのオントロジーを決定することができる。言い換えると、このシステムは、エンティティとその属性との間の関係に基づいて規定されたオントロジーを含むスキーマからモデルを生成することができる。リファレンススキーマは、システムによって与えられるものであっても、デフォルトリファレンススキーマであっても、代わりに、ユーザから供給されるもしくは第三者リファレンススキーマであってもよい。
【0346】
データ統合フレームワークのうちのいくつかは、エンジニアメタデータを周知のシステムソースタイプからリバースする場合があるが、パターン定義およびエンティティ分類に使用出来る関数型システムを構築するためのメタデータの解析は提供しない。また、メタデータハーベスティングは、範囲が限られており、抽出されたデータセットまたはエンティティのためのデータプロファイリングまで拡張されるものではない。ユーザが、(同様のトポロジー空間における)エンティティ分類に加えて複雑なプロセス(ビジネスロジック)および統合パターンにおいて使用する関数型システムオントロジー学習のためにリファレンススキーマを特定できるようにする機能は、現在利用できない。
【0347】
ある実施形態に従うと、1つ以上のスキーマをリファレンスHUBに格納することができる。これ自体は、システムHUBの中にまたはその一部として設けることができる。リファレンススキーマと同様、リファレンスHUBも、ユーザから提供されるもしくは第三者リファレンスHUBであってもよく、または、マルチテナント環境において、特定のテナントに対応付けられたとえばデータフローAPIを通してアクセスされてもよい。
【0348】
ある実施形態に従うと、リファレンスHUBを使用してデータフローを解析し、さらに
分類またはレコメンデーションを行うことができる。それはたとえば、変換、エンリッチ化、フィルタリング、またはクロスエンティティ・データフュージョンである。
【0349】
たとえば、ある実施形態に従うと、このシステムは、リファレンスHUBをオントロジー解析のためのスキーマとして規定する入力を受けることができる。リファレンスHUBは、インポートされてエンティティ定義(属性定義、データ型、およびデータセットまたはエンティティ、制約、またはビジネスルール間の関係)を取得してもよい。リファレンスHUB内のサンプルデータ(たとえば、例としてカラムデータ等の属性ベクトル)を、すべてのデータセットまたはエンティティおよびプロファイリングされたデータについて抽出することにより、データのいくつかのメトリクスを導出してもよい。
【0350】
ある実施形態に従うと、型システムは、リファレンススキーマの用語集に基づいてインスタンス化することができる。システムは、オントロジー解析を実行することにより、データの型を記述するオントロジー(たとえば一組のルール)を導出することができる。オントロジー解析はデータルールを決定することができる。データルールは、プロファイリングされたデータ(たとえば属性または合成値)メトリクスについて規定されたものであり、ビジネス型要素(たとえばUOM、ROIL、または通貨の種類)を、そのデータプロファイルとともに記述する。オントロジー解析は、関係ルールおよび複合ルールを決定することができる。関係ルールは、データセットまたはエンティティと属性ベクトル(リファレンススキーマからインポートされた制約またはリファレンス)との対応関係を規定し、複合ルールは、データルールおよび関係ルールの組み合わせから導出できる。そうすると、型システムは、メタデータハーベスティングおよびデータサンプリングを通して得られたルールに基づいて規定することができる。
【0351】
ある実施形態に従うと、オントロジー解析を用いてインスタンス化した型システムに基づいて、システムHUBからのパターンおよびテンプレートを利用することができる。そうすると、システムは型システムを用いてデータフロー処理を実行することができる。
【0352】
たとえば、ある実施形態に従うと、データセットまたはエンティティの分類および型アノテーションは、登録されたHUBの型システムによって特定することができる。型システムを用いて、リファレンススキーマから導出した関数型およびビジネス型についてルールを規定することができる。型システムを用いて、たとえばブレンド、エンリッチ化、および変換レコメンデーション等のアクションを、型システムに基づいてデータフロー内で特定したエンティティに対して実行することができる。
【0353】
図44は、ある実施形態に係る、関数型ルールを生成するためのシステムを示す図である。
【0354】
図44に示すように、ある実施形態に従うと、コンピュータシステムまたはその他の処理デバイスによって実行可能なソフトウェアまたはプログラムコードとして提供されるルール帰納ロジック850またはソフトウェアコンポーネントによって、ルール851を関数型システム852に対応付けることができる。
【0355】
図44は、ある実施形態に係る、関数型ルールを生成するためのシステムを示す図である。
【0356】
図45に示すように、ある実施形態に従うと、HUB1はリファレンスオントロジーとして機能することができる。これは、他の(たとえば新たに登録された)HUBたとえばHUB2およびHUB3から提供されたメタデータスキーマまたはオントロジーの、型タグ付け、比較、分類、そうでなければ評価に使用することができ、データAIシステムが
使用する適切なルールを作成する。
【0357】
図46は、ある実施形態に係る、関数型ルールの生成に使用するオブジェクト図を示す図である。
【0358】
ある実施形態に従うと、たとえば
図46に示すように、ルール帰納ロジックにより、ルールを、一組の関数型853(たとえばHUB、データセットまたはエンティティ、および属性)を有する関数型システムに対応付け、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションの作成に使用するためにレジストリに格納することができる。これは、各関数型854を関数型ルール856およびルール858に対応付けることができることを含む。各ルールはルールパラメータ860に対応付けることができる。
【0359】
ある実施形態に従うと、最初にリファレンススキーマが処理され、このスキーマに適した一組のルールを含むオントロジーを作成することができる。
【0360】
ある実施形態に従うと、次に新たなHUBまたは新たなスキーマが評価され、そのデータセットまたはエンティティを、既存のオントロジーおよび作成したルールと比較し、新たなHUB/スキーマおよびそのエンティティの解析、ならびに、システムのさらなる学習に、使用することができる。
【0361】
データ統合フレームワークにおけるメタデータハーベスティングはリバースエンジニアリングのエンティティ定義(属性およびそのデータ型、場合によっては関係)に限定される場合があるが、ある実施形態に従うと、本明細書に記載のシステムが提供するアプローチは以下の点が異なる。すなわち、スキーマ定義をリファレンスオントロジーとして使用できるようにし、そこからビジネス型および関数型を導出することができ、また、リファレンススキーマにおけるデータセットまたはエンティティのためのデータプロファイリングメトリクスを導出することができる。そうすると、このリファレンスHUBを用いてその他のHUB(データソース)内のビジネスエンティティを解析することにより、さらに分類またはレコメンデーション(たとえばブレンドまたはエンリッチ化)を行うことができる。
【0362】
ある実施形態に従うと、システムは、リファレンススキーマを用いるオントロジー学習に対して以下の一組のステップを使用する。
【0363】
ユーザは、新たに登録されたHUBをリファレンススキーマとして使用するためのオプションを指定する。
【0364】
エンティティ定義(たとえば属性定義、データ型、エンティティ間の関係、制約またはビジネスルールがインポートされる)。
【0365】
すべてのデータセットまたはエンティティについてサンプルデータが抽出され、データがプロファイリングされてデータに関するいくつかのメトリクスが導出される。
【0366】
型システムがリファレンススキーマの用語集に基づいてインスタンス化される(関数型およびビジネス型)。
【0367】
ビジネス型を記述する一組のルールが導出される。
データルールは、プロファイリングされたデータメトリクスに関して規定され、ビジネス型要素の性質を記述する(たとえば、UOM、ROIまたは通貨の種類は、そのデータ
プロファイルとともにビジネス型要素として規定できる)。
【0368】
要素(リファレンススキーマからインポートされた制約またはリファレンス)におけるアソシエーションを規定する関係ルールが生成される。
【0369】
データおよび関係ルールの組み合わせを通して導出できる複合ルールが生成される。
型システム(関数およびビジネス)は、メタデータハーベスティングおよびデータサンプリングを通して導出されたルールに基づいて規定される。
【0370】
そうすると、パターンまたはテンプレートは、リファレンススキーマに基づいてインスタンス化された型を用いて複雑なビジネスロジックを規定することができる。
【0371】
そうすると、システムに登録されたHUBをリファレンススキーマのコンテキストで解析することができる。
【0372】
新たに登録されたHUBにおいて、データセットまたはエンティティの分類および型アノテーションを、リファレンススキーマから導出した関数型およびビジネス型についてのルールに基づいて、実施することができる。
【0373】
型アノテーションに基づいて、データセットまたはエンティティに対し、ブレンド、エンリッチ化、変換レコメンデーションを実行することができる。
【0374】
図47は、ある実施形態に係る、生成された1つ以上のルールに基づいて関数型システムを生成するプロセスを示す図である。
【0375】
図47に示すように、ある実施形態に従い、ステップ862において、リファレンスHUBを規定する入力を受信する。
【0376】
ステップ863において、リファレンスHUBにアクセスすることにより、リファレンスHUBによって与えられる、データセットまたはエンティティに対応付けられた1つ以上のエンティティ定義を取得する。
【0377】
ステップ864において、リファレンスHUBから1つ以上のデータセットまたはエンティティのサンプルデータを生成する。
【0378】
ステップ865において、このサンプルデータをプロファイリングすることにより、このサンプルデータに対応付けられた1つ以上のメトリクスを判定する。
【0379】
ステップ866において、エンティティ定義に基づいて1つ以上のルールを生成する。
ステップ867において、生成した1つ以上のルールに基づいて関数型システムを生成する。
【0380】
ステップ868において、データ入力の処理において使用するために、関数型システムおよびサンプルデータのプロファイルを永続化する。
【0381】
他言語関数インターフェイス
ある実施形態に従うと、このシステムは、(本明細書においていくつかの実施形態では
他言語関数インターフェイスと呼ぶ)プログラマティックインターフェイスを提供する。このインターフェイスにより、ユーザまたは第三者は、サービス、関数型およびビジネス型、セマンティックアクション、ならびに関数型およびビジネス型に基づくパターンまた
は予め定められた複合データフローを、宣言的に規定することにより、システムの機能を拡張することができる。
【0382】
先に述べたように、現在のデータ統合システムが提供し得るインターフェイスは限られており、タイプに対するサポートがなく、また、オブジェクト組成およびパターン定義について明確に規定されたインターフェイスがない。このような短所のために、フレームワークを拡張するサービス全体にわたってセマンティックアクションを呼び出すためのクロスサービスレコメンデーションまたは統一アプリケーション設計プラットフォームのような複雑な機能は、現在のところ提供されていない。
【0383】
ある実施形態に従うと、多言語関数インターフェイスにより、ユーザは、定義またはその他の情報を(たとえば顧客から他の第三者に)宣言型で提供することによってシステムの機能を拡張することができる。
【0384】
ある実施形態に従うと、システムはメタデータ駆動型であり、多言語関数インターフェイスを通して受けた定義を処理することによってメタデータを求め、当該メタデータの分類たとえばデータ型(たとえば関数型およびビジネス型)を判別し、これらのデータ型(関数およびビジネス両方)を既存のメタデータと比較して、型の一致があるか否かを判断することができる。
【0385】
ある実施形態に従うと、多言語関数インターフェイスを通して受けたメタデータを、システムHUBに格納することにより、システムがデータフローを処理するためにメタデータにアクセスできるようにしてもよい。たとえば、メタデータにアクセスすることにより、入力として受けたデータセットのタイプに基づいてセマンティックアクションを決定することができる。システムは、このインターフェイスを通して提供されたデータのタイプについて許可されるセマンティックアクションを決定することができる。
【0386】
ある実施形態に従うと、共通の宣言型インターフェイスを提供することにより、システムは、ユーザが、サービスネイティブのタイプおよびアクションを、プラットフォームネイティブのタイプおよびアクションにマッピングすることを可能にすることができる。これにより、タイプおよびパターンの発見を通して、統一されたアプリケーション設計体験が可能になる。これはまた、プラットフォームを拡張するさまざまなサービスのコンポーネント、および、各セマンティックアクションのためのネイティブコードの生成を必要とする、純粋に宣言型のデータフロー定義および設計を容易にする。
【0387】
ある実施形態に従うと、多言語関数インターフェイスを通して受けたメタデータを自動で処理し、そこに記述されているオブジェクトまたはアーティファクト(たとえばデータ型またはセマンティックアクション)を、システムが処理するデータフローの動作において使用することができる。1つ以上の第三者システムから受けたメタデータ情報を用いて、サービスを規定する、1つ以上の関数型およびビジネス型を表示する、1つ以上のセマンティックアクションを表示する、または、1つ以上のパターン/テンプレートを表示してもよい。
【0388】
たとえば、ある実施形態に従うと、データの関数型およびビジネス型といった、アクセスされたデータの分類を、判別することができる。この分類は、情報とともに受けたデータに関する情報に基づいて特定することができる。1つ以上の第三者システムからデータを受けることによって、システムの機能を拡張することにより、第三者から受けた情報(たとえばサービス、セマンティックアクション、またはパターン)に基づいてデータフローのデータ統合を実行することができる。
【0389】
ある実施形態に従うと、システムHUB内のメタデータをアップデートすることにより、データに関して特定される情報を含むようにすることができる。たとえば、サービスおよびパターン/テンプレートを、アップデートすることにより、多言語関数インターフェイスを通して受けたメタデータにおいて特定された情報(たとえばセマンティックアクション)に基づいて、実行することができる。このようにして、システムを、データフローの処理を妨害することなく、多言語関数インターフェイスを通して強化することができる。
【0390】
ある実施形態に従うと、後続のデータフローは、システムHUB内のメタデータを、そのアップデート後に用いて処理することができる。メタデータ解析は、データフローアプリケーション、たとえばパイプライン、Lambdaアプリケーションのデータフローに対して実行することができる。次に、システムHUBを用いて、他言語関数インターフェイスを介して提供された定義を考慮して変換のレコメンデーションを決定することができる。変換は、サービスを実行するためにセマンティックアクションを規定するのに使用されるパターン/テンプレートに基づいて決定することができ、セマンティックアクションも同様に他言語関数インターフェイスを介して提供された定義を考慮することができる。
【0391】
図48は、ある実施形態に係る、多言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定するためのシステムを示す図である。
【0392】
図48に示すように、ある実施形態に従うと、他言語関数インターフェイス900を介して受けた定義を用いて、システムHUB内の、サービスレジストリ902、関数およびビジネス型レジストリ904、またはパターン/テンプレート906をアップデートすることができる。
【0393】
ある実施形態に従うと、アップデートした情報を、ルールエンジン908を含むデータAIサブシステムが使用することによって、たとえば、システムHUB内のタイプがアノテートされたHUB、データセットもしくはエンティティ、または属性910を判別し、これらのデータセットまたはエンティティを、ソフトウェア開発コンポーネント(たとえばLambda Studio)を介したデータフローアプリケーションたとえばパイプライン、Lambdaアプリケーションに関するレコメンデーションの提供において使用するために、レコメ
ンデーションエンジン912に提供することができる。
【0394】
図49は、ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定することをさらに示す図である。
【0395】
図49に示すように、ある実施形態に従うと、第三者メタデータ920を他言語関数インターフェイスで受けることができる。
【0396】
図50は、ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定することをさらに示す図である。
【0397】
図50に示すように、ある実施形態に従うと、多言語関数インターフェイスで受けた第三者メタデータを用いてシステムの機能を拡張することができる。
【0398】
ある実施形態に従うと、このシステムにより、明確に規定されたインターフェイスを通してフレームワークを拡張することが可能になる。このインターフェイスにより、サービ
ス、サービスのネイティブなタイプ、サービスによって実現されるセマンティックアクションを、特にサービスの一部として利用できる予め規定されたアルゴリズムを抽出するタイプ付きパラメータ、パターンまたはテンプレートとともに、登録することができる。
【0399】
ある実施形態に従うと、共通の宣言型プログラミングパラダイムを提供することにより、プラガブルサービスアーキテクチャは、サービスネイティブのタイプおよびアクションを、プラットフォームネイティブのタイプおよびアクションにマッピングすることを可能にする。これにより、タイプおよびパターンの発見を通して、統一されたアプリケーションの設計体験が可能になる。これはまた、プラットフォームを拡張するさまざまなサービスのコンポーネント、および、各セマンティックアクションのためのネイティブコードの生成を必要とする、純粋に宣言型のデータフロー定義および設計を容易にする。
【0400】
ある実施形態に従うと、プラガブルサービスアーキテクチャはまた、プラグインのための、コンパイル、生成、デプロイ、および実行時実行フレームワーク(統一アプリケーション設計サービス)を規定する。レコメンデーションエンジンは、プラグインされたすべてのサービスのセマンティックアクションおよびパターンの機械学習および推論を行うことができ、分散型複合データフロー設計および開発に関するクロスサービスセマンティックアクションレコメンデーションを行うことができる。
【0401】
図51は、ある実施形態に係る、他言語関数インターフェイスを介して提供された情報に基づくデータフローに関するレコメンデーションの提供において使用するパターンを特定するプロセスを示す図である。
【0402】
図51に示すように、ある実施形態に従うと、ステップ932において、データの処理において使用するメタデータの1つ以上の定義を他言語関数インターフェイスを介して受信する。
【0403】
ステップ934において、他言語関数インターフェイスを介して受信したメタデータを処理することにより、受信したメタデータによって規定される、分類、セマンティックアクション、パターンを規定するテンプレート、またはサービスのうちの1つ以上を含む、受信したメタデータに関する情報を特定する。
【0404】
ステップ936において、他言語関数インターフェイスを介して受信したメタデータをシステムHUBに格納する。システムHUBは、アップデートされることにより、受信したメタデータに関する情報を含み、かつ、システムのサポートされるタイプ、セマンティックアクション、テンプレート、およびサービスを含むシステムの機能を拡張する。
【0405】
938において、他言語関数インターフェイスを介してシステムHUBにおいてアップデートされた情報に基づいてデータフローに関するレコメンデーションを提供するためのパターンを特定する。
【0406】
ポリシーベースのライフサイクル管理
ある実施形態に従うと、このシステムはデータガバナンス機能を提供することができる。これはたとえば、特定のスナップショットに時間的に関連するデータのスライスごとの、履歴情報(特定のデータはどこから来たデータか)、系統(このデータはどのようにして取得/処理されたか)、セキュリティ(誰がこのデータの責任者だったか)、分類(このデータは何に関連するデータか)、影響力(このデータがビジネスにどれほどの影響があるか)、保持時間(このデータはどれだけの時間存続すべきか)、および有効性(このデータは解析/処理のために除外される/含まれるべきか否か)である。これらは、ライフサイクルの決定およびデータフローのレコメンデーションにおいて使用することができ
る。
【0407】
データライフサイクルの管理についての現在のアプローチは、一時パーティションに全体にわたるデータ特性の変化に基づくガバナンス関連機能またはデータの進化(データプロファイルまたはドリフトの変化)のトラッキングを含まない。システムが観察したまたは導出したデータ特性(分類、変化の頻度、変化のタイプ、またはプロセスにおける用途)は、ライフサイクルの決定またはデータについてのレコメンデーション(保持時間、セキュリティ、有効性、取得間隔)には使用されない。
【0408】
ある実施形態に従うと、システムは、系統トラッキングに基づいてデータフローのライフサイクルを表示できるグラフィカルユーザインターフェイスを提供することができる。ライフサイクルは、どこでデータが処理されたか、および、そのデータの処理中にエラーが生じたか否かを示すことができ、データのタイムライン図(たとえば、データセットの数、データセットのボリューム、およびデータセットの使用)として示すことができる。上記インターフェイスは、データのある時点のスナップショットを提供することができ、かつ、データの処理中にその視覚的インジケータを提供することができる。よって、このインターフェイスにより、データの完全な監査、または、ライフサイクルに基づくデータのシステムスナップショット(たとえばパフォーマンスメトリクス、またはリソース使用法)が可能である。
【0409】
ある実施形態に従うと、システムは、(インジェストされたデータから周期的にサンプリングされた)サンプルデータおよびユーザ規定アプリケーションによる処理のために取得したデータに基づいて、データのライフサイクルを求めることができる。データライフサイクル管理のいくつかの側面は、インジェストされたデータすなわちストリーミングデータおよびバッチデータ(リファレンスおよびインクリメンタル)のカテゴリ全体にわたって同様である。インクリメンタルデータの場合、システムは、スケジュールされたログ収集イベント駆動型方法を用いてデータの一時スライスを取得し以下の機能をカバーするアプリケーションインスタンス全体にわたるスライスの割当を管理することができる。
【0410】
ある実施形態に従うと、システムは、データ損失の場合、システムHUB内で管理されるメタデータから層全体にわたる系統を用いてデータを再構成することができる。
【0411】
たとえば、ある実施形態に従うと、インクリメンタルデータ属性カラム、または、ユーザ構成設定を、特定することにより、インクリメンタルデータを取得することができ、データインジェスト全体にわたり高および低ウォーターマークを維持する。クエリまたはAPIおよび対応するパラメータ(タイムスタンプまたはIDカラム)を、インジェストされたデータに対応付けることができる。
【0412】
ある実施形態に従うと、システムは、層全体にわたって系統情報を管理することができる。それはたとえば、エッジレイヤ内のクエリまたはログメタデータ、スケーラブルI/Oレイヤ内のインジェストごとのトピック/パーティションオフセット、データレイク内のスライス(ファイルパーティション)、このデータを用いた後続のダウンストリーム処理済データセットのプロセス系統(データおよびそれに対応付けられたパラメータを生成するアプリケーションの特定の実行インスタンス)のリファレンス、ターゲットエンドポイントに対してパブリッシュされることが「マークされた」データセットおよびデータレイク内のそれに対応するデータスライスに関するトピック/パーティション、ならびに、ジョブ実行インスタンスのパブリッシュおよび処理されてターゲットエンドポイントに対してパブリッシュされるパーティション内のオフセット、である。
【0413】
ある実施形態に従うと、レイヤ(たとえばエッジ、スケーラブルI/O、データレイク
、またはパブリッシュ)の障害の場合、データはアップストリームレイヤから再構成するかまたはソースから取得することができる。
【0414】
ある実施形態に従うと、システムは、その他のライフサイクル管理機能を果たすことができる。
【0415】
たとえば、ある実施形態に従うと、セキュリティは、データスライスのこれらのレイヤ各々で強化および監査される。データスライスは、処理またはアクセスの対象から除外する、または(既に除外されていた場合は)その対象にすることができる。これにより、スプリアスなまたは破損したデータスライスは処理されないようにすることができる。保持ポリシーは、スライディングウィンドウを通してデータのスライスに対して強化することができる。データのスライスについて影響力を解析する(たとえば、所定のウィンドウのスライスをタグ付けする能力を、四半期ごとの報告のために構築されたデータマートのコンテキストにおいて影響力があると解析)。
【0416】
ある実施形態に従うと、データを、システム内で規定された関数型またはビジネス型をタグ付けすることによって分類する(たとえば、データセットを、ビジネス型(たとえばオーダー、顧客、製品、または時間)とともに関数型でタグ付けする(キューブまたはディメンションまたは階層データとして))。
【0417】
ある実施形態に従うと、システムは、1つ以上のHUBからデータにアクセスすることを含む方法を実行することができる。このデータはサンプリングすることができ、システムは、データの一時スライスを決定し、スライスを管理する。これは、システムのシステムHUBにアクセスし、サンプリングされたデータに関するメタデータを取得することを含む。サンプリングされたデータは、システム内の1つ以上の層全体にわたる系統トラッキングのために管理することができる。
【0418】
ある実施形態に従うと、サンプルデータに関するインクリメンタルデータおよびパラメータは、インジェストされたデータに対して管理することができる。データは、サンプルデータに対応付けられたデータの型のタグ付けによって分類できる。
【0419】
図52は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理を示す図である。
【0420】
たとえば、
図52に示すように、ある実施形態に従うと、このシステムを用いて、HUB952、この例ではOracleデータベース、および、HUB954、この例ではS3またはその他の環境から、データを受けることがきる。エッジレイヤにおいて入力HUBから受けたデータは、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーションによる使用のために、1つ以上のトピックスとして、スケーラブルI/Oレイヤに与えることができる(トピックス各々は分散パーティションとして提供することができる)。
【0421】
ある実施形態に従うと、典型的にはパーティションへのオフセットによって表される、インジェストされたデータは、コンピュートレイヤによって正規化964することができ、システムの層にまたがる1つ以上の一時スライスとしてデータレイクに書き込むことができる。
【0422】
ある実施形態に従うと、このデータはその後、データフローアプリケーションたとえばパイプライン、Lambdaアプリケーション966、968によって使用され、最終的には1つ以上の追加のトピックス960、962に対してパブリッシュ970され、その後、こ
の例ではDBCS環境等の1つ以上の出力HUBでターゲットエンドポイント(たとえばテーブル)に対してパブリッシュされることができる。
【0423】
図52に示すように、ある実施形態に従うと、最初、データ再構成および系統トラッキング情報は、たとえば、履歴情報(provenance)(Hub 1、S3)、系統(lineage)(Source Entity in Hub 1)、セキュリティ(security)(Connection Credential used)、またはデータのインジェストに関するその他の情報を、含み得る。
【0424】
図53は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
図53に示すように、その後、データ再構成および系統トラッキング情報をアップデートすることにより、たとえば、アップデートされた履歴情報(→T1)、系統(→T1(インジェストプロセス(Ingest Process))、またはその他の情報等の情報を含むようにすることができる。
【0425】
図54は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
図54に示すように、その後、データ再構成および系統トラッキング情報をさらにアップデートすることにより、たとえば、アップデートされた履歴情報(→E1)、系統(→E1(正規化(Normalize))、またはその他の情報等の情報を含むようにすることができ
る。
【0426】
ある実施形態に従うと、1つ以上のデータフローアプリケーションたとえばパイプライン、Lambdaアプリケーションによって使用される、一時スライス972は、システムの層にまたがるように作成することができる。障害、たとえば、データレイクへの書込において障害が発生した場合、システムは、未処理の1つ以上のデータスライスを判別し、そのデータスライスの処理を、全体としてまたはインクリメンタルに、完了することができる。
【0427】
図55は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
図55に示すように、その後、データ再構成および系統トラッキング情報をさらにアップデートし追加の一時スライスを作成することにより、たとえば、アップデートされた履歴情報(→E11(App1))、セキュリティ(Role Executing App 1)、またはその他の情報等の情報を含むようにすることができる。
【0428】
図56は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
図56に示すように、その後、データ再構成および系統トラッキング情報をさらにアップデートし追加の一時スライスを作成することにより、たとえば、アップデートされた系統(→E12(App2))、セキュリティ(Role Executing App 2)、またはその他の情報等の情報を含むようにすることができる。
【0429】
図57は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
図57に示すように、その後、データ再構成および系統トラッキング情報をさらにアップデートし追加の一時スライスを作成することにより、たとえば、アップデートされた系統(→T2(Publish))、セキュリティ(Role Executing Publish to I/O Layer)、またはその他の情報等の情報を含むようにすることができる。
【0430】
図58は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理をさらに示す図である。
図58に示すように、その後、データ再構成および系統トラッキング情報をさらにアップデートすることにより、ターゲットエンドポイント976へのデータの出力を反映することができる。
【0431】
データライフサイクル管理
ある実施形態に従うと、上記系統トラッキングに基づくデータライフサイクル管理は、いくつかの機能エリアに向けられている。これらのエリアのうちのいくつかは、ユーザによって構成されることができ(アクセスコントロール、保持時間、有効性)、いくつかは導出され(履歴情報、系統)、それ以外は機械学習アルゴリズムを使用する(分類、影響力)。たとえば、データ管理は、サンプルデータ(インジェストされたデータから定期的にサンプリング)にも、ユーザ規定アプリケーションによる処理のために取得されたデータにも、適用される。データライフサイクル管理のいくつかの側面は、インジェストされたデータすなわちストリーミングデータおよびバッチデータ(リファレンスおよびインクリメンタル)のカテゴリ全体にわたって同様である。インクリメンタルデータの場合、DFMLは、スケジュールされたログ収集イベント駆動型方法を用いてデータの一時スライスを取得し以下の機能をカバーするアプリケーションインスタンス全体にわたるスライスの割当を管理する。
【0432】
データ損失の場合、システムHUBにおいて管理されるメタデータから層全体にわたる系統を用いてデータを再構成。
【0433】
インクリメンタルデータ属性カラムまたはユーザ構成設定を特定することにより、インクリメンタルデータを取得し、インジェスト全体にわたり高および低ウォーターマークを維持。
【0434】
インジェストごとに、クエリまたはAPIおよび対応するパラメータ(タイムスタンプまたはIDカラム)を対応付ける。
【0435】
層全体にわたる系統情報の管理。エッジレイヤ内のクエリまたはログメタデータ。スケーラブルI/Oレイヤ内のインジェストごとのトピック/パーティションオフセット。データレイク内のスライス(ファイルパーティション)。このデータを用いた後続のすべてのダウンストリーム処理済データセットのプロセス系統(データおよびそれに対応付けられたパラメータを生成するアプリケーションの特定の実行インスタンス)のリファレンス。ターゲットエンドポイントに対してパブリッシュされることが「マークされた」データセットのトピック/パーティションオフセットおよびデータレイク内の対応するデータスライス。ジョブ実行インスタンスのパブリッシュおよび処理されてターゲットエンドポイントに対してパブリッシュされるパーティション内のオフセット。
【0436】
レイヤの障害の場合、データはアップストリームレイヤから再構成するかまたはソースから取得することができる。セキュリティは、データスライスのこれらのレイヤ各々で強化および監査される。データスライスは、処理またはアクセスの対象から除外する、または(すでに除外されていた場合は)その対象にすることができる。これにより、スプリアスなまたは破損したデータスライスは処理されないようにすることができる。保持時間ポリシーは、スライディングウィンドウを通してデータのスライスに対して強化することができる。データのスライスについて影響力を解析する(たとえば、所定のウィンドウについてスライスをタグ付けする能力を、四半期ごとの報告のために構築されたデータマートのコンテキストにおいて影響力があると解析)。
【0437】
システム内で規定された関数型またはビジネス型のタグ付けによってデータを分類(たとえば、データセットを、ビジネス型(たとえばオーダー、顧客、製品、または時間)とともに、関数型(キューブまたは次元または階層データ)でタグ付け)。
【0438】
図59は、ある実施形態に係る、1つ以上の層全体にわたる系統トラッキングのための、サンプリングされたデータまたはアクセスされたデータの管理のプロセスを示す図である。
【0439】
図59に示すように、ある実施形態に従うと、ステップ982において、1つ以上のHUBからデータにアクセスする。
【0440】
ステップ983において、アクセスしたデータをサンプリングする。
ステップ984において、サンプリングされたデータおよびアクセスされたデータについて、一時スライスを特定する。
【0441】
ステップ985において、システムHUBにアクセスすることにより、一時スライスによって表されるサンプリングされたデータまたはアクセスされたデータに関するメタデータを取得する。
【0442】
ステップ986において、一時スライスによって表されるサンプリングされたデータまたはアクセスされたデータについて分類情報を判断する。
【0443】
ステップ987において、一時スライスによって表されるサンプリングされたデータまたはアクセスされたデータを、システム内の1つ以上の層全体にわたる系統トラッキングのために管理する。
【0444】
本発明の実施形態は、汎用または専用デジタルコンピュータ、コンピューティングデバイス、マシン、またはマイクロプロセッサを用いて実現可能である。これは、本開示の教示に従ってプログラムされた、1つ以上のプロセッサ、メモリおよび/またはコンピュータ読取可能な記憶媒体を含む。熟練プログラマーは本開示の教示に基づいて適切なソフトウェアコーディングを簡単に作成でき、それはソフトウェア技術の当業者には明らかであろう。
【0445】
いくつかの実施形態において、本発明は、コンピュータをプログラムすることにより本発明のプロセスのうちのいずれかを実行するために使用できる命令が格納された非一時的なコンピュータ読取可能媒体(複数の媒体)であるコンピュータプログラムプロダクトを含む。記憶媒体の例は、フロッピー(登録商標)ディスク、光ディスク、DVD、CD-ROM、マイクロドライブ、および光磁気ディスク、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、フラッシュメモリデバイス、磁気または光カード、名のシステム(分子メモリICを含む)、または、命令および/またはデータの非一時的な格納に適したその他のタイプの記憶媒体または装置を含み得るが、これらに限定される訳ではない。
【0446】
これまでの本発明の記載は例示および説明を目的として提供されている。すべてを網羅するまたは本発明を開示されている形態そのものに限定することは意図されていない。数多くの変更および変形が当業者には明らかであろう。
【0447】
たとえば、上記実施形態のうちのいくつかは、たとえばWolfram、Yago、Chronos、およびSpark等の製品を使用することによりさまざまな計算を実行すること、および、たとえ
ばBDP、SFDCおよびS3等のデータソースを使用することによりデータのソースま
たはターゲットとして機能することを示しているが、本明細書に記載の実施形態は、同様のタイプの機能を提供するその他のタイプの製品およびデータソースとともに使用することもできる。
【0448】
加えて、上記実施形態のうちのいくつかは、さまざまな実施形態のコンポーネント、レイヤ、オブジェクト、ロジックまたはその他の特徴を示しているが、このような特徴は、コンピュータシステムまたはその他処理装置によって実行可能なソフトウェアまたはプログラムコードとして提供することができる。
【0449】
実施形態は、本発明の原理とその実際の応用を最適に説明することにより、意図する特定の用途に適したさまざまな実施形態およびさまざまな変更を伴うこの発明を当業者が理解できるようにすることを目的として、選択され説明されている。変更および変形は、開示されている特徴の関連する任意の組合わせを含む。本発明の範囲は以下の請求項およびその均等物によって規定されることが意図されている。