DataLakes 和 DataWarehouses：如何在 SEO 中使用它們

儘管 DataWarehouses 和 DataLakes 的概念很久以前就成為數據分析師和數據科學家日常語言的一部分，但在過去的幾年裡，我們只是在其他行業中聽說過它們。
例如，網絡分析師和 SEO 專家開始認真看待這些概念，因為他們的工作性質以及他們所做的事情與數據操作之間存在的緊密聯繫。 最近的許多文章都談到了實施 SEO DataLake 或 SEO DataWarehouse 的興趣，將這兩個術語視為可互換的，並且不區分兩者。

在本文中，我們將指導您確定 DataLakes 和 DataWarehouses 之間的差異，以了解它們在 SEO 和 Web 分析中的用途和用例。

DataWarehouse：數據的結構化倉庫

“DataWarehouse”一詞的第一次使用可以追溯到 1988 年 Paul Murphy 和 Barry Delvin 的論文《商業和信息系統的架構》 。 本文首次將這一概念定義為易於訪問的關係數據庫環境，匯集了對戰略決策有用的所有業務數據。

數據倉庫包含什麼？

數據倉庫用於在一個地方收集對公司戰略決策有用的業務數據。 我們談論的業務數據可以涵蓋從客戶數據到庫存信息，再到商業網站上的轉換或自然訪問（例如來自 Google 等搜索引擎）的任何內容。

人們普遍認為，發送到 DataWarehouse 的數據是結構化的、預處理的數據，用於卸載操作數據庫，這最終允許盡可能少地請求這些操作數據庫以用於查詢目的。
DataWarehouse 和管理它的人的主要目標是編譯來自各種異構來源（內部和外部）的數據，以便對其進行標準化，以便各種來源可以相互通信。 最終目標是使用這些數據進行分析、報告、決策支持等。

誰是 DataWarehouse 的日常用戶？

由於 DataWarehouse 的性質及其包含的數據格式和類型，它是數據和 Web 分析師的理想場所。
數據分析師與數據倉庫管理員（或管理團隊）一起工作。 它們定義了業務需求和用例。 他們確定數據源和上游處理數據所需的操作。 然後，這些數據將由鏈末端的數據分析師使用。

用戶如何與 DataWarehouse 進行通信？

一旦確定了數據源，並且在 DataWarehouse 中處理、攝取和鏈接了數據，數據分析師就可以在分析中使用這些數據並創建新的數據組合。 此過程可用於維護報告儀表板、警報儀表板等。

在 DataWarehouse 中查詢最常用的編程語言是 SQL（或類似 SQL 的語言）。 SQL 允許數據分析師操作和處理數據以滿足業務需求：監控、戰略決策等。

DataWarehouse 服務於哪些用例和項目類型？

不可能列出涉及使用數據倉庫的用例的詳盡列表。 但是，以下是數據分析師可能從事的一些項目示例：

數據倉庫的改進：
在設置 DataWarehouse 時經常會遇到這種類型的項目，而且在確定新的需求或業務用例時也會遇到這種情況。
這裡的問題是向 DWH 添加新數據（同樣，這可以是內部數據或外部數據）。
在這種情況下，我們經常談到一個 ETL（Extraction-Transformation-Loading）過程：

• 萃取：
  第一步包括從進一步操作所需的各種來源中識別和收集數據。
• 轉型：
  這第二步非常重要，因為沒有調整，沒有標準化，通常不可能使用新數據並使它們與 DWH 中已經存在的數據進行通信。
  因此，這是一個必要的標準化階段，有時會因 DWH 在格式和表模式方面的僵化而變得複雜。
• 加載：
  在 DWH 中處理（並因此結構化）數據的攝取階段。

統計分析的實現：
這是 DWH 的一個非常頻繁的使用。 目標可能是通過數據證明 X 或 Y，根據可用的歷史數據生成統計數據，或建立因果關係來解釋發現等。
報告和警報：
這又是一個非常常見的用例。 事實上，由於 DWH 中的數據是高度結構化和格式化的（共享一個固定和預定​​義的模式），它都適合將數據推送到報告或警報儀表板。

這是高層管理人員反复提出的要求，他們需要能夠以最簡單和最快的方式監控運營團隊以及結果、銷售等的健康狀況。

如果我們總結所有這些，我們或多或少有兩種類型的項目：數據採集和集成項目（也可以類比為數據存儲和歷史化的一種形式）和數據分析和評估項目（通過監控/儀表板和警報）。

