云计算

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

本文主要是介绍如何在数据中台中提高效率并节省成本?,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

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

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

某电商业务数据建设资源增长趋势(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。所以模型复用,还可实现省钱。

第四,数据倾斜。

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

单Stage阶段Spark任务数据分片运行图

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

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

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

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

img

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

第六,调度周期不合理。

img

通过这张图你可以看到,大数据任务的资源消耗有很明显的高峰和低谷效应,一般晚上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 全局资产盘点

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

img

全链路数据资产视图:

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

计算全链路数据资产视图中,末端数据的成本和价值(末端数据就是加工链路最下游的表,例如图中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进行处理,然后对结果进行并集

推荐阅读

除数据倾斜,还应该查任务的配置参数。如Spark执行引擎:

  • Executor个数是否过大
  • executor-cores和executor-memory是否过多,利用率较低

一般executors-memorty 设4G-8G,executor-cores设2-4个(实践过利用率最高的配置项)。

还要考虑任务是否真有必要在高峰期执行,可根据集群负载情况,尽量将任务迁移到非高峰期执行,“削峰填谷”。

上面几点是产出任务高消耗的情况。

对存储消耗比较大的任务,先考虑是否要压缩,尤其对原始数据层和明细数据层,建议压缩

压缩方式

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

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

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

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

治理效果评估

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

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

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

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

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

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

成本治理中心

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

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

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

总结

通过数据中台:

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

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

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

FAQ

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

  1. 垂直切分:将宽表按照字段的访问频率划分,将访问频率高的字段单独划分为一张表,访问频率低的字段单独划分为一张表。这样可以减少查询时扫描的字段数,提高查询效率

  2. 水平切分:将宽表按照行进行切分,将每个切分后的表中的字段数控制在可接受的范围内,这样可以减少单个表的字段数,提高查询效率

  3. 建立索引:对于宽表中的访问频率高的字段,可以建立索引,这样可以加快查询速度

  4. 缓存机制:对于查询频率高的数据,可以采用缓存机制,将数据缓存在内存中,这样可以减少查询时间

  5. 数据压缩:对于宽表中的冷数据,可以采用数据压缩技术,减少存储空间,提高查询效率

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

这篇关于如何在数据中台中提高效率并节省成本?的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!