这篇文章通过演化模式的视角，讲述了数据领域中的进化故事它谈到了演化历程中的重要里程碑、它们的成就、挑战以及下一个解决这些挑战的里程碑这篇文章从商业和技术角度双重视角出发，…

由Srujan和Travis Thompson合著

数据领域已经成熟并且自基础文件在地下室出现以来已经走过了很长的路程。这段旅程一直充满了迷人的和激动人心的元素，就像软件革命一样。好处是我们正处于数据革命的中心，并有机会亲身见证。

5-10年前，我们正在面对完全不同的问题，而今天我们正在面对完全不同的问题。有些问题由于数据的富勃发展而产生，有些问题则出人意料地由于解决最初的问题所设计的解决方案而起源。

这导致了许多数据堆栈和体系结构之间的转变。然而，最为突出的是三个简单但基本的堆栈：传统数据堆栈、现代数据堆栈和数据优先堆栈。让我们看看这是如何运作的。

进化基础：触发数据领域变革的模式

进化有两个广义模式：分化和趋同。这些广义模式也适用于数据领域。

地球上物种的多样性是由于分化进化。同样，分化进化导致了数据行业中称为MAD Landscape的各种工具和服务的广泛出现。趋同进化随着时间的推移，在工具的变体中创造了具有共享特征的工具。例如，老鼠和老虎都是非常不同的动物，但它们都有类似的特征，如触须、毛发、四肢和尾巴。

趋同进化导致了工具解决方案中的共同分母，这意味着用户为冗余功能付费。分化进化导致了更高的集成成本，并需要专家了解和维护每个工具的独特理念。

请注意，共同分母并不意味着点解决方案正在朝着统一的解决方案趋近。相反，每个点都在开发与其他点的解决方案交叉的解决方案，这些解决方案基于需求。这些共同的能力具有不同的语言和理念，并需要专业的专家。

例如，Immuta和Atlan分别是数据治理和目录解决方案。但是，Immuta也正在开发数据目录，而Atlan正在增加治理功能。客户往往会用专门处理它们的工具替换次要功能。这导致以下结果：

• 花费时间了解每个产品的语言和理念
• 重复成本的启动两个具有类似功能的工具
• 狭窄专家的高资源成本；更具挑战性，因为缺乏良好的人才

现在我们对进化模式有了高层次的理解，让我们看看它们如何在数据领域中体现。出于简洁起见，我们不会回溯太远。

倒带几年

我们作为数据行业今天面临的问题与5-6年前大不相同。当时组织面临的主要挑战是从本地系统转移到云端。本地大数据生态系统和SQL仓库（或传统数据堆栈，又称TDS）不仅难以维护，可用时间极低，而且在数据到洞察之旅的长度方面也极其缓慢。简而言之，规模和效率远远超出了范围，特别是由于以下障碍：

数据工程师的军队

任何数量的数据工程师都不足以维护内部系统。从仓库和ETL到仪表板和BI工作流程，所有内容都必须在内部进行工程设计，导致大部分组织的资源都花费在建设和维护上，而不是收入生成活动上。

管道压倒性

数据管道是复杂且相互连接的，其中许多管道是为了应对新的业务需求而创建的。有时，需要新的管道来回答一个问题或从少量源表创建大量数据仓库表。这种复杂性可能是不可抗拒的，难以管理。

零容错

没有备份、恢复或RCA，数据是不安全也不可信的。数据质量和治理是思考后事，并且有时甚至超出了工程师的工作范围，他们在管道活动的重压下辛勤工作。

数据移动的成本

在传统系统之间进行大规模数据迁移是另一个红旗，消耗了大量的资源和时间。此外，它最终导致了数据损坏和格式问题，这需要另外几个月来解决或被抛弃。

抵制变化

本地系统中的管道非常脆弱，因此对频繁的变化或任何变化都有很强的抵制力，对于动态和变化多端的数据操作来说，这成为一场灾难，使得实验成本高昂。

疲惫不堪的步伐

花费了数月甚至数年时间部署新的管道以回答通用的业务问题。动态业务请求是不可能的。更不用说在高频率停机期间失去了活跃的业务。

技能不足

高额的技术债务或软件腐败导致了项目交接上的抵制，因为存在关键依赖关系。市场上缺乏正确的技能也没有帮助，经常导致关键管道的重复跟踪数月之久。

当时的解决方案及其带来的问题

