この記事は、ビル・インモン氏による独占コンテンツのゲスト投稿です。ビル・インモン氏は、「データウェアハウスの父と呼ばれるアメリカのコンピュータ科学者であり、データウェアハウスに関する本の出版、雑誌のコラムの投稿、会合の開催、そしてクラスを提供した最初の人である。」-ウィキペディアより

主なポイント

  1. 基本的にレイクハウスは、【構造化データ】、【トランザクションベースのデータ】、【テキストデータ】の3種類のデータで構成されている
  2. ブレンドデータを用いた分析処理では、複数の環境からのデータを分析するという課題への取り組みが必要である
  3. 生のテキストは、メール、インターネット、リサーチ、会話、印刷された報告書などから得られることがある
  4. 2種類のデータの根本的な違いにより、データの交点は見つかりにくくなっている
  5. テキスト環境のデータと構造化環境のデータを組み合わせることで、より包括的な分析が可能になる

多くの計算・分析環境の特徴の1つは、OLTP（オンライントランザクション処理）環境は主にトランザクションベースのデータで、データウェアハウス環境は統合された過去のデータで、テキスト環境はテキストでなど、環境が1種類のデータのみで構成されている点です。

目次

レイクハウス

ただしレイクハウスに関しては、データの種類の特異性に例外があります。レイクハウスは主に、構造化データ、トランザクションデータ、テキストデータの3種類のデータと、IoTやアナログベースのデータなどその他の非構造化データで構成されています。このようにデータレイクハウスには様々な種類のデータが混在しているため、データレイクハウスを利用する際に「異なるタイプのデータをうまくブレンドする」という新たな問題が発生します。

ブレンドされたデータを使って分析処理を行うには、異なる環境のデータをどのように分析するかという問題に取り組まなければいけません。

データの起源

データレイクハウスで見つかったデータの出自は次のように表示されます。：

データレイクハウス内のデータは、通常、2つの異なる処理技術から作成されており、レイクハウス内の構造化データおよびその他の非構造化データは出力として実現され、テキストデータは生のテキストをテキストETLに通すことで実現されます。このようなデータソースから、データはデータレイクハウスに到着します。

データ解析の種類

データレイクアーキテクチャでは、基本的に3つのタイプの分析ができます：

  • 構造化データ分析
  • テキストデータのみの分析
  • テキストと構造化データの混合分析

構造化環境におけるデータは、通常、高度に構造化された形で発見され、キーや属性、インデックス、レコードが、構造化環境で見られるデータの典型的なものになります。

構造化環境におけるレコードは、それぞれこのような特性をすべて備えており、例えば社会保障番号は、キーの簡単な例として考えられます。そして属性の簡単な例は、その人の名前や住所、電話番号などで、インデックスの簡単な例は、その人が住んでいる町とか。そしてこのような情報は、すべて1つのレコードに含まれています。

構造化環境の各レコードには、このような情報がすべてあります：

反復データ

構造化環境の各レコードは同じ種類の情報を持っているので、レコードは反復的であると言われています。各レコードに同じタイプの情報があるといって、各レコードの情報が同じというわけではありません。例えばあるレコードでは名前はメアリー・ジョーンズかもしれませんし、次のレコードでは名前はサム・スミスとなっています。でもそれぞれのレコードに名前がありますよね。「同じタイプのデータ」と「同じデータ」は違うのです。

構造化されたデータからしか作成できない分析の簡単な例として、アナリストのキャッシュフローに関する月次レポートの発行があります。お金の出どころは様々で、月ごとに違いますよね。キャッシュフローの分析は、企業のKPIの1つになります。

テキスト環境から

テキスト環境からのデータは、生のテキストとして始まり、生のテキストは、メールやインターネット、リサーチや会話、印刷されたレポートなど、ほとんどどこからでも来ることができます。生テキストを取り込み、読み取りや管理ができる形式にした後はデータベースに変換されます。ブレンドされたデータに対して分析処理を行う場合、データが構造化されていなければならないことから、データベースへの変換が必要なのです。

つまり、テキストを生のままにしておくと、有用な形でデータベースに収まらないのです。

出来上がったデータベースには、変換後に以下のような要素があります：

  • 発信元文書の特定
  • 分析対象文書内の気になる単語の位置
  • 気になる単語
  • 気になる単語の文脈

