SLA 99.99％或更高！你饿了吗？实时计算平台的三年发展

管理

工具

火花

卡夫卡

暴风雨

作者简介

饥饿的BDI-大数据平台研发高级技术经理倪增光先后在PPTV和Vip.com工作. 我已经饿了十五年了. 我已经组建了一个数据架构团队. 我负责离线平台，实时平台和平台工具的开发和运营. 我经历了Vip.com的过程以及从零开始到不断改进的饥饿数据平台.

一个，背景

你饿了吗？ BDI-大数据平台研发团队目前约有20人，主要负责离线和实时基础设施和平台工具的开发，包括20多个组件的开发和维护，2K +服务器的操作和维护以及围绕数据平台的派生工具. 研发与维护. 离线的Infra和平台工具与外界共享更多.

今天，我将主要讨论实时计算平台的一些演进经验. 整个实时平台也经历了从无到有，快速发展，平台化的阶段，每个阶段都面临着不同的问题.

第二，总体规模和结构

首先介绍当前实时平台的总体规模:

4个Kafka群集，单个Kafka峰值100wmsg / s；

2个ELK集群用于日志检索，整个网络的索引为86w / s；

4个Storm集群，根据业务SLA进行物理拆分，整个网络的峰值计算负载为1.6kw / s；

2个Spark Streaming集群和2个Flink集群都处于Yarn模式，在该模式下Flink正在进行一些业务尝试；

超过20个业务方访问，总共有120多个Storm任务（包括HyperMetro和DataPipeline服务），26多个Spark Streaming任务，10多个Streaming SQL任务，涉及实时搜索建议，实时风险控制，实时监控，实时营销和其他项目.

总体架构图如下:

如您所见，它包括数据收集，传输，计算，着陆和服务. 组件很多，系统压力很大. 有些业务直接应用于关键路径，要求整体SLA高于99.99％.

三，进化过程

整个过程还经历了几个阶段: 从头开始到快速开发和平台化.

1，从头开始

饿了吗？从5月15日发布实时计算开始，现阶段面临的问题是

需求低. 公司对实时业务的促进不够，仅对一项UBT Domain QoS分析要求，用于计算QoS数据，例如网站错误率，HTTPCode分布，页面加载速度等；

单个数据源. 数据源只是用户行为日志，缺少诸如订单和运单之类的核心数据；

容量有限. 群集大小小于20，并且与脱机混合. 它必须同时支持实时和离线需求，并且存在资源竞争；

稳定性问题. 缺乏标准姿势的统一使用，并且各种组件存在更多的应用问题. 例如，每个应用程序需要哪种类型的计算机，以及如何优化配置...同时，由于使用的开源组件的版本较旧，因此存在一些稳定性错误；

数据延迟和数据不完整. 由于最初的技术选择存在问题，因此在数据收集端使用了自行开发的Python程序，同时使用了跨计算机机房的传输，从而导致频繁的数据丢失和延迟问题. 在最坏的情况下，高峰时期的实时数据会延迟2个小时以上，并且基本上不可用.

此阶段主要解决环境，稳定性，数据延迟和数据丢失的问题，主要做以下工作:

对于环境和标准化问题:

根据业务特征（不同的计算密集型，内存密集型，IO密集型，混合密集型等）确定新模型的配置；

设置每个组件的部署规范和参数规范，包括环境变量，内核参数计算平台，应用程序参数等: 例如JVM参数的调整，ZK / Kafka配置的优化；包括硬件标准: 例如旧的Kafka不支持JBOD Markdown，因此我们将在磁盘上进行RAID以增强系统的可用性；

实时和离线拆分，独立部署以避免资源争用；

升级现有组件并修复稳定性错误（例如Storm版本演化0.9.4-> 0.9.6至以下1.0.1、1.0.3）；

同时基于环境标准化和自动化考虑，引入了Puppet来维持环境配置的收敛性，引入Ansible进行自动化部署，以及可以快速维护的一键式管理工具.

关于稳定性问题:

在数据收集端，为了减少应用程序端的流量消耗并提高整体传输效率，在应用程序端引入了Merge + Gzip，将多条消息合并到SDK中的单个压缩中并发送到Nginx服务器，然后在Nginx上使用Lua解压缩它并使其进入AccessLog模式；

