Starrocks 主键查询和分区裁剪/bucket裁剪

Doris 全景解析:实时数仓架构、特性与选型指南 从OLAP与OLTP的边界讲起,说明实时数仓在现代数据架构中的核心地位。Doris作为MPP架构的OLAP数据库,通过FE与BE的协作、列式存储和多种索引机制,实现高吞吐的实时写入与复杂分析查询。它兼容MySQL协议,支持Routine Load、Stream Load等多种导入方式,覆盖离线批处理与实时流计算场景。在用户行为分析、实时报表、多表关联分析等场景中表现突出,但需注意其不适用于强事务和高并发点查。通过对比ClickHouse、StarRocks等引擎,帮助团队根据业务查询模型和数据更新频率做出合 阅读详情

背景

在之前的Starrocks ShortCircuit短路径的调度,我们只是提到经过了SQL优化模块,就直接进入到了发送BE阶段,其实在这里还有一个很重要的部分,就是分区裁剪和tablet裁剪,经过这两个步骤,才会发送到对应的BE节点上,也从侧面解释了StarRocks 各类索引以及存储位置详解中的主键为啥会在tablet层级(经过了tablet裁剪后,就可以直接通过主键索引获取到对应的数据),这里也顺便了解一下 分区裁剪和tablet裁剪 的实现。

