1、Flink 在数据分析中的应用 肖 强 TalkingData 架构师 TalkingData流处理的背景与痛点 Flink在TalkingData SaaS分析中的演进路线 Flink实践中的重点问题解决方案 总结与展望 Agenda TalkingData SaaS的流处理服务演进: 1. TalkingData流处理的背景与痛点 Before 20017now Jetty 服务 不易扩展与维护 性能问题 自研etl-framework 无法完整表达DAG 容错机制不足 性能问题 新的流处理系统 满足更大的业务量 满足更复杂的业务场景 Flink是什么 1. Talk

2、ingData流处理的背景与痛点 技术选型 1. TalkingData流处理的背景与痛点 注:对比为16年的特性FlinkHeron 性能优于storm，基于流优于storm，基于流 语义exactly-once/at-least-onceat-least-once 自主内存管理是否 Operator支持较丰富较丰富 SQL支持是否 Batch支持Batch只是stream的特例否 监控不完善较完善 使用者阿里, 华为Twitter 2.1 standalone cluster 2. Flink在TalkingData SaaS分析中的演进路线 2.1 standalone cluster

3、2. Flink在TalkingData SaaS分析中的演进路线 分布式数据收集服务: td-collector 分布式消息队列: Kafka 流式引擎: Flink 流式服务:etl-service 存储: HDFS/Cassandra/Elasticsearch OLAP engine:Druid 2.1 standalone cluster 2. Flink在TalkingData SaaS分析中的演进路线 时间点数据量问题部署规模 2017.4 2017.6 Game: 12亿 SDK packages/day, Game: 峰值 1.8w SDK packages/s 无单集群，4

4、8 cores 2017.7 2017.8 Game: 18亿 SDK packages/day, Game: 峰值 3w SDK packages/s Job deployed不均匀，导致消费不均匀单集群, 120cores 2017.9 2017.12 Game: 16亿SDK packages/day, Game: 峰值2.7w SDK package/s, App: 19亿 SDK packages/day, App: 峰值2.5w SDK packages/s 随着Job部署增多，相互干扰抢占资源； 阻塞在requestBufferBlocking,导致整个 Job假死 单集群，26

5、4cores 2018.1 2018.12 Game: 16亿 SDK packages/day, Game: 峰值2.8w SDK package/s, App: 28亿 SDK packages/day, App: 峰值 4.6w SDK packages/day, Other-jobs: 20w events/s 资源分配不均，job相互干扰拆分成2个集群，456cores 2.2 flink on yarn 2. Flink在TalkingData SaaS分析中的演进路线 job执行计划构建/提交/web ui 多租户分发/调度 监控 Flink on yarn cluster 批处

6、理队列 App Batch Yarn 1 ADT Batch Yarn 1 Game Batch Yarn 1 混合队列 Hybrid Yarn 1 流式队列 App Stream Yarn 1 App Stream Yarn 2 Game Stream Yarn 1 ADT Stream Yarn 1 ADT Stream Yarn 2 HDFS YARN Resource Manager 2.2 flink on yarn 2. Flink在TalkingData SaaS分析中的演进路线 3. Allocate AppMaster Container YARN ContainerYARN

7、 Container Flink TaskManager 4. Allocate Worker Always Bootstrap containers with Uberjar and config 1. Store Uberjar and configuration “Master” Node YARN Container Flink TaskManager Flink JobManager YARN App, Master 2. Register resources and request AppMaster container Flink YARN Client 2.2 flink on

8、 yarn 2. Flink在TalkingData SaaS分析中的演进路线 日均:42亿 7.4w package/s 20w events/s 规模: 456 核 Standalone Cluster 日均:15亿 2.8w package/s 40w events/s 规模: 120 核 Standalone Cluster 日均:46亿 6.5w package/s 40w events/s 规模: 288 核 On Yarn 日均:63亿 9.5w package/s 80w events/s 规模: 432 核 On Yarn 2018/122019/72019/11 3.1 J

9、ob阻塞与网络 栈的优化 3. 实践经验 问题：Job Blocked, 吞吐量急剧下降 3.1 Job阻塞与网络栈的优化 3. 实践经验 分布在不同TM的operator 之间的数据传输需要Buffer Buffer即MemorySegment， 有效减少GC 数据传输与Buffer申请释放 的过程 BufferPool中Buffer不足时 会阻塞 3.1 Job阻塞与网络栈的优化 3. 实践经验 3.1 Job阻塞与网络栈的优化 3. 实践经验 11 TaskManager 1TaskManager 2 TCP Connection announce credit Send buffers

10、 & Announce backlog size Channel Credit Backlog Backlog size Subtask A.2Subtask B.4 Floating Buffers Unannounced Credit Exclusive Buffers Ask for floating buffers 2 0 5 1 1 1 1 1 1 1 1 1 1 1 1 1 Buffer Pool 2 3.1 Job阻塞与网络栈的优化 3. 实践经验 尽可能的将operator chain 在一起，避免网络传输和 序列化反序列化的开销 使用Flink 1.5之后的版本 3.2 资源

11、的balance与isolation 3. 实践经验 Standalone cluster资源分配不均匀 Task slot TM1 Task slot 空 闲 TM2 Task slot 空 闲 TM1 3.2 资源的balance与isolation 3. 实践经验 Standalone的不均匀现象Task slot 空 闲 TM2 Task slot 空 闲 TM3 Task slot 空 闲 TM4 3.2 资源的balance与isolation 3. 实践经验 解决之道 将TaskManager的粒度变小，即一台机器部署多个实例，每个实例持有 的slot数较少； 将大的业务job隔

12、离到不同的集群上 Flink on Yarn Container的拆解粒度不宜过小: 1core 2g vs 2core 4g 3.3 Serialize/Deserialize 3. 实践经验 遇到问题: 序列化成了CPU抽样的热点，对性能损耗较大 更泛化的JsonNode vs Pojos TypeInformation: 类型信息知道的越多，Flink可以选取更好的序列化方式，并使Flink对内存的使用更高效； TypeInformation内部封装了自己的序列化器，可通过createSerializer()获取，这样可以让用 户不再操心序列化框架的使用(例如如何将他们自定义的类型注册到

13、序列化框架中，尽管 用户的定制化和注册可以提高性能) POJOs: 类似于Java-Bean 成员类型是Primitive, 或者BasicType 3.3 Serialize/Deserialize 3. 实践经验 3.3 Serialize/Deserialize 3. 实践经验 显示调用returns方法，触发Flink的Type Hint: dataStream.flatMap(new MyOperator().returns(MyClass.class) 注册subtypes: 通过StreamExecutionEnvironment或ExecutionEnvironment 的实例的registerType(clazz)方法注册我们的数据类及其子类、其字段的 类型。如果Flink对类型知道的越多，性能会更好； 自己定制序列化器 4. 总结与展望 Flink已经稳定支持TalkingData分析线日均63亿 package，峰值: 9.5w package/s 80w events/s的体量 未来可以探索将更复杂的业务迁移到Flink上，甚 至Batch Job