工程未来：数据、软件和人工智能的共同线索

原文：towardsdatascience.com/engineering-the-future-common-threads-in-data-software-and-artificial-intelligence-2aa46b262150

我注意到 IT 部门中存在过度专业化的持续趋势。然而，我在多年中学习到的一个关键教训是这种孤岛式专业化的负面影响。

虽然这主要是一个组织问题，但盲目接受供应商提供的专业平台产品的趋势也导致了我们企业架构中功能的重要重叠。medium.com/towards-data-science/avoid-building-a-data-platform-in-2024-56f0ee95da42。

如果你的业务是提供专业的 IT 解决方案平台，你当然可以从锐利的专业化中受益。

对于所有其他业务，我认为这需要得到纠正。

从孤岛到更好的协作

传统的软件应用工程、数据工程和人工智能/机器学习（AI/ML）目前形成了大的孤岛。

虽然不同的 IT 任务被认为在很大程度上是不同的，目标也不同，但实际上业务要求应用程序和人工智能/机器学习模型之间实现无缝的数据交换和集成。

我们需要从孤立的任务转向集成系统。

每个领域的工程师实际上都依赖于许多共享的实践，需要一种共同的语言和方法。数据管道现在必须支持实时模型推理；应用程序软件必须动态处理数据流；并且人工智能/机器学习模型必须无缝地融入实际应用中。

这些跨领域的互动应该重新定义每个领域工程师的孤岛角色，明确指出我们必须超越传统学科的界限。

当我在医疗保健行业工作时，我也观察到了过度专业化的相同问题。医生也只关注特定的器官或系统（例如，心脏病学家、神经学家）。这种过度专业化，虽然可以推进某些条件的治疗，但往往会导致一种碎片化的方法，可能会忽视患者的整体健康。这可能会使获得良好的全面建议变得非常困难。

然而，近年来医疗保健确实发生了重大转变：从孤岛思维转向更综合的整体方法。这一趋势强调跨学科合作，结合不同专业领域的知识以提高患者结果。

我们迫切需要在 IT 工程中进行同样的重新思考。

共同线索：连接学科的原理

当我回顾过去时，有一些关键原则脱颖而出，无论你是数据工程师、软件开发者还是 AI/ML 从业者。

显而易见的共同点包括编程能力、算法思维和问题解决以及正确处理数据结构。这些原则为所有工程师提供了一个共同的基础。

让我们看看一些更常见的线索。

模块化和可重用性

模块化多年来一直是软件架构的基石。

在数据工程中，这一原则同样至关重要。一个设计良好的数据管道必须是模块化的，以支持可重用的数据转换和易于调整的组件。尽管在应用开发中我们学会了以（微）服务的方式思考，这些服务有助于构建一个连贯的整体系统，但我们仍然缺乏构建数据管道的相同熟练度。相反，我经常听到不恰当的断言，数据工程不是软件工程。

对 Google 论文"机器学习系统中的隐藏技术债务"的分析清楚地表明，模型本身只是需要开发的整体 AI/ML 服务中的一小部分。大多数服务需要软件和数据工程知识才能正确集成到企业架构中。例如，特征工程实际上是 AI/ML 模型的数据工程，与传统数据仓库的 ETL 处理有许多共同之处。

当所有三个学科都追求模块化架构时，整合不同的系统以及跨领域重用组件变得更加容易。

版本控制和生命周期管理

在软件开发中，版本控制对于管理变更至关重要，这一原则同样适用于数据和 AI/ML 模型。数据版本化确保团队能够跟踪变更、维护血缘关系并保证可重复性。AI/ML 模型的实验跟踪和生命周期管理可以防止更新中断流程或在生产中引入意外的行为。

在所有领域对版本控制进行严格的处理确保了系统的干净同步，尤其是在我们的动态环境中，数据、代码和模型不断演变。这种需求反映在像 DevOps、MLOps 和 DataOps 这样的"*Ops"学科的兴起中，它们都旨在促进高质量软件产品的快速交付。

然而，这些重叠的学科会导致不必要的项目管理和工作流程开销。我们维护三个独立的、过度专业化的类似流程版本。一个能够跨越这些领域的统一方法将显著减少复杂性并提高效率。

实时处理和响应性

随着对低延迟处理需求的增加，传统的批处理系统已不再足够。今天的用户期望即时信息供应。这种向近实时响应性的转变需要新的集成水平。

