携程基于携程基于Flink的实时特征平台的实时特征平台
本文主要内容如下:
在公司实时特征开发的现状基础上,说明实时特征平台的开发背景、目标以及现状
选择Flink作为平台计算引擎的原因
Flink的实践:有代表性的使用示例、为兼容Aerospike(平台的存储介质)的开发以及碰到的坑
当前效果&未来规划
一、在公司实时特征开发的现状基础上,说明实时特征平台的开发背景、目标以及现状
1、原实时特征作业的开发运维
1.1、选择实时计算平台:依据项目的性能指标要求(latency,throughput等),在已有的实时计算平台:Storm Spark flink进
行选择
1.2主要的开发运维过程:
80%以上的作业需要用到消息队列数据源,但是消息队列为非结构化数据且没有统一的数据字典。所以需要通过消费对应的
topic,解析消息并确定所需的内容
基于需求中的场景,设计开发计算逻辑
在实时数据不能完全满足数据需求的情况,另外开发单独的离线作业以及融合逻辑;
例如:在需要30天数据的场景下,但消息队列中只有七天内的数据时(kafka中消息的默认保留时间),剩下23天就需要用离
线数据来补充。
设计开发数据的校验和纠错逻辑 消息的传输需要依赖网络,消息丢失和超时难以完全避免,所以需要有一个校验和纠错的逻
辑。
测试上线
监控和预警
2、原实时特征作业的开发痛点
消息队列数据源结构没有统一的数据字典
特征计算逻辑高度定制化,开发测试周期长
实时数据不能满足需求时,需要定制离线作业和融合逻辑
校验和纠错方案没有形成最佳实践,实际效果比较依赖个人能力
监控和预警方案需要基于业务逻辑定制
3、基于整理的痛点,确定下来的平台目标
实时数据字典:提供统一的数据源注册、管理功能,支持单一结构消息的topic和包含多种不同结构消息的topic
逻辑抽象:抽象为SQL,减少工作量&降低使用门槛
特征融合:提供融合特征的功能,解决实时特征不能完全满足数据需求的情况
数据校验和纠错:提供利用离线数据校验和纠错实时特征的功能
实时计算延迟:ms级
实时计算容错:端到端 exactly-once
统一的监控预警和HA方案
4、特征平台系统架构
评论0