1.vivo实时计算业务内容和服务现状，我们需要对如此大规模的用户产生的海量数据进行实时处理，以帮助我们进行运营决策，做出准确的建议，并改善最终用户体验。广告服务。近年来，大数据实时计算技术和公司实时数据业务发展迅速。截至今年8月，vivo实时计算日处理数据量已达5PB，有效任务数超过4000个。目前已接入98个项目，从趋势上看，年增长率在100%以上。如此大的业务规模和业务增长率，对我们的实时计算团队提出了非常大的挑战。首先，我们需要保证业务的稳定性。快速增长的数据、复杂的业务场景和系统架构，需要我们自下而上的全方位稳定性建设；为了帮助用户快速落地业务，我们需要降低开发门槛，提??供良好的易用性和覆盖各种场景的功能特性，服务的高效接入和运维可以带来长期的成本降低收益。同时，我们也希望大规模的数据和计算能够以尽可能低的成本运行，这就需要我们提供高效的存储和计算能力，而对于很多关键业务来说，实时计算时效性的要求是也很高。在复杂的数据环境下保障数据安全，需要非常好的前瞻性设计，优秀的安全能力需要能够提前防范可能出现的风险。2019年下半年开始实时计算平台建设，2020年着重稳定建设，SQL能力初步上线。2021年，我们推出Flink1.13版本，开始容器化建设。2022年，我们主要关注效率提升。包括流批集成、任务诊断等。到目前为止，我们的平台已经初步具备了一些能力，所以今天我代表我们团队简单介绍一下我们的平台建设实践。2.实时计算平台建设实践从我们大数据平台的系统架构来看，通过汇聚层能力收集整个vivo互联网的埋点和服务器日志，通过计算从海量数据中挖掘商业价值、存储和分析功能。.实时计算作为平台的核心能力之一，同时满足了大规模数据计算和高时效计算的需求。我们使用实时计算平台来承载和提供这种能力给业务。vivo实时计算平台是基于自研ApacheFlink计算引擎，涵盖实时流数据接入、开发、部署、运维、运营全流程的一站式数据构建和管理平台。下面我将从基础服务建设、稳定性建设、易用性建设、效率提升、安全能力建设五个方面介绍我们团队的建设思路和实践过程。2.1基础服务搭建我们自研的实时平台后端架构包括两个核心服务：SubmissionServer：负责作业提交和与资源管理系统交互，具有高可用性和可扩展性，支持多版本Flink和多任务类型.ControlServer：负责任务运行状态的维护。我们定义了9种任务状态，通过内置状态机进行实时状态维护。状态更新延迟为二级。基础服务还包括统一的元数据服务和实时监控告警服务。对这两部分进行简单介绍。我们使用HiveMetaStore作为基本的元数据服务。基于TIDB的扩展能力，目前元数据实体规模已达1亿。通过对MetaStore服务的优化，大分区表的运行性能提升了10倍。目前已接入Spark、Hive、Flink、Presto等Engine，同时，统一的权限控制、数据分级分类、数据沿袭、元数据变更记录等能力也为数据治理提供了良好的基础.基于Flink的CEP能力，我们构建了秒级延时、动态规则配置的监控告警系统。同时，我们从基础设施、基础服务、实时任务、业务等多个维度构建了完善的监控体系。以上三个方面构成了我们的基本服务。基础服务都具备高可用特性，但是要保证业务的稳定性，还需要关注整个系统以及系统上运行的业务数据链路。这里有两个最重要的方面：大数据组件服务的稳定性和任务本身的稳定性。稳定。2.2稳定性建设我们使用HDFS作为状态的持久化存储和业务数据落地的存储。随着存储规模和读写量的增长，我们遇到了DataNode的StaleNode问题，低版本HDFS流写入无法恢复的问题，越来越严重的小文件问题，我们解决了这些问题通过平滑升级HDFS到版本3，优化FlinkSink性能，基于Spark3构建小文件合并服务。Kafka是主要的流式存储组件，但在集群运维方面存在一些痛点。例如，扩缩容、节点硬件故障，都会导致资源不平衡，消费和生产异常。Kafka团队构建了流量均衡和动态限流能力，显着提升了Kafka服务的稳定性。同时，我们还提升了Flink对KafkaBroker重启的容忍度，可以有效降低Broker故障对运行任务的影响。此外，Flink任务的高可用依赖于Zookeeper。为了避免ZKleader切换对实时作业的影响，我们增强了Flink1.10和1.13版本的容错性，并对低版本的任务进行了版本升级。根据社区经验优化了FlinkHA部分的功能，加强了对ZK的整体监控和治理，保证了ZK的稳定性。通过这些对相关组件的优化措施，减少了任务的异常时间和频率，有效提高了任务的稳定性。接下来我们将针对具体场景介绍我们的Flink任务稳定性优化实践。在实时内容推荐场景中，需要将在线预估服务生成的用户特征快照与用户的实时数据进行拼接。由于数据量巨大，在做Join的时候需要很大的缓存。相对于原来使用Redis作为缓存的方案，Flink的RocksDBstatebackend是更合适的方案，但是当statesize达到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社区提供的NativeK8s特性和平台良好的扩展性，我们目前支持JAR任务的容器化部署，并通过开发、运维、资源交付等方式构建保证用户体验与YARN一致。通过容器化，可以保证开发、测试、线上环境的一致性，提高研发效率。目前已经接入了3个服务，明年会比较大规模的应用。多年来，在大数据领域的发展过程中，批和流两套架构并存。很多时候，业务在落地的过程中，不得不考虑同时投入两套链路的建设。例如离线数仓和实时数仓的独立建设，需要额外努力保证数据口径和计算结果的一致性。Hive表不支持数据更新，检测慢，Kafka数据回溯和查询困难一直困扰着数据。开发商。值得庆幸的是，业界已经探索出基于数据湖组件在分布式存储之上构建流批统一存储的技术。我们根据vivo的业务特点，选择并设计了我们的流批一体化解决方案。目前，我们已经完成了基于Hudi的统一存储引擎、基于Flink的统一接入湖、基于HMS的统一元数据构建已经完成试用并开始接入业务。今年我们主要接入实时服务，明年我们将接入线下服务。这也是我们大数据平台构建湖仓一体化的重要一步。在实时运营的长期运维过程中，我们积累了大量的运营优化和问题解决经验。随着运维压力的增加，我们都在思考如何提高运维效率。我们还发现，当用户资源队列满时，机器的CPU利用率处于较低水平，于是我们思考如何减少资源浪费，提高集群的资源利用效率。资源诊断和异常诊断这两类问题属于作业优化问题。优化作业首先需要了解作业及其运行环境的信息，包括运行指标、运行日志、GC日志、依赖组件运行状态、操作系统进程级信息等，以及作业配置、环境配置等，然后需要将运维经验和思路转化为启发式算法的规则和数据，并利用这些数据、算法和规则寻找优化方法。基于这样的思路，我们构建了具有灵活的信息采集、规则配置、数据调优功能的诊断服务。它可以在作业启动或运行时诊断作业的健康状况，并为我们的用户提供一些优化建议。目前资源诊断能力已经上线，异常诊断还在建设中。2.5安全能力建设作为大数据的基础服务，安全在我们看来是一个非常重要的命题。因此，我们在系统设计之初就考虑了实时数据访问，离线数据读写，以及各个系统和服务之间的关系。在安全隔离能力等方面的设计上，在实时数仓具备一定规模后，我们构建了数据分级分类、日志审计等能力。去年，根据最新合规要求，离线存储支持列级透明加密，实时数据支持敏感字段自动检测等能力。安全无止境，我们也在对DSMM进行研究和解读，不断提升大数据的安全能力。以上是我们平台建设的一些实践。综上所述，我们基于Flink构建了比较完善的实时计算开发和运维能力。业务复杂度越来越高。我们还有很多挑战，比如Flink引擎的优化。疑难问题的解决、计算效率的进一步提升、流批融合、容器化的大规模应用，都是我们后续的重点方向。如前所述，基于实时计算平台，公司多个中台团队共构建了五项中台能力，涵盖了多种实时场景。在这里我就两个典型的场景给大家简单分享一下。3.应用场景介绍3.1实时数仓vivo大数据团队基于vStream平台构建的实时数仓服务涵盖报表、营销、推荐、决策、广告等多个业务线应用程序分发、内容分发、产品平台和商业化。以及许多其他应用场景。实时数仓遵循离线数仓的逻辑分层理论，从数据源通过采集、ETL进入ODS层，再通过扩维、过滤、转换等操作进入DWD明细层，以及然后是轻聚合层DWS，最后根据主题或业务需求，将结果指标计算并存储到ClickHouse等OLAP引擎中成为ADS层，为业务提供数据报表、接口或数据服务。与离线不同，实时数据受限于数据到达时间或业务对数据的要求，可能存在分层裁剪，因此实时数仓还提供了打通中间层的能力。实时数仓部分维表与线下共享，为保证与线下链路数据口径一致，需要将Kafka流表落地到Hive表进行数据比对。离线和实时的互操作不是很方便，因此，数据仓库团队开始基于流批集成能力构建准实时数据链路。那么我们来看看实时计算是如何应用于内容推荐场景的。3.2短视频实时内容推荐vivo短视频是一款非常受欢迎的应用。为了向用户推荐高质量的视频内容，尤其依赖于推荐模型的时效性和用户特征计算的时效性。为了实现实时模型训练需要实时样本数据。因此，实时特征计算和样本拼接在内容推荐中起着非常重要的作用。vStream平台提供的TB级超大状态任务能力，支持短视频等众多应用的实时样本拼接任务。同时我们也可以看到，在这个方案中，特征和样本都存在离线和实时的链接。这是因为Flink的批计算能力不如Spark成熟，基于Kafka的实时计算难以实现数据回溯，从我们大数据平台的角度来说，一方面我们希望减少重复的计算和存储，另一方面我们也希望平台用户不需要重复开发计算和回溯代码。业界广泛讨论的湖仓一体化架构最重要的方面之一就是解决这些问题。后面的部分，我们再讲湖仓的融合。实时计算的应用场景很多，但其目的与离线计算本质上是一样的，都是为业务提供数据支持。从前面的介绍可以看出，目前基于Hadoop的大数据平台组件多，架构复杂，流批重复，资源效率低。有没有办法或希望改变这种情况？我觉得有，最后分享一下我们对未来的一些探索和展望。4.探索与展望我们知道业务是灵活的，比如一天之内的用户访问总有波峰和波谷，一段时间内业务总有增长或下降。但是目前无论是我们的数据计算任务还是YARN集群的资源分配策略都不灵活。首先，分配给任务的资源是固定的，为了尽可能避免业务波动对计算的影响，离线、实时和在线三种不同类型的计算运行在不同的物理集群上。因此，我们需要以下两个维度的弹性能力：任务级弹性能力，我们计划密切关注Flink社区，探索其AutoScaling特性的应用。对于集群级别的弹性，我们会使用vivo容器团队提供的离线混合能力来实现。刚才我们提到了湖仓一体化，为什么要湖仓一体化呢？我们可以把BI和AI这两个大数据应用领域放在一起来看。流计算、批计算、分析计算、AI计算及其对应的存储系统解决各自的问题，并且由于发展阶段的差异，围绕这四种计算形式构建了大量的平台系统和业务系统，而运行这个复杂庞大的系统的资源和人力成本非常高。因此，大家期望通过统一的存储抽象、统一的计算抽象、统一的资源抽象、统一的数据管理，构建一个内聚的、低成本的、易用的大数据系统。大家的期待推动了云原生、数据湖、下一代计算引擎等技术的发展。这些发展，也让大家的期待更加明确，更加一致。
