例如有这样一个需求：业务方希望获取司机实时更新的累计完单量，需保证收到完单事件后秒级更新。由于滴滴订单量很大，单个司机的完单量从几单到几万单不等，直接查询底层存储如MySQL、ElasticSearch等存储，会对底层存储造成很大查询压力，并且延时也较高，在高并发等情况下容易出现各种问题。在特征服务这边采用批处理+流处理这样的Lambda架构来实现这类需求，整个的数据流如下：
可以看到这是一个典型的Lambda架构，不了解的可以参考维基百科：Lambda architecture
在统计特征汇总历史完单量和实时完单量，需要注意以下情况：当T-1天未准备就绪时，需要使用T-2天的历史数据、T-1天实时数据、T天实时数据相加。举例如下：
假设批处理计算司机历史完单量的任务平均在上午6点完成并导入KV存储系统。
- 在6月10日0到6时期间，计算逻辑如下：截止到6月8日（含）的历史完单量 + 6月9日的实时完单量 + 6月10日的实时完单量。
- 在6月10日6到24时期间，计算逻辑如下：截止到6月9日（含）的历史完单量 + 6月10日的实时完单量。