图片由作者提供。（由Midjourney生成，再用Krita进行润色处理。）
本文最初发表在我的博客https://jack-vanlightly.com上。
这篇文章是受到伯恩德·韦斯利的帖子中“提防筒仓式专长”部分的启发，并对其进行了延伸讨论《数据架构：经验教训》。它结合了我所观察到的一些趋势，并融入了我的个人见解，结合了我在软件和数据团队两边工作了二十年的经验和个人见解。
康威定律（Conway's Law），即组织的沟通结构将决定所产生的软件的结构。
“任何一个设计系统的组织（广义上的系统），其设计结构都会是该组织沟通结构的翻版。” ——梅尔文·康韦
这种情况在全球数以万计的组织中上演，尤其明显地体现在软件开发团队和数据分析团队之间的分隔。这两个团队通常有不同的汇报线，一直延伸到或紧挨着高管团队。
这现在是个问题，而且只会越来越严重。
Jay Kreps [五年前说过](https://www.confluent.io/blog/every-company-is-becoming-software/ 原文链接)，组织正在变得越来越像软件。
“不仅仅是企业使用了更多的软件，而且企业的核心业务流程越来越多地通过软件来定义。也就是说，从产品生产、客户互动到服务提供，这些核心流程越来越多地通过软件来定义、监控和执行。” — Jay Kreps
此软件的效果直接影响到组织的成功。如果软件运行不正常，会导致组织也出现问题。反之亦然，组织的问题也会反映在软件上。所有这些都意味着一家想要在行业内取得成功的公司，可能在执行上落后于竞争对手，而且在应对市场条件变化时反应迟缓。虽然这种观点已经重复了很多次，但它确实是基本事实。
当“软件工程”团队和“数据”团队各自在其独立的汇报结构中运作时，就会发生一种悲喜剧，使得这最大的输家就是整个业务。
变革的风刮起了
作者的图片。（由Midjourney生成，用Krita润色过）
越来越多的迹象表明，对于目前“我们和他们”的状况，即软件和数据团队各自为战，完全不了解对方的需求和对业务成功所做的贡献，人们的态度正在发生变化。在最近两年里，数据分析领域出现了三个关键趋势，这些趋势有可能带来真正的改善。每个趋势仍处于早期阶段，但正逐步增强：
- 数据工程是软件工程的一个分支。
- 数据协议和数据产品。
- 左移策略。
读了这篇文章，你就会发现这三者确实紧密相连。
数据工程学是软件工程中的一种学科数据工程作为一个独立学科从软件工程中独立出来的理由有很多：
- 在数据分析和商业智能（BI）领域，即数据工程在此领域中被实践，过去它一直被视为与软件开发完全不同的业务职能。这导致了双方文化的分歧，双方之间缺乏交流与学习。
- 数据工程面对的问题与传统软件开发不同，所以使用的工具也不同。
- 过去25年来，数据工程经历了巨大变化。许多新问题的出现要求从基础重新思考技术，导致了一段漫长的试验和创新期。
虽然技术还在不断发展，但大部分尘埃已经落定。我们有了充裕的时间来巩固成果并评估现状。数据社区已经开始意识到，许多当前问题与软件开发中的问题其实并没有太大区别。数据团队编写软件并与软件系统交互，这和软件工程师的工作并无二致。
软件的类型可能看起来有所不同，但软件工程中的许多实践同样适用于数据工程和分析工程。
- 测试。
- 稳定可靠的 API。
- 可观察性/监控，
- 模块化和可重用性。
- 与尽早修复相比，后期修复 bug 的成本更高。
到了让数据和分析工程师们把自己当作软件工程师，并定期将软件工程领域的常见实践应用于自己领域的时候了。
数据协议和数据产品数据契约在2022/2023年突然出现在数据领域，作为对由管道故障和表现不佳的数据团队导致的挫败感的回应。它迅速流行起来，每个人都在谈论数据契约，尽管具体如何实施并不清楚。但目标是明确的：解决管道问题。
由于多种原因，管道破裂：
- 软件工程师对数据工程师在其应用程序数据库之上构建的内容一无所知，因此，他们既不保证也不预警那些即将影响到管道的表结构更改（通常是因为他们对此毫不知情）。
- 由于组织内部的问题，如功能障碍或隔离等原因，数据工程师很难与他们依赖的软件团队建立健康的合作关系。即使能够建立关系，软件团队的领导也不愿意帮助数据团队获取所需数据，仅仅提供数据库凭证。因此，数据工程师直接从源中获取数据，破坏了传统的软件封装原则，从而导致了一系列问题。
最近我听了Super Data Science E825这集，嘉宾是Chad Sanderson。他是一位非常支持数据合约的人。我特别喜欢他对这个术语的解释。
我对数据质量的定义与其他人的略有不同。在软件世界中，人们通常将质量视为确定性的。所以我正在编写一个功能，或者构建一个应用程序，我为该应用程序设有一套要求，如果软件不再符合这些要求，这就是一个已知的错误，是一个质量问题。但在数据领域，你可能会有一个数据的生产者，它在以某种方式生成或收集数据，做出一个对他们的用例来说完全合理的改变。例如，我可能有一个名为“时间戳”的列，记录的是本地时间，但我会将它改为UTC格式。完全没问题，合情合理，这可能是你应该做的。但如果我下游的某一方期望的是本地时间，他们将面临一个数据质量问题。因此，我的看法是，数据质量问题实际上是由于数据生产者和数据消费者之间未管理好期望所导致的，而这正是数据合同的作用。它的作用是帮助这两方更好地相互合作。 —— Chad Sanderson
数据合约的定义在解释和实现上针对实际技术和模式的具体应用具有一定的灵活性。模式管理是主要议题，但只是解决方案的一部分。数据合约不仅仅是定义数据的结构（即模式），还涉及到信任和可靠性，我们可以从REST API社区的角度来理解这一点。
- REST API 通常通过 OpenAPI 这种 REST API 规范工具进行文档记录。这主要涉及请求和响应模式，以及安全方案。
- REST API 会进行版本控制，并非常小心地在不引入破坏性变更的情况下进行版本更新。关于 API 版本控制的话题很长，有着悠久的讨论历史，关于哪种选项最适宜。但重点是，软件工程界已经深思熟虑了如何让 API 演变。
- 频繁因破坏性变更发布新主要版本的 REST API 就是糟糕的 API。发布 API 给客户的组织必须确保不仅创建一个结构良好且规范的 API，还要确保它不会频繁变化。
在软件工程中，服务A绝不会这么做。服务A绝对不会直接访问服务B的内部数据库，而是如下：
在软件工程中，服务A绝不会这么做。服务A绝对不会直接访问服务B的内部数据库，而是如下：
- 两个服务的工程领导/团队建立沟通渠道，最开始可能是面对面的沟通。
- 服务A的团队为服务B设计良好的接口，不会破坏服务A的封装。这可能是一个REST API，或者一个服务B可以订阅的事件流或消息队列。
- 服务A的团队承诺维护这个API/流/队列。这包括随着时间演进，为服务B提供一个稳定且可预测的接口。其中一些维护工作可以由平台团队承担，他们负责为开发团队提供基础构建模块。
服务A的团队为什么要做这件事来帮助服务B的团队？纯粹是为了利他主义吗？不是。他们之所以合作，是因为这对企业来说是有价值的。一个运作良好的组织会秉持#OneTeam的精神，组织会采取必要的措施来高效和有效地运作。这意味着服务A的团队有时需要为其他团队的利益工作。这是因为激励机制在各个管理层之间得到了一致。
在软件工程中也众所周知，如果在开发周期后期甚至是在生产环境中修复 bug，其成本会比早期解决高得多。回溯到一两周或一个月前的工作会干扰软件流程，而生产环境中的 bug 可能会带来各种麻烦。前期花点功夫生产出稳定且良好的 API，会让每个人的工作更轻松。正如一句老话所说：预防胜于治疗，防微杜渐。
这些API就像合同。它们通过软件团队间的沟通建立，并在当明确投入回报率值得时实施。这实际上是这样的。由于软件管理层的利益一致性，这通常是软件工程部门内部运作的方式。
数据类产品术语 API（或应用程序编程接口）并不完全适用于“数据”这一概念。因为产品本身是数据，而不是某个业务逻辑的接口，所以“数据产品”这个词更合适。这个词“产品”也暗示着某种质量，某种程度的专业性和可靠性。这就是为什么数据合约和数据产品密切相关，数据产品是数据合约的一种具体表现。
数据产品在软件层面上与REST API非常相似。它涉及到团队间沟通渠道的开放，数据形态的严格规范（包括前面Chad提到的时区），随着不可避免的变化谨慎演进，以及数据提供者对保持稳定数据API的承诺。不同之处在于，数据产品通常是一个表或一个数据流，而不是像HTTP REST API那样通常用于驱动某些逻辑或每次调用检索单个实体。
另一个关键的见解是，正如 API 可以以可预测的方式使服务更可重用，数据产品也可以使处理数据的工作更加可重用。在软件世界中，一旦订单 API 发布了，所有需要与订单子系统交互的下游服务都通过该 API 进行交互。并不会为每个下游用例单独设置一次性接口。而在数据工程中，我们经常看到的是单一用途的管道和用于不同用例的多个数据副本。
简单点说，软件工程通过模块化（比如软件模块或API）促进软件的重用。对于数据产品而言，它们对数据也是如此。
左移策略Shift Left 起源于网络安全领域。安全也一直是一个独立的领域，软件团队和安全团队在不同的汇报结构下工作，使用不同的工具，有不同的激励，并且很少共享相同的专业术语。结果就是，我们已经习惯了日益严重的信息安全危机，以至于下一起涉及数百万条记录的泄露事件几乎不再引起关注。我们对这种情况已经习以为常，甚至可能不再认为这是危机，但当你看到勒索软件团伙、信息窃取者和勒索者留下的破坏痕迹时，很难说这种情况应该被视为正常。
Shift Left 的理念是指将安全的关注点转移到软件开发阶段，而不是由一个对软件开发不太了解的团队在开发完成后单独进行。这不仅意味着在开发流程的早期阶段就融入安全性，也是关于提高网络遥测的质量。网络遥测的多样性和复杂性促使将处理、清理和上下文关联的工作提前到数据生成的地方。一旦数据来源丢失，这些数据的分析就会变得非常困难。尽管网络数据特别棘手，但这些经验也可以应用于其他领域，比如数据处理。
网络安全和数据 analytics 的孤立系统非常相似。孤立系统假设其功能可以独立运作，与其他业务功能分离。然而，无论是网络安全还是数据 analytics，都是跨职能的，必须与其他多个业务领域互动。跨职能团队不能孤立操作或事后补救。这种孤立的方式行不通，“左移”则是打破这种孤立，采用更融入软件开发流程的方式替代集中式的做法。
伯恩德·维斯利在TowardsDataScience上写了一篇精彩的博文，讨论了数据孤岛现象。他认为，数据分析孤岛如此根深蒂固，以至于当前的做法从未受到质疑。他指出，这种“先摄入再处理”的模式只是应对不当数据管理的一种权宜之计。这种权宜之计之所以必要，是因为企业今天处理数据的方式极其不恰当。
可惜的是，这一切都不是新鲜事。我职业生涯中一直在读关于打破部门壁垒的文章，而现在已经是2024年了，我们还在讨论打破它们的必要性！但我们必须打破它们，这一点不容置疑！
如果数据孤岛是一个与组织其他软件分离的集中式的单体系统，那么“左移”这一概念则指的是将数据基础设施集成到软件所在、开发和运维的实际位置。
服务B不仅直接访问了服务A的私有内部；相反，创建了一个接口，让服务A可以从服务B获取数据而不违反封装原则。这个接口，无论是API、队列还是流，都成为了一种稳定的数据获取方式，不会因为服务A每次需要更改其内部机制而中断。服务A的团队承担了提供这个接口的任务，因为这是正确的解决方案，但也从商业角度支持这样做。同样适用于“左移”；与其将使数据可用的责任放在想要使用数据的人身上，不如将责任转移到数据的生产者和维护者身上。
这一向左的转变核心是数据产品。无论是事件流数据还是冰山表，通常最好由负责基础数据的团队管理。这样，我们就可以避开那些临时凑合的解决方案，不避开好的做法。
要做到这一点，我们需要以下内容：
- 各方之间需要良好的沟通与协调。这需要一定的商业成熟度，但在我们达到这个目标之前，我们可能还在讨论十年或二十年之后打破信息孤岛的问题，或者直到人工智能彻底取代我们。
- 技术解决方案，以简化数据产品的开发、维护和支持。
在这个领域我们看到了很多动态，从目录、治理工具，再到如Apache Iceberg等表格式以及丰富的事件流选项。这里不仅有大量的开源项目，也有许多供应商。构建数据产品的技术和实践仍然处于初级阶段，但预计这一领域将会迅速发展。
结论是你可能以为数据平台工程大多数情况下是解决技术难题。可惜的是，偏偏又是人事问题耗尽了全部精力。——Birdy (@CorvusCrypto)
组织正在软件化，而软件的组织方式则依据业务的通讯结构；因此，如果我们想要解决软件、数据、安全孤岛问题，那么解决之道就在通讯结构上。
要让数据分析在企业中更具影响力，最有效的方式是解决康威定律的问题。这导致了数据团队与更广泛的软件工程学科在文化和技术上的脱节，以及沟通结构不完善和缺乏共同语言。
结果就是这样的：
-
两边合作和协调不佳，导致：
- 操作层面与数据分析层面之间的拼凑整合。
- 为了应对操作层面的变化，数据分析层面不断进行频繁的修复工作。
- 软件工程师用来让软件开发更经济且更可靠的许多优秀实践被忽视。
实现更加集成的软件和数据分析世界的愿景所面临的障碍是数据团队持续的孤立以及妨碍软件和数据团队合作的激励不一致。我相信，那些拥抱“#OneTeam”理念，让这两方面进行交流与合作，甚至在一定程度上合并的组织将获得最大的投资回报。一些组织可能已经采取了这一做法，但这还远未成为普遍现象。
事情在变；态度也在变。例如，数据工程是软件工程，数据契约和产品的出现以及左移策略都是这些变化的早期迹象。
随时随地看视频
