中通快递基于SelectDB实时数仓的应用实践

童孝天高级研发工程师 背景介绍01应用实践02对比测试03未来展望04 目录 01背景介绍 公司简介 简介 中通快递股份有限公司成立于2002年5月8日，总部位于上海，是一家集快递、物流及其他业务于一体的大型集团公司，中通快递的包裹量在2024年第三季度达到了87.2亿件，同比增长15.9%，市场份额为20.0%左右。 中通科技是中通快递旗下的互联网物流科技平台，拥有一支千余人规模的研发团队，秉承着“互联网+物流”的理念，与公司的战略、业务紧密的衔接，为中通生态圈的业务打造全场景全链路的数字化平台服务。 选型背景 随着业务的不断发展，之前双十一的业务量到现在已成为每日的常态。为了满足各大业务场景对实时分析时效性的要求，同时保证数据快速写入和极速查询，需要一个合适的OLAP引擎补充原有的离线数仓架构体系，痛点具体如下： 数据时效不足 离线数据仓库使用离线抽取的方案，数据时效性为T+1，而报表、数据大盘要求数据实时更新，当前架构无法满足 查询效率低 BI报表/离线分析需满足秒级别查询响应，离线数据仓库执行引擎主要是Trino及SparkSQL，需读取和写入HDFS中的数据，执行时长一般为分钟级别，影响查询效率 维护成本高 整个技术栈涉及组件繁多，包括Trino/HDFS/Yarn/HBase，之前线上也有一些实时场景使用ClickHouse，但是维护较为复杂，且有些场景需求也无法满足 应用场景 借助SelectDB的高效的数据更新，低延时的实时写入以及优异的查询性能，我们在以下几个场景中进行应用实践： 复杂的实时需求 构建实时宽表，横跨快递的整个生命周期，需要汇总多条kafka数据流，进行数据整合，在通过Flink计算后，将数据写入SelectDB集群，并在此基础上进行准实时的数据分析 离线数据查询 对于BI报表/离线分析需满足秒级别查询响应，我们将离线数据计算后的数据定期导入实时数仓SelectDB表中，可以实现快查询，满足离线数据分析和决策的需求 简单的实时需求 对于一些较为简单的实时需求，利用SelectDB的部分列更新，以及其高效的查询能力，给C端或者实时大屏提供数据服务接口的能力 实时宽表 借助其他OLAP数据库，构建大宽表，基于宽表做分钟级的准实时分析： 存在的问题：总任务数50+，时效在5-10分钟，随着任务数量的增加，同一时间点的任务数会增加，导致集群负载变大，影响任务的执行时间，时效难以保证 使用SelectDB带来的收益 更节约 更高效 更稳定 支持分区表，扫描的分区数据固定，相对较稳定，原OLAP对全局索引不是很友好，每次都会扫描全表数据，对集群影响更大 相比原OLAP数据库，部分SQL性能提升5-10倍，从原来10分钟左右到目前90%以上的分析能到1分钟内，部分可以秒级响应 资源仅使用原有机器的1/3，便可以cover住原来的所有业务 BI报表/离线分析加速 查询不够稳定 在超大Hadoop集群下，namenode的轻微抖动会严重影响一些短而小的adhoc查询和报表分析，导致查询不够稳定。 不支持高并发 使用的Trino和SparkSQL在处理大规模数据集方面表现出色，但面对高并发查询时，处理效率与我们的预期存在较大差距。 引入SelectDB 极致的加速体验 •在实时数仓建设阶段，我们把离线数据DIM维度层、应用层的数据通过SeaTunnel写入了SelectDB中，实现了结果表的查询加速，从而实现每秒上2K+数量级的QPS并发查询，数据报表更新及时度大大提高 •SelectDB提供了灵活丰富的SQL函数公式，并拥有高吞吐量的计算能力，数据分析师、产品经理等业务人员通过Metabase（数据探索与可视化工具）+SelectDB即可基本满足BI的数据探索需求，大部分查询响应速度都在秒级完成 高并发与分析场景实践 极致的时效性 作为数据服务提供数据大屏，对实时性要求高，借助倒排、BloomFilter来支持多维分析，通过合理的分区分桶，在查询时过滤非必要的数据，使数据扫描快速定位，加速查询响应时间 需要进行更新 支持主键表（UniqueKey）进行高效的数据更新，并对Upsert、条件更新/条件删除、部分列更新、分区覆盖等各类更新提供了完备的支持，满足高效灵活的数据更新需求 对表结构的设计需要结合业务，因地制宜，合理规划Key和分区分筒列，一般将where条件或者join的字段定义成分桶较为合适 ES使用场景 写入吞吐大/高并发点查询 快递信息流转数据量巨大，对写入要求高，并且对订单ID等有高并发点查的需求。 多维查询 创建时间/签收时间分片 为了加速查询性能，减少扫描数据，分别按照揽收时间/签收时间分片，冗余多份数据，加速查询 ES相关业务痛点 存储成本高 •全字段索引：索引在表创建时是固定的，基于多维度查询创建了全字段索引，存储成本相对较高。 •数据写入时倒排索引需要进行分词，排序等一些CPU密集型操作，大量的倒排索引会导致写入性能下降。 •根据逻辑字段按照固定算法确定数据所属分片，指定分片查询；•需要额外了解ES查询语法，门槛高。 基于SelectDB带来的收益 多场景下的查询加速 存储成本低 开发灵活 SelectDB兼容MySQL，使开发操作简单、使用门槛低，并且易于部署、迁移与运维。 按需设置倒排索引，降低数据存储，另外SelectDB列存采用的ZSTD压缩算法，可实现8:1的压缩比，进一步降低存储成本。 高频使用SelectDB分区分桶裁剪功能，在查询时过滤非必要的数据，因而在百亿数据集下，依然能有很快的响应时间和更高的并发。 SelectDBVsPresto 数据量 单分区:100GB数据格式：ORC SelectDB较Presto有1-2倍的性能提升 参数优化 dfs.client.socket-timeout=500解决长尾问题，hdfs集群较大，负载较高时，调低socket-timeout，快速失败，从新的block块进行读取重试，提升稳定性 未来规划 目前SQL调优，严重依赖Profile，优化难度大，期望Profile能精简，更直观，方便用户调优 降低用户之间的影响，针对不同的用户优先级，分配相应的资源 加强在数据湖上的应用 打通Hive外表权限验证 借助Multi-Catalog功能，支持多种异构数据源上的联邦查询，提升SelectDB在Hudi/Paimon等数据湖上的分析能力 使用Hive-Catalog后的权限希望能透传JDBC账号，用于和现有大数据权限体系打通，进行权限管控 ThanksforWatching！