如何在数据中台中提高效率并节省成本？

上节讨论了如何保障数据中台的数据质量，让数据“准”。除了“快”和“准”，数据中台还离不开“省”。随数据规模越来越大，成本越来越高，如不合理控制成本，还没等你挖掘出数据应用价值，企业利润就被消耗完。

能否做到精细化成本管理，关乎数据中台项目成败。

某电商业务数据建设资源增长趋势（CU= 1vcpu + 4G memory）：

某电商平台的大数据资源消耗增长趋势，2019全年资源规模25000CU，全年机器预算3500W。对创业企业显然不小开支。

一天，数据团队负责人李好看被CEO叫到了办公室：

这3500W花在什么业务？
你们做了哪些成本优化的举措，效果如何？

把李问懵，他心想：团队的成本是按机器又不是数据应用核算。在数据中台中，数据应用之间的底层数据是复用的，那具体每个数据产品或者报表花了多少钱，自己没有这样的数据啊，咋可能知道。

可对CEO这些很重要，因为资源有限，他须确保资源都用在战略目标的关键节点。如电商团队今年核心KPI是提升单个注册会员在平台的消费额，老板角度，他须确保资源都投入与KPI相关业务，如基于数据对注册会员精准化营销，提升会员在平台的消费额。

自己所在的团队是否发生过类似的事情？数据部门是企业的成本中心，如要展现自己的价值：

支撑好业务，获得业务的认可
精简成本，为公司省钱

所以，今天重点在省钱，聊数据中台的精细化成本管理。

1 成本陷阱

一开始建设数据中台时，你往往会关注新业务的接入，数据的整合，数据价值的挖掘上，忽略成本管控的问题，从而落入陷阱中，造成成本爆炸式的增长。所以，有必要深入了解有哪些陷阱，尽量在日常开发中避免。

这里总结8种陷阱：

1~3广泛存在，但易被忽略
4~8涉及数据开发中一些技能，开发时注意就可

“知其然，更要知其所以然”，才能发现问题本质，深入掌握解决问题的方法。

1.1 数据上线容易，下线难

某数据中台项目，表相关的使用统计。一半的表30d内都没有访问，而这些表占26%存储。如把这些表的产出任务单独拎出，高峰期需消耗5000Core CPU计算资源，换算成服务器需125台（按一台服务器可分配CPU 40Core计算），成本一年近500W。自己竟然有这么多无用数据？我经常把数据比作手机中的图片，我们不断拍照生图，却懒得清，最终手机存储经常不够。

无法及时清数据，数据开发也有苦衷。他们不知道一个表：

还有哪些任务在引用
还有哪些人在查询

自然不敢停止这个表的数据加工，导致数据上线易，下线难。

1.2 低价值的数据应用消耗了大量的资源

数据看上去每天都被访问，但究竟产出多少价值，ROI值得吗？

有个宽表（拥有很多列的表，经常出现在数据中台下游的汇总层数据中），加上上游加工链路的任务，每天加工这张宽表要消耗6000块钱，一年200W，可追查后我们发现，这张宽表实际每天只有一个人在使用，还是一个运营的实习生。显然，投入和产出极不匹配。

间接说明，数据部门比较关注新的数据产品带给业务的价值，却忽略已存产品或报表是否还存在价值，最终导致低价值的应用仍大量耗资源。

1.3 烟囱式的开发模式

不仅研发效率低，因数据重复加工，还资源浪费。一张500T表，加工这表，计算任务需高峰期消耗300Core，折合7台服务器（按一台服务器可分配CPU 40Core计算），加上存储盘成本(按照0.7 元/TB*天计算)，一年消耗40W。

而这张表每复用一次，就可节省40W。所以模型复用，还可实现省钱。

第四，数据倾斜。

数据倾斜会让任务性能变差，也会浪费大量的资源，那什么是数据倾斜呢？

你肯定听说过木桶效应吧？一个木桶装多少水，主要取决于最短的那块板。对于一个分布式并行计算框架来说，这个效应同样存在。对于Spark计算引擎来说，它可以将海量的数据切分成不同的分片（Partition），分配到不同机器运行的任务中，进行并行计算，从而实现计算能力水平扩展。

但是整个任务的运行时长，其实取决于运行最长的那个任务。因为每个分片的数据量可能不同，每个任务需要的资源也不相同。由于不同的任务不能分配不同的资源，所以，总任务消耗资源=max{单个任务消耗的资源} * 任务数量。这样一来，数据量小的任务会消耗更多的资源，就会造成资源的浪费。

我们还是举个电商场景的例子。

假设你需要按照商户粒度统计每个商户的交易金额，此时，我们需要对订单流水表按照商户进行group by计算。在平台上，每个商户的订单交易量实际差距很大，有的订单交易量很多，有的却比较少。

我们利用Spark SQL完成计算过程。

在上图中，任务A 读取了左边某个分片的数据，按照供应商进行聚合，然后输出给下一个Stage的B、C、D任务。

