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

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

本文主要内容如下：

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

• 选择Flink作为平台计算引擎的原因

• Flink的实践：有代表性的使用示例、为兼容Aerospike（平台的存储介质）的开发以及碰到的坑

• 当前效果&未来规划

一、实时特征平台的开发背景、目标以及现状

1、原实时特征作业的开发运维；

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

• 80%以上的作业需要用到消息队列数据源，但是消息队列为非结构化数据且没有统一
  的数据字典。所以需要通过消费对应的topic，解析消息并确定所需的内容

• 基于需求中的场景，设计开发计算逻辑

• 在实时数据不能完全满足数据需求的情况，另外开发单独的离线作业以及融合逻辑；
  例如：在需要30天数据的场景下，但消息队列中只有七天内的数据时（kafka中消息的默认保留时间），剩下23天就需要用离线数据来补充。

• 设计开发数据的校验和纠错逻辑
  消息的传输需要依赖网络，消息丢失和超时难以完全避免，所以需要有一个校验和纠错的逻辑。

• 测试上线

• 监控和预警

2、原实时特征作业的开发痛点

• 消息队列数据源结构没有统一的数据字典

• 特征计算逻辑高度定制化，开发测试周期长

• 实时数据不能满足需求时，需要定制离线作业和融合逻辑

• 校验和纠错方案没有形成最佳实践，实际效果比较依赖个人能力

• 监控和预警方案需要基于业务逻辑定制