文｜沈睿｜新一代快速全场景MPP数据库可用于获物技术 StarRocks 支持各种数据分析场景的快速分析；结构简单，采用全面定量引擎，配备新设计 CBO 优化器，查询速度(尤其是多表相关查询)；支持实时数据分析，实现实时更新数据的有效查询， 还支持现代化物化视图，进一步加快查询；用户可灵活构建各种模型，包括大宽表、星形模型和雪花模型；兼容性 MySQL 协议，支持标准 SQL 语法，易于对接使用，整个系统无外部依赖，可用性高，操作维护管理方便。
核心进程：FE（Frontend）、BE（Backend）。
注：所有节点都处于状态。FE（Frontend）负责管理元数据、管理客户端连接、查询规划、查询调度等工作。 Follower Leader：Folllower将通过类Paxos的BDBJE协议选择一个Leader，所有事务的提交都由Leader发起并完成； Follower：同时，提高并发查询，参与投票，参与选主操作。 Observer：不参与选主操作，只会异步同步并回放日志，主要用于扩大集群查询并发能力。BE（Backend）负责数据存储和SQL执行。
在starrocks中，一个表的数据将分为多个tablet，每个tablet将以多个副本的形式存储在BE节点中，如下图所示：
error during initialization
分割Table数据 Tablet三副本的数据分布：
支持Hash分布的StarrocksRange-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数据分析。
存在的挑战，各种业务场景难以调整，总结数据特征如下：需要全日志细节；需要数据可以始终是最新的，即满足实时更新场景；需要层次聚合数据，可能是月、周、日、小时等。；需要承载更大的写入量；每个业务数据应灵活配置数据保存时间；数据源多，报告定制度高，有多个数据源合并成大宽表的场景，也有多个表连接的需求；各种监控地图、报告显示、业务实时查询等。，也就是说，更高的不是查询。
StarRockStar
幸运的是，Starrocks拥有丰富的数据模型，涵盖了上述所有业务场景的需求，即明细模型、更新模型、聚合模型和主键模型。同时，选择更灵活的星形模型代替大宽表，即直接使用多表关联进行查询。
细节模型：埋点数据在结构化处理后按细节存储；场景对DB在1亿级数据量下的查询性能有较高的要求；过期策略可以通过配置动态分区来配置；场景使用时，从结构化数据中选择个别字段维度进行在线聚合查询。
聚合模型:埋点数据量巨大，不需要追溯明细数据，直接进行聚合计算，如PV计算、过期策略可以通过配置动态分区来配置数据。
更新模型：埋点数据的状态将发生变化，数据需要实时更新。更新数据的范围不会跨越多个分区，如订单、优惠券状态等；过期策略可以通过配置动态分区来配置数据。
基于对上述业务场景的分析，这三种模型可以完美地解决数据问题。
我还使用了业内流行的解决方案，即数据收集到场景中需要实时数据， Kafka 之后，用Flink实时写入Starrocks。Starrocks提供了一个非常有用的Flink-conector插件。
小tips：
1. 虽然Starrocks已经很好地优化了写入性能，但当写入压力很大时，仍然会有写入拒绝。建议适当增加单次导入数据量，降低频率，但也会导致数据存储延迟增加。因此，我们需要做出一定的选择，以最大化收入。
2. 不建议Flink的sink终端配置过大，这会导致太多的并发事务错误报告。建议每个flink任务source可以配置更多，sink的连接数不能太大。
小结
集群规模：5FE(8c32GB)、5BE(32c128GB)
目前，该方案支持数百个业务指标的访问，涉及数十个市场指标的显示和报警，数据存储TB级，每天净增长数百G，整体运行稳定。
业务背景
内部系统业务看板，主要服务于全公司员工，提供项目和任务跟踪等功能。业务场景分析
分析业务特点：数据变更频繁（更新），变更时间跨度长，查询时间跨度长，报告多，相关维度表查询多，部门/业务线/资源域等冷热数据，最近数据查询频繁
历史结构和痛点
在最初的数据库选择中，用户需要动态、灵活地添加和删除来记录自己的任务，因此他们选择了JOSN 该模型减少了应用程序代码与存储层之间的阻抗，并选择MongoDB作为数据存储。
随着公司的快速发展，当需要显示报告时，特别是当涉及多部门、多维度、细粒度等报告时，需要在MongoDB执行10s甚至更长时间的查询时间。
StarRockStar
对StarRockstarcks进行了调查、ClickHouse是一个非常优秀的分析数据库。在选择类型时，它分析了业务应用场景，主要集中在单表聚合查询、多表关联查询和实时更新读写查询。维度表更新频繁，即存储在MySQL中，Starrocks更好地支持外观关联查询，大大降低了开发难度，最终决定选择Starrocks作为存储引擎。
在改造阶段，原MongoDB中的一个集合被分成三个表。使用详细模型记录相应人员的日常任务信息，根据天分区，从以前的每个人每天记录到事件，每个人每天可以记录多个记录。
对于频繁更新的维表，选择使用外表，将维度数据同步到Starrocks的复杂性。
小结
改造前，MongoDB查询，写作复杂，查询多次。
改造后，直接与SQL兼容，单次聚合。
对比查询报表2021/01/01~2022/03/01之间的数据：StarRocks: 可以通过复杂的SQL聚合函数完全计算一次查询聚合，耗时 295msmongodbod: 需分2次查询 计算，总耗时3s 9s=12s
使用Starrocks时遇到的一些错误报告和解决方案(网上信息较少的错误报告信息)：
a.Streamm导入Streamm数据 Load报错：“Load报错：”current running txns on db 13003 is 100, larger than limit 100”
原因：超过每个数据库中正在运行的导入操作的最大数量，默认值为100。可通过调整进行调整
max_running_txn_num_per_db参数增加每次导入作业的数量，最好通过调整作业提交批次。也就是说，保存批次，减少并发。
b. FE报错：“FE报错：“
java.io.FileNotFoundException: /proc/net/snmp (Too many open files)”
原因:文件句柄不足。这里需要注意的是，如果是supervisor管理过程，则需要将文件句柄的配置添加到fe的启动脚本中。
c. StarRocks 支持使用 Java 语言编写用户定义函数 UDF，执行函数报错：“rpc failed, host: x.x.x.x”，be.out日志中报错：
原因:在使用supervisor管理过程中，需要注意增加JAVA_HOME环境变量。即使是BE节点也需要调用JAVA的一些函数，BE启动脚本也可以直接添加JAVA_HOME环境变量配置。
d. 执行Delete操作报错如下：
原因:delete后的where条件不支持betwenen 目前and操作只支持and操作 =、>、>=、<、<=、!=、IN、NOT IN<、<=、!=、IN、NOT IN
e. 使用Routine 当Load消耗kakfa数据时，会产生大量随机group_id
建议:建议:建议routine 在load中指定group时 name。
f. Starrocks连接超时，查询语句报错：“ERROR 1064(HY000):there is no scanNode Backend当BE节点重新启动时，短暂恢复。日志报错如下：
原因:Routine Load连接kafka有问题时，Brpcworker线程耗尽，影响Starrocks的正常访问。临时解决方案是找到问题任务，暂停任务，然后恢复。
接下来，我们将有更多的业务接入 StarRocks，替换原有 OLAP 查询引擎；利用更多的业务场景，积累经验，提高集群稳定性。希望未来 StarRocks 优化提升主键模类型内存占用，支持更灵活的部分列更新方法，不断优化和改进 Bitmap 查询性能，优化多租户资源隔离。今后，我们将继续积极参与 StarRocks 对业务场景进行社区讨论和反馈。
网友评论