本文主要分享 Datacake 在大数据治理中，AI 算法的应用经验

　　本文主要分享 Datacake 在大数据治理中，AI 算法的应用经验。本次分享分为五大部分，第一部分阐明大数据与 AI 的关系，大数据不仅可以服务于 AI，也可以使用 AI 来优化自身服务，两者是互相支撑、依赖的关系；第二部分介绍利用 AI 模型综合评估大数据任务健康度的应用实践，为后续开展数据治理提供量化依据；第三部分介绍利用 AI 模型智能推荐 Spark 任务运行参数配置的应用实践，实现了提高云资源利用率的目标；第四部分介绍在 SQL 查询场景中，由模型智能推荐任务执行引擎的实践；第五部分展望了在大数据整个生命周期中，AI 的应用场景。

　　普遍观念认为，云计算收集存储海量数据，从而形成大数据；再经过对大数据的挖掘学习，进一步形成 AI 模型。这种观念默认了大数据服务于 AI，但忽视了其实 AI 算法也可以反哺于大数据，它们之间是一个双向、互相支撑、依赖的关系。

　　大数据的全生命周期可以分成六个阶段，每个阶段都面临一些问题，恰当地使用 AI 算法有助于这些问题的解决。

　　数据采集：这个阶段会比较关注数据采集的质量、频率、以及安全性，例如采集到的数据是否完整，采集数据的速度是否过快或者过慢，采集的数据是否经过脱敏或者加密等。这时候 AI 可以发挥一些作用，比如基于同类应用来评估日志采集的合理性、使用异常检测算法来发现数据量暴增或骤减等情况。

　　数据传输：这个阶段比较关注数据的可用性、完整性和安全性，可以使用 AI 算法来做一些故障的诊断和入侵检测。

　　数据存储：这个阶段比较关注数据的存储结构是否合理、资源占用是否足够低、是否足够安全等，同样可以用 AI 算法来做一些评估以及优化。

　　数据处理：这个阶段是影响及优化收益最明显的一个阶段，其核心问题就是提高数据的处理效率且降低资源的消耗，AI 可以从多个着手点进行优化。

　　数据交换：企业之间的合作越来越多，这就会涉及到数据的安全性问题。算法在这方面也可以得到应用，比如时下热门的联邦学习就可以帮助更好更安全地进行数据的共享。

　　数据销毁：数据不可能只存不删，这就需要考虑什么时候可以去删数据、是否有风险。在业务规则的基础上，AI 算法可以辅助判断删除数据的时机及关联影响。

　　整体来看，数据生命周期管理有三大目标：高效、低成本，以及安全。以往的做法是依靠专家经验来制定一些规则策略，其弊端非常明显，成本高、效率低人工智能ai绘画。恰当地采用 AI 算法可以避免这些弊端，反哺于大数据基础服务的建设。

　　在大数据平台上，每天运行着成千上万的任务。但是很多任务仅停留在能正确产数阶段，对于任务的运行耗时、资源消耗等并未给予关注，导致很多任务存在效率低下、资源浪费的情况。

　　即使有数据开发者开始关注任务健康度，也很难准确的评估任务究竟健康与否。因为任务相关的指标非常多，失败率、耗时、资源消耗等，况且不同任务的复杂度及处理数据的体量存在天然差别，因此简单选择某项指标的绝对值作为评估标准显然是不合理的。

　　没有量化的任务健康度，就很难确定哪些任务不健康、需要治理，更不知道问题在哪里、从哪着手治理，即使治理完也不知道效果如何，甚至出现某项指标提升但别的指标恶化的情况。

　　需求：面对上述难题，我们急需一种量化指标来准确反映任务的综合健康状况。人工制定规则的方式效率低且不全面，因此考虑借助机器学习模型的力量。目标是模型能给出任务的量化评分及其在全局分布中的位置，并且给出任务的主要问题及解决方案。

　　对此需求，我们的功能模块方案是，在管理界面显示 owner 名下所有任务的关键信息，如评分、任务成本、CPU 利用率、内存利用率等。这样任务的健康度一目了然，方便后续由任务 owner 去做任务的治理。

　　其次，评分功能的模型方案，我们是把它作为一个分类问题来处理。直观来看，任务评分显然是一个回归问题，给出的应该是 0 到 100 之间的任意实数。但这样的话就要求有足够多的带评分的样本，人工标注成本高且不可靠。

