(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-14
(45)【発行日】2023-12-22
(54)【発明の名称】データ統合方法およびデータ統合システム
(51)【国際特許分類】
G06F 16/90 20190101AFI20231215BHJP
【ＦＩ】
G06F16/90
【請求項の数】
9
(21)【出願番号】P 2020189622
(22)【出願日】2020-11-13
(65)【公開番号】P2022078737
(43)【公開日】2022-05-25
【審査請求日】2023-02-10
(73)【特許権者】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110002365
【氏名又は名称】弁理士法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】高田 実佳
【審査官】早川 学
(56)【参考文献】
【文献】特開２０１４－０９６１７７（ＪＰ，Ａ）
【文献】特開２００５－０６３３３２（ＪＰ，Ａ）
【文献】米国特許出願公開第２００６／０１３６４５２（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０２０／０１２５５３０（ＵＳ，Ａ１）
【文献】国際公開第２０２０／１３９０７９（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／００－１６／９５８
(57)【特許請求の範囲】
【請求項1】
データレイクに格納されている第１のデータおよび第２のデータの型または質の不整合を整合化するデータ統合システムが実行するデータ統合方法であって、前記第１のデータおよび前記第２のデータの特徴量を算出する特徴量算出ステップと、
前記特徴量に基づいて前記第１のデータおよび前記第２のデータの前記不整合を検知する不整合検知ステップと、
ユーザによる前記第１のデータおよび前記第２のデータの取得の要求に応じて、統合ビューを用いて、前記不整合を整合化するデータ調整ステップと
を有することを特徴とするデータ統合方法。
【請求項2】
前記特徴量算出ステップおよび前記不整合検知ステップを予め実行して前記第１のデータおよび前記第２のデータの前記不整合を検知しておき、ユーザによって前記第１のデータおよび前記第２のデータの取得が要求された際に、前記データ調整ステップを実行する
ことを特徴とする請求項１に記載のデータ統合方法。
【請求項3】
前記特徴量算出ステップおよび前記不整合検知ステップを実行して前記第１のデータおよび前記第２のデータの前記不整合を検知した際に、前記データ調整ステップを実行することを特徴とする請求項１に記載のデータ統合方法。
【請求項4】
前記第２のデータとしての対象データをデータモデルのテーブル名および項目名毎に分割する分割ステップと、前記対象データのうち、テーブル名および項目名が同一であるデータ、および、テーブル名および項目名の少なくとも一つが異なるがコンテンツが同一であるデータ、のそれぞれを同一グループにグループ化するグループ化ステップと、
前記グループ化ステップによって同一グループにグループ化されたデータを、共通するデータスキーマへ変換するスキーマ変換ステップと
をさらに有することを特徴とする請求項１に記載のデータ統合方法。
【請求項5】
前記不整合検知ステップでは、前記第１のデータとしての新規データと同一のテーブル名および項目名を有する前記グループ化ステップによってグループ化された既存グループが存在し、かつ、前記既存グループに属するデータの特徴量の中心値を前記既存グループの特徴量とした場合の前記新規データと前記既存グループの特徴量の差分が所定条件を充足する場合に、前記新規データが前記既存グループに属するとして前記不整合を検知せず、
前記新規データと同一のテーブル名および項目名を有する前記既存グループが存在しない、または、前記新規データと前記既存グループの前記特徴量の差分が所定条件を充足しない場合に、前記新規データが前記既存グループに属さず新規グループに属するとして前記不整合を検知する
ことを特徴とする請求項４に記載のデータ統合方法。
【請求項6】
前記グループ化ステップによってグループ化されたグループ毎に統合ビューを用いて他のグループへデータの型または質を変換する際の変換コストを計算する変換コスト計算ステップをさらに有し、前記データ調整ステップにおいて、前記変換コスト計算ステップによって計算された変換コストが最小のグループのデータの型または質を変換コストが最大のグループのデータの型または質へ変換する統合ビューを用いて前記不整合を整合化する
ことを特徴とする請求項５に記載のデータ統合方法。
【請求項7】
前記データ調整ステップにおいて、既存の前記統合ビューを用いて前記不整合を整合化することを特徴とする請求項６に記載のデータ統合方法。
【請求項8】
前記データ調整ステップにおいて、ユーザが要求するデータの型または質を充足するように前記不整合を整合化することを特徴とする請求項１に記載のデータ統合方法。
【請求項9】
データレイクに格納されている第１のデータおよび第２のデータの型または質の不整合を整合化するデータ統合システムであって、前記第１のデータおよび前記第２のデータの特徴量を算出し、前記特徴量に基づいて前記第１のデータおよび前記第２のデータの前記不整合を検知する不整合検知部と、
ユーザによる前記第１のデータおよび前記第２のデータの取得の要求に応じて、統合ビューを用いて、前記不整合を整合化するデータ調整部と
を有することを特徴とするデータ統合システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、データ統合方法およびデータ統合システムに関する。
【背景技術】
【0002】
ＣＳＶ（Comma Separated Value）などの構造化されたデータやテキストファイル等の非構造データなど、様々な形態のデータがデータレイクに蓄積され管理される。そうしたデータの中には、データのプロトコルの変更、センサの変更、ベンダの変更、などの要因によって同じデータの識別子がついたデータでも違うデータ型やデータの質を取ることがある。このように、時間的な前後や同一データが変化することで起こるデータの不整合や、空間的な位置の異なる場所において同じ識別子がついた複数のデータが発生するといった不整合なデータ、が生じることがある。
【0003】
こうしたデータを利用する業務アプリケーションでは、管理されているデータを抽出し、クレンジングやデータ変換などによってデータの型や質が一定あるいは一定範囲となることを想定してデータ準備処理を構築し、業務アプリケーションが正常稼働できるようにシステムが構築される（例えば特許文献１および２参照）。
【先行技術文献】
【特許文献】
【0004】
【文献】国際公開第２０２０／０７９７４９号公報
【文献】特開２０２０－０５２９４３号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
ここで、業務アプリケーションが想定しているデータと実際のデータとの間に型や質の不整合が起こると、業務アプリケーションがエラーや機能不十分に陥るため、迅速にデータの不整合を検知し、データ準備処理を修正し、検知したデータの不整合に対応できるようにすることが行われている。
【0006】
しかしながら上述の従来技術では、データを整合する為のルールを自動的に検知することができるものの、検知したルールに基づき、エンジニアが業務アプリケーションを修正することになる。データの不整合が検知される度にデータ準備処理を業務アプリケーションに施すことは、困難を伴う。すなわち、蓄積データが多数で多様なデータになればなるほど、データの不整合は一般に増加するため、アプリケーション毎に想定するデータ型や質に合わせて調整することはエンジニアリング工数を増加させ、業務アプリケーションを利用する業務への悪影響が深刻化する。
【0007】
本発明は、上記課題に鑑みてなされたものであり、データの不整合を自動的に検知し、ユーザの求めるデータの型や質に基づいてデータの型や質を自動的に調整できるようにすることを目的とする。
【課題を解決するための手段】
【0008】
上記目的を達成するために、本発明のデータ統合方法では、データレイクに格納されている第１のデータおよび第２のデータの型または質の不整合を整合化するデータ統合システムが実行するデータ統合方法であって、前記第１のデータおよび前記第２のデータの特徴量を算出する特徴量算出ステップと、前記特徴量に基づいて前記第１のデータおよび前記第２のデータの前記不整合を検知する不整合検知ステップと、ユーザによる前記第１のデータおよび前記第２のデータの取得の要求に応じて、統合ビューを用いて、前記不整合を整合化するデータ調整ステップとを有することを特徴とする。
【発明の効果】
【0009】
本発明によれば、データの不整合を自動的に検知し、ユーザの求めるデータの型や質に基づいてデータの型や質を自動的に調整できる。
【図面の簡単な説明】
【0010】
【図1】実施例１のデータ統合システムを構成するコンピュータのハードウェア構成の一例を示す図である。
【図2】実施例１のデータ統合システムの機能構成の一例を示す図である。
【図3】実施例１のクラスタテーブルの一例を示す図である。
【図4】実施例１のマップテーブルの一例を示す図である。
【図5A】実施例１の特徴量定義（連続値）の一例を示す図である。
【図5B】実施例１の特徴量定義（離散値）の一例を示す図である。
【図6】実施例１の不整合検知定義の一例を示す図である。
【図7】実施例１のデータ不整合検知処理を示すフローチャートである。
【図8】実施例１のスキーママッピング検知の詳細処理を示すフローチャートである。
【図9】実施例１の不整合検知の詳細処理を示すフローチャートである。
【図10】実施例１のマップ追加・更新の詳細処理を示すフローチャートである。
【図11】実施例１のデータ調整処理を示すフローチャートである。
【図12】実施例１のクエリ解釈の詳細処理を示すフローチャートである。
【図13A】実施例１のＳＱＬのクエリ（連続型データ抽出）の一例を示す図である。
【図13B】実施例１のＳＱＬのクエリ（離散型データ抽出）の一例を示す図である。
【図14】実施例１のユーザ要求を入力するＧＵＩの一例を示す図である。
【図15】実施例１のデータ調整の詳細処理を示すフローチャートである。
【図16】実施例２のデータ不整合検知処理を示すフローチャートである。
【図17】実施例２のユーザによるデータ統合システムへの要求入力処理を示すフローチャートである。
【発明を実施するための形態】
【0011】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素およびその組合せの全てが発明の解決手段に必須であるとは限らない。また発明の構成に必須だが周知である構成については、図示および説明を省略する場合がある。また各図に示す各要素の数は一例であって、図示に限られるものではない。明細書全体を通して使用される用語は、例として提供されるものであり、限定を意図しない。
【0012】
以下では、病院の医療データに関する実施例を開示するが、これに限らず、本発明は、政府機関、産業、金融など様々な分野における多様で大量なデータを扱う分野へ拡張することができる。
【実施例1】
【0013】
（データ統合システムＳを構成するコンピュータ１１０１のハードウェア構成）
図１は、実施例１のデータ統合システムＳを構成するコンピュータ１１０１のハードウェア構成の一例を示す図である。コンピュータ１１０１は、サーバやストレージなどである。プロセッサ１１０２、メモリ１１０３、通信Ｉ／Ｆ１１０４、入力インターフェース１１０５、出力インターフェース１１０６、および記憶装置１１０７など、データ管理を行うための要素を有する。
図１は、実施例１のデータ統合システムＳを構成するコンピュータ１１０１のハードウェア構成の一例を示す図である。コンピュータ１１０１は、サーバやストレージなどである。プロセッサ１１０２、メモリ１１０３、通信Ｉ／Ｆ１１０４、入力インターフェース１１０５、出力インターフェース１１０６、および記憶装置１１０７など、データ管理を行うための要素を有する。
【0014】
コンピュータ１１０１が有する各要素は、バス１１０８を通して互いに接続される。コンピュータ１１０１は、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）などであるネットワーク１１０９を通して、外部の１または複数のクライアント装置１１１０に接続されて、双方向または一方向の方式でデータの送受信を行う。
【0015】
クライアント装置１１１０は、ＧＵＩなどを介して、ユーザの入力を受付け、コンピュータ１１０１へ送信する。また、クライアント装置１１１０は、ユーザの入力に応じた処理結果をコンピュータ１１０１から受信し、ＧＵＩなどを介してユーザに対して表示する。プロセッサ１１０２は、ＡＳＩＣやＰＬＤといったハードウェアプロセッサ、ＣＰＵといったソフトウェアプロセッサ、または、ハードウェアプロセッサおよびソフトウェアプロセッサの組合せである。
【0016】
（データ統合システムＳの機能構成）
図２は、実施例１のデータ統合システムＳの機能構成の一例を示す図である。データ統合システムＳは、サーバ１０００およびストレージ１０１０を含んで構成される。サーバ１０００およびストレージ１０１０は、連携可能に接続されている。
図２は、実施例１のデータ統合システムＳの機能構成の一例を示す図である。データ統合システムＳは、サーバ１０００およびストレージ１０１０を含んで構成される。サーバ１０００およびストレージ１０１０は、連携可能に接続されている。
【0017】
サーバ１０００は、スキーママッピング検知部１００１、不整合検知部１００２、マップ追加・更新部１００３、クエリ解釈部１００４、データ調整部１００５、およびＵＩ部１００６を有し、変換コスト１００７を保存している。
【0018】
ストレージ１０１０は、クラスタテーブル１０１１、マップテーブル１０１２、特徴量定義１０１３、不整合検知定義１０１４、オリジナルデータ１０１５を格納する。オリジナルデータ１０１５は、不整合検知およびデータ調整の対象となるデータであり、図２では説明の簡単のためストレージ１０１０内のデータレイクに格納されているとして説明するが、ストレージ１０１０以外の装置内のデータレイクに格納されていてもよい。
【0019】
なお、スキーママッピング検知部１００１、不整合検知部１００２、マップ追加・更新部１００３、クエリ解釈部１００４、およびデータ調整部１００５といったデータ整合化に係る機能部は、図２では説明の便宜上サーバ１０００内に配置している。しかしこれに限らず、オリジナルデータ１０１５を格納するデータレイク内、データレイク外、あるいはＳＱＬを発行するＤＢＭＳ（Data Base Management System）内に配置されるなど様々な形態がある。
【0020】
（クラスタテーブル１０１１）
図３は、実施例１のクラスタテーブル１０１１の一例を示す図である。クラスタテーブル１０１１は、テーブル名１０１１１、カラム名１０１１２、データ型１０１１３、データフォーマット１０１１４、レコード識別番号１０１１５、クラスタ番号１０１１６、クラスタ中心値１０１１７のカラムを有する。
図３は、実施例１のクラスタテーブル１０１１の一例を示す図である。クラスタテーブル１０１１は、テーブル名１０１１１、カラム名１０１１２、データ型１０１１３、データフォーマット１０１１４、レコード識別番号１０１１５、クラスタ番号１０１１６、クラスタ中心値１０１１７のカラムを有する。
【0021】
カラム名１０１１２は、テーブル名１０１１１で特定されるテーブルにおいてタグまたはカラムとして与えられた項目の名称である。データ型１０１１３はカラム名１０１１２のデータの種類であり、データフォーマット１０１１４はデータ型１０１１３の形式情報である。例えばデータ型１０１１３がTimestamp(0)（日時型）である場合に、データフォーマット１０１１４が“yyyy/MM/dd hh:mm:ss”といったように、該当クラスタにおけるデータの表現形式を定める。
【0022】
レコード識別番号１０１１５は、テーブル名１０１１１で与えられたテーブル内のレコードのうちクラスタを構成するレコードの識別番号である。クラスタ番号１０１１６は、レコード識別番号１０１１５で識別されるレコードで構成されるクラスタの識別番号である。クラスタ中心値１０１１７は、クラスタ番号１０１１６で識別されるクラスタの特徴ベクトル空間における中心値である。クラスタはグループの一例であり、グラスタリングはグループ化の一例である。
【0023】
（マップテーブル１０１２）
図４は、実施例１のマップテーブル１０１２の一例を示す図である。マップテーブル１０１２は、クラスタ番号（１）１０１２１、クラスタ番号（２）１０１２２、距離（Dis）１０１２３、特徴量１差分（diff(1)）１０１２４、および特徴量２差分（diff(2)）１０１２５のカラムを有する。
図４は、実施例１のマップテーブル１０１２の一例を示す図である。マップテーブル１０１２は、クラスタ番号（１）１０１２１、クラスタ番号（２）１０１２２、距離（Dis）１０１２３、特徴量１差分（diff(1)）１０１２４、および特徴量２差分（diff(2)）１０１２５のカラムを有する。
【0024】
距離１０１２３は、クラスタ番号（１）１０１２１およびクラスタ番号（２）１０１２２で特定される２つのクラスタ間の距離である。特徴量１差分（diff(1)）１０１２４は、１つ目の特徴量に関し、クラスタ番号（１）１０１２１およびクラスタ番号（２）１０１２２で特定される２つのクラスタ間の差分である。特徴量２差分（diff(2)）１０１２５は、２つ目の特徴量に関し、クラスタ番号（１）１０１２１およびクラスタ番号（２）１０１２２で特定される２つのクラスタ間の差分である。
【0025】
（特徴量定義１０１３）
図５Ａは、実施例１の特徴量定義１０１３（連続値）の一例を示す図である。特徴量定義１０１３（連続値）は、例えばPatient_ID１０１３０が“１”のデータに関して、連続値のデータ型１０１３１がTimestamp(0)（日時型）であり、特徴量としてのデータフォーマット１０１３２が“yyyy/MM/dd hh:mm:ss”であることを示す。
図５Ａは、実施例１の特徴量定義１０１３（連続値）の一例を示す図である。特徴量定義１０１３（連続値）は、例えばPatient_ID１０１３０が“１”のデータに関して、連続値のデータ型１０１３１がTimestamp(0)（日時型）であり、特徴量としてのデータフォーマット１０１３２が“yyyy/MM/dd hh:mm:ss”であることを示す。
【0026】
図５Ｂは、実施例１の特徴量定義１０１３（離散値）の一例を示す図である。特徴量定義１０１３（離散値）は、例えばPatient_ID１０１３０が“１”のデータに関して、離散値のデータ型１０１３３がTextであり、特徴量としてのデータフォーマット１０１３４が{‘H’,‘L’,‘N’}”であることを示す。
【0027】
（不整合検知定義１０１４）
図６は、実施例１の不整合検知定義１０１４の一例を示す図である。不整合検知定義１０１４は、不整合検知の際に用いられる閾値である。図６の例では閾値＝１であるが、適宜変更可能である。
図６は、実施例１の不整合検知定義１０１４の一例を示す図である。不整合検知定義１０１４は、不整合検知の際に用いられる閾値である。図６の例では閾値＝１であるが、適宜変更可能である。
【0028】
（データ不整合検知処理）
図７は、実施例１のデータ不整合検知処理を示すフローチャートである。データ不整合検知処理では、データの型または質の不整合を検知する。データ不整合検知処理は、定期的、あるいはエンジニアの指示タイミングで実行される。
図７は、実施例１のデータ不整合検知処理を示すフローチャートである。データ不整合検知処理では、データの型または質の不整合を検知する。データ不整合検知処理は、定期的、あるいはエンジニアの指示タイミングで実行される。
【0029】
先ずＳ１１では、スキーママッピング検知部１００１は、スキーママッピング検知を実行する。スキーママッピング検知Ｓ１１の詳細処理は、図８を参照して後述する。
【0030】
次にＳ１２では、不整合検知部１００２は、不整合検知を実行する。不整合検知では、不整合検知部１００２は、特徴量空間における新規データが属するクラスタを判別し、判別したクラスタ情報をクラスタテーブル１０１１に格納する。不整合検知部１００２は、新規データが属するクラスタが既存クラスタではなく新規クラスタである場合には、不整合検知フラグを出力する。不整合検知Ｓ１２の詳細処理は、図９を参照して後述する。
【0031】
次にＳ１３では、不整合検知部１００２は、Ｓ１２で不整合検知フラグを出力した場合にはＳ１４へ処理を移し、不整合検知フラグを出力しなかった場合にはデータ不整合検知処理を終了する。
【0032】
Ｓ１４では、マップ追加・更新部１００３は、Ｓ１２で検知された新規クラスタと既存クラスタについて、マップテーブル１０１２に新規レコード追加するか、またはマップテーブル１０１２のレコードを更新する。マップ追加・更新Ｓ１４の詳細処理は、図１０を参照して後述する。
【0033】
（スキーママッピング検知Ｓ１１の詳細処理）
図８は、実施例１のスキーママッピング検知Ｓ１１の詳細処理を示すフローチャートである。先ずＳ１１１では、スキーママッピング検知部１００１は、データレイク中のオリジナルデータ１０１５から入力対象データを受信する。次にＳ１１２では、スキーママッピング検知部１００１は、Ｓ１１１で受信した入力対象データを、データモデルのテーブル名およびカラム（項目）名毎に分割する。データモデルには、ＲＤＢ（Relational Database）形式やＣＳＶ形式等の構造データファイル形式などがある。またカラム名が存在しないデータに対し、データロード時に付けされたタグなどもカラム名相当とする。
図８は、実施例１のスキーママッピング検知Ｓ１１の詳細処理を示すフローチャートである。先ずＳ１１１では、スキーママッピング検知部１００１は、データレイク中のオリジナルデータ１０１５から入力対象データを受信する。次にＳ１１２では、スキーママッピング検知部１００１は、Ｓ１１１で受信した入力対象データを、データモデルのテーブル名およびカラム（項目）名毎に分割する。データモデルには、ＲＤＢ（Relational Database）形式やＣＳＶ形式等の構造データファイル形式などがある。またカラム名が存在しないデータに対し、データロード時に付けされたタグなどもカラム名相当とする。
【0034】
次にＳ１１３では、スキーママッピング検知部１００１は、Ｓ１１２で分割したデータのうち、テーブル名およびカラム名の少なくとも一方が異なるが、データのコンテンツが同値とみなせるデータの組合せが存在するかを判定する。データのコンテンツとは、テーブル名や項目名といったデータの属性以外のデータの実体である。スキーママッピング検知部１００１は、そのようなデータの組合せが存在する場合（Ｓ１１３ＹＥＳ）にはＳ１１４へ処理を移し、存在しない場合（Ｓ１１３ＮＯ）にはＳ１１５へ処理を移す。
【0035】
Ｓ１１４では、スキーママッピング検知部１００１は、テーブル名およびカラム名の少なくとも一方が異なってもコンテンツが同一であるデータを同一のテーブル名およびカラム名として同一グループにグルーピングする。この際、同一グループにグルーピングしたデータを、共通するデータスキーマに変換してもよい。一方Ｓ１１５では、組（テーブル名およびカラム名）が同じものを同一グループにグルーピングする。最後にＳ１１６では、スキーママッピング検知部１００１は、Ｓ１１４またはＳ１１５で同一グループにグルーピング（クラスタリング）されたデータをグループ毎に出力する。スキーママッピング検知部１００１は、グループ毎のデータを、クラスタテーブル１０１１に格納する。
【0036】
（不整合検知Ｓ１２の詳細処理）
図９は、実施例の不整合検知Ｓ１２の詳細処理を示すフローチャートである。先ずＳ１２１では、不整合検知部１００２は、オリジナルデータ１０１５として新規にロードされた新規データを受信する。次にＳ１２２では、不整合検知部１００２は、特徴量定義１０１３に基づいて、Ｓ１２１で受信した新規データから特徴量ベクトルを算出する。
図９は、実施例の不整合検知Ｓ１２の詳細処理を示すフローチャートである。先ずＳ１２１では、不整合検知部１００２は、オリジナルデータ１０１５として新規にロードされた新規データを受信する。次にＳ１２２では、不整合検知部１００２は、特徴量定義１０１３に基づいて、Ｓ１２１で受信した新規データから特徴量ベクトルを算出する。
【0037】
次にＳ１２３では、不整合検知部１００２は、Ｓ１２１で受信した新規データの持つテーブル名およびカラム名に対応する既存クラスタがクラスタテーブル１０１１内に存在するか否かを判定する。そして、不整合検知部１００２は、Ｓ１２２で生成した特徴量ベクトルをもとに、新規データが既存クラスタに属するか否かを判定し、既存クラスタに属さない場合は新規クラスタに属すると決定する。
【0038】
具体的には、次のようにクラスタを決定する。新規データとある既存クラスタとの間の距離Disを、例えば下記式（１）のように算出する。新規データの特徴量をｆ１＝（ｘ１，ｘ２）、ある既存クラスタの特徴量の中心をｆ２＝（ｃ１，ｃ２）＝（（ａ１＋ａ２＋…＋ａｍ）／ｍ，（ｂ１＋ｂ２＋…＋ｂｍ）／ｍ）とする。この既存クラスタに既に属しているデータの特徴量を、（ａ１，b１）、（ａ２，b２）、…、（ａｍ，bｍ）としている。
【0039】
不整合検知部１００２は、Dis＜不整合検知定義１０１４の値（本実施例では“１”）であれば新規データがある既存クラスに属するとし、それ以外であればその既存クラスタには属さないと判定し、新規データが属するクラスタを特定する。新規データが何れの既存クラスタにも属さない場合は、新規データは新規クラスタに属するとする。
【数1】
【0040】
また、不整合検知部１００２は、特徴量１差分（diff(1)）１０１２４および特徴量２差分（diff(2)）１０１２５を、下記式（２－１）、式（２－２）のように算出する。なお、下記式（２－１）および式（２－２）は、特徴量が２つの場合であり、特徴量の数だけ特徴量差分が算出される。
【数2】
【0041】
また、不整合検知部１００２は、新規データが、特徴量の中心がｆ２＝（ｃ１，ｃ２）である既存クラスタに属する場合には、下記式（３）にようにクラスタの特徴量の中心ｆ２を更新する。下記式（３）における“ｃ１_next”、“ｃ２_next”は、更新後の特徴量の中心である。
ｆ２＝（ｃ１_next，ｃ２_next）
＝（（ｘ１＋ａ１＋ａ２＋・・・＋ａｍ）／ｍ，（ｘ２＋ｂ１＋ｂ２＋・・・＋ｂｍ）／ｍ）・・・（３）
ｆ２＝（ｃ１_next，ｃ２_next）
＝（（ｘ１＋ａ１＋ａ２＋・・・＋ａｍ）／ｍ，（ｘ２＋ｂ１＋ｂ２＋・・・＋ｂｍ）／ｍ）・・・（３）
【0042】
なお、既存クラスタと新規データの特徴量ベクトルの差分やその次元毎の差分は、ユークリッド距離に限らず、他の距離でもよい。
【0043】
次にＳ１２４では、不整合検知部１００２は、Ｓ１２３で判定したクラスタ名やクラスタ中心値などのＳ１２４で導出された値をクラスタテーブル１０１１に追記する。次にＳ１２５では、不整合検知部１００２は、Ｓ１２３で算出したクラスタ間毎の距離Dis、特徴量毎の差分diff(1)、diff(2)、およびＳ１２３で新規クラスタを生成した際の不整合検知フラグを出力する。
【0044】
（マップ追加・更新Ｓ１４の詳細処理）
図１０は、実施例１のマップ追加・更新Ｓ１４の詳細処理を示すフローチャートである。先ずＳ１４１では、マップ追加・更新部１００３は、Ｓ１２５の出力結果を受信する。次にＳ１４２では、マップ追加・更新部１００３は、クラスタ間毎の距離Disと特徴量毎の差分diff(1)，diff(2)を、マップテーブル１０１２に追記する。本実施例では、例えば２次元の特徴ベクトルの場合を示すが、ｎ次元になっても同様である。
図１０は、実施例１のマップ追加・更新Ｓ１４の詳細処理を示すフローチャートである。先ずＳ１４１では、マップ追加・更新部１００３は、Ｓ１２５の出力結果を受信する。次にＳ１４２では、マップ追加・更新部１００３は、クラスタ間毎の距離Disと特徴量毎の差分diff(1)，diff(2)を、マップテーブル１０１２に追記する。本実施例では、例えば２次元の特徴ベクトルの場合を示すが、ｎ次元になっても同様である。
【0045】
（データ調整処理）
図１１は、実施例１のデータ調整処理を示すフローチャートである。データ調整処理は、オリジナルデータ１０１５に対するクエリをクエリ解釈部１００４が検知する度に起動される処理である。
図１１は、実施例１のデータ調整処理を示すフローチャートである。データ調整処理は、オリジナルデータ１０１５に対するクエリをクエリ解釈部１００４が検知する度に起動される処理である。
【0046】
先ずＳ２１では、クエリ解釈部１００４は、クエリ解釈を実行する。すなわち、クエリの要求対象とするデータの型やデータの質の対象データを抽出する。クエリ解釈Ｓ２１の詳細処理は、図１２を参照して後述する。
【0047】
次にＳ２２では、クエリ解釈部１００４は、Ｓ２１で抽出された対象データに対するレコードがマップテーブル１０１２に存在するか否かを判定し、存在すればＳ２３へ処理を移し、存在しなければデータ調整処理を終了する。
【0048】
Ｓ２３では、データ調整部１００５で抽出された対象データに対する不整合を整合化するデータ調整を行う。データ調整Ｓ２３の詳細処理は、図１５を参照して後述する。
【0049】
（クエリ解釈の詳細処理）
図１２は、実施例１のクエリ解釈の詳細処理を示すフローチャートである。先ずＳ２１１では、クエリ解釈部１００４は、ユーザがＳＱＬやＵＩ部１００６のＧＵＩなどから指定した、ユーザが要求するデータ項目の型やデータの質を受信する。データの質とは、例えばデータの精度や粒度である。ＳＱＬインターフェースやＵＩ部１００６のＧＵＩは、スタンドアローンで提供されてもよいし、ウェブで提供されてもよい。Ｓ２１１でユーザが要求するデータの型または質が指定されることで、後述のデータ調整Ｓ２３が実行される際、ユーザ所望のデータの型または質の変換が実行される。
図１２は、実施例１のクエリ解釈の詳細処理を示すフローチャートである。先ずＳ２１１では、クエリ解釈部１００４は、ユーザがＳＱＬやＵＩ部１００６のＧＵＩなどから指定した、ユーザが要求するデータ項目の型やデータの質を受信する。データの質とは、例えばデータの精度や粒度である。ＳＱＬインターフェースやＵＩ部１００６のＧＵＩは、スタンドアローンで提供されてもよいし、ウェブで提供されてもよい。Ｓ２１１でユーザが要求するデータの型または質が指定されることで、後述のデータ調整Ｓ２３が実行される際、ユーザ所望のデータの型または質の変換が実行される。
【0050】
Ｓ２１１で受信されるユーザ要求が指定されたＳＱＬの例としては、連続型データ抽出のためのＳＱＬと離散型データ抽出のためのＳＱＬがある。図１３Ａは、実施例１のＳＱＬのクエリ（連続型データ抽出）の一例を示す図である。図１３Ａは、テーブルLab_testから、Test_dateが2016-01-01 00:00:00～2020-04-02 23:59:59の期間に該当するレコードのデータ項目Patient_ID、Test_date、Test_id、Test_resultを抽出する例を示す。
【0051】
また、図１３Ｂは、実施例１のＳＱＬのクエリ（離散型データ抽出）の一例を示す図である。図１３Ｂは、テーブルLab_testから、Patient_idが“P00001”かつTest_resultが“H”または“L”に該当するレコードのデータ項目Patient_ID、Test_date、Test_id、Test_resultを抽出する例を示す。
【0052】
【0053】
ＧＵＩ６１０は、テーブル選択セクション６１１、選択されたテーブルから抽出するレコードの項目（カラム）を選択する抽出項目選択セクション６１２、レコードの抽出期間を指定する抽出期間６１７、抽出項目選択セクション６１２で選択された抽出項目の抽出条件を指定する項目抽出条件６２０、抽出条件に該当する抽出結果を出力する出力セクション６２５を有する。
【0054】
図１４は、抽出項目がPatient_ID６１３、Test_date６１４、Test_id６１５、Test_result６１６であり、選択欄ですべてのカラムを選択する例を示す。抽出期間６１７は、抽出項目選択セクション６１２中にTest_date６１４のように時刻型のデータがある場合に、Test_date６１８に対応する時間範囲６１９が指定される。時間範囲６１９に指定がなければ全時刻範囲となる。
【0055】
項目抽出条件６２０は、抽出項目選択セクション６１２で選択されたカラム毎にPatient_ID６２１に対してはNullが５％未満という条件、Test_date６２２に対してはTimestamp(0)型、Test_id622に対してはNullが５％未満、Test_result６２１に対してはNullが５％未満かつ値が(‘H’または‘L’)である、という条件を付けてデータを抽出する例である。出力セクション６２５には、抽出結果のデータが表示される。
【0056】
説明を図１２に戻す。次にＳ２１２では、クエリ解釈部１００４は、クエリ（またはデータ抽出アプリから入力されたデータ抽出条件）を分解し、アクセス先データ情報である対象データと対象期間を抽出する。対象データは、スキーマ名、対象テーブル名、および対象カラム名から成る辞書型でもよいし、ファイルパスなどでもよく、ユーザが指定するデータを特定するに十分な情報であればよい。
【0057】
（データ調整Ｓ２３の詳細処理）
図１５は、実施例１のデータ調整Ｓ２３の詳細処理を示すフローチャートである。先ず、Ｓ２３１では、データ調整部１００５は、Ｓ２１２で得られたユーザが要求する対象データとデータレイクに格納されているデータ、および対象データに対応するマップテーブル１０１２のレコードに基づいて、クラスタ毎に統合ビューを用いて他のクラスタへデータの型および質を変換して整合化する変換コスト１００７を計算する。
図１５は、実施例１のデータ調整Ｓ２３の詳細処理を示すフローチャートである。先ず、Ｓ２３１では、データ調整部１００５は、Ｓ２１２で得られたユーザが要求する対象データとデータレイクに格納されているデータ、および対象データに対応するマップテーブル１０１２のレコードに基づいて、クラスタ毎に統合ビューを用いて他のクラスタへデータの型および質を変換して整合化する変換コスト１００７を計算する。
【0058】
例えば、変換コスト１００７は、クラスタに属するオリジナルデータ１０１５のレコード数に比例する値として計算できる。または、変換コスト１００７は、クラスタ間の距離１０１２３、特徴量１差分（diff(1)）１０１２４、および特徴量２差分（diff(2)）１０１２５に基づく値として計算できる。あるいは、変換コスト１００７は、変換するレコード数と１レコードあたりの変換コストの積に関する関数として計算してもよく、方法はこれらまたはこれらの組合せに限らない。
【0059】
次にＳ２３２では、データ調整部１００５は、Ｓ２１２で得た対象データを、最小の変換コストで、マップテーブル１０１２を用いて整合化しデータの型または質を統合することができる既存ビューが存在するか探索する。既存ビューは、所定の記憶領域に保存されている。データ調整部１００５は、既存ビューが存在する場合には既存ビューを利用し、Ｓ２３３へ処理を移す。既存ビューを利用することで、データの型または質の変換の処理負荷をさらに軽減できる。
【0060】
一方、データ調整部１００５は、既存ビューが存在しない場合にはＳ２３１で計算した変換コスト１００７が小さいクラスタから最大クラスタのデータ型およびデータフォーマットへ変換する。これにより、変換コストを抑えてデータの型または質を変換することができる。データ調整部１００５は、データ型の変換後、Ｓ２１２で得られたユーザが要求する対象データから、マップテーブル１０１２を用いて新規ビューを生成し、所定の記憶領域に保存する。
【0061】
次にＳ２３３では、データ調整部１００５は、Ｓ２１２で得られた対象データのデータ名（例えばテーブル名またはファイル名）を一時的に変更し、統合ビュー（Ｓ２３２の既存ビューまたは新規ビュー）の名称をＳ２１２で得られた対象データのテーブル名およびカラム名とする。
【0062】
（実施例１の効果）
本実施例では、データを利用して監視や機械学習などを行うアプリケーションのためのデータを格納するデータレイクのデータのデータ型に時間的・空間的な不整合がある場合に、アプリ改修で整合化するのではなく、ビューを生成し、このビューを用いてユーザの要求レベルを充足するように整合化することで、アプリ改修と比較して工数削減を図ることができる。
本実施例では、データを利用して監視や機械学習などを行うアプリケーションのためのデータを格納するデータレイクのデータのデータ型に時間的・空間的な不整合がある場合に、アプリ改修で整合化するのではなく、ビューを生成し、このビューを用いてユーザの要求レベルを充足するように整合化することで、アプリ改修と比較して工数削減を図ることができる。
【0063】
また本実施例では、データ型の不整合のみならず、データ品質（データ粒度等）の不整合もビューを用いた整合化の対象とする。機械学習アプリケーションのようにデータ品質がユーザ要求を充足することが求められる場合、対象データを調整することで、ユーザの品質要求を充足することができる。
【0064】
また本実施例では、データの型または質の不整合を予め検知しておき、ユーザによってクエリが発行された際に、抽出に該当するデータの不整合を統合ビューを用いて整合化するので、クエリ発行頻度が少ない場合に、無駄な整合化処理を行うことなく、必要に応じて効率的に整合化を行うことができる。
【実施例2】
【0065】
以下、本発明の実施例２を説明する。実施例２の説明では、実施例１との差分のみを説明し、重複説明を省略する。実施例１の不整合検知処理（図７）では、不整合を検知しても直ちにはデータ調整を行わず、クエリ受信時にデータ調整を行う場合（図１１）を示したが、これに限らず、データ不整合を検知すると直ちにデータ調整を実行してもよい。以下、これを実施例２として説明する。
【0066】
図１６は、実施例２のデータ不整合検知処理を示すフローチャートである。実施例２のデータ不整合検知処理は、実施例１のデータ不整合検知処理（図７）と比較して、Ｓ１１～Ｓ１４までは同様であるが、Ｓ１４に続いてＳ２３が実行される点が異なる。Ｓ２３は、データ調整部１００５が行う処理であり、実施例１のデータ調整処理（図１１）のＳ２３と同一である。図１６のＳ２３でデータ調整を行い、いかなる不整合に対してもこの不整合を調整するビューを随時用意する。データ不整合検知処理は、定期的、あるいはエンジニアの指示タイミングで実行される。
【0067】
図１７は、実施例２のユーザによるデータ統合システムＳへの要求入力処理を示すフローチャートである。本処理では、図１４に示す実施例１と同様のＧＵＩ６１０を用いる。Ｓ３１では、ＵＩ部１００６は、ＧＵＩ６１０を介して入力されたユーザ要求データをクエリ解釈部１００４へ送信する。次にＳ２１では、クエリ解釈部１００４は、Ｓ３１で送信されたクエリを解釈する。図１６のＳ２１は、図１１のＳ２１と同様の処理である。次にＳ３２では、ＵＩ部１００６は、ユーザが要求したデータをＧＵＩ６１０に表示する。
【0068】
図１４を参照して、ＧＵＩ６１０の例を説明する。Ｓ３１でユーザによって入力される部分はテーブル選択セクション６１１、抽出項目選択セクション６１２、抽出期間６１７、項目抽出条件６２０の抽出条件セクションが該当する。Ｓ３２で取得されたデータは、出力セクション６２５に表示される。
【0069】
なお、実施例２においても、クエリ解釈部１００４が、ユーザが要求するデータ項目やデータ品質を受信する方法は、ＧＵＩ６１０を介したデータ要求に限らず、ＳＱＬなどのクエリによって受信する方法であってもよい。
【0070】
（実施例２の効果）
本実施例では、データの型または質の不整合を検知した際に、該当するデータの不整合を統合ビューを用いて整合化するので、クエリ発行頻度が多い場合にシステム負荷を掛けることなく不整合を是正し、データ統合を効率的に行うことができる。
本実施例では、データの型または質の不整合を検知した際に、該当するデータの不整合を統合ビューを用いて整合化するので、クエリ発行頻度が多い場合にシステム負荷を掛けることなく不整合を是正し、データ統合を効率的に行うことができる。
【0071】
上述した実施形態は、本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。さらに、上述した複数の実施形態および変形例において、本発明の主旨を変えない範囲内で、装置またはシステム構成の変更や、一部の構成または処理手順の省略や入れ替え、組合せを行ってもよい。さらに、図１、図２で説明したハードウェア図やブロック図では、制御線や情報線は説明上必要と考えられるものだけを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【0072】
１０００：サーバ、１００１：スキーママッピング検知部、１００２：不整合検知部、１００３：マップ追加・更新部、１００４：クエリ解釈部、１００５：データ調整部、１００６：ＵＩ部、１００７：変換コスト、１０１０：ストレージ、１０１１：クラスタテーブル、１０１２：マップテーブル、１０１３：特徴量定義、１０１４：不整合検知定義、１０１５：オリジナルデータ
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】