云的出现与成为云原生的义务

十年前，数据并没有像今天这样被视为资产。特别是因为组织没有足够的数据可以利用为资产，而且因为他们必须处理无数问题才能生成一个可行的仪表板。但随着时间的推移，随着流程和组织变得更加数字化和数据友好，数据生成和捕获突然呈指数级增长。

组织意识到，通过理解比他们的容量大得多的历史模式，他们可以改进他们的流程。为了解决TDS的持久性问题并赋予数据应用程序的功能，出现了多个点解决方案并集成到中央数据湖中。我们称这种组合为现代数据堆栈（MDS）。毫无疑问，它几乎是当时数据行业问题的完美解决方案。

➡️ 转向现代数据堆栈（MDS）

MDS解决了当时数据领域中一些持久性问题。其最大的成就可能是对云的革命性转变，使得数据不仅更加易于获取，而且也更易于恢复。像Snowflake、Databricks和Redshift这样的解决方案帮助大型组织将数据迁移到云中，增加了可靠性和容错性。

由于各种原因，包括预算限制，支持TDS的数据领导人感到有义务转向云，并在看到其他组织成功转型后保持竞争力。这需要说服CFO优先考虑并投资于转型，这可以通过承诺在不久的将来创造价值来实现。

但是成为云原生并不仅仅意味着迁移到云中，这本身就是一个巨大的成本。成为真正的云原生还意味着集成一系列解决方案来在云中操作数据。计划看起来很好，但MDS最终将所有数据都倾泻到一个中央湖中，导致跨行业的数据沼泽无法管理。

💰 投资于虚幻承诺

• 将大量数据资产迁移到云中的成本
• 保持云的运行成本
• 购买点解决方案所需的个人许可证的成本
• 在点解决方案中的共同或冗余因素的成本
• 理解每个工具不同哲学的认知负荷和专业知识的成本
• 每当新工具加入生态系统时的持续集成成本
• 持续维护集成和随之而来的管道堵塞的成本
• 建立数据设计基础架构以操作点解决方案的成本
• 保持基础架构运行的专用平台团队的成本
• 存储、移动和计算数据沼泽中100%的数据的成本
• 针对每个曝光点或集成点进行孤立治理的成本
• 由于多个曝光点而产生的频繁数据风险的成本
• 在频繁的项目交接中进行复杂依赖关系的成本

正如您所想象的那样，这个列表远非详尽无遗。

🔄 数据ROI的恶性循环

数据领导者，包括CDO和CTO，很快感受到了数百万美元规模的投资未实现的承诺的负担。增量补丁解决方案所带来的问题和解决的问题一样多，数据团队又回到了无法使用自己拥有的丰富数据的根本问题上。

未来保障的缺失对领导者来说是一个严重的风险，他们在组织中的任期缩短至不到24个月。为了确保CFO看到回报，他们抓住了流行的数据设计架构和新的工具创新，为他们展开了新的承诺。

此时，CFO办公室不可避免地开始质疑承诺的结果的可信度。更危险的是，他们开始质疑投资于数据中心垂直本身的价值。难道在其他运营上花费的数百万美元不会在五年内产生更好的影响吗？

如果我们深入研究并接近上面讨论的实际解决方案，它将更清楚地说明多年来数据投资已经生锈，特别是由于隐藏的和意外的成本。

TCO的估算是基于专业人士的成本、迁移、设置、处理固定工作负载的计算、存储、许可证费用以及治理、目录和BI工具等点解决方案的累计成本。基于客户与这些供应商的经验，我们在顶部添加了方格条，因为在使用这些平台时，通常会发生意外的成本跳跃。

由于这些成本的多样性，可能是工作量增加或背景查询到定价模型本身，它们最好被分类为“神秘成本”。另一方面，采用以数据为先的方法来抽象工具复杂性，TCO没有意外跳跃。对于每个工作负载和使用的存储，都有完全控制的计算。

💣 工具的大量扩散使每个堆栈都成为维护优先和数据最后。

随着MAD Landscape或MDS所展示的众多工具，组织越来越难以专注于实际带来业务结果的解决方案开发，因为维护工单不断引起注意。

不称职的数据工程师陷入了维护优先、集成次要和数据最后的经济中。这包括花费无数小时解决基础设施缺陷和维护数据管道。而托管和集成多种工具所需的基础设施也同样痛苦。

