0、starrocks介绍
StarRocks是一个高性能分布式关系型列式数据库，通过MPP执行框架，单节点每秒可处理多达100亿行数据，同时支持星型模型和雪花模型。
StarRocks集群由FE和BE构成，可以使用MySQL客户端访问StarRocks集群。
FE接收MySQL客户端的连接，解析并执行SQL语句，管理元数据，执行SQL DDL命令， 用Catalog记录库、表、分区，tablet副本等信息。
BE管理tablet副本，tablet是table经过分区分桶形成的子表，采用列式存储。BE受FE指导，创建或删除子表。
BE接收FE分发的物理执行计划并指定BE coordinator节点，在BE coordinator的调度下，与其他BE worker共同协作完成执行。
BE读本地的列存储引擎，获取数据，通过索引和谓词下沉快速过滤数据。
1、为什么要使用starrocks
首先，我不准备去说什么是mpp数据库是什么，starrocks有多好，原因是官网上介绍的足够详细了，所以我准备说说starrocks相对于其他好在哪里以及类似数据库clickhouse。
先说说与clickhouse的对比吧：
-
数据库的扩缩容：难点不在于数据库集群增加节点，而在于增加节点后数据能否均衡。倘若数据不均衡，就会导致数据热点，在数据较多的机器上参与计算的数据多，单一节点的计算瓶颈会导致整体任务执行时间拉长。clickhouse的数据均衡并不是很方便，需要手动维护，而starrocks的数据均衡是自动完成的，降低了用户上手难度。
-
集群高可用高可靠：clickhouse使用副本分片，需要将同一分片副本在不同节点上以此来保证数据的高可靠性。其次保证高可用，需要使用zookeeper进行通信，增加了运维成本。starrocks集群不需要依赖任何其他组件。
再说说对比hadoop生态类的组件：
-
hadoop生态的存储依赖于hdfs，比如传统数据仓库采用hive+hdfs方式，而starrocks存算一体，使用非常方便。
-
hdfs默认存储方式没有压缩，需要安装额外插件，比如lzo、snappy等，starrocks默认采用lz4，减少用户额外工作量。
-
计算速度方面，hive计算速度是非常慢的，实时性计算需要采用spark、kylin等，那么为了满足这样计算需要临时开发或提前构建cube，总之体验不太好，而starrocks不需要构建cube，担心维度爆炸，剪枝，也不用打开编辑器撸一段代码。starrocks的计算速度可以满足业务上的灵活查询，在维度建模、雪花模型上的体验也是可以的。
-
starrocks的查询速度、支持高并发查询也是可以媲美传统大数据解决方案。
以上是我在从hadoop生态到starrocks数据库的使用心得。
2、starrocks使用必备
-
starrocks兼容mysql协议，数据访问使用方式上可以像使用mysql一样使用starrocks。
-
mysql、starrocks等兼容mysql协议的数据库都可以使用datax来进行数据的迁移。
-
联邦查询：hive支持联邦查询，比如可以hive on hbase，hive on elasticsearch，只不过需要添加依赖包（hbase不需要）。通过联邦查询，一份数据不需要多地存储，保证了数据源的一致性。目前最新版本支持hive、mysql、elasticsearch三种类型的外表。
-
数据导入：
-
Routine Load：starrocks可以实时消费kafka数据。
-
Datax writer：可以将业务数据批量导入。
-
除了常用的实时导入和批量导入，还支持spark、flink数据导入，增强和其他组件交互能力，让生态更完善。
-
-
模型：
-
明细模型：用户导入什么数据就存储什么数据，一般用于存储历史数据，比如日志数据。
-
聚合模型：聚合模型有主键概念，会将用户导入的数据进行合并，可以立即为后台自动完成基于明细数据的group by操作。
-
更新模型：更新模型中，主键数据是唯一的，用户不同时间导入的数据，更新模型会帮用户完成数据覆盖更新，保留时间最近的数据。
-
-
分区与分桶：
-
一般使用分区，都是动态分区，动态分区要开启，参数:
dynamic_partition.enable" = "true" -
数据开发时，一般数据都是按天分区，按天写入数据，按天创建分区，也不会删除之前的分区，所以动态分区表的参数配置如下：
#按天分区 "dynamic_partition.time_unit" = "DAY", #提前创建一天分区 "dynamic_partition.end" = "1", #分区名浅醉，可以自定义 "dynamic_partition.prefix" = "p", -
创建表时需要指定存储介质，一般是SSD和HDD，集群配置中也会指定，当建表时没有指定，会使用集群中的配置，优先使用建表语句中。设置冷却时间的参数
storage_cooldown_time，如果不需要冷却，可以将该值设置为"9999-12-31 00:00:00"，默认设置是30天，30天是指创建表时间加30天，所以手动指定时，尽量将时间设置在夜间触发，因为冷热数据迁移会占用cpu等资源。 -
分桶：starrocks是先分区后分桶，如果不设置分区，会默认给一个分区，所有的桶都在这个分区里，分桶计算规则是hash分桶，比如DISTRIBUTED BY HASH(site_id) BUCKETS 10，数据进入分区后，根据将每个分区下的数据分了10个桶，再根据hash算法，数据分别进入这10个桶中。
官方——分桶数如何确定
在StarRocks系统中，分桶是实际物理文件组织的单元。数据在写入磁盘后，就会涉及磁盘文件的管理。一般而言，我们不建议分桶数据过大或过小，尽量适中会比较妥当。
分桶的数据的压缩方式使用的是Lz4。建议压缩后磁盘上每个分桶数据文件大小在 100MB-1GB 左右。这种模式在多数情况下足以满足业务需求。
建议用户根据集群规模的变化，建表时调整分桶的数量。集群规模变化，主要指节点数目的变化。假设现有20G原始数据，依照上述标准，可以建10个分桶（压缩前每个 tablet 大小2GB，压缩后可能在 200MB-500MB）。但是如果用户有20台机器，那么可以适当再缩小每个分桶的数据量，加大分桶数。比如分成40个分桶，大概每个 tablet 500MB（保持压缩后一般不小于 100MB）。
对于这个计算方式，是一个通用的方案，但在实际中要根据数据量、数据长度、服务器配置等因素综合考虑，核心因素还是在于数据均衡以免引起数据倾斜，数据文件不过大以免降低计算效率，数据文件不过多以免增加元数据维护成本。
-
3、实战
-
查询：对sql语句分析主要是查询规划和查询执行，查询规划是在sql客户端explain +sql，就可以得到查询规划。查询执行，需要手动开启，开启后，进入对应host的页面可以找到刚才执行的profile，进行分析就可以。
#session级别，在某个客户端生效 set is_report_success = true官网给了一个例子如何分析explain。
https://docs.starrocks.com/zh-cn/main/administration/Query_planning
-
sql优化：先进行分区裁剪，减少数据量。条件匹配时按照前缀索引的顺序。
-
添加分区：需要先关闭动态分区，手动按照分区创建规则，添加分区之后再开启动态分区（别忘记），分区默认是左闭右开。
1、查看分区名称 show create table，会显示所有分区名称及分区区间 分区表建表时默认根据日期分区，会有默认分区名称前缀p 2、添加分区命令 alter table test add partition p20220508 VALUES [('2022-05-08'), ('2022-05-09')) 这时会提示需要先修改 关闭动态分区参数 3、关闭动态分区 ALTER TABLE test SET ("dynamic_partition.enable" = "false") 4、再次执行第二步添加分区命令 5、开启动态分区 ALTER TABLE test SET ("dynamic_partition.enable" = "true") -
starrocks的主键覆盖是立即生效？还是后台慢慢合并数据？
StarRocks的后台合并就是参考google的mesa的模型，有两层compaction，会后台策略触发合并。如果没有合并完成，查询的时候会合并，但是读出来只会有一个最新的版本，不存在「导入后数据读不到最新版本」的情况。 -
外部表不能修改表结构
-
olap表不能修改表名
-
如果不确定字段类型，尤其是double、decimal和int之前转换时，可以先将数据类型设置为string，string类型可以转其他类型。
-
sum(ifnull(col,0)) 优化后的写法：ifnull(sum(col),0)。比如有10000条数据，第一种写法需要计算20000次，第二种写入计算10001次。
扫一扫
1821
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
