网易云音乐实时数仓控制优化通常

一、现状和疑问

云音乐数仓平台曾经上线经常使用超越6年期间，目前累计用户（包括离任人员）超越700人，每日UV超越200，触及数仓开发、数据产品、剖析师、算法、业务开发、QA等简直一切角色的开发人员。笼罩了音乐一切的业务线，一些典型的业务类型包括索引构建、特色开发、内容监控，以及报表、线上统计等。云音乐业务开展到当天，一切部门的业务都离不开大数据处置。一切的开发多多少少都会接触到大数据处置。目前平台上实时义务有1600+ ，离线义务有 7000 到 8000 之间，80% 以上的义务都是 SQL 义务。目前整个云音乐的集群规模，纯计算节点大略有2000+ 台机器，每天原始日志量超越千亿级别。

平台的树立思绪是宿愿成为衔接技术和业务的桥梁，整合技术和业务，经过平台让数据被更高效地用起来。咱们的定位是云音乐这个垂直业务的数据平台团队，需求方更多是音乐外部的需求，并不是通用的团体需求，因此与团体平台或许通用云服务上数据平台相比，咱们更贴近业务，工具也更业务化。不同于普适的数据开发平台更偏差于放开通用才干，不会依据业务的流程规范做定制，咱们须要依据外部的规范和需求定制化平台才干，须要深化到业务当中去，了解业务的需求和开发的痛点，提供整套的处置打算，同时咱们也更关心业务方的老本，宿愿全体的经常使用愈加经济，替业务省钱。

咱们全体的才干构建于集群服务之上，团体服务提供了通用的数据处置和控制的能才干，对比实时义务开发平台sloth，基于Flink，提供了通用的实时数据处置才干，允许SQL处置实时数据；离线开发平台猛犸提供了通用的离线义务提交、调度以及管控的才干，允许MR、SparkSQL、Jar、HiveSQL等多种义务类型；元数据中心提供了通用的数仓元数据控制才干，血统追踪才干；安保中心，基于Ranger提供了通用的权限控制的基础才干。在团体提供的完善的基础才干之上，咱们依据云音乐外部的规范以及需求做了封装和定制，把业务规范做到平台上、整合最佳通常，让用户以更低的门槛和老本，以更高的效率和品质在平台上成功业务需求数据处置上班。

目前平台 80% 以上的义务都是平台上定制组件来成功的，关于平台的义务，咱们可以更好地了解义务的业务需求和特点，同时对用户义务的管控度也会比拟大，可以愈加繁难地在用户无感知的状况下批量地启动优化，成功开发品质的优化，这关于前面的控制上班是一大助力。当然这也是一把双刃剑，更多的成功和干预，也会带来更大的运维压力，关于团队人员的开发品质和才干也是一大应战，须要愈加片面地思索组件的各种运行场景。

咱们启动控制是基于以下一些要素。

二、控制布局

控制布局重要分为四大块：

要做哪些事件，如今状况是怎样的，做到控制对症下药，极速高效地拿到结果。

存量历史义务多，初期咱们须要一些人肉的举措来静止式地推进控制举措，极速拿到数据结果，降落全体水位。

在静止式控制的环节中，咱们也做了技术优化，来优化义务的资源经常使用，优化义务的稳固性，降落全体计算集群资源的水位、以及Kafka集群的水位。

以上三局部事件做完，咱们还须要思索控制上班可继续开展，不是一锤子交易，同时也不能不时靠堆人力静止式控制的方法来处置疑问，咱们宿愿能够把静止式控制的主动收益，转化成用户主动触发控制行为的主动收益。

为了摸清现状，咱们做了以下一些上班：

和团体底层团队协作，整合团体的资源监控服务Smildon ，实时失掉集群一切义务的资源经常使用状况，统计一切义务经常使用的资源和老本，并将资源和老本间接换算成钱，经过前端实时的反应给用户。从用户角度看，用户可以对义务的老本有最间接的感知，在经常使用资源时会愈加审慎，同时在平台推进用户控制时，用户也会愈加配合。从平台角度看，可以取得一个全体的资源经常使用大盘，从资源经常使用多的义务开局控制，极速收敛资源水位。

同时咱们还搜集了义务并发和输入流量的相关，统计一切义务的单位并发的处置量，而后经过这个目的极速评价出平台全体的处置才干，经过这个值的大小，极速挑选发现出资源性能或许有疑问的义务，高效地启动优化控制。

为了控制每个部门资源的增长，咱们以部门为单位，整合从Smildon系统搜集过去的实时资源经常使用数据，构建逻辑的虚构队列，实时地统计每个部门大略用了多少资源，而后划定初始的限度，假设超越限度，就要走放开流程来扩容，经过这种流程上的手腕来控制它的增长（图示是一个虚构队列资源）。