在数据传输方面，请重新研究数据传输解决方案. 考虑到该团队使用Java作为技术栈和外部案例，将Flume作为数据收集管道引入，以Tail Log和Sink的形式将数据收集到Kafka集群，并基于HDFS Sink开发分区功能. 到EventTime，并同时修复Backlog和Kafka Sink的错误；

在数据着陆侧，为了存储中间状态结果，引入了KV存储. 最初，使用独立的Redis来存储数据，并对集合进行了重复数据删除，并遇到了严重的性能问题. 因此，逐渐采用了自分片-> Redis + Tewmproxy方法，但是维护成本较高. 后来，随着RedisCluster稳定版本开始逐渐迁移到集群模式，在此阶段，该公司在NoSQL方面的经验不足，因此在团队内部不断发展.

现阶段的实时架构如下:

在这个阶段，整个平台的研发只有四个人. 他们不仅负责离线，实时和平台工具的开发和维护，还支持业务发展. 资源相对紧张，实时投资被拉长了.

尽管解决了基本的稳定性和数据延迟及丢失问题，但总体链路SLA仍然不高，并且单个数据源和单个应用程序也存在问题.

2. 快速发展

在过去的16年中，公司的业务蓬勃发展，并且对实时性的需求不断增长. SLA低，数据源单一和应用程序单一的问题需要解决.

由于业务需求，需要开发一个实时仪表板来实时关注业务状况，其中涉及交通，订单和运单等重要数据. 该项目需要涉及不同的数据源（日志，和业务数据），并且需要SLA 99.99％或更高.

为了提高整体SLA并覆盖DB端的数据源计算平台，对以下链接进行了调整和优化:

关于数据源:

优化UBT（Nginx AccessLog）的传输效率，调整Flume和Kafka的批量大小，并增加Flume Timeout发送功能（默认Flume 1.6.0仅具有Batch的控制，而没有Timeout的控制，会导致消息“延迟”在低峰值时变大）. 考虑到“批处理大小”越大，吞吐量越高，并且相应的延迟也越大，因此有必要对吞吐量和实时性要求进行权衡. 通过数据分析，最终将“批量大小”调整为10，并将“超时”调整为100ms. 最后，UBT数据链接（从收集服务器到着陆计算）的延迟减少了99.9％<1s;

同时，为了防止异常流量引起日志收集端雪崩，引入了Nginx限速模块；

为了满足Binlog数据收集的需要，引入了OR作为解析工具. 为了防止由于OR异常退出而导致的数据丢失问题，开发了ZK存储偏移功能，并且在异常崩溃重新启动后可以继续使用最后的偏移消耗.

计算:

如前所述，用户日志是组合发送的. 在卡夫卡，多个合并形成一个. 如果需要使用该应用程序，则需要根据某些规则对其进行拆分. 同时，每个企业关注的类型也不同. 不同的服务需要完全消耗所有日志，并且它们需要自行拆分，这需要大量的计算和高昂的维护成本. 为了解决这个问题，引入了双层卡夫卡结构. 第一层是统一的“拆分和过滤”以过滤异常流量，同时，它按类型写入第二层“主题”，因此每个使用者仅需要消耗相应的数据部分. 与以前相比，与流量相关的整体业务的计算量减少了一半以上；

在涉及UV计算的方案中，Redis Set最初用于重复数据删除，但是内存消耗过多. 由于紫外线指示器允许误差在1％以内，因此需要权衡准确性和时空效率，而要使用Redis的HLL进行估算. 随着业务量的增加，Redis的QPS成为瓶颈. 同时，Redis无法跨实例执行HLL合并，并且演变为基于内存的HLL估计和合并. 同时，Redis用于直接存储对象，从而节省了数百倍的内存. 维度合并操作；

考虑到多个系统同时共享ZK，ZK可能具有相对较大的压力，因此请分析ZK事务日志以确定呼叫分配. 例如，通过分析发现，Storm Worker的心跳频繁访问ZK，因此通过增加Heartbeat Commit的时间来减轻ZK的压力；

为了减少重复的代码开发，对基本组件进行了封装: 包括数据消耗，重复数据删除，累积，数据写入和其他运算符，最终将某些任务的代码量减少了50％，并提高了总体开发效率让用户专注于业务逻辑.

包装组件清单

运维管理:

要了解总体容量状况，请通过实时获取Zabbix Item LastValue来开发实时容量看板并监视Storm＆RedisCluster的实时压力状况；