数据工程师被大量的配置文件、频繁的配置漂移、每个文件的特定环境自定义以及无数的依赖项开销所压倒。简而言之，数据工程师为了确保数据基础架构与正常运行时间SLO相匹配而彻夜难眠。

工具的压倒不仅在时间和精力上昂贵，而且集成和维护开销直接影响了工程团队的ROI，而不会为驱动业务的数据应用程序提供任何直接的改进。

这里是通过传统的ETL和ELT方法表示企业数据移动的方式。它包括集成批处理和流式数据源以及数据工作流程的协调成本。

随着时间的推移，企业将增加平台的使用量，包括集成的源系统数量和执行的后续数据处理，成本也相应增加。

发现大多数客户都是如此。在以数据为先的方法中，数据集成成本为零到最小，因为它普遍采用智能数据移动和抽象的集成管理，允许最小的数据移动进行数据处理。

🚧 组织被迫遵循工具的理念。

管理一堆不同的解决方案并不是结束了。组织被迫遵循这些单独工具预定义的方向和理念。例如，如果引入治理工具，数据开发人员就会学习如何操作该工具，学习它与其他工具通信的特定方式，并重新排列其他工具以匹配新组件的规格。

每个工具都有自己的哲学，作为设计架构的一部分，这使得互操作性变得更加复杂和选择性。缺乏灵活性也是采用新的和创新的基础设施设计（例如网格和织物）的成本高昂的原因，这可能潜在地提高承诺的ROI。

大量具有独特理念的工具需要丰富的专业知识。在实践中，雇用、培训、维护和与如此多的数据工程师合作是不可能的。特别是在该领域中缺乏熟练和有经验的专业人士。

🧩 无法捕获和操作原子洞察力

严格的基础设施，由于丰富的工具和集成，意味着在正确的时刻向正确的客户端终点通道中的原子数据字节的低灵活性。原子性的缺乏也是低互操作性和孤立的子系统的结果，这些子系统没有很好的相互通信的已确立的路线。

一个很好的例子是每个点工具维护其单独的元数据引擎来操作元数据。元数据引擎有不同的语言和传输通道，除非专门设计用于此，否则几乎无法相互通信。这些新设计的通道还增加了维护标签。使用数据在翻译中丢失，并且平行垂直线无法利用从彼此中提取的洞察力。

此外，在MDS中的数据操作通常是批量开发、承诺和部署的，因为无法在MDS的混乱扩散中强制执行类似于软件的实践。实际上，除非将数据（数据堆栈的唯一非确定性组件）插入到可以强制执行原子提交、垂直测试沿着变化线和CI/CD原则的统一层中，否则DataOps是不可行的，从而消除不仅是数据孤岛而且还有数据代码孤岛。

应对MDS后续问题的解决方案

从传统数据堆栈到现代数据堆栈，最后再到基于数据的堆栈（DFS）的转变在很大程度上是不可避免的。由于在数据工程范围内积累了大量的技术债务，因此对DFS的需求在很大程度上得到了体现。DFS提出了一种统一方法或伞形解决方案，针对TDS和MDS的弱环节进行了针对整体而非补丁工作的哲学。

DFS为业务团队带来了自助服务功能。他们可以使用自己的计算资源，而不是争夺IT资源（这在许多企业中严重限制了业务团队访问数据的机会）。使用DFS更容易与合作伙伴共享数据并以合规方式获取利润。用户可以将数据放在首位，而不是努力整合数百个分散的解决方案，将重点放在核心目标上：构建直接提升业务结果的数据应用程序。

在当前市场上，降低资源成本是组织的首要任务之一，但要治理和编目多个点解决方案的分散景观的合规成本非常高，几乎是不可能的。DFS的统一基础架构通过将这些点能力组合成基本构建块并集中控制这些块来减少这种成本，从而立即提高了发现性和透明度。

DFS的编目解决方案是全面的，因为其数据发现和可观察性功能嵌入了本地治理和丰富的语义知识，允许进行主动元数据管理。除此之外，它还可以完全控制数据基础设施的所有应用程序和服务的访问控制。

基于数据的堆栈本质上是一个操作系统（OS），这是一个管理最终用户所需的所有程序的程序，而不是弄清楚如何运行这些程序。我们大多数人都曾在笔记本电脑、手机以及事实上任何界面驱动的设备上体验过操作系统。我们喜欢这些系统，因为我们可以从日常应用程序的启动、维护和运行低级细节的痛苦中抽象出来。相反，我们直接使用这些应用程序来推动结果。