你可以看到，聚合后，B、C和D任务输入的数据量有很大的不同，B处理的数据量比C和D多，消耗的内存自然更多，假设单个Executor需要分配16G，而B、C、D不能设置不同的内存大小，所以C和D也都设置了16G。可实际上，按照C和D的数据量，只需要4G就够了。这就造成了C和D 任务资源分配的浪费。

第五，数据未设置生命周期。

在06讲中，我强调，一般原始数据和明细数据，会保留完整的历史数据。而在汇总层、集市层或者应用层，考虑到存储成本，数据建议按照生命周期来管理，通常保留几天的快照或者分区。如果存在大表没有设置生命周期，就会浪费存储资源。

第六，调度周期不合理。

通过这张图你可以看到，大数据任务的资源消耗有很明显的高峰和低谷效应，一般晚上12点到第二天的9点是高峰期，9点到晚上12点，是低谷期。

虽然任务有明显的高峰低谷效应，但是服务器资源不是弹性的，所以就会出现服务器在低谷期比较空闲，在高峰期比较繁忙的情况，整个集群的资源配置取决于高峰期的任务消耗。所以，把一些不必要在高峰期内运行任务迁移到低谷期运行，也可以节省资源的消耗。

第七，任务参数配置。

任务参数配置的不合理，往往也会浪费资源。比如在Spark中，Executor 内存设置的过大；CPU设置的过多；还有Spark 没有开启动态资源分配策略，一些已经运行完Task的Executor 不能释放，持续占用资源，尤其是遇到数据倾斜的情况，资源浪费会更加明显。

第八，数据未压缩。

Hadoop 的HDFS 为了实现高可用，默认数据存储3副本，所以大数据的物理存储量消耗是比较大的。尤其是对于一些原始数据层和明细数据层的大表，动辄500多T，折合物理存储需要1.5P（三副本，所以实际物理存储5003），大约需要16台物理服务器（一台服务器可分配存储按照128T计算），如果不启用压缩，存储资源成本会很高。

另外，在Hive或者Spark 计算过程中，中间结果也需要压缩，可以降低网络传输量，提高Shuffer (在Hive或者Spark 计算过程中，数据在不同节点之间的传输过程)性能。

你看，我为你列举了8个典型的成本陷阱，那你可能会问了，老师，我已经中招了，该怎么办呢？别急，接下来我们就看一看，如何进行精细化的成本管理。

2 如何实现精细化成本管理？

成本治理应遵循全局盘点、发现问题、治理优化和效果评估四步。

2.1 全局资产盘点

对数据中台中，所有的数据进行一次全面盘点，基于元数据中心提供的数据血缘，建立全链路的数据资产视图。

全链路数据资产视图：

下游末端关联到数据应用（报表：财务分析）
上游起点是刚进入数据中台的原始数据
数据之间通过任务进行连接

计算全链路数据资产视图中，末端数据的成本和价值（末端数据就是加工链路最下游的表，例如图中TableA，Table G）。

为什么一定要从末端开始？因为中间数据在计算价值时，还要考虑下游表被使用的情况，较难计算清楚，所以从末端数据开始。这与下线表的顺序也一致，如数据的价值很低，成本很高，也从末端数据开始下线。

数据成本该如何计算？

对上图中财务分析报表核算成本，这报表上游链路中涉及a，b，c，3个任务，A，B，C，D，E，F， 6张表：

这张报表的成本=3个任务加工消耗的计算资源成本+6张表消耗的存储资源的成本。

如一个表被多个下游应用复用，那这个表的存储资源成本以及产出任务消耗的成本，需分摊给多个应用。

那价值又该如何计算？

如末端数据是一张应用层的表，它对接的是一个数据报表，那衡量这数据价值主要看报表的使用范围和使用频率。

计算使用范围时，通常用周活评估，同时还要考虑不同管理级别的人权重，对老板，他一个人权重可相当1000个普通员工。所以这样设计考虑到管理级别越高，做出商业决策影响越大，自然价值越大。使用频率一般使用单个用户每周查看报表的次数来衡量，次数越高，说明报表价值越大。

如末端数据对接的不是一个数据报表，而是面向特定场景的数据应用（比如我之前提到过的供应链分析决策系统，它面向的人群主要是供应链部门）。衡量这类产品的价值，主要考虑目标人群的覆盖率和直接业务价值产出。什么是直接业务价值产出呢？，在供应链决策系统中，就是通过系统自动生成的采购订单占所有采购订单的比例。

末端数据可能还是一张集市层的表，主要用于提供给分析师做探索式查询。这类表的价值看它被哪些分析师使用，使用频率。使用范围评估时，也要对分析师按级别加权。

2.2 发现问题

全局盘点为发现问题提供数据支撑，关注：

持续产生成本，但已没有使用的末端数据（一般指30天内无访问）
没有使用，但一直在消耗成本的表，对应的就是我提到的陷阱1
数据应用价值很低，成本却很高，这些数据应用上游链路上的所有相关数据
低价值产出，高成本的数据应用，对应的是陷阱2
高峰期高消耗的数据
高成本的数据，对应陷阱4～8

陷阱3实际是在第6节模型设计中解决的。

2.3 治理优化

