云原生主键模型：高效、弹性，省钱又省心

于 2024-09-02 15:07:25 发布
阅读量614 收藏 28
点赞数 20
文章标签： 数据库 数据仓库 大数据 湖仓一体 云计算
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/StarRocks/article/details/141820373
版权

作者简介：罗一鑫，StarRocks Committer，主要负责存储引擎相关的工作。

导读：

在 StarRocks 3.3.1 版本中，我们推出了云原生持久化索引，旨在解决本地磁盘持久化索引的关键问题。本文将详细探讨其优势，并对比云原生与本地磁盘持久化索引在大批量导入、小批实时导入以及弹性调度等场景中的表现。尤其在弹性调度场景中，云原生架构使延迟性能提升至本地磁盘的 10 倍。

主键模型是 StarRocks 全新设计开发的存储引擎，其主要优势在于支撑实时数据更新的同时，也能保证高效的复杂即席查询性能。通过主键表，实时分析业务能够在最新数据上进行分析，从而实现及时决策，突破了传统 T+1 数据延迟的限制。主键表中的主键具备唯一非空约束，用于唯一标识每一行数据。如果新数据的主键值与表中原数据的主键值相同，则存在唯一约束冲突，新数据将替代原有数据。

从 StarRocks 3.1 版本开始，主键模型开始支持存算分离架构的部署模式。在主键模型的实现中，主键索引是其核心组件。主键索引保存了从主键与对应数据位置的映射关系，从而可以帮助我们实现：

  1. 在 upsert/delete 操作中对旧数据的快速标记删除

  2. 部分列更新

  3. 高并发点查加速

  4. ......

在之前的版本中，存算分离架构下支持了两类主键索引实现：

  1. 内存索引

  2. 基于本地磁盘的持久化索引

内存索引由于大量占用内存资源，目前已不推荐使用，默认转为基于本地磁盘的持久化索引。虽然持久化索引显著降低了内存开销，并提供强劲的性能，但在云原生场景下仍存在以下问题：

  1. 磁盘空间的使用与 local data cache 管理不统一，可能导致磁盘空间抢占问题。

  2. 扩缩容不够灵活。调度迁移后的 tablet，需要在新节点上重建索引，耗时长，影响实时数据导入。

  3. Compute Node 节点需挂载足够大的本地磁盘。

引入云原生持久化索引

为了解决本地磁盘的持久化索引存在的问题，从 StarRocks 3.3.1 版本开始，我们推出了云原生持久化索引，其主要优势包括：

  1. 索引文件存储在对象存储上，通过和数据文件一致的 local data cache 来做访问加速，实现缓存统一管理。

  2. 支持弹性扩缩容。调度迁移后的 tablet 只需拉取少量数据即可完成索引重建，不影响导入的实时性。

  3. 不再要求 Compute Node 节点挂载本地磁盘，减少了对磁盘空间的硬性要求，进一步降低了硬件成本。

导入性能对比

为了评估云原生持久化索引的实际性能提升，我们对比了云原生持久化索引与本地磁盘持久化索引在以下几种场景中的表现：

  1. TPCH100G 数据批量导入

  2. 订单表小批实时导入

  3. 弹性调度测试

通过对这些场景的性能测试，我们将详细分析云原生持久化索引在延迟性能上的显著提升，以及在实际应用中的优势。

测试环境

1 FE : ecs.g6.xlarge (4c 16g) - PL0
1 BE : ecs.g6.4xlarge (16c 64g) - PL1

对比版本

Version: branch-3.3-2b87854

测试场景

TPC-H 100G 数据批量导入

建表语句：