为了方便用户快速查看任务日志，引入了ELK，并在Kafka2es层引入了环聊以取代Flume（它可以支持超过3倍的性能提升）. 最后，Storm Top Log-> Logstash-> Kafka-> Hangout-> ES-> Kanbana的整个Log链接.

总体SLA增强功能:

在数据收集端和计算端都引入了限速和反压功能，以防止流量激增引起的雪崩效应;

从数据收集到数据的最终登录，使用双链接方法，并使用多计算机机房方法: 例如，数据收集终端分布在两个计算机房中的不同位置，使用本地计算+最终合并或数据双向传输+完整计算； <

与Kafka Binlog数据重放和Nginx模拟访问配合，在整个链路上执行模拟压力测试，与实时监控和业务绩效配合以关注每个组件的性能关键点；

基于3个数据的容量规划，并同时进行资源隔离；

改进所有级别的监视和警报策略，包括模拟用户访问以验证链接条件. 同时，为避免口径不一致引起的数据问题，开发离线和实时的数据质量比较报告，以监控数据质量问题；

p>

在业务端和后端以及同时在后端服务自动故障转移中添加降级策略；

改善应急计划SOP并进行有针对性的演练: 例如，通过切断活动数据登陆层来确定应用程序是否可以进行自动故障转移；

数据层使用缓存，例如将一些Storm中间计算状态数据写入Redis；

同时，为了防止Crash的应用导致数据故障，开发了补充功能，并且在异常恢复之后，历史数据可以由离线数据进行补充.

通过上述一系列调整，业务流量的增长最终受到了几次抵制，从而确保了整体服务的稳定性.

业务监控仪表板的示例示例:

现阶段实时平台的主要用户仍然是大数据本身，其应用架构如下:

尽管此阶段解决了单一数据源和整体SLA较低的问题，但也带来了新的问题:

Storm任务越来越多，Kafka主题越来越多，它们是该主题的生产者和消费者，数据量越来越大，任务维护成本也越来越高，迫切需要一种平台工具; <

不同的用户需求，一个引擎不再能够满足业务需求，并且需要多个引擎支持；

由于您很饿，所以存在多种语言的开发场景（Go，Python，Java，Scala等），Storm任务开发和学习成本相对较高，用户希望通过一种SQL支持一些简单的场景； <

需要通过Nginx + Flume方法收集业务日志，而OPS需要协调Flume的部署. 但是，OPS学生拒绝Flume，迫切需要提供一种标准的SDK访问手势，以便于编写开发数据；

过去，业务数据登陆仓库需要使用Kafka-> Flume-> HDFS. 随着越来越多的商务人士的参与，Flume的维护成本越来越高. 同时，有多个2HDFS错误导致数据重复. 迫切需要提供一种方便的数据维护解决方案，以支持多个数据和稳定的数据流通.

3. 平台化

17世纪初期，生产和研究逐渐与实时计算联系在一起. 上述问题逐渐暴露出来，迫切需要在平台一级采用统一的解决方案来解决用户的痛点. 因此，在年初，我们确定了“以ERDP实时平台为核心，开放数据收集，数据传输，数据计算和数据着陆的DataPipeline为用户提供一个整体”的方向. -stop实时平台”.

在此目标之上，我们进行了以下调整:

开发资源重点:

由于负责实时平台的人员只有3-5人，因此我们开始逐步推广一些组件以访问公司的统一服务（例如监视和警报），并将一些任务移交给应用程序团队，只保留个人实时业务. 平台相关部分的开发；

考虑到每次将连接到OR，都需要启动实例，并且维护成本相对较高. 同时，该公司开始推广统一的Binlog解析工具DRC，以在多机房中同步DB数据. 因此，我们已逐渐使用DRC代替OR.

解决数据收集的难题:

通过开发统一的多语言数据访问SDK并访问配置中心，数据访问的格式得以标准化，从而可以快速访问用户的业务数据. 同时，为了提高可用性，SDK集成了降级和限速功能.

解决数据传输访问的难题:

参考Flume Source-> Channel-> Sink的思想，我们基于Storm的Data Pipeline功能开发了一个组件EDSink，它可以支持多种数据写入方法，包括2KAFKA，2ES，2HDFS和2DB. 同时，它被高度封装并且抽象了一些配置. 用户只需要填写一些参数即可实现数据的登陆，从而大大提高了数据访问的效率，并在数据登陆的层次上引入了保险丝功能；