因此，数据操作系统（DataOS）对于既懂数据又不懂数据的组织都是相关的。总之，它通过抽象用户的应用程序的程序复杂性来实现自助数据基础设施，并声明性地提供结果。

🥇 从以维护为先向以数据为先的转变

数据操作系统（DataOS）是将数据放在首位并理解组织必须成为数据的用户而不是数据基础设施的构建者的数据堆栈。DataOS抽象了所有低级数据管理的细节，否则会占据大部分数据开发人员的时间。

通过声明式管理系统，大大减少了系统的脆弱性范围，并在需要时提供 RCA 镜头，从而优化资源和投资回报率。这使得工程人才可以将他们的时间和资源投入到数据和构建直接影响业务的数据应用程序中。

数据开发人员可以通过消除配置漂移和大量的配置文件，通过不需要环境特定变量的标准基础配置快速部署工作负载。该系统自动生成应用程序的清单文件，可以对其进行增删改查操作、执行和元存储等，从而实现了以工作负载为中心的开发，其中数据开发人员声明工作负载要求，而 DataOS 提供资源并解决依赖项。结果，部署频率的增加可以立即实现。

💠 走向统一架构

🧱 从拼凑解决方案到基本构建块的转变

通过可组合的 Data Operating System 架构的高内部质量，仅需数周即可实现数据优先：统一化通过模块化。模块化可以通过一组有限的基元实现，这些基元已被认为是数据堆栈在其最基本形式下的基本组成部分。这些基元可以被特定地排列以构建更高级别的组件和应用程序。

它们可以被视为工件，可以使用版本控制系统进行源代码控制和管理。每个基元都可以被认为是一种抽象，它允许您以声明性方式枚举特定目标和结果，而不是定义“如何达到这些结果”的艰难过程。

🦾 统一预先存在的工具以进行声明式管理

DataOS 作为建筑层之上的艺术品，使用开放标准，可用于与 DataOS 本机和外部的异构组件交互。因此，组织可以将其现有的数据基础结构与新的创新技术集成，而无需完全重建其现有系统。

对于开发人员而言，它是一个完整的自助式界面，通过 API 和 CLI 声明性地管理资源。业务用户通过直观的 GUI 实现自助服务，可以直接将业务逻辑集成到数据模型中。GUI 接口还允许开发人员可视化资源分配并简化资源管理。这节省了开发人员的大量时间，增强了生产力，他们可以轻松地管理资源，而无需过多的技术知识。

☀️ 中央治理、编排和元数据管理

DataOS 在双平面概念架构上运行，其中控制在一个中央平面用于核心全球组件，而一个或多个数据平面用于本地化操作。控制平面帮助管理员通过垂直组件的集中管理和控制来管理数据生态系统。

用户可以集中管理基于策略和目的的云原生环境中各种接触点的访问控制，优先考虑本地所有权，编排数据工作负载，计算集群生命周期管理，DataOS 资源的版本控制以及管理不同类型的数据资产的元数据。

⚛️ 用于实验性用例的原子洞察

行业正在迅速从交易性用例转向实验性用例。从长期批次的大块数据中获得的重大洞察现在是次要需求。从点数据中推断出的原子或字节大小的洞察是新的游戏规则，客户非常愿意为此付费。

基元的共同基础层确保数据在统一架构中的所有接触点上可见，并可以根据业务用例的要求通过语义抽象材料化到任何通道中。

Animesh Kumar 是 @Modern 的首席技术官兼联合创始人，也是数据操作系统基础架构规范的共同创建者。在他 30 多年的数据工程领域工作中，他曾为包括 NFL、GAP、Verizon、Rediff、Reliance、SGWS、Gensler、TOI 等在内的众多 A-Players 架构了工程解决方案。

Srujan 是 @Modern 的首席执行官兼联合创始人。在他 30 年的数据和工程领域工作中，Srujan 作为企业家、产品执行官和业务领袖积极参与社区，多次在 Motorola、TeleNav、Doot 和 Personagraph 等组织中推出多个屡获殊荣的产品。

Travis Thompson（共同作者）：Travis是数据操作系统基础设施规范的首席架构师。在数据和工程领域拥有30年的经验，为GAP、Iterative、MuleSoft、HP等顶级组织设计了最先进的架构和解决方案。