共计 6041 个字符，预计需要花费 16 分钟才能阅读完成。
作者：vivo 互联网实时计算团队 - Chen Tao
本文依据“2022 vivo 开发者大会 ” 现场演讲内容整顿而成。
vivo 实时计算平台是 vivo 实时团队基于 Apache Flink 计算引擎自研的笼罩实时流数据接入、开发、部署、运维和经营全流程的一站式数据建设与治理平台。
一、vivo 实时计算业务现状
2022 年，vivo 互联网在网用户总数达到 2.8 亿，多款互联网利用的日活超过了千万甚至冲破了 1 亿，为了向用户提供优质的内容和服务，咱们须要对如此大规模的用户所产生的海量数据进行实时处理，帮忙咱们进行经营决策、精准举荐、晋升终端用户体验，同时通过晋升咱们的商业化能力为广告主提供更加优质的广告服务。
近几年，大数据实时计算技术和公司的实时数据业务都在飞速发展，截止到往年 8 月，vivo 实时计算每日解决数据量达到 5PB，无效工作数超过 4000，目前已接入 98 个我的项目，从趋势上来看，每年都有超过 100% 的规模增长，如此大的业务规模和业务增速给咱们实时计算团队带来的十分大的挑战。首先，咱们要确保业务的稳固，高速增长的数据、简单的业务场景和零碎架构须要咱们自底向上的全方位的稳定性建设；为了帮忙用户疾速落地业务，咱们须要升高开发门槛，提供良好的易用性和笼罩各种场景的性能个性，业务的高效接入和运维能带来长期的降本收益。同时，大规模的数据和计算咱们也心愿可能以尽可能低的老本去运行，这就须要咱们提供高效的存储、计算能力，并且对于许多要害业务，实时计算时效性保障的要求也十分高。在简单的数据环境中要保障数据安全须要有十分良好的且具备前瞻性的设计，优良的平安能力须要可能提前防备可能的危险。
咱们从 2019 年下半年启动了实时计算平台的建设，2020 年关注在稳定性建设，初步上线了 SQL 能力，2021 年引入了 Flink 1.13 版本并启动了容器化建设，2022 年次要关注在效率晋升，包含流批一体、工作诊断等，到目前为止，咱们平台已初步具备了一些能力，所以明天我代表咱们团队简略给大家介绍一下咱们的平台建设实际。
二、实时计算平台建设实际
从咱们大数据平台的体系架构上来看，咱们通过汇聚层能力收集整个 vivo 互联网的埋点、服务器日志，通过计算、存储、剖析等能力从海量数据中挖掘出业务价值。实时计算作为平台的外围能力之一，它同时满足了大规模数据计算和高时效计算的需要，咱们通过实时计算平台来承载和向业务提供这方面的能力。
vivo 实时计算平台是基于 Apache Flink 计算引擎自研的笼罩实时流数据接入、开发、部署、运维和经营全流程的一站式数据建设与治理平台。接下来我会从根底服务建设、稳定性建设、易用性建设、效率晋升和平安能力建设五个方面来介绍咱们团队的建设思路和实际过程。
2.1 根底服务建设
咱们自研的实时平台后端架构包含两个 外围服务：
- SubmissionServer：负责作业的提交，以及跟资源管理零碎的交互，具备高可用、高可扩大能力，反对多版本 Flink 和多种工作类型。
- ControlServer：负责工作运行状态的保护，咱们定义了 9 种工作状态，通过一个内置状态机进行实时的状态保护，状态的更新提早在秒级。
根底服务还包含对立的元数据服务和实时的监控告警服务。这两个局部做一下简略介绍。
咱们应用 HiveMetaStore 作为元数据根底服务，基于 TIDB 的扩大能力，以后元数据实体规模已达到亿级，通过对 MetaStore 服务的优化，大分区表操作性能晋升了 10 倍，目前已接入 Spark、Hive、Flink、Presto 等引擎，同时，对立的权限管制、数据分类分级、数据血统、元数据变更记录等能力也为数据治理提供了良好的根底。
咱们基于 Flink 的 CEP 能力构建了一套秒级提早、反对动静规定配置的监控告警零碎，同时从基础设施、根底服务、实时工作和业务多个维度构建了全方位的监控体系。以上这三个方面形成了咱们的根底服务。根底服务都具备高可用个性，然而要保障业务稳固，还须要关注整个零碎以及在零碎上运行的业务数据链路，这里最重要的有两个方面：大数据组件服务的稳定性和工作自身的稳定性。
2.2 稳定性建设
咱们应用 HDFS 作为状态的长久存储和业务数据落地的存储，随着存储规模和读写量的增长，咱们遇到了 DataNode 的 StaleNode 问题、低版本 HDFS 流式写无奈复原问题和越来越重大的小文件问题，为此咱们通过平滑降级 HDFS 到 3 版本、优化 Flink Sink 性能和基于 Spark3 建设小文件合并服务来解决这些问题。
Kafka 是次要的流存储组件，然而在集群运维上存在一些痛点，比方扩缩容和节点硬件故障会导致资源不平衡和生产生产的异样，Kafka 团队建设了流量平衡和动静限流能力，显著晋升了 Kafka 服务的稳定性，同时咱们也晋升了 Flink 对 Kafka Broker 重启的容忍度，可能无效缩小 Broker 故障对运行工作带来的影响。
另外，Flink 工作的高可用依赖于 Zookeeper，为了防止 ZK leader 切换对实时作业的影响，咱们对 1.10 和 1.13 版本的 Flink 进行了容忍度加强，对更低版本的工作做了版本升级，也依据社区教训优化了 Flink HA 局部的性能，以及增强了对 ZK 的全面监控和治理，保障了 ZK 的稳定性。
通过这些对相干组件的优化措施缩小了工作异样工夫和次数，无效的晋升了工作稳定性。接下来介绍一下咱们针对某种特定场景的 Flink 工作稳定性优化实际。
在内容实时举荐场景，产生自在线预估服务的用户特色快照须要与用户实时数据进行拼接，因为数据量微小在做 Join 时须要一个大缓存，相比于原来采纳 Redis 作为缓存的计划，Flink 的 RocksDB 状态后端是一个更适合的计划，然而在状态大小达到 TB 级别时，工作稳定性很难保障。咱们基于对 RocksDB 内存模型的深刻理解，扩大原生监控指标，降级 RocksDB 版本，建设了状态治理相干能力，把工作稳定性晋升到了生产可用级别。在多个业务场景上线后，样本和模型的时效性和稳定性失去保障，举荐成果失去很大晋升。
后续咱们布局通过减少读缓存和优化前缀匹配策略进一步晋升 RocksDB 状态后端的性能。
咱们始终在思考如何进一步晋升业务的稳定性，绝对于工作的稳定性咱们的用户更加关怀他们所须要的数据是否准时、数据品质是否合乎预期，而工作的稳固不齐全等同于时效和品质。在时效这个维度咱们定义了数据准时率的 SLI 指标，这对咱们有两方面的指引：更自动化和精细化的故障分级保障和流计算的弹性能力的建设。其中前者正在建设中，后者也在咱们的布局之中。
2.3 易用性建设
从 实时作业 开发角度，
咱们提供了功能完善、体验良好的 FlinkSQL 开发环境。相比于社区版本 Flink，咱们对 SQL 能力进行了扩大，比方更加可控的窗口计算触发性能，兼容性更强的 DDL 性能，更加不便的流表创立性能，咱们对 Format、Connector、UDF 都做了一些扩大和优化，实用于更多业务场景，晋升了性能；同时咱们建设了运行于 Standalone 集群的 SQL 调试能力，具备数据抽样、上传、DAG 图展现、调试后果实时展现等性能。通过一年的建设，新增 SQL 运行工作占比从 5% 晋升到了 60%。
从 实时作业运维 角度，
咱们提供了实时全链路的血统与提早监控性能。为了实现数据业务，实时计算链路往往是很长的，而一个团队个别只负责其中一段，为了解决链路中呈现的问题，可能须要上下游多个团队配合，效率很低。咱们作为平台团队为用户提供了一个全局的视角，这样能够迅速定位到异样工作节点，十分高效。血统数据能够实时生成，并且不须要工作的重启，因而不存在血统不全的问题。同时，咱们也能够输入端到端全链路提早数据和工作解决提早数据，帮忙咱们的用户做品质监控。
2.4 效率晋升
往年，降本提效是咱们的重点工作方向，咱们从计算、存储和资源治理三个方面做了一些工作，获得初步成果。YARN 资源管理的粒度较大，而 K8s 更精密的资源粒度从整体上来看能够无效晋升资源利用效率。YARN 尽管开启了 cgroups，然而对系统资源的隔离能力依然较弱，个别异样工作耗尽机器资源可能影响失常运行的工作。因而平台反对了 K8s 的资源管理能力，借助于 Flink 社区提供的 Native K8s 个性以及平台良好的可扩展性，咱们以后反对 JAR 工作的容器化部署，并且通过在开发、运维、资源交付等方面的建设确保了用户体验与 YARN 是统一的。借助于容器化，咱们能够确保开发、测试、线上等环境的一致性，研发效率也失去晋升。目前已接入 3 个业务，明年会比拟大规模的利用。
多年以来，大数据畛域在倒退过程中造成了批和流两套架构并存的现状，很多时候，业务在落地过程中不得不同时思考和投入建设两套链路。比方离线数仓和实时数仓独立建设，数据口径和计算结果的一致性保障须要付出额定的致力，Hive 表不反对数据更新、探查较慢，Kafka 数据回溯和查问艰难等问题也始终困扰着数据开发人员。
侥幸的是，业界曾经摸索进去基于数据湖组件在分布式存储之上构建流批对立存储的技术，咱们依据 vivo 的业务特点抉择并设计了咱们的流批一体计划，目前曾经实现基于 Hudi 的对立存储引擎、基于 Flink 的对立入湖、基于 HMS 的对立元数据建设，目前业务曾经实现试用并开始接入。往年咱们次要接入实时业务，明年会有离线业务的接入。这也是咱们大数据平台构建湖仓一体很重要的一步。
在长期的实时作业运维过程中，咱们积攒的大量作业调优和问题解决教训，随着运维压力的减少，咱们在思考如何晋升运维效率。咱们也发现用户资源队列用满的同时，机器的 CPU 利用率却处于较低水平，因而咱们思考如何缩小资源节约，晋升集群的资源利用效率。资源诊断和异样诊断这两类问题都是作业优化问题，要优化作业，首先须要把握作业及其运行环境的信息，包含运行指标、运行日志、GC 日志、依赖组件运行状况、操作系统过程级别信息，以及作业配置、环境配置等等，而后须要将运维教训和思路转化为启发式算法的规定和数据，使用这些数据、算法和规定去找到优化的办法。基于这个思路，咱们建设了一个诊断服务，具备灵便的信息收集、规定配置、数据调优性能，可能在作业启动或运行时，诊断作业的衰弱水平，提供一些作业的优化倡议给咱们的用户。目前资源诊断能力曾经在运行，异样诊断还在建设中。
2.5 平安能力建设
作为一个根底的大数据服务，平安在咱们看来是一个十分重要的命题，因而咱们在零碎设计之初就思考了实时数据拜访、离线数据读写、各个系统与服务之间的平安隔离能力等方面的设计，在实时数仓具备肯定规模后，咱们又建设了数据分类分级、日志审计等能力。去年，依据最新的合规要求，离线存储反对了列级别通明加密，实时数据反对了敏感字段自动检测等能力。平安无止境，咱们也在对 DSMM 进行钻研解读，以继续晋升大数据的平安能力。
以上是咱们平台建设的一些实际，总结来看，咱们基于 Flink 建设了性能比较完善的实时计算开发和运维能力，业务复杂度越来越高，咱们的挑战还有很多，比方 Flink 引擎的优化与难点问题的解决、计算效率的进一步晋升、流批一体、容器化的大规模利用等，都是咱们后续的重点方向。
后面有提到，基于实时计算平台，公司的多个中台团队建设了五大中台能力，笼罩了各种各样的实时场景，这里就跟大家简略分享下其中两个典型场景。
三、利用场景简介
3.1 实时数仓
vivo 大数据团队基于 vStream 平台建设的实时数仓服务笼罩了利用散发、内容散发、产品平台、商业化等多个业务线的报表、营销、举荐、决策、广告等多种利用场景。实时数仓沿用了离线数仓的逻辑分层实践，从数据源通过采集和 ETL 进入到 ODS 层，而后通过维度扩大、过滤、转换等操作进入到 DWD 明细层，而后是轻度聚合层 DWS，最初依照主题或业务需要计算出后果指标存入 ClickHouse 等 OLAP 引擎成为 ADS 层，为业务提供数据报表、接口或者数据服务。与离线有所不同的是，实时数据受限于数据达到工夫或业务对数据的要求，可能会有档次的裁剪，因而实时数仓也提供了中间层凋谢的能力。
实时数仓的一部分维度表与离线是共用的，并且为了与离线链路保障统一的数据口径须要将 Kafka 流表落地到 Hive 表进行数据的比对，离线与实时的互操作不是很不便，因而，数仓团队曾经开始基于流批一体能力建设准实时的数据链路。而后咱们看一下，实时计算是如何利用在内容举荐场景的。
3.2 短视频实时内容举荐
vivo 短视频是一个很火的利用，为了给到用户高质量的视频内容举荐，特地依赖于举荐模型的时效性以及用户特色计算的时效性，为了做到实时的模型训练，须要有实时的样本数据。因而实时特色计算和样本拼接在内容举荐外面表演了很重要的角色，vStream 平台提供的 TB 级别超大状态工作能力撑持了短视频以及许多其余利用的实时样本拼接工作。同时咱们也能够看到，在这个计划里，特色和样本都同时存在离线和实时两条链路，这是因为 Flink 的批计算能力目前还没有 Spark 成熟，基于 Kafka 的实时计算难以做到数据回溯，站在咱们大数据平台的角度，一方面咱们心愿可能缩小反复的计算和存储，另一方面也心愿平台的用户可能不须要反复开发计算和回溯的代码。在业界宽泛探讨的湖仓一体架构，很重要的一个方面就是为了解决这些问题。在前面的局部，咱们会再聊一聊湖仓一体。
实时计算的利用场景有很多，但实质上来说它的目标跟离线计算是一样的，就是为业务提供数据反对。从后面的介绍能够看到，以后基于 Hadoop 的大数据平台组件繁多、架构简单、流批反复、资源效率较低，那么咱们有没有方法或者说有没有心愿扭转这种现状呢？我认为是有的，最初分享一下咱们对将来的一些摸索和瞻望。
四、摸索与瞻望
咱们晓得，业务是弹性的，比方在一天之内总有用户拜访的顶峰和低谷，一段时间内总有业务的增长或降落。然而以后，不论是咱们的数据计算工作还是 YARN 集群的资源分配策略，都不具备弹性，首先，任务分配的资源是固定的，并且，为了尽可能防止计算受到业务稳定的影响，离线、实时和在线三种不同类型的计算别离运行在不同的物理集群。
因而咱们须要如下两种维度的弹性能力：
- 工作级别的弹性能力，咱们打算紧跟 Flink 社区，摸索其 AutoScaling 个性的利用。
- 集群级别的弹性能力，咱们会采纳 vivo 容器团队提供的在离线混部能力来实现。
刚刚咱们提到了湖仓一体，为什么须要湖仓一体呢？能够拿 BI 和 AI 两个大数据应用领域放在一起来看，流计算、批计算、剖析型计算和 AI 计算及其对应的存储系统别离解决各自的问题，并且因为倒退阶段差别，围绕这四种计算模式建设了大量的平台零碎和业务零碎，经营这个简单宏大的系统资源老本和人力老本都是十分高的。因而大家冀望通过对立的存储形象、对立的计算形象、对立的资源形象和对立的数据管理来建设一个 架构内聚、低成本、易于应用 的大数据系统。大家的冀望促成了云原生、数据湖、新一代计算引擎等技术的倒退，这些倒退也使得大家的冀望更明确更统一。