　　因此我们考虑将问题转化为分类问题如何看待人工智能，分类模型给出的类别概率可以进一步映射为实数分值。我们将任务分为好任务 1 和坏任务 0 两类，由大数据工程师标注。所谓好任务，通常是指同等任务量与复杂度的情况下，耗时短、资源消耗少的任务人工智能ai绘画。

　　首先是样本准备，我们的样本来自于历史运行的任务数据，样本特征包括运行时间、使用的资源、是否执行失败等等，样本标签是由大数据工程师根据规则或经验标注成好、坏两类。然后就可以训练模型了，我们先后尝试过 LR、GBDT、XGboost 等模型人工智能ai绘画，理论及实践均证明 XGboost 具有更好的分类效果如何看待人工智能。模型最终会输出任务为“好任务”的概率，该概率越大，最终映射出的任务评分就越高。

　　经过训练之后，从最初将近 50 个原始特征里面筛选出 19 个特征，这 19 个特征基本上能够决定一个任务是否是一个好的任务。比如失败次数多的任务、资源利用率低的任务，大部分得分不会太高，与人工的主观感受基本一致。

　　使用模型对任务打分后可以看到，在 0 到 30 分以下属于不太健康的、急需要治理的任务；30 到 60 之间的是健康度尚可的任务；60 分以上的是健康度比较好的，需要保持现状的任务。这样有了量化指标，就可以引导任务 owner 去积极地做一些任务的治理，从而实现降本增效的目标。

　　① 首先，任务 owner 对其名下任务的健康度可以做到心中有数，通过分数、排名就能够知道任务是否需要治理；

　　第二个应用场景是 Spark 任务的智能调参。Gartner 的一项调研揭示，云用户消耗的 70% 的云资源都存在不必要的浪费。在申请云资源时，很多人为了确保任务的成功执行，可能会去多申请一些资源，这就会造成不必要的浪费。还有很多人在创建任务时采用了默认配置，但其实这并不是最优配置。如果能够认真配置，可以达到非常好的效果，既能保证运行效率，又能保证运行成功，同时还能够节省很多的资源。但任务参数配置对用户有很高的要求，除了了解配置项的含义，还需要考虑配置项之间的关联影响。即使依赖专家经验也很难达到最优，而且规则类的策略难以动态调整。

　　这就提出一个需求，希望由模型智能地推荐出任务运行最优的参数配置，使得在保持任务原有运行时间不变长的前提下，提高任务云资源的利用率。

　　对于任务调参功能模块，我们设计的方案包含两种情况：第一种是对于已经在线上运行了一段时间的任务，模型要能够根据任务历史运行情况推荐出最合适的配置参数；第二种情况是对于用户还没上线的任务，模型要能够通过对任务的分析给出合理的配置。

　　接下来就是训练模型了，首先要确定模型的输出目标。可配置项有三百多条，不可能都由模型给出。经过测试与调研，我们选择了三项对任务运行性能影响最大的参数，分别是执行器 executor 的 cores 核心数、memory 内存总量、instances 实例个数。每个配置项都有其默认值及可调范围，其实就是给定了一个参数空间，模型只需要在这个空间里去寻找最优解即可。

　　训练阶段，有两种方案来进行。方案一是学习经验规则：前期采用规则的方式推荐参数，上线之后效果还不错，因此先让模型来学习这套规则，从而达到快速上线的目标。模型训练样本是之前根据规则计算出来的七万余条任务配置，样本特征是任务的历史运行数据（比如任务处理的数据量、资源的使用量、任务耗时等），以及一些统计信息（比如过去七日的平均耗量、最大耗量等）。

　　基础模型我们选择了多因变量的多元回归模型。常见的回归模型是单输出的，有很多自变量但只有一个因变量。这里我们希望能输出三个参数，所以采用的是多因变量的多元回归模型，它的本质还是一个 LR 模型。

　　上图展示的是这个模型的理论基础如何看待人工智能。左侧是一个多标签，就是三个配置项，β 是每个特征的系数，Σ 是误差。训练方式和一元回归一样，用最小二乘法去做估计使得 Σ 中各元素的平方和达到最小。