有了上方说的数据目的就能极速把有疑问的义务筛进去，而后依据一切义务的资源的经常使用量，以及单位并发的处置才干等目的做倒排，极速优化控制相关义务，收敛资源，拿到数据结果。义务的控制上班重要分以下几类：

（1）第一：无用义务探查下线

这个操作的关键在于如何判别义务能否还在经常使用，目前咱们的判别依据重要有以下几点：

（2）第二：义务自身的资源不正当

经过前面提到的义务的单个并发处置数据量的目的，极速挑选出资源性能不正当或许性比拟大的义务，调整并发优化资源，由于咱们平台用户大局部都不是数据开发的背景，这种Case还是十分多的。

（3）第三：流量萎缩造成义务资源性能冗余过剩

还有很多义务历史流量很大，然而起初流量逐渐降落，然而义务资源没有相应的调整，也造成了全体资源的性能不正当，这个后续可以经过数据来记载义务历史处置才干，来判别全体资源的正当性。

（4）第四：技术优化

为了优化全体的资源经常使用，咱们还做了很多技术优化，比如Flink SQL的增强，参与一些额外的才干优化全体性能, Kafka写入的优化，经过写入的batch优化降落全体Kafka的水位，设计开发分区流表技术，优化流量经常使用，缩小无用的信息消费，降落全体带宽和全体计算资源，这些前面会做详细引见。

可继续开展指的是让控制上班变成常态化，目前这一局部性能还在开发中。咱们宿愿把前文中提到的规定落到控制平台，经过智能化的流程去推进用户，智能扫描出有疑问的义务，推进通知用户，让用户主动地做开发控制，让每团体都介入到控制上班中来平台方从静止式控制的主动收益，变成智能化的主动收益。

三、技术优化

接上去将分三局部来引见技术上的优化：Flink SQL优化、Kafka 的batch优化，以及咱们设计开发的“分区流表”的优化。

1、Flink SQL 优化

Flink SQL的颁布，大大降落了实时计算的开发门槛，优化了开发效率，然而它也带来了一些疑问，SQL面前逻辑的不透明，让用户能够控制的物品也变少了，这造成了一些不用要的计算逻辑，同时用户能做的优化手腕也变少了，这造成了两边有很多的资源糜费。上方咱们经过一些Case来说明。

（1）Case 1 : 信息反序列化前置优化

背景：日志信息格局为userid\001os\001action\001logtime\001props。Props 是 JSON格局，所以在读取流表的环节中大局部性能损耗都在JSON 的解析上。离线的场景下咱们可以做列裁剪，只读须要的数据，然而在实时状况下，还没有那么成熟，不论咱们须要不须要props这个字段，FlinkSQL自身都会对整条信息做解析，这造成了很多的资源糜费。

为了处置这个疑问，我在反序列化上做了一些优化，用户可以经过一些性能在解析完整日志前做一些过滤，比如上图中的这两条SQL的对比，在解析整条信息之前，经过keyword性能做关键字过滤，将不蕴含‘user-fm’关键字的信息所有过滤掉，在解析props之前，经过os.list和action.list过滤掉多余的信息，经过这些性能可以缩小少量无用信息的解析，大大优化全体义务的性能，降落CPU的消耗。这些优化在很多状况下效果十分显著，极其状况下能缩小50% 以上的性能损耗。

与离线场景下的列裁剪相似，按需解析，按需反序列化，这个优化还可以继续优化，如今还须要用户手动去性能，咱们最终的目的是依据用户的 Select 字段联合format的成功做智能的列裁剪优化。

第二个case是索引构建场景。很多索引是经过关联多张数据库表，生成大宽表，写入到索引引擎外面的，而后提供应前端用户去查问。大抵流程为，用户经过Flink订阅数据库的binlog日志来监听业务库的数据变动，而后把binlog外面关键数据和很多业务DB表启动关联，生成一个大宽表，最后再经过Flink写入到索引构建引擎外面，供用户查问。这里存在几个疑问：

两者联合就造成全体的处置性能不可做到水平扩展，无论怎样扩展Flink义务并发，一直也都只要10个并发在处置信息，造成义务的提前十分重大。

2、Kafka 的Batch 优化

前面曾经提到，咱们的Kafka集群不时处于水位比拟高的形态，高峰期水位到达80%，加上业务行将上线新的埋点体系，会带来三倍的流量增长。为了降落全体Kafka集群水位，咱们做了以下上班：

早期咱们这边Kafka的运维体系比拟粗陋，监控目的不够完善，造成咱们的优化上班难以下手，为了更好地了解Kafka水位高的要素，咱们参考了 Kafka 社区的打算搭建了十分完善的监控，取得了比拟完善的数据监控，给咱们的优化提供了方向，咱们经过监控的数据发现了上方提到的疑问。