DWH 的概念已經存在於那些長期使用數據的人的日常語言中。 它的工作原理及其眾多用例早已得到證實，並且在涉及數據管理問題的許多不同成熟度的公司中都可以找到 DWH。

DataLakes 的概念就不是這樣了，它更年輕，也更不普及。

抓取數據³

通過與其他數據集的無縫連接來擴展您的分析。 根據來自您的 CRM、監控解決方案或任何其他來源的反向鏈接、SEO 流量、排名和自定義數據集的數據分析您的 SEO 策略。

學到更多

DataLake：大數據湖（BigData）

這個概念的起源歸功於 Penthao 的首席技術官 James Dixon，他將其定義為一種存儲和利用大量數據的解決方案，無需預處理，也無需特定的用例……與 DWH 不同，後者非常面向朝向立即激活。
DL 試圖填補隨著大數據的出現而變得越來越重要的空白，即如何處理我們今天能夠收集的所有這些大量數據以及如何利用它。

DataLake 包含什麼？

我將首先引用 James Dixon 的話，他使用了一個非常令人回味的比較，既可以解釋他的概念的“湖”名稱，也可以作為與 DWH 的區別：

“如果您將數據集市視為瓶裝水的商店——經過清潔、包裝和結構化以便於飲用——那麼數據湖就是處於更自然狀態的一大片水體。 數據湖的內容從源頭湧入填滿湖，湖的各種用戶可以來檢查、潛入或取樣。”

這句話完美地說明了 DWH 中包含的數據類型和 DataLake 中包含的數據類型之間的區別根據需要從樣本中提取，無論是否是探索性的。

在 DWH 被限制為容納結構化數據的情況下，DataLake 用於存儲各種原始數據（結構化或非結構化數據）。 Tamara Dull（亞馬遜網絡服務）和 Anne Buff（微軟 SAS）之間的辯論讓我們對 DataLake 的內容有了更具體的看法：

“數據湖是一個存儲庫，以原生格式保存大量原始數據，包括結構化、半結構化和非結構化數據。 直到需要數據時才定義數據結構和要求。”

DataLakes 的日常用戶有哪些？

數據分析師非常適合處理 DHW 中包含的結構化數據，而原始數據則是數據科學家的專長，他們通常更有能力處理此類數據。
數據配置文件和主要用戶的這種變化也導致了不同的編程語言和用例。

DataLakes 服務於哪些用例和項目類型？

由於它的非結構化性質和 DataLake 可以包含的大量數據，用例可能與以前在 DWH 框架中發現的用例非常不同，例如：

• 機器學習算法的實施為大數據創造附加值：
  我們經常在這裡談論基於利用各種數據的機器學習算法的預測分析。
  舉一個更具​​體的例子，讓我們假設一家金融部門（銀行和保險）的公司想要確定金融交易 X 是欺詐的概率。 這可能需要數據科學家來創建機器學習算法，這些算法將訓練 DataLake 中包含的大量數據（數量、日期、頻率、賬戶所有者進行的交易的通常概況等）。 目標是進行一項預測研究，用於識別潛在的欺詐交易，從而使公司能夠減少檢測它們的反應時間，並最終避免給他們和他們的客戶帶來巨大損失。
  這是一個簡單的例子，經常被用來說明機器學習的興趣和附加價值，但還有很多其他的例子，正如你想像的那樣。
• DataLakes 作為 DataWarehouse 的數據源：
  很簡單，DataLake 可以充當各種內部和外部數據源與 DWH 之間的中轉區。 DataLake 的基本原理是集中所有類型的結構化或非結構化數據，以便通過 ML 進行預測研究，或提取為樣本進行分析。 因此，DWH 似乎非常適合第二類項目，並受益於作為潛在來源的 DataLake（前提是如果需要，DataLake 數據是通過預處理以結構化方式導入的）。
• 從 DataLake 到 BI（商業智能）軟件：
  我們可以將其視為類似於我們在 DataWarehouses 中看到的用途，認為為此目的使用 DataLake 有某些特殊性。 DataLake 將允許您通過 Tableau、Qlikview、Google Data Studio、Microstrategy 等工具進行更奇特的可視化（由於它包含的數據種類繁多）。

用戶如何與 DataLake 通信？

