今天，数据科学家和工程师需要做的任务范围是非常大的。在这篇文章中，你会发现对它的最好描述。人工智能的需求层次。在你开始研究真正的商业问题和建立有价值的数据产品之前，需要完成一长串的技术问题。 大部分时间都花在基础设施、数据安全、过渡、处理、存储、配置、测试和运营准备/健康上。
作为一个数据工程师，我需要一个单一的接口或操作系统，在分布式混合环境中提供可组合的能力，并可扩展到未来的实施。
给予这样一个工具，将有助于数据科学家和工程师保持对业务问题解决的关注，而不必潜心研究实施细节和操作准备的技术复杂性。
目标：为数据工程师创建一个统一的 数据管道 为数据工程师创建一个统一的协调界面。
什么是数据管道？
从用户和应用活动中得到的数据可以分为两组。
- 操作性 - 内部系统事件和指标。用于优化应用程序的性能和可靠性。
- 分析 - 用户在使用应用程序时创建的历史数据。用于优化用户体验。
这种衍生的数据带来了许多由服务运营商、数据工程师和分析人员创建的副产品，如KPI报告、监控仪表盘、机器学习模型等。为了创建这样的数据产品，需要从源头收集数据，进行清理，作为一个流进行处理，然后发送到一个汇，如 数据仓库或数据湖。
数据管道是一个术语，用于描述由读取、处理和存储任务组成的数据流，这些任务从一个或多个来源摄取、移动和转换原始数据到一个目的地。
每个元素代表一个任务，其资源负责管道主体中的一个目的。例如，一个源 - 提供从其他系统读取数据的能力。它可以是一个Kafka连接器，rest API轮询器，或webhook订阅器。它也可以是Linux操作系统中的一个简单的bash命令，但在高密集的大数据世界中，它也需要在分布式处理环境中配置资源。
该元素本身负责。
- 输入验证和接受（包括来自用户和其他元素）。
- 资源供应
- 任务和服务的执行
- 状态管理（调度、重试、错误处理）
- 输出的提供
它们之间也有依赖关系，单个命令或资源的输出应被引导为其他元素的输入。假设组件的生命周期由不同的状态组成（例如，供应、准备、健康、错误），其处理需要一个可以自动化的管理过程。
管道协调
单个组件本身并不能解决复杂的数据工程问题。例如：为了准备ML模型训练的数据，我们很可能需要从源头读取数据，验证和过滤不适用的异常值，用转换执行聚合，并将其发送到存储系统。编排是指从一个负责的块、元素或组件组成或构建复杂结构的过程。
协调层的能力。
- 将组件连接到工作流程/任务/步骤链中
- 将资源配置到下游系统中
- 输入/输出和状态管理
非功能性的能力
- 可扩展的
- 可观察的
- 混合环境下的分布式处理
一个类似的例子是系统命令行界面，它允许你通过管道将单个命令组合成一个功能链。命令本身在职责上有很大的限制，但遵循Unix哲学，相当稳定，性能很高。早期的操作系统终端是用户和技术之间沟通的唯一API或入口。今天，我们有同样的业务需求，但数据密集型的应用程序在分布式云环境中工作。
今天可用的协调产品
云原生计算基金会提供的AI&Data景观显示，今天有大量的工具可供数据工程师使用，如果我们还加上云供应商和SaaS公司的DevOps工具和服务，它就变得非常巨大。 我以后会回来对它们进行详细的分析和比较，也许，如果我有一台时间停止的机器:) 现在，让我们来看看Apache Airflow和Terraform，它们是工作流任务和基础设施协调方面最受欢迎的工具。
在Apache Airflow中，DAG（直接无环图）通常用于将任务连接到工作流中。这就解决了连接元素和定义依赖关系的问题，以后用于任务执行。但如何在外部系统中提供资源呢？这就是为什么Airflow的运营商有 很多供应商可用。这也解决了可扩展性的问题。
使用Terraform，DevOps工程师可以协调复杂的结构，并使用单一的API接口来配置它。与Phyton的Airflow命令式编程模型相比，声明式模型被用于创建作为代码的基础设施。与Airflow一样，有一个供应商委托和扩展机制，有很多供应商可用。
所有这些工具都有不同的接口，很难说是简单的。对于协调元素应该是什么样的，目前还没有一个统一的模型...
协调模型
利用这些协调工具，让我们试着定义协调组件的统一结构。
当我们想创建某个东西时，我们需要块。有很多词可以用于这样一个单一的构建单元：组件、任务、块、节点、对象、函数、实体、砖块、资源、原子、量子等等。以块作为主要的构建单元，在许多创造性的工程游戏中都有使用。例如，《Minecraft》、乐高积木或拼图。
让我们想象一下，我们有这样一个用于数据管道协调的元素。 它应该由什么组成？
JSON
{
"type": "source",
"version": "0.0.1",
"name": "exampleHttpSource",
"provider": "AWS",
"extension": "S3SourceExtension",
"state": "READY",
"configuration": {},
"outputs": {},
"dependsOn": []
}
类型- 是客户端的属性，帮助轻松定义元素的目的或行为（源、流、转换、汇、模式等）。
提供者--是一个云提供商、SaaS服务供应商或下游系统o，用于委托资源配置。
扩展--是一个具有所有资源创建逻辑的实现类。扩展的想法来自于微内核模式。
配置--是一个占位符，用于在下游系统中提供元素或执行命令所需的所有属性。
该元素的目的不仅是提供资源，而且还提供关于它的反馈。状态将显示它是否被成功创建，是否仍在进行中，或者是否发生了一些错误。
在元素生命周期的每一步，可能会产生一些输出，如ID、名称或错误信息。所有这些元信息都可以在输出部分找到。
元素中的信息应该足以让客户理解其目的和如何使用它。同时，封装在实施类和配置部分的技术规范将给提供者提供如何执行的指示。
如今，数据科学家的生活很辛苦，解决技术问题比解决业务问题需要更多时间。像Airflow和Terraform这样的协调工具帮助很大，然而，对于协调模型应该是什么样子，并没有一个统一的接口或标准。在这篇文章中，我分享了一个关于这种统一模型的想法。这可能对那些希望建立领域驱动的解决方案的数据工程师和架构师有帮助，因为他们要对快速增长和变化的开发环境进行抽象化和不可知。这并不是我们今天的问题的完整解决方案，而是对我们明天可以达到的目标的一种意向。
