StarRocks的应用场景
StarRocks简介
- StarRocks是新一代极速全场景MPP数据库。
- StarRocks充分吸收关系型OLAP数据库和分布式存储系统在大数据时代的优秀研究成果，在业界实践的基础上，进一步改进优化、升级架构，并增添了众多全新功能，形成了全新的企业级产品。
- StarRocks致力于构建极速统一分析体验，满足企业用户的多种数据分析场景，支持多种数据模型(明细模型、聚合模型、更新模型)，多种导入方式（批量和实时），支持导入多达10000列的数据，可整合和接入多种现有系统(Spark、Flink、Hive、 ElasticSearch)。
- StarRocks兼容MySQL协议，可使用MySQL客户端和常用BI工具对接StarRocks来进行数据分析。
- StarRocks采用分布式架构，对数据表进行水平划分并以多副本存储。集群规模可以灵活伸缩，能够支持10PB级别的数据分析; 支持MPP框架，并行加速计算; 支持多副本，具有弹性容错能力。
- StarRocks采用关系模型，使用严格的数据类型和列式存储引擎，通过编码和压缩技术，降低读写放大；使用向量化执行方式，充分挖掘多核CPU的并行计算能力，从而显著提升查询性能
StarRocks特性
架构精简
StarRocks内部通过MPP计算框架完成SQL的具体执行工作。MPP框架本身能够充分的利用多节点的计算能力，整个查询并行执行，从而实现良好的交互式分析体验。 StarRocks集群不需要依赖任何其他组件，易部署、易维护，极简的架构设计，降低了StarRocks系统的复杂度和维护成本，同时也提升了系统的可靠性和扩展性。 管理员只需要专注于StarRocks系统，无需学习和管理任何其他外部系统。
全面向量化引擎
StarRocks的计算层全面采用了向量化技术，将所有算子、函数、扫描过滤和导入导出模块进行了系统性优化。通过列式的内存布局、适配CPU的SIMD指令集等手段，充分发挥了现代CPU的并行计算能力，从而实现亚秒级别的多维分析能力。
智能查询优化
StarRocks通过CBO优化器(Cost Based Optimizer)可以对复杂查询自动优化。无需人工干预，就可以通过统计信息合理估算执行成本，生成更优的执行计划，大大提高了Adhoc和ETL场景的数据分析效率。
联邦查询
StarRocks支持使用外表的方式进行联邦查询，当前可以支持Hive、MySQL、Elasticsearch三种类型的外表，用户无需通过数据导入，可以直接进行数据查询加速。
高效更新
StarRocks支持多种数据模型，其中更新模型可以按照主键进行upsert/delete操作，通过存储和索引的优化可以在并发更新的同时实现高效的查询优化，更好的服务实时数仓的场景。
智能物化视图
StarRocks支持智能的物化视图。用户可以通过创建物化视图，预先计算生成预聚合表用于加速聚合类查询请求。StarRocks的物化视图能够在数据导入时自动完成汇聚，与原始表数据保持一致。并且在查询的时候，用户无需指定物化视图，StarRocks能够自动选择最优的物化视图来满足查询请求。
标准SQL
StarRocks支持标准的SQL语法，包括聚合、JOIN、排序、窗口函数和自定义函数等功能。StarRocks可以完整支持TPC-H的22个SQL和TPC-DS的99个SQL。此外，StarRocks还兼容MySQL协议语法，可使用现有的各种客户端工具、BI软件访问StarRocks，对StarRocks中的数据进行拖拽式分析。
流批一体
StarRocks支持实时和批量两种数据导入方式，支持的数据源有Kafka、HDFS、本地文件，支持的数据格式有ORC、Parquet和CSV等，支持导入多达10000列的数据。StarRocks可以实时消费Kafka数据来完成数据导入，保证数据不丢不重（exactly once）。StarRocks也可以从本地或者远程（HDFS）批量导入数据。
高可用易扩展
StarRocks的元数据和数据都是多副本存储，并且集群中服务有热备，多实例部署，避免了单点故障。集群具有自愈能力，可弹性恢复，节点的宕机、下线、异常都不会影响StarRocks集群服务的整体稳定性。 StarRocks采用分布式架构，存储容量和计算能力可近乎线性水平扩展。StarRocks单集群的节点规模可扩展到数百节点，数据规模可达到10PB级别。 扩缩容期间无需停服，可以正常提供查询服务。 另外StarRocks中表模式热变更，可通过一条简单SQL命令动态地修改表的定义，例如增加列、减少列、新建物化视图等。同时，处于模式变更中的表也可也正常导入和查询数据。
应用场景
- OLAP多维分析
- 用户行为分析
- 用户画像、标签分析、圈人
- 高维业务指标报表
- 自助式报表平台
- 业务问题探查分析
- 跨主题业务分析
- 财务报表
- 系统监控分析
- 实时数据分析
- 电商大促数据分析
- 教育行业的直播质量分析
- 物流行业的运单分析
- 金融行业绩效分析、指标计算
- 广告投放分析
- 管理驾驶舱
- 探针分析APM（Application Performance Management）
- 高并发查询
- 广告主报表分析
- 零售行业渠道人员分析
- SaaS行业面向用户分析报表
- Dashbroad多页面分析
- 统一分析
- 通过使用一套系统解决多维分析、高并发查询、预计算、实时分析、Adhoc查询等场景，降低系统复杂度和多技术栈开发与维护成本。
案例介绍
案例一：海尔云链 金融数据查询增速三倍，服务器成本减半
业务背景及历史架构痛点
金融信贷业务
在传统的金融信贷业务中，业务系统主要划分为贷前、贷中、贷后三个阶段（客户信息录入、放款、贷款清收），而从数据角度出发主要分为贷前和贷后两个阶段（按照是否放款进行区分）。
贷前阶段主要是进行客户个人信息相关的数据处理，相对贷后阶段数据较少，一般较多结合业务系统、在传统的关系型数据库中处理。
贷后的数据量会膨胀为贷前的几十倍（例如房贷、车贷，一个客户成功申请会随之带来几十上百条的账单信息），加上代扣等操作带来的数据量再次膨胀，导致传统的关系型数据库在处理贷后数据时负担极大，每天都需要进行部分数据归档迁移。
然而，贷后的数据极为重要，客户、合作助贷方、渠道、商户、业务人员、财务部门都需要不同的贷后数据，而且大多都需要实时数据。
查询特点上，这些业务方会定时、不定时来获取各个维度的数据，包括历史数据。这导致基于传统关系型数据库的核心业务系统负担极大。
核心诉求
基于以上现实情况，我们开始探索基于大数据处理，打造一个能对内、对外提供实时、离线计算和查询的贷后处理系统。这个系统需要能解决以下各个问题：
- 提供实时数据以及批量数据写入、更新的能力；
- 能提供大数据量下的数据快速查询能力；
- 能提供 SQL 或者类 SQL 的语言，便于报表系统或者业务人员操作；
- 能够有较好的数据容灾副本机制；
- 能够提供较好的并发支持能力。
主流方案
行业内主流处理方案分为如下几种，一般采用其中一种或者多种组合使用：
- 数据量相对较小，使用关系型数据库的只读库或者备库，为贷后数据业务提供支撑。该方案使用没有什么问题，也比较成熟；缺点很明显，关系型数据库处理数据量级有限。
- 数据量大，使用 ETL 工具将数据写入大数据系统，采用 Hbase+Phoenix 的方案，基于 Phoenix 对外提供数据支撑。该方案能够处理大量数据，也能通过 ETL 将离线数据统一跑批写入 Hbase；缺点是只能做大宽表，而且数据处理流程相对复杂。
- 数据量大，依旧使用 ETL 工具将数据写入 ClickHouse。该方案能处理大量数据，也可以做离线数据的统一处理；缺点也是大多做大宽表，而且数据实时性更新能力不强，并发支持也不强。
- 数据量大，依旧使用 ETL 工具将数据写入 Hive，基于 Impala、Presto 等方式对外提供数据，或者使用 Druid 等。这几个方式的缺点都是无法完成实时更新且并发能力较弱。
历史架构
基于上述情况，海尔云链科技第一代金融贷后数据处理系统诞生。受限于历史技术条件、业务数据规模和成本考量，第一代金融贷后数据架构的链路较为复杂、数据存在一定冗余，如下图所示。
具体来说，数据从各个核心业务数据库通过 ETL 平台将实时、离线数据汇集到 Hadoop 集群中。数据根据实时性以及数据量被分别写入到 Hbase 与 Hive，结合 Phoenix、Alluxio+Presto 对外统一提供数据。用户通过前端系统调用配置等多种方式获取数据。
在实时数据方面，由于金融数据要求实时可变动，且针对多个部门渠道有不同的数据要求、数据获取的条件灵活多变，而业务部门期望查询都能快速响应，由此建立了大量二级索引。在金融业务中，每天晚上核心业务系统数据会进行大量账务计算，每月还有一个定期数据入账日。面临这种短时间、超大批量数据进入的任务，大数据集群的 Hbase 会出现巨大的写入延迟，同时集群 CPU 拉升、性能大幅下降。
在离线数据方面，由于数据量和业务复杂度的上升，以及客户对 BI 系统的期望越来越高，数据平台对离线分析数据进行了多次升级。在 Hive+Presto 的基础上再附加 Alluxio 作缓存，直接导致系统硬件成本翻倍，并且加大了运维成本。
架构升级
进行 架构升级前，首先需要了解大数据金融行业的数据特性：
- 数据时效性高，且需要实时或者准实时更新；
- 每天、每月有日终、月终结算，会短时间产生大量的变动日志数据；
- 数据量差异明显，扣款处理明细等日增量数据之间存在千万级别的差别；
- 数据维度丰富，查询条件多样且易变，查询聚合能力要求高。
为了解决以上问题，海尔云链在 2021 年年中对市面上的主流 OLAP 引擎进行了调研选型测试，综合评判下来，我们最终选择了 StarRocks。
升级效果
引入 StarRocks 后，我们在实时处理方面用 StarRocks 替代了以前的 Hbase+Phoenix，离线数据方面也部分用 StarRocks 替代了 Hive+Alluxio+Presto。
迭代新架构后，查询效率大幅提升。下图所示对比测试是在 StarRocks v1.19.0，CentOS 7.8 上进行的。响应速度方面，以前是 90% 查询在 5s 内、99% 查询在 10s 内，如今是 90% 查询在 1s 内、99% 查询在 3s 内。Hive 外表查询方面，之前是 99% 在 35s 内返回，如今是 99% 在 5s 内返回，查询平均耗时得到了大幅缩减。
此外，通过升级改造，服务器成本整体减低到接近原体系架构的一半。以前使用多服务多组件，如今统一到 StarRocks，使得运维成本也得到了大大降低。
选型 StarRocks 后的新一代贷后系统，对关联查询的支持非常友好。我们可以直接通过 ETL 将数据源实时无修改的写入，恢复业务原貌的同时还能满足业务需要，大大降低了 ETL 复杂度。此外，我们还能利用聚合模型提升聚合数据的支撑性能。
StarRocks 的多种模型，支持金融数据根据数据和业务特性，选择最优的解决方案。
在上一代贷后系统中，业务代扣信息相关数据只存在新增，数据日增在千万级别。业务部门需要根据业务主键和时间段进行查询，又要附带其他的业务信息，导致这个表字段又多、数据量又大。涉及该表的一些查询都需要 10s 左右，还存在 Hbase 分裂处理、索引设计等一系列复杂情况。
在新一代的贷后系统中，通过利用 StarRocks 的明细模型，可以自动按照日期分区、去除冗余字段、缩减单表数据大小。涉及到该表的相关查询，最多不到 3s 就可以返回结果，并且大部分查询在 1s 内就能完成。
如今，业务部门会议已经无需提前准备数据，会议现场可以直接从贷后系统获取最新实时数据、聚合报表等。申报数据延迟、查询缓慢等问题，也从之前周周提报到现在消声灭迹。
方案总结
在使用 StarRocks 作为新技术架构后，海尔云链充分利用 StarRocks 不同模型，StarRocks 卓越的关联查询能力使得数据灵活性大大提升，查询效率得到了 3-7 倍的提升。
由于新架构不存在老架构索引过多导致数据写入缓慢的问题（如在日终或月度入账时，短时间产生的大量日志数据会在短时间内被处理），并且支持根据数据业务特性选择不同的数据模型，极大解决了业务痛点。
此外，使用 StarRocks 后极大减少了服务器成本，其简单的部署、扩展、监控方式，极大提升了运维效率。
案例二：涉密行业下的StarRocks的信创应用
行业特殊性
环境要求
某涉密公司深处公安行业，为行业内客户提供敏感业务方向产品开发和业务技术支持，提升行业工作效率。由于行业特殊性相关，近年来，行业标准要求所有行业内公司使用的软件及硬件环境都需要符合国家信创标准。因此，该涉密公司需要寻求技术方案将原有的不符合信创标准的软件框架进行替换，选用信创目录中的满足标准需要软硬件产品。
在这种环境下，该公司在数仓领域将原有的架构进行了升级替换，满足了产品要求，提升了产品性能。
数据体量大
该公司面对的业务具有特殊性，数据量比较大，数据总量PB级别，日增TB级别，因此选用合适的数仓框架，对于产品稳定性和查询性能极为重要。
历史架构痛点
历史架构使用了多种开源组件，包括flume、kafka、storm、greenplum，数据链路较长，数据冗余份数较多，由于数据体量较大，从数据处理到最终用户使用耗时较长，整个处理流程需要一天甚至两天的时长，损失了数据的实效性，系统臃肿，核心数仓greenplum的稳定性也较差，经常需要人工干预集群运维，增加运维成本。
架构升级
经过调研测试后，我们选用了StarRocks作为核心数仓的计算引擎，并重构了整个数据链路，减少了数据在多个组件中的冗余和IO次数，简化了整个架构。并且开发了相关的自动化运维工具，使得整个数仓的数据处理能力和稳定性上升了一个量级。
升级效果
- 满足了客户对于软硬件的背景审查，整个产品满足了客户的信创标准。
- 数仓减重，轻量化，简洁化，减少了开发和运维人员的技术成本。
- 硬件成本大大减少。相比较之前的历史方案，升级后的硬件资源消耗在同等数据规模下，成本下降了近4-5倍，大幅减少了硬件支出，提高了盈利能力。
- 软件性能大大提升。原有的数据处理流程较长，处理速度较慢，整个链路是需要天级别的时间处理，升级后，流程减少，处理时间大大加速，客户查询响应由原来的分钟甚至小时级别加速到秒级，整个处理链路也由原来的天级别缩短至现在的分钟级别。获得了客户的一致好评。
方案总结
该公司在使用StarRocks作为数仓核心计算引擎后，大幅减少了硬件支持和软件开发成本，使得该重型项目得以轻量化开发，不仅满足了国家信创标准，赢得了客户的一致好评，还为企业增加了盈利空间，减少支出。未来，该企业将在多个业务方向上引进StarRocks作为核心计算引擎使用，提高企业效率。
案例三：小红书 简化数仓链路，提升查询性能
小红书数仓演进史
小红书 OLAP 演进可以分为四个阶段。**第一阶段，在2017年之前，数据总量还不算非常大，这个阶段主要使用 AWS 的 Redshift。**此阶段数仓体系还没有完全建立，很多数据需求的实现都是用短平快、烟囱式开发的方式来满足。数据 ETL、数仓模型到最后报表端展现，在 Redshift 中一站式完成。但随着业务复杂度不断提升，以及数据量的快速增长，这种模式很快遇到了瓶颈。
第二阶段，基于 Hadoop 生态构建了小红书的数仓体系，基于 Hive 和 Presto 构建数据分析平台。
**第三阶段，随着数据实时性的要求越来越高，业务方对整个数据分析的性能要求也越来越高，所以在2019年左右引入了 ClickHouse。**通过 ClickHouse 强悍的分析能力，构造了一个准实时的交互式的分析平台，来支撑公司内包括用户行为分析、实验平台等一系列的场景。
**第四阶段，随着实时数仓体系的设计和建设不断的推进，越来越多内部包括外部的数据应用也对数据分析要求越来越高。**除了要求超低延迟的响应要求，同时还可能有比较高的 QPS 要求，ClickHouse 在这方面就不能够很好的满足业务的需求。所以在2020年底的时候，我们尝试了 StarRocks，并且目前已经在公司内多个业务场景中落地推广。
业务背景
小红书的广告场景大概可以分为两类，一种是搜索广告，一种是效果广告。搜索广告主要会利用实时计算出来一些统计指标，来对广告的部分召回进行推荐。
效果广告主要是会根据用户的一些展点销的信息，统计出的实时指标，再结合一些投放的实验进行智能广告的投放。同时，广告平台会根据各种业务的统计指标，产生实时或者离线的数据报告，供广告主进行分析运营使用。
历史架构痛点
搜索业务场景主要包括三个方面的业务特征：第一个是要计算的特征的数量特别多，并且组合维度也非常的灵活。第二个是统计指标的时间粒度跨度非常广，可能有小时级别、6小时、12小时，也有一天、两天甚至一个月的这种时间力度。第三个是所有的维度组合统计的时间粒度，它的变更在后续可能会非常的频繁。
在之前的架构中，主要是通过一个 Flink Java 程序去实现的。在这个 Java 程序当中，实现了所需要的所有维度组合时间粒度统计。这种架构现在来看其实是有很明显的弊端的：**首先整个架构的灵活性是非常差的。**如果要做一些变更，不仅需要进行一些开发和测试，还涉及到上线发版停服的问题。**第二个因为所有的业务逻辑加工都是在这个 Java 代码中实现的，整个开发过程当中非常容易出错。**所以开发完成之后，对数据质量的校验要花非常多的时间，导致整个业务变更的周期也会拉得很长。**第三个是整个架构的扩展性是比较差的。**随着维度增长，整个 Flink 集群的性能和稳定性会受到比较大的影响。
架构升级
通过 StarRocks 的引入，在 Flink 侧做的事情就比较简单，主要负责这些实时和离线数据的载入，然后通过 StarRocks 来为下游的这些广告算法策略、实时计费，还有投放端的数据报告，提供一个统一的数据加工分析平台。改造之后的数据链路就如图所示：
在这个链路当中，数据载入会包括两方面：第一个是实时的数据载入，在这里面我们主要还是用 Flink SQL 来完成的。有两方面的考虑，一是通过 StarRocks Connector 来实现 Exactly Once 语义，保证数据不丢不重。同时，跟小红书内的数据交换平台集成，可以很方便的去管理这些实时载入的任务。第二个是离线报表的数据载入，我们这里选择的是 Broker Load 载入方式，因为相比于 Stream Load，开启向量化的数据导入之后，Broker Load 的性能大概有10倍的提升。可以很好的满足我们这种数据报告高 SLA 的要求。
在表模型选择上，这个业务当中，90%以上的表都是聚合表。除了聚合表之外，我们还用了明细表模型。主要的使用场景就是用来展示这种 T + 1 的离线报表数据。虽然它是明细表，配合导数的后置数据质量校验工具，可以有效的保障数据的正确性。如果涉及到大量的历史数据的 Backfill， 也有非常好的表现。
另外就是 Unique 模型表的使用。我们在将 MySQL 维度表实时同步到 StarRocks 中时，主要采用的是这种模式。在引入 StarRocks 之前，当时我们是起了一个定时调度任务，每3分钟去删除 ClickHouse 里面的维度数据，然后再从 MySQL 里面全量的导入一遍。这个方式也运行了很长的一段时间没出过问题，直到有一天业务方提了一个表变更的需求。当我们在做变更的时候，正在删 MySQL 的维度数据，然后又触发了 ClickHouse 的一个 bug，就是当多个 DDL 在进行操作的时候，可能会从这死锁。所以在那个时候我们就出现了一段时间的数据的不可用，导致广告主那边看到的数据报告是不准确的。现在使用 StarRocks 引擎，我们通过 Flink 实时消费 MySQL 的 Binlog，然后直接插入到一个 Unique 表当中。这样的数据链路一方面大大提升了数据更新的时效性，另外一方面也提升了整个架构的可靠性。
升级效果
广告数据中心建设到现在已经上线了很长一段时间了，目前每天会有超过百万次的查询分析，然后在高峰的时段查询的 QPS 达到数几百条，当然这远远没有达到 StarRocks 的性能上限。我们做过一个性能测试，单 FE 的 QPS 能达到2000，单集群的 QPS 能达到10000以上，可以有效地支撑我们未来的业务增长。并且整个查询的延迟是非常低的，我们整体的 P99 的查询耗时在 200毫秒以内，绝大部分时候都在100毫秒以内。
方案总结
小红书使用过多种 OLAP 数据分析系统。StarRocks 采用了全面向量化计算技术，是性能非常强悍的新一代 MPP 数据库。通过引入 StarRocks，小红书构建了全新的统一数据服务平台，大大降低了数据链路开发复杂性，提升了高并发极速查询能力。
