1.什么是StarRocks新一代极速全场景MPP数据库？StarRocks可用于支持各种数据分析场景的极速分析；结构简单，采用全面的向量化引擎，并配备全新设计的CBO优化器，查询速度快（尤其是多表关联查询）；很好地支持实时数据分析，可以实现实时更新数据的高效查询，还支持现代物化视图，进一步加快查询速度；用户可以灵活构建各种模型，包括大表、宽表、星型模式、雪花模式；兼容MySQL协议，支持标准SQL语法，连接使用方便。整个系统无外部依赖，可用性高，易于运维管理。2、系统架构核心流程：FE（Frontend）、BE（Backend）。注意：所有节点都是有状态的。FE（Frontend）负责管理元数据、管理客户端连接、查询规划、查询调度等。-Leader：Followers将通过类Paxos的BDBJE协议选举出一个Leader。所有交易提交均由Leader发起和完成；-Follower：提高查询并发，参与投票，参与leader选举操作。FollowerObserver：不参与选主操作，只异步同步和回放日志，主要用于扩展集群的查询并发能力。BE（Backend）负责数据存储和SQL执行。3.存储架构在StarRocks中，一张表的数据会被拆分成多个tablet，每个tablet会以多份的形式存储在BE节点中，如下图所示：Table数据划分+Tablet三-复制数据分布：StarRocks支持Hash分布和Range-Hash组合数据分布（推荐）。为了获得更高的性能，强烈推荐使用Range-Hash的组合数据分布，即先分区后分桶。范围分区可以动态添加和删除；Hash桶一旦确定，就不能再调整，只有未创建的分区才能设置新的桶号。分区和桶的选择非常关键。在建表时选择一个好的分区和桶列，可以有效提升集群的整体性能。以下是特殊应用场景下的分区和分桶选择的一些建议：数据倾斜：如果业务方确定数据存在较大程度的倾斜，建议使用多列组合进行数据分桶，而不是只用一个single使用具有大斜率的列进行分桶。高并发：分区和分桶尽量覆盖查询语句的条件，可以有效减少扫描数据，提高并发。高吞吐量：尽量将数据打散，让集群扫描并发较高的数据，完成相应的计算。3.1表存储在存储表时，表会被分区分桶成两层，表中的数据会分布到多台机器上进行存储和管理。分区机制：高效过滤，提高查询性能。分区类似于分表。就是根据分区键来划分一个表。可以按时间分区，按日/月/年按数据量分区等。分区可以用来裁剪少量的访问，也可以根据数据的冷热程度将数据划分到不同的介质中。Bucketing机制：充分发挥集群性能，避免热点。使用bucketingkeyHash后，数据均匀分布到所有BE中，分桶数据不倾斜。bucketingkey的选择原则是将高基数列或多列组合成一个高基数列。充分分散数据。注意：桶的数量需要适中。如果要充分发挥性能，可以设置为：BE数*CPU核数/2。平板最好控制在1GB左右。如果tablet太少，并行度可能不够。如果有太多的平板电脑，可能会有太多的数据。过多的并发扫描会降低性能。Tablet：最小的数据逻辑单元，可以灵活设置并行计算资源。一个table被分成多个tablet。StarRocks在执行SQL语句时，可以实现对所有tablet的并发处理，从而充分利用多机多核提供的计算能力。创建表时，可以指定副本数。多个副本足以保证数据存储的高可靠性和服务的高可用性。Rowset：每一次数据变化都会产生一个Rowset。它是一些以组存储方式组织的文件。每次提交都会生成一个新版本，每个版本中都包含哪些Rowsets。每次写入都会增加一个版本（无论是单个文件还是streamload几个G的文件）。Segment：如果一个Rowset数据量很大，会被拆分成多个Segment数据落盘。4、需求背景案例一：业务背景指标工厂服务主要面向业务人员。通过对业务指标的采集和处理，实时反映产品状态，为运营提供数据支持，检测产品漏洞或服务异常，提供指标异常报警功能等。业务场景分析业务指标的埋点方式多种多样，并不局限于某一种方式。只要埋点明确，业务参数丰富，数据满足解析的基本要求，就可以作为数据源。大致可以分为：SDK、MySQLBinLog、业务日志、阿里云ODPS数据分析。现有挑战，各种业务场景难以调整，数据特点总结如下：需要全日志明细；数据必须始终是最新的，即满足实时更新的场景；数据需要分层聚合，即可能是按月、按周、按日、按小时等；它需要能够承载更大的书写量；每个业务数据都要灵活配置数据的存储时间；数据源多，报表定制化比较高，多个数据源合并成一个大宽表还有多表连接的需求；各种监控图、报表展示、实时业务查询等，即上级不查询。引入StarRocks好在StarRocks有比较丰富的数据模型，涵盖了以上所有业务场景的需求，即：明细模型、更新模型、聚合模型、主键模型，选择更灵活的星型模型而不是宽表方式，就是直接使用多表关联查询。细节模型：嵌入点数据经过结构化处理后，全细节存储；该场景对亿级数据量下的DB查询性能要求较高；数据可以配置动态分区，配置过期策略；选择单个字段维度进行优化数据的在线聚合查询。聚合模型：埋点数据数据量巨大，不需要追溯明细数据，直接进行聚合计算，如计算PV、UV场景；数据可以通过配置动态分区来配置过期策略。更新模型：埋点数据状态会发生变化，需要实时更新数据。更新数据的范围不会跨越多个分区，例如：订单、优惠券状态等。数据可以通过配置动态分区来配置过期策略。基于以上业务场景的分析，这三种模式都可以完美解决数据问题。对于实时数据写入的场景，我也是沿用了业界流行的方案，即数据采集到Kafka后，我用Flink实时写入StarRocks。StarRocks提供了一个非常好用的Flink-connector插件。小tips：1.虽然StarRocks对写入性能做了很好的优化，但是当写入压力大的时候，还是会出现写入卡顿的情况。建议增加一次导入的数据量，降低频率，但同时也会造成数据Lag延迟增加。因此，需要进行某些权衡以实现利润最大化。2、Flink的sink端不建议配置太大，会导致并发事务错误过多。建议每个FlinkTaskSource可以配置多一些，Sink连接数不要太大。集群规模：5FE（8c32GB），5BE（32c128GB）目前该方案支持上百个业务指标的接入，指标展示和告警涉及数十个大盘，TB级数据存储，每日净增数百个G的整体运行稳定。案例二：业务背景内部系统业务看板主要服务于全公司员工，提供项目、任务跟踪等功能。业务场景分析分析业务特点：数据变化（更新）频繁，变化时间跨度长，查询时间跨度长，多个报表需要实时更新，关联维表，查询次数多，冷热数据如部门/业务线/资源域、近期数据查询历史架构及痛点用户在选择数据库时，结合业务特点，需要动态灵活的增删改查任务。因此，选择JSON模型来降低应用代码与存储层之间的阻抗，选择MongoDB作为数据存储。随着公司的快速发展，当需要报表展示时，尤其是时间跨度比较大，涉及到多部门、多维度、细粒度的报表展示时，MongoDB中的查询时间需要执行10s或甚至更长。引入StarRocks考察StarRocks和ClickHouse，都是优秀的分析型数据库。在选择模型时，他们分析了业务应用场景，主要关注单表聚合查询、多表关联查询、实时更新读写查询。维度表是经常更新的，即存储在MySQL中。StarRocks更好地支持外观相关查询，大大降低了开发难度。最后，我们决定选择StarRocks作为存储引擎。在转换阶段，将原始MongoDB中的一个集合拆分为三个表。使用明细模型每天记录对应人员的任务信息，按天分区，从之前的每人每天一条记录，到以事件为单位，每个人每天可以有多条记录。要实现频繁更新的维度表，选择使用外部表来降低将维度数据同步到StarRocks的复杂性。总结改造前，MongoDB查询语句编写复杂，查询次数多。？