对于数据工程师来说，实时处理意味着重新思考传统的 ETL 管道，转向更多事件驱动的架构，在数据创建时推送数据。软件工程师必须设计能够处理实时数据流的系统，通常需要集成 AI/ML 推理以提供个性化或上下文感知的响应。对于 AI/ML 工程师来说，这是构建具有最小延迟的模型。

不幸的是，我们仍然离统一批处理和流处理还有很长的路要走。

抽象的力量使跨职能系统成为可能

避免重叠功能的最强大工具之一是抽象。

每个领域都发展了自己的抽象概念——例如，在应用开发中，UX 原则如模型-视图-控制器 (MVC) 或前端后端 (BFF)，数据工程中的 ETL 管道编排，以及用于机器学习的神经网络层。

通过在共同抽象上构建系统，我们创造了一种可以在不同学科中理解的语言。

考虑像“数据即产品”这样的抽象概念如何可以作为共享语言。对于数据工程师来说，数据即产品是由应用程序创建的、定义良好的数据集，用于公开和传输给消费者。对于 AI/ML 实践者来说，它是一组为模型训练准备的特征集。对于软件工程师来说，它就像是一个 API 端点，为应用程序功能提供可靠的数据输入。通过创建和消费数据作为产品，每个团队都使用相同的语言，这促进了更好的理解。

操作系统 (OS) 一直是提供这种基本抽象的基础设施，使所有特定应用程序都能同等有效地工作。在我们创建新的、基本的抽象作为单一学科的专用工具之前，我们应该三思是否它不会更好地由基础设施组件覆盖——例如作为操作系统扩展。

拥抱反馈循环

随着学科之间的界限变得模糊，对反馈循环的需求变得至关重要。

数据、软件和 AI/ML 系统不再是静态的；它们在用户反馈和数据分析洞察的驱动下持续发展。这进一步缩小了开发和生产之间的差距，使系统能够随着时间的推移学习和适应。这种针对此类反馈循环的学科通常被称为“可观察性”。

在数据工程中，可观察性可能意味着监控数据流，允许持续的协作来提高准确性和可靠性。对于软件工程师来说，这可能意味着收集实时应用程序使用情况和用户反馈，以完善功能和用户体验。在机器学习（ML）中，反馈循环对于根据新的数据分布重新训练模型至关重要，确保预测保持相关性和准确性。

一个设计良好的反馈循环确保所有系统持续优化。这些循环还促进了跨职能学习，其中一个领域的见解直接转化为另一个领域的改进，从而形成一个增强和适应的良性循环。

简化你的招聘流程

不断增长的专业化反映了应对现代系统日益增长的复杂性的必要演变。

尽管专业化的学科可以带来显著的好处，但它们高度重叠的部分导致了协调和整合的挑战。那些通过依赖合理的架构原则、协作文化和统一战略来协调这些跨领域组织的组织将获得竞争优势。

你不需要你的企业架构的每个方面都有过度专业化的工程师。我们不可能只依靠少数有足够经验来监督跨学科方面的企业架构师就取得成功。强大的抽象不是通过生活在思维孤岛中产生的。必须鼓励工程师跳出思维定势，并理解在企业层面采用进化式架构的好处。

所有工程师都需要遵循合理的企业架构原则，而不仅仅是架构师。因此，确保你的 IT 工程师中有一批广泛的企业架构知识。

不要寻找一个对所有最新工具都了如指掌的高度专业化的 DevOps 工程师，寻找一个对软件工程了解很多并且懂得如何快速将软件投入生产同时保持最高质量的 IT 工程师。

向统一工程思维迈进

在我们设计未来时，很明显，我们的成功取决于在需要的地方弥合分离的学科。数据工程师、软件开发人员和 AI/ML 从业者必须采用统一的工程思维，接受共享的原则和实践，以创建满足业务跨领域需求的系统。

我坚信工程学的未来是一个协作的旅程。通过在一个共享框架内工作——模块化、版本控制、近乎实时的响应性和抽象——我们为集成系统奠定了基础。目标不是抹去各领域的区别，而是利用它们的独特优势超越任何单一学科的局限性。

成功将属于那些能够跨越边界、采用跨职能原则，并对他们构建的系统进行整体思考的人。通过以这些共同线索进行工程化，我们不仅提高了每个领域的效率，还促进了更大的跨领域创新和敏捷性。未来是相互关联的，而构建未来的道路始于接受 IT 工程中的共同原则。