在通过EDSink将数据写入HDFS方面，它开放了离线平台调度系统和元数据管理功能，集成了表创建和数据清理功能，并实现了一键式数据登陆. 目前，通过EDSink访问数据仓库的业务日志已从以前的2-3天减少到不到2小时；

为了支持更细粒度的任务调度，EDSink中集成了基于事件的分区功能，该功能可以支持细粒度的分区，并与Spark结合以支持半小时ETL链接的开发小时链接从40分钟缩短到20分钟，可以在大约左侧或右侧完成；

同时，它与Binlog解析工具链接在一起，以支持用户自行申请数据. 基于此解决方案，该团队正在对数据进行反序列化，这有望大大节省从属服务器的成本.

提供更多计算方法:

Spark Streaming被引入并集成到ERDP平台中，该平台封装了基本的Spark Streaming运算符，用户可以通过该平台管理Spark Streaming任务；

考虑到需要支持某些SQL要求，我们比较了Spark Streaming，Flink，Storm CQL和其他引擎. 从团队的技术堆栈，引擎成熟度和稳定性来看，我们最终选择了Spark Streaming. 并且基于Spark Streaming的SQL功能，它为用户封装了基本运算符. 同时，它支持上传Jar包以提供UDF功能和Scala脚本支持. 它支持结构化流以支持状态增量计算. 意识到用户编写SQL可以满足实时开发需求. 需求（目前支持90％的业务场景）.

自动化和自助功能可促进任务和资源管理:

先前用户对Storm任务的配置更改都需要重新打包，并且用户管理成本相对较高. 因此，引入了Storm Flux函数以封装基本组件并将其集成到实时平台中. 用户可以生成0个代码的数据，可以快速开发和管理任务，并自动生成YML文件以减少任务的维护成本；

通过开放各种资源的应用程序流程，支持自助应用以及自动创建Kafka Topic和其他资源，基于Topic数据完善元数据管理，并为资源核算和实时元数据亲属关系提供数据基础;

为了便于监视任务，将Storm，SparkStreaming和Kafka级别的监视统一到InfluxDB中，并且自动生成模板. 用户不需要手动添加监视和警报. 任务联机后，会自动报告并创建Metric＆Dashboard. API数据被写入InfluxDB，并且标准模板也用于自动生成Grafana监视模板.

Kafka监控示例

通过上述一系列调整，最终使整个平台得以完善，解决了用户开发成本高，访问成本高，管理成本高的难题. 最终的架构图是本文的开头.

4. 后续计划

尽管经过一些发展，现有平台仍然存在一些问题，例如:

SQL模式的覆盖范围有限；

用户在选择引擎时遇到困难，并且没有引擎能够满足大多数需求；

Kafka 0.8.2版本的功能有限，不支持Excatly Once，不支持JBOD Markdown等；

实时和离线分离，并且重复构造数据. 由于实现方法不同，实时和离线实现相同的数据口径很难.

公司内部对实时业务场景的覆盖不足；

......

因此，对于这些痛点，我们也在进行以下尝试:

Flink凭借其性能和易用性而在实时计算领域变得流行，并且我们还在做一些业务试验；

测试实时和离线CEP场景的融合；

Kafka的新版本的引入，包括对Qouta速度限制，JBOD Markdown，Stream API，Excatly Once和其他功能的支持；

实时平台集成到统一的多合一平台中，用户可以在一个平台上完成实时和离线开发；

探索业务场景. 例如，我们当前与策略部门合作的实时营销项目是使用用户的行为数据来制定一些策略来提高转化率.

四个，一些经验

最后谈谈平台化演进中的经验:

学会收集资源（善于使用外力，必须拥有VS才能拥有）；

最小化MVP的可行性研究（将产品迭代出来，而不是一整夜，完成后是完美的）；

懒惰的思想，不要反复制造轮子（其他山上的石头会袭击玉石）；

赋予用户权力，尝试实现自动化和自助（提高效率，解放生产力）；

基于数据的操作（与数据对话）；

资源隔离，关键业务的SLA保证（降级电流限制策略，背压功能等）；

做好监视（监视整个链接并进行必要的测试）；

防止墨菲定律，及时进行容量规划和压力测试，并不断提高SOP；

抽象思维（从一个问题抽象到一种问题）；

解决实际问题，而不是炫耀技能；

关注用户体验（在VS完成后完成）；

防火胜过消防，多想一些步骤，并继续总结和改进标准，计划和流程（规范/清单/ SOP流程等）.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-273252-1.html