企业降本增效是越来越热门的话题，除去较为粗暴的“毕业”之外，企业还可以在许多地方下功夫，例如降低大数据成本、营销成本、运营成本等等。在ArchSummit全球架构师峰会深圳站上，我们邀请了货拉拉大数据架构负责人王海华，他为我们分享了《货拉拉基于混合云的大数据成本管控体系建设实践》，本文为其演讲整理，期待你可以有所收获。
大家好，我是王海华，货拉拉基础架构负责人，我将从以下几方面展开分享。首先是背景与挑战；其次是大数据成本管理体系；接着是存储成本优化和计算成本优化技术细节；最后是总结与展望。
背景与挑战
我先从货拉拉业务背景出发，介绍整个大数据成本管控的挑战。货拉拉业务线较多，其中包括拉货、搬家、大车、跨城、卖车等，所有业务覆盖全国多个城市，月活用户W+，并且货拉拉大数据跨越了三个IDC，其中包括华为云、阿里云以及自建的机房；另外，机器数存储量和日均任务规模相对较大。
讲完业务，谈谈大数据体系。货拉拉大数据架构共六层，最下面是基础层和接入层，提供最基础的数据存储、计算以及接入的能力；接着是平台层和数仓层，平台层提供了数据研发、运维以及数据治理等能力；数仓层包含数仓分层模型和集市层，以及面向应用场景的标签画像体系、指标体系和特征体系；再向上是服务层和应用层。整个大数据架构是自上往下、相互依赖的体系，由此引发的成本管控治理也会比较复杂。
就货拉拉大数据成本管控挑战而言，主要有三方面，场景多样性、数据资产多样性、成本管控挑战。
首先是场景非常多样。货拉拉大数据存在离线、在线、以及实时三种主要的场景。上图是三种场景的计算量在一天24小时内随时间波动的趋势。首先，不管是离线、在线还是实时，都有明显的波峰波谷现象；其次，三种场景的计算量高低峰时间不一样，离线高峰期是零~六点之间，实时的高峰期在白天。如果大数据计算集群是固定大小，就会出现低峰期的浪费情况，并且由于在线、实时和离线是不同集群低峰期也不能互相借用资源。
其次是数据资产的多样性，上图是货拉拉数据流架构图，它分为数据采集、数据存储和计算、数据服务三个阶段。
第一，数据采集有实时采集和定时离线采集，这里会存在采集任务的数据资产信息；第二，实时的数据存储和计算会涉及实时数仓、实时计算以及实时在线存储，最后可能会直接推送到线上服务使用，这里会涉及到像HBase、Kafka、MySQL等各类表数据资产信息；第三，在离线的计算场景中，数据资产会有离线任务、Hive表、数仓表、数据指标标签和特征等数据资产信息。第四，最右端的数据服务，会涉及到数据接口以及报表等数据资产。以上10余种的数据资产信息都需要消耗成本，因此需要被统计被治理。
详细来看，成本管控挑战如下：
第一，单均成本飞涨。上图显示，在未经治理之前，成本和单均成本都呈现上涨的趋势。货拉拉这里强调单均成本，它是指每个订单中所含的大数据IT成本，我们认为，单均成本应该随着业务量的上升，呈现持平或下降优势，否则不具备规模经济的优势；但图中可以看出大数据单均成本逐渐上升的趋势；第二，成本是谁花出去的？大数据呈现平台性质特征，实际上成本的消耗方应该是大数据支撑的真实的业务方；第三，成本使用是否合理？大数据的成本水位是否健康，当时很难说的清楚。
货拉拉成本管控的思路如下：最开始是数据资产的梳理和成本分摊，这主要解决成本的度量和分摊问题；接着对真正使用到大数据成本的相关业务方，建立预算制的申请和管控制度。业务方需要根据业务价值，在年初提出每年的预算额度，作为当年的（增量）成本上限；接着当大数据成本进行分摊和预算制施行之后，大数据便由成本消耗方成为了平台支持方，我们通过提供存储和计算的辅助治理手段，来为业务提供成本治理的方法，比如说表删除能力、生命周期能力、归档能力等。通过以上几个阶段，具备了基本的成本管控能力；接着大数据部门利用大数据领域的技术优势对成本进行深度优化，帮助业务来进一步降低成本；最后，由大数据牵头提出基于健康度的成本运营机制，帮助存储和计算的资源保持在健康水位。
大数据成本管控体系
详细的成本管控体系共有四部分，数据资产度量、资源预算、辅助治理、持续运营。数据资产度量指从资源池、成本、以及健康度方面进行数据搜集，为后续成本管控提供支撑；资源预算包含预算的申请、使用跟踪以及预警和限制；辅助治理包括离线存储和计算两方面的治理能力；持续运营会根据成本健康程度提出来红黑榜单，配备响应的奖惩措施。
整个预算管控流程，先从成本分摊开始，货拉拉将资源消耗较大的前五名纳入到成本预算制度中，确认各业务方当年资源上限，每月进行成本跟踪与预警，如果连续一个季度超额，就将进行预算限制措施。预算限制措施包含禁止新建任务与表等，等待成本下降到上限之后，再解除限制措施。最后进行成本年终复盘。
上图是某部门预算跟踪示意图，我们将预算按照一定的口径拆分到每月，从图中可以看出，业务部门在三月超出了当月预算，此时进行预警，经过业务部门处理之后，解除预警。后来，在八九十连续三月超出了预算，则会进行预算的限制措施，这时要求业务部门快速治理，然后恢复后给再解除限制措施。当然如果有特殊情况，也可以通过财务以及高层审批补充额外的预算上限。
数据资产度量方面，货拉拉将所有数据资产类、基础设施类信息数据，统一收集到数仓建立平台数仓分层架构，然后对其进行加工处理，产出成本明细、资源明细、成本账单、健康信息等集市层数据，以此来支撑资源优化、存储治理、冷热分层、成本运营等场景。
存储成本优化
货拉拉的存储，当时遇到最大问题是存储量增长较快并且控制不住，当年2-9月时间数据量增长了三倍；与此同时，冷数据也在同比增长。这些冷数据可能是可以删除的，删除不了也不应该跟热数据占用一样的存储价格。例如云存储提供了数据归档能力是比较适合冷存储的。
针对这个问题，我们首先进行冷热分层，将冷数据进行区分标识；其次建立系统能力，例如，数据归档能力、数据温度显示能力、数据生命周期过期删除能力等；最后，大数据部门牵头进行存储治理，涵盖冷数据归档、数据生命周期治理、无用表下线删除等。
货拉拉进行冷热分层的依据是云存储数据归档收益曲线，我们将最近90天被访问次数的数据进行分类，通过上图可以看到，最近90天被访问零次的归档收益为50.87%，这类数据占比较高，存储归档收益相对较高，被访问一次或者两次的数据归档收益相对较低。因此，我们将90天内被访问次数作为分层的界限。90天内被访问次数为零次的数据定义为“冰数据”，90天内被访问次数1-2次的数据定义为“冷数据”。
当每个数据有温度标识之后，可以针对性地进行处理。对于冰数据，强烈建议用户进行优先删除其次归档；对于冷数据，可能会建议用户进行归档；对于热数据，（未来）可以进行缓存化处理，做计算提速。
讲过冷热分层思路之后，接下来介绍冷热分层技术架构。货拉拉根据SQL查询的记录和存储底层访问的审计日志，综合收集并进行合并，来确定数据表分区级的热度信息，接着推送到Elastic服务层存储。最后，冷热分层管理服务支持温度展示、数据归档、数据归档恢复，以及数据生命周期的过期管理等。
表数据随着时间的流逝越来越冷，我们为表设定了两个属性，生命周期和归档周期，来实现自动化的过期归档和过期删除能力。图中示例生命周期为天，只要到天过期的数据就会被删除；归档周期为90天，90天-天之间的数据将被归档。这里提一个细节，如何计算数据已存活时间，就选择数据当前时间而言，实践上表名最合适的口径是分区的业务时间（例如pt=YYYYMMDD分区中的YYYYMMDD）；非分区表方面，利用表的修改时间与最后访问时间，取一个最大值。
接下来是存储的优化治理，其中包含了生命周期治理、数据归档、文件压缩格式算法升级、专项深度治理、数仓的专项深度治理。这里主要提一下文件的压缩格式的算法升级。
货拉拉的文件默认使用Snappy格式压缩，测试表名如若改为Zlib压缩，会节省25%~30%空间。对于时延要求不敏感的场景，我们全量推行了Zlib压缩方式；对于延迟要求敏感的某些核心表，我们通过研发Zstd来达到压缩比和解压缩速度的双重收益。（Zstd压缩算法优势是压缩比高，同时解压缩速度与Snappy持平比Zlib快很多，是一种比较好的压缩方式。）
货拉拉存储优化的效益明显。在优化之前，存储线性增长较快，优化之后，存储8个月零增长并持续下降，累计节省了54%的存储成本，预估每年节省成本（包含增量收益）在千万以上。
计算成本优化
分享过存储优化之后，我们看看计算成本优化。上图是离线和实时集群的资源利用率趋势图，其特征有如下几个：波峰波谷特征明显、资源特征不同、任务分布集中。如果集群按照高峰期资源需求固定下来，那么，低峰期之时便会浪费很多资源。通过测算，大概计算资源的会浪费20%-30%左右。
为了解决这个问题，我们提出了弹性计算资源管理项目。弹性计算资源管理是通过三个手段协同来实现的，首先是自研弹性扩缩容服务，实现高低峰资源弹性管理机制和策略；其次是利用公有云按需/竞价类型实例，实现弹性资源池；最后是通过Yarn调度改造实现高优作业的保障。
在弹性资源池方面，公有云常常会提供三种实例，预留实例、按需实例、以及竞价实例。预留实例，单位成本相对比较划算，不过它是按天或按月收费，它适合做固定保障资源池，按需实例单价比较高，它适合分时弹性的资源池。但是竞价实例，竞价实例单价非常低，但是它随时可能会被抢占。所以货拉拉充分利用这三种的资源池，我们形成了弹性的资源池。
上图中绿色的线是预留实例，蓝色的线是竞价实例，黄色的线是按需实例。待低峰期过去，可以通过按需实例、竞价实例进行缩容；如果有临时非高优先级的任务需求，可以弹起竞价实例，因为这些任务可以容忍抖动；等高峰期来临的时候，可以通过按需实例和竞价实例进行扩容，高优任务，通过Yarn调度改造会尽量调度到预留和按需实例上，避免竞价实例抢占引起的抖动。
除此之外，基于公有云资源池，通过自研弹性服务，支持定时或者触发式的扩缩容策略、机制的管理以及按需实例的补偿，由此，可实现了集群按需的动态伸缩能力。通过这些措施，整体集群成本下降20~30%，与此同时，高优作业也不受影响。
不过弹性资源管理仅仅解决了逻辑资源利用低问题，它没有解决物理资源利用率的问题。我们通过上图中其他措施解决这个问题。其中比较有效的措施是计算超卖。
不管是离线，还是实时集群，当逻辑资源打满之后，物理CPU利用率在50%以下，实时集群甚至在20%左右。解决方法是，首先，我们根据集群逻辑资源打满情况，确认物理资源水位的超卖空间，接着通过YarnDynamicResource刷新NodeManager逻辑资源上限实现超卖，我们可能按照10%、20%、30%阶梯式提升超卖比例，然后，观察CPU利用率和LinuxOOM的情况，持续调整最佳的超卖比例。最后，我们实现了离线和实时集群逻辑资源都超卖了25%，换句话说，如果一个月花万的计算集群，可以当作每月成本万的集群来用。
计算超卖需要注意一些细节。
比如当Linux系统OOM比较严重之时，一方面，任务会不停的抖动；另一方面，重要的Container会被Kill掉。我们可以通过内核日志分析OOM频率和机器分布，观察超卖临界点；其次，我们可以对重要的Container定时设置OOM分数，实现OOM保护。
另外，有时候，当单个机器物理负载比较重会导致任务变慢，我们可以利用了YARNNMunhealthy反压机制来降低负载。例如，当CPU持续达到警戒值例如%，触发unhealthy，不分配Container，从而降低单机负载热点。
关于计算超卖的后续改进。现在超卖只考虑的CPU和内存，后面可以考虑更多维度，例如IO、Kernel等等。
最后，再分享一个我们提升物理CPU利用率的措施。很多数据平台推荐Hive计算Container内存大小是4GB/核，不过实际生产使用过程，我们发现Container大多数用不到4GB，我们希望将整体内存的大小降低，这样每个机器可以跑更多的Container，从而提升物理CPU利用率。不过当调低之后，可能有少数作业会出现JavaOOM现象，我们开发了参数灰度的能力，它可以实现分队列的参数个性化设置。对于普通队列，可以激进地下压，即使出现OOM现象，第二天进行治理就可以，目前已经整体缩小到2GB/核；对于相对核心任务，我们比较谨慎，目前优化到3GB/核。
上述措施之后，Hive任务资源消耗降低了15%，这等同于将计算集群扩容了15%。其他提升物理CPU利用率的措施还有直接改变云服务器机型CPU内存配比，例如CPU内存比从4GB/核提升到到8GB/核，也非常有效。
总结
回顾整个分享，货拉拉将成本管控体系分为预算和管控、辅助治理、持续运营和技术优化。
通过预算和管控，可以实现数据资产度量、成本分摊，清楚了解成本使用业务方、预算上限以及定期进行预算跟踪和预警限制等；通过辅助治理能力，帮助业务方实现冷数据、计算任务的浪费情况和业务价值查看能力，从而业务方以此为依据进行成本治理如冷数据过期删除或归档、计算任务下线等措施；通过技术的持续优化，例如弹性资源管理、计算超卖与内存优化，以及文件压缩算法的升级等帮助业务方进一步提效降本；最后通过持续运营，让成本水位保持在健康的状态。
最后分享一些成本管控的思考。
首先，成本目标需要依靠于体系化的建设，才能避免盲点实现收益最大化。当货拉拉刚开始进行成本治理时，以离线治理为主，后来整体梳理之后，我们发现一个盲点是HBase集群竟然占总成本占比也很高，然后快速通过机型的降配和缩容等操作，节省了HBase近30%成本，因此，成本管控需要依靠体系化的梳理和建设。
其次，当公司的初期，业务方不是特别多的情况下，保姆式运动式的治理效果更好、更快。但是当公司规模增长，业务线和业务方繁的时候，就需要通过预算管控，以实现业务的自助式治理从而达到持续控本目标，这样做大数据团队可以释放更多精力进行一些技术相关的成本优化探索。
第三，大数据团队在其中一个重要使命是希望通过技术手段和基于健康度的运营等手段实现对业务损伤小、相对透明化的成本优化和控制，我们不希望用迫使业务方减少机器或者减少任务等粗暴的手段实现这个目标，成本的限制仅仅是兜底的措施。
最后，大数据场景多样性且有个性化特征，成本优化需要持续精进不断地探索。例如之前降到的弹性资源池和扩缩容能力，是因为许多大数据场景对延时不敏感，大家可以结合竞价实例来降低成本。另外，冷数据也可以利用公有云的低频存储、归档能力甚至是深度归档能力，实现更精细化的管理。
今天的分享就到这里，谢谢大家。