CREATE TABLE `lineitem_pk` (
  `l_shipdate` date NOT NULL COMMENT "",
  `l_orderkey` int(11) NOT NULL COMMENT "",
  `l_linenumber` int(11) NOT NULL COMMENT "",
  `l_partkey` int(11) NOT NULL COMMENT "",
  `l_suppkey` int(11) NOT NULL COMMENT "",
  `l_quantity` decimal(15, 2) NOT NULL COMMENT "",
  `l_extendedprice` decimal(15, 2) NOT NULL COMMENT "",
  `l_discount` decimal(15, 2) NOT NULL COMMENT "",
  `l_tax` decimal(15, 2) NOT NULL COMMENT "",
  `l_returnflag` varchar(1) NOT NULL COMMENT "",
  `l_linestatus` varchar(1) NOT NULL COMMENT "",
  `l_commitdate` date NOT NULL COMMENT "",
  `l_receiptdate` date NOT NULL COMMENT "",
  `l_shipinstruct` varchar(25) NOT NULL COMMENT "",
  `l_shipmode` varchar(10) NOT NULL COMMENT "",
  `l_comment` varchar(44) NOT NULL COMMENT ""
) ENGINE=OLAP
PRIMARY KEY(`l_shipdate`, `l_orderkey`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`l_orderkey`) BUCKETS 96
PROPERTIES (
"compression" = "LZ4",
"datacache.enable" = "true",
"enable_async_write_back" = "false",
"replication_num" = "1",
"storage_volume" = "builtin_storage_volume",
"enable_persistent_index" = "true",
"persistent_index_type" = "LOCAL|CLOUD_NATIVE"
);


CREATE TABLE `orders_pk` (
  `o_orderkey` int(11) NOT NULL COMMENT "",
  `o_orderdate` date NOT NULL COMMENT "",
  `o_custkey` int(11) NOT NULL COMMENT "",
  `o_orderstatus` varchar(1) NOT NULL COMMENT "",
  `o_totalprice` decimal(15, 2) NOT NULL COMMENT "",
  `o_orderpriority` varchar(15) NOT NULL COMMENT "",
  `o_clerk` varchar(15) NOT NULL COMMENT "",
  `o_shippriority` int(11) NOT NULL COMMENT "",
  `o_comment` varchar(79) NOT NULL COMMENT ""
) ENGINE=OLAP
PRIMARY KEY(`o_orderkey`, `o_orderdate`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`o_orderkey`) BUCKETS 96
PROPERTIES (
"compression" = "LZ4",
"datacache.enable" = "true",
"enable_async_write_back" = "false",
"replication_num" = "1",
"storage_volume" = "builtin_storage_volume",
"enable_persistent_index" = "true",
"persistent_index_type" = "LOCAL|CLOUD_NATIVE"
);

导入语句：

insert into lineitem_pk select * from lineitem;
insert into orders_pk select * from orders;

导入结果：

图片

订单表小批实时导入

建表语句：

CREATE TABLE tbl_pk (
  `lo_orderkey` string,
  `lo_linenumber` int(11),
  `lo_custkey` int(11),
  `lo_partkey` int(11),
  `lo_suppkey` int(11),
  `lo_orderdate` varchar(15),
  `lo_orderpriority` varchar(16),
  `lo_shippriority` int(11),
  `lo_quantity` int(11),
  `lo_extendedprice` int(11),
  `lo_ordtotalprice` int(11),
  `lo_discount` int(11),
  `lo_revenue` int(11),
  `lo_supplycost` int(11),
  `lo_tax` int(11),
  `lo_commitdate` bigint(11),
  `lo_shipmode` varchar(11)
)
PRIMARY KEY(lo_orderkey,lo_linenumber,lo_custkey,lo_partkey,lo_suppkey,lo_orderdate)
COMMENT "OLAP"
DISTRIBUTED BY HASH(lo_orderkey,lo_linenumber,lo_custkey,lo_partkey,lo_suppkey,lo_orderdate) BUCKETS 6
PROPERTIES (
"replication_num" = "1",
"enable_persistent_index" = "true",
"persistent_index_type" = "LOCAL|CLOUD_NATIVE"
);

导入语句：

curl --location-trusted -u root: -T .../fake_data$loop_file.csv -XPUT -H label:stream_load_$uuid -H "timeout:86400" -H "max_filter_ratio:0.1" http://$host_ip:$http_port/api/$database_name/tbl_pk/_stream_load

导入数据为大小7.6G随机生成的订单数据，切分为100个文件，分100次导入。

导入结果：

图片

弹性调度测试

建表语句：

CREATE TABLE tbl_pk (
  `lo_orderkey` string,
  `lo_linenumber` int(11),
  `lo_custkey` int(11),
  `lo_partkey` int(11),
  `lo_suppkey` int(11),
  `lo_orderdate` varchar(15),
  `lo_orderpriority` varchar(16),
  `lo_shippriority` int(11),
  `lo_quantity` int(11),
  `lo_extendedprice` int(11),
  `lo_ordtotalprice` int(11),
  `lo_discount` int(11),
  `lo_revenue` int(11),
  `lo_supplycost` int(11),
  `lo_tax` int(11),
  `lo_commitdate` bigint(11),
  `lo_shipmode` varchar(11)
)
PRIMARY KEY(lo_orderkey,lo_linenumber,lo_custkey,lo_partkey,lo_suppkey,lo_orderdate)
COMMENT "OLAP"
DISTRIBUTED BY HASH(lo_orderkey,lo_linenumber,lo_custkey,lo_partkey,lo_suppkey,lo_orderdate) BUCKETS 1
PROPERTIES (
"replication_num" = "1",
"enable_persistent_index" = "true",
"persistent_index_type" = "LOCAL|CLOUD_NATIVE"
);

