【数据架构】新兴数据基础架构的现代架构

自2020年底以来，数据基础设施行业的增长有增无减。

在过去一年中，几乎所有关键行业指标都创下了历史新高，新的产品类别出现的速度超过了大多数数据团队可以合理跟踪的速度。
甚至基准战争和广告牌大战也卷土重来。

为了帮助数据团队掌握行业中发生的变化，它们显示了分析和运营系统中当前同类最佳的堆栈，这是从去年与我们交谈的众多运营商收集的。每个架构蓝图都包含自上一版本以来发生的更改的摘要。
我们还将试图解释为什么这些变化需要时间。

我们认为，核心数据处理系统在过去一年中保持相对稳定，而支持工具和应用程序迅速增加。
我们探索了这样一种假设，即平台开始出现在数据生态系统中，这有助于解释我们在数据堆栈演化中看到的特定模式。

为了编辑这项工作，我们再次依赖于几十名数据专家的输入，他们在本文末尾列出。没有他们，这根本不可能存在
在我们深入了解细节之前，下面是最新的架构图。
这些是在领先的数据从业者的帮助下编译的，基于他们在内部运行的内容以及他们对新部署的建议。
第一个视图显示了所有数据基础架构用例的统一概述：

Changelog（更改日志）

未更改的内容：

核心稳定性

尽管在过去一年里数据基础架构活动非常活跃，但令人惊讶的是，在某些方面，几乎没有什么变化。
在我们的第一步中，我们区分了支持数据驱动决策的分析系统和支持数据驱动产品的运营系统。
然后，我们将这些类别映射到三个模式或蓝图，通常由领先的数据团队实现。

其中一个关键问题是这些架构模式是否会趋同。一年后，这似乎并没有发生。
特别是，分析和业务生态系统都继续蓬勃发展。Snowflake等云数据仓库发展迅速，主要专注于SQL用户和商业智能用例。但其他技术的采用也加速了——例如，Databricks之类的数据湖正在以前所未有的速度增加客户。与我们交谈的许多数据团队都确认，异构性可能会留在数据堆栈中。

其他核心数据系统——即摄取和转换——也被证明具有类似的持久性。

这在现代商业智能模式中尤其明显，其中Fivetran和dbt（或类似技术）的组合几乎无处不在。但在某种程度上，在运营系统中也是如此，出现了Databricks/Spark、Confluent/Kafka和Astronomer/Airflow等事实上的标准。

新增内容：寒武纪爆发

围绕稳定的核心，数据堆栈在过去一年中迅速发展。从广义上讲，我们在两个领域看到了最多的活动：

• 旨在支持关键数据流程和工作流的新工具，如数据发现、可观察性或ML模型审核
  允许数据团队和业务用户以新的、更强大的方式从数据中产生价值的新应用程序，如数据工作区、反向ETL和ML应用程序框架

我们还看到一些旨在增强核心数据处理系统的新技术的引入。值得注意的是，围绕分析生态系统中的度量层和运营系统的lakehouse模式进行了积极的辩论——两者都在向有用的定义和架构趋同。

更新的蓝图

在这种情况下，我们将详细讨论每个主要的数据基础架构蓝图。下面的每个部分都显示了更新的图表和关键更改的分析。
这些部分主要用作实现这些堆栈的数据团队的参考，阅读它们并不是后续文章的必要内容。

未更改的内容：

• 数据复制（如Fivetran）、云数据仓库（如Snowflake）和基于SQL的数据建模（使用dbt）的组合继续构成该模式的核心。这些技术的采用有意义地增加了，促进了新竞争对手（例如Airbyte和Firebolt）的融资和早期增长。
• 仪表板仍然是输出层中使用的最常见的应用程序，包括Looker、Tableau、PowerBI和较新的入口（如Superset）。

新增功能：

