首先要解决的重要问题：数据工程和软件工程有什么区别？两者非常相似，许多起源于软件工程的最佳实践对数据工程同样有效，只要它们的结构正确。在本文中，我将详细介绍几种软件工程最佳实践以及如何更好地创建和维护数据管道。在本文中，我们将特别关注管道，因为这是我们在Estuary关注的重点，这些原则也适用于大数据堆栈。这个讨论将是高层次的，虽然我自己不是软件工程师，但我希望你能从从属原则中获得战略和领导价值。软件工程与数据工程：异同数据产品和软件产品之间存在差异，其利益相关者也各不相同。通常，软件产品的构建涉及高技能团队之间的协作，这些团队需要将产品交付给不同的用户组，通常用于商业用途。例如，银行可能会为其客户创建一个移动应用程序。相比之下，数据产品往往存在于企业内部，利益相关者和参与者的范围从高技能工程师到需要利用数据完成工作的非技术专业人员。例如，同一家银行可能会为其客户创建不同的金融和人口统计数据产品，以服务于不同的安全、销售和战略职能。读者在阅读本文的过程中，会在数据空间中徘徊，可能并不需要在细节上强调两者的区别。读者只需要从业务的角度来审视数据和软件的区别。但从根本上说，数据工程和软件工程的实践基本相同，即可以编写、维护和部署代码来解决可重复的问题。正因为如此，一些有价值的软件工程最佳实践可以转化为数据工程最佳实践许多最新的数据趋势——例如数据网格和数据操作程序——以新的方式实施软件工程实践，并取得了可喜的成果。软件工程和数据工程的历史通过查看历史数据了解为什么这些数据最佳实践起源于软件工程，并了解为什么直到最近才将它们应用到数据工程中。当软件工程学科在1960年代首次得到认可时，软件创建是一种工程形式的想法引起了轰动。事实上，选择“软件工程”一词是为了鼓励从业者停下来并将科学原理应用到他们的工作中。在接下来的几十年里，软件工程师测试并改进了科学和机械工程中的原理。在1990年代，随着对软件需求的增加，整个行业落后于对软件不断增长的需求，导致了所谓的“应用程序开发危机”，促使软件工程师采用敏捷开发和相关实践，这意味着优先考虑快速生命周期迭代并将价值放在软件背后的人类系统上。众所周知，数据工程是一个相对年轻的领域。虽然绝大多数关于人类历史的数据已经存在，但关系数据库是在1970年代创建的。直到2000年代初，数据库仅限于一小部分管理员，而在IT中，数据基础设施通常作为具有许多组件的内部企业资源，是一个相对较新的发展（不可否认：一个快速变化的）），标题“数据工程师”起源于2010年代。总而言之，软件工程师已经工作了大约60年，他们今天仍在做大致相似的工作，在那段时间里，他们解决了很多问题。数据工程领域可以利用软件工程的这种优势。事不宜迟，这里有一些可以（并且应该）应用于数据管道的软件工程最佳实践。1.建立（更短的）生命周期软件或数据产品的生命周期包括规划、构建、文档、测试、部署和维护的循环过程。敏捷软件开发通过缩短开发生命周期来满足需求，同时持续迭代和改进产品。同样，可以（并且应该）为数据管道实施快速生命周期。在整个组织中，对新数据产品的需求将快速而频繁地出现，应为生命周期工作流程中的所有环节做好准备。计划：与利益相关者一起制定计划，以确保管道能够交付所需的产品。构建：根据不同的平台和接口构建流水线、编写规范或创建DAG。文档：记录管道，包括模式、元数据或书面文档（dbt文档是一个很好的例子，尽管数据堆栈的不同部分有不同的dbt文档）。测试：在部署之前测试管道-管道工具可能具有内置测试，或者您可以编写自己的测试。部署：部署管道。监控：查看错误警报并更新它们。迭代：随着用例的变化快速迭代，继续构建以前的管道和回收组件。将敏捷开发方法集成到数据中的概念是DataOps框架的重要组成部分，请参阅我关于此主题的完整文章。2.选择合适的抽象层次为了确保更紧凑的数据生命周期，不要迷失在技术实现的细节中是非常重要的。需要对技术的具体实现细节进行抽象。软件工程师对抽象的想法很满意，将信息简化为更通用的对象或系统，也可以将其视为泛化或建模。在软件工程中，相关的抽象层次通常存在于代码中。例如，函数式或面向对象的编程语言是有用的工具，但它们并没有透露如何使用它们的细节。在数据中，需要比代码更高的抽象级别，主要原因有两个：数据产品与其提供的业务用例之间的相互关系意味着需要以更“现实”的方式讨论数据。阐明这一抽象级别意味着建立一个通用的语义层，并有助于避免不同BI工具和用户组之间存在多个冲突的语义层。在数据利益相关者中发现了更广泛的技术层面，这意味着在谈论更技术性的东西（例如代码）时它不是很适用。对于数据管道，两个相关的抽象是：从一个系统摄取数据并将其推送到另一个系统的行为（术语捕获和物化在Estuary中使用，但语义不同）。在谈论使用“捕获”和“物化”等术语时，工程师和业务用户都需要统一管道的语义值（从系统X获取数据并将其推送到系统Y，以便Z得以实现）。3.创建一个声明式数据产品理解了上面的意思之后，你就抓住了重点，但这只是抽象讨论的延续，下面会进行更实质性的讨论。首先将数据视为产品，这是流行的数据网格框架的核心原则。数据即产品属于公司内的不同领域：具有不同技能的团队，共享数据的操作用例。数据即产品可以快速转换为多种形式的可交付成果，所有这些都由用例驱动。换句话说：它们是关于“做什么”，而不是“如何做”。软件工程与声明式编程并行运行，后者关注程序可以“做什么”，而不是命令式编程，后者关注任务应该“如何”完成。声明式编程是建立在命令式编程之上的抽象程序：在运行时，程序被编译以解决“如何做”的问题。声明式编程允许在运行时具有更大的灵活性，从而节省资源。此外，声明式编程更容易控制，更容易实现。Makepipelinesdeclarative：首先建立在pipeline的功能上，而不是pipeline的机制上，这样才能更好的支持“dataasaproduct”的文化理念。项目将从管道要交付的内容开始，比如特定的物化视图，并基于此设计管道。声明式管道方法可确保您不会迷失在技术细节中，也不会忽视数据的商业价值。4.预防故障在软件开发和数据管道中，故障是不可避免的。许多人从失败中吸取教训：试图修复灾难性的系统损坏，避免因中断而丢失进度或数据，或者避免放大低级错误。无论是在应用软件还是数据上下文中，都可以采用类似的预防性备份措施来防止故障的发生。一些重要的考虑需要添加到此，管道供应商将提供数据编排工具来实现这些功能。测试就像软件工程一样，测试是管道生命周期的一部分。除了部署前的全面手动测试外，还应编写自动化单元测试以密切关注生产中的管道。如何编写这些测试取决于平台的类型以及您如何与之交互。例如，如果您需要在您的管道中使用Airflow，您可以创建Python脚本来测试它们。或者，最好使用更强大的监视设置来捕获潜在问题。根据经验，数据管道应用的转换越多，需要的测试就越多。版本控制软件工程师使用版本控制（通常是Git）来协同工作并保留将软件回滚到以前版本的能力。如果您使用的是供应商的产品，它可能会提供GitOps工作流程，这意味着工程师可以使用Git在他们首选的开发环境中的管道上进行协作。然而，并不是每个人都这样做。即使无法在数据基础架构中使用Git，供应商也会启用备份管道的选项，因此请务必利用该功能。分布式存储和回填能力云托管和存储技术的出现降低了数据中断和数据丢失的风险，但并没有完全消除这些风险。数据基础设施应该是分布式的，即不同的组件应该分布到不同的服务器上，这样才能够容错。对风险的控制程度取决于云提供商及其选择的供应商。始终迭代软件工程最佳实践的最终策略是：当某些例程不起作用时进行迭代。现状和最佳实践总是在不断变化，这适用于软件工程和数据工程。最好的方法始终是在所有利益相关者的支持下，经过深思熟虑、安全地引入变革。从这些原则开始，相互合作以适应数据团队的系统和文化。始终关注那些积极的影响和需要改进的领域，并从那里采取行动。本文改编自Estuary的博客，我们的团队可以在LinkedIn上找到，源代码在GitHub上。衷心感谢BenHuberman的大力支持
