DataLakesとDataWarehouses：SEOでの使用方法

DataWarehousesとDataLakesの概念は、かなり前にデータアナリストとデータサイエンティストの日常の言葉の一部になりましたが、過去数年間、他の業界でしか聞いていません。
たとえば、WebアナリストとSEOエキスパートは、仕事の性質と、彼らの仕事とデータ操作の間に存在する強いつながりのために、これらの概念を真剣に検討し始めています。 最近の多くの記事では、SEODataLakeまたはSEODataWarehouseを実装することの関心について説明しており、2つの用語を交換可能として扱い、2つを区別していません。

この記事では、DataLakesとDataWarehousesの目的と、SEOおよびWeb分析でのユースケースを理解するために、DataLakesとDataWarehousesの違いを判断する方法について説明します。

DataWarehouse：データ用の構造化された倉庫

「データウェアハウス」という用語の最初の使用は、ビジネスおよび情報システムのアーキテクチャであるPaulMurphyとBarryDelvinによる論文で1988年にさかのぼります。 この記事では、アクセスしやすいリレーショナルデータベース環境としての概念の最初の定義を示し、戦略的な意思決定に役立つすべてのビジネスデータをまとめます。

DataWarehouseには何が含まれていますか？

DataWarehouseは、企業の戦略的意思決定に役立つビジネスデータを1か所に収集するために使用されます。 私たちは、顧客データから在庫情報、商用Webサイトでのコンバージョン、またはオーガニック訪問（たとえば、Googleなどの検索エンジンから）まで、あらゆるものをカバーできるビジネスデータについて話しています。

DataWarehouseに送信されるデータは、運用データベースのオフロードに使用される構造化された前処理されたデータであることが一般的に認められています。
データウェアハウスとそれを管理する人々の主な目標は、さまざまなソースが相互に通信できるようにデータを標準化するために、さまざまな異種ソース（内部と外部の両方）からのデータをコンパイルすることです。 最終的な目標は、このデータを使用して、分析、レポート、意思決定のサポートなどを実行することです。

DataWarehouseの毎日のユーザーは誰ですか？

データウェアハウスの性質とそれに含まれるデータの形式とタイプのため、データウェアハウスはデータおよびWebアナリストにとって理想的な遊び場です。
データアナリストは、DataWarehouse管理者（または管理チーム）と協力して機能します。 それらはビジネスニーズとユースケースを定義します。 これらは、データソースとデータをアップストリームで処理するために必要なアクションを識別します。 これらのデータは、チェーンの最後にあるデータアナリストによって使用されます。

ユーザーはどのようにデータウェアハウスと通信しますか？

データソースが特定され、データウェアハウスでデータが処理、取り込み、リンクされると、データアナリストはこのデータを分析に使用し、新しいデータの組み合わせを作成できます。 このプロセスは、レポートダッシュボード、アラートダッシュボードなどを維持するために使用できます。

DataWarehouseでクエリを実行するために最も一般的に使用されるプログラミング言語は、SQL（またはSQLに似た言語）です。 SQLを使用すると、データアナリストは、監視、戦略的意思決定などのビジネスニーズを満たすために、データを操作および処理できます。

DataWarehousesはどのようなユースケースとプロジェクトタイプを提供しますか？

DataWarehouseの使用を含むユースケースの完全なリストを作成することは不可能です。 ただし、データアナリストが取り組む可能性のあるプロジェクトの例を次に示します。

データウェアハウスの改善：
このタイプのプロジェクトは、DataWarehouseをセットアップするときによく発生しますが、新しいニーズやビジネスのユースケースが特定されたときにも発生します。
ここで、DWHに新しいデータを追加することが問題になります（これも内部データでも外部データでもかまいません）。
この場合、ETL（Extraction-Transformation-Loading）プロセスについてよく話します。

• 抽出：
  さらなる操作に必要なさまざまなソースからデータを識別して収集することからなる最初のステップ。
• 変身：
  この2番目のステップは非常に重要です。調整なし、標準化なしでは、新しいデータを使用して、DWHにすでに存在するデータと通信させることは一般に不可能だからです。
  したがって、これは必要な標準化のフェーズであり、フォーマットとテーブルスキーマの観点からDWHによって課せられる厳格さによって複雑になる場合があります。
