本文共 1001 字，大约阅读时间需要 3 分钟。
大数据项目组实时流处理架构设计与优化
本文总结了大数据项目组在亲听项目和全链路debug项目中实时流处理的需求梳理、架构选型及实现效果。
一、背景介绍
1.1 亲听项目
亲听项目旨在帮助用户收集、展示、监控和处理用户体验问题，是保障产品主观评价质量的重要工具。通过对上游TimeTunnel日志的解析和处理，亲听系统输出关键指标并进行前端展示和阈值监控报警，用于算法效果监控。
需求要点：
每秒处理万级到几十万级的TimeTunnel日志记录 数据处理逻辑复杂且需支持频繁迭代 需要秒级低延时的数据展示 1.2 全链路debug
全链路debug专注于在线搜索异常时定位后端子系统问题。其实时流处理需求是从TimeTunnel日志中提取关键内容，用于问题排查。
需求要点：
每秒处理万级到几十万级的日志记录 单条记录数据较大（平均几KB） 解析逻辑主要为字段提取和透传
二、解决方案
2.1 整体架构
亲听和全链路debug的实时流处理系统架构如下：
亲听：
- 采用tt → blink → HBase架构
- blink任务输出到TimeTunnel中记录的字段经分类合并处理
- 下游引入druid进行实时流查询
全链路debug：
- 采用tt → blink → Druid架构
- Druid表中存储实时流数据
- 单条记录数据大小较大，适合HBase存储
2.2 实时性
- 数据处理：使用blink的Table API编写，支持复杂逻辑且代码可维护性高
- 存储与查询：结合HBase和Druid，满足高并发写读需求
2.3 扩展性
- 查询逻辑前移：将Druid查询逻辑迁移到blink任务，提升扩展性
- 字段归类合并：通过udtf函数统一处理多值字段，减少代码复杂度
2.4 实时流处理优化
- 查询性能优化：将处理逻辑迁移到blink任务，减少Druid内存占用和查询延迟
- 架构选择：根据数据特性选择HBase或Druid，提升处理效率
三、成果总结
通过对亲听和全链路debug项目的实时流处理需求的梳理和架构优化，我们成功实现了以下成果：
- 高效处理：实现了秒级延时完成实时日志处理
- 架构灵活：支持多种场景下的实时流处理需求
- 性能优化：显著提升了系统的扩展性和查询性能
四、作者简介
鸷鸟，来自搜索事业部-工程效率与技术质量-算法工程平台-实时大数据平台，15年加入阿里，专注于电商体系实时数据研发及实时大数据平台建设。
转载地址：http://qtgb.baihongyu.com/