图片来自宝途网【原创稿件】WAIC实时流计算平台为新浪微博提供可靠的毫秒级和秒级实时数据处理服务，通过提供统一的数据源和配置访问方式，有助于提高新浪微博实时运营的开发效率，降低部门开发运营成本。2018年5月18-19日，由主办方主办的全球软件与运维技术峰会在北京召开。在“高并发与实时处理”分会场，新浪微博实时流技术平台负责人廖波发表主题演讲《WAIC 实时流计算平台的成长和繁衍》。本文将分以下四个阶段分享微博实时流计算平台的搭建过程，以及创建过程中遇到的一些问题和解决方案：初入实时流计算实时流计算平台初步搭建实时流计算平台开发总结DQRA设计模式首先进入实时流计算，介绍一下我们实时流计算平台的发展历程：2015年，我进入了新浪微博。当年我们用实时流计算打造了一个素材池系统。2016年，我们开发了用户实时兴趣反馈系统。2017年我们对接了一些多媒体相关的项目，比如人脸识别系统的建设。同年，我们也开始了实时流计算平台的初步建设。2018年，我们推出WAIC实时流计算平台。上图展示了实时流计算的技术背景。常用的计算引擎包括：Spark、Streaming、Flink、Storm、Flume、Kafka等中间件。在我们的WAIC实时流计算平台中，使用的主要计算引擎有：Storm、Kafka、Flume和Flink。上图是实时流计算的第一阶段。这是一个经典的架构，使用Flume将业务系统中的实时流式日志数据写入到Kafka中。然后使用Storm读取Kafka中的数据，最后用相应的业务逻辑对数据进行处理。这一阶段我们主要完成了以下两个任务：让微博“接入”实时流计算功能。当数据处理失败时，使用Kafka进行必要的数据回滚来解决问题。上图是第一阶段对应的数据结果。当时数据量和集群数量都比较少，所以主要的问题包括：人工工作量比较大，就是面对需求的时候，完全靠人来写代码。代码重复率比较高，排查异常的方式比较简单。这一切都取决于登录到服务器并转到Grep日志。监控的方式完全依赖于脚本。上图展示了第一阶段遗留的一些问题。实时流计算平台初建，但是随着实时流计算的频繁使用，业务场景的增多，监控需求的提升，我们意识到需要搭建一个实时流计算平台.我们当时提出的平台目标主要包括：开发一个可结算、可配置的开发框架。统一所有监控，打造统一监控平台。这是实时流媒体第二阶段的初步架构图。到这里，我们的访问日志方式就丰富了很多。如图所示，我们不仅通过Scribe收集数据，还从Kafka和Mcq中读取数据。然后使用Scribe或者其他数据同步服务将它们连接到实时队列，最后在不同的业务场景下使用不同的实时集群进行处理。自研WeiPig框架为了降低开发者上手实时任务开发的门槛，我们自研了WeiPig框架。它具有以下四个主要特点：可配置开发。对于一些简单的开发需求，我们只需要编写WeiPig开发文件即可实现。插件编程。它为插件编程提供了编码标准。对于一些初始的功能需求，我们按照相应的规范进行编码，即编写WeiPig文件来满足各种需求。通用解决方案。因为WeiPig是为实时流开发的应用框架，它需要满足供应链中所有不同类型的实时流需求。统一贡献机制。使不同的业务团队能够按照同一套规范开发相应的插件，并提供相应的插件功能。同时，他们也可以按照相同的规范和机制使用其他团队提供的功能插件。同时，我们需要借助WeiPig框架来“沉淀”所有开发人员的工作模式，实现公司各部门的共享与协作。统一监控平台如前所述，在第一阶段，我们的监控实现方式基本是：依靠运行在不同服务器上的脚本来收集日志数据，然后发送告警邮件。进入第二阶段后，我们使用上图所示的实时流式统一计算和监控平台来展示和配置运行状态。即：系统不仅可以显示相应的数据监控指标，还可以为数据监控指标配置相应的告警。这些监控指标数据通过不同的采集工具进行采集，然后录入到MySQL数据库中。上图是第二阶段对应的结果。虽然此时已经有了WeiPig开发框架，但是我们手动的工作量还是比较大的。由于WeiPig的插件主要由平台侧的几个开发者来实现，不仅插件数量相对较少，而且其工作量也达到了80%。此外，代码重复率仅占50%左右，直接导致异常排查效率低下。同时，在监控配置方面，我们仍然需要手动配置和编写脚本来采集相关指标数据。第二阶段之后，我们留下了很多问题，包括：缺乏权限机制缺乏资源统一调度问题排查比较慢碎片化资源比较多（主要是我们用的是一些小集群，导致大量遗留问题冗余资源闲置在系统中）缺乏高可靠性保障开发效率低实时流计算平台开发实时流计算平台进入第三阶段后，我们提出了相应的宏观目标，即：提高公司开发生产效率高，节省重复建设成本。可视化操作。上图是目前实时流计算平台的架构图。数据流转逻辑如下：用户通过UI交互客户端和Weiclient等交互模块向控制中心提交作业。控制中心进行初步权限验证和资源审核后，将资源提交给任务调度。任务调度将对应的作业提交到对应的集群微信。如果作业提交成功，微信将相应的作业信息返回给控制中心。控制中心通过用户交互客户端将作业的结果返回给用户。同时将职位信息同步到管理服务后台。用户通过管理服务后台的客户端在集群上操作自己的功能。控制中心既可以减少资源使用，又可以实现对每个团队的资源控制。控制中心的初步出现在早期向集群提交各种作业（如Storm）时，很多开发者会自己配置一个本地环境实现直接提交，这使得平台难以有效管控集群。因此，对于我们的三级控制中心来说，它的主要目标是：解决集群上随机提交作业和管理作业混乱的现象。集群资源统一管理，避免资源过度浪费。上图是实时流计算平台控制中心的架构图。流程如下：“基础模块”通过权限验证和资源审核，将作业提交给“作业在线流程”服务。“作业上线流程”调用post-check模块检查作业是否在集群上运行成功，判断作业占用的资源以及提交时是否指定资源量。如果“JobOnlineProcess”服务提交作业成功，则“ResourceDecisionService”调用动态资源调整模块定期（例如：每小时或每天）检查集群上作业使用和处理的数据量，以及每条数据的处理时间。因此，该模块使用一个简单的公式来判断作业是否需要占用这么多资源。前文提到，有些开发者可能会通过在本机配置相应的作业提交环境来向集群提交作业。然后，为了控制集群上相应业务组占用的资源量，我们调用“资源决策服务”中的作业识别模块。资源配置策略为了提高公司的生产和发展效率，我们实施了第三阶段的资源配置策略。同时，我们的核心目标是鼓励各业务团队在二期通过WeiPig开发框架贡献相应的插件。其实WeiPig是一个标准的协议，大家在贡献插件前需要多投入学习。因此，对于一些已经实现了计算能力的业务方来说，迁移老平台虽然有好处，但是不愿意投入这样的学习成本。于是我们想出了一个换取资源的办法，为威猪的前向发展做准备。我们将所有平台资源分为四个方向：基础资源、弹性资源、奖励资源和平台资源。其中基础资源只占1%，基本上只有一两台机器。有20%的弹性资源。每个公司根据业务量和业务级别进行划分。当业务量很大时，每个业务可以有自己的重要性和优先级。值得一提的是：奖励资源为30%。它使用两个标准：威猪贡献的功能数量，以及有多少业务方会使用这些常用功能来衡量公式算法。如果您贡献的多，被其他业务方使用的多，那么我们将从所有平台资源的30%中分配更多的资源给您。实时对账系统为了满足一些高成功率场景的需求，我们在第三阶段设计了一个实时对账系统。系统的主要成果是：满足实时计算平台完成6个9的数据成功率要求。上图是实时对账系统的简单架构图。在数据处理开始时，我们会将数据写入实时对账系统，并标记为开始。同时，实时对账系统会将数据的开始处理和结束处理标志存储在存储服务上。图中最下方的离线定时服务会定时查询实时对账系统，并做出如下判断：如果一条数据根据处理终值既有入库又有退出，则认为该数据已经被处理。即对账成功。如果一条数据只有数据处理的开始，而没有处理结束的迹象，那么这条数据可能丢失了，需要重试。如果一条数据只是数据处理完成，但没有数据处理成功的迹象，就会发出相应的告警，需要找到相应的问题。稳定服务平台另外，在第三阶段，我们将二期的“统一监控平台”升级为“稳定服务平台”。其目标有以下三点：通用监控指标的数据统一生成。在统一监控平台第二阶段，我们要在界面上配置需要监控的指标项，编写相应的采集代码，然后将脚本部署到服务器，方便采集监控。而在第三阶段的稳定服务平台上，作业提交到集群后，稳定服务平台会统一生成集群处理的数据量、处理延迟、错误量等通用指标。集群资源负载均衡的监控。事实上，与Hadoop、Flink和Yum不同，Storm没有资源调度管理系统。因此，当它自己管理资源时，集群中会出现某台服务器的CPU使用率达到90%，而其他服务器的CPU使用率只占50%到60%。所以我们自己开发了集群资源负载均衡的监控。监控指标采集平台统一采集所有监控数据。此处展示的是实时流计算平台稳定服务的架构图。左侧数据采集平台包括：Storm指标项目数据采集、Kafka数据积累数据采集、日志采集平台、监控脚本运行平台、服务器硬件资源采集。这是一个比较简单方便的资源负载均衡监控服务。统一采集完成后，系统调用数据存储服务，通过服务平台的管理服务平台、运维服务平台、第三方服务平台为外部开发者提供相应的服务。上图是第三阶段对应的结果。目前我们的平台每天可以处理超过1000亿条数据，TPS大约是每秒100万条，作业数量大约是每天150-200条。现在无论是多媒体相关的数字计算需求，还是微博相关的处理需求，我们的人工工作量都比较小，主要工作量都集中在为WeiPig编写相应的配置文件上。相应的代码重复率也比较低，也主要集中在WeiPig文件上。另外，由于我们主要是去HDFS收集和控制相应的日志，异常排查效率一般。至于监控方式，我们大多采用自动生成的方式，所以我们只针对一些特殊需求进行监控配置。当然，目前的实时流计算平台还存在两个遗留问题：缺乏系统的资源调度。我们需要一个资源调度系统来实时知道集群上的作业应该运行在哪台服务器上。目前我们采用的一种简单的方法是：收集各个服务器上的资源，然后用我们自己的程序进行判断和处理。如果某台机器的利用率比其他服务器高20%，那么我们就认为它的负载不平衡。日志采集方案不统一。总结一下DQRA设计模式，我们在实时流计算的发展过程中，在搭建业务平台的过程中解决了很多问题。因此，我们总结了一套DQRA设计模式。DQRA对它们进行了详细的解释：Difficulty（逻辑复杂度）Quantity（数据量）Reliability（可靠性）Asynchronous（异步时序）因此，我们认为面对大多数需求，我们可以将问题的实现拆解成上面的一种四个属性。例如：逻辑复杂度为难、中、易；数据量有大、中、小；可靠性为高、中、弱；等等。以上是DQRA的不同可能组合以及相应的解决方案。DQRA案例分析下面我们将介绍一个简单的案例，它包括以下特点：DDifficult，表示实现的复杂性，即实时流作业中要处理的逻辑比较难。在Q中，表示数据量可能是平均的，从几千万到十亿不等。R高表示可靠性高，即成功率要求高，比如上面说的69数据处理成功率。具体来说，是需要持续稳定服务保障的图像分析处理系统。因此，系统稳定性是第一位的。其次，它要求数据处理的成功率大于6个9，单日处理5000万的数据量。因此，我们通过以上三个方面来满足系统的要求：第一，为了系统的稳定性，我们采用了内网和阿里云的“双保险”网络部署方式。其次，因为涉及到图片的下载，所以我们在做分析的时候，调用在线模型预测的方法。因此，为了避免可能出现的图像分析失败，我们采用了实时对账系统进行必要的重试处理。廖波，新浪微博实时流媒体技术平台负责人，曾在搜狐、雅虎研究院、支付宝等公司工作，参与了数据高速公路、大数据系统等第一代大数据生态系统、数据仓库、UUS（用户理解服务）目前就职于新浪微博，主导开发实时流计算平台，完成多媒体分析平台、素材池系统等多个子系统的开发建设，以及基于该平台的样本生成平台。【原创稿件，合作网站转载请注明原作者和出处为.com】
