“作者：韩文博联想销售物流大数据平台负责人，专注于数仓建设、数据分析等领域研究。”
一、OLAP引擎在Lenovo联晟智达的演进史
第一阶段
在2018年之前，联晟智达的数据总量还不是特别大，这个阶段使用的是传统关系型数据库(SQL Server)，数据仓库体系还尚未建立，很多数据需求的实现都是以SQL脚本的开发方式来满足。
但随着业务复杂度不断提升，以及数据量的快速增长，这种模式很快遇到了瓶颈。最主要体现在查询响应时效变得越来越慢。例如：之前运行一个任务需要10分钟或20分钟，现在需要一个小时或更长时间，查询效率严重下降。另外数据存储容量也存在瓶颈，无法满足随业务而快速增长的数据量存储需求。
第二阶段
2019年随着数据仓库在Hadoop/Hive体系上搭建和完善，ETL任务全部转移至Hadoop集群，这个阶段使用数十台Presto完成OLAP分析。Presto天然和Hive共享元数据信息，且共同使用物理数据存储，大量的对数仓表的灵活查询使用Presto完成。前端BI层面使用Tableau直接连接Presto，实现数据分析与挖掘。
第三阶段
2021年联晟大数据团队进行了离线数仓的整体设计和搭建，既需要做低延时的BI报表，又要满足Adhoc复杂查询，同时对高效明细查询也有很高的要求。这个阶段我们根据场景引入了OLAP圈炙手可热的DorisDB产品，它既能做Presto的Adhoc多表关联查询及复杂嵌套子查询，又能提供比ClickHouse更好的单表明细查询和多维物化视图上卷加速，满足极速BI分析需求。
二、数据分析体系架构
1.OLAP体系现状
整个数据分析体系，由数据采集、数据存储与计算、数据查询与分析和数据应用组成。
原始架构图：
数据采集
1)通过Sqoop读取RDBMS导入Hive。
2)用Flume来同步日志文件到Hive。
3)通过爬虫技术将网上数据爬取下来，存储到RDBMS，再由Sqoop读取RDBMS，导入到Hive。
数据存储与计算
离线数据处理：利用Hive高可扩展的批处理能力承担所有的离线数仓的ETL和数据模型加工的工作。
数据查询与分析
数据共享层主要提供对外服务的底层数据存储和查询共享界面。离线ETL后的数据写入RDBMS或MPP数据库中，面向下游多种服务，为Tableau BI、多维固定报表、Adhoc即席查询等不同场景提供OLAP查询分析能力。应用侧完美服务于BI报表平台、即席查询分析平台及数据可视化平台(Control Tower)
数据应用层
数据应用层主要为面向管理和运营人员的报表，查询要求低时延响应，需求也是迭代层出不穷。面向数据分析师的即席查询，更是要求OLAP引擎能支持复杂SQL处理、从海量数据中快速遴选数据的能力。
三、各OLAP分析工具选型比较
1.ClickHouse
优点
1)很强的单表查询性能，适合基于大宽表的OLAP多维分析查询。
2)包含丰富的MergeTree Family，支持预聚合。
3)非常适合大规模日志明细数据写入分析。
缺点
1)不支持真正的删除与更新。
2)Join方式不是很友好。
3)并发能力比较低。
4)MergeTree合并不完全。
2.DorisDB
优点
1)单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。
2)支持高并发查询。
3)支持实时数据微批ETL处理。
4)流式和批量数据写入都能都比较强。
5)兼容MySQL协议和标准SQL。
缺点
1)大规模ETL能力不足。
2)资源隔离还不完善。
四、DorisDB在SEC数据中心的应用实践
渠道仓配管理(SEC)的核心数据来自两大块：一个是消费业务;第二个是SMB中小企业务(Think、扬天)。基于这些数据，根据不同的业务场景需求，汇总出相关业务统计指标，对外提供查询分析服务。
1.原有解决方案
在引入DorisDB之前，用到大量Hive任务进行业务逻辑清洗加工，清洗加工后的数据部分保留在Hive，部分数据写入MySQL/SQL Server，以达到数据的落地。前端BI通过Presto计算引擎连接Hive、MysSQL、SQL Server等，实现报表分析及数据可视化。
2.技术痛点
原有架构主要有以下两个问题：
1)数据逻辑没有很好做归拢合并，维护工作量大，新需求无法快速响应。
2)Presto的在SQL较多的Tableau复杂报表上响应较慢，不能满足业务即时看数需求。
因此我们希望对原有体系进行优化，核心思路是利用一个OLAP引擎进行这一层的统一，对OLAP引擎的要求是比较高的：
1)能支撑大吞吐量的数据写入要求。
2)可以支持多维度组合的灵活查询，响应时效在100ms以下。
3)比较好的支持多表关联。
4)单表查询数据量在10亿以上，响应时效在100ms以下。
经过大量调研，DorisDB比较契合数据中心的整体要求。DorisDB本身高效的查询能力，可以为数据中心数据报告提供一体化服务。新架构具备以下优点：
1)结构清晰，RDBMS专注于数据的清洗，业务逻辑计算从Hive迁到DorisDB内实现，DorisDB就是数据业务逻辑的终点。
2)可以维护统一的数据口径，一份数据输入，多个APP接口输出。
3)MPP分布式架构，得以更好的支持分布式聚合和关联查询。
4)和Tableau有较好的兼容性，可以满足核心BI分析需求。
3.基于DorisDB的解决方案
升级后架构图：
数据表设计
1)数据模型设计
DorisDB本身提供三种数据模型：明细模型/聚合模型/更新模型。对SEC业务来说，目前以明细模型为主，后续如果有其他场景，再考虑应用其他模型。
2)数据分区/分桶
DorisDB提供的数据分区和分桶功能，可以很好的提升历史库存及周转场景下明细查询的性能。例如，历史库存查询常见的一种查询场景，是查询过去某一时间段内的库存周转情况，我们可以在DorisDB中根据出库时间进行分区，过滤掉不必要的分区数据，减少整个查询的数据量进行快速定位，尽量减少了查询语句所覆盖的数据范围，分区、分桶、前缀索引等能力，可以大大提高点查并发能力。这些特性对业务迎接增长，面对未来可能出现的高并发场景也具有非常大的意义。查询某一个物料条码(SN)的历史轨迹数据，能够快速的检索出该条码的所有历史出入库轨迹信息，帮助我们高效的完成供应链全生命周期回溯。
物化视图
我们利用DorisDB物化视图能够实时、按需构建，灵活增加删除以及透明化使用的特性，建立了基于库存物料SN粒度、基于产品类型特征粒度、基于库房粒度、基于分销商粒度的物化视图。基于这些物化视图，可以极大加速查询。
数据导入
数据导入DorisDB这里用到了两种方案：
1)在DorisDB提供的Broker Load基础上将离线数仓Hive的表导入到DorisDB中。
2)通过DataX工具，将SQL Server、MySQL上的数据导入到DorisDB。
4.DorisDB使用效果
灵活建模提升开发效率
结合使用宽表模型和星型模型，宽表和物化视图可以保证报表性能和并发能力，而星型模型可以让AP如TP里那样建模，直接进行关联查询，不必所有场景都依赖宽表准备，在数据一致性和开发效率上得到很好提升。另外，有不少表是在MySQL里的，我们通过DorisDB外表的方式暴露查询，省去了数据导入的过程，大大降低了业务方的开发和迁移周期。DorisDB的分布式Join能力非常强，结合View的能力构建统一的视图层，面下不同BI报表进行查询，提升了指标口径的一致性，降低了重复开发。
BI体验极好
前期部分BI可视化是基于SQL Server、MySQL构建的。部分看板不断优化和丰富需求后，加上多维度灵活条件筛选，每次加载很慢，有些Tableau报表很长时间才能加载出来，业务无法接受。引入DorisDB之后，我们用DataX将SQL Server数据导入DorisDB，这里使用了DorisDB-Writer插件，底层封装的Stream-Load接口，向量化导入效率非常高。MySQL可以通过外表insert into select流式导入，也可以直接外表查询，非常便捷。Tableau图表秒出，体验有了质的飞跃。
运维成本较低
数据中心是非常核心的一个线上服务，因此对高可用及灵活扩容能力有非常高的要求。DorisDB支持数据多副本，FE、BE仅仅2种角色组成的简洁架构，在单个节点故障的时候可以保证整个集群的高可用。另外，DorisDB在大数据规模下可以进行在线弹性扩展，在扩容时无Down Time，不会影响到在线业务，这个能力也是我们非常需要的。
总结
Lenovo联晟智达从今年(2021年)4月份开始调研DorisDB，POC测试阶段用了1/4的资源，就完美替代了数十个节点的Presto集群，当前DorisDB已经上线稳定运行。引入DorisDB后，实现了数据服务统一化，大大简化了离线数据处理链路，同时也能保障查询时延要求，之后将用来提升更多业务场景的数据服务和查询能力。最后，感谢鼎石科技的大力支持，也期望DorisDB作为性能强悍的新一代MPP数据库引领者越来越好!