テキスト環境で見られるデータの種類の例として、ドキュメントIDは 「YELP Comment 506 on Jan 27, 2020 」のようになるかもしれません。バイトアドレスは 「byte 208」 かもしれないですし、単語は 「liked」で、文脈は 「positive sentiment"」 かもしれません。

生テキストをベースにした分析処理のみを行う場合、センチメント分析か相関分析のどちらかを行うといいでしょう：

テキストと生データの結合

最も強力な分析処理は、構造化環境とテキスト環境の両方からのデータの結合であり、このような分析を行うには、2つの環境からのデータ結合が必要です。

テキスト環境と構造化環境のデータの結合の例として、ある顧客が自動車について述べたコメントを考えてみましょう。ある日、顧客は「最近買ったシボレーには本当にがっかりした」と書いた。この顧客のコメントを購入記録と照合すると、その顧客は2007年にシボレー・カマロを新車で購入していることがわかります。これで、コメントを特定の自動車に添付することができます。

最も興味深く、分析に最も有用なデータは、異なる種類のデータが交差しているデータです。

2種類のデータは根本的に異なるため、データの交点は大抵見つかりにくいです。

一般的な識別子

2つの環境からデータをブレンドする最も簡単な方法は、テキストデータに識別子が関連付けられている場合です。多くのテキストデータでは、特定の識別子を見つけることができ、典型的な識別子には、社会保障番号、文書内のパスポート番号、従業員番号などがありますが、場合によっては、文書そのものが何らかの識別子を必要とすることもあります。

もし、実際にテキスト文書に識別子があれば、テキスト文書と構造化文書の照合はかなり簡単になります。

例えば、構造化環境における社会保障番号は、テキスト文書における同じ社会保障番号と照合されます。

なお、生テキスト文書の中には、構造化された要素を持つものもあり、その場合は、構造化データと非構造化データのマッチングがしやすくなります。

ただ、多くのテキスト文書には構造化要素も識別子もなく、その場合は、識別子以外のデータ型をブレンドするための他のタイプのデータを見つけるといいでしょう。

日付識別子

構造化データと非構造化データの両方から日付を見つけることも、ドキュメントをブレンドする簡単な方法の一つであり、どちらのタイプの文書にも、何らかの形で日付が入っているのが一般的です。

ただ、日付にはさまざまな種類があることに注意しましょう。 購入日、製造日、販売日、データ取得日などがあり、トランザクションが関係している場合は、大抵はトランザクションの日付を反映するものが最も有意義な日付のタイプです。

日付の照合で機械的に考慮すべきことは、テキストが取り得るさまざまな表現形式の照合です。あるケースでは、日付は「2021年3月13日」となり、別のケースでは、データは「2021/3/13」となる可能性があります。論理的には、これらは同じ日付ですが、物理的には全く異なります。

位置識別情報

異なるタイプのデータも、場所によって照合することができます。簡単な例として、テキサス州は、構造化文書とテキスト文書の両方のタイプの文書に含まれていることがあります。州名での照合ということでしょう。

機械的に考えると、州名は複数の形式を取ることができます。例えばあるケースでは、テキサス州は「Texas」と綴られるかもしれませんが、別の文書では、州は「TX」と略記されることがあり、さらに別の書式では、「Tex」と表示されることもあります。

名前識別情報

データは、名前そのものにブレンドすることもできます。この例では、「Jena Smith」という名前が、構造化環境のドキュメントとテキスト環境のドキュメントで見つかります。

しかし、一般に以下のような理由から、名前でのマッチングは最も弱いマッチングになります：

  • J Smith、Jena Smith、J H Smith など、一つの名前でも色々な書き方がある
  • 複数の同姓同名の可能性がある
  • Mr.やMissなどの敬称が人によって付いたり付かなかったりする

一般に、名前でのマッチングは、具体的なマッチングと考えるべきではありません。つまり、名前でマッチングした場合、その結果は常に疑わしいものなのです。

製品名の識別子

「”4x2テレビセット」と呼ばれる製品は、異なる環境間でマッチングさせることができます。

ただ、このマッチング手法には、同じ商品でも複数の場所で微妙に名称が異なるという問題点があります。

データマッチングの重要性

あまり知られていないかもしれませんが、構造化データとテキストのマッチングには大きな価値があり、その価値は、マッチング基準によって分析の方法が決定されるという事実のもとにあります。

例えば、場所によってマッチングされたデータに対して、商品分析を行うことはできません。このように、マッチングの基準によって分析が可能になるため、データのマッチング方法は重要です。

