跨越速运 x DorisDB:统一查询引擎,强悍性能带来极速体验

发布时间:2022年05月11日
       跨过速运集团有限公司创立于2007年, 现在服务网点超越3000家, 掩盖城市500余个, 是我国物流服务行业独角兽企业。跨过集团大数据中心担任全集团一切数据渠道组件的建造和保护, 支撑20余条中心事务线, 面向集团5万多职工的运用。
       现在, 大数据中心已建造数据查询接口1W+, 每天调用次数超越1千万, TP99在1秒以下。咱们运用DorisDB作为通用查询引擎, 有用处理了原架构许多查询回来时刻过长, 功用达不到预期的问题。“张杰跨过集团大数据运维架构师, 担任集团公司大数据渠道的保护和建造”一、事务布景1、全体架构咱们原始离线数仓的全体架构如下图所示, 数据从各个事务线的数据库,

比方MySQL等, 经过数据集成东西会聚到ETL集群(即Hadoop集群), 再运用Hive、Spark、Presto等批量处理引擎进行数据仓库的分层处理, 然后将DW层和ADS层的数据推送到各种不同的查询引擎。
       在这些查询引擎之上, 有个一致的查询API网关, 运用层的自助剖析东西或ERP体系前端经过调用这个API网关, 将数据内容出现给用户。二、事务痛点该体系最大的痛点是查询功用问题。公司对大数据查询接口的呼应推迟是有查核的, 期望99%的查询恳求都能在1秒内回来, 比方页面ERP体系、手机端各类报表APP, 用户会随时检查数据并进行出产环节调整, 过慢的查询呼应会影响用户体会, 乃至影响事务出产。针对杂乱的SQL查询场景, 之前选用的Presto、Impala+Kudu、ClickHouse等体系, 是远远达不到预期的。别的, 针对各种杂乱的数据剖析事务场景, 引进许多不同组件, 导致了保护和运用本钱十分高。因而, 咱们急需一个新的查询引擎, 能一致查询引擎,

处理功用查询问题, 下降运用和保护本钱。三、OLAP引擎选型第一阶段, 在2019年,

跨过集团大数据中心运用Presto作为通用的查询引擎。此阶段集团大数据中心数仓层根本用的是Hive, Presto能够直连Hive的特性让咱们无需做过多的改造, 就能够直接生成查询的API。从功用视点考虑, 咱们也会将数仓中的部分数据复制至独立的Presto集群, 和数仓ETL集群进行资源阻隔。
       这套架构运转一年多之后, 跟着事务需求越来越杂乱, 数据量越来越大, 该依据Presto构建的集群功用急剧下降。第二阶段, 为处理Presto集群功用缺乏的缺点, 咱们依据ClickHouse开端构建新的通用查询引擎。2020年咱们运用ClickHouse构建了许多大宽表, 将此前需求多层相关的查询逐渐迁移到ClickHouse集群。经过这种方法, 咱们的确处理了此前面对的功用问题。但与此同时, 咱们需求建造越来越多的大宽表, 操作繁琐运维困难。而且这种数据模型无法随事务需求改动而快速改动, 灵敏性差。第三阶段, 咱们在2021年开端寻觅其他能满意咱们需求的OLAP引擎, 此刻咱们发现了DorisDB这个产品。首要关注到DorisDB的单表、多表相关查询的功用都十分优异, 能够满意咱们对查询延时的需求;DorisDB支撑MySQL协议, 让咱们开发搭档在开发接口的时分学习和运用门槛十分低。别的, DorisDB还具有支撑按主键更新、支撑多种类型表面、布置运维简略以及支撑丰厚的数据导入方法等特性。这些都是咱们所需求的。因而, 咱们开端逐渐将以往的剖析事务迁移到DorisDB集群上, 将DorisDB作为大数据中心的通用查询引擎。四、DorisDB在跨过集团的运用1、在线场景运用当时咱们每天在线数据接口的查询恳求量现已超越千万。在引进DorisDB前, 咱们用了8到9种查询引擎来支撑各种在线事务场景。大数据量的明细点查场景运用ElasticSearch作为支撑;关于查询维度固定、能够提早预核算的报表场景, 会运用MySQL;关于SQL查询杂乱, 假如多表Join、子查询嵌套的查询场景, 会运用Presto;实时更新的场景, 则会运用Impala+Kudu的组合来支撑。引进DorisDB后, 现在已替换掉Presto和Impala+Kudu支撑的场景。ElasticSearch、MySQL以及ClickHouse, 后续也可能会依据事务场景实践情况逐渐替换为DorisDB。下面具体介绍一个实践在线场景的典型事例。如上图,