• 度量层（metrics layer）引起了极大的兴趣，该系统在数据仓库之上提供了一组标准的定义。这已经引起了激烈的辩论，包括它应该具有哪些功能，哪些供应商应该拥有它，以及它应该遵循什么规范。
• 到目前为止，我们已经看到了几种可靠的纯游戏产品（如Transform和Supergrain），以及通过dbt扩展到这一类别的产品。
• 反向ETL供应商有了显著的增长，特别是Hightouch和Census。这些产品的目的是使用来自数据仓库的输出和见解来更新运营系统，如CRM或ERP。
• 数据团队对新应用程序表现出更强的兴趣，以增强其标准仪表板，特别是数据工作区（如Hex）。广义地说，新应用程序可能是云数据仓库中日益标准化的结果——一旦数据结构清晰且易于访问，数据团队自然希望对其进行更多的操作。
• 数据发现和可观察性公司激增并筹集了大量资本（特别是Monte Carlo 和Bigeye）。
• 虽然这些产品的好处很明显，即更可靠的数据管道和更好的协作，但随着客户发现相关的用例和预算，采用这些产品仍然相对较早。（技术说明：尽管在数据发现方面有几个可信的新供应商——例如Select Star、Metaphor、Stemma、Secoda、Castor——但我们通常将种子期公司排除在图表之外。）

未更改的内容：

• 数据处理（例如Databricks、Starburst和Dremio）、传输（例如Confluent和Airflow）和存储（AWS）中的核心系统继续快速增长，并形成了该蓝图的主干。
• 多模态数据处理在设计上保持多样性，允许公司在分析和运营数据应用程序中采用最适合其特定需求的系统。

新增功能：

• lakehouse 筑越来越受到重视，也越来越清晰。我们看到了广泛的供应商（包括AWS、Databricks、Google Cloud、Starburst和Dremio）和数据仓库先驱支持这种方法。
• lakehouse的基本价值是将健壮的存储层与一系列强大的数据处理引擎（如Spark、Presto、Druid/Clickhouse、Python库等）配对。
• 存储层本身正在升级。虽然Delta、Iceberg和Hudi等技术不是新技术，但它们的采用速度正在加快，并正在构建到商业产品中。其中一些技术（特别是Iceberg）也可以与Snowflake等云数据仓库进行互操作。如果异质性继续存在，这可能会成为多模式数据堆栈的关键部分。
• 流处理（即实时分析数据处理）的采用可能会增加。虽然第一代技术（如Flink）仍未成为主流，但具有更简单编程模型（如Materialize和Upsolver）的新进入者正在获得早期采用，并且，有趣的是，来自现有Databricks和Confluent的流处理产品的使用也开始加速。

未更改的内容：

• 与2020年相比，今天用于模型开发的工具大体相似，包括主要云供应商（例如Databricks和AWS）、ML框架（例如XGBoost和PyTorch）以及实验管理工具（例如Weights&Biases和Comet）
• 实验管理有效地将模型可视化和调优归入了独立的类别。
• 构建和操作机器学习堆栈是复杂的，需要专门的专业知识。这个蓝图并不适合胆小的人——生产人工智能对许多数据团队来说仍然是一个挑战。

新增功能：

ML行业正在围绕以数据为中心的方法进行整合，强调复杂的数据管理而不是增量建模改进。这有几个含义：

• 数据标签（例如，Scale和Labelbox）的快速增长以及对闭环数据引擎的兴趣不断增长，这在很大程度上是以特斯拉的Autopilot数据管道为模型的。
• 对于批量和实时用例，功能存储（例如Tecton）的采用增加，作为以协作方式开发生产级ML数据的一种手段。
• 重新激发了对低代码ML解决方案（如Continual和MindsDB）的兴趣，这些解决方案至少部分地自动化了ML建模过程。这些较新的解决方案专注于将新用户（即分析师和软件开发人员）引入ML市场。
• 使用预先训练的模型正在成为默认模式，特别是在NLP中，并为OpenAI和Hugging Face等公司提供顺风。这里仍然有一些关于微调、成本和扩展的有意义的问题需要解决。
• ML的操作工具（有时称为MLops）正在变得越来越成熟，围绕ML监控构建，作为最符合需求的用例和即时预算。与此同时，一系列新的运营工具——特别是验证和审计——正在出现，最终市场仍有待确定。
• 人们越来越关注开发人员如何将ML模型无缝集成到应用程序中，包括通过预构建的API（例如OpenAI）、向量数据库（例如Pinecone）和更固执己见的框架。

数据平台假设

