关于开发工具:得物基于-StarRocks-的-OLAP-需求实践

新一代极速全场景 MPP 数据库，能够用 StarRocks 来反对多种数据分析场景的极速剖析；
架构简洁，采纳了全面向量化引擎，并装备全新设计的 CBO 优化器，查问速度（尤其是多表关联查问）；
很好地反对实时数据分析，并能实现对实时更新数据的高效查问，还反对现代化物化视图，以进一步减速查问；
用户能够灵便构建包含大宽表、星型模型、雪花模型在内的各类模型；
兼容 MySQL 协定，反对规范 SQL 语法，易于对接应用，全零碎无内部依赖，高可用，易于运维治理。

外围过程：FE（Frontend）、BE（Backend）。
注：所有节点都是有状态的。

FE（Frontend）负责管理元数据，治理客户端连贯，进行查问布局、查问调度等工作。
- Follower
  - Leader：Follower 会通过类 Paxos 的 BDBJE 协定选主出一个 Leader，所有事务的提交都是由 Leader 发动，并实现；
  - Follower：进步查问并发，同时参加投票，参加选主操作。
- Observer：不参加选主操作，只会异步同步并且回放日志，次要用于扩大集群的查问并发能力。
BE（Backend）负责数据存储以及 SQL 执行等工作。

在 StarRocks 里，一张表的数据会被拆分成多个 Tablet，而每个 Tablet 都会以多正本的模式存储在 BE 节点中，如下图：

Table 数据划分 + Tablet 三正本的数据分布：

StarRocks 反对 Hash 散布、Range-Hash 的组合数据分布（举荐）。
为了等到更高的性能，强烈建议应用 Range-Hash 的组合数据分布，即先分区后分桶的形式。

Range 分区可动静增加和删减；
Hash 分桶一旦确定，不能再进行调整，只有未创立的分区能力设置新的分桶数。

分区和分桶的抉择是十分要害的。在建表时抉择好的分辨别桶列，能够无效进步集群整体性能。

以下是针对非凡利用场景下，对分区和分桶抉择的一些倡议：

数据歪斜：业务方如果确定数据有很大水平的歪斜，那么倡议采纳多列组合的形式进行数据分桶，而不是只独自采纳倾斜度大的列做分桶。
高并发：分区和分桶应该尽量笼罩查问语句所带的条件，这样能够无效缩小扫描数据，进步并发。
高吞吐：尽量把数据打散，让集群以更高的并发扫描数据，实现相应计算。

对表进行存储时，会对表进行分区和分桶两层解决，将表的数据扩散到多台机器进行存储和治理。

分区机制：高效过滤，晋升查问性能。
- 分区相似分表，是对一个表依照分区键进行宰割，能够依照工夫分区，依据数据量依照天 / 月 / 年划分等等。能够利用分区裁剪对多数访问量，也能够依据数据的冷热水平把数据分到不同介质上。
分桶机制：充分发挥集群性能，防止热点问题。
- 应用分桶键 Hash 当前，把数据平均的散布到所有的 BE 上，不要呈现 bucket 数据歪斜的状况，分桶键的抉择准则就是高基数的列或者多个列组合成为一个高基数的列，尽量将数据充沛打散。
- 注：Bucket 数量的须要适中，如果心愿充分发挥性能能够设置为：BE 数量 * CPU core/2，最好 tablet 管制在 1GB 左右，tablet 太少并行度可能不够，太多可能远数据过多，底层 scan 并发太多性能降落。
Tablet：最小的数据逻辑单元，能够灵便设置并行计算资源。
- 一张表被切分成了多个 Tablet，StarRocks 在执行 SQL 语句时，能够对所有 Tablet 实现并发解决，从而充沛的利用多机、多核提供的计算能力。
- 表在创立的时候能够指定正本数，多正本够保证数据存储的高牢靠，以及服务的高可用。
Rowset：每一次的数据变更就会产生一个 Rowset。
- 就是以组列存形式组织的的一些文件，每次的 commit 都会产生一个新的版本，每个版本蕴含哪些 Rowset。
- 每次写入都会减少一个版本（无论是单条、还是 stream load 几个 G 的文件）。
Segment：如果一个 Rowset 数据量比拟大，则拆分成多个 Segment 数据断落盘。

