存储成本降低80%，有赞数据中台成本治理怎么做的？

导语 | 随着直播电商行业的兴盛，有赞业务高速发展。但同时数据仓库中存储资源和计算资源消耗也非常高，甚至一度超过了整个平台业务的增速，显然不是一个可持续发展的态势。本文是对有赞技术副总裁，腾讯云最具价值专家 TVP——沈淦老师在云+社区沙龙 online 的分享整理，为大家介绍有赞在数据中台成本治理上的实践，与大家一同交流。

https://v.qq.com/x/page/k3124wjyelx.html

点击查看完整直播回放

一、背景介绍

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）延迟启动

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

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

5. 成本运营机制

前面提到的四块内容，实际上是偏技术层面的阶段性的做法。但从长远来说，如果要把成本治理长效的做下去，技术方案虽然必须的，但同时接入企业的运营机制，也是一个关键动作。

我们这里也做了一些相关的工作，第一个方式就是把成本量化。简单来讲就是使用了什么数据或者什么资源，那么这个资源怎么去定成本的价格，是一个关键。

所以成本量化，基本上就是把机器的成本拆分成一些关键的成本，如 CPU 、内存、存储还有时间等要素。

跑出来的数据如何占用资源，需要准确的采集方案。集群里面的计费，也就是不同时间段不同的计费价格。最后是要让数据成本透明，每一个数据的使用团队都可以知道自己跑的任务到底消耗了多少成本。

我们会把消耗的成本以一个成本账单的形式记录下来，记录的维度可以是数据的维度也可以是人、团队或者整个数据平台的维度，我们下一步是发展到整个业务端，跟业务一起联动，但目前还只是在数据中台内部，没有跨到业务当中去。

第三步是优化推进。有了成本数据之后会有两个维度，一是这些计算资源的使用方，他们可以知道自己的一个成本数据，会主动的去降低成本、优化任务或者资源的使用方式。另一个是治理团队进行的推动，这对业务来说是被动降本。基本上大的方式都一样，从成本数据中找到降本点后，关注一些资源大户，跟他们形成降本的计划并推动。

第四块是跟踪反馈，降本的动作执行之后，需要监控这个降本动作是阶段性的降本还是长效的策略，进行定期的跟踪。

最后就是奖惩措施。目前主要的奖惩方式还是以激励为主，没有和那种对同学有非常大影响的比如绩效、晋升等因素挂钩。目前采取的手段，主要还是通过一些红黑榜、有赞币（有赞内部的一种同学直接互相表达谢意的方式）重点场合表扬之类偏氛围、文化方面的形式进行激励。在极少数的项目中，可能会因为降本措施不到位的原因，对发布进行了一些限制。就是说如果没有进行治理成本优化的话，是不允许发布新功能的。这种场景目前使用的不多。

（1）成本量化模型

下面我们再看一下如何做一个成本量化模型。

上图表达的比较清楚。右半部分是先把所消耗的资源进行划分，基本上是按存储资源、计算资源和时间维度。

我们会对每一种资源进行定价。定价的依据方式基本上是根据不同场景采用不同的计算类型，这首先需要有一个合理水位的划分。有些可能定 50% 是合理水位，有些可能会高一些。

第二点是根据不同资源的稀缺性。从离线计算的场景来看，CPU 的成本定价会高一点，而磁盘存储在离线的场景下，定价就会稍微低一点。

最后再根据资源总的情况和总成本的情况，折算出一个单价。有了单价指标之后，每一个跑批使用了多少资源，再乘以单价就可以得到成本的数据。

数据成本模型在成本治理中非常关键。我们也做了不少时间上的打磨，逐渐得出一个比较合理的定义

（2）成本单价

上图主要是为了解释：为什么把不同的资源进行不同的划分？实际上我们采购的是整机的资源，那么这个总盘子要怎么划分？

其实就像猪不同部位的价格是不同的，不同的原因是因为资源稀缺性的差别。比如说在离线计算场景中，CPU 就比磁盘要更稀缺，它的定价可能就会更高一点。

（3）计算资源采集

另一部分是怎么样去采集我们真正的计算资源。有赞离线计算主要是用 Spark ，大多数都是 Spark SQL 的方式来跑的，有一部分是用程序化的方式来跑的。程序化的方式我们有一个真实损耗的采集，使用 Spark monitor 就可以的导出一个比较真实的资源使用情况。

而 Spark SQL 方式的任务，因为任务调度本身有一个预热、执行和资源回收三个阶段，而我们通过 Spark thrift server（ STS ）采集到的数据，只反映执行阶段的资源使用情况，不包含预热和回收部分。所以我们在通过 STS 采集到的资源使用数据的基础上，乘上一个损耗系数来反映真实的资源使用情况。损耗系数目前我们跑下来基本定在 10% 。

（4）运营

再结合我们刚才的公式，就可以得到不同任务数字资源的成本。

通过这样的方式，加上我们前文所讲的机制，就能够为每一个任务，再通过任务到人，再从人到团队，从团队再到一个更大的整个数据中台，从而建立起一个完整的成本账单的模型。

