原文towardsdatascience.com/radical-simplicity-in-data-engineering-86ec3d2bd71c?sourcecollection_archive---------4-----------------------#2024-07-26向软件工程师学习发现“差的就是更好的”思维方式的乐趣https://medium.com/caiparryjones96?sourcepost_page---byline--86ec3d2bd71c--------------------------------https://towardsdatascience.com/?sourcepost_page---byline--86ec3d2bd71c-------------------------------- Cai Parry-Jones·发布于 Towards Data Science ·6 分钟阅读·2024 年 7 月 26 日–https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/9427c6236c0c26ea78735c52b9b205e6.png来源unsplash.com最近我有幸与许多数据工程师和数据架构师交流了他们在企业中遇到的数据问题。我一次又一次听到的主要痛点包括不知道为什么某些东西坏了遇到高昂的云计算成本构建数据解决方案/完成数据项目的时间过长需要精通许多工具和技术这些问题并不新鲜。我自己遇到过你也许也遇到过。然而我们似乎无法找到一种能从长远解决所有这些问题的方案。你可能会心想“第一个问题可以用{插入数据可观测性工具}来解决”或者“第二个问题只需要一个更严格的数据治理计划”。这些解决方案的问题在于它们增加了额外的复杂性这使得最后两个痛点变得更加严重。痛苦的总和保持不变只是四个痛点之间的分布不同。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/a8dc96143f25d0bb69eacb1128c1193a.png作者使用 Google Sheets 创建本文旨在提出一种相反的解决问题方式激进简化。总结软件工程师们在拥抱简化方面取得了巨大的成功。过度工程化和追求完美可能会导致臃肿、开发缓慢的数据系统并且给企业带来高昂的成本。数据团队应考虑为了简化和加速牺牲一些功能。从那些软件工程师那里学到的一课1989 年计算机科学家理查德·P·加布里埃尔写了一篇相对著名的文章标题是《‘Worse Is Better’》。我不会深入讲解如果你感兴趣可以在这里阅读文章但文章的核心信息是软件质量不一定随着功能的增加而提升。换句话说有时你可以为了简洁性牺牲完整性最终因为简化而获得一个本质上“更好”的产品。对于 1950/60 年代的计算机先驱们来说这个想法是非常陌生的。那个时代的理念是计算机系统必须纯粹只有在考虑了所有可能的情境下它才能称为纯粹。这很可能是因为当时大多数领先的计算机科学家都是学术界人士他们非常希望将计算机科学视为一门严谨的学科。当时计算机领域的领先机构麻省理工学院MIT的学者们开始着手开发下一代计算机操作系统名为Multics。经过近十年的开发和数百万美元的投资MIT 的团队发布了他们的新系统。毫无疑问这是当时最先进的操作系统然而由于计算要求高安装非常困难而且由于代码库庞大功能更新缓慢。因此它仅在少数几所大学和行业中获得应用。在 Multics 开发的同时支持 Multics 开发的小组对于系统日益增长的要求感到沮丧。他们最终决定脱离这个项目。凭借这些经验他们开始着手创建自己的操作系统这个操作系统有着根本性的哲学转变设计必须简单无论是实现还是界面。实现的简单性比界面的简单性更为重要。简洁性是设计中最重要的考虑因素。— 理查德·P·加布里埃尔在 Multics 发布五年后这个脱离小组发布了他们的操作系统Unix。它缓慢而稳步地获得了认可到 1990 年代Unix 成为了计算机的首选操作系统全球前 500 强超级计算机中超过 90%使用了 Unix。直到今天Unix 仍然被广泛使用最著名的是作为 macOS 的底层系统。显然除了简洁性之外还有其他因素促成了 Unix 的成功。但其轻量级设计是该系统至今依然极为宝贵的资产。这一切的实现归功于设计师们愿意牺牲一些功能性。数据行业不应害怕以同样的方式思考。回到 21 世纪的数据回想我自己的经历我参与的大多数大数据工程项目的哲学与 Multics 项目类似。例如有一个项目我们需要自动化地标准化从所有客户处获取的原始数据。我们决定通过数据仓库使用 dbt 来完成因为这样我们就可以全面查看数据的血缘关系从最原始的文件一直到标准化的单一表格版本及之后的内容。问题是第一阶段的转换非常手动必须将每个原始客户文件单独加载到仓库中然后 dbt 为每个客户的文件创建清理模型。这导致需要生成数百个 dbt 模型所有模型本质上使用相同的逻辑。dbt 变得过于臃肿以至于在 dbt 文档网站上加载数据血缘图表需要几分钟时间而我们的 GitHub Actions 进行 CI持续集成每次拉取请求都需要超过一个小时才能完成。如果领导层允许我们在数据仓库之外进行第一层转换使用 AWS Lambda 和 Python这个问题本可以相对简单地解决。但没有这样的话dbt 生成的数据血缘图就不能做到 100%的完整性。仅此而已。这就是不大幅简化项目的唯一理由。就像从 Multics 项目中脱离出来的小组一样我在项目中途离开了因为在一个显然可以更简单的项目上工作实在太令人沮丧了。当我写这些时我发现他们仍然在继续做这个项目。那么激进简化到底是什么呢数据工程中的激进简化并不是一种框架或数据栈工具集而是一种心态。这是一种哲学优先考虑简单、直接的解决方案而不是复杂的、包罗万象的系统。这种哲学的关键原则包括极简主义专注于提供最大价值的核心功能而不是试图满足每一个可能的场景或需求。接受权衡愿意在简化、速度和维护方便性上牺牲一定的完整性或完美性。实用主义胜过理想主义优先考虑能够高效解决实际业务问题的可行解决方案而不是追求理论上完美但过于复杂的系统。减少认知负担设计易于理解、实施和维护的系统和流程从而减少在多个工具和技术中的专业知识要求。成本效益拥抱更简单的解决方案这些解决方案通常需要更少的计算资源和人力资本从而降低整体成本。敏捷性与适应性创建更容易修改和发展的系统以应对业务需求的变化而不是僵化的、过度设计的解决方案。专注于结果强调最终成果和业务价值而不是陷入数据处理过程的复杂细节中。这种思维方式可能与现代数据工程解决方案中的增加更多工具、流程和层级相矛盾。因此你应该做好准备为自己的立场辩护。在提出替代、更简单的解决方案之前要深入理解当前的问题。我想起了这句名言要把事情做得简单需要付出大量的努力真正理解潜在的挑战并提出优雅的解决方案。[…] 这不仅仅是简约主义或去除杂乱它涉及深入挖掘复杂性的深度。要做到真正的简单你必须深入其中。[…] 你必须深刻理解产品的本质才能去除那些非必要的部分。— 史蒂夫·乔布斯旁注要注意采纳极简主义并不意味着忽视新工具和先进技术。事实上我目前在数据仓库方面最喜欢的解决方案之一是使用一个名为duckDB的开源数据库。看看吧它相当酷。结论软件工程历史中的教训为今天的数据领域提供了宝贵的见解。通过拥抱极简主义数据团队可以解决许多困扰现代数据解决方案的痛点。不要害怕在数据团队中倡导极简主义。如果你发现有机会精简和简化成为变革的催化剂。通往简化的道路并不容易但潜在的回报可能是巨大的。