指标工厂服务次要面向业务人员，通过对业务指标的采集和解决，实时反映产品状态，为经营提供数据撑持、检测产品破绽或服务异样、提供指标异样告警性能等。

业务场景剖析

业务指标埋点形式多样，并不局限于某种形式，只有合乎埋点标识明确、业务参数丰盛、数据满足可解析的根本要求皆可作为数据源，大抵能够分为：SDK、MySQL BinLog、业务日志、阿里云 ODPS 数据分析。
存在的挑战，各种业务场景众口难调，演绎数据特色如下：

须要全量日志明细；
须要数据能够始终是最新的，即满足实时更新场景；
须要对数据做层级聚合的，即可能是月、周、日、小时等；
须要能够承载更大的写入量；
每个业务数据都要灵便的配置数据的保留工夫；
数据源起源多，报表定制化比拟高，有多个数据源合并成一个大宽表的场景、也有多表连贯的的需要；
各种监控图、报表展现、业务实时查问等，即较高的并非查问。

引入 StarRocks

侥幸的是 StarRocks 有比拟丰盛的数据模型，笼罩了下面的所有业务场景的需要，即：明细模型、更新模型、聚合模型、主键模型，同时抉择更为灵便的星型模型代替大宽表的形式，即间接应用多表关联来查问。

明细模型：

埋点数据通过结构化解决后按明细全量存储；
该场景对 DB 在亿级数据量下查问性能有较高的要求；
数据能够通过配置动静分区来配置过期策略；
场景应用时从结构化数据抉择个别字段维度在线聚合查问。

聚合模型：

埋点数据数据量微小，且对明细数据不要求溯源，间接做聚合计算，比方计算 PV、UV 场景；
数据能够通过配置动静分区来配置过期策略。

更新模型：

埋点数据状态会产生变动，且须要实时更新数据，更新数据范畴不会跨度多个分区的，比方：订单、优惠券状态等；
数据能够通过配置动静分区来配置过期策略。

基于以上业务场景的剖析，这三种模型能够完满解决数据的问题。

须要实时的数据写入场景，我也沿用了业内风行的解决方案，即数据采集到 Kafka 之后，应用 Flink 做实时写入到 StarRocks。StarRocks 提供了十分好用的 Flink-connector 插件。

小 tips：
1. 尽管 StarRocks 曾经很好的优化了写入性能，当写入压力大，仍会呈现写入回绝，倡议可适当增大单次导入数据量，升高频率，但同时也会导致数据落库提早减少。所以须要做好肯定的取舍，做到收益最大化。
2. Flink 的 sink 端不倡议配置过大，会引起并发事务过多的报错，倡议每个 flink 工作 source 能够配置多些，sink 的连接数不能过大。

小结

集群规模：5FE(8c32GB)、5BE(32c128GB)

目前该计划已反对数百个业务指标的接入，波及几十个大盘的指标展现和告警，数据存储 TB 级，每日净增长上百 G，总体运行稳固。

外部零碎业务看板，次要服务于全公司员工，提供我的项目及工作跟踪等性能。

业务场景剖析

剖析业务特点：

数据变更频繁(更新)，变更时间跨度长
查问时间跨度多
报表需准实时更新
关联维表查问多，部门 / 业务线 / 资源域等
冷热数据，最近数据查问频繁

历史架构与痛点

当初数据库选型时，联合业务特点，用户须要动静、灵便的增删记录本人的工作，因此抉择了 JOSN 模型缩小了利用程序代码和存储层之间的阻抗，抉择 MongoDB 作为数据存储。