鑑於用例和用戶（數據科學家），我們經常會發現 Python、Java、R、Scala 等編程語言……
在大多數情況下，這些語言在數據科學領域已經存在了很長時間。

因此，DataLake 是管理大數據的工具。 它依賴於原始數據的海量存儲來進行高級分析和可視化，從而可以增強以前沒有大量使用的數據。

總而言之，這裡是自本文開始以來建立的差異化元素的表格：

預測分析、機器學習、數據源和 DWH 之間的中轉區、高級可視化 - BI、數據驅動分析

正是這些差異使這兩個概念成為互補的工具。 在許多情況下，根據公司治理和數據管理的成熟度，他們可能依賴於這兩種工具的組合。
DWH 主要用於傳統的報告和分析，而 DataLake 在公司接近數據主體成熟度時發揮其全部潛力之前充當數據源。

在我看來，DataLakes 更像是對 21 世紀新的數據問題的回應，特別是隨著大數據的出現和公司收集數據的能力的增加，而不是像某些人想像的那樣替代 DWH。
兩者都有其優點，缺點，優點和缺點。 充分利用兩者的最佳方法仍然是同時使用兩者，以便能夠應對任何可能發生的情況並滿足更廣泛的需求。

現在我們已經明確定義了這些概念，我們最終將專注於使用 DataWarehouses 和 DataLakes 進行營銷，更具體地說是 SEO（即使在許多情況下，前者的正確性將適用於後者，反之亦然反之亦然）。

數據倉庫和數據湖 SEO

我們將在這裡討論 DataWarehouse 或 DataLake（或兩者），其中至少部分數據可用於 SEO 用例。

為什麼將 DataLakes 和 DataWarehouses 與營銷和 SEO 相關聯？

近年來，搜索引擎優化（以及更普遍的營銷）已經非常明顯地轉向數據。 越來越多的任務需要使用各種數據源：

• 分析數據（Google Analytics、AT internet 等）
• 性能數據（谷歌搜索控制台、分析）
• 日誌數據，對於一些站點來說是一個非常大的數據“源”，需要更新頻率高，存儲容量大。
• 網絡鏈接數據（Majestic、Ahrefs、Babbar）
• 定位數據（SEMRush、Monitorank 等）
• 爬取數據（OnCrawl 等）
• 有時還有商業/行業數據

在這個列表中，我們還應該添加對諸如 Search Console、Majestic、Google Analytics 等工具的 API 的使用，這自然將我們推向本文前面描述的那種解決方案。
正是 SEO 和數據之間的這種緊密聯繫促使越來越多的網絡分析師和 SEO 專家了解組織數據管道的新方法。

然而，這種轉變的驅動力不僅與 SEO 和數據的潛力和相互聯繫有關。 許多日常用例與上面列出的 DWH 和 DL 項目類型產生了共鳴。

SEO DataWarehouse 或 SEO DataLake 的用例。

我將首先從 SEO 專家經常遇到的痛點開始，然後解釋如何使用 DataLake 或 DataWarehouse 來解決這些痛點。
在主要痛點中，以下突出：

• Excel 文件的倍增（我們十年的活頁紙）和相關的複制和粘貼：
  對於許多 SEO 來說，這仍然是常態，但老實說，這既費時又受限制，而且非常容易導致人為錯誤。為此，DataWarehouse 是一個完美的解決方案。 數據倉庫不僅允許從各種可用數據源收集執行此或那個審計/分析所需的所有 KPI，而且還允許實現預期結果所需的處理自動化。
  隨著數據倉庫的建立，越來越多的用例被識別，越來越多的問題得到解決，隨著時間的推移，節省的時間越來越多。