通过我们的实践发现还是很关键的，所以我们的团队写了一个「降本运营」真经：

降本意识靠宣导，

成本大户要骚扰；

既要用户多反馈，

也要奖惩做到位。

总结下来就是要宣导、骚扰、反馈、奖惩，这个是我们团队也是我个人比较深的体会。不光是在降本这件事情上，我们很多技术侧的工作，通过技术把事情做好可能只是个开始，更大部分的事情是要通过技术运营的方式，让这个事情真正滚动起来。

相当于我们这边画的滚动飞轮一样，只要让它真的滚动起来才有价值，而不仅仅是做阶段性的上线。就算一次降本能达到 18%-20% ，但如果没有一个持续运营的工作，可能慢慢的又涨了回去，效果就不会很好。

三、收效与展望

以上就是我跟大家分享的关于有赞上半年做的一些内容，下面再花一些时间来看一下我们的收益情况。

整体资源利用率无论是从内存还是 CPU 上都略有提升，但为什么提升的幅度看上去不是特别大呢？这是因为我们上半年主要还是集中在离线产品的降本上，对于在线计算场景和其他场景，我们在下半年会逐渐加上。

从数据上来看，通过统一机型的方式，整体的计算性能提升了 12% ；通过将无用数据下线、任务调优后计算节省了 17% ；通过使用腾讯云的 COS 服务备份冷数据，存储成本下降了 80% ；通过提成升本意识，自主降本的比例超过了 25% ，通过这样变成了一个良性循环。

这样资产治理团队要 push 的工作就会越来越少，资产治理团队会有更多精力去到更多的场景进行降本优化。

最后从整体资源的情况来看， 2020 年 Q1 有赞整体收入的增加是非常快的，增加了 50% 左右，但数据中台在整个 H1 的资源只增加了 21.5% 。这跟 2019 年下半年的情况是完全相反的。

2019 年下半年，我们的情况是整个数据中台的资源成本，增加的速度远远超过了整体有赞业务的 GMV 增速。所以从目前取得的成绩来看，是万里长征第一步，开了一个不错的头。

对于下半年来说，在现有的机制特别是成本账单的基础上，会不断的去做更多的降本场景的优化，把降本的效果发挥到更大的程度。

接下来的工作计划与展望，首先是我们可能计划一个更大规模的离在线的混部，并在更多场景实现资源的按需采购。就像前文提到的那样，在离线场景中，我们有 50% 的计算资源计划进行按需采购，使成本大幅降低。

第三点是在线计算的优化。具体做法和之前讨论的内容差不多，继续推进。

第四点是相对要花比较大的力气推进的，就是把现在成本账单的模型，从业务中台再往上推进到业务方。业务方有两种，一种是技术侧、产研侧的研发，另一种是运营团队、销售、商服等，这样让大家都能更全局的感受到数据成本，从而让大家的成本意识上升到一个更高的水平。

有赞的数据团队也是一个比较年轻有朝气的团队，目前整体的业务量包括计算的复杂度都在飞速发展，也特别期待有更多热爱数据、渴望在比较大的平台挖掘数据价值、期待用数据驱动业务的同学加入到我们的团队当中。

最后一句话：不计成本的数据，也许只是一堆垃圾。要把数据变成真正有价值的资产，首先要从怎么更好的做好数据的成本治理开始！

四、Q&A

Q：持续运营的成本怎么样呢？

A： 因为整套的运营机制已经建⽴起来，用户可以⾃主通过系统能⼒降本。保持现状的话，只需要一人投入 10% 左右的精力来跟进，就能持续节省成本。但是我们还会持续探索更多降本点，扩⼤战场。这样的话，也只需要半个人⼒就够了。

Q：数据中台全上云了吗？还是说部分，现在比例是多少？

A： 如果上云是指⽤云⼚商的服务器，那数据中台已经全部上云了。

Q：对于团队奖惩措施能聊⼀下么？

A： ”惩“⽬前有”⿊榜“，我们会⾃动挖掘出每个⼈的“降本空间”。⽐如哪些任务应该下线、哪些任务可以延迟启动，形成⼀个榜单，在平台公示，给浪费者⼀定的压⼒。另外⼀个惩的方式，是对于降本不到位的，进⾏任务发布限制，不过触发这个条件的极少。

总之，我们以奖为主，以惩为辅，奖惩都是为了更好地降本。⽬前⼩伙伴们的意识有很⼤提升，⾃主降本率超 25% ，不需要特别的惩罚就已经达到不错的效果了。所以在“惩”这个⽅⾯，还没有继续加码。

Q：数据的血缘关系用什么实现的呢？

A： 我们有研发平台，所有的任务都在系统上有对应的代码。对于 Hive/sparksql 任务，我们通过 sql 解析，可以获取表-表血缘，再根据任务关系衍生到表-任务；对于其他任务，我们要求在系统里登记任务数据依赖和产出，这样通过采集配置信息就能获取。

Q：冷数据 COS 存储是使用归档吗？

