共计 6149 个字符，预计需要花费 16 分钟才能阅读完成。
小编导读：
自从 2023 年 4 月正式推出 3.0 版本的存算拆散性能以来，目前已有蕴含芒果 TV、聚水潭、网易邮箱、浪潮、天道金科等数十家用户实现测试，多家用户也已开始逐渐将其利用于理论业务中。目前，StarRocks 存算拆散上线的场景蕴含电商 ERP 订单剖析零碎、金融业务数据分析和制造业设施数据分析。由此可见，StarRocks 存算拆散已达到生产可用的高标准。
在本文中，咱们将向大家介绍一家曾经胜利上线存算拆散架构的金融科技公司，重点论述他们如何引入了 StarRocks 3.0 架构。目前，他们所应用的 StarRocks 3.1 存算拆散版本已在线稳固运行。
随着互联网迅速演进，金融畛域正经验着向智能化和数字化方向的继续转型。作为引领金融畛域改革的先锋，金融科技（FinTech）正施展着重要作用，而在这个改革过程中，大数据技术成为了不可或缺的关键环节。
在这背景下，某国内出名金融科技公司为了构建区域供应链金融科技平台，实现降本增效，做出了一项重大决策：将原有的 Hadoop 集群平滑迁徙为 StarRocks。 通过深刻的测试和调研，该公司胜利地上线了 StarRocks 3.1 版本的存算拆散架构。新架构的上线不仅显著晋升了查问性能超过 10 倍，精细化了权限管控流程，实现了更实时的数据更新，还极大地加重了保护工作的累赘。
本文旨在具体介绍这家金融科技公司引入 StarRocks 存算拆散架构的搭建过程和利用实际。通过深刻探索，读者将更清晰地理解这一转型背地的思考、施行以及获得的成绩。
业务背景
数据团队是负责解决和治理企业海量数据的外围团队，为企业决策提供松软的数据反对。为了推动大数据平台的建设和数据治理工作，咱们在晚期搭建了基于 Hadoop 的大数据平台，并将历史数据都迁徙至 Hive 数仓中。
（旧有大数据架构）
如上图所示，咱们的数据仓库 Hive 集成了阿里云 Jindo SDK，底层应用 OSS 存储海量数据。计算引擎咱们采纳了 Spark，通过在其上方构建了 Kyuubi 网关，实现了多租户和资源隔离，从而进一步优化了计算资源的利用；即席查问，咱们抉择了 Trino（原 Presto）作为执行引擎；次要的数据治理和开发工作则是应用了 SparkSql+UDF/UDAF。
业务痛点
1. 数据治理链路简单
在数据治理整个链路上，数据团队通常先用 Presto 进行数据探查，探查完后再通过 SparkSQL+UDF 对数据进行加工，最初通过 DataX 和 SeaTunnel 将后果同步到 MySQL 和 Elasticsearch 中。Spark 工作和同步工作通过海豚调度（DolphinScheduler) T+1 执行。其余部门人员和客户即可在后果库进行数据查问剖析。
然而，在数据治理的不同阶段，咱们留神到不同部门和团队成员可能会对同一数据内容有不同的了解、计算规定或数据定义存在差别，导致最终在后果库中的数据呈现出不一致性。这可能引发数据口径不统一的状况，须要咱们进行数据回溯和调整，以确保数据统计的准确性和一致性。
2. ODS 层数据合并效率太低
因为 Hive 表不足主键更新性能，咱们在原有的 ODS 层增量数据合并流程中面临一些挑战，不得不针对每天单表几亿行数据，与数十万到几百万行的增量数据进行关联，对执行开窗去重操作并在数据量比对和查看后，采纳 INSERT OVERWRITE 的形式来笼罩老数据，从而实现增量数据的合并。然而，这种流程效率较低，往往须要消耗长达两个多小时的工夫来实现 ODS 层的增量数据合并工作。
3. 大数据量数据查问慢，产出工夫长
因为集群的磁盘空间不足以寄存几十 T 的数据量，为了解决这一问题，咱们在大数据平台上引入了 JindoSDK 并将底层存储从 HDFS 切换到 OSS。只管这种扭转能为数据存储的扩展性带来一些益处，但在进行 Spark 批处理工作时，却导致了工作执行工夫的显著缩短。常常一个工作流须要几个小时实现，一旦批改调整一点加工逻辑，就须要从头开始加工计算，整体的数据产出工夫很长。
4. 大数据集群稳定性差，保护老本高
在 Spark shuffle 过程中，大量的两头数据须要被写入磁盘，导致 ECS 的磁盘 I/O 常常打满。应用 Spark 初期，集群因为各种问题报错，以及机器磁盘被打满，平台每天都要重启集群 2-3 次，重大影响了生产环境可用性。另外，因为大数据集群中涵盖了泛滥组件，须要每天查看外加每周定时巡检。在数据治理的同时还须要大量工夫去保护整个集群，这对开发和运维人员造成了不小的累赘。
原有集群：
（CDH 集群监控）
（CDH 物理节点监控）
针对现有大数据架构下面提到的各种问题，咱们大数据团队踊跃寻找各种解决方案，心愿应用更先进的架构来取代老的大数据体系。通过详尽的调研，最终咱们将眼光锁定在 StarRocks。StarRocks 作为新一代云原生湖仓一体架构的数据分析平台，其具备性能优异、场景丰盛和运维简略等长处，是咱们外部对立数据处理架构的现实抉择。
同时，思考到咱们始终采纳存算拆散架构来解决大数据，咱们也心愿 StarRocks 能具备存算拆散架构以节约老本并加重运维累赘。调研之时，咱们也凑巧赶上社区推出了 3.0 版本，咱们毫不犹豫第一工夫进行了测试和体验，并领会到其性能的优越（具体的测试报告请见：https://forum.mirrorship.cn/t/topic/7075）。测评后，咱们立即上线了 StarRocks 3.0 存算拆散版本，随后立刻降级应用 3.1.0 版本，并运行在存算拆散模式。整个集群由 3 个前端节点（FE）和 8 个后端节点（BE）组成，其中 FE 为 3 台 32G 的 ECS 组成高可用，而 BE 局部则采纳了 32C 128G 2T 磁盘的 ECS。所有业务数据都存储在 OSS 中。
自往年 3 月开始内测存算拆散，目前上线存算拆散已有两个月。咱们已胜利实现对整个 ODS 层业务数据的迁徙，总数据量已达到 4TB。接下来，咱们将具体介绍一下 StarRocks 3.0 存算拆散版本所具备的劣势，以及它为咱们带来的显著价值：
StarRocks 存算拆散劣势
1. 劣势一：性能晋升 10 倍以上
过来，咱们应用 Spark 进行批处理工作时，工作速度迟缓，导致开发效率低下。然而，通过采纳 StarRocks 存算拆散的新架构，只管数据依然存储在 OSS 中，但工作的执行速度相较于 Spark 工作晋升了 10 倍以上。 这一微小的性能晋升缩短了工作执行工夫，从而显著减少了开发效率。
（性能测试数据）
测试结果显示，即便敞开了 Cache，相比 Spark SQL 等最高也有近百倍的性能晋升，让咱们在享受存算拆散便当的同时还能领有之前未曾体验的极速性能。
2. 劣势二：权限管控流程更加简略和精细化
在 CDH 平台中，权限管控始终是一个简单而繁琐的问题。原先咱们应用 Kerberos 认证，但无奈实现对库级别和表级别权限的细化管制。这意味着开发、经营和算法团队都可能拜访所有数据，导致数据的安全性受到了很大的影响。
与之相比，StarRocks 采纳了基于角色的访问控制（RBAC）权限模型，大大简化了权限治理流程。咱们可能实现库级别和表级别权限的细粒度管制，这在适应多业务线的场景中尤为重要。 用户与角色的调配也更加灵便。对非公开的财务数据，咱们能 够为个别用户独自受权拜访某个库或特定表的权限，从而极大地晋升了数据的安全性。 这正是咱们急需的性能，为数据安全提供了松软保障。
3. 劣势三：反对主键模型，数据更新更实时
StarRocks 3.1 版本的存算拆散架构曾经引入了主键模型表的反对。 通过主键模型的利用，咱们胜利地克服了老架构中每天只能合并百万级增量数据的限度。通过简略的 update 语句，咱们可能轻松将增量数据同步至 StarRocks。外部通过高效的数据更新策略，咱们可能迅速实现数据更新操作。 目前，线上大多数表都曾经应用了主键模型稳固运行着。
4. 劣势四：反对局部列更新，大幅升高保护工作
在 Hive 数仓中，更新单条数据或局部列的操作是绝对简单的，只能通过创立长期表进行 insert into 或是 insert overwrite 整表笼罩。这对于须要频繁更新单条数据或局部列的财务非公开数据而言，保护工作十分繁琐。
然而，一旦咱们将财务非公开数据迁徙到了 StarRocks 的存算拆散架构下，就可能轻松实现对单个企业的财务数据进行单条数据的更新，或是在财务统计口径变动时对整表进行局部列的更新。 这种形式保护起来十分不便，大大提高了数据的加工效率。
5. 劣势五：架构简略易运维
原先的大数据平台涵盖了许多组件，如 Spark、Yarn、Hive、Trino、Zookeeper 和 HDFS 等，简单的架构加上人力的缓和，整个零碎的保护变得异样简单和繁琐，令人应接不暇。然而，引入 StarRocks 后，整个架构失去了显著简化。StarRocks 仅包含 FE 和 BE 这两个外围组件，并且在存算拆散版本中，只依赖一个内部对象存储服务（例如 OSS）。相比存算一体架构，存算拆散架构也并未引入额定的组件，运维起来极其不便。
6. 劣势六：社区沉闷
自从 StarRocks 3.0 版本推出后咱们就开始着手测试，从测试到上线只用了短短 3 个月的工夫。值得一提的是，社区在问题响应方面的速度十分迅速。咱们遇到问题后，通常只需在社区群里发问，基本上当天就能失去解决方案并修复问题。令人惊喜的是，咱们还发现社区在存算拆散的性能和性能方面迭代速度极快。从 3.0 版本刚推出到 3.1 版本的主键模型根本成熟，每个版本都为咱们带来了惊喜。因而，接下来咱们也打算亲密跟进社区的迭代步调，以便为业务带来更大的价值。
StarRocks 存算拆散实际
借由引入 StarRocks，咱们胜利地取代了原有的大数据集群，以 StarRocks 对立了整个大数据平台。通过存算拆散业务数据依然存储在低成本的对象存储中，计算节点则能够依据业务需要随便进行扩容和缩容。
（StarRocks 存算拆散版本 & 配置信息）
1. 历史数据迁徙
首先，咱们在 StarRocks 创立主键模型表，并设定按天动静分区。为了实现 ODS、DWD、DWS 和 ADS 层的历史数据迁徙，咱们通过 Broker Load 工作间接从 OSS 读取 ORC 文件并同步到 StarRocks 中。Broker Load 工作导入速度非常惊人，屡次导入操作的平均速度达到约每秒 70 万条数据。
导入样例 – 生产 Broker Load：
导入一张 3.2 亿数据量的业务表，耗时 433 秒。
2. 增量数据更新
针对增量数据，咱们以前是创立 Hive 的 JSON 格局表，并将 FTP 中 T+1 增量的 JSON 间接传输到 OSS 中。目前，咱们通过 Python 代码实现了将每个表的增量 JSON 文件通过 Stream Load 事务接口写入 StarRocks 的主键模型表。当遇到 JSON 文件过大时，咱们会提前切割 JSON 文件再写入，确保每个文件大小不超过 10GB。咱们同时使用了 4 个并发的 Stream Load 工作，导入的平均速度大概是每秒 6 到 7 万条数据。
导入样例 – 生产 Stream Load：
下图所示，咱们导入了一个 3.3GB 的 JSON 文件，总数据量 244 万条，导入耗时 37.4 秒。
3. ETL 工作转化
因为 StarRocks 兼容 MySQL 协定，咱们将原有的 SparkSQL 革新成类 MySQL 语法，关联查问再以 insert overwrite 的形式从全表操作转变为只波及 T+1 分区数据进行关联写入指标表。在 Dbeaver 中应用 MySQL 驱动即可查问 StarRocks 中的存算拆散表，加工逻辑筹备好后放入调度平台 T+1 执行即可。咱们还应用异步物化视图来代替一些长期表，以减速查问过程。
4. 大数据量查问写入优化
- 算子落盘 + 分区裁剪优化：在大数据量查问中，初期数据量太大常常导致 BE 因为 OOM 失败。通过开启新版本的算子落盘性能，同时进行分区的裁剪优化，无效放大了数据查问范畴，原来的大查问再也不会呈现问题了。
- 物化视图减速查问：对于数据治理过程中须要应用的长期表，或者是那些查问频率高、耗时长的查问，能够构建异步物化视图，在关联查问中能够无感知进行查问减速。
- 聚合模型优化指标统计：明细数据通过轻量汇总统计写入聚合模型表，升高统计延时。原来须要小时级别聚合的指标升高到秒级聚合。
存算拆散的三步布局
咱们在 StarRocks 存算拆散架构下依照三个步骤进行大数据架构的调整，其中第一和第二阶段皆已上线：
1. 第一阶段：
应用 StarRocks 来构建指标标签和企业画像零碎（StarRocks 作为 ADS 层应用）。 咱们的数据将被积淀并展现在 BI 报表上。具体操作是将指标和标签数据通过 Hive Catalog 计算，而后将汇总数据写入 StarRocks，而明细数据则通过异步物化视图形式写入 StarRocks。最终，BI 报表将连贯到 StarRocks 数据源来读取数据。此时，大数据集群与 StarRocks 共存。
2. 第二阶段：
在新的数据需要场景应用 StarRocks 进行数据开发、计算存储。在开发过程中逐渐相熟 StarRocks 的相干个性以及调优性能。
第一 + 第二阶段（已上生产）：
应用 StarRocks 存储指标、标签以及画像输入到 HBase 以及 BI 报表，局部代替 Trino 即席查问，并通过 Hive catalog+ 异步物化视图将 Hive 数据导入到 StarRocks 中。
3. 第三阶段（布局中）
弃用大数据 CDH 集群，整体数据链路组件只有 Kafka、Flink 和 StarRocks。
后在第三阶段，咱们打算用 StarRocks 替换掉现有的大数据集群，实现极速对立的湖仓一体架构。数据存储和计算拆散，存储层在 OSS 中，而计算节点能够依据业务须要任意扩缩容。这样一来能够防止集群组件繁多，保护麻烦的问题。
总结
自 StarRocks 社区推出 3.0 版本以来，咱们便在生产环境中开始应用它。StarRocks 取代了原有的多套计算引擎，性能优异，架构简略清晰，运维不便。
通过应用 StarRocks，咱们胜利地对立了数据管理与剖析，让经营、算法和数据开发团队可能共享同一份数据，这突破了数据壁垒，同时也确保了数据更高的一致性。
StarRocks 同时反对主键模型和聚合模型，能够满足绝大多数业务需要。为增量数据创立主键表，原先数小时合并的工作，缩短至十几秒的 Stream Load，极大的晋升效率的同时简化了开发人员累赘，用户体验十分杰出。
咱们实现了与 Hadoop 生态的无缝对接，从 Hadoop 平滑迁徙到 StarRocks 集群，无需依赖内部组件，极大中央便了用户的应用。
StarRocks 在查问性能方面体现十分优越。相较于 Spark，StarRocks 以近乎实时的查问性能为代价带来了更低的机器老本，从而大幅晋升了查问效率。StarRocks 在许多场景下进行了优化，包含 Colocate Join、CBO 和 Bitmap 等个性。
最初，欢送大家多加利用以下资源理解 StarRocks 存算拆散：
- 云原生湖仓第二期 Meetup –“StarRocks 存算拆散技术摸索”
- 实测后果公开：用户见证 StarRocks 存算拆散优异性能！
- 兼顾降本与增效，咱们对存算拆散的设计与思考
- StraRocks 3.1 下载地址：https://www.mirrorship.cn/zh-CN/download/community
- 存算拆散专属探讨群：