一个Kakfa集群服务很多业务，每个业务有很多信息队列topic，每个topic又有很多partition分区，这些分区散布在集群的机器上，分区和机器的相关都是手动保养的，信息分区的散布不均，每个分区信息的流量大小也不相反，这间接造成了有些机器的负载比拟高，有些机器的负载低。这块目前的优化打算比拟繁难粗犷，经过监控直观地看到每台机器的流量状况，而后PE经过工具手动调整topic的partition散布状况，保证每台机器流量平衡稳固。这个疑问也是Kafka开源版本普遍存在的疑问。未来会思索把Kafka 交流成 Pulsar，经过存算分别的架构长处来处置这个疑问。

经过监控发现，以前的Kafka的水位矮小局部是由于处置线程池不够以及磁盘的 IO比拟大，然而全体信息量还好。深挖后发现，信息发送的batch size性能没有失效，很多时刻一次性发送只要一到两条信息，这样100条信息就要发送100次恳求，这会造成Kafka信息处置的线程水位十分高，磁盘IO的操作频次也是一样。然而为什么batch size的性能没有失效？调研发现Kafka batch 与batch size 大小的性能、 以及liner.ms最大容忍提前期间这两特性能无关，liner.ms的自动性能为0，然而当咱们优化了这特性能，batch效果还是不显著，最后咱们发现还与producer partitioner的战略有相关。

Partitioner优化战略思索以下几点：

在三者之间要做 trade Off，太大的话会影响提前，太小的话整个 IO 也会不行。Kafka在2.4版本里引入了新的 Partition战略：Sticky Partitioner ，在公共的Partitioner接口中参与了一个新的 onNewBatch 方法，每次创立新的 Batch的时刻会调这个方法，在这个方法调用时， Sticky Partitioner 会随机选用一个分区，而后将一切的信息都会放到一个Cache 当中，在下一次性OnNewBatch 的时刻会把Cache中一切信息打包成一个batch发送到随机选用的那个分区当中，下一次性再随机选一个分区，继续积攒信息到Cache中而后打包发送，这种战略既保证了分区的平衡性又保证了Batch效果的最大化。经过通常测试，经过Sticky Partitioner的Batch战略带来的性能优化十分显著，整个Kafka集群的水位从80%降落到了30%。

3、分区流表优化

（1）数仓的处置流程

在离线场景下，咱们可以经过列存储、分桶、分区、索引等诸多手腕来缩小不用要的数据读取，从而优化程序的性能。为了降落全体实时集群的经常使用老本，扛住新埋点三倍的流量冲击，咱们参考了 Hive 的分区设计，成功了一套实时分区流表的设计。

上图是一个比拟惯例的实时数仓的处置流程图，反常的日志处置流程包括 DS 归档（网易外部服务，搜集日志到Kafka和HDFS），而后经过Flink荡涤格局化到ODS层，再到DWD层，业务运行程序消费DWD，消费出ADS层给下层运行提供服务。整个流程中，ODS 的日志量十分大，在开发DWD的时刻，须要消费全量的ODS层的日志，假设ODS层日志流量大小是700M/S，那么下游一切的DWD的义务都要消费这700M/S的流量，要处置这么大的流量，大略要900Core资源，相当于9台最新性能的物理主机，每多一个DWD表义务，就须要参与9台物理主机。另内在这么大流量的状况下，义务的稳固性不可保证，任何一波日志的动摇，都会对下游义务发生比拟大的影响，Kafka的压力也会十分大，老本也不可接受。

（2）历史打算

咱们以前的打算是在源头上对原始日志做拆分，经过独自散发程序，按业务需求将原始日志拆分红不同的Topic，业内一些公司也是也是这么做的，然而这种做法有如下疑问：

① 运维老本高，拆分粒度相对较粗，下游还是有必定水平的流量的无用消费，前期拆分也比拟艰巨。

② 用户在经常使用实时流表的时刻须要很多的先验常识，须要了解信息的散发规定读取正确的流表，经常使用老本高。

③ 实时数仓的建模和离线不能一致，前期假构想做批流一体，实时数仓和离线数仓没法做到Schema的分歧，继而也没法做到一套代码同时允许实时和离线。

④ 不可迁徙复用，在源头独自做一个定制的散发程序，下游消费的散发后数据有或许存在流量大的疑问，下游用户没法轻松的复用这套打算，不能够继续发生价值。

（3）分区流表优化