咱们在原Presto体系上有一个包括200个字段的宽表聚合查询。由于事务需求比较杂乱, SQL句子有600多行。咱们曾期望从事务逻辑上进行优化, 可是并不简单, 不能由于体系才能问题就一味要求事务方来姑息。现在咱们运用10个节点相同装备的DorisDB替换原15台相同装备服务器的Presto集群后, 在没有做什么事务逻辑改动的情况下, 运用DorisDB明细模型, 凭仗DorisDB自身的高功用将查询延时从5.7秒下降为1秒, 功用是原Presto集群的近6倍。2、OLAP场景运用跨过集团的OLAP多维剖析渠道是咱们自研的一套BI体系。用户能够依据自己事务场景挑选字段以及相关条件等, 以迁延拽的方法生成数据的表格或图表。最早咱们支撑OLAP多维剖析的后端引擎是Presto, 在这类场景下的功用的确不尽善尽美。由于功用问题, 咱们也没办法将这个东西推行给更多的用户运用。咱们将后端查询引擎替换为DorisDB后, 功用提高十分显着。咱们将OLAP多维剖析渠道向整个集团推行, 受到了越来越多的用户好评。OLAP多维剖析主要是离线剖析为主, 以客户离线剖析场景为例, 数据经过ETL处理后, 生成对应的DW层或ADS层数据, 再经过BrokerLoad将数据按天导入DorisDB中。咱们运用星型模型构建客户主题域, 客户主表以明细模型在DorisDB中建表, 相同以明细模型创立维表。这样用户就能够在前端对客户主题域的各种目标、各种维度进行迁延拽, 生成对应的表格和图表。在客户离线剖析场景下, 咱们DorisDB上线前后事务逻辑没有进行太多调整前提下, TP99从4.5秒下降到1.7秒, 功用是本来的三倍(后续咱们将测验敞开CBO优化器, 估计会有更大功用提高)。绝大多数场景都能完成1s内回来, 大大提高了用户的体会。运用DorisDB的实时剖析才能, 咱们还构建了实时OLAP多维剖析。以运单实时剖析场景为例, 本来咱们是用Hive每两小时跑批的方法来完成的,

将固定维度数据算好, 成果写入Presto上供给查询, 逻辑类似于离线数仓, 并不能称为真实的实时。引进DorisDB后, 咱们调整数据流通逻辑, 经过监听Binlog将数据写入Kafka, 再经过RontineLoad的方法消费Kafka, 将数据实时写入DorisDB中。咱们运用更新模型树立实时运单主表, 将运单ID设置成主键, 这样每一笔运单更新后, 都能实时更新到运单主表中。和离线剖析场景相同, 运用星型模型构建运单主题域。经过这样的调整, 以往每两小时更新数据的运单主题域, 现在能够完成秒级更新, 成为当之无愧的实时剖析。别的此前需求依靠预核算, 维度都是固定的, 许多剖析上功用受限。经改造后, 除了大幅提高“实时”体会外, 在剖析灵敏性上的提高也十分显着。实时体会和灵敏剖析也成为OLAP多维剖析渠道东西在实践服务中最大的亮点。五、后续规划1、为了防止部分慢查询影响全体的集群功用, 后续会建立多套DorisDB集群, 按事务场景进行物理资源阻隔。2、DorisDB查询Hive表面的功用, 经内部测试比Presto查询Hive的功用要好, 后续会将本来Presto查询Hive的场景无缝迁移到DorisDB上。3、现在咱们在DorisDB上写入了许多实时数据, 这些数据需求进行聚合等处理, 咱们正在测验运用调度东西, 在DorisDB上进行5分钟级、10分钟级的轻量ETL处理。4、敞开DorisDB的CBO优化器, 进一步提高查询功用。最终, 感谢鼎石为咱们供给DorisDB这么好的产品, 满意了咱们对功用强、功用全的查询引擎产品的要求;感谢鼎石一直以来供给的技术支撑, 处理了咱们在运用中遇到的各类问题。