• 読み込み中：
  DWHで処理された（したがって構造化された）データの取り込みのフェーズ。

統計分析の実現：
これは、DWHの非常に頻繁な使用です。 目標は、データを通じてXまたはYを証明すること、利用可能な履歴データに基づいて統計を生成すること、または結果を説明するための因果関係を確立することなどです。
レポートとアラート：
これもまた、非常に頻繁な使用例です。 実際、DWHのデータは高度に構造化およびフォーマットされているため（固定および事前定義されたスキーマを共有）、データをレポートまたはアラートダッシュボードにプッシュするのにすべて適しています。

これはトップマネジメントからの繰り返しのリクエストであり、経営陣と結果、売上などの健全性を可能な限り簡単かつ迅速に監視できる必要があります。

これらすべてを要約すると、多かれ少なかれ2つのタイプのプロジェクトがあります。データの取得と統合のプロジェクト（データの保存と履歴の形式と比較することもできます）とデータの分析と評価のプロジェクト（監視/ダッシュボードとアラートによる）です。 ）。

DWHの概念は、データを扱う人々の日常の言葉で長い間存在してきました。 それがどのように機能するか、そしてその多くのユースケースは長い間確認されており、DWHは、データ管理の問題が関係するさまざまな成熟度の多くの企業で見つけることができます。

これは、はるかに若く、あまり普及していないDataLakesの概念には当てはまりません。

オンクロールデータ³

追加のデータセットへのシームレスな接続で分析を拡張します。 バックリンク、SEOトラフィック、ランキング、およびCRM、監視ソリューション、またはその他のソースからのカスタムデータセットに関するデータに基づいて、SEO戦略を分析します。

もっと詳しく知る

DataLake：メガデータの湖（BigData）

この概念の起源は、PenthaoのCTOであるJames Dixonにあります。彼は、前処理や特定のユースケースを必要とせずに、大量のデータを保存および活用するためのソリューションとして定義しています。即時アクティベーションに向けて。
DLは、ビッグデータの出現によりますます重要になる、今日収集できるこの大量のデータをどのように処理し、それをどのように活用するかというギャップを埋めようとします。

DataLakeには何が含まれていますか？

まず、非常に刺激的な比較を使用するJames Dixonを引用します。これは、彼のコンセプトの「湖」の名前の説明と、DWHとの差別化の両方の役割を果たします。

「データマートを、簡単に消費できるように洗浄、パッケージ化、構造化されたボトル入り飲料水の貯蔵庫と考えると、データレイクはより自然な状態の大きな水域です。 データレイクのコンテンツは、ソースから湖を埋めるために流れ込み、湖のさまざまなユーザーが調べたり、飛び込んだり、サンプルを採取したりすることができます。」

この引用は、正確で固定されたパターンを持つテーブルに構造化および編成されたDWHに含まれるデータのタイプと、事前処理なしで未加工で取得可能なDataLakeに含まれるデータのタイプとの違いを完全に示しています。探索的かどうかにかかわらず、必要に応じてからのサンプル。

DWHが構造化データに対応するように制限されている場合、DataLakeはすべての種類の生データ（構造化されているかどうかに関係なく）を格納するように作成されています。 Tamara Dull（Amazon Web Service）とAnne Buff（Microsoft SAS）の間の議論により、DataLakeのコンテンツについてもう少し具体的なビジョンが得られます。

「データレイクは、構造化データ、半構造化データ、非構造化データなど、ネイティブ形式の大量の生データを保持するストレージリポジトリです。 データが必要になるまで、データ構造と要件は定義されません。」

DataLakesの毎日のユーザーは誰ですか？

データアナリストがDHWに含まれる構造化データを処理するのに完全に適していた場合、生データは代わりにデータサイエンティストの専門であり、多くの場合、このタイプのデータを操作するための設備が整っています。
このデータプロファイルとメインユーザーの変更により、プログラミング言語とユースケースも異なります。