咱们参考Hive表的分区设计，从新设计了实时流表的元数据结果，让实时流表也有分区的概念，分区元信息中蕴含分区和Kafka topic的映射相关，而后咱们定制修正了Kafka Connector，依据流表的分区元信息，写入流表时依据信息中分区字段的内容和分区的元信息将信息写入到不同的topic当中。读取流表时，咱们在Kafka Connector的基础上成功了分区下推，会依据用户查问SQL中分区条件，智能推断出须要的分区topic，裁剪掉不须要的分区topic，缩小不用要的信息读取，缩小资源糜费。

有了分区流表，咱们就可以把DS归档过去的日志，下游一切的DWD义务都能够在无感知的状况下享遭到分区流表带来的流量优化的红利，用户不须要关注太多，定好分区规定，经常使用SQL 读写，不须要构建独自的程序做散发，复用的老本十分低，下游的大流量的 DWD 层表的树立也可以以很低的老本复用分区流表技术，做到全体流量的缩小。

四、未来布局

未来布局，重要是两块：大数据容器化变革和智能化控制平台。

1、容器化变革

咱们宿愿经过容器化变革取得以下几方面的才干：

在Yarn环境下，咱们只能经过yarn.containers.vcores做一些资源精细化的资源调整，然而全体粒度较粗，在K8S上可以做到1/1000Core粒度，资源性能愈加精细化，愈加灵敏。

在Yarn环境下，由于没有很好的资源隔离性，自身也不足container级别的资源应用率的详细目的，造成咱们很难从机器负载、CPU应用率、内存应用，带宽经常使用等微观目的来评价义务资源经常使用的正当性；在K8S环境下，领有比拟好的资源隔离性，以及完善资源目的，咱们搭建义务级别的微观监控体系，参考普通web运行程序，经过CPU 应用率、 IO 应用率、内存应用率等微观监控极速评价出Flink运行的资源放开的正当性，极速控制优化。

K8S自身可以定制十分灵敏的调度战略，繁难咱们依据义务特点选用不同类型的机器；还可以和其它类型业务（如机器学习、在线业务、离线计算等）的资源混合部署，到达全体资源应用率的最大化。

2、智能化控制平台

正如前面提到的，咱们宿愿经过搜集数仓、义务、用户平台要素的元数据，构建元数据仓库，在元数据仓库的基础之上，经常使用这些元数据启动规定性能。在开发上线前，经过规定启动一些非法性的校验，如SQL能否规范、报警能否完备等前置审核；服务中经过规定活期扫描，智能发现疑问，如资源能否正当、能否可以下线等，智能化地推进用户启动控制；义务控制应前回收控制效果，经过晒控制结果构成红黑榜，构成一个良性的闭环。

五、Q&A

Q1：有基于分区流表做一些流批一体的上班吗？

A：咱们如今的打算都是经过构建一层数据模型层，数据模型层会关联离线数仓表和实时数仓表，在离线场景读取离线表，实时场景读取实时流表。前面提到的分区流表的技术处置了实时数仓表单表流量过大的疑问，做到了离线数仓和实时数仓建模的一致，所以在数据模型这一层就很容易做到了一致的映射。

文中提到了一个 FastX 的开发工具，是一个基于数据模型的低代码的开发上班，可以在FastX控制数据模型，而后在数据模型的基础上经过低代码的方式做性能化的开发。经过低代码的方式生成一套一致的计算逻辑，成功一套逻辑性能，在流批两套环境下运转。

Q2：怎样屏蔽SQL的不同

A：FastX会经过低代码性能化的方式消费一套一致的DSL，在实时场景下会选用实时数仓的数据源，而后将DSL生成实时的FlinkSQL，离线状况下选用离线数据源生成Spark SQL启动执行。下层交互是有限的，全体的算子也是可控的，所以咱们逐渐笼罩业务场景，成功一套逻辑，同时跑在离线和实时环境上。目前FastX定位是一个基于业务场景的开发平台，做全场景的必需很难，咱们宿愿依据二八准则，能够笼罩80%的业务场景。

Q3：实时数仓控制跟离线数仓控制在方法论上有哪些异同点？

A：方法论上觉得是差不多的，然而实时数仓与离线数仓相比，开展期间还比拟短。离线数仓控制上有很少数据目的来评价数仓的品质，比如穿透率、复用率、闲置滤等来评价数据资产的好坏，会朝着这些量化的目的来做数据仓库结构上的优化。在实时场景下，数仓的结构还比拟繁难，档次比拟少，普通不会在实时场景下建 DWS 层，顶多是 ODS 层到DWD 层，而后再到业务层，构建 DWS 层老本也十分高，存储也很难选。自身实时场景的Flink义务对资源以及稳固性、提前等都比拟敏感，必要的时刻，数仓树立的规范须要给资源性能退让，所以在实时数仓的控制上咱们更关注稳固性、资源的控制。