原文towardsdatascience.com/the-curse-of-conway-and-the-data-space-e3cba689a915?sourcecollection_archive---------4-----------------------#2024-10-25现代趋势如何追溯到康威定律https://medium.com/jvanlightly?sourcepost_page---byline--e3cba689a915--------------------------------https://towardsdatascience.com/?sourcepost_page---byline--e3cba689a915-------------------------------- Jack Vanlightly·发表于 Towards Data Science ·12 分钟阅读·2024 年 10 月 25 日–https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/c0fe5540e797849545f2f267be1b70b9.png图片由作者提供。由 Midjourney 生成并用 Krita 进行修饰本文最初发表于我的博客上https://jack-vanlightly.com。本文的灵感来源并延伸了 Bernd Wessely 在《数据架构经验教训》一文中的“警惕孤岛化专业化”部分Data Architecture: Lessons Learned*。它汇集了我观察到的几个趋势以及我在软件与数据团队分割两边工作二十年的经验所形成的个人看法。*康威定律“任何设计系统的组织广义定义都会产生一个结构其结构是该组织沟通结构的复制。”— Melvin Conway这一现象在全球范围内的数十万家组织中都有上演尤其在软件开发与数据分析团队之间的分裂中体现得尤为明显。这两组通常有不同的汇报结构直到或紧接着高层管理团队。这个问题如今已经存在并且只会不断加剧。Jay Kreps 五年前提到组织正在变成软件“问题不仅仅在于企业使用更多的软件而是越来越多的企业在软件中得以定义。也就是说一个企业执行的核心流程——从它如何生产产品到它如何与客户互动再到它如何提供服务——越来越多地在软件中被明确、监控和执行。” — Jay Kreps这一软件的有效性与组织的成功直接相关。如果软件存在功能障碍组织也会出现问题。反过来组织结构上的问题也会在软件中体现出来。这意味着一个想要在其领域中脱颖而出的公司可能会在执行上落后于竞争对手反应市场条件的速度也太慢。这样的情况已经被说了无数次但这依然是一个基本的真理。当“软件工程”团队和“数据”团队在各自的汇报结构中各自为政时就会产生一种悲剧性的喜剧局面最终最大输家是整个企业。变革的风正在吹起https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/0d2c8bdf201a3416e9b1fea510171c54.png图片由作者提供。由 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 的组织能够让这两个团队进行对话、合作甚至在某些程度上融合将会看到最大的投资回报。一些组织可能已经这样做了但这还远未普及。事物在变化态度也在变化。数据工程就是软件工程数据契约/产品以及向左转的兴起都是重要的领先指标。