不完全なマッチング

どのようなデータ照合でも、対応できない文書がある可能性は常にあります。つまり、構造化された世界にはテキストの世界では何もマッチしない文書が存在することになり、逆に、テキストの世界には構造化データの世界ではマッチしない文書が存在することになります。

例えば、ある人が車を購入したけど、その車についての意見は何も言わなかったとします。この場合、車の購入に関する構造化された記録は存在しますが、その車自体に関するテキストの意見は存在しません。でもこういったミスマッチはよくあることで、心配する必要はありません。データソースは決して緊密に連携するようにはデザインされていないので、すべてのデータが一致するわけではないのは当然のことなのです。

レストランの事例

レストランでの例を出しましょう。ある日、あるレストランチェーンが、何号店が好調なのかを調べることにしました。データアナリストはあるアイデアを思いつき、顧客から受け取った食事体験に関するレビューを見ることにしました。

分析者はテキストを集め、シンプルな方法で仕分けます。ポジティブなコメント、中立的なコメント、ネガティブなコメントがありますね。

アナリストはネガティブコメントを取り、どの店舗に最も多くのネガティブコメントが寄せられているかに基づいて整理します。

以下のような結果が出ました：

12号店が最もネガティブなコメントが多く、その直後に2号店が続き、3番目に7号店といった具合です。

この結果を見た経営陣は、まず12号店、2号店、7号店の管理職をクビにしようと考えます。

否定的なコメントが多い店は、何かしら問題があるに違いないという論理ですね。

しかし、アナリストはその結果を見て、テキストだけから来るデータは少しズレがあるかもしれないと判断し、構造化されたデータを分析に取り入れることを提案します。

アナリストは、店舗の規模や平均顧客数を考慮した新しい分析を作成します。この分析が終わると比率が作成され、この比率は、その店舗の月間総売上高に対するネガティブクレームの数を計算します。

この分析では、まったく異なる結果が得られました。例えば、クレーム件数1位の店舗を見ると、ニューヨーク州マンハッタンにある店舗です。これでは、マンハッタンは経営がうまくいっていない店舗だと思われても仕方ないでしょう。しかし、マンハッタン店とニューメキシコ州のギャラップ店の客数を比べてみると、マンハッタンの1日5,000人に対して、ギャラップは1日に35人と、話にならないのです。マンハッタン店は、ギャラップ店よりはるかに多い客数であることから、単純にクレームが多いのです。

構造化データを持ち込み、構造化データとテキストデータを組み合わせることで、何号店が最も管理が行き届いていないのか、より現実的な視点での分析が可能になります。

クレームの件数に客数を加味すると、最も経営状態の悪い店舗はニューメキシコ州ギャラップ、ミシシッピ州ジャクソン、テキサス州バンホーンであることが浮かび上がってきます。


この測定値は、経営不振の店舗をはるかに正確に、そして現実的に表しています。

ちなみに、構造化データを織り込むには、さまざまな方法があったはずです。毎日の総金額を使用することも可能でした。毎日提供された食事の総数が使えたかもしれないし、毎日の総客数を使うこともできたでしょう。

これは、構造化データとテキストデータを併用することで、正確なイメージが実現された良例です。

コロナの影響

テキストデータと構造化データの融合の必要性を示す別の例として、ある州における新型コロナウィルスによる死亡の報告数を考えてみましょう。分析者は病院の報告書を調べ、病院がコロナ関連の死亡を一定数報告していることがわかりました。このレポートを統合し、米国におけるコロナによる死亡件数を分析することができます。

このような数字は、さまざまな報告書や情報源から集められたものです。経営陣が報告書を調べると、全国のコロナ死亡者数の合計が興味深い数字であることがわかりますが、その情報だけでは不十分です。

経営陣は、さらに掘り下げることに決めましたが、全国のコロナ死亡者数が載っているレポートには、州ごとの詳細な情報はありません。

すると分析者は、構造化されたシステムに格納されている個々の状態のレポートにアクセスすることに決めました。

テキスト環境のデータと構造化環境のデータを組み合わせることで、より包括的な分析ができます。

Integrate.ioとの提携

Integrate.ioは、高速な CDC、リバース ETL、高度な eコマース機能を備えた新しいETLプラットフォームで、あらゆる面で優れています。詳細については、ぜひお問い合わせください。