分区裁剪PartitionPruneRule

  • 作用:在“分区(Partition)”维度剔除不相关的粗粒度数据集合。
  • 原理: 该 Rule 提取查询中的过滤条件(例如 WHERE pk = 123 或者 date = ‘2023-01-01’),并将这些条件(Predicate)与表的分区信息(Range 或 List)进行求交集运算。
  • 在主键查询中的表现:
  1. 如果你的表是非分区表(即整表只有一个默认分区),或者查询条件中未带上分区列,这一步会原封不动,保留全部分区或者这单一分区。
  2. 如果查询条件中包含了分区列(例如通常按时间范围分区,查询包含时间条件),PartitionPruneRule会计算出特定的值落在哪个分区,剔除(Prune)掉所有不符合条件的 Partition。
  • 收益:避免扫描几百到上千个无关的分区元数据和底层文件。
    这里的关键代码是在OptOlapPartitionPruner.prunePartitions:
 public static LogicalOlapScanOperator prunePartitions(LogicalOlapScanOperator logicalOlapScanOperator) {
        List<Long> selectedPartitionIds = null;
        OlapTable table = (OlapTable) logicalOlapScanOperator.getTable();

        PartitionInfo partitionInfo = table.getPartitionInfo();

        if (partitionInfo.isRangePartition()) {
            selectedPartitionIds = rangePartitionPrune(table, (RangePartitionInfo) partitionInfo, logicalOlapScanOperator);
        } else if (partitionInfo.getType() == PartitionType.LIST) {
            selectedPartitionIds = listPartitionPrune(table, (ListPartitionInfo) partitionInfo, logicalOlapScanOperator);
        }

这里会根据分区类型不同,选择不同的处理路径:

  • Range 分区裁剪 (rangePartitionPrune):内部利用查询中解析出的 where col1 >= ‘X’ and col1 <= ‘Y’,构建出一个 Range 过滤器,遍历所有 Partition 的区间 [low, high),找交集,交集不为空则保留这个分区。
  • List 分区裁剪 (listPartitionPrune):如果是 city in (‘beijing’, ‘shanghai’) 这种分区,它会直接找到这几个离散的分区 ID
    这里的代码和其他引擎的大同小异,读者自行查看即可

tablet裁剪DistributionPruneRule

  • 作用:在裁剪后剩余的分区中,进一步在“分桶 / 分片(Tablet)”维度精确定位数据。这个规则必须在 PartitionPruneRule 执行完成之后进行。

  • 原理: StarRocks 的分布式存储架构中,每个分区会被切分成多个分桶(Tablet),通常是通过主键 Hash 的方式来切分(即主键表的 hash distribution 配置)。
    DistributionPruneRule根据查询的分布列(Distribution columns,主键表里即对应主键字段)条件进行哈希计算。如果查询谓词给出的是主键的精确匹配等值条件(如 id = 1):规则类底层的 HashDistributionPruner 会对查询值 “1” 运行与导入时一样的数据 Hash 函数,直接计算出该数据必然落在该分区内的**某 1 个特定的 Tablet(Bucket)**上。

  • 在主键查询中的表现: 经过这一步,原本需要在选定分区下扫描的所有 Tablet (通常会有几到几百个),会被硬核裁剪到只剩 1 个指定的 Tablet ID。

  • 收益:彻底消除无需读取的分桶 I/O 开销和分布式执行资源调度的开销。

这里只说核心部分:
以 Hash 分桶为例,关键的代码在于HashDistributionPruner.prune

public Collection<Long> prune(int columnId, HashDistributionKey hashKey, int complex) {
        if (columnId == distributionColumns.size()) {
            // compute Hash Key
            long hashValue = hashKey.getHashValue();
            return Lists.newArrayList(tabletIdsInOrder.get((int) ((hashValue & 0xffffffff) % tabletIdsInOrder.size())));
        }
        Column keyColumn = distributionColumns.get(columnId);
...
  public long getHashValue() {
        CRC32 hashValue = new CRC32();
        int i = 0;
        for (LiteralExpr expr : keys) {
            ByteBuffer buffer = expr.getHashValue(types.get(i));
            hashValue.update(buffer.array(), 0, buffer.limit());
            i++;
        }
        return hashValue.getValue();
    }

bucketId是通过如下方法获取的bucketId = (hashValue & 0xffffffff) % bucketNum ,用这个 hashValue 对 bucket 数取模,得到 bucket 序号,然后用该序号去 tabletIdsInOrder 里取对应的 tabletId
而这里的分桶算法和当初写入数据时计算的bucketId是一致的,核心代码在OlapTablePartitionParam::find_tablets():

Status OlapTablePartitionParam::find_tablets(Chunk* chunk, std::vector<OlapTablePartition*>* partitions,
                                             std::vector<uint32_t>* hashes, std::vector<uint8_t>* selection,
                                             std::vector<int>* invalid_row_indexs, int64_t txn_id,
                                             std::vector<std::vector<std::string>>* partition_not_exist_row_values) {
    size_t num_rows = chunk->num_rows();
    partitions->resize(num_rows);

    _compute_hashes(chunk, hashes);
...

void OlapTablePartitionParam::_compute_hashes(const Chunk* chunk, std::vector<uint32_t>* hashes) {
    size_t num_rows = chunk->num_rows();
    hashes->assign(num_rows, 0);

    if (is_hash_distribution()) {
        for (size_t i = 0; i < _distributed_slot_descs.size(); ++i) {
            _distributed_columns[i] = chunk->get_column_by_slot_id(_distributed_slot_descs[i]->id()).get();
            _distributed_columns[i]->crc32_hash(&(*hashes)[0], 0, num_rows);
        }
    } else if (is_random_distribution()) {
        uint32_t r = _rand.Next();
        for (auto i = 0; i < num_rows; ++i) {
            (*hashes)[i] = r++;
        }
    }
}

对于这里的Hash算法,采用的是CRC32,和tablet裁剪的时候是一致的:

  • 单列分桶:hash = CRC32(col)
  • 多列分桶:hash = CRC32( CRC32(0, col1), col2, … )(按列顺序累积)
多维聚合实战:从SQL到Pandas的动态聚合心法 多维聚合是现代数据分析的核心能力,本质是基于维度建模对数据进行可复用、可钻取、可交叉的分组聚合操作。它超越传统GROUP BY的静态汇总,融合OLAP的Roll-up/Drill-down思维与轻量级工具链的工程实践。技术价值在于统一数据口径、支撑自助分析、实现秒级响应,广泛应用于BI看板构建、用户留存分析、营销归因建模等场景。本文聚焦多维聚合与数据操作两大核心,详解如何通过维度建模、动态聚合流水线和伪Cube设计,在不依赖重型OLAP引擎的前提下,达成高效、准确、可维护的多维分析目标。 阅读详情

相关推荐

多维聚合中的数据变形:维度建模与度量校验实战指南

多维聚合是BI分析与数据仓库建设的核心能力,本质是围绕业务维度构建可钻取、可对比、可滚动计算的分析坐标系。其技术原理在于理解维度的层级拓扑关系与度量的数学聚合性质——如可加性、半可加性及比率度量必须重算分子分母等关键约束。正确实施能显著提升报表可信度与决策响应速度,支撑销售归因、用户行为分析、IoT时序汇总等典型场景。本文聚焦真实生产环境中的数据变形链路,涵盖维度对齐、空值治理、衍生维度构建及预聚合快照等核心环节,并结合Pandas/Spark/SQL三栈工具落地验证,解决85%以上因变形失当导致的分析偏差

chenzhuofei4155的博客 434

StarRocks实战笔记

必须指定 job_id 过滤条件。

qq_25925839的专栏 179

多维聚合实战:超越GROUP BY的七步工程化方法

多维聚合是OLAP分析的核心能力,本质是在定义好的维度空间上执行分组、汇总与坐标系级操作。其原理远超基础SQL的GROUP BY,需结合ROLLUP、GROUPING SETS、窗口函数及维度层次建模,实现动态切片、二次计算与明细回溯。技术价值在于构建可复用、可编排、可验证的数据中间层,支撑实时大屏、BI自助分析与算法建模等关键场景。本文聚焦生产环境验证的工程化路径,深入解析维度建模、粒度定义、聚合函数语义选型及结果塑形等核心环节,特别涵盖ClickHouse、Doris、Polars等主流工具在多维聚合中

weixin_34163553的博客 426

StarRocks 中 CURRENT_TIMESTAMP 和 CURRENT_TIME 分区过滤问题

方法中, 具体的实现,可以细看 PartitionPruneRule对应的方法,也就是在这个规则里会对涉及到的谓词来过滤出对应的分区,很显然因为。至于 PartitionPruneRule 则会在“Optimizer” 阶段完成 ,也就是。函数不支持常量折叠,也就是不支持在计划解析和优化阶段来计算结果。以上的 都在 “Transformer” 阶段完成的。是常量,所以能够裁剪到对应的分区中去,而。在优化算子阶段就已经计算出来了,为。在计划优化阶段就可以计算出结果。函数的 只选择了一个分区的数据。

monkeyboy_tech的博客 968

多维聚合实战:超越GROUP BY的数据语义重构与工程化落地

多维聚合是BI分析与指标体系建设的核心能力,其本质远超SQL中GROUP BY的语法层面,涉及维度对齐、度量归一与上下文注入三大语义重构过程。在真实业务场景中,时间粒度冲突、维度爆炸、稀疏填充和动态切换等挑战,常导致报表数据失真、下钻失败或性能崩溃。解决这些问题需结合列式存储引擎(如Doris/StarRocks)、维度主数据治理、时间桥接表、CUBE+GROUPING SETS填充及语义层参数化等关键技术。本文聚焦数据工程师与BI分析师高频痛点,系统梳理从清洗、对齐、计算到物化的七步实操链,并提供可落地的

weixin_30832405的博客 361

卸载重装Ubuntu22.04双系统

先说一下写此篇文章的背景吧,我在Windows下配置了三个cornerNet深度学习环境分别是cuda10.3(显卡版本太高不支持),cuda11.3(配置后偶然看到一篇说这个版本win下只能用CPU跑),最后是cuda11.1终究还是没能跑通代码,因为它的代码是在Liunx系统写的,就想着装个Ubuntu试试看,在网上看说一般软件不要装太高版本,我就下载了470版的显卡驱动,跟着步骤升级了系统内核,结果第二天开机Ubuntu就崩了,开机黑屏左上角只有一道横杠显示,只能按ctrl+shift+f5进入命令窗

编程小白的博客 8102

Kafka到Flink再到StarRocks实时链路搭建与调优避坑

实时数据链路通常由消息队列、流式计算和OLAP数据库组成:Kafka承接可回放的事件流,Flink完成Flink读取Kafka数据后的清洗、补维、聚合等数据处理,StarRocks以主键模型承接高并发点查与聚合查询。其原理在于用checkpoint和两阶段提交协调消费位点与写入事务,再通过攒批、并行度和分区分桶参数平衡延迟、吞吐与一致性。技术价值是让秒级看板、漏斗分析、明细点查和实时风控等场景获得可控的新鲜度与可恢复性。落到工程实践,关键在于Kafka Source、Flink状态与水印、写入StarRoc

weixin_33798152的博客 417

android6 usb默认文件管理,不弹RSA配对提示框

本文修改针对 高通 Android6.0.1 出user版本时 https://www.cnblogs.com/Jokeyyu/p/7424262.html http://blog.youkuaiyun.com/sinc00/article/details/44957943 diff --git a/frameworks/base/packages/SystemUI/src/com/android...

木叶风的博客 690

StarRocks极速OLAP数据库实战:从架构原理到部署优化全解析

在当今数据驱动的时代,海量数据的实时分析能力已成为企业核心竞争力的关键。面对传统Hadoop/Spark生态在复杂即席查询和高并发场景下的性能瓶颈,新一代MPP(大规模并行处理)数据库应运而生。其核心原理在于通过分布式架构将计算任务并行化,结合列式存储技术大幅提升数据压缩比与I/O效率,并利用向量化执行引擎充分压榨现代CPU的SIMD指令集潜力,从而实现亚秒级的极速查询响应。这种技术组合为实时数仓、交互式BI报表和即席分析等高价值场景提供了强大支撑。本文以StarRocks这一典型代表为例,深入剖析其如何通

weixin_33946020的博客 375

Anaconda+Pycharm安装

我提前创建好一个自己项目所需的虚拟环境。步骤是:打开终端(cmd)或者 搜索 ”Anaconda Prompt“ 并打开,输入 conda create -n pytorch python=3.9 -c。

Wang_sweet的博客 3230

UVM仿真卡住了?别慌!手把手教你定位并解决PH_TIMEOUT超时错误

本文详细解析了UVM仿真中常见的PH_TIMEOUT超时错误,提供了从错误诊断到解决方案的完整指南。通过理解错误机制、分析调试技巧和常见问题场景,帮助验证工程师快速定位并解决这一棘手问题,同时分享了预防措施与最佳实践,提升仿真效率。

weixin_28683065的博客 367

StarRocks + Paimon 实战:构建 Lakehouse 原生数据引擎的选型、调优与踩坑记录

在数据架构演进中,湖仓一体(Lakehouse)正成为融合数据湖灵活性与数据仓库性能的关键方案。其核心原理在于:底层存储使用支持 ACID 与主键更新的表格式(如 Paimon),查询引擎则通过 Catalog 直接读取文件元数据与统计信息,实现谓词下推、分区裁剪等深度优化,从而在对象存储上获得数仓级查询速度。这种模式的技术价值在于降低存储成本、统一流批链路,并支持实时更新与复杂分析并存。实际应用中,企业常面临 Hive 查询慢、ClickHouse 更新弱等痛点,而将 Paimon 与 StarRocks

weixin_32377497的博客 287

手把手教你为RK3588开发板适配RTL8211F网卡:设备树配置与PHY驱动匹配全流程

本文详细介绍了在RK3588开发板上适配RTL8211F千兆以太网PHY芯片的全流程,包括硬件原理图确认、设备树配置与PHY驱动匹配。通过实战案例和调试技巧,帮助开发者解决常见问题并优化网络性能,适用于嵌入式Linux开发中的Ethernet网络功能实现。

weixin_29184075的博客 525

StarRocks高性能分析型数据库:从向量化引擎到MPP架构的实战解析

在数据仓库与大数据分析领域,高性能查询引擎是处理海量数据实时分析的核心技术。其基本原理在于通过优化数据存储模型与计算执行路径,大幅提升复杂查询的响应速度。从技术价值看,这类引擎能够将传统数仓的秒级查询降至毫秒级,直接支撑高并发数据服务与实时决策。具体到应用场景,它广泛适用于实时大屏、交互式即席分析、在线报表等对数据新鲜度和查询延迟要求极高的业务。本文以StarRocks为例,深入剖析其实现高性能的关键:全链路向量化执行引擎通过按列批处理数据,减少虚函数调用并充分利用CPU的SIMD指令集;而新一代MPP架构

weixin_34101784的博客 479

高通SDX12:ProSLIC Si32185移植调试

高通 SDX12 语音芯片slic 音频驱动 Si32185

不秃头的程序猿Gabriel的博客 2036

基于AnimeGAN模型生成宫崎骏风格动漫照片

用于动画风格纹理和线条转换的灰度样式丢失;新颖的颜色重建损失,以保留内容图像的颜色;新的灰度对抗损失防止生成的图像从显示为灰度图像;使用深度可分卷积和反向残块的轻量级生成器,以实现更快的传输。实验表明,AnimeGAN可以对真实世界的照片进行变换场景动画风格的图像与高质量的动画视觉效果和显著优于最先进的风格化方法。# 生成宫崎骏风格图片 model = hub . Module('animegan_v1_hayao_60' , use_gpu = True)images:输入的图片数据。

优快云 精品推荐 3629

StarRocks实战复盘:从OLAP架构原理到查询调优的完整指南

在实时数仓与离线分析场景中,传统MPP引擎常面临查询延迟高、运维复杂、多表Join性能差等痛点。OLAP引擎通过MPP架构实现多节点并行计算,配合向量化执行引擎批量处理数据,显著提升聚合与排序效率。列式存储与ZoneMap索引、Bitmap索引进一步压缩扫描IO,使得亿级数据秒级响应成为可能。本文以StarRocks为核心,从分区分桶设计、数据模型选型,到Colocate Join、资源组隔离、异步物化视图等实战调优手段,覆盖实时报表、用户画像、风控查询等典型应用场景,为正在评估或已上手StarRocks的

weixin_29047545的博客 249

关于“为爱发电”的一些说明~~

专栏教学资料+工程文件

数字IC/FPGA杂货铺,找一找,或许有你想要的~ 2672

MPP/OLAP 数据库实战优化案例:从1小时到2分钟,SQL调优+存储优化+数据倾斜解决

本文总结了Greenplum数据仓库运维中的6个典型性能优化案例,涉及SQL拆解、执行计划修复、数据倾斜处理等场景。通过拆表+UNION实现30倍性能提升、合并循环JOIN减少扫描次数、更新统计信息修复执行计划、分区键对齐避免数据重分布、按倾斜字段重新分区、采用分区压缩优化存储等方案,有效解决了各类性能瓶颈。这些优化思路具有通用性,同样适用于Doris、StarRocks等MPP架构的OLAP数据库,核心要点包括:减少数据扫描和移动、优化执行计划、均匀分布数据、降低IO成本等。掌握这些分布式数据库的通用优化

m0_63960309的博客 508

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

廖雪峰Python教程[完整版]

廖雪峰的python教程整理的,已经排好版了,而且还是完整的,适合小白

Dinky+Paimon+RustFS:一套开源MySQL实时同步到数据湖仓的完整方案

在数据架构演进中,实时数据同步与湖仓一体已成为企业构建分析能力的核心诉求。Dinky作为Flink SQL开发与调度平台,Paimon作为流批一体的湖仓存储格式,RustFS作为S3兼容的分布式对象存储底座,三者组合可端到端打通从MySQL业务库到可分析数据湖仓的链路,实现低延迟、可插拔的实时同步。该方案利用CDC捕获变更,结合Paimon主键表和MOR机制,既支持全量历史追溯,又满足流式读取;同时借助RustFS降低存储运维成本,并能使Doris、StarRocks等引擎直接查询。本文从环境部署到代码实现

weixin_33816946的博客 374

Statistics and Machine Learning Toolbox

Statistics and Machine Learning Toolbox(带书签),MATLAB统计学习工具

营销自动化OLAP架构演进:从离线数仓到实时决策的实践

多源数据驱动的营销场景,常常因数据口径不一、时效性割裂而无法形成有效闭环。OLAP作为统一分析层,能整合广告平台、埋点行为、订单业务等多源数据,通过分层建模与实时计算,实现精准人群圈选与自动化触达。其核心在于理解OLAP引擎的选型逻辑、明细与聚合模型的合理设计,以及数据一致性保障机制。架构演进应从离线数仓逐步迈向准实时管道,匹配营销决策对分钟级反馈的需求,从而让数据真正转化为投放优化与自动化运营的驱动力。

weixin_34409357的博客 320

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

程序员如何应对海量数据:从单机思维到分布式分析的范式迁移

海量数据并非单纯指文件体积大,而是标志着数据访问模式、计算范式与系统约束的根本转变。当数据规模突破单机内存承载、SQL直连查询和人工验证能力的临界点,传统编程思维便面临失效——核心矛盾从‘怎么算’转向‘在哪算、谁调度、结果是否可信’。理解数据寻址替代数据持有、列存+向量化执行替代逐行迭代、分层建模替代一把梭、可观测性替代经验主义,是构建高可用分析能力的技术基石。本文聚焦程序员真实落地场景,融合DuckDB、Flink、StarRocks等现代工具链实践,解决‘pandas卡死’‘SQL突然不灵’‘报表总延迟

382

Apache Doris 实时分析数据库入门:从核心原理到单机部署实战

在数据驱动的业务场景中,实时分析数据库是支撑高并发、低延迟查询的关键技术。其核心原理通常基于MPP(大规模并行处理)架构,通过向量化执行引擎和智能预聚合等技术,实现对海量数据的快速分析,从而为实时大屏、用户行为分析和风控决策等应用场景提供即时洞察。Apache Doris作为一款现代化的实时分析数据库,正是这一技术领域的杰出代表。它凭借极简的架构、完整的SQL支持以及与MySQL协议的兼容性,极大地降低了使用门槛。同时,其丰富的生态连接能力,支持从Kafka、MySQL等多种数据源进行实时数据导入,并能无缝

weixin_30835649的博客 466

【Paimon 学习笔记 一】从 Hive 到Paimon: 大数据表发展历程

Flink SQL 系列里,订单表、城市维表、商品维表、订单宽表全都建在 Paimon 上——但一直只管用,没开过盒。第一篇先解决"为什么"。要理解 Paimon 出现的意义,得先回到它出现之前——Hive 是怎么干活的。

MaoLin Tian's Blog 501

大数据实时备份架构全解析:从CDC到Hudi的选型与落地

数据备份是保障大数据平台稳定性的基础能力,但传统定时快照往往无法满足秒级恢复需求。实时备份基于变更数据捕获(CDC)原理,通过解析数据库日志将每一次插入、更新、删除转化为持续的数据流,配合消息队列与数据湖表格式,实现任意时间点的数据回放。这一架构能有效降低RPO和RTO,支撑金融、电商等核心业务在误删或故障后快速恢复。本文从实时备份的架构定位出发,对比Debezium、Flink CDC等工具选型,深入讲解Kafka分区策略、Hudi写入优化、恢复演练及生产环境常见问题,为数据架构师提供一套可落地的参考方案

weixin_34348174的博客 171

多维聚合中的数据变形:从立方体导航到可追溯分析

多维聚合是现代数据分析的核心范式,它超越传统GROUP BY的降维坍缩,转向基于维度坐标系的结构化操作。其原理根植于OLAP立方体模型,通过roll-up、drill-down、slice、dice等几何化变形实现灵活切片与路径可溯。技术价值在于保障指标口径一致性、支撑高频业务迭代,并显著提升千万级数据下的查询响应效率。典型应用场景涵盖电商实时看板、金融反欺诈特征工程及IoT时序分析。本文聚焦多维聚合中的数据变形本质,结合Doris+Spark混合架构与维度契约建模,系统阐述如何构建可复用、可验证、可追溯的

weixin_33694172的博客 549
上一篇: Starrrocks中的 pipeline 调度的说明
下一篇: Rust 的 mod(模块) 说明
鸿乃江边鸟
博客等级 码龄6年 3746粉丝 235原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值