图片来自包图网

【51CTO.com原创稿件】WAIC 实时流计算平台为新浪微博提供可靠的毫秒级和秒级实时数据处理服务，通过提供统一的数据源和配置化接入方式，帮助提高新浪微博实时作业的开发效率，降低部门开发与运营的成本。

2018 年 5 月 18-19 日，由 51CTO 主办的全球软件与运维技术峰会在北京召开。

在“高并发与实时处理”分会场，新浪微博实时流技术平台负责人廖博带来了《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 等交互模块，将作业提交给控制中心。
• 控制中心进行初步的权限校验和资源审核之后，将资源提交给任务调度。
• 任务调度将相应的作业提交给对应的集群 Weibox。
• 如果作业提交成功，Weibox 会把相应的作业信息重新返回给控制中心。
• 控制中心将作业通过用户交互客户端返回给用户结果。同时，它会将作业信息同步给管理服务后台。
• 用户通过管理服务后台的客户端，去操作自己在集群上面的功能。控制中心既能减少已占用的资源，又能为每一个团队实现资源控制。

控制中心初现

由于前期各种作业(如 Storm)在向集群提交的时候，许多开发人员会自行配置一个本地环境，以实现直接提交，这就造成了平台方很难对集群进行有效的管控。

因此对于我们第三阶段的控制中心而言，其主要目标是：

• 解决作业随意提交，治理集群上作业混乱的现象。
• 对集群资源进行统一管理，从而避免过多的资源浪费。

上图是实时流计算平台的控制中心架构图。其流程如下：

• “基础模块”通过权限校验和资源审核，将作业提交给“作业上线流程”服务。
• “作业上线流程”调用后置的检查模块，检查该作业是否在集群上运行成功，以及判断该作业所占用的资源、是否为它在提交时指定了资源量。
• 如果“作业上线流程”服务提交作业成功，那么“资源决策服务”调用动态资源调节模块，在集群上定时(如：每小时或每天)检查该作业所使用和处理的数据量，以及每条数据的处理时长。籍此，该模块运用简单的公式，来判断该作业是否需要占这么多资源。

上述提到过，一些开发人员可能会通过在自己的本机上配置相应的作业提交环境，以实现将作业提交到集群之中。

那么为了管控对应的业务组在集群上占用的资源量，我们在“资源决策服务”里，调用到了作业识别模块。

资源配置策略

为了提高公司的生产开发效率，我们在第三阶段实施了资源配置策略。同时，我们的核心目标点是：通过第二阶段的 WeiPig 开发框架，来鼓励各个业务团队贡献相应的插件。

其实 WeiPig 是一套规范协议，大家在贡献插件之前需要增加学习上的投入。因此，对于一些已经实施了计算能力的业务方来说，虽然有利于将旧平台迁移过来，但是他们不太愿意投入此类学习的成本。

所以我们想出了用资源去换取 WeiPig 前向发展的方法。我们将所有的平台资源按照基础资源、弹性资源、奖励资源和平台资源，四个方向进行划分。

其中基础资源仅占 1%，基本上只有一、两台机器。弹性资源有 20%，各个公司根据业务量和业务等级进行划分，当业务量多的时候，每一个业务都可以有自己的重要程度和优先级。

值得一提的是：奖励资源为 30%。它通过两方面标准：WeiPig 里贡献的 Function 数量，和这些通用 Function 会被多少业务方所使用到，来进行公式算法上的衡量。

如果你贡献的多，而且被其他业务方使用的也比较多，那么我们就会从所有平台资源的 30% 中，给你划分出更多的资源。

实时对账系统

为了满足某些高成功率场景的需求，我们在第三阶段自行设计了一个实时对账系统。

该系统的主要成绩是：满足实时计算平台完成 6 个 9 的数据成功率需求。

上图是实时对账系统的一个简单架构图。在数据处理开始时，我们会将数据写入实时对账系统，并打上开始标志。

同时，实时对账系统会将该数据的开始处理、和结束处理的标志，存放到存储服务上。

而图中下方的离线定时服务，会定时查询实时对账系统，并进行如下判断：

• 如果一条数据既有入账，又有根据处理结束值所求的出账，则认为该条数据已处理完成，即对账成功。
• 如果一条数据只有数据处理的开始，却没有处理结束的标志，则该条数据可能出现被丢掉的情况，我们需要重试。
• 如果一条数据只有数据处理结束，却没有数据处理成功的标志，则会发出相应的报警，我们需要查找相应的问题。

稳定性服务平台

另外，在第三阶段，我们将第二阶段的“统一监控平台”升级成了“稳定性服务平台”。

