共计 3245 个字符，预计需要花费 9 分钟才能阅读完成。
作者：大润发大数据团队
自 1998 年在上海开设第一家大型超市以来，大润发已在中国大陆地区胜利开设近 500 家综合性大型超市，覆盖全国 29 个省市及自治区达 230 多个城市，年销售额过千亿。大润发优鲜、淘鲜达、饿了么、天猫超市线上平台用户达到 6900 万。沉闷用户超过 1650 万，一线城市均匀每店日均线上订单量冲破 2000 单。
作为国内大型连锁量贩超市的先导者，大润发在物流仓储、商品治理等畛域很早就引入了大数据技术进行智能决策分析，帮忙优化治理精度、进步管理水平。大数据平台也追随技术浪潮屡次迭代降级，积淀出一整套特有的数据子系统和大数据处理计划。
大润发大数据业务起步较早、数据累积和历史组件较多，同时为了保障技术的前沿性，因而逐渐倒退出了多剖析引擎的架构。一方面能够依据各类型引擎的特点解决适合的在线数据产品，一方面也能够依据各类引擎的技术劣势及应用成果调整应用场景调节使用权重。然而，随着业务需要的多样化、复杂化以及数据系统的革新降级，本来一些下放门店库的查问需要对立收归中心化的数据中台解决，导致高 并发 且简单的查问场景呈现频次激增。面对此种场景，无论是能力还是效率，现有的剖析引擎都显得力不从心，简单查问性能呈现显著有余。因而咱们亟需一款可能适应高并发低延时的查问引擎作为咱们大数据框架 OLAP 剖析平台的全新能源。
OLAP 组件选型
选型要求
对于新的 OLAP 引擎咱们的需要有如下几点期待：
社区沉闷的开源框架，运维老本不会太高；
可能反对多类型 Join，大表 Join 性能要优良；
要反对高并发解决查问，且查问提早低，这也是咱们最外围的诉求；
要可能反对大规模数据的导入导出，且能与现有数据平台互相兼容；数据模型灵便，应用场景全面；
反对预计算技术。
选型比照
咱们针对时下风行的组件进行了后期调研，StarRocks 以其杰出的性能、良好的兼容、极简的部署吸引了咱们的留神。StarRocks 与大润发数据平台框架现有组件的特点及利用场景比照如下：
组件测试
为了验证 StarRocks 理论使用性能是否可能达到预期，咱们采纳了学术界和工业界宽泛应用的星型模型测试集 Star Schema Benchmark（简称 SSB 测试集），在本地测试集群（3 FE +3BE 架构）上进行了单表查问的系列测试。单表查问的测试后果如下：
系列测试论断如下：在 SSB 测试集的 13 个查问中，StarRocks 的整体查问性能是 ClickHouse 的 2 倍多；在 SSB 测试集的 12 个低基数查问中，StarRocks 的整体查问性能为 ClickHouse 的 1.1 倍。
组件部署
从测试后果来看，StarRocks 的性能十分优良，组件架构也十分精简。通过简略的部署革新，StarRocks 加强了咱们 OLAP 剖析引擎高 并发 场景下的解决能力。
实际案例
离线利用
1、建模
大润发的外围业务依靠于各大中小门店的进、销、存经营数据，该局部数据以业务流程型单据明细为主。通常的逻辑是，业务中台零碎的门店明细数据通过自研采集零碎同步到数据中台中，通过 ETL 荡涤、转换、聚合解决，输入到 BI 报表进行后果展示。在利用内部 OLAP 剖析引擎的场景中，咱们会把业务维表和局部剖析逻辑放到 引擎库中。引入 StarRocks 革新后，咱们也进行了初步摸索，针对 StarRocks 的四种模型规定了应用场景，并特地对明细模型的建模细化了两种利用形式：一种是不必分区的维度表，一种是须要按同步工夫分区的明细表。
建表还须要留神一些分辨别桶问题，官网倡议单个分桶的大小在 1-10G，此时查问性能较好。所以如果源表数据量过大或过小，能够适当调整分区或分桶数，以达到最佳的性能状态。
2、同步
得益于 StarRocks 兼容 MySQL 协定，可能与咱们现有的数据平台整合，进行简略的配置就能够进行数据的同步和开发。不同于以往的 Hive 或者 MySQL 数据库，StarRocks 通过动静分区导入数据的前提是分区必须已被创立，而其自身无奈依据分区字段实时动态创建分区。这里有两种办法解决：能够依据建表语句 properties 配置中的参数开启动静分区性能，让 StarRocks 调用底层常驻线程预创立分区；能够敞开 StarRocks 的动静分区，通过数据平台执行预约义 SQL 语句进行分区创立操作。在刷数的时候，对于特定历史分区的刷数操作，能够应用 StarRocks 的长期分区性能实现无感刷数。
3、查问
咱们所应用的 BI 报表工具，对 前端 报表查问控件的操作都会在底层转化成预约义的 SQL 向 StarRocks 查问，返回后果再进行 Web 渲染。因为采纳的是主动生成的 SQL 语句，须要留神在 SQL 生成的过程中，是否对表的索引字段主动增加了转换函数，从而导致索引生效的状况。4、性能成果报表上线后，咱们对理论的查问成果也做了继续的察看和剖析。包含简单查问在内，总体 99% 查问延时在 150ms 左右，QPS 9000+ 的高并发场景下仍能较为稳固执行，达到了导入的预期成果。
实时摸索 1、兼容测试实时团队也测试了 Flink+StarRocks 的兼容性，凭借官网的 Flink-connector-starrocks 依赖，能够很好实现实时需要的革新。不过须要留神的是：1.11 版本的依赖没有 Source 读取办法，仍需应用 JDBC 读取。1.13 当前版本的依赖有 Source 和 Sink 办法，这两个办法的底层理论是转为 Stream Load 办法进行写入写出，比照 JDBC 的单 FE，能够实现多 FE 数据传输，性能更强。所以如果有实时的利用场景，举荐 Flink 1.13+ 版本配合对应的依赖获得更好的应用体验。2、其余构想咱们曾尝试应用 Kafka+RoutineLoad 的形式将数据导入 StarRocks，冀望联合 StarRocks 自身的物化视图预计算实现实时 Join，从而间接代替 Spark/Flink 这类业余的实时引擎。遗憾的是，咱们 基于 2.1.6 版本的物化视图性能比拟根底，尚无奈实现更为简单的表间关联操作，而 StarRocks 2.4 版本已开始反对并逐步完善多表物化视图性能。
实际总结
长处
性能卓越：StarRocks 的单表性能不输 ClickHouse，多表 Join 的延时比照咱们现有的的组件又有着较大劣势，即使不做特定的优化，也能有较好体现，这是非常难得的。运维简略：StarRocks 舍弃了传统多组件的架构模式，FE +BE 的构造非常精简，部署较为便捷。而运行上的稳固牢靠，使得对运维的资源耗费非常低。插件丰盛：开发者保护了一些较为实用的插件和工具，能够进行一键部署、日志结构化等。如果这些性能前期可能稳固嵌入 StarRocks 后续 版本 中，应该能够更好优化应用体验。社区沉闷：开源社区有长期稳定版和疾速迭代版能够自由选择，版本升级操作也较为容易。同时有中文社区论坛和官网群能够随时进行问题反馈取得答疑，这一点是要胜过很多竞品的。
有余
这里基于 2.1.6 版本提出两点应用中的困扰：权限治理有余：StarRocks 的用户角色性能有待改善，例如该版本只能在创立用户时授予角色，不能授予用户多角色，删除角色后用户权限仍然保留。庆幸的是，在不久后的 3.0 版本中，StarRocks 将实现残缺的 RBAC，并丰盛更多权限我的项目，从而解决这一问题。预计算性能泛用性不强：物化视图作为预计算的特色性能，使用场景较为根底，条条框框局限过多，比方不能实现多列聚合运算，不能实现多表 Join 等，应用起来难以做到如臂使指的成果。StarRocks 2.4 版本的异步物化视图性能曾经在逐渐解决这一困扰。
咱们通过实际发现，StarRocks 可能很好地解决大润发数据分析中的一些痛点问题，可能解决问题的工具就是好工具。StarRocks 以其优异的个性，失去大润发数据团队的统一好评。而其开发团队从善如流的服务态度，高效迭代的技术致力，无不彰显着他们在这片市场耕耘的勃勃雄心，置信 StarRocks 在不远的将来，可能结出他们所期待的光明。