针对这三类问题制订相应策略。

第一类，应对表下线。数据下线要谨慎，参考数据下线的执行过程图：

末端数据删除后，原先末端数据的上游数据会成为新的末端数据，同样还要按发现问题到治理优化进行重复，直到所有的末端数据都不满足下线策略为止。

对第二类问题，我们需要按照应用粒度评估应用是否还有存在的必要。对于报表，可以按照30天内没有访问的应用自动下线的策略，先对报表进行销毁，然后对报表上游的表进行下线，如果该表还被其他的应用引用，就不能下线。下线步骤可以参考前面的下线步骤。

第三类问题，主要是针对高消耗的数据，又具体分为产出数据的任务高消耗和数据存储高消耗。对于产出任务高消耗，首先要考虑是不是数据倾斜。具体怎么判断呢？其实你可以通过MR或者Spark日志中，Shuffer的数据量进行判断。如果有某一个Task 数据量非常大，其他的很少，就可以判定出现了数据倾斜。

图 Spark task shuffer records：

图 MR reduce task records：

数据倾斜处理？

不同的场景有一些适用的解决方案：

如一些大表和小表关联时，Key分布不均造成数据倾斜，可使用mapjoin
较通用的处理方式，如把热点Key单独处理，然后对剩下的Key进行处理，然后对结果进行并集

压缩方式

小文件的压缩，不考虑split，gzip较合适
大文件，推荐lzo，支持split，在保证压缩效率前提下，有相对稳定压缩比

还要考虑生命周期是否设置：

ODS原始数据层和DWD 明细数据层，适合用永久保留策略
一些商品、用户维表，可考虑3、5年保留策略

整体上，底层表都是长期保留。关注重点应是汇总层以上的表（包括汇总层），一般可根据数据的重要性，制订7天，1个月保留策略。

治理效果评估

量化治理成果 - 省了多少钱

若直接拿服务器数量来衡量，不能真实反应治理效果，因为还要考虑业务增长原因，可围绕任务和数据的成本考虑：

下线了多少任务和数据
这些任务每日消耗了多少资源
数据占用了多少存储空间

拿这些资源来计算成本，就能算出省了多少钱。如开头案例，任务A运行3h，在运行过程中，共消耗5384503 cpus，37007892 GB s, 假设我们1个CU （1 cpu， 4g memeory）一年是1300元成本，折合每天为3.5元（计算公式为1300/365）。

不论是优化或下线任务，只统计高峰时间段内，因为优化低峰时间无法实际节省资源。

高峰时间段为8h，那折合每s费用0.00012153，则该任的费用为max{53845030.00012153, 37007892/4 0.00012153} = max{654, 1124} = 1124 。下线这任务后节省1124元，再加上表A占用的存储空间大小乘以每GB的成本，可得数据表A下线节省费用。

成本治理中心

成本治理不是一劳永逸的工作，需要持之以恒，不断发现问题，然后治理优化，建立长久运行机制的前提是必须降低成本治理的门槛，接下来，看一下网易的一个成本治理的平台，EasyCost。

系统提供了数据诊断的功能，可以按照访问时间、访问频率、关联的应用，设置下线策略，支持一键灰度下线，大幅提高了管理的效率。

可通过系统化方式沉淀到产品，然后通过产品提高管理效率，实现治理机制的长久落地。

总结

通过数据中台：

可获得大数据作为资产中心带来的红利
也可能陷入成本的深渊，为野蛮增长的大数据费用买单

从常见成本陷阱入手，分析可能造成成本浪费的原因，然后介绍精细化成本管理的方法，最后强调：

无用数据的下线应该从全链路数据资产视图的末端入手，然后抽丝剥茧，一层一层，向数据加工链路的上游推进。
应用层表的价值应该以数据应用的价值来衡量，对于低价值产出的应用，应该以应用为粒度进行下线。
对高消耗任务的优化只要关注集群高峰期的任务，项目的整体资源消耗只取决于高峰期的任务消耗，当然，如果你使用的是公有云的资源，可以高峰和低谷实施差异化的成本结算，那低谷期的也是要关注的。

FAQ

在数据中台的集市层，存在一些大宽表，几百个字段，上游可能数十个表，如计算这个表的成本会非常高。这表中，字段访问频率不同，优化这张宽表?

垂直切分：将宽表按照字段的访问频率划分，将访问频率高的字段单独划分为一张表，访问频率低的字段单独划分为一张表。这样可以减少查询时扫描的字段数，提高查询效率
水平切分：将宽表按照行进行切分，将每个切分后的表中的字段数控制在可接受的范围内，这样可以减少单个表的字段数，提高查询效率
建立索引：对于宽表中的访问频率高的字段，可以建立索引，这样可以加快查询速度
缓存机制：对于查询频率高的数据，可以采用缓存机制，将数据缓存在内存中，这样可以减少查询时间
数据压缩：对于宽表中的冷数据，可以采用数据压缩技术，减少存储空间，提高查询效率

可根据实际情况选择合适的优化方式来提高查询效率。

本文由博客一文多发平台 OpenWrite 发布！