测试过程：

  1. 首先导入数据。

  2. 停止 BE 节点，清理磁盘中的持久化索引文件和缓存，以模拟扩缩容调度后 tablet 被调度到新节点上的情况。

  3. 发起新的导入事务，该事务的耗时中会包含重建索引的时间。通过对比该事务的延迟，验证云原生索引的弹性。

测试结果：

图片

总结分析

  1. 无论是大批导入或是小批实时导入，云原生主键索引性能与本地磁盘索引性能基本持平。

  2. 在弹性调度场景中，得益于云原生的架构，云原生持久化索引的延迟性能提升达到了本地磁盘持久化索引的 10 倍。

如何使用

从 StarRocks 3.3.1 版本开始，我们支持了云原生持久化索引。要启用该功能，可以在建表语句中通过指定 persistent_index_type 为 CLOUD_NATIVE。例如：

CREATE TABLE `orders` (
  `o_orderkey` int(11) NOT NULL COMMENT "",
  `o_orderdate` date NOT NULL COMMENT "",
  `o_custkey` int(11) NOT NULL COMMENT "",
   ...
) ENGINE=OLAP
PRIMARY KEY(`o_orderkey`, `o_orderdate`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`o_orderkey`) BUCKETS 96
PROPERTIES (
"enable_persistent_index" = "true",
"persistent_index_type" = "CLOUD_NATIVE" // LOCAL | CLOUD_NATIVE
);

LOCAL

为本地磁盘主键索引（目前默认使用）。

CLOUD_NATIVE

为云原生主键索引。

建表完成后，可以通过show create table语句来确认云原生索引是否成功开启。

目前暂时不支持通过 alter table 语句来动态调整持久化索引的实现类型。

如果您当前正在使用存算分离的主键模型表，并且受到本地磁盘持久化索引的几大缺陷困扰，欢迎尝试新发布的云原生主键索引。虽然云原生主键索引仍处于早期版本，许多实现仍有提升空间，我们将持续优化和改进。您的使用反馈对我们至关重要，欢迎随时提供意见和建议，让我们一起做得更好！

点击下方链接，添加小助手，加入存算分离技术交流：
StarRocks

