1. 数据中台机器资源情况

　　从整体的资源角度看，有赞数据中台机器数量在 1500 台左右，其中大部分是物理机，也有一部分是虚拟机，同时有 100 个左右的应用、4 万个核，数据规模在 15 PB 左右。

　　从规模上来看属于不大不小的一个数据集群。从业务的特征上看，离线计算、实时计算、平台应用、在线服务等都依赖于这些资源。其中离线机器的成本占了将近 50% ，其他的部分相对来讲占的是小头。

　　2. 数据成本增速超业务

　　在我们上半年的治理中，主要是针对离线计算场景，实时计算的部分目前在规划启动中。

　　根据目前的业务情况来看，数据中台资源上投入成本的增速比我们整个业务发展的增速还要快，这就导致了它的不可持续性，这也是我们进行成本治理的一个主要原因。

　　3. 问题剖析

　　分析下来，在成本方面我们主要面临的问题有以下这几个方面。

　　（1）资源水位低

　　一是整体的资源水位比较低，平均CPU使用率为 11% ，内存为 30% 左右。具体到场景中，离线的平均 CPU 使用率大概在 25% 左右，内存在 40% 左右。实时计算的平均 CPU 使用率在 18% 左右，在线服务的就更低了。

　　整体来看，使用率都是偏低的。原因一方面主要是在业务增长的过程中，为了保证对业务增速有一个比较好的资源支撑，做了一些能力的冗余，放大系数也设置的比较大。这样才能保证在有突发流量的时候，整体的性能有一个比较好的保障，特别是在 HBase 部分，问题更加突出。

　　（2）扩缩容成本高

　　第二个问题是扩缩容的成本和能力。2019 年的时候，有赞容器化的程度不高，在很多场景基本上是要以月为维度来进行机器的采购和搭建。特别是有大促活动的时候，额外扩出来的资源要放很长时间才能逐渐回收，这就导致长期成本比较高。

　　之前在扩缩容的效率方面还不够敏捷，为了保证业务能够在大促的时候能做到比较好的支撑，实际上只能采用这种方式。

　　（3）存储成为瓶颈

　　第三点是存储。为了那些不可恢复的数据的备份，之前我们专门做了一个集群来存储数据。这部分的数据实际上只是为了存储的目的，但也是用物理机来存的，付出的成本是整机成本，但是只使用整机的存储资源，计算资源利用率很低，所以代价也比较高。

　　（4）离线计算浪费

　　第四点是离线计算。我们之前更多关注点是把跑批的任务能够正确的跑下来。整个跑批的优化空间相对是比较大的，今年上半年我们也花了比较多的力气在做这一部分的优化。

　　（5）缺少成本意识

　　再往深层来看，还有一个很大的原因。

　　在没有做系统化的成本治理之前，部门同学在成本方面的意识要比对业务支撑的意识弱很多，对于这块关注的比较少，考虑更多的是如何更好的支撑业务。

　　同学们对于成本的意识缺乏一个统一的引导，特别是缺乏一个能够让同学直接感知到成本的机制，这种情况下成本意识的落地是相对比较难的。下文会讲到一个重点，我们做了一个成本账单的模型，能够让每一个做数据或者使用数据的同学清晰的感受到他自己的数据成本是多少，这样就能很容易的建立起来意识成本。

　　二、综合治理

　　在这样的大背景下，我们从 5 个方面进行了成本的综合治理。和前面的问题也有关联：

　　1. 提升资源利用率

　　要提升资源利用率，从本身来讲，首先要制定利用率的标准，确认利用率在什么水位是合理的。

　　我们基本上是根据不同的集群和环境来设定。QA环境、预发环境和生产环境的水位设置会有差别；服务场景目前是按离线、在线和实时进行划分；另外，针对不同的业务场景也会设置不同的水位。

　　比如，有些业务是内部应用，有些是核心业务，而有些是边缘业务。我们针对不同的业务制定了不同的水位划分，让不同的业务都能有一个具体的参照方式，从而去做一些扩缩容的处理。

　　还有就是对机型的优化。因为历史原因，我们在采购不同机器的时候，型号上有很多会不匹配。虽然都是计算型的，也都是按照当时的高配进行的采购，但随着时间的变化已经变成了中配或者低配。这样在后面的统一调度上增加了复杂度，所以我们上半年有计划的把一些机器进行了更新换代，更统一的机器会让集群调度、容器化等变得更简单、更清晰。

　　另外就是把机器根据不同的计算场景进行标准化的处理，就像计算型、内存型、存储型等的标准。

　　提升利用率还有一个方式，就是把像跑批这样的任务进行合理的划分，从而起到削峰填谷的效果。

　　2. 容器化改造

