0. 目录
- 业务背景:雄关漫道真如铁
- 技术探讨:工欲善其事必先利其器
- Ingest SST
- Map/Reduce产出全局有序文件
- 系统架构:千磨万击还坚劲
- 总结展望:直挂云帆济沧海
- 基于FastLoad的数据传输给业务带来的收益
- 发展规划
FastLoad致力于离线数据在线化,服务业务300+,单日运行次数1000+,在线搬运30TB+的数据,提供数百亿次高效查询,服务稳定性达到99.99%。
1. 业务背景:雄关漫道真如铁
在没有FastLoad以前,业务一般都会自己维护读离线数据,写在线存储引擎的业务逻辑。比如,滴滴有很多重要的业务有如下的场景:前一天的订单数据会落到离线平台,经过一些特征提取和分析,转换成业务需要使用的数据。在第二天线上高峰期前,需要把这部分数据及时导入线上,才能够不影响业务逻辑。这些业务都需要定时更新在线数据、线上使用最新数据,下面我们对需求进行提取。
定时更新
像特征数据,一般需要小时级别甚至天级别的更新,所以业务需要有快捷的定时更新功能。
快速更新
特征数据还有一个特点,就是数据量特别大,以乘客特征为例,动辄上 TB 级别数据量。这么大的数据量通过 SDK 写入肯定是不行的。刚开始业务方也确实是这么玩的,直接通过 Hadoop 任务调用 Redis SDK,然后一条条的写入 Fusion,一般是每天凌晨开始写数据,等到早高峰 8 点时大量读取。但是这种方法实践下来,经常导致 Fusion 各类超时,在早高峰打车已经来临时还在写凌晨的数据,非常影响稳定性。因此第 3 个需求是必须快速更新。
稳定性
这个是毋容置疑的。
多表隔离
有些业务有很多类特征数据,他们有隔离存储的需求,也有分类更新、分类查找的需求,因此需要多表来支持逻辑到物理的隔离。