万亿级实时流计算架构

1、万亿级实时流计算架构技术创新，变革未来流计算在运营商中有什么用途？应用领域：时延敏感的应用领域 网络层面：实时性能监控故障预测位置信息服务：实时人流（标签）实时标签用户行为预测1大数据在运营商网络维护和优化中的应用举例高铁沿线短信中 心疑似病毒URL清单360确认结果进一步处置： 信安中心进 一步确认、 提醒、直接 封堵2高铁模拟路测故障双向定界病毒短信检测平台架构3平台与数据规模APP#3CPU CORE480数据量约50TB/天记录数约1200亿/天4Storm的主要组件Storm平台的 物理结构5一个Topology的 逻辑结构实践经验（1）：从SDTP到Flume Source：透传

2、Vs. 落盘【问题描述】在Flume出现流量瓶颈，说的更准确一些，是在Flume的前一级服 务器出现数据堆积透传，单线程落盘，多线程6实践经验（2）：Kafka的流量“陷阱”【问题描述】Kafka出现瓶颈7实践经验（3）：运算结果的更新方式：增量式 Vs. 覆盖式8【问题描述】严重的结果稳定性问题。以某省会城市的5分钟流量为例，比如一 般都在800GB上下，但有时候某一次计算结果突然下降到400GB左右在不考虑数据延迟的情况下，为了计算5分钟的流量，我们需要在Bolt中设置 一个变量hz_bytes以保存中间结果。比如在10:03的时候，hz_bytes中实际保 存了10:00 10:03的该

3、市流量。当10:05时，该Bolt就将hz_bytes的值输出到Redis中。如果这个Bolt所在的Executor在10:03挂掉，Storm会重新选择一个Worker，并 重新调度该Bolt这是Storm的一个最基本的HA机制。但是当Bolt重新启动 后，hz_bytes却已经丢失了之前暂存的10:0010:03流量。所以，最后写出到Redis的，实际上是10:0310:05的流量。这就是结果中流量 会突然减少的原因。增量式覆盖式性能？健壮性？实践经验（4）：数据倾斜与分片【问题描述】因某个Bolt处理的数据量特别大，导致集群性能严重不足。【例】如果计算每个地市的总 流量（某省的话，总共是

4、11个 地市），一种做法是直接根据 地市对数据进行分片，然后直 接汇总。但是由于某些大城市 的流量特别大，从而导致处理 这些地区Bolt的压力特别大， 从而大幅度延缓了整个Toplogy的处理性能。9【解决办法】先CELL级别汇总， 后地市级别二次汇总【额外的性能开销？】实践经验（5）：Redis的吞吐能力【问题描述】因Redis读写能力不足，导致批量写Redis的Bolt出现性能瓶颈。内存操作单线程非阻塞IO（EPOLL）10如何定位Storm UI中“读写Redis”的Bolt会频繁抛出类似“Redis连接池满，无法获得连 接”、“Redis连接被复位”的ExceptionRedis采用的

5、是单线程模型，因此，当出现性能瓶颈时，会有一个CPU CORE的使用率接近100%，这个可以通过“mpstat -P ALL”看到实践经验（6）：数据延时的计算方法力【问题描述】在现网调测和后期运行的过程中，如何确定数据延时的“分布”2类值得关注的数据延时从Flume进，到Kafka出从Flume进，到Storm输出最终结果（端到端延时）11【基本思想】Flume源端随机 生成测试数据，Storm端发现 并保存数据实践经验（7）：原始数据的清洗与过滤【问题描述】处理的数据量严重偏少，统计出来的流量值只有其他途径的1/2”在Spout端统计Storm处理的数据总量、过滤数量及由Spout最终Em

6、it出来的量， 以文件的形式保存，并通过脚本将数据进行统计处理习惯与“脏数据”共事，对大数据从业者而言很重要！12实践经验（8）：基站小区活跃用户数的统计方法【问题描述】在尽可能少消耗系统资源前提下，在误差允许的范围内，实时计算基站小区的活跃用户数（类似于UV的实时计算？）最准确的方法用HashSet保存手机号码Bloom FilterHyperLogL og资源消耗误差统计结果的 可聚合性13流计算系统的监控重点关注Flume、Kafka、Storm、Redis等各主要进程运行是否正常？数据在“流转”过程中在任何节点都不会出现“积压”？ 混入的测试数据的计算结果是否正确？Flume数据积压测试记录KafkaKafka ManagerKafka Offset MonitorStorm：Storm UISpout和B