共计 6958 个字符，预计需要花费 18 分钟才能阅读完成。
多点 DMALL 成立于 2015 年，是一站式全渠道数字批发解决方案服务商。数字化解构重构批发产业，提供端到端的商业 SaaS 解决方案。目前，多点 DMALL 已与 120 多家连锁零售商、品牌商等达成单干，笼罩四个国家和地区 15000 家门店，模式受到宽泛验证。
多点大数据部门应用 StarRocks 逐渐代替了 Impala、Impala on Kudu、Apache Kylin 等存储引擎，实现了存储引擎的收敛，简化了实时数据处理链路，同时也能保障较高的查问并发以及较低的响应提早要求。
“作者：任伟，
多点生存大数据部门资深研发工程师”
背景介绍
多点大数据部门为外部业务研发团队、数据分析师、内部用户以及合作伙伴，提供了根底的大数据产品、平台服务，帮忙批发企业解决了从根本的数据汇总治理、对立的数据计算利用、到各种场景下对数据的多模式应用的需要，可笼罩批发企业绝大部分数据诉求。
技术层面，多点大数据部门基于 Hadoop 开源技术栈，并进行了局部二次开发后构建起了以下的一个技术架构全景图。从下到上分为基础设施层、数据源层、数据集成层、离线 / 实时计算层、集市层、剖析存储层、数据服务 / 应用层，数据开发、数据模型核心与运维管理层对各层提供反对。
基础设施层 ：包含超大带宽的专线网络；私有云、公有云、机房托管的混合云部署；
数据源层 ：包含企业 OLTP 数据库、业务数据、日志数据、三方接入数据；数据集成层：DataBus 是多点自研数据同步平台，解决企业内各业务线之间、跨企业组织之间以及跨行业的数据汇聚、交融等问题，将不同零碎的数据互相买通，实现数据自在流动；
离线计算层 ：利用 Hive / Spark 高可扩大的批处理能力承当离线数仓的 ETL 和数据模型加工；
实时计算层 ：利用 Flink / Spark Streaming 实现实时数据的 ETL（包含维度裁减，多流 Join，实时汇总）等；
离线 / 实时集市层 ：应用数仓分层模型构建 ODS（原始数据层）、DWD（数据明细层）、DWS（汇总层）、DIM（维度层）、DWT（主题层）、ADS（应用层），并依据公司业务拆分不同的数据域；
剖析存储层 ：次要依赖 Druid、ClickHouse、Impala on Kudu、Apache Kylin、Elasticsearch、HBase、MySQL、StarRocks 提供 OLAP 查问能力；
数据服务 / 应用层 ：该层通过提供 BI 剖析产品、数据服务接口、营销、报表类产品，向外部经营人员、内部客户、合作伙伴提供数据分析决策能力。
原有架构痛点
上述架构解决了多点绝大部分数据诉求，在整个架构中，无论是基于 Hive、Spark 的离线计算，基于 Flink、Spark Streaming 的实时计算；基于 HDFS、Kafka 的存储；基于数仓分层模型建设等计划都已根本成熟。然而在 OLAP 畛域，无论是多点还是业界依然处于百家争鸣，各有千秋的状态。纵观多点在 OLAP 引擎的摸索实际中，遇到了各种各样的问题，总结起来如下：
技术老本
因为下层业务场景简单，各个场景的技术难点、外围点均不一样。多点生存在整个技术架构降级的过程中先后引入了 HBase、Elasticsearch、Druid、ClickHouse、Impala on Kudu、Apache Kylin 等 OLAP 引擎。然而随着技术栈增多，技术曲线平缓，没有短缺的资源进行多技术栈的保护，造成了比拟高的技术老本。
开发成本
多点的数据分析场景大抵能够分为 离线 T+1 更新剖析场景、实时更新剖析场景、固定维度剖析场景。
- 离线 T+1 更新的剖析场景
例如多点的精细化用户经营平台，其外围的性能是基于用户、生产、行为、设施等属性，提供多维度筛选条件，并通过自定义条件实现用户分层，便于进行精细化用户经营。
针对数据更新为 T+1 的剖析场景，原次要应用的剖析引擎为 ClickHouse。利用 ClickHouse 构建“大宽表”模型，将事实表与维度表提前进行关联，对外提供单表聚合的 SQL 查问，以及通过构建 DWT 主题宽表，提供 Adhoc 查问；该场景面临的问题是：尽管 ClickHouse 单表查问强悍，然而 Join 能力不强，须要提前进行关联，将多表关联成单表，会存在额定的开发成本。
- 实时更新剖析场景
实时更新场景次要是实时监控经营的各项指标，如以后时间段内的 GMV、下单数量、妥投数量、指标达成、比照、环比等指标。为客户的经营决策提供更具备时效性的参考根据。
针对数据为实时（秒级）更新的场景，原次要应用 Impala on Kudu 引擎，采纳 Lambda 架构，基于雷同的主键，将流式的预计算的后果数据、批计算的后果数据，基于雷同的主键进行 merge。
上述计划中的 Flink AGG 局部，该程序的性能包含窗口内的预计算、多流 Join 等操作。当业务需要变更或者上游数据结构变动的时候，须要降级 Flink AGG 程序，以及离线 ETL 的工作，相似于“烟囱式”的迭代开发，开发效率低下。资源耗费层面，在 Flink 外面做预计算，工夫窗口的选取以及内存占用之间也须要均衡。
- 固定维度剖析场景
固定维度的剖析场景次要针对固化的、规范的业务场景进行剖析，多维分析能够对以多维模式组织起来的数据进行上卷、下钻、切片、切块、旋转等各种剖析操作，以便分析数据，使剖析者、决策者能从多个角度、多个侧面察看数据仓库中的数据，从而深刻理解蕴含在数据中的信息和外延。
针对剖析维度固定的剖析场景，依照业务上罕用的剖析指标以及维度，此前应用 Apache Kylin 进行 cube 预计算。然而应用 Apache Kylin 也会遇到如下问题：
- 因为多点业务场景波及的维度比拟多，各种类目、营运组织的组合，会导致 cube 收缩，占用比拟多的存储资源；
- 当数据重跑以及新增维度，指标的时候。针对曾经在线上运行的 cube 模型，为了保障数据重跑时候服务仍然可用，须要新增 cube 模型，并行提供反对，造成存储反复；
- 因为目前应用的 Apache Kylin v3.1.2 是应用 HBase 作为后端存储，row key 程序设计以及分区键的抉择会重大的影响查问性能，对开发不敌对。
运维老本
多点作为一站式全渠道数字批发解决方案服务商，能够满足客户不同的接入部署需要。多点大数据产品零碎的接入能够大抵分为 SaaS 化接入、公有云以及本地化部署。针对公有云、本地化部署的客户，OLAP 引擎易部署、易保护、极简的架构尤其重要，像 HBase、Impala on Kudu、Apache Kylin 等强依赖 Hadoop 生态的 OLAP 引擎，会减少部署的复杂性；ClickHouse 集群不能主动感知集群拓扑变动，也不能主动 balance 数据，会减少缩容、扩容等的保护老本。
抉择 StarRocks 的起因
多点大数据部门从 2021 年年初开始，在调研市面上罕用的存储引擎时发现了 StarRocks。StarRocks 架构设计交融了 MPP 数据库，以及分布式系统的设计思维，具备架构精简，反对全面向量化引擎、智能查问优化、高效更新、智能物化视图、规范 SQL、流批一体、高可用易扩大等个性，人造的解决了上述的问题。
应用 StarRocks 的个性解决以后痛点
- 引擎收敛
原有零碎的多维分析，高并发查问，预计算，实时剖析，Adhoc 查问等场景下应用了多套零碎，基本上能够应用一套 StarRocks 解决。多点大数据平台、产品逐步形成以 StarRocks 为主，其余 OLAP 引擎为辅的存储架构，解决保护多套引擎的技术老本问题。
- 应用星型、星座模型代替“大宽表”模型
StarRocks 反对 Broadcast Join、Colocate Join 等分布式 Join 的个性，能够在查问性能可承受的范畴内，应用星型、星座模型代替“大宽表”模型，节约提前关联的开发成本，同时针对事实表中历史数据变更，须要从新“跑数”的场景，能够只重跑（OverWrite）局部表的数据，进步整体的“跑数”效率。
- 简化 Lambda 架构中的预聚合局部
StarRocks 反对明细、聚合、更新模型，能够基于 StarRocks 自带预聚合的个性，优化掉现有 Lambda 架构的中的预聚合局部。StarRocks 间接拉取 / 订阅 Hive 或者 Kafka 中的数据，在 StarRocks 中进行聚合运算；StarRocks 的数据模型是 Aggregate 模型，通过 MAX、SUM、MIN、BITMAP_UNION 等聚合函数在 StarRocks 中进行预聚合。
- 模型继续迭代
针对已在线上运行的模型，如果有需要上的变更，比方减少、删除、变更字段，能够应用 StarRocks 简略 SQL 命令动静地批改表的定义，在表构造变更的过程中，线上的服务不受任何的影响。
- 明细、汇总一体化
在理论的业务场景中，通常存在两种场景并存的剖析需要：对固定维度的聚合剖析 和对原始明细数据的查问。在这种状况下，StarRocks 反对对原表构建物化视图，数据更新的时候，物化视图追随原表一起进行更新，保证数据的一致性。当用户查问时，并不感知物化视图的存在，不用显式的指定物化视图的名称，查问优化器能够依据查问条件主动判断是否能够路由到相应的物化视图上。
- 表面能力
StarRocks 反对以内部表的模式，接入其余数据源包含 MySQL、HDFS、Elasticsearch、Hive 等。比方能够应用 StarRocks 建设 Elasticsearch 的表面，为 Elasticsearch 提供 SQL 查问的能力。
基于多点报表业务实在场景的性能测试
- 单表聚合查问
在现有的数据 T+1 更新的汇总业务场景中，选取了多点报表业务中的“单品销售剖析”场景进行测试，单表单天数据亿级别，上百个维度和剖析指标，属于典型的基于“大宽表”的 Adhoc 查问场景。在雷同状况（机器配置、数据量、SQL）下进行 ClickHouse 比照 StarRocks 的性能测试：
横坐标：分区（天）数 - 并发数；纵坐标：响应时长（ms）
从查问响应时长来看，单表的聚合查问，ClickHouse 与 StarRocks 的查问响应时长相差不多。
- 多表关联查问
在现有的数据 T+1 更新多表关联的汇总剖析业务场景中，选取了当初多点报表业务中的“门店销售剖析”场景进行测试，事实表单天数据亿级别，多个维表数据量在十万级别，属于典型的高维剖析场景。在雷同状况（机器配置、数据量、SQL）下进行 ClickHouse 比照 StarRocks 的性能测试：
横坐标：分区（天）数 - 并发数；纵坐标：响应时长（ms）
从查问响应时长来看，多表关联聚合查问，StarRocks 的性能要优于 ClickHouse。
- 实时更新读写查问
在现有的数据准实时更新（边写边读）的汇总查问业务场景中，选取了“实时销售剖析”场景进行测试，订单数据实时更新，单天数据量亿级别。属于典型的“实时更新，实时查问”场景。在雷同状况（机器配置、数据量、SQL）下进行 Impala on Kudu 比照 StarRocks 的性能测试：
横坐标：分区（天）数 - 并发数；纵坐标：响应时长（ms）。
从查问响应时长来看，在边读边写的状况下，聚合查问的 SQL，StarRocks 的性能要优于 Impala on Kudu。
实践经验
多点目前曾经在高维业务指标报表、Adhoc 剖析、实时全链路监控等场景中引入了 StarRocks，在应用中总结出以下教训：
集群拆分
因为 StarRocks 极简的架构设计，易于运维部署。咱们依据肯定的规定，搭建了多套集群，防止业务之间的相互影响。
依照数据更新频率进行拆分
例如数据是 T+1 更新，且单表数据量在百亿级别以上的场景（例如高维业务指标报表、Adhoc 剖析），咱们构建了离线剖析集群。通过进步 StarRocks 的查问并发（parallel_fragment_exec_instance_num）、单节点内存限度（exec_mem_limit）等对简单查问敌对的参数，进步集群的查问性能；针对数据是准实时更新，写多读多的场景（实时报表、实时全链路监控），咱们构建了实时剖析集群，通过 调整 StarRocks 的 compaction（cumulative_compaction_num_threads_per_disk、base_compaction_num_threads_per_disk）等对写入敌对的参数，放慢数据版本合并。
依照业务域进行拆分
多点客户的接入形式不同，且各种 SLA 要求也不同，会依照不同的需要搭建不同的 StarRocks 集群，尽量满足多种客户需要。
调优伎俩
针对在线服务、零碎，为了进步零碎整体的查问性能，能够从不同的维度进行优化：
- 优化表构造定义
1、模型抉择
StarRocks 的模型包含明细模型、聚合模型、更新模型。如果须要对原始的数据（例如订单流水，原始操作记录等）来进行剖析，能够抉择明细模型；如果业务方进行的查问为汇总类查问，比方 SUM、COUNT、MAX 等类型的查问，能够抉择聚合模型，提前进行预聚合，查问的时候间接获取后果；如果数据须要频繁的进行状态更新（比方订单的状态变更），能够抉择更新模型。
2、分区 (parition) 和分桶 (bucket)
StarRocks 能够对表进行分区和分桶，分区在逻辑上把表划分成了多个子表，能够依照工夫进行分区；分桶能够依照不同的策略将数据划分为不同的 tablet，散布在不同的 BE 节点上。依照目前多点大数据集群的机器配置（64C+256G+12TB SSD），通常将一个 tablet 放弃在 200MB~1GB 的大小，会有比拟好的性能。
3、稠密索引、bloomfilter、Bitmap Index
为了进步查问的性能，能够对 StarRocks 的表构造额定构建索引。稠密索引：能够将查问中常见的过滤字段放在 schema 的后面, 区分度越大，频次越高的查问字段越往前放；同时对区分度比拟大的列构建 bloomfilter；对区分度不大的列构建 Bitmap Index。
4、物化视图
针对实际查问场景中常常用到的查问 SQL，能够对原始表构建物化视图，其本质为原始表 (base table) 的一个物化索引，通过物化视图提前进行索引排序、指标预计算，查问的时候主动路由到物化视图进行查问。
**
5、应用 BITMAP / HyperLogLog 数据类型进行去重 **
在交易场景中进行会计算交易次数，应用惯例的形式（COUNT DISTRINCT order_id）去重，其毛病是须要耗费极大的计算和存储资源，对大规模数据集和查问提早敏感的去重场景反对不够敌对。通过定义 BITMAP 的数据类型，能够缩小传统 COUNT DISTINCT 去重的执行须要的内存空间、执行时长；而对于像流量统计场景中针对 UV 的计算，在容许有局部统计偏差的前提下，能够定义 HyperLogLog 的数据类型，进步去重效率。
- 优化查问 SQL
1、小表 Join 能够对应用 Broadcast Join
当大表与小表进行 Join 的时候，能够应用 Broadcast Join（StarRocks 针对小表的默认 Join 形式），小表向大表播送的形式进行 Join。该形式能够用于事实表与维度表进行关联查问；
2、大表 Join 能够应用 Colocation Join
当大表与大表进行 Join 的时候，为了减速查问，相干表能够采纳独特的分桶列（colocate_with）进行分桶。当分桶列雷同，相干表进行 Join 操作时，能够间接在本地进行 Join，再将后果数据进行合并，防止数据在两头计算的时候就在集群中的传输。
3、并行度调整
当机器资源比拟富余时，能够将减少执行并行度（parallel_fragment_exec_instance_num），让更多的执行实例同时解决一组数据扫描，从而晋升查问效率。然而并行度设置为较大的数值会耗费更多的机器资源，如 CPU、内存、磁盘 IO，影响整体的 QPS。须要依据实际上的查问场景来设置并行度，个别倡议占用机器核数的 50%。
4、CBO 优化器
针对简单 Ad-hoc 场景，能够开启 StarRocks 的基于老本（Cost-based Optimizer，CBO）的查问布局器，在泛滥查问打算空间中疾速找到最优打算，进步查问优化器。
工具集成
为了与目前多点的大数据平台进行买通，对 StartRocks 进行了一些集成封装。
- 数据集成
通过封装 StarRocks 的 Broker Load 以及 Stream Load 接口，与多点的大数据平台买通，实现通过配置的形式将数据从 Hive 批量同步到 StarRocks，或者订阅 MQ 将实时数据同步到 StarRocks。
- 监控预警
通过集成 Prometheus 与 Grafana，与监控平台买通。对多个 StarRocks 集群的运行状况进行监控，当集群的某些指标超过肯定阈值的时候进行报警。
总结与瞻望
多点从 2021 年上半年开始调研引入 StarRocks，以后已有四个集群在稳固运行提供线上服务，逐渐代替了 Impala、Impala on Kudu、Apache Kylin 等存储引擎，实现了存储引擎的收敛，简化了实时数据处理链路，同时也能保障较高的查问并发以及较低的响应提早要求。目前公司也在越来越多的业务中尝试应用 StarRocks。
在引擎引入以及切换的过程中，失去了 StarRocks 社区的大力支持。后续公司在有余力的状况下会参加 StarRocks 的社区共建，独特打造性能强悍的国产新一代 MPP 数据库。
