·发表于 Towards Data Science ·12 分钟阅读·2024 年 10 月 25 日
--
图片由作者提供。（由 Midjourney 生成，并用 Krita 进行修饰）
本文最初发表于 我的博客 上 https://jack-vanlightly.com。
本文的灵感来源并延伸了 Bernd Wessely 在《数据架构：经验教训》一文中的“警惕孤岛化专业化”部分 Data Architecture: Lessons Learned*。它汇集了我观察到的几个趋势，以及我在软件与数据团队分割两边工作二十年的经验所形成的个人看法。*
康威定律：
“任何设计系统的组织（广义定义）都会产生一个结构，其结构是该组织沟通结构的复制。” — Melvin Conway
这一现象在全球范围内的数十万家组织中都有上演，尤其在软件开发与数据分析团队之间的分裂中体现得尤为明显。这两组通常有不同的汇报结构，直到或紧接着高层管理团队。
这个问题如今已经存在，并且只会不断加剧。
Jay Kreps 五年前提到组织正在变成软件：
“问题不仅仅在于企业使用更多的软件，而是越来越多的企业在软件中得以定义。也就是说，一个企业执行的核心流程——从它如何生产产品，到它如何与客户互动，再到它如何提供服务——越来越多地在软件中被明确、监控和执行。” — Jay Kreps
这一软件的有效性与组织的成功直接相关。如果软件存在功能障碍，组织也会出现问题。反过来，组织结构上的问题也会在软件中体现出来。这意味着，一个想要在其领域中脱颖而出的公司，可能会在执行上落后于竞争对手，反应市场条件的速度也太慢。这样的情况已经被说了无数次，但这依然是一个基本的真理。
当“软件工程”团队和“数据”团队在各自的汇报结构中各自为政时，就会产生一种悲剧性的喜剧局面，最终最大输家是整个企业。
图片由作者提供。（由 Midjourney 生成，使用 Krita 进行了修饰）
越来越多的迹象表明，当前“我们与他们”的态度正发生变化，软件和数据团队之间的目标对立或完全忽视彼此的需求、激励和对企业成功的贡献的状况正在被改变。在过去两年中，数据分析领域出现了三大关键趋势，这些趋势有潜力带来真正的改进。每一个趋势仍然处于初步阶段，但正在获得动力：
-
数据工程是软件工程的一个学科。
-
数据契约和数据产品。
-
向左移动（Shift Left）。
阅读完本文后，我相信你会同意这三者紧密相连。
数据工程已经发展成为与软件工程分开的学科，原因有很多：
-
数据分析/商业智能（BI）领域，其中实践数据工程的地方，历来是与软件开发分开的业务职能。这导致了文化上的分歧，双方没有互相倾听或学习。
-
数据工程解决的问题与传统的软件开发有所不同，因此使用的工具也不同。
-
数据工程在过去 25 年中发生了巨大变化。许多新问题出现，需要从根本上重新思考技术，这导致了一段漫长的、混乱的实验和创新期。
尽管技术仍在发展，但尘埃大致已经落定。我们有时间整合并审视我们所处的状态。数据社区开始意识到，许多当前的问题实际上与软件开发领域的问题并没有本质区别。数据团队像软件工程师一样编写软件并与软件系统互动。
软件的类型可能不同，但许多来自软件工程的实践同样适用于数据和分析工程：
-
测试。
-
良好的稳定 API。
-
可观察性/监控。
-
模块化与重用。
-
在开发过程中后期修复错误的成本比在早期解决它们的成本更高。
是时候让数据和分析工程师认同自己是软件工程师，并定期将更广泛的软件工程学科的实践应用到自己的子学科中。
数据合同在 2022/2023 年间因应对数据管道不断崩溃修复和数据团队表现不佳的挫败感而迅速兴起。它迅速传播开来，大家纷纷讨论数据合同，尽管具体如何实现数据合同的细节并不多见。但目标是明确的：解决数据管道崩溃的问题。
由于多种原因，数据管道崩溃：
-
软件工程师并不知道数据工程师在他们的应用数据库之上构建了什么，因此没有对表格模式的变更提供任何保证，甚至没有警告即将发生的可能破坏数据管道的变化（通常是因为他们根本不知道）。
-
数据工程师由于组织功能失调或孤立，通常无法与他们依赖的软件团队建立健康的同行关系。或者即使能够建立关系，软件团队领导也没有支持数据团队获取所需数据的意愿，除了提供数据库凭证。结果就是直接从数据源中获取数据，破坏了长期以来软件工程中封装的实践（并因此遭受后果）。
最近我听了Super Data Science E825这一期节目，嘉宾是数据合同的倡导者 Chad Sanderson。我非常喜欢他对这一术语的定义：
我对数据质量的定义与其他人的有些不同。在软件领域，人们通常将质量视为非常确定的东西。比如，我在写一个功能，构建一个应用程序，我有一套该应用的需求，如果软件不再满足这些需求，那就叫做一个 bug，属于质量问题。但在数据领域，可能有一个数据生产者在以某种方式生成或收集数据，这种改变对他们的用例是完全合理的。举个例子，也许我有一个名为 timestamp 的列，它以本地时间记录，但我决定将其更改为 UTC 格式。这完全没有问题，也完全合理，可能是你应该做的事情。但是，如果我下游的某个使用者预期的是本地时间，那么他们就会遇到数据质量问题。因此，我的观点是，数据质量实际上是数据生产者与数据消费者之间管理不当的预期的结果，而数据合同的作用正是帮助这两方更好地协作。——Chad Sanderson
数据合同的构成仍然在一定程度上开放解释和实现，涉及具体的技术和模式。架构管理是一个核心主题，但仅是解决方案的一部分。数据合同不仅仅是指定数据的形状（其架构）；它还涉及信任和可靠性，我们可以从 REST API 社区中理解这一点：
-
REST API 通常通过 OpenAPI 来进行文档编制，这是一个 REST API 规范工具。它本质上是请求和响应的架构，以及安全方案。
-
REST API 是有版本的，并且非常小心地对其进行版本管理，以避免引入破坏性变化。当发生破坏性变化时，API 会发布一个新的主版本。API 版本控制是一个深入的话题，关于最佳选项的讨论历史悠久。但重点是，软件工程社区已经经过深思熟虑，思考如何演化 API。
-
一个不断变化并因破坏性变化而发布新主版本的 REST API 是一个糟糕的 API。发布 API 给客户的组织必须确保他们不仅要创建一个设计良好并且指定清晰的 API，还要确保其稳定，不会频繁变化。
在软件工程中，当 Service A 需要 Service B 的数据时，Service A 完全不会直接访问 Service B 的私有数据库。发生的情况是：
-
两个服务的工程领导/团队建立了沟通渠道，最初可能是面对面的对话。
-
Service A 团队为 Service B 安排了一个精心设计的接口，确保不会破坏 Service A 的封装。这可能会导致一个 REST API，或者是一个事件流或队列，供 Service B 消费。
-
Service A 团队承诺将继续维护这个 API/流/队列。这涉及到随着时间推移不断演化它，为 Service B 提供一个稳定且可预测的接口。部分维护工作可能会由一个平台团队承担，平台团队的责任是为开发团队提供基础设施构件。
为什么 Service A 团队要为 Service B 团队做这些工作？是出于无私吗？不是。他们之所以合作，是因为这样做对业务有价值。一个管理得当的组织秉持着 #OneTeam 的座右铭，组织会做出必要的事情，以高效和有效的方式运作。这意味着，Service A 团队有时必须为其他团队的利益做工作。这是因为上层管理层的激励目标对齐。
软件工程中也有一个众所周知的事实，那就是在开发周期的后期，或者更糟糕的是在生产环境中修复漏洞，远比在早期解决这些问题要昂贵得多。回到一周或一个月前的工作去修改问题，严重干扰了软件过程，而生产环境中的漏洞可能引发各种不良后果。提前做些工作，生产出设计良好、稳定的 API 会让每个人的生活更轻松。对此有一句话：“一盎司的预防胜过一磅的治疗。”
这些 API 是契约。它们通过在软件团队之间建立沟通来达成，并在明确 ROI（投资回报率）足够时进行实现。其实就这么简单。由于软件领导层的激励一致，通常在软件工程部门内部是这样运作的。
API（或应用程序编程接口）这个术语并不完全适用于“数据”。因为产品本身是数据，而不是某些业务逻辑之上的接口，所以“数据产品”这个术语更为恰当。单词“产品”也暗示着某种质量附带，某种程度的专业性和可靠性。这就是为什么数据契约与数据产品密切相关，数据产品是更抽象的数据契约的具象化体现。
数据产品与软件端的 REST API 非常相似。它归结为团队之间开启沟通渠道、严格规范数据形状（包括从查德的言论中提到的时区）、随着不可避免的变化小心演进，以及数据生产者承诺为消费者维护稳定的数据 API。不同之处在于，数据产品通常是表格或流（数据本身），而不是 HTTP REST API，后者通常驱动某些逻辑或每次调用时检索一个实体。
另一个关键的见解是，正如 API 使得服务以可预测的方式可重用，数据产品则使得数据处理工作更具可重用性。在软件领域，一旦“订单 API”发布，所有需要与订单子系统交互的下游服务都会通过该 API 进行操作。并不会为每个下游使用场景建立一堆一次性接口。然而，这正是我们在数据工程中常见的现象，即单次使用的管道和为不同使用场景复制的源数据。
简单来说，软件工程通过模块化（无论是实际的软件模块还是 API）促进了软件的可重用性。数据产品在数据方面也做到了这一点。
Shift Left 概念源于网络安全领域。安全 historically 也是另一个孤岛，软件团队和安全团队各自有不同的报告结构、工具、激励措施，并且共享的词汇极少。结果是，我们已习惯了日益严重的安全危机，以至于下一个百万级数据泄露事件几乎没有被报道。我们已对它麻木，以至于可能不会认为这是个危机，但当你看到勒索软件团伙、信息窃取者和勒索者留下的破坏痕迹时，很难说这应该当作日常业务来处理。
Shift Left 的理念是将安全关注点向左移，即将安全措施嵌入到软件开发的过程中，而不是由一个与正在开发、修改和部署的软件几乎没有关联的独立团队在事后应用。它不仅仅是将安全集成到开发过程中，更是关于提高网络遥测数据的质量。网络遥测的异质性和普遍的“混乱”促使了这一将处理、清理和上下文化工作移到数据产生源头的运动。一旦失去来源信息，推理这些数据就变得异常具有挑战性。虽然网络数据异常具有挑战性，但在这一领域的经验教训是可以推广到其他领域的，例如数据分析。
网络安全孤岛与数据分析孤岛的相似性令人震惊。孤岛假设孤岛功能可以作为一个独立的单元运作，与其他业务功能分离。然而，网络安全和数据分析都是跨职能的，它们必须与企业中的许多不同领域互动。跨职能团队不能在幕后、事后或者旁边运作。孤岛行不通，而 Shift Left 则是要推翻这些孤岛，并用一些更加嵌入在软件开发过程中、不那么集中化的方式替代它们。
Bernd Wessely 在 TowardsDataScience 上写了一篇关于“信息孤岛”问题的精彩文章。他在文中指出，数据分析孤岛问题已经根深蒂固，以至于当前的实践几乎没有受到质疑。他认为，由“先接收再处理”组成的数据孤岛，“只是一个不合适的数据管理方式的临时解决方案。这个临时解决方案是因为当前企业在处理数据时的方式完全不适当所必需的。”
可悲的是，这一切并不新鲜。我从职业生涯开始就一直在阅读关于打破信息孤岛的文章，然而我们依然在 2024 年讨论打破孤岛的必要性！但我们必须打破它们！
如果数据孤岛是那个与组织其他软件分离的集中式庞然大物，那么 Shift Left 就是要将数据基础设施集成到软件开发、运营所在的环境中。
服务 B 不仅仅是直接访问服务 A 的私有内部；相反，创建了一个接口，允许服务 A 在不违反封装的情况下从服务 B 获取数据。这个接口——无论是 API、队列还是流——成为了一种稳定的数据消费方式，不会因为每次服务 A 需要更改其隐藏的内部结构时而中断。提供该接口的责任落在了服务 A 的团队上，因为这是正确的解决方案，但这背后也有商业理由。同样的原则适用于 Shift Left；与其将使数据可用的责任放在需要使用数据的人身上，不如将这个责任上游，交给数据产生和维护的地方。
这个向左转变的核心是数据产品。无论是事件流还是 Iceberg 表格，数据产品通常最好由拥有底层数据的团队来管理。这样，我们就避免了那些临时的、仓促的解决方案，这些解决方案绕过了良好的实践。
为了实现这一目标，我们需要以下条件：
-
各方之间的沟通与协调。这需要一定的业务成熟度才能实现，但在我们做到之前，我们会在未来十年或二十年内继续谈论打破孤岛，或者直到人工智能取代我们为止。
-
使生产、维护和支持数据产品更加容易的技术解决方案。
我们看到这个领域正在发生许多变化，从目录、治理工具、表格格式（如 Apache Iceberg）到丰富的事件流选项。这里有大量的开源项目，也有大量的供应商。构建数据产品的技术和实践仍处于早期阶段，但预计这个领域将迅速发展。
你可能会认为大多数数据平台工程是在解决大规模的技术问题。不幸的是，再次是人与人之间的问题占据了主导地位。— Birdy
组织正在变成软件，而软件则根据业务的沟通结构进行组织；因此，如果我们想要解决软件/数据/安全孤岛问题，那么解决方案就在沟通结构中。
让数据分析在企业中更具影响力的最有效方法是解决康威定律问题。它导致了数据团队与更广泛的软件工程学科的文化和技术分离，以及沟通结构薄弱和缺乏共同理解。
结果是：
-
双方之间的合作与协调不良，导致了：
– 在操作层面（软件服务）和数据分析层面之间的混乱集成。
– 针对操作层面所做的更改，数据分析层面不断进行修复工作。
-
软件工程师用来使软件开发更具成本效益和可靠性的众多优秀实践往往被忽视。
实现更为一体化的软件和数据分析世界的障碍在于数据团队的持续孤立，以及激励机制的不对齐，这阻碍了软件团队和数据团队之间的合作。我相信，拥抱#OneTeam 的组织，能够让这两个团队进行对话、合作，甚至在某些程度上融合，将会看到最大的投资回报。一些组织可能已经这样做了，但这还远未普及。
事物在变化，态度也在变化。数据工程就是软件工程，数据契约/产品，以及向左转的兴起，都是重要的领先指标。