DataLakesはどのようなユースケースとプロジェクトタイプを提供しますか？

構造化されていない性質とDataLakeに含めることができる大量のデータのために、ユースケースはDWHフレームワークで以前に見られたものとは大きく異なる可能性があります。

• BigDataの付加価値を生み出すための機械学習アルゴリズムの実装：
  ここでは、あらゆる種類のデータを活用する機械学習アルゴリズムに基づく予測分析についてよく話します。
  より具体的な例として、金融セクター（銀行および保険）の企業が、金融取引Xが不正である確率を判断したいとします。 これには、DataLakeに含まれる天文学的な量のデータ（量、日付、頻度、アカウント所有者によって実行されるトランザクションの通常のプロファイルなど）をトレーニングする機械学習アルゴリズムを作成できるデータサイエンティストが必要になる場合があります。 目標は、潜在的に不正な取引を特定するために使用される予測調査を実施することです。これにより、企業はそれらを検出する際の反応時間を短縮し、最終的には彼らとその顧客の大きな損失を回避できます。
  これは、機械学習の興味と付加価値を説明するために定期的に使用される簡単な例ですが、想像できるように他にもたくさんあります。
• DataWarehouseのデータソースとしてのDataLakes：
  非常に簡単に言えば、DataLakeは、さまざまな内部および外部データソースとDWHの間のトランジットゾーンとして機能できます。 DataLakeの基本は、構造化または非構造化を問わず、あらゆる種類のデータを一元化して、MLを介して予測研究を実行したり、分析用のサンプルとして抽出したりすることです。 したがって、DWHはこの2番目のカテゴリのプロジェクトに非常に適しているようであり、潜在的なソースとしてDataLakeの恩恵を受けます（DataLakeデータが必要に応じて前処理を介して構造化された方法でインポートされる場合）。
• DataLakeからBI（ビジネスインテリジェンス）ソフトウェアへ：
  これは、DataWarehousesで見たのと同様の使用法であると見なすことができます。この目的で、DataLakeを使用することには特定の特殊性があると考えられます。 DataLakeを使用すると、Tableau、Qlikview、Google Data Studio、Microstrategyなどのツールを使用して、（含まれるデータの多様性のために）少しエキゾチックな視覚化を行うことができます。

ユーザーはどのようにDataLakeと通信しますか？

ユースケースとユーザー（データサイエンティスト）を考えると、Python、Java、R、Scalaなどのプログラミング言語を見つけることがよくあります…
ほとんどの場合、これらの言語はデータサイエンスの分野で長い間存在してきました。

したがって、DataLakeはビッグデータを管理するためのツールです。 高度な分析と視覚化の目的で生データの大規模なストレージに依存しているため、これまであまり使用されていなかったデータの拡張が可能になります。

要約すると、この記事の冒頭から確立された差別化要素の表を次に示します。

予測分析、機械学習、データソースとDWH間のトランジットゾーン、高度な視覚化– BI、データ駆動型分析

これらの2つの概念を補完的なツールにするのは、これらの違いです。 多くの場合、企業のガバナンスとデータ管理の成熟度によっては、これら2つのツールの組み合わせに依存する場合があります。
DWHは主に従来のレポートと分析に使用されますが、DataLakeは、会社がデータ主体の成熟に近づくにつれて、その潜在能力を最大限に発揮する前にデータソースとして機能します。

私の意見では、DataLakesは、21世紀の新しいデータの問題への対応であり、特にBigDataの出現と、データを収集する企業の能力の向上により、一部の人が考えるように、DWHに代わるものではありません。
どちらにも長所、短所、長所と短所があります。 両方を最大限に活用するための最良の方法は、不測の事態に対処し、さまざまなニーズに対応できるように、両方を一緒に使用することです。

概念を明確に定義したので、最終的に、マーケティング、より具体的にはSEOのためのDataWarehousesとDataLakesの使用に焦点を当てます（多くの場合、前者に当てはまることが後者にも当てはまります。逆）。

DataWarehouseとDataLakeSEO

ここでは、存在するデータの少なくとも一部をSEOのユースケースに使用できるDataWarehouseまたはDataLake（あるいはその両方）について説明します。