　　容器化的改造是比较重要的部分。对于我们前面提到的问题，容器化在很多方面都会提供一个非常好的支撑。

　　第一点就是扩缩容。前文提到的扩缩容的能力是资源浪费很重要的一部分。我们上半年把离线产品的容器化基本做完了，这样离线计算扩缩容的时候响应速度是非常高的，基本上是分钟级的采购。

　　现在是和腾讯云合作，把采购的 API 打通，这样就可以通过调度策略来进行扩缩容，比以前按月的采购方式效率要高很多，成本也会降低。

　　通过容器化，也可以很方便的实现存储与计算分离。一般而言，用来完成在线服务的资源，在夜间的利用率是非常低的，这部分计算资源是可以在夜间加入到容器中，为夜间跑批提供更多的资源，优点非常多。

　　上图说明了容器化改造后带来的价值。左边的部分是相对固定采购的一些集群，属于常规的采购，白天和晚上都在跑。

　　我们采取的策略是，最早的时候只有图中左边部分的集群，没有做扩缩容。实际上日间的利用率不高，而我们现在是把日间利用率的能力跑满到 100% 。

　　因为日间的流量不大，目前占我们总量的 40% 。夜间相当于还缺少 60% 的计算资源，其中 50% 我们是通过按需采购的方式进行采购。这部分资源，只需要按照夜间8小时的时间窗口采购。这样实际上只需要采购1/3的时长。当然按需采购的成本也会略高于按月采购的成本，但只采购三分之一的时间，所以总体成本要比按月采购低非常多。

　　剩下的 10% 我们主要利用在线的计算资源来完成。这就是容器化给我们带来的比较大的价值。

　　3. 存储优化

　　存储优化基本可以分为以下几块：

　　第一是冷备的数据。冷备的数据主要针对不可恢复数据的存储。这一块我们是用一个专门的机器来做，现在基本上把这部分的内容都存到了腾讯的 COS 上，成本降低非常大。COS 给了我们一个很好的折扣，比起之前冷数据的独立集群存储，降低了大概 80% 的成本。而且放到 COS 上也比放在自己的服务器上安全性高了很多。

　　第二部分是 Hive 数据生命周期的管理。我们之前对于数据的分区做的是比较弱的，今年上半年我们基本把 90% 以上的 Hive 的分区表都做了历史分区的清理，这样节省了大约 20% 以上的存储空间。

　　第三部分是我们目前正在进行中的一项工作。我们 hadoop 目前还是 2.x 版本为主，目前也在往 3.x 上迁移。因为 3.x 提供了很好的存储压缩的方案，如果整体迁完，可以降低一半左右的空间。当然，这个操作对于比较热的数据可能不是很合适，主要用来优化一些相对偏冷的数据。

　　4. 离线任务优化

　　对于离线任务的优化我们称之为「六脉神剑」。

　　（1）下线

　　第一部分是把一些无用的数据下线。这块是利用全链路的数据资产和血缘关系，进行智能挖掘，特别是上游应用场景中已经不再使用或者使用频率非常低的数据，再结合人工的判断促进下线。

　　（2）任务调度

　　第二部分是任务方面的调优。一方面是任务本身的调度安排和语法安排，还有就是在不同的任务中可能有重复计算，我们会把这些找出来进行优化。

　　（3）高转低频

　　第三部分是对频次的管理。有一些任务是小时级的跑频，特别是很多跑的频率相对比较高的任务，会有同学进行跟踪和对上游的使用场景进行核对，评估这些本来按小时跑的频率能否降低到一天或者三天，结合具体的业务场景进行更科学的评估。

　　我们也正在 Hive 上使用立方体的概念，这样一次计算就可以把多个维度的组合跑完，进而降低跑批的频率、提升跑批的效果。

　　（4）替换

　　第四部分主要是老数据的替换。这里主要发生在一些跑的时间比较长的业务场景中。这些数据可能本身是支持一些老业务的，但随着时间的变化，有一些新的场景老任务支持不了，可能需要另起一个任务来支持新的业务。最后的结果是老的和新的都在线上长期并存。我们也付出了一些代价对这些任务进行整合，把老任务下线的同时，也让整体任务运行的更好。

　　（5）小文件合并

　　第五部分是小文件的合并，这是 spark 本身特性导致的。我们跑批主要是用 spark 来跑，但因为 spark 跑的时候会产生很多小文件，所以今年上半年我们也做了一个统一的合并，来提升整体的任务效果。

　　（6）延迟启动

　　延迟启动主要是为了更合理的利用时间，把高优先级的任务跑完后再错峰的跑其他任务。

　　这就是我们对离线任务所做的一些优化，主要是通过以上六个场景进行。