A：腾讯云的 COS 产品有标准存储和归档存储，冷数据 COS 存储是使⽤了 COS 的标准存储，存的是访问量⾮常低的原始数据。

Q：k8s 如果将应用和数据节点封装在⼀个容器⾥是不是可以提高利用率降低成本？

A： 数据可以理解为持久化的状态，容器是⽆状态的，如果数据封装在容器⾥，容器销毁了，数据就丢失了。数据通常是⽆法封装到容器，除⾮挂载在云盘，但云盘的读写效率就不如本地盘。

Q：会不会有些冷数据被删除后发现⼜要⽤的情况？

A： 冷数据备份到 COS 后，读取很⽅便，COS 兼容 hdfs 的 client 。上层的应⽤⽐如 Hive，数据可以存在 hdfs 也可以存在 COS ，只是元数据⾥的 Location 信息指向不同而已。

Q：我看刚才说到有比较精准的成本分析，但有没有模型定义数据成本投⼊相关的产

出？是从业务收入定义吗？

A： 这个问题很好，也是我们在思考的，除了关注成本（投⼊），也要关注价值（产出），通过 ROI，可以更准确地判定“合理”。上半年我们还没定义“产出”，因为我们刚摸索出⼀套合理的模型和运营机制。

下半年我们⾸先会将成本算到业务，让业务⽅对成本有感知，促进他们关注价值。同时我们也会去探索，如何更好地衡量“价值”，业务收⼊会是其中⼀个参考因素。

Q：数据中台和数据仓库有什么区别或者关系?

A： 从组织上看，目前我们数据中台是包含数据仓库的。从业务上讲，数据仓库是⽀撑上层业务需求的⼀种数据组织。我们有专门的数仓团队，负责数据中间层的建设，也有业务团队，对数仓本⾝做贡献，满⾜业务的需求。

Q：平台画像，做数据分析用的什么技术？

A： 有赞平台画像的标签产出有两种途径：基于离线数据⽣成的标签和基于实时流式数据⽣成的标签。基于离线数据生成的标签，采⽤的是 Hive+Spark SQL 进⾏数据分析。基于实时流式数据生成的标签，采⽤的是 Kafka+Flink 进⾏数据分析。另外，还会⽤到 presto 做画像洞察，⾃动打标⽤规则引擎，使⽤机器学习算法进⾏某些标签的预测。

Q：我想问⼀下，有多少业务做的实时数据，有多少是 T+1 的批处理？实时数据还会用批处理更新吗？

A： ⽬前有赞的实时处理的业务⼤概 1k+，离线业务场景 1w+，有些实时业务是保证 exactly once，有些⽆法保证的会使⽤批处理修。

Q：冷备份是批处理，定时在容器中做⼀个服务，CPU 空闲时备份吧，是吗？备份到什么里面去了，具体用的什么技术？

A： 是定时服务，CPU 空闲时(⽩天)备份，备份到腾讯云的对象存储 COS ⾥，主要是有赞基于 Hadoop distcp 改造的⼀个具有加密功能的从 hdfs 拷贝到 COS 的⼯具。

Q：数据治理的过程，有什么好的技巧推动业务参与，很多时候业务更关注业务功能开发？

A： ⾸先要找到跟业务的利益共同点，如果没有，就想办法打造⼀个。比如数据治理关注的成本和质量，成本⽅⾯其实在整个公司都会重视，所以只要能合理地指出“浪费”的地⽅，业务⽅会主动去减少；质量方面，保障⾼质量，是业务稳定的前提，直接关乎利益。

当然，也需要有⼀定的运营⼿段和推动⽅法，让这个过程更⾼效。⽐如红⿊榜之类的奖惩措施，以周粒度进⾏项⽬迭代的⽅式推进等。

Q：数据中台，离线数据占比高，能举例⼀个场景吗？

A： 离线数据从大小上看，⼤约是在线的 3 倍，成本占到整个数据中台集群成本的 40% 以上。不确定这个问题想要的场景指的是啥，如果是离线的应⽤场景，有很多，⽐如机器学习的模型离线训练，商家的分析、经营数据等。

Q：Flink 在线场景⽤到哪⾥了？

A： Flink⽤到的在线场景有：商家的实时看板、主播的实时爆单统计、实时监控等。

Q：存储部分 结构化数据和⾮结构化数据如何构架的？

A： 结构化数据主要使用 json、avro，⾮结构化数据就是存经过压缩后的⽂本。

Q：存储上云，成本更好吗？

A： 我们对⽐过存储上云和纯粹买机器的磁盘成本，上云的存储成本⽐磁盘成本会低⼀些(差距不⼤)，但由于买来的机器上往往会有 CPU 和空闲的内存在某些时间是⽆法充分利⽤的。尤其在冷备集群，买来的机器基本上只充分利⽤上了磁盘，CPU 和内存是浪费的，这是我们冷备集群上云的考虑。

Q：数据治理怎么和数据成本关联

A： 数据治理的范围很⼴，包含数据本⾝的管理、数据安全、数据质量、数据成本等。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/lkZ2_W20IdVh8x_dcyFekw