なぜDataLakesとDataWarehousesをマーケティングとSEOに関連付けるのですか？

SEO（そしてより一般的にはマーケティング）は、近年すでにデータに向けて非常に目覚ましい変化を遂げています。 ますます多くのタスクで、さまざまなデータソースを使用する必要があります。

• 分析データ（Google Analytics、ATインターネットなど）
• パフォーマンスデータ（Google Search Console、Analytics）
• ログデータ。一部のサイトでは非常に大きなデータの「ソース」であり、高い更新頻度と大きなストレージ容量が必要です。
• ネットリンクデータ（Majestic、Ahrefs、Babbar）
• ポジショニングデータ（SEMRush、Monitorankなど）
• クロールデータ（OnCrawlなど）
• 時にはビジネス/業界データも

このリストに、検索コンソール、Majestic、Google AnalyticsなどのツールのAPIの使用も追加する必要があります。これにより、この記事で前述した種類のソリューションに自然に移行できます。
SEOとデータの間のこの強力なつながりが、ますます多くのWebアナリストとSEOエキスパートに、データパイプラインを整理するための新しい方法について学ぶように促しています。

ただし、この移行の推進要因は、SEOとデータの可能性と相互接続性だけではありません。 多くの日常的なユースケースは、DWHおよびDLについて上記にリストされたプロジェクトタイプと共鳴します。

SEODataWarehouseまたはSEODataLakeのユースケース。

まず、SEOエキスパートが一般的に遭遇する問題点から始めてから、DataLakeまたはDataWarehouseの使用がそれらに対処する際に考慮すべき答えである方法を説明します。
主な問題点の中で、次の点が際立っています。

• Excelファイル（私たちの10年のルーズリーフ紙）の乗算と関連するコピーアンドペースト：
  多くのSEOにとって、これは依然として標準ですが、正直に言うと、時間がかかり、制約があり、人為的エラーを非常に助長します。このため、DataWarehouseは完璧なソリューションです。 データウェアハウスでは、これを実行するために必要なすべてのKPI、または利用可能なさまざまなデータソースから監査/分析を収集できるだけでなく、期待される結果を達成するために必要な処理を自動化できます。
  データウェアハウスが構築されるにつれて、ますます多くのユースケースが特定され、ますます多くの問題が解決され、時間の経過とともにますます大幅な時間の節約につながります。
• 容量の制限（Excelは、1,048,576行を超えない場合にのみファイル全体を開くことができます。これは多くのように見えますが、実際には今日のボリュームではそれほど多くありません）：ここでは特に使用例はありません。一般に、DataLakesとDataWarehousesの両方がこの種の制限に悩まされることはありません。 どちらも、あらゆるタイプのニーズに対応するために大量のデータを要求する手段を提供します。 この特定のケースでは、必要に応じて、どちらか一方を使用すると容量制限から解放され、最終的にはこれらの状況に簡単に対処できることを覚えておくことが重要です。
• データの履歴化の必要性に対応する
  ネタバレ：使用例の1つは、たとえば、データスタジオダッシュボードを維持するために毎週Googleシートにデータをコピーしてページングするのではなく、SEOデータウェアハウスのGoogle検索コンソールからデータの履歴を保存することです。私の意見では、ここでは、代理店であろうと社内であろうと、SEOエキスパートの間で最も一般的な使用例の1つであるデータ履歴があります。 実際、多くのSEOアナリストは過去のデータを見て、そこから結論を導き出します。
  直接頭に浮かんだかもしれない例は、Google検索コンソールの場合です。 今日の16か月の履歴へのアクセスのみを提供します（API経由でも）。 また、エクスポートを介して手動のバックログを毎週Googleスプレッドシートに貼り付けることができる場合（または他のあいまいな方法）、面倒で退屈なだけでなく、かなりの時間の無駄になります。
  DataWarehouseで対処するのは比較的簡単な問題なので、これは良いことです。 Google Search Console APIへの自動接続を設定し、実際の付加価値のあるデータを取得するために必要なさまざまな前処理とデータの組み合わせを定義し、最後にAPI呼び出しを自動化するだけです。