• 容量限制（提醒一下，Excel 只能在不超過 1,048,576 行的情況下打開整個文件。這似乎很多，但在今天的捲中實際上並沒有那麼多）：這裡沒有任何特定的用例，因為在一般來說，DataLakes 和 DataWarehouses 都不會受到這種限制。 它們都提供了為任何類型的需求請求大量數據的方法。 對於這種特定情況，重要的是要記住，根據需要，其中一個可以讓您擺脫容量限制，並最終更輕鬆地解決這些情況。
• 響應數據歷史化需求
  劇透：其中一個用例可以是，例如，將來自 Google Search Console 的數據歷史記錄保存在 SEO DataWarehouse 中，而不是每週在 Google Sheets 中復制和分頁數據以維護 Data Studio 儀表板。我認為，無論是在代理機構還是在內部，我們在這裡都有 SEO 專家中最常見的用例之一：數據歷史化。 事實上，許多 SEO 分析師查看歷史數據並從中得出結論。
  您可能直接想到的例子就是 Google Search Console 的例子。 它僅提供對今天 16 個月曆史的訪問（甚至通過 API）。 而且，如果手動積壓仍然可以通過導出每週粘貼到 Google 表格（或其他晦澀的方法），那麼除了痛苦和無聊之外，這也是一種相當大的時間浪費。
  這是一件好事，因為使用 DataWarehouse 解決它是一個相對簡單的問題。 您所要做的就是設置與 Google Search Console API 的自動連接，定義各種可能的預處理和數據組合，以獲取具有真正附加值的數據，最後，自動化 API 調用。
• 希望進一步分析，以工業化的方式合併或“交叉分析”爬網數據、受眾數據、日誌等。
  因為小的競爭優勢永遠不會受到傷害。我們對 DataWarehouse 和 DataLake 的描述在這裡不言自明。 這兩種工具的主要目標之一是通過數據收集和交叉分析和/或機器學習為分析開闢新的可能性。
  僅舉一個非常有代表性的例子； 使用隨機森林或 XG-Boost 等機器學習算法在 Google 上進行排名預測。
  很簡單，這個想法是在大量谷歌 SERP（結果頁面）和所有可用於這些 SERP 的 SEO 指標上訓練算法，以便根據這些相同的指標確定給定 URL 的排名潛力（以及因此，更具體地說，確定在特定部門/主題中排名的最重要指標）。
  → 您將在 Oncrawl 產品總監 Vincent Terrasi 的文章中找到完整的方法， “在數據科學的前沿成功預測 Google 排名” ，2018 年。
• 希望盡可能多地自動化報告，以便專注於高附加值的任務。同樣，這實際上屬於數據倉庫的經典用例。 它提供了自動化各種數據源的整個恢復和處理的可能性，並且完美地解決了這個痛點。 設置完成後，表格將自動輸入 DWH，並可用作與 BI 軟件的連接，用於儀表板、監控、警報等。當然，自動化並不僅僅停留在報告項目上。 DWH 和 DL 都可用於許多自動 SEO 優化。 例如，動態更新內部鏈接塊的排名、抓取預算、SEO 受眾等（DWH 中包含的所有數據）。
• 希望一勞永逸地結束安全問題（我們知道誰做了什麼以及在哪裡找到它們）並避免花費時間進行維護。嚴格來說，我們在比用例更面向過程的方面結束。
  DataLakes 和 DataWarehouses 都意味著特定流程的實現，可以通過以下簡化方式呈現：
  • 起點是分解為需求陳述的觀察（業務團隊/ SEO - 數據分析師）。
  • 然後，將其轉化為技術性更強的規範，使管理該工具的團隊能夠了解需要做什麼以及需要如何完成。
  • 同一管理團隊執行該請求。
  • 業務團隊和數據分析師為所執行的工作生成一個程序用例。
  • 有一個持續的過程，其中鏈的兩端（DataWarehouse 或 DataLake 的業務團隊和管理團隊）確保在輸入和輸出方面沒有任何變化。
    對於 DWH 尤其如此，它將拒絕任何不屬於結構（預定義模式）的數據。

同樣，這是 DataWarehouse – DataLake SEO 的痛點和可能用例的非詳盡列表。 限制更多是因為使用它們的人缺乏想像力，而不是工具本身。

為您的 SEO 使用選擇 DataWarehouse 或 DataLake

總而言之，與您可能經常聽到或讀到的相反，DataWarehouses 和 DataLakes 是用於數據存儲和收集的獨立結構，並且並非不兼容。 沒有必要二選一，恰恰相反。 兩者都有不同的用例，甚至有一些粘連。

SEO 的案例就是一個很好的例子，它總體上強化了對 DataWarehouses 和 DataLakes 的需求。 數據在 SEO 中無處不在：我們必須處理來自不同來源的大量數據。 因此，我們在這種情況下談論 DataWarehouses 和 DataLakes 也就不足為奇了。 我們可以想像 SEO 中有很多 DataWarehouses 或 DataLakes 的用例，無論是出於自動化目的，通過數據執行“增強”分析，還是僅僅解決重複出現的問題（痛點）。