　　方案一的好处，就是能快速学到规则经验，成本也是比较小的。缺陷是其优化上限最多能达到和规则一样好的效果，但如果想超过会比较困难。

　　第二种方案是贝叶斯优化，其思路和强化学习比较类似，通过在参数空间里做尝试寻找最优配置。这里采用了贝叶斯框架，原因是其能够利用上一次尝试的基础，在下次尝试时就会有一些先验的经验，能够快速找到较优位置。整个训练过程会在一个参数空间里面进行，随机采样一种配置来做验证，然后去运行；运行之后会关注一些指标，比如使用率、成本等，判断是不是最优；然后重复以上步骤，直到调优完成。模型训练好后，在使用过程中也有一个取巧的过程，假如新任务和历史任务有一定的相似度，就不需要再去计算一遍配置，直接采用以往的最优配置即可。

　　经过这两种方案的尝试和实践，能够看到取得了一定的效果。对于已有的任务如何看待人工智能，按照模型推荐的配置参数来做修改后，80% 以上的任务能够实现大概 15% 的资源利用率的提升，部分任务资源的使用率甚至是翻倍的。但这两种方案其实都存在缺陷：学习规则的回归模型，其优化上限较低；全局寻优的贝叶斯优化模型，缺点是要做各种尝试，成本太高。

　　语义分析：Spark 语义是比较丰富的，包含不同的代码结构和算子函数，其与任务参数配置、资源消耗息息相关。但是目前我们利用的只是任务的历史运行情况，忽略了 Spark 语义本身，这就是一种信息的浪费。接下来要做的是渗透到代码层面，分析 Spark 任务中包含的算子函数，据此做更细粒度的调优。

　　分类调优：Spark 的应用场景很多，比如用于纯分析、用于开发、用于处理等，不同场景的调优空间与目标也是不同的，所以有必要做分类调优。

　　工程优化：在实践过程中遇到的一个困难是样本较少、测试成本较高，这需要相关方共同配合，在工程或流程上做优化。

　　（1）SQL 查询平台是大多数用户接触最多的、体验最明显的一个大数据产品，不管是数据分析师、研发，还是产品经理，每天都会写大量 SQL 来获取自己想要的数据；

　　（2）很多人在运行 SQL 任务的时候，并不会去关注底层的执行引擎，比如 Presto 是基于纯内存的计算，在一些简单查询的场景下，其优势就是执行速度会比较快，但缺点就是假如存储量不够用的话会直接挂掉；与它形成对比的是 Spark，其比较适合执行大数据量的复杂场景，即使出现了 oom 也会使用磁盘的存储，从而避免任务的失败。所以，不同的引擎是适合不同的任务场景的。

　　（3）SQL 查询效果要综合考虑任务的执行时间以及资源的消耗，既不能过分追求查询速度而不考虑资源消耗，也不能为了节省资源而影响查询效率。

　　（4）业界传统的引擎选择方式主要有三种人工智能ai绘画，RBO、CBO 和 HBO。RBO是基于规则的优化器，规则制定困难且更新频率低；CBO是基于成本的优化，太过于追求成本的优化，可能会导致任务执行失败；HBO是基于历史任务运行情况的一种优化器，比较局限于历史数据。

　　在功能模块上的设计，当用户编写完 SQL 语句提交执行后，由模型自动判断使用哪种引擎并弹窗提示，由用户最终决定是否采用推荐的引擎执行。

　　模型的整体方案是基于 SQL 语句本身来推荐执行引擎。因为从 SQL 本身就能够看到用了什么表、用到哪些函数等，这些信息直接决定了 SQL 的复杂度，从而影响执行引擎的选择。模型训练样本来自于历史运行的 SQL 语句，模型标签是根据历史执行情况进行标注，比如任务执行超长、涉及数据量超大的任务会标为适合在 Spark 上运行，剩下的就是适合在 Presto 上去运行的 SQL。样本特征提取用到 NLP 技术，N-gram 加 TF-IDF 方法，大致原理是提取词组去看它在语句中出现的频率，这样能够提取出关键词组。经此操作后生成的向量特征非常大，我们先利用线 个特征，然后训练生成 XGBoost 模型作为最终的预测模型。

　　最终模型在线上的应用流程是：用户提交 SQL 后由模型推荐执行引擎，假如与用户最初选择的引擎不一样，则会调用语言转换模块完成 SQL 语句的转换。假如切换引擎之后执行失败，我们会有 failover 机制切回到用户原有引擎去执行，保证任务执行成功。

