导读：为了适应快速的增长需求，橙联于年正式引入ApacheDoris，以ApacheDoris为核心构建了新的数仓架构，构建过程中对服务稳定性、查询稳定性、数据同步等多方面进行了优化，同时建立了以ApacheDoris为核心的数据中台，在这一过程中积累了诸多使用及优化经验，在此分享给大家。
作者｜橙联大数据研发经理付帅#业务背景橙联股份是一家服务全球跨境电商的科技公司，致力于通过市场分析、系统研发及资源整合，为客户提供物流、金融、大数据等多方面的服务产品，为全球跨境电商提供高品质、全方位的服务解决方案。随着公司业务的发展和数据的不断增长，早期基于MySQL的传统数仓架构已经无法应对公司数据的快速增长。业务的需求和运营的决策对于数据时效性的要求越来越高，对数仓准实时能力的需求越发强烈。为了适应快速的增长需求，橙联于年正式引入ApacheDoris，以ApacheDoris为核心构建了新的数仓架构，构建过程中对服务稳定性、查询稳定性、数据同步等多方面进行了优化，同时建立了以ApacheDoris为核心的数据中台，在这一过程中积累了诸多使用及优化经验，在此分享给大家。
#数据架构演进
早期数仓架构公司在成?初期业务量不?，数据团队规模?较?，对数据的需求仅局限于少量T+1定制化报表需求。因此，早期数仓架构十分简单，如下图所示，直接使用MySQL构建数仓集市层，使用数仓集市层的数据进行报表开发，基于商业化的报表平台向需求方提供T+1的数据报表服务。存在的问题随着公司业务规模扩大、数据量激增以及对数据时效性要求不断提高，使?MySQL进?数据分析越来越不能满?业务?的要求。没有对数仓进?分层划域，烟囱式的开发模式数据复?性很差，开发成本?，业务?提出的需求不能快速得到响应。对数据的质量和元数据的管理缺乏管控。新数仓架构为了解决旧架构日益凸显的问题，适应快速增长的数据和业务需求，今年正式引入ApacheDoris构建新的数仓架构。选择ApacheDoris的原因：易?性-在当前应用场景下，引入新技术，将面临大量报表迁移问题，因此必须要考虑的产品易用性问题，而ApacheDoris在学习成本、报表迁移成本、服务运维成本上有着非常优秀的表现，具体包括：采?MySQL协议和语法，?持标准SQL，可以通过各类客户端?具来访问Doris，能够与BI?具?缝对接?持多表Join，针对不同场景的Join提供了多种优化?案?态扩展完善，离线数据的?效批量导?、流式数据的低延迟实时导?都有很好的?持相较于业界其他热?OLAP数据库，ApacheDoris的分布式架构?常简洁，只有FE、BE两个进程，运?不依赖任何第三?系统?持弹性伸缩，对于部署、运维?常友好。
性能-当前报表存在大量降耦聚合操作，对多表关联的查询性能和实时查询的时效性有着十分高的要求，而ApacheDoris基于MPP架构实现，并自带了?效的列式存储引擎，可以支持：数据的预聚合以及预聚合结果的?动更新数据的实时更新?并发查询基于以上的原因，最终选择了以ApacheDoris为核心构建新的数仓。架构介绍
ApacheDoris的数仓架构十分简洁，不依赖Hadoop生态组件，构建及运维成本较低。如以上架构图所示，我们的数据源共有4种，业务数据MySQL、文件系统CSV、埋点数据和第三方系统API；针对不同的需求，使用了不同的数据导入方式，文件数据导入使用DorisStreamLoad，离线数据使用DataXdoriswriter进行数据初始化，实时增量数据使用FlinkCDC+FlinkDorisConnector的方式进行数据同步；数据存储和计算层使用了Doris，在分层设计上采用ODS(OperationDataStore数据准备区，也称为贴源层)、明细层DWD、中间层DWM、服务层DWS、应用层ADS的分层思想，ODS之后的分层数据通过DolphinScheduler调度DorisSQL进行增量和全量的数据更新。最终上层数据应用使用自研的一站式数据服务平台，可以和ApacheDoris无缝对接，提供自助报表、自助取数、数据大屏、用户行为分析的数据应用服务。
基于ApacheDoris的数仓架构方案可同时支持离线和准实时应用场景，准实时的ApacheDoris数仓可以覆盖80%以上的业务场景。这套架构大大降低了研发成本，提高了开发效率。当然在架构构建过程中也遇到一些问题和挑战，我们针对问题进行了相应的优化。#ApacheDoris构建数仓优化方案
在数仓的使用过程中，主要遇到三方面问题。首先是服务稳定性问题，其次是查询速度逐渐变慢的问题，最后是Doris数据同步和DorisSQL调度问题。具体体现在以下：服务稳定性优化前
在ApacheDoris使用初期，FE和BE的部署方式如下：FE负责元数据的管理、用户请求接入、查询的解析规划，资源占用较低，因此将FE和其他大数据组件混合部署FE*。BE负责数据存储、计算、查询计划的执行，资源占用较大，因此BE进行独立部署且分配了较多的资源BE（16CG4T*1）*7。基于以上方式部署，使用初期运行的稳定性还不错，然而在使用一段时间之后，这种部署方式暴露的问题就越来越明显。
存在的问题首先，FE混合部署存在资源竞争。其他组件与FE服务竞争资源，导致FE资源不足，服务运行稳定性不好。具体问题表现在：每当机器资源使用率打满，就会导致FE节点无法连接，长时间获取不到心跳而被FE集群判定为离线。其次，BE单磁盘存在Compaction效率低的问题。初期，我们在部署BE时，每个节点只分配了1块4T的磁盘，虽然磁盘的空间并不小，但是磁盘的数量比较少，Compaction线程数只有2，Compaction效率很低，这是导致BECompactionScore不健康的原因之?。Compaction配置参数：