随同着公司疾速快发，当须要报表展现，特地是时间跨度比拟大，波及到多部门、多维度、细粒度等报表展现时，查问工夫在 MongoDB 须要执行 10s 甚至更久。

引入 StarRocks

调研了 StarRocks、ClickHouse 两款都是十分优良的剖析型数据库，在选型时，剖析了业务利用场景，次要集中在单表聚合查问、多表关联查问、实时更新读写查问。维度表更新频繁，即存储在 MySQL 中，StarRocks 比拟好的反对表面关联查问，很大水平上升高了开发难度，最终决定选用 StarRocks 作为存储引擎。

革新阶段，将原先 MongoDB 中的一个汇合拆分成 3 张表。应用明细模型，记录每天的对应人员的工作信息，按天分区，由之前的每人每天一条记录改为，以事件为单位，每人每天能够多条记录。

实现频繁更新的维表，则抉择应用内部表，缩小维度数据同步到 StarRocks 的复杂度。

小结
革新前，MongoDB 查问，写法简单，屡次查问。

db.time_note_new.aggregate(
    [{'$unwind': '$depart'},
       {'$match': {'depart': {'$in': ['部门 id']},
           'workday': {'$gte': 1609430400, '$lt': 1646064000},
           'content.id': {'$in': ['事项 id']}, 
           'vacate_state': {'$in': [0, 1]}}
       }, 
       {'$group': { 
           '_id': '$depart', 
           'write_hour': {'$sum': '$write_hour'}, 
           'code_count': {'$sum': '$code_count'}, 
           'all_hour': {'$sum': '$all_hour'}, 
           'count_day_user': {'$sum': {'$cond': [{'$eq': ['$vacate_state', 0]}, 1, 0]}}, 
           'vacate_hour': {'$sum': {'$cond': [{'$eq': ['$vacate_state', 0]}, '$all_hour', 0]}}, 
           'vacate_write_hour': {'$sum': {'$cond': [{'$eq': ['$vacate_state', 0]}, '$write_hour', 0]}}}
           -- ... more field
       }, 
       {'$project': {
           '_id': 1, 
           'write_hour': {'$cond': [{'$eq': ['$count_day_user', 0]}, 0, {'$divide': ['$vacate_write_hour', '$count_day_user']}]}, 
           'count_day_user': 1, 
           'vacate_hour': 1, 
           'vacate_write_hour': 1, 
           'code_count': {'$cond': [{'$eq': ['$count_day_user', 0]}, 0, {'$divide': ['$code_count', '$count_day_user']}]}, 
           'all_hour': {'$cond': [{'$eq': ['$count_day_user', 0]}, 0, {'$divide': ['$vacate_hour', '$count_day_user']}]}}
           -- ... more field
       }
    ]
)

革新后，间接兼容 SQL，单次聚合。

WITH cont_time as (
    SELECT b.depart_id, a.user_id, a.workday, a.content_id, a.vacate_state
        min(a.content_second)/3600 AS content_hour,
        min(a.write_second)/3600 AS write_hour,
        min(a.all_second)/3600 AS all_hour
    FROM time_note_report AS a
    JOIN user_department AS b ON a.user_id = b.user_id
    -- 更多维表关联
    WHERE b.depart_id IN (?)  AND a.content_id IN (?) 
      AND a.workday >= '2021-01-01' AND a.workday < '2022-03-31' 
      AND a.vacate_state IN (0, 1)
    GROUP BY b.depart_id, a.user_id, a.workday, a.content_id,a.vacate_state
)
SELECT M.*, N.*
FROM ( 
    SELECT t.depart_id,
         SUM(IF(t.content_id = 14, t.content_hour, 0))   AS content_hour_14,
         SUM(IF(t.content_id = 46, t.content_hour, 0))   AS content_hour_46,
         -- ...more
    FROM cont_time t
    GROUP BY t.depart_id
) M
JOIN ( 
    SELECT depart_id                                  AS join_depart_id,
      SUM(write_hour)                                 AS write_hour,
      SUM(all_hour)                                   AS all_hour
      -- 更多指标
    FROM cont_time
    GROUP BY depart_id
) N ON M.depart_id = N.join_depart_id
ORDER BY depart_id ASC

