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 的用例，无论是出于自动化目的，通过数据执行“增强”分析，还是仅仅解决重复出现的问题（痛点）。