携程基于Flink的实时特征平台-阿里云开发者社区

携程基于Flink的实时特征平台

2018-11-14 3516

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

实时计算 Flink 版，5000CU*H 3个月

简介： 本文来自7月26日在上海举行的 Flink Meetup 会议，分享来自于刘康，目前在大数据平台部从事模型生命周期相关平台开发，现在主要负责基于flink开发实时模型特征计算平台。熟悉分布式计算，在模型部署及运维方面有丰富实战经验和深入的理解，对模型的算法及训练有一定的了解。

本文来自7月26日在上海举行的 Flink Meetup 会议，分享来自于刘康，目前在大数据平台部从事模型生命周期相关平台开发，现在主要负责基于flink开发实时模型特征计算平台。熟悉分布式计算，在模型部署及运维方面有丰富实战经验和深入的理解，对模型的算法及训练有一定的了解。

本文主要内容如下：

一、在公司实时特征开发的现状基础上，说明实时特征平台的开发背景、目标以及现状#

1.1、选择实时计算平台：依据项目的性能指标要求（latency，throughput等），在已有的实时计算平台:Storm Spark flink进行选择

1.2主要的开发运维过程：

80%以上的作业需要用到消息队列数据源，但是消息队列为非结构化数据且没有统一的数据字典。所以需要通过消费对应的topic，解析消息并确定所需的内容
基于需求中的场景，设计开发计算逻辑
在实时数据不能完全满足数据需求的情况，另外开发单独的离线作业以及融合逻辑；
例如：在需要30天数据的场景下，但消息队列中只有七天内的数据时（kafka中消息的默认保留时间），剩下23天就需要用离线数据来补充。
设计开发数据的校验和纠错逻辑消息的传输需要依赖网络，消息丢失和超时难以完全避免，所以需要有一个校验和纠错的逻辑。
测试上线
监控和预警

现在的架构是标准lamda架构，离线部分由spark sql + dataX组成。现在使用的是KV存储系统Aerospike，跟redis的主要区别是使用SSD作为主存，我们压测下来大部分场景读写性能跟redis在同一个数据量级。

实时部分：使用flink作为计算引擎，介绍一下用户的使用方式：

注册数据源：目前支持的实时数据源主要是Kafka和Aerospike，其中Aerospike中的数据如果是在平台上配置的离线或者实时特征，会进行自动注册。Kafka数据源需要上传对应的schemaSample文件
计算逻辑：通过SQL表达
定义输出：定义输出的Aerospike表和可能需要的Kafka Topic,用于推送Update或者Insert的数据的key

用户完成上面的操作后，平台将所有信息写入到json配置文件。下一步平台将配置文件和之前准备好的flinkTemplate.jar(包含所有平台所需的flink功能)提交给yarn，启动flink job。

1）平台功能展示-数据源注册

2）实时特征编辑-基本信息

3）实时特征编辑-数据源选择

4）实时特征编辑-SQL计算

5）实时特征编辑-选择输出

我们下面一个我们说一下我们选择flink来做这个特征平台的原因。

分为三个维度：最高延迟、容错、sql功能成熟度

延迟：storm和flink是纯流式，最低可以达到毫秒级的延迟。spark的纯流式机制是continuous模式，也可以达最低毫秒级的延迟
容错：storm使用异或ack的模式，支持atLeastOnce。消息重复解决不。spark通过checkpoint和WAL来提供exactlyOnce。flink通过checkpoint和SavePoint来做到exactlyOnce。
sql成熟度：storm现在的版本中SQL还在一个实验阶段,不支持聚合和join。spark现在可以提供绝大部分功能，不支持distinct、limit和聚合结果的order by。flink现在社区版中提供的sql，不支持distinct aggregate
三、Flink实践#
1、实⽤示例