在数据工程中追求极简风格

来源: unsplash(网站),

最近，我有机会与多位数据工程师和数据架构师交谈，他们反复提到的主要问题有：

• 不知道为什么某样东西坏了
• 被高昂的云计算成本烧到
• 花太多时间建立数据解决方案/完成数据项目
• 需要对许多工具和技术都很精通

这些问题并不新鲜。我经历过这些问题，你也可能经历过。然而，我们似乎找不到一个长期有效的解决方案来解决所有这些问题。你可能会想，“好吧，第一点可以用{插入某种数据可观测性工具}来解决”，或者“只需要一个更严格的数据治理计划就可以解决第二点问题”。这类解决方案的问题在于，它们增加了额外的复杂性，这使得最后两个痛点变得更加突出。总的痛苦并没有减少，只是在四个问题上的表现有所不同而已。

作者利用Google Sheets创建的这个

本文旨在提出一种截然不同的问题解决方式：激进的简单。

• 软件工程师在拥抱简洁方面取得了巨大成功。
• 过度复杂的设计和追求完美会导致臃肿、开发缓慢的数据系统，给企业带来高昂的费用。
• 数据团队应该为了简洁和速度而舍弃一些功能。

1989年，计算机科学家Richard P. Gabriel写了一篇相对著名的关于计算机系统的文章《更糟是更好》。这里就不详细介绍了，如果你想了解更多，可以在这里阅读原文here。但其核心信息是，软件质量不一定随着功能的增加而提升。换句话说，在某些情况下，可以通过简化功能来提高质量，反而能得到一个更好的产品。

在20世纪50至60年代，对计算机先驱们来说，这是一个奇怪的想法。当时的哲学是：计算机系统必须纯粹，只有考虑到所有可能的情况，才能保持纯粹。这可能是因为当时大多数领先的计算机科学家都是来自学术界，他们非常希望将计算机科学视为一门严谨的学科。

当时的计算领先机构麻省理工学院（MIT）的学者们开始为下一代计算机开发一个名为Multics的操作系统。经过近十年的发展和数百万美元的投资后，麻省理工学院的团队发布了他们的新系统。当时，它毫无疑问是最先进的操作系统，然而由于其高计算需求，安装起来非常麻烦，而且由于庞大的代码库，功能更新速度缓慢。因此，它从未真正流行起来，除了在少数几所大学和行业之外。

在 Multics 正在开发的过程中，支持 Multics 发展的一个小团队对系统需求不断增加感到沮丧。他们最终决定从项目中抽身。带着这次经历，他们着手开发自己的操作系统，一个具有根本哲学转变的系统：

设计必须在实现和界面两方面都简单。实现的简洁比界面更重要。在设计上，简洁性是最关键的考量。

——理查德·P·加贝尓

五年后，这个脱离的小组发布了他们的操作系统，Unix。慢慢地但稳定地，它逐渐获得了认可，并且到了1990年代，Unix已成为计算机界的首选，全球最快的500台超级计算机中有超过90%运行的是Unix。直到今天，Unix仍然被广泛使用，尤其是作为macOS的基础系统。

很明显，除了它的简洁性以外，还有其他因素促成了Unix的成功。但其轻量级的设计，至今仍然是该系统的一大宝贵资产。这只能是因为设计者愿意牺牲一些功能才能实现。数据行业也不应该害怕效仿这样的设计理念。

回想起来，我自己的经历，我参与的大多数大数据工程项目类似 Multics 的设计理念。例如，有一个项目需要自动化标准化所有客户的原始数据。我们决定通过数据仓库使用 dbt 来完成这一任务，因为我们能够从最初的原始文件追踪到标准化的单表版本，甚至更进一步。问题在于，第一阶段的转换非常手动，它需要将每个单独的原始客户文件加载到仓库中，然后 dbt 会为每个客户的文件创建一个模型进行清理处理。这从而产生了数百个 dbt 模型，所有模型基本上使用相同的逻辑。dbt 变得过于臃肿，以至于在 dbt 文档网站上加载数据血缘图需要几分钟，而且我们的 GitHub Actions 在处理每个拉取请求时需要超过一个小时。

这本可以通过相对简单的方式来轻松解决，如果领导允许我们在数据仓库之外，用AWS Lambda和Python进行首次转换。但是不行，那样的话，由dbt生成的数据血统将无法保持100%的完整性。就这样，这就是整个项目不能大幅度简化的原因。处理这样一个本可以如此简单的项目实在是令人沮丧，就像那些从Multics项目中脱离出来的团队一样，我也在项目进行到一半时离开了。当我写下这段话时，发现他们仍在继续进行这个项目。

数据工程中的真正极简主义不是一种框架或数据栈工具包，而是一种心态。这样的态度就是一种哲学，它更偏好简单直接的解决方案，而不是复杂的全面系统。

该哲学包括一些关键原则：

1. 极简主义：专注于提供最大价值的核心功能，而不是试图适应每个可能的场景或需求。
2. 接受权衡：为了简单、速度和易于维护，愿意牺牲一些完整性和完美的程度。
3. 实用主义胜于理想主义：优先考虑实际可行的解决方案，高效地解决真实商业问题，而不是追求理论上完美但过于复杂的系统。
4. 减轻认知负荷：设计易于理解、实施和维护的系统和流程，从而减少在多个工具和技术上的专长需求。
5. 成本效益：采用通常需要较少计算资源和人力资本的简单解决方案，从而降低成本。
6. 灵活性和适应性：构建易于修改和演化的系统，以适应业务需求的变化，而不是僵硬且过度工程化的解决方案。
7. 重视成果：强调最终结果和商业价值，而不是纠结于数据流程本身的复杂性。

这种心态可能与现代数据工程中不断增加工具、流程和层次的做法直接矛盾。因此，准备好为你的观点辩护。在提出一个更简单、更有效的解决方案前，必须先深入理解问题。这让我想起了下面这句话：

要让某事变得简单，需要付出巨大的努力，真正理解其中的挑战，并找到简洁而优雅的解决方案。 […] 简洁不仅仅是极简主义或消除杂乱，而是要深入复杂性，挖掘其本质。要真正简单，你必须深入研究。 […] 你必须深刻理解产品的本质，才能去掉那些不必要部分。

—— 史蒂夫·乔布斯

附注：采用极简风格并不意味着忽视新的工具和技术进步。实际上，我目前最喜欢的数据仓库解决方案之一是使用一个名为duckDB的新开源数据库。了解一下，它相当不错。

软件工程历史给我们提供了宝贵的教训，这表明对于今天的数据环境有着重要的意义。通过拥抱简约，数据团队可以解决现代数据解决方案中常见的问题，这有助于缓解许多困扰现代数据解决方案的痛点。

不要害怕在你的数据团队中推动激进的简约。如果你看到简化的机会，就要成为推动变革的人。走向简约的道路并不容易，但潜在的回报可能非常丰厚。