概括一下：在过去的一年中，数据基础架构堆栈在核心系统中保持了实质性的稳定性，支持工具和应用程序迅速增加。为了帮助解释为什么会发生这种情况，我们在这里介绍了数据平台的概念。

什么是平台？

“平台”一词在数据生态系统中过载，通常由内部团队用于描述其整个技术堆栈，或由供应商用于销售松散连接的产品套件。

在更广泛的软件中，平台是其他开发人员可以在其上构建的东西。平台本身提供的价值通常有限——例如，大多数用户对访问Windows或iOS的内核没有兴趣。但它们提供了一系列好处，如通用编程接口和庞大的安装基础，允许开发人员构建和分发用户最终关心的应用程序。
从行业角度来看，平台的定义特征是具有影响力的平台提供商和大量第三方开发人员之间的相互依赖性（技术和经济）。

什么是数据平台？

从历史上看，数据堆栈显然不适合平台的定义。ETL、数据仓库和报告供应商之间存在相互依赖性，例如，但集成模型倾向于一对一，而不是一对多，并由专业服务大量补充。

根据与我们交谈的一些数据专家的说法，这可能正在开始改变。

平台假设认为，数据堆栈的“后端”（大致定义为数据接收、存储、处理和转换）已经开始围绕相对较少的基于云的供应商进行整合。因此，客户数据是在一组标准系统中收集的，供应商正在进行大量投资，以使其他开发人员能够轻松访问这些数据——这是Databricks等系统的基本设计原则，也是Snowflake等系统中的SQL标准加上自定义计算API。

反过来，“前端”开发人员也利用了这个集成点来构建一系列新的应用程序。他们依赖于数据仓库/lakehouse中干净、连接的数据，而不担心它是如何到达那里的底层细节。单个客户可以在一个核心数据系统上购买和构建许多应用程序。我们甚至开始看到传统的企业系统，如财务或产品分析，正在使用“仓库本机”架构进行重建。
图片可能如下所示：

需要明确的是，这并不意味着OLTP数据库或其他重要的后端技术将在不久的将来消失。但与OLAP系统的本机集成可能会成为应用程序开发的关键组件。随着时间的推移，越来越多的业务逻辑和应用程序功能可以过渡到该模型。我们可能会看到在该数据平台上构建了一整套新产品。

数据应用程序的出现？

数据平台假设仍然存在很大的争议。
然而，我们看到在数据平台之上实现为水平层的复杂垂直SaaS解决方案的增加。

因此，在早期，我们认为数据堆栈中发生的变化至少与平台正在占据主导地位的想法一致。
有许多原因，例如，像Snowflake和Databricks这样的公司已经成为数据堆栈中稳定的部分，包括优秀的产品、有能力的销售团队和低摩擦部署模型。但也有一种情况需要说明，平台动态增强了它们的粘性-一旦客户构建了一系列数据应用程序和/或将其与其中一个系统集成，则通常没有必要过渡。

对于近年来新的数据基础架构产品的激增，也可以提出类似的论点。这一趋势的典型解释与大量的数据、不断增加的企业预算以及风险投资的过剩有关。但可以说，这些事情几十年来都是真的。我们现在看到如此多的新产品出现的原因可能与平台有关——也就是说，采用新的数据应用程序从未如此容易，正确维护平台从未如此重要。

最后，平台假设在竞争动力学方面提供了一些预测能力。在规模上，平台可能非常有价值。核心数据系统供应商今天可能正在激烈竞争，不仅是为了当前的预算，还为了长期的平台地位。如果您认为数据摄取和转换公司是新兴数据平台的核心部分，那么对它们惊人的估值——或者特别是关于度量层或反向ETL等新类别的激烈辩论——也更有意义。

展望未来

我们仍然处于定义分析和运营数据平台的早期阶段，平台的各个部分都在不断变化。因此，它作为类比可能比作为严格定义更有用。但它可能是一种有用的工具，可以将信号从噪声中过滤出来，并有助于理解市场为什么会这样发展。

自数据库发明以来，数据团队现在拥有比任何时候（可能）更多的工具、资源和组织动力。我们非常兴奋地看到应用程序层在新兴平台之上的发展。