StarRocks_labs
关注
  • 20
    点赞
  • 踩
  • 28
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
博客
StarRocks Lakehouse 快速入门——Apache Paimon
08-15 966
Apache Paimon （后简称 Paimon）起源于 Apache Flink （后简称 Flink）的一个子项目，起初它只是 Flink 内置的 Table Store 的一个格式，经过了几年的发展后，在 2024 年成功从 Apache 软件基金会（ASF）孵化器毕业，成为正式的顶级项目。Paimon 围绕具有 ACID 特性的数据湖存储构建，支持 DML 操作， 可以完整地支持批处理和流处理。它创新性地将 LSM Tree 与湖格式相结合，具有高效的实时更新能力与 compaction 效率。
博客
Pinterest：从 Druid 到 StarRocks，实现 6 倍成本效益比提升
08-09 725
Pinterest 是一个视觉发现平台，用户可以在上面找到食谱、家居和风格灵感等创意。该平台拥有超过5亿月活跃用户，为广告商提供了重要的广告机会。广告商可以利用数据来分析用户行为，以取得更优的广告表现。Partner Insights 是 Pinterest 提供给广告商的工具，允许他们通过定制的仪表板获取实时洞察。这些洞察帮助广告商了解广告策略的效果，并进行数据驱动的调整，提高广告投资回报率。
博客
StarRocks on AWS Graviton3，实现 50% 以上性价比提升
07-18 967
基于 StarRocks 当前的优化情况和最新的测试数据来看，StarRocks on Graviton3 (C7g) 的总体性能比 Ice Lake 8375C (C6i) 实现了30%以上的综合性能提升。再结合 AWS Graviton3 自身的价格优势（C7g 相对于C6i 有 15% 的成本优化），StarRocks on C7g 相对于 C6i 可以实现 50% 以上的性价比提升。
博客
成本下降50%，腾讯音乐StarRocks存算分离大规模实践！
07-12 1061
StarRocks 存算分离替换上千节点 Clickhouse 和 Druid 集群，效率不变，成本下降50%。
博客
数仓还是湖仓？专家圆桌深度解析
07-05 853
Apache Iceberg 代表：周劲松——Apache Amoro (incubating) PPMC 成员/腾讯云专家工程师（前网易平台开发专家）Apache Hudi 代表：徐昱——Apache Hudi & StarRocks Contributor/vivo 湖仓组件研发负责人Apache Paimon 代表：王日宇——StarRocks Committer/阿里云高级研发工程师。
博客
StarRocks 3.3 重磅发布，Lakehouse 架构发展进入快车道！
07-03 1107
在 Lakehouse 架构中，缓存设计是实现高效数据处理的关键一环。对于存算分离架构来说，缓存的重要性不言而喻。无论是 Hive、Iceberg、Paimon 等外表，还是 StarRocks 存算分离的内表，缓存命中率的高低直接影响性能的优劣。在缓存命中情况下，性能已经能够追平存算一体的架构，但如何合理、稳定地将热数据保存在缓存中却是一大挑战。StarRocks 原生开发的缓存功能为用户提供了开箱即用的便捷体验。无需复杂的配置，用户即可利用强大的缓存机制提升数据处理性能。
博客
极速查询：StarRocks 存算分离 Compaction 原理 & 调优指南
06-18 1244
作者：丁凯，StarRocks TSC member/镜舟科技云原生技术负责人StarRocks 在数据摄入过程中，每次操作都会创建一个新的数据版本。在查询时，为了得到准确的结果，必须将所有版本合并。然而，随着历史数据版本的累积，需要合并的文件数量增多，这将显著降低查询效率。为了解决这个问题，StarRocks 会定期执行内部任务，通过合并历史数据版本来消除重复记录，这个过程被称为 Compaction。
博客
StarRocks x 腾讯视频：指标中台驱动湖仓一体建设实践
06-17 1056
首先来介绍一下腾讯视频相关业务背景和技术背景。最后对指标中台以及湖仓一体进行一下总结和展望。我们未来会建立以指标为中心，定义、生产、消费、质量保障为一体的指标驱动式数据消费的新模式。在指标生产部分，提供标准化配置化的生产。指标消费部分提供一次定义，多处使用。指标质量部分提供全链路全面的可观测和诊断。指标运营部分降低成本，优化指标生产消费的流程，最终形成以指标驱动的数据消费新模式。
博客
StarRocks vs. Trino: 高并发性能背后的技术优势是什么？
06-11 936
Trino（之前称 PrestoSQL）项目最初由 Meta 开发，旨在让数据分析师能够在广泛的 Apache Hadoop 数据仓库上执行交互式查询。其高效处理大型数据集和复杂查询的能力，以及多数据源连接的灵活性，使其迅速成为大规模组织的首选数据分析工具。随着时间的推移，用户对数据分析的需求不断演变。移动互联网和 SaaS 应用的兴起，实时分析变得至关重要。因此，企业需要更高性能、更高并发、低延迟的数据分析引擎来满足不断增长的数据分析需求。在这种情况下，越来越多的用户开始寻找替代方案。
博客
Data Lakehouse：你的下一个数据仓库
05-29 890
Lakehouse 兼具数据仓库与数据湖的优势，是下一代数据分析架构的演进趋势；StarRocks 是构建 Lakehouse 的最佳选择，已在微信、小红书、携程、平安银行等数十个大型企业落地实践，帮助企业实现 One data、all analytics 的业务价值。更多交流，联系我们：https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/8da64。
博客
优化数据查询性能：StarRocks 与 Apache Iceberg 的强强联合
05-23 825
Apache Iceberg 是一种开源的表格格式，专为在数据湖中存储大规模分析数据而设计。它与多种大数据生态系统组件高度兼容，相较于传统的 Hive 表格格式，Iceberg 在设计上提供了更高的性能和更好的可扩展性。它支持 ACID 事务、Schema 演化、数据版本化、隐式分区和跨引擎兼容性等功能，使其特别适合处理数据密集型的大数据分析任务。然而，Iceberg 的使用也伴随着一些挑战，如较高的上手难度、后台维护需求、性能优化和治理策略等。
博客
AI 写 SQL 真的靠谱吗？腾讯游戏在 AI+ 湖仓一体的实践
05-15 1210
作者：腾讯游戏数据技术负责人 刘岩腾讯游戏是全球领先的游戏开发和运营商，其数据团队拥有十余年、700+ 款大型游戏的数据工作沉淀。复杂的业务环境下，腾讯游戏数据团队每年需要处理超过 3 万个数据提取需求，SQL 编写需要耗费大量时间和精力，如何提升效率成为了一个关键问题。本文介绍了腾讯游戏数据团队如何通过最新的大语言模型技术，基于StarRocks构建一个高效的湖仓一体 +AI 数据管理新范式，解决游戏业务数据提取需求上痛点的实践经验。
博客
StarRocks （江）湖英雄召集令！
05-09 727
We want you！英雄们，一起建设湖仓生态吧！
博客
StarRocks 跨集群数据迁移，SDM 帮你一键搞定！
05-09 1239
告别复杂，迎接效率
博客
StarRocks x Paimon 构建极速实时湖仓分析架构实践
04-26 1621
当前 StarRocks x Paimon 的能力主要包括：支持各类存储系统，包括 HDFS 以及对象存储 S3/OSS/OSS-HDFS支持 HMS 以及阿里云 DLF 元数据管理系统支持 Paimon 的 Primary Key 和 Append Only 表类型查询支持 Paimon 系统表的查询，常见例如 Read Optimized 表，snapshots 表等支持 Paimon 表和其他类型数据湖格式的关联查询支持 Paimon 表和 StarRocks 内表的关联查询。
博客
StarRocks 实战指南：100+ 大型企业背后的最佳实践经验
04-23 955
编者荐语：本文由镜舟科技的 DBA 团队负责人景丹撰写。在过去三年中，他服务了上百家 StarRocks 大型企业用户，并总结了最佳使用方法。文章涵盖了部署、建模、导入、查询和监控五个模块。以下文章来源于小景说 ，作者镜舟科技 DBA。
博客
升级啦！探索全新 StarRocks 中文社区与高效使用秘籍！
04-17 301
眼尖的朋友可能已经注意到，StarRocks 中文社区最近换上了全新的皮肤。是的，我们 StarRocks 的聚集地升级了！🎉自成立两年半以来，StarRocks 中文社区不断壮大，现已发展成为一个拥有数万名成员的活跃社区。为了帮助大家更便捷地获取最新资讯、降低参与社区的门槛，我们对中文社区进行了一次重要的升级。
博客
StarRocks 物化视图：指标平台性能提升的新引擎
04-12 1296
在这样的背景下，StarRocks 以其卓越的性能和灵活的物化视图功能，成为了构建指标平台的理想选择。平台的复杂性增加，涉及更多指标维度和衍生方法，以及更广泛的业务服务，这使得 Kylin 构建 Cube 时的性能问题逐渐显现，特别是在 Cube 构建过程中的性能开销较大。指标平台通过简化这一流程，使得分析工程师 （analytic engineer）能够统一数据工程和数据分析的角色，从业务视角出发定义一致的指标，并通过平台自动生成相应的 SQL 查询和 BI 报表，从而提高效率和准确性。
博客
基于 StarRocks 的风控实时特征探索和实践
04-12 1086
编者荐语：金融风控特征在实时业务中至关重要，是评估和管理风险的核心指标。经过评估，滴滴最终选择了 StarRocks 作为验证选项的落地方案。通过 StarRocks 实现流批一体，成功解决了风控实时特征流批分离的难题，缩短了开发周期，实现了更快的需求交付。
博客
StarRocks 助力小红书离线数仓提效，提升百倍回刷性能！
03-26 1188
OLAP 引擎在实时数仓建设方面已经得到了广泛的应用。我们的实践证明，结合业务特点，在处理中小规模数据量时，使用 StarRocks 等分布式 OLAP 引擎替换 Spark ，承担更多的离线处理任务，可以显著提高数据仓库产出的速度和效率，达到降本增效的目的。展望未来，我们计划进一步探索 StarRocks 在湖仓一体和存算分离的应用场景，以构建更加高效、灵活的数据生产链路和自助分析产品。我们期待通过这些创新实践，能够为公司带来更强大的数据处理能力，支持业务的持续增长和决策的精准性。作者简介。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值