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