其目标有如下三点：

• 通用监控指标的数据统一生成。前面在第二阶段的监控统一平台中，我们必须在界面上去配置要监控的指标项目，通过编写相应的采集代码，然后把脚本部署到服务器上，以方便监控的采集。

但是在第三阶段的稳定性服务平台上，一个作业被提交到集群上之后，稳定性服务平台会对集群上处理的数据量、处理延迟、错误量等通用指标进行统一生成。

• 集群资源负载均衡的监控。其实 Storm 不像 Hadoop、Flink、Yum，它并没有资源调度的管理系统。

因此，它在自己做管理资源时，会出现在一个集群中，某个服务器的 CPU 利用率已达 90%，而其他服务器的 CPU 利用率只占有 50%～60% 的情况。所以我们自行研发了对集群资源负载均衡的监控。

• 监控指标采集平台，统一所有监控数据的采集。

这里展示的是实时流计算平台稳定性服务的架构图。左侧的数据采集平台包括：Storm 指标项目数据收集、Kafka 数据堆积量的数据收集、日志收集平台、监控脚本运行平台、和服务器硬件资源的收集。

这是一个比较简易的、便捷的资源负载均衡的监控服务。完成统一采集之后，系统调用数据存储服务，经由服务平台的管理服务平台、运维服务平台、和第三方服务平台，对外面开发人员提供相应的服务。

上图是第三阶段相应的成果。目前，我们的平台每天能处理大约一千多亿的数据量，TPS 大约有百万每秒，作业个数则每天约有 150～200 个。

如今无论是多媒体相关的数字计算需求，还是微博相关的处理需求，我们的人工工作量已相对较少了，主要的工作量集中在编写 WeiPig 相应的配置文件上。相应的代码重复率也比较低，同样主要集中在 WeiPig 文件上。

另外，由于我们主要是到 HDFS 上去搜集和管控相应的日志，因此异常排查的效率适中。

而对于监控方式而言，我们大部分采用的是自动生成的方式，所以只对一些特殊要求才进行监控配置。

当然，目前的实时流计算平台仍有两个遗留问题：

• 缺乏系统性的资源调度。我们需要有一个资源调度系统，来实时获知集群上的作业到底应该运行在哪一台服务器上。

目前我们采用的一种简易方式是：搜集各台服务器上的资源情况，然后用自己的程序进行判断和处理。如果某一台机器利用率高于其他服务器20%的话，那么我们认为其负载是不均衡的。

• 日志收集方案不统一。

总结 DQRA 设计模式

我们在实时流计算开发的过程中，一边搭建业务平台，一边解决了不少问题。因此我们总结出了一套 DQRA 的设计模式。

DQRA 详解

它们分别是：

• Difficulty(逻辑复杂度)
• Quantity(数据量)
• Reliability(可靠性)
• Asynchronous(异步时序性)

因此，我们认为：面对大多数的需求，我们可以把问题的实现拆解为上述四个属性中的某种。

例如：逻辑复杂度有难、中、易;数据量有大、中、小;可靠性是高、中、弱;等方面。

上述便是 DQRA 可能出现的不同组合，以及所对应的不同解决方法。

DQRA 案例分析

下面我们会介绍一个简单案例，它包含如下特性：

• D 难，表示实现的复杂度，即实时流作业中需要处理的逻辑比较难。
• Q 中，表示数据量可能一般，可能是从几千万到十亿之间。
• R 高，表示可靠性高，即成功率要求高，如前面提到的 6 个 9 的数据处理成功率。

具体来说，它是一个图像分析与处理类系统，需要具有持续稳定的服务保证。因此，系统稳定是第一位的。

其次，它要求数据处理的成功率大于 6 个 9，从而能应对单日 5000 万的数据量。

因此，我们通过上述三个方面来实现该系统的需求：

• 首先，针对系统的稳定性，我们采用的是内网和阿里云的“双保险”网络部署方式。
• 其次，由于涉及到图片的下载，而我们在做分析时，调用的是在线模型预测方式。

因此，为了避免可能出现的图片分析失败，我们采用了实时对账系统，实现了必要的重试处理。

廖博，新浪微博实时流技术平台负责人，曾就职于搜狐、雅虎研究院、支付宝等公司参与 Data Highway、大数据系统、数据仓库、UUS(User Understanding Service)等第一代大数据生态系统的搭建工作;现就职于新浪微博，主导和开发实时流计算平台，基于该平台之上完成多媒体分析平台、物料池系统、样本生成平台等多个子系统的开发和建设。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】