公司和云复杂性的现实要求新的控制和自治级别以实现规模化的业务目标
随着数据团队在云上的规模扩大，数据平台团队需要确保他们负责的工作负载能够满足业务目标。随着数十个数据工程师构建数百个生产作业，从技术到人员的种种原因，控制他们的性能规模是不可行的。
今天的缺失环节是建立一个闭环反馈系统，帮助自动推动管道基础设施朝着业务目标的方向发展。这个问题有点复杂，让我们深入探讨一下这个问题。
数据平台团队面临的问题
数据平台团队必须管理来自管理层到工程师的基本不同的利益相关者。往往情况是这两个团队有着相反的目标，平台经理可能会受到双方的压力。
我们与平台经理和数据工程师进行的真实对话通常是这样的：
“我们的首席执行官希望我降低云成本，并确保我们的服务级别协议得到满足，以让我们的客户满意。”
好的，那问题是什么？
“问题是我实际上不能直接改变任何东西，我需要其他人的帮助，这就是瓶颈。”
所以基本上，平台团队发现自己被限制，并在试图实施改进时面临巨大的摩擦。让我们深入了解其中的原因。
是什么阻碍了平台团队的发展？
- 数据团队超出技术范畴 – 调整集群或复杂配置（Databricks、Snowflake）是一项耗时的任务，数据团队更愿意专注于实际的管道和SQL代码。许多工程师没有这方面的技能、支持结构，甚至不知道他们的作业成本是多少。识别和解决根本原因问题也是一项艰巨的任务，妨碍了构建一个功能性管道。
- 抽象层次过多 – 让我们只关注一个堆栈：Databricks运行他们自己的Apache Spark版本，该版本运行在云提供商的虚拟计算上（AWS、Azure、GCP），具有不同的网络选项和不同的存储选项（DBFS、S3、Blob），而且所有这些都可以独立和随机地在一年中进行更新。可选择的数量令人不知所措，平台人员无法确保一切都是最新和最优的。
- 遗留代码 – 不幸的是，现实情况是遗留代码。公司中的团队经常发生变动，人来人往，随着时间的推移，对任何一个特定作业的了解可能会逐渐消失。这种情况使调整或优化特定作业变得更加困难。
- 变化是令人担忧的 – 对于变化存在固有的恐惧。如果一个生产作业在顺利进行，我们是否愿意冒险进行调整？一句老话闪现在脑海中：“不坏就不需要修理。”往往这种恐惧是真实的，如果一个作业不是幂等的，或者存在其他下游影响，一个失败的作业可能会带来真正的麻烦。这为改进作业性能甚至尝试性能提供了心理障碍。
- 规模化时作业太多 – 通常情况下，平台经理需要监督数百甚至数千个生产作业。未来公司的增长会确保这个数字只会增加。考虑到以上所有因素，即使你有一个本地专家，逐个调整作业是不现实的。尽管对于一些高优先级的作业可以这样操作，但公司的大部分工作负载基本上无人管理。
显然，对于数据平台团队来说，在规模上快速使系统更高效是一场艰苦的战斗。我们相信解决方案是管道构建方式的范式转变。管道需要一个闭环控制系统，能够不需要人的干预不断推动管道朝着业务目标发展。让我们深入了解一下。
管道的闭环反馈控制意味着什么？
今天的流水线是所谓的“开环”系统，工作只是在没有任何反馈的情况下运行。为了说明我的观点，下图显示了“作业1”每天都运行，每次运行的成本为50美元。假设业务目标是让该作业的成本降低到30美元。嗯，除非有人真正采取行动，否则这个成本将在可预见的未来保持在50美元的水平，如成本与时间的图表所示。
如果我们有一个系统，可以实际反馈作业的输出统计数据，以便改进第二天的部署，会是什么样子呢？它会是这样的：
你在这里看到的是一个经典的反馈循环，这种情况下期望的“设定点”是30美元。由于这个作业每天都会运行，我们可以获取实际成本的反馈，并将其发送到一个“更新配置”块，该块接收成本差异（在这种情况下为20美元），并且会对“作业1”的配置进行更改。例如，“更新配置”块可以减少Databricks集群中的节点数量。
这在实际中是什么样子？
实际上，这不是一次性的。现在，“更新配置”模型负责调整基础架构，以尝试将成本降低到30美元。可以想象，随着时间的推移，系统将改进，并最终达到期望的30美元成本，如下图所示。
这听起来可能很好，但你可能会疑惑，“这个神奇的‘更新配置’块是什么？”嗯，那就是实现目标的关键。该块是一个数学模型，可以输入一个数值目标差值，并输出基础架构配置或代码更改。
这并不容易，而且会根据目标（例如成本、运行时间、利用率等）而有所不同。该模型必须从根本上预测基础架构变化对业务目标的影响——这并不容易。
没有人可以预测未来
一个微妙的问题是，“更新配置”模型并不是100%准确的。在第4个蓝点中，你实际上可以看到成本曾经上升过。这是因为该模型试图预测会降低成本的配置变化，但由于没有任何东西可以以100%的准确性进行预测，有时候它会在局部上出错，因此成本可能在单次运行时上升，而系统正在“训练”中。
但是，随着时间的推移，我们可以看到总成本实际上是下降的。你可以将其视为一个智能的试错过程，因为以100%的准确性预测配置变化的影响是不可能的。
重要的是什么？-设定任何目标并开始
上述方法是一种通用的策略，不仅限于成本节约。上面的“设定点”只是一个数据平台人员设定的目标。它可以是任何可衡量的目标，例如运行时间就是一个很好的例子。
假设我们希望作业的运行时间在1小时之内（或者是服务级别协议）。我们可以让上述系统调整配置，直到达到服务级别协议。或者如果情况更复杂，同时有成本和服务级别协议的目标呢？完全没有问题，该系统可以通过多个参数进行优化，以达到你的目标。除了成本和运行时间，其他业务用例的目标还有：
- 资源利用率：独立于成本和运行时间，我是否正确使用了我的资源？
- 能源效率：我是否尽可能少地消耗资源，以减少碳排放？
- 容错性：我的作业是否真的具有容错性？这意味着我是否要超额配置它，以防被抢占，或者以防没有可用的 SPOT 实例？
- 可扩展性：我的作业是否具有可扩展性？如果输入数据增加了10倍，我的作业会崩溃吗？
- 延迟：我的作业是否达到了延迟目标？响应时间目标？
从理论上讲，数据平台的人只需要设定目标，然后一个自动系统就可以迭代地改进基础设施，直到达到目标。其中没有人类参与，也没有工程师需要加入。平台团队只需设定他们从利益相关者那里获得的目标。听起来像是一个梦想。
到目前为止，我们一直都很抽象。让我们深入一些具体的用例，希望能够说服人们：
示例功能＃1：按业务目标分组作业
假设你是一个数据平台经理，负责管理数百个生产作业的运行。目前，它们都有自己的成本和运行时间。下面的简单图表显示了一个卡通示例，其中基本上所有作业都随机分布在成本和运行时间的图表上。
如果你想要在规模上降低成本怎么办？如果你想要同时改变许多作业的运行时间（或SLA）怎么办？目前你会被迫恳求工程师帮助你修改所有作业（祝你好运）。
现在想象一下，如果你的所有作业都实现了上述的闭环控制系统。你只需要设定作业的高级业务目标（在这种情况下是SLA运行时间要求），反馈控制系统会尽力找到能够实现你目标的基础设施。最终的状态将如下所示：
在这里，我们可以看到每个作业的颜色代表了不同的业务目标，由SLA定义。背后的闭环反馈控制系统会更改群集/仓库大小、各种配置，甚至调整整个流水线，以尽力在最低成本下达到SLA运行时间的目标。通常，较长的作业运行时间会带来较低的成本机会。
示例功能＃2：自愈作业
正如大多数数据平台人员可以确认的那样，他们的数据流程中的事物总是在变化。其中两种非常常见的情况是：数据规模随时间增长和代码更改。这两种情况都可能导致成本和运行时间的不稳定行为。
下面的插图显示了基本概念。让我们从左到右分析一下示例：
- 开始：假设你有一个作业，随着时间的推移，数据规模增长。通常情况下，你的群集保持不变，导致成本和运行时间都增加。
- 开始反馈：随着时间的推移，运行时间接近SLA要求，反馈控制系统在绿色箭头处启动。此时，控制系统会更改群集以保持在红色虚线下，同时使成本最小化。
- 代码更改：在某个时刻，开发人员推送了一个新的代码更新，导致成本和运行时间激增。反馈控制系统会启动并调整群集，以更好地与新的代码更改配合工作。
希望这两个示例能解释闭环控制流程的潜在好处。当然，在现实中，会有很多细节被忽略，并且公司将不得不遵循一些设计原则。
其中一个重要的问题是配置可以在出现问题时恢复到先前的状态。如果需要多次迭代，幂等流程将非常理想。
结论
数据流水线是复杂的系统，就像其他复杂的系统一样，它们需要反馈和控制以确保稳定的性能。这不仅有助于解决技术或业务问题，还将大大帮助释放数据平台和工程团队的精力，使其专注于实际构建流水线。
正如我们之前提到的，很多问题关键在于“更新配置”块的性能。这是反馈循环成功所需的关键智能组件。构建这个块并不是一件轻松的事情，它是当前的主要技术障碍。它可以是一个算法或一个机器学习模型，并利用历史数据。这是我们在过去几年中一直在努力解决的主要技术组成部分。
在我们的下一篇文章中，我们将展示这个系统应用于Databricks Jobs的实际实现，这样你就可以相信我们所说的是真实的！
如果您对关闭循环控制Databricks流水线的更多信息感兴趣，请联系Jeff Chou和Sync团队的其他成员。