about the author
Ni Zengguang, hungry yet BDI- big data platform development, senior technical manager, has worked in PPTV, the only product. 15 joined hungry yet, set up data architecture team, responsible for the overall platform offline, real-time platform, development tools and platform operation and maintenance, has gone through the CD products will be, what hungry data platform from scratch to continuous improvement process.
One, background
What BDI- hungry big data platform R & D team is currently a total of about 20 people, mainly responsible for Infra real-time and off-line & platform development tools, including the development and maintenance of 20+ components, 2K + Servers operation and maintenance and data platform surrounding derivatives R & D & maintenance . Infra offline tools and platform to share this one outside more.
Today, the main tell us something about it in the calculation of the number of hungry evolution experience platform, real-time, real-time platform is also a whole has experienced rapid development from scratch → → platforms of phases, each faces a different problem.
Second, the overall size and architecture
First introduced to the current overall size of what hungry real-time platform:
Kafka cluster. 4, single peak Kafka 100wmsg / s;
2 ELK cluster used for log retrieval, indexing the amount of the whole network 86w / s;
. 4
Storm
cluster, physically split according to the SLA operations, the whole network peak calculation 1.6kw / s;
2 Spark Streaming clusters and two Flink clusters are On Yarn mode, which Flink try doing some online business;
More than 20 access business side, a total of 120+ Storm tasks (including active-active & DataPipeline business), 26 + Spark Streaming task, 10 + Streaming
SQL
task involving recommend real-time search, real-time risk control, real-time monitoring, real-time marketing projects .
The overall structure is as follows:
It can be seen, including data collection, transmission, calculation, as well as the service floor. Multi-component system and the pressure, applied directly to the part of the business critical path, than required overall SLA to 99.99%.
Third, the evolution
As a whole has gone through several stages: from scratch, rapid development platform.
1, from scratch
What hungry real-time computing on-line from 15 May, at this stage facing the question:
Less demand. Real-time business in the company's promotion is not enough, there is only one UBT Domain QoS requirements analysis, used to calculate the site error rate, HTTPCode distribution, QoS data page loading speed;
A single data source. Only data source user behavior Log, a lack of orders, waybills and other core DB data;
Capacity is limited. Cluster size is less than 20, and the mixed unit and offline, to support both real-time + off-line demand, there is competition for resources;
Stability problems. Lack of uniform standards using gestures, each component of the application more problems. For example, each application needs what type of machine, how to better configure ...... and because of open source components using an older version, there are some stability bug;
Data delayed and incomplete data. Because there is a problem in the initial technical options, use a Python program developed in the data collection terminal, using both transport across the room, resulting in data loss and delay problems often arise. The most serious, real-time data to Delay at the peak of more than two hours, basically unusable.
This stage is mainly to solve the environment, stability, data latency and data loss problems, mainly to do the following work:
For environmental and standardization issues:
Determining operational characteristics of the new model configuration (case compute-intensive, memory-intensive, the IO-intensive, intensive mixing, etc.) according to;
Setting parameters of each component deployment specification & specification, including environment variables, kernel parameters, application parameters: JVM such adjustment parameters, configuration ZK / Kafka optimization; standard hardware comprising: for example, does not support the old Kafka JBOD Markdown, So we do have a disk RAID, enhance system availability;
Real-time and off-line split, independent deployment, avoid contention for resources;
Upgrading of existing components, stability fix bugs (such as an evolved version Storm 0.9.4-> 0.9.6 behind the 1.0.1,1.0.3);
At the same time based on environmental considerations of standardization and automation, the introduction of
Puppet
to do to maintain convergence environment configuration, Ansible do automated deployment, and made a key management tool that can quickly maintain.
For stability:
In the data acquisition side, in order to reduce traffic app end consumption and enhancing efficiency of the entire transmission, the introduction of Merge + Gzip in app end, sent to Nginx Server after the SDK the plurality of message Merge into a compressed and Nginx end in Lua decompress in a manner AccessLog floor;
In the data transmission side, re-survey data transmission scheme, taking into account the team to
Java
as the technology stack, as well as external cases, the introduction of the Flume as the data acquisition pipeline for data collection to Tail Log form and Sink to Kafka cluster, based on HDFS Sink the development of EventTime Partition function, and at the same time fix Backlog Kafka Sink of bugs;
In the data-side ground, in order to store intermediate results of the state, is introduced KV storage. Single initial use
Redis
to store data, set to re-encountered serious performance problems, so the back began to gradually use Self Sharding-> Redis + Tewmproxy way, but maintenance costs are higher. With RedisCluster behind the stable version of Release gradually migrate to the Cluster mode, at this stage in the company
NoSQL
experience has been insufficient, so the internal team is constantly find their way.
This stage real-time architecture is this:
The entire platform development stage only four individuals, we must be responsible for off-line, real-time, platform development and maintenance tools, but also to support business development, resource shortages, real-time invest stretched.
虽然解决了基本的稳定性 & 数据延迟和丢失的问题，但是整体链路 SLA 还是不高，同时还存在数据源单一、应用单一的问题。
2、快速发展
16年公司业务大力发展，实时方面的需求越来越多。SLA 不高、数据源单一、应用单一的问题亟待解决。
由于业务需求，需开发实时 Dashboard 来实时关注业务情况，涉及流量、订单、运单等重要数据，项目需要涉及不同的数据源（Log & DB &业务数据），同时要求 SLA 99.99%以上。
为了提高整体的 SLA，同时覆盖 DB 侧的数据源，针对整个链路做了如下调整优化：
数据源方面：
优化 UBT（Nginx AccessLog）传输效率，调整 Flume 和 Kafka 的 Batch 大小、增加 Flume Timeout send 功能（默认 Flume1.6.0只有 Batch 的控制，没有 Timeout 的控制，会导致低峰时消息 Delay 变大）。考虑到 Batch Size 越大吞吐量越高，相应延迟也越大，因此需要针对吞吐量 & 实时性要求做 Trade Off。通过线上数据的分析，最终把 Batch Size 调整到10，Timeout 调整到100ms，最终 UBT 数据链路（从采集 Server 到计算落地）延迟降低99.9%<1s；
同时为了防止异常流量导致日志收集端雪崩，引入了 Nginx 限流限速模块；
为了满足 Binlog 数据采集的需求引入 OR 做解析工具，为防止 OR 异常退出导致数据丢失问题，开发基于 ZK 存储 Offset 功能，在异常 Crash 重启后继续上次的 Offset 消费即可。
计算方面：
前面提到用户 Log 是合并发送，在 Kafka 中的表现是多条 Merge 成一条，应用如果需要使用的话，需要按照一定的规则 Split。同时每个业务关注的 Type 不一样，不同的业务需要全量消费所有 Log，同时需要自行进行 Split，计算量大，维护成本比较高。为了解决这个问题引入了双层 Kafka 结构，在第一层进行统一的 Split 和 Filter，过滤异常流量，同时分 Type 写入二层 Topic，这样每个消费方只需消费对应的数据部分即可，整体流量相关业务计算量对比之前降低了一半以上；
涉及 UV 计算的场景，初始使用 Redis Set 去重，但是内存消耗过大。由于 UV 指标允许1%以内误差，在精度和时空效率上做 Trade Off，转而使用 Redis 的 HLL 来估算。随着业务量的增大，Redis 的 QPS 成为瓶颈，同时 Redis 无法跨实例进行 HLL 的 Merge，又演化为基于内存的 HLL 估算和 Merge，同时使用 Redis 直接存储对象，节省百倍内存的同时，支持多维度的 Merge 操作；
同时考虑到多个系统共用 ZK，ZK 可能存在比较大的压力，因此通过分析 ZK 的 Transcation Log 来确定调用分布。比如通过分析发现 Storm Worker 的 Heartbeat 会频繁访问 ZK，因此通过增加 Heartbeat Commit 时间减少 ZK 的压力；
为了减少重复的代码开发，对基础组件进行了封装：包括数据消费、去重、累加、数据写入等算子，最终减少了部分任务50%的代码量，提高了整体的开发效率，让用户关注业务逻辑即可。
封装组件列表
运维管理方面：
为了解整体的容量情况，开发实时容量看板，通过实时获取 Zabbix Item LastValue 来监控 Storm & RedisCluster 实时压力情况；
为方便用户可以快速查看任务 Log 引入 ELK，同时在 Kafka2es 这一层引入 Hangout 替代 Flume （可支持3x以上性能提升），最终实现了 Storm Top Log->Logstash->Kafka->Hangout->ES->Kanbana 的整个 Log 链路。
整体 SLA 增强方面：
数据采集侧和计算侧均引入限速 & 反压功能，防止流量暴涨导致的雪崩效应；
从数据采集到数据最终落地使用双链路的方式，并采用多机房方式：比如数据采集端分布在异地两机房，使用本地计算+最终 Merge 或者数据双向传输+全量计算的方式；
配合 Kafka Binlog 数据的重放和 Nginx 模拟访问，对全链路进行模拟压测，配合实时监控 & 业务表现来关注各组件的性能临界点；
基于3的数据进行容量规划，同时做好资源的隔离；
完善各层面的监控和报警策略，包括模拟用户的访问来验证链路的情况，同时为了避免口径不一致导致的数据问题，开发离线&实时数据质量对比 Report，监控数据质量问题；
在业务端&后端增加降级策略，同时后端服务 Auto Failover；
完善各紧急预案 SOP，并针对性演练：比如通过切断 Active 的数据落地层来确定应用是否可以 Auto Failover；
数据层利用缓存，比如把一些 Storm 中间计算态数据写入 Redis 中；
同时为了防止应用 Crash 导致数据断层问题，开发了补数功能，在异常恢复后可以通过离线的数据补齐历史数据。
通过上述的一系列调整，最终抗住业务几倍的流量增长，保证了整体服务的稳定性。
业务监控 Dashboard 部分示例：
这个阶段实时平台的主要用户还是大数据自身，应用架构如下：
这个阶段虽然解决了数据源单一、整体 SLA 不高的问题，但是也带来了新的问题：
Storm 任务越来越多、Kafka Topic 越来越多、Topic 的 Producer 端和 Consumer 各是哪些、数据量如何，同时任务维护成本也越来越高，亟需一个平台化的工具；
用户的需求多样，一种引擎已经无法满足业务需求，需要多种引擎支持；
由于饿了么存在多语言开发场景（Go、Python、Java、
Scala 等），Storm 任务开发学习成本比较高，用户希望通过一个 SQL 即可支持部分简单场景；
业务 Log 需要通过 Nginx+Flume 方式收集，需要协调 OPS 部署 Flume，而 OPS 的同学比较排斥 Flume，亟需提供一个方便开发数据写入的标准 SDK 接入姿势；
之前业务数据落地仓库需要通过 Kafka->Flume->HDFS 方式，随着接入业务方变多，Flume 的维护成本越来越高，同时发生了多起 2HDFS 的 bug 导致数据重复的问题，亟需提供一个方便维护、支持多种数据 Sink 方式、稳定的数据流通解决方案。
3、平台化
17年初各产研逐步接入实时计算，上述问题也逐渐暴露出来，平台层面亟需一个统一的方案来解决用户的痛点。因此在年初，我们确定了“以 ERDP 实时平台为核心，打通数据采集、数据传输、数据计算、数据落地 DataPipeline 整体流程，为用户提供一个一站式的实时平台”的方向。
在此目标之上，我们做了如下的调整：
开发资源聚焦：
因为负责实时平台相关的小伙伴只有3-5人，我们开始逐步推动部分组件接入公司统一服务（比如监控 & 报警），并将部分任务移交到应用团队 team，只保留个别实时业务和平台相关部分开发；
考虑到 OR 每接入一个 DB 都需要启动 Instance，维护成本比较高，同时公司开始推动统一的 Binlog 解析工具 DRC 来做多机房间 DB 数据同步，因此我们也逐步使用 DRC 来替换 OR。
解决数据采集痛点：
通过开发统一的多语言数据接入 SDK 并接入配置中心，标准化数据接入的格式，方便用户的业务数据可以快速接入，同时为了提高可用性，在 SDK 中集成了降级 & 限速功能。
解决数据传输接入痛点：
参考 Flume Source->Channel->Sink 的思想，开发了基于 Storm 的 Data Pipeline 功能的组件 EDSink，可以支持多种数据写入方式，包括 2KAFKA、2ES、2HDFS、2DB。同时高度封装，抽象出部分配置，用户只需要通过填写一部分参数就可以实现数据的落地，大大加快了数据接入的效率，同时在数据落地层面引入了熔断功能；
在数据通过 EDSink 写入 HDFS 方面，打通了离线平台的调度系统和元数据管理使用，集成了建表和数据清洗功能，实现了一键化的数据落地。目前业务 Log 通过 EDSink 接入数据仓库已经从之前的2-3天降低到2小时以内；
为支持更细粒度的任务调度，在 EDSink 中集成基于 EventTime 分区功能，可以支持分钟粒度分区，结合 Spark 来支持半小时 ETL 链路的开发，小时整体链路从之前的40min缩短到20min左右即可完成；
同时和 Binlog 解析工具联动打通，支持用户自助申请落地 DB 数据，目前基于此方案，团队在进行 DB 数据去 Sqoop 化，预计可大大节省线上 DB Slave 服务器成本。
提供更多的计算方式：
引入 Spark Streaming 并集成到 ERDP 平台，封装基本的 Spark Streaming 算子，用户可以通过平台对 Spark Streaming 任务进行管理；
考虑到需要支持部分 SQL 的需求，在 Spark Streaming、Flink、Storm CQL 等引擎中做了对比，从团队的技术栈、引擎的成熟度、稳定性等层面综合考虑最终选择了 Spark Streaming。并基于 Spark Streaming 的 SQL 功能，为用户封装基本算子，同时支持上传 Jar 包提供 UDF 功能及 Scala 脚本支持，支持 Structured Streaming 以支持带状态的增量计算，实现用户写 SQL 即可满足实时开发的需求（目前可支持90%的业务场景）。
自动化&自助化便于任务和资源管理：
之前用户的 Storm 任务配置更改都需要重新打包，用户管理成本比较高，因此引入 Storm Flux 功能，封装基本组件并集成到实时平台。用户可以0代码生成数据 Sink，同时可以快速进行任务的开发和管理，自动生成 YML 文件降低任务的维护成本；
通过打通各个资源申请流程，支持 Kafka Topic 等资源的自助化申请和自动化创建，基于 Topic 数据完善元数据的管理，为资源的核算和实时元数据血缘做数据基础；
为了方便任务的监控，将 Storm，SparkStreaming，Kafka 层面监控统一入库 InfluxDB，并自动化模板生成功能，用户无需手动添加监控和报警，任务上线后 Metric & Dashboard 自动上报和创建，通过自动采集 API 的数据写入 InfluxDB，同时做了一个标准的 Template 用来自动生成 Grafana 的监控模板。
Kafka监控示例
通过上述一系列的调整，最终完善了整个平台，解决了用户开发成本高、接入成本高、管理成本高等痛点，最终的架构图就是文章开始的状况。
4、后续计划
虽然经过了一些演进，现有的平台仍然存在一些问题，比如：
SQL 方式覆盖场景有限；
用户在引擎中选择困难，没有一个引擎可以解决大部分需求；
Kafka0.8.2 版本功能有限，不支持 Excatly Once，不支持 JBOD Markdown 等；
实时和离线分离，数据重复建设，因为实现方式不同，实时和离线很难做到数据口径完全一致；
实时业务场景在公司内覆盖不够；
……
因此针对这些痛点我们也在做如下尝试：
Flink 以其性能&易用性在实时计算领域开始大行其道，我们也在做一些业务试点;
实时和离线融合 CEP 场景的试水；
Kafka 新版本的引入，包括 Qouta 限速、JBOD Markdown、Stream API、Excatly Once 等功能的支持；
实时平台集成到统一的一体化平台，用户在一个平台完成实时 & 离线开发；
发掘线上的业务场景，比如我们目前和策略部门合作的实时营销项目就是通过用户的行为数据来做一些策略，提高转化率。
四、一些心得
最后说一下关于平台化演进中的心得：
学会资源聚集（善于借助外力，must to have VS nice to have）；
MVP 最小化可行性调研（产品是迭代出来的，不是一蹴而就的，先完成后完美）；
偷懒思想，不重复造轮子（他山之石可以攻玉）；
赋能用户，尽量自动化&自助化（提高效率，解放生产力）；
数据化运营（用数据说话）；
资源隔离，重点业务的 SLA 保证（降级限流策略，反压功能等）；
做好监控（全链路的监控，并做必要测试）；
防范墨菲定律，及时做好容量规划 & 压测，同时不断完善 SOP；
抽象思维（从一个到一类问题的抽象）；
以解决实际问题为目的，而不是炫技；
关注用户体验（做完了 VS 做好了）；
防火胜于救火，多想几步，不断总结并完善标准 & 规划 & 流程（上线规范/ Checklist / SOP 流程等）。