　　该实践的收益是模型可以自动选择出最适合的执行引擎，并且完成后续的语句转换，不需要用户再去做额外的学习。

　　另外，模型推荐的引擎基本上能够保持原有的执行效率不变，同时又能够降低失败率，所以整体上用户体验会上升。

　　最后就是由于减少了不必要的高成本引擎的使用，以及任务执行失败率的下降，使得整体资源成本消耗下降。

　　第二部分到第四部分，我们分享了 AI 算法在大数据平台上的三个应用。能够看到它的一个特点，就是使用的算法并不是特别复杂，但是效果会非常明显。这就启发我们要主动去了解大数据平台在运行过程中有哪些痛点或者优化空间，确定好应用场景后就可以尝试使用不同的机器学习方法去解决这些问题，从而实现 AI 算法向大数据的反哺。

　　以上介绍的三个应用场景，比较集中在数据处理阶段。其实呼应一下第一章讲的 AI 和大数据的关系，在整个数据生命周期里，AI 都能发挥比较好的作用。

　　比如在数据采集阶段，能够判断日志是否合理；传输时能够去做入侵检测；处理时，还可以再进一步的降本增效；交换时去做一些保障数据安全的工作；销毁时能够去判断销毁的时机与关联影响等。AI 在大数据平台的应用场景是非常多的，这里仅是抛砖引玉。相信未来 AI 与大数据的互相支撑关系会更加凸显，AI 辅助大数据平台更好地去采集处理数据，更好的数据质量后续又能帮助训练更好的 AI 模型，从而实现良性循环。

　　A1：这里所谓的调参规则是前期我们大数据同事根据手动调优经验制定的，比如任务的执行时间超出多少分钟、或者处理的数据量超出多大，给任务推荐多少核心数或者内存量等。这是一套经过长时间积累形成的规则，而且上线后效果比较好，所以使用这一套规则来训练我们的参数推荐模型。

　　A2：在做参数推荐的时候，我们并不是只一味的追求成本要低，否则推荐的资源会偏低导致任务失败。因变量确实只有参数调整，但为了防止不稳定性我们加了额外限制。首先是模型特征，我们选取的是某段时间的平均值而非孤立某天的数值；其次对于模型推荐的参数，我们会比较其与实际配置值之间的差别，如果差别过大则会采用缓升缓降策略，避免一次性调整过大导致任务失败。

　　A3：不是的。刚刚讲到在做参数推荐这块，我们是有用过两种方案：学习规则用的是回归模型；再往后是用的贝叶斯优化的框架。它们两个并不是同时使用的，我们是做了两种尝试。前一种学习规则，好处就是能够快速的把历史以往的经验给使用起来；第二个模型在前一个的基础上，能够去寻找一个更优，甚至是最优的配置。他们两个是属于一种先后的，或者是递进的关系，而不是同时使用。

　　A4：是的。刚刚有讲到，在做 Spark 调参的时候我们用到的信息只有它的历史执行情况，但对于 Spark 任务本身目前还没去关注。Spark 本身其实包含非常多的信息，有各种各样的算子人工智能ai绘画、阶段等。如果不去分析它的语义，会丢失很多信息。所以我们下一步的计划就是去分析 Spark 任务的语义，拓展更多的特征来辅助参数计算。

　　Q5：参数推荐是否会出现参数推荐不合理，导致任务异常甚至失败，然后对于这样的场景怎么降低异常任务报错和任务波动？

　　A5：如果完全依赖模型，有可能它追求的就是尽可能高的提升资源的利用率，这时候推荐的参数有可能会比较激进，比如内存一下子由 30g 缩到 5g。因此除了模型推荐外，我们会增加额外的限制条件，比如调参跨度不能超过多少 g 等，也即缓升缓降策略。

　　A6：任务智能调参还是比较热门的研究方向，不同领域的团队采用了不同的方法模型。我们在着手做之前调研了比较多的业界方法，包括你提到的 sigmoid 2022 论文。经过比较与实践，最终尝试了我们分享的这两种方案。后续我们会继续关注这个方向的最新进展，尝试更多方法来提高推荐效果。

　　专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章900+，百万+阅读，16万+精准粉丝。