数据库StarRocks在信也科技的应用实践
业务背景
公司销售业务快速发展，用户对多维数据分析的实时性要求越来越高，场景也变化多样，业务的复杂性和多样性给公司研发和运维成本带来很大的挑战，与此同时开源引擎也是百花齐放，日新月异；而信也科技实时数据团队致力于研发效率最大化，选择一款合适高效的存储引擎就尤为重要，信也科技通过引入新一代性能彪悍的MPP架构数据库StarRocks来构建实时数仓平台，进行实时数据分析，提供统一的数据服务：降低业务使用复杂度，提升用户体验，实现生产效率最大化
销售数据原有平台架构
业务痛点
销售数据平台初期分四个子项目
销售APP系统，实时消费业务库Binlog数据，通过Flink实时消费清洗，计算不同维度下的销售订单和业绩等指标，按时、按天、按月等时间维度进行实时计算，数据落到MySQL/MONGODB 销售智能地图系统，为了更好的分析销售行为和跟踪销售轨迹，关注销售的订单，业绩等指标，数据经过流转和清洗完之后，除了发一份数据到MySQL之外，最后还要推送一份数据到ES中，引入ES的原因一是用到地图GEO函数，二是灵活多种维度查询 销售实时大盘，清洗完的数据（订单、业绩等）发送到消息中间件，然后落到Redis,MySQL等存储系统中供前端使用 销售消息推送系统，数据（订单、业绩）经过清洗之后，会发一份数据到ClickHouse中，最后实时推送数据，以满足不同的场景
为了快速响应业务需求，满足不同的业务场景，团队选择不同技术方案来快速满足业务需求，项目的初期很好的满足了业务需求，随着时间的推移，数据量和业务功能变的越来越复杂，同时业务口径变更和新需求的不断提出，项目的维护成本和痛点就越来越明显
同一份数据存储多份，浪费存储资源 新需求或需求变更所涉及的团队和数据存储，数据服务比较多，沟通成本和研发成本相应增加 多层级组织架构下进行计算和统计分析业绩，订单，标的等指标，这些指标在不断变化的维度和不同的计算口径下给系统带来很大的挑战，很难快速响应业务需求 多种存储引擎和多套数据服务带来巨大的运维成本和整体系统的不稳定性因素和隐患也相应增加
OLAP引擎选择
根据目前的业务痛点和业务本身对数据多维分析查询的的要求，以及能适应公司未来在线实时查询需要，我们选择一款OLAP引擎要有几点要求
低延迟的毫秒级响应,数据秒级写入 运维简单，易用性强 复杂的场景查询 明细数据查询 多表关联查询性能好 支持高并发 对地图函数有支持 要有物化视图的能力
StarRocks引擎
优势：
支持标准SQL，兼容MySQL协议以及分布式join
计算、存储分离，不依赖外部组件，方便缩扩容
支持多种聚合算子，物化视图
MPP架构，分片分桶的复合存储模型
支持大并发查询，QPS可达千、万量级，
支持宽表和多表JOIN查询，数据查询秒级/毫秒级
支持地图geo函数
运维简单，易用性强 复杂的场景查询
劣势：
缺乏单列数据更新能力
周边生态还不是很完善
ClickHouse引擎
优势：
数据压缩，多核并行处理,单表性能极佳
向量引擎，稀疏索引,适合在线查询
支持数据复制和数据完整性
支持地图geo函数
劣势：
没有完整的事务支持以及多表join不友好
对修改或删除数据的能力支持不够，MergeTree合并不完全
并发能力不高
依赖zookeeper，在集群扩大时zk会成为性能瓶颈
TiDB/TiFlash引擎
优势：
数据压缩，多核并行处理,单表性能极佳
支持标准SQL，兼容MySQL协议以及分布式join
TiFlash预处理加速OLAP分析
TiDB计算、存储分离，高可用模式，运维依赖于 自动化运维工具，易操作
支持高并发查询
劣势：
强依赖SSD，硬件成本比较高
OLAP场景下查询性能相对弱一些
不支持实时预聚合
不支持地图geo函数
早期OLAP引擎Presto，Impala（无法提供低延迟亚秒级响应）,Druid（不提供明细查询）,Kylin（无法基于明细提供毫秒级查询，更多场景是预计算，运维成本也比较高)都无法满足我们的需求，StarRocks、TiDB/TiFlash、ClickHouse这些当下性能卓越的开源引擎，对比下来我们基本上锁定了StarRocks作为我们新一代的MPP架构的OLAP引擎
销售平台现有架构
新架构优点
统一数据存储计算引擎，有助于打破数据壁垒，实现数据价值最大化
统一数据管理，减低管理复杂度，提升数据安全性
统一数据服务计算，复用已有接口，研发效率最大化
灵活多变的维度组合查询，快速响应业务需求
StarRocks介绍
1. 系统架构
架构简单，只有两种类型的进程FE和BE
这两种类型进程扩容缩容只需要一个命令，单机灵活，不影响线上正常服务
alter system add backend ‘be_host:be_heartbeat_service_port‘（扩容）
altersystem decommission backend “be_host:be_heartbeat_service_port”（缩容）
当FE（leader）节点出现故障时，存活的FE(follower)会自动选择一个新的leader节点提供服务
当BE节点出现故障时，StarRocks内部会自动负载平衡，内部数据会自动迁移，系统会继续对外提供服务
针对FE,BE启动守护进程，当发现有进程挂掉时，会自动重启新进程，与此同时会通知研发人员，做到实时监控
2. 数据模型
明细模型
表中存在主键重复的数据行,和摄入数据行一一对应,用户可以召回所摄入的全部历史数据.
明细模型一般适用保留明细的，没有修改的，查询灵活的场景，比如原始日志数据。
聚合模型
表中不存在主键重复的数据行,摄入的主键重复的数据行合并为一行,这些数据行的指标列通过聚合函数合并,用户可以召回所摄入的全部历史数据的累积结果,但无法召回全部历史数据.
聚合模型一般适用于不频繁更新，只会新增数据，比如分析网站或APP访问量的统计，访问总次数，访问总时长等
更新模型
聚合模型的特殊情形,主键满足唯一性约束,最近摄入的数据行,替换掉其他主键重复的数据行.相当于在聚合模型中,为数据表的指标列指定的聚合函数为REPLACE,REPLACE函数返回一组数据中的最新数据
更新模型一般适合于有大量更新的需求，比如订单数据实时分析，订单状态会不断的变化
3.数据导入方式
现有系统数据导入主要如下两种方式
对于离线数据，我们用自研的Data Cloud调度平台自动从MySQL抽取数据，进行清洗，数据落在HDFS/Hive中，然后通过Broker Load方式导入StarRocks中
对于实时数据，业务库数据通过Canal方式抽取到Kafka,后面通过Flink实时消费Kafka，进行数据清洗，关联等操作，然后通过Stread Load方式导入，我们定制开发了 Flink-Doris-Connector 写入到StarRocks中
4. 优势
极速多维分析
全新的向量化执行引擎，亚秒级查询延时，单节点每秒可处理多达100亿行数据。强大的MPP执行框架，支持星型模型和雪花模型，综合查询速度比其他产品快10—100倍！
秒级实时分
新型存储引擎，支持大规模数据实时写入，秒级实时性保证。新型读写并发管理模式，可同时高效处理数据读取和写入。
高并发查询
灵活的资源分配策略，每秒可支持高达1万以上的并发查询，有效支持数千用户同时进行数据分析。
灵活模型构建
基于多种数据模型皆可实现极速分析，快速响应业务变化。根据业务不同要求，可灵活选择预聚合、大宽表和星型/雪花模型，提高构建灵活性。
StarRocks运维
基于Prometheus+Grafana进行监控
Prometheus 是一个拥有多维度数据模型的、灵活的查询语句的时序数据库。它可以通过Pull 或 Push 采集被监控系统的监控项，存入自身的时序数据库中。并且通过丰富的多维数据查询语言，满足用户的不同需求。
Grafana 是一个开源的metric 分析及可视化系统。支持多种数据源，详情可参考官网文档。通过对应的查询语句，从数据源中获取展现数据。通过灵活可配置的 Dashboard，快速的将这些数据以图表的形式展示给用户。
基于日志的审计监控
SQL慢查询，响应时间长，不规范的SQL会给整个平台带来不稳定的因素，另外还有些大批数据导入可能会带来短时间的CPU、IO等压力，这些操作我们都需要监控到，避免带来不必要的麻烦，目前我们是通过FileBeat去采集FE上审计日志信息，然后插入ClickHouse，然后在Grafana上展示出来，对这些SQL进行分析和监控，以便可以更好的进行优化
未来规划
StarRocks作为新一代极速全场景MPP数据库，引入了StarRocks之后，实现了统一存储，统一服务，并且其在多种场景下表现出色，帮我们产出价值最大化。未来我们对StarRocks也进行了一定的规划
根据业务场景不同，对响应时间要求不同，搭建多套StarRocks集群，进行物理资源隔离
更多的在线实时任意多维度分析业务迁移到StarRocks,打造统一的实时数仓平台
加速Hadoop数仓体系， 提升用户极速体验，打造实时数仓和离线数仓融合和一体化建设
打通数据接入平台和数据开发平台，完善运维监控体系，保证大数据基础服务的稳定性
作者介绍
yurx， 实时数据团队资深技术专家