目录
[5.1 使用经验分享](#5.1 使用经验分享)
[5.2 下一步计划](#5.2 下一步计划)
[5.2.1 StarRocks集群自动安装](#5.2.1 StarRocks集群自动安装)
[5.2.2 StarRocks集群高可用架构](#5.2.2 StarRocks集群高可用架构)
原文大佬的这篇StarRocks应用实践有借鉴意义，这里摘抄下来用作学习和知识沉淀。
一、为何引入StarRocks
目前公司大数据平台已经引入了多个OLAP技术框架，随着应用的深入，在部分场景下发现这些框架也都由各自的缺点，主要体现在以下几个方面：
因此期望寻找一款能至少在部分业务场景下解决以上问题的新框架，与现有框架实现互补，理想情况下能替换调部分技术框架，满足功能需求的同时降低技术栈复杂度。
二、主要应用 场景
目前我主要将StarRocks应用于业务数据的分析和大屏展示，业务数据经过实时清洗进入StarRocks或通过离线方式定时拉取写入StarRocks，再经过相应扩展分别提供给BI报表数据源，集成到大屏展示及通过SDK提供给业务代码访问。
根据业务数据对查询性能要求较高，且要求支持数据进行部分列更新的特点，我们主要采用的是主键模型。部分列更新是指每次更新数据按照主键，只需要更新指定字段数据，而非整行覆盖数据。以订单数据为例，订单数据量较大，且不同部分信息在业务库中存在不同表中。可以建立以订单ID为主键的主键模型，通过定时数据拉取任务，将业务库属于不同表的订单相关数据合并到StarRocks中订单明细表，避免查询时join引起的性能问题。
而对于数据量不大，且不经常需要查询的维度数据，则可以单独建立维度表，只在需要查询时进行关联。有效节省存储量，同时维表可以定时更新，保证维度数据是最新的。对于需要保持历史数据的维度字段，则可以像上面的订单各部分信息一样，采用部分列更新方式冗余在明细表上，做到业务需求和成本的有效平衡。这个场景的成功应用，得益于StarRocks对多表关联的支持。
三、封装或 扩展
为了将StarRocks集成到公司的大数据平台中，并为业务部门提供相关组件和工具支撑，我们围绕StarRocks进行了以下封装或扩展：
- 大数据访问SDK：对StarRocks访问操作做了封装，并集成了响应时间，请求TPS，请求链路等监控埋点，以及请求日志，异常日志等功能。
- StarRocks查询工具：是一款Web方式访问的查询分析工具，方便业务部门同事开发/运维期间查询验证数据使用。
- Kettle和HUE StarRocksDataX插件：分别基于HUE和Kettle的进行扩展，提供了向StarRocks进行数据同步的插件，支持多种参数配置。
- StarRocks监控埋点：对StarRocks集群的相关运行参数进行采集，并集成到公司监控平台。
四、集群监控预警
通过将StarRocks监控指标参数抓取到公司监控预警平台，实现了StarRocks集群运行情况的实时监控和及时预警。
五、总结规划展望
目前初期阶段，StarRocks投入应用场景50+，总表个数200+, 数据总量超过5TB，相关功能在切换后，在响应时间，存储成本等方面都有相应改善。
5.1 使用经验分享
-
合理设置分区分桶键，分区和分桶应该尽量覆盖查询语句所带的条件，这样可以有效减少扫描数据，提高查询性能。
-
合理设置分区和分桶大小，实现数据均衡分布，单个分区原始数据量建议不要超过100GB，单个分桶控制在100M到1G左右，最大不要超过10G。太小造成小文件tablet太多，影响磁盘IO，太大不利于资源合理分配并影响查询效率。
-
排序键不应该包含过多的列，对于主键模型而言，key列大小不能超过127个字节。选择过多排序列并不能提升查询性能，而且会增大排序的开销，进而增加数据导入的开销。
-
当排序键涉及多个列的时候，建议把区分度高、且经常查询的列放在前面。区分度高的列是指取值个数多，且持续增加的列。
-
查询时尽量只select需要的字段, 减少不必要的开销。
-
关联维表可显式添加shuffle关键字进行优化（Join Hint 语法，手动指定join类型）。
-
据量非常大的维表中常用字段，考虑在主表（维度退化）进行冗余。
5.2 下一步计划
5.2.1 StarRocks集群自动安装
目前在搭建不同环境时，都是手动进行StarRocks的部署和配置。重复进行相同工作，且手工处理易出错，效率低。计划将StarRocks集成到公司的大数据安装框架，实现StarRocks安装部署和元数据初始化的自动化。提高部署效率，降低运维成本。
5.2.2 StarRocks集群高可用 架构
随着越来越多的业务迁移到StarRocks，特别是一些重要级别较高业务的迁移，对StarRocks的可用性提出了更高的要求。虽然StarRock本身通过其架构特点提供了一定的高可用性。但我们仍然计划基于自建的集群高可用框架，在数据双写的基础上提供集群级别的高可用，以实现在集群宕机时故障的快速转移，高可用框架的主要架构如下：
参考文章：