向软件工程师学习，发现“更糟糕就是更好”思维的乐趣

         欢迎来到雲闪世界。最近，我有幸与多位数据工程师和数据架构师交流了他们在业务中遇到的数据问题。我一次又一次听到的主要痛点是：

• 不知道为什么东西坏了
• 云计算成本高昂
• 构建数据解决方案/完成数据项目花费时间太长
• 需要掌握多种工具和技术的专业知识

这些问题并不新鲜。我经历过，你可能也经历过。然而，我们似乎无法找到一个长期解决所有这些问题的解决方案。你可能会想，“第一点可以用{插入数据可观察性工具}解决”，或者“第二点只需要制定更严格的数据治理计划”。这些解决方案的问题在于它们增加了额外的复杂性，这导致最后两个痛点的严重性增加。痛苦的总和保持不变，只是四个点之间的分布不同。

作者使用Google 表格创建

本文旨在提出一种相反的解决问题的方式：彻底简单。

总结

• 软件工程师通过拥抱简单性获得了巨大的成功。
• 过度设计和追求完美可能会导致数据系统臃肿、开发缓慢，并给企业带来高昂的成本。
• 数据团队应该考虑为了简单和速度而牺牲一些功能。

软件开发人员的教训

1989 年，计算机科学家Richard P. Gabriel写了一篇关于计算机系统的相对著名的文章，题目自相矛盾，叫做《更坏即更好》。它的基本信息是，随着功能的增加，软件质量并不一定提高。换句话说，有时，你可以为了简单而牺牲完整性，并因此得到一个本质上“更好”的产品。

对于 20 世纪 50 年代/60 年代的计算机先驱来说，这是一个奇怪的想法。当时的理念是：计算机系统需要纯粹，只有考虑到所有可能的情况，它才是纯粹的。这可能是因为当时大多数领先的计算机科学家都是学者，他们非常想把计算机科学当作一门硬科学来对待。

当时，计算机领域的领先机构麻省理工学院的学者们开始研究下一代计算机的操作系统Multics。经过近十年的开发和数百万美元的投资，麻省理工学院的研究人员发布了他们的新系统。毫无疑问，这是当时最先进的操作系统，但由于计算要求高，安装起来很麻烦，而且由于代码库庞大，功能更新速度很慢。因此，除了少数几所大学和行业外，它从未流行起来。

在 Multics 构建过程中，支持 Multics 开发的一个小团队对系统日益增长的需求感到沮丧。他们最终决定退出该项目。凭借这一经验，他们着眼于创建自己的操作系统，该系统具有根本性的哲学转变：

设计必须简单，无论是实现还是接口。实现的简单比接口的简单更重要。简单是设计中最重要的考虑因素。

— 理查德·P·加布里埃尔

Multics 发布五年后，该独立小组发布了他们的操作系统Unix。它缓慢但稳步地获得了关注，到 20 世纪 90 年代，Unix 成为计算机的首选，全球速度最快的 500 台超级计算机中有 90% 以上都在使用它。时至今日，Unix 仍然被广泛使用，最引人注目的是作为 macOS 的底层系统。

显然，除了简单性之外，还有其他因素导致了 Unix 的成功。但它的轻量级设计曾经是、现在仍然是该系统的一项非常宝贵的资产。这只能是因为设计者愿意牺牲功能性。数据行业不应该害怕以同样的方式思考。

回到21世纪的数据

回想我自己的经历，我参与过的大多数大数据工程项目的理念与 Multics 相似。例如，有一个项目需要我们自动标准化来自所有客户的原始数据。我们决定通过 dbt 在数据仓库中执行此操作，因为这样我们就可以全面了解从原始文件到标准化单表版本及以后的数据沿袭情况。问题在于，转换的第一阶段非常手动，它需要将每个单独的原始客户端文件加载到仓库中，然后 dbt 创建一个模型来清理每个客户端的文件。这导致需要生成数百个 dbt 模型，所有模型基本上都使用相同的逻辑。Dbt 变得非常臃肿，数据沿袭图表需要几分钟才能加载到 dbt 文档网站中，而我们的 GitHub Actions for CI（持续集成）需要一个多小时才能完成每个拉取请求。

如果领导层允许我们使用 AWS Lambda 和 Python 在数据仓库之外进行第一层转换，这个问题就可以相当简单地解决。但不，这意味着 dbt 生成的数据沿袭不会 100% 完整。就是这样。这就是不大规模简化项目的全部原因。与脱离 Multics 项目的团队类似，我在这个项目中途离开了，从事一件显然可以简单得多的事情实在是太令人沮丧了。在我写这篇文章的时候，我发现他们仍在从事这个项目。

那么，彻底简单到底是什么？

数据工程中的极简主义不是一种框架或数据堆栈工具包，而是一种思维框架。这种理念优先考虑简单、直接的解决方案，而不是复杂、包罗万象的系统。

这一理念的关键原则包括：

1. 极简主义：专注于提供最大价值的核心功能，而不是试图满足每一种可能的情况或要求。
2. 接受权衡：愿意牺牲一定程度的完整性或完美性，以换取简单性、速度和易于维护。
3. 实用主义而非理想主义：优先考虑能够有效解决实际业务问题的实用、可行的解决方案，而不是追求理论上完美但过于复杂的系统。
4. 减少认知负荷：设计更易于理解、实施和维护的系统和流程，从而减少跨多种工具和技术所需的专业知识。
5. 成本效益：采用更简单的解决方案，通常需要更少的计算资源和人力资本，从而降低总体成本。
6. 敏捷性和适应性：创建更容易随着业务需求的变化而修改和发展的系统，而不是僵化的、过度设计的解决方案。
7. 关注结果：强调最终结果和商业价值，而不是陷入数据流程本身的复杂性。

这种思维方式可能与添加更多工具、流程和层的现代数据工程解决方案直接相矛盾。因此，你要为自己辩护。在提出替代的、更简单的解决方案之前，请准备好深入了解手头的问题。这让我想起了这句话：

要让某件事情变得简单，要真正理解潜在的挑战并想出优雅的解决方案，需要付出很多努力。[…] 这不仅仅是极简主义或没有杂乱。它涉及挖掘复杂性的深度。要真正做到简单，你必须深入挖掘。[…] 你必须深刻理解产品的本质，才能摆脱不必要的部分。

— 史蒂夫·乔布斯

附注：请注意，采用彻底的简化并不意味着忽视新工具和先进技术。事实上，目前我最喜欢的数据仓库解决方案之一是使用名为duckDB的新开源数据库。看看吧，它很酷。

结论

软件工程历史的经验教训为当今的数据格局提供了宝贵的见解。通过采用彻底的简化，数据团队可以解决困扰现代数据解决方案的许多痛点。

不要害怕在数据团队中倡导彻底的简化。如果您看到精简和简化的机会，请成为变革的催化剂。简化之路并不容易，但潜在的回报可能是巨大的。