• 分析をさらに進め、クロールデータ、オーディエンスデータ、ログなどを工業化された方法でマージまたは「相互分析」したいという要望。
  小さな競争上の優位性が損なわれることは決してないからです。ここでは、DataWarehouseとDataLakeについて説明しました。 両方のツールの主な目的の1つは、データ収集と相互分析、および/または機械学習を通じて、分析の新しい可能性を開くことです。
  非常に代表的な例を1つだけ引用します。 ランダムフォレストやXG-Boostなどの機械学習アルゴリズムを使用してGoogleでランキングを予測します。
  非常に簡単に言えば、アイデアは、多数のGoogle SERP（結果ページ）とこれらのSERPで収集可能なすべてのSEOメトリックでアルゴリズムをトレーニングし、それらの同じメトリックに基づいて、特定のURL（およびしたがって、さらに具体的には、特定のセクター/テーマでランク付けするための最も重要なメトリックを決定します）。
  →完全な方法論は、OncrawlのプロダクトディレクターであるVincent Terrasiによる記事、 「データサイエンスの最先端でのGoogleランキングの予測に成功」 、2018年にあります。
• 付加価値の高いタスクに集中するために、レポートを可能な限り自動化することを望んでいます。これも、文字通り、データウェアハウスの従来のユースケースに該当します。 さまざまなデータソースのリカバリと処理全体を自動化する可能性を提供し、この問題点に完全に対処します。 設定が完了すると、テーブルは自動的にDWHに送られ、監視やアラートなどのダッシュボード用のBIソフトウェアへの接続として使用できます。もちろん、自動化はプロジェクトのレポートだけにとどまりません。 DWHとDLの両方を、多くの自動SEO最適化に使用できます。 たとえば、ランク、クロールバジェット、SEOオーディエンスなど（DWHに含まれるすべてのデータ）での内部リンクブロックの動的更新。
• セキュリティ上の懸念（誰が何をどこで見つけたかを知っている）に終止符を打ち、メンテナンスに時間を費やさないようにしたいという願望。厳密に言えば、ユースケースよりもプロセス指向の側面で終わります。
  DataLakesとDataWarehousesはどちらも、次の簡略化された方法で提示できる特定のプロセスの実装を意味します。
  • 出発点は、ニーズのステートメント（ビジネスチーム/ SEO –データアナリスト）に分解された観察です。
  • 次に、これはより技術的な仕様に変換され、ツールを管理するチームが何を行う必要があり、どのように行う必要があるかを理解できるようになります。
  • この同じ管理チームがリクエストを実行します。
  • ビジネスチームとデータアナリストは、実行された作業の手順のユースケースを作成します。
  • チェーンの両端（DataWarehouseまたはDataLakeのビジネスチームと管理チーム）が入力と出力に関して何も変更されていないことを確認する進行中のプロセスがあります。
    これは特に、構造（事前定義されたスキーマ）の一部ではないデータを拒否するDWHの場合です。

繰り返しになりますが、これは、DataWarehouse –DataLakeSEOの問題点と考えられるユースケースの網羅的ではないリストです。 限界は、ツール自体よりも、それらを使用する人々の想像力の欠如によってより多く遭遇します。

SEOの用途にDataWarehouseまたはDataLakeを選択する

結論として、よく耳にすることや読むこととは異なり、DataWarehousesとDataLakesはデータの保存と収集のための別個の構造であり、互換性がありません。 まったく逆に、どちらかを選択する必要はありません。 どちらもユースケースが異なり、いくつかの癒着さえあります。

SEOの事例はその好例であり、一般的なデータウェアハウスとデータレイクの必要性を強調しています。 データはSEOに遍在しています。さまざまなソースからの膨大な量のデータを操作する必要があります。 したがって、このコンテキストでDataWarehousesとDataLakesについて話すのは当然のことです。 自動化の目的であれ、データを介した「拡張」分析の実行であれ、単に繰り返し発生する問題（問題点）の解決であれ、SEOにおけるDataWarehousesまたはDataLakesの多くのユースケースを想像できます。