以查问报表 2021/01/01~2022/03/01 之间数据比照：

StarRocks: 1 次查问聚合，可齐全通过简单 SQL 聚合函数计算，耗时 295ms
Mongodb: 需分 2 次查问 + 计算，共耗时 3s+9s=12s

在应用 StarRocks 时遇到的一些报错和解决方案（网上材料较少的报错信息）：

a. 数据导入 Stream Load 报错：“current running txns on db 13003 is 100, larger than limit 100”

起因：超过了每个数据库中正在运行的导入作业的最大个数，默认值为 100。能够通过调整 max_running_txn_num_per_db 参数来减少每次导入作业的个数，最好是通过调整作业提交批次。即攒批，缩小并发。

b. FE 报错：“java.io.FileNotFoundException: /proc/net/snmp (Too many open files)”

起因：文件句柄有余，这里须要留神，如果是 supervisor 治理过程，则须要将文件句柄的配置加到 fe 的启动脚本中。

if [[$(ulimit -n) -lt 60000 ]]; then
  ulimit -n 65535
fi

c. StarRocks 反对应用 Java 语言编写用户定义函数 UDF，在执行函数报错：“rpc failed, host: x.x.x.x”，be.out 日志中报错：

start time: Tue Aug 9 19:05:14 CST 2022
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

起因：在应用 supervisor 治理过程，须要留神减少 JAVA_HOME 环境变量，即便是 BE 节点也是须要调用 Java 的一些函数，也能够间接将 BE 启动脚本减少 JAVA_HOME 环境变量配置。

d. 执行 Delete 操作报错如下：

SQL > delete from tableName partition (p20220809,p20220810) where `c_time` > '2022-08-09 15:20:00' and `c_time` < '2022-08-10 15:20:00';
ERROR 1064 (HY000): Where clause only supports compound predicate, binary predicate, is_null predicate and in predicate

起因：目前 delete 后的 where 条件不反对 between and 操作，目前只反对 =、>、>=、<、<=、!=、IN、NOT IN

e. 应用 Routine Load 生产 kakfa 数据的时候产生了大量随机 group_id

倡议：建 routine load 的时候指定一下 group name。

f. StarRocks 连贯超时，查问语句报错：“ERROR 1064(HY000):there is no scanNode Backend”，当重新启动 BE 节点后，短暂的复原。日志报错如下：


kafka log-4-FAIL, event: [thrd:x.x.x.x:9092/bootstrap]: x.x.x.x:9092/1: ApiVersionRequest failed: Local: Timed out: probably due to broker version < 0.10 (see api.version.request configuration) (after 10009ms in state APIVERSION_QUERY)

起因：当 Routine Load 连贯 kafka 有问题时，会导致 BrpcWorker 线程耗尽，影响失常拜访连贯 StarRocks。长期解决方案是找到问题工作，暂停工作，即可复原。

接下来咱们会有更多业务接入 StarRocks，替换原有 OLAP 查问引擎；使用更多的业务场景，积攒教训，进步集群稳定性。将来心愿 StarRocks 优化晋升主键模型内存占用，反对更灵便的局部列更新形式，继续优化晋升 Bitmap 查问性能，同时优化多租户资源隔离。今后咱们也会持续积极参与 StarRocks 的社区探讨，反馈业务场景。

* 文 / 沈睿
关注得物技术，每周一三五晚 18:30 更新技术干货
要是感觉文章对你有帮忙的话，欢送评论转发点赞～

关于开发工具:得物基于-StarRocks-的-OLAP-需求实践

1. 什么是 StarRocks

2. 零碎架构

3. 存储架构

3.1 表的存储

4. 需要背景

案例一：业务背景

案例二：业务背景

5. 教训分享

6. 将来布局