cover_image

中通实时数仓概述

中通科技 科技中通
2024年07月25日 08:21

随着电子商务的蓬勃发展和快递物流行业的日益激烈竞争,中通快递作为该行业的领先者,正面临着前所未有的业务处理量和快速增长的数据处理需求。在这种背景下,企业内部对数据的时效性、准确性以及即时可用性的要求不断提高,不仅需要天、小时级别的离线数仓进行事后的数据分析和决策支持,也更加重视通过实时数仓实现对事中事件的预警和即时干预。

图片

图片

图片



图片


图片

图片

优点:数据准确度高,不易出错;

劣势:架构复杂,运维成本高。



图片

图片

方案优势:实践丰富、层次分明、分工明确

方案劣势:数据冗余、链路复杂、排查困难


图片

图片

方案优势:业务灵活性强,指标修正简单

方案劣势:查询性能较低,无法支撑高QPS


图片


Kafka实时数仓

OLAP数仓

Lambda数仓

数据维护性

简单

查询性能

数据时效

成本

适用场景

时效性和QPS要求非常高,需求较固定

QPS要求不高,对灵活性要求较高

实时离线需求重叠较高,对历史数据统计要求较高


图片

图片

中通实时数仓主要以olap数仓为主,同时针对高QPS场景,使用预聚合在保障分钟级延迟情况下提高查询性能。


图片

宽表模型有以下优点:

  • 统一指标口径

在数据开发过程中,往往由于数据源多、数据流复杂,不同数据流程的处理差异常导致报表指标不统一,将核心逻辑集成至宽表可以显著简化数据一致性

  • 提高开发效率:

宽表在落地时,不仅仅是不同数据源字段的聚合,同时也会根据业务场景,业务需求预处理复杂逻辑。例如,对于跟踪快递单号的当前状态(如收件、发件、揽收、派送、签收),原需通过多条件判断当前状态。引入宽表后,通过预先设定的状态字段简化了此类复杂业务逻辑的处理,使得数据更易于管理和使用。

  • 保证数据准确性:

在复杂的实时数据处理链路中,多组件依赖和潜在的维护或硬件异常可能引起数据重复。宽表通过实施幂处理机制,确保数据仅被计算一次,保障了数据的准确性和可靠性。


在实时宽表处理中,面临诸多挑战:

  • 数据处理和排查问题
使用Flink处理数据时,其状态的不可见性尤其在遭遇数据异常时挑战重重。限于Kafka存储成本及数据保留量,追溯问题变得困难。引入Hive作为明细数据存储,记录每个状态的快照,便于异常时利用Hive的数据进行诊断。

图片


  • 多流数据Join:
处理多数据流Join时,Flink SQL复杂化任务结构,影响性能。转而使用Flink原生API,并针对Flink Connect算子的限制及union算子的格式一致性要求,通过自定义数据类型和键值提取,实现数据统一处理,维持数据源schema。

图片


  • 状态丢失与数据异常:
Flink处理中,初期开发可能未覆盖所有业务场景,导致状态数据异常。面对此情况,先暂停处理,用补丁程序修复TiDB明细数据,然后丢弃状态,新的数据进来时从tidb读取数据然后存入状态中,确保新数据处理时的数据准确性。

图片


图片

图片

图片

图片

图片


图片


继续滑动看下一个
科技中通
向上滑动看下一个