随着电子商务的蓬勃发展和快递物流行业的日益激烈竞争,中通快递作为该行业的领先者,正面临着前所未有的业务处理量和快速增长的数据处理需求。在这种背景下,企业内部对数据的时效性、准确性以及即时可用性的要求不断提高,不仅需要天、小时级别的离线数仓进行事后的数据分析和决策支持,也更加重视通过实时数仓实现对事中事件的预警和即时干预。
优点:数据准确度高,不易出错;
劣势:架构复杂,运维成本高。
方案劣势:数据冗余、链路复杂、排查困难
方案劣势:查询性能较低,无法支撑高QPS
Kafka实时数仓 | OLAP数仓 | Lambda数仓 | |
数据维护性 | 中 | 简单 | 中 |
查询性能 | 高 | 中 | 高 |
数据时效 | 高 | 高 | 高 |
成本 | 高 | 中 | 高 |
适用场景 | 时效性和QPS要求非常高,需求较固定 | QPS要求不高,对灵活性要求较高 | 实时离线需求重叠较高,对历史数据统计要求较高 |
中通实时数仓主要以olap数仓为主,同时针对高QPS场景,使用预聚合在保障分钟级延迟情况下提高查询性能。
宽表模型有以下优点:
在数据开发过程中,往往由于数据源多、数据流复杂,不同数据流程的处理差异常导致报表指标不统一,将核心逻辑集成至宽表可以显著简化数据一致性
宽表在落地时,不仅仅是不同数据源字段的聚合,同时也会根据业务场景,业务需求预处理复杂逻辑。例如,对于跟踪快递单号的当前状态(如收件、发件、揽收、派送、签收),原需通过多条件判断当前状态。引入宽表后,通过预先设定的状态字段简化了此类复杂业务逻辑的处理,使得数据更易于管理和使用。
在复杂的实时数据处理链路中,多组件依赖和潜在的维护或硬件异常可能引起数据重复。宽表通过实施幂处理机制,确保数据仅被计算一次,保障了数据的准确性和可靠性。
在实时宽表处理中,面临诸多挑战: