大厂自建：埋点平台为什么最后都长成“数据基础设施”

中国大厂很少把“埋点分析”做成一个独立产品。字节的入口叫流量平台，B 站叫北极星，网易云音乐叫全链路埋点管理平台，京东没有统一平台名，公开的是“流量数仓”。名字各异，骨架却趋同：上面是漏斗、留存、路径，中间是指标与 OLAP，下面是采集、传输、存储，贯穿始终的是一层埋点元数据。分析界面是这套系统的出口，不是主体。

这个观察有一个直接推论：大厂自建真正解决的，不是“有没有图看”，而是“这条事件是谁定义的、什么时候改的、错了谁负责、一年花多少钱”。当事件量到万亿级、业务线到上百条，后面这四个问题会比“再多一个图表”贵得多。于是平台的重心自然从报表往上游移，最后长成一套需要编制预算、划分 SLA、做版本发布的数据基础设施。

判断：大厂自建的产物是“埋点全生命周期 + 成本核算”的基础设施，分析只是它最上面的一层。判断一家公司的自建水平，看三件事就够：埋点有没有唯一权威的元数据，事件有没有版本与测试，成本有没有被货币化。

5.1 从报表到平台#

先把“自建”拆成三个世界，否则很容易把内部工具、云产品和开源项目混为一谈。

内部平台不对外售卖，买单人是业务线，收入体现为内部结算或成本分摊。字节流量平台、B 站北极星、网易云音乐埋点管理平台、京东零售流量数仓、快手 OneSQL、美团与滴滴的指标平台都属于这一类。它们的公开材料以技术博客、QCon/DataFun 演讲和公众号整理稿为主，细节多，但数字基本是自报。

能力外溢的云产品是第二类。字节把增长分析做成 DataFinder、把研发治理做成 DataLeap、把 ClickHouse 做成 ByteHouse；阿里云提供 Quick Tracking；腾讯把灯塔放到腾讯云，把零售分析做成有数；网易数帆卖有数 BI。它们有官网、文档和定价页，证据等级更高，但功能被标准化过，和内部平台不是同一套东西（DataFinder 产品页、Quick Tracking 快速接入、腾讯云灯塔、有数 BI 定价）。

技术输出与开源是第三类。滴滴把小桔棱镜（DiDiPrism）以 Apache-2.0 开源，做移动端操作回放与检测；快手把百 PB 迁移做成平台化的“星移”流程；美团、滴滴把指标平台方法论公开。它们不直接卖 UBA，但降低了后来者的自建门槛（DiDiPrism、LICENSE、快手迁移实践）。

把 11 家公司放到一条时间轴上，会看到相当一致的四个阶段。第一阶段是报表：按需求建表，一个埋点一张 Hive 表，事件没有统一模型，B 站称之为“按业务需求定制化管理”，数据只能一次性使用（B 站 2023 年分享）。第二阶段是事件模型：引入 who/when/where/what/how 的抽象，统一公共字段，SDK 收敛采集，美团的声明式埋点、字节的 Applog、B 站的 SPMID 都在这一层。第三阶段是元数据平台：埋点设计成为第一手资料，录入只是二手信息，埋点有了版本、负责人、血缘、质量规则和测试用例；字节的说法很直接——“埋点设计才是 single source of truth”（字节 2021 年演讲）。第四阶段是基础设施：埋点平台与实时计算、湖仓、指标平台、实验平台打通，按成本、SLA、合规做分级。

判断：这四个阶段不能跳。直接买一个分析工具，等于跳过第二、第三阶段，最后一定会回到“口径对不上、埋点找不到、成本下不来”的原点。

先说明证据成色。A 级是官方文档、博客、源码与定价页；B 级是有署名讲者的演讲整理，或细节具体、可追溯的第三方整理；C 级是资料不足或只有二手转述。按此口径，美团、网易有数的部分材料是 A；字节、腾讯灯塔、B 站、网易云音乐、滴滴、京东、快手是 A- 或 B+；阿里大量依赖生态文档，记 B；拼多多是 C。等级不是给公司打分，只说明哪些数字能直接用，哪些只能当公司口径。

5.2 字节跳动：把成本算到每条业务头上#

字节的公开材料里，最值得看的不是“日增多少万亿”，而是它怎么把埋点变成一门内部生意。

平台结构分三块：埋点内容（设计、开发、验证、上线、下线）、埋点治理（成本、SLA、合规）、链路（收集、处理、订阅），治理操作台叫 ByteIO。SDK 内置管控，合规不允许的埋点在端侧直接丢弃；Event 先聚合成 Applog 再上报，HTTP 收数进消息队列，实时 ETL 完成解析、清洗、分发。自研计算引擎支持 Groovy 热加载、拓扑重构、UDF/RPC 动态化，可插拔 Flink、PyJstorm、TCE 等运行时（2021 年演讲）。

规模数字能说明这套系统的量级：2021 年覆盖 2000+ 应用、20 万埋点、日增事件万亿级；2023 年峰值 1 亿+/秒、日增 10 万亿、HDFS 日增 10+PB。这些是公司自报口径，且“万亿/天”包含重复上报与多端，不能直接换算成唯一事件数（字节 2021、字节 2023）。

真正难复制的是治理链路：无用埋点下线 → 埋点分级 → 采样上报 → 自动治理，每一步都有平台入口和可计算的收益。公开口径是 2021 年下线无用埋点省近亿元、分级存储省 100+PB；2022 年采样省 3000+ 万元；监督式治理当年再省 4000 万元。无监督式治理把长尾业务的无用埋点占比从 60% 降到 20%（2023 年成本治理分享）。

这套治理能运转，靠的是四个可被业务看懂的指标：埋点上报总量、埋点成本、无用埋点占比、埋点密度（上报总量 ÷ 用户活跃时长）。埋点密度比总量更有解释力——用户时长没涨、上报量疯涨，基本就是埋点失控。字节的另一个经验是“治理不能靠运动”：业务不会主动看指标，所以要把人工发起改成系统监测、推送、负责人确认，监督式治理每两个月跑一次。

对外，字节把经验拆成三个产品：DataFinder 做增长分析与广告监测，DataLeap 做研发治理，ByteHouse 做分析型数据库（DataFinder 事件分析、广告监测、DataLeap、ByteHouse）。但三者都没有公开单价，属询价型；内部平台与对外产品是否同源、同代码，公开材料没有说明。

5.3 阿里巴巴：资产是编码体系，不是平台#

阿里对这件事的贡献，主要不在某个平台，而在三套编码：UT 解决“怎么声明和上报”，SPM 解决“位点怎么编号”，黄金令箭解决“日志按什么规范采集”。再往上，OneData 解决“指标怎么定义”。四件事拼起来，才是阿里系的埋点与指标体系（UT 接入文档、OneData 整理）。

UT 用声明式属性（ut-click、ut-visit、ut-data 等）把埋点写进 HTML，减少业务代码侵入；SPM 把页面、模块、位置编成层级位点（spm-a/b/c）；黄金令箭用类似 /lemon.track.module 的编码标记采集点。三者共同的思路是：让埋点在写代码之前就有一个可读、可复用、可定位的名字。

对外产品 Quick Tracking 的接入顺序很讲究：先定指标体系、再录事件与属性、最后才接 SDK（快速接入）。它支持事件分析、漏斗、留存、分布、间隔、session、路径、可视化与归因（埋点 API 文档）。文档 2025-06 仍在更新，但公开定价页缺失，国内项目仍以询价与部署方案为主。

OneData 的方法论影响更长远：原子指标、派生指标、复合指标，配合 ODS/CDM/ADS 三层建模，把“指标”从报表里抽出来变成可复用的定义。不过公开材料多为第三方整理，像“3000+ 质量规则”这类数字无法独立核实；Quick Tracking 与内部 UT 体系是否同源，官方也没有明确说明。

5.4 腾讯：两条产品线，一个融合引擎#

腾讯的公开材料里有两个容易混淆的产品。灯塔是“全场景大数据分析套件”，官方称由腾讯 50+ 业务自 2018 年以来使用的数据中台演化而成，日均数十亿条数据、服务数千名业务员工；有数面向智慧零售，做经营、渠道、客群与营销分析（腾讯云灯塔 2024-10、有数用户指南）。前者是分析平台，后者更接近零售商的经营工具，不能当成同一个东西。

灯塔的能力面很宽：数据上报接入、开发治理、敏捷分析、可视化、用户行为分析、画像、自动化运营、机器学习、A/B 实验。底层是融合分析引擎——Calcite 做统一 SQL 前端，Presto/Impala 做 MPP，ClickHouse 做 BI 抽取加速，Alluxio 做缓存，Kudu 做存储，再加 WLM 负载管理和物化视图（融合引擎 2023）。时效被明确分层：实时统计约 1 分钟可见，基础概况与时段分布约 2 小时，画像按月计算（腾讯云灯塔）。这个分层值得抄：不同问题需要不同新鲜度，不必都塞进同一条实时链路。

有数的数据模型是另一条线索。它用 Object 模型（type、props、from、tracking_id），其中 tracking_id 是会话级 uuid，用于行为追溯与数据恢复；再用 idmapping 融合线上、线下用户（有数数据上报）。这是零售场景逼出来的设计：门店、导购、线上账号本来就不是一套 ID。

限制同样明显。灯塔 FAQ 里“覆盖 7 亿终端”的说法没有标日期（灯塔平台介绍），属于旧数据，不能当作 2026 年的现状；融合引擎文章停在 2023 年；灯塔与有数的内部埋点治理（元数据、版本、成本）几乎没有公开。腾讯公开的是“引擎能力”和“行业模型”，不是“怎么管埋点”。

5.5 美团与滴滴：采集和语义，分成两层做#

美团没有统一对外的埋点平台品牌，公开的是前端埋点体系、指标平台与 BI 三条线。2017 年，美团把埋点分成代码埋点、声明式埋点、无痕埋点三类并存。无痕埋点通过控件 ID、类名、父组件 Index 生成事件标识，配置后台维护映射并动态下发；官方称这套方案让埋点成本降低 80%、上线后无埋点故障（2017 年实践）。同一篇文章还给了一个冷静的判断：无痕埋点只能覆盖约 70% 的需求，剩下 30% 仍要声明式或代码埋点。2019 年的 MTFlexbox 把埋点类型做成 Tag 属性写进布局文件，双端一份配置，支持可视化圈选，让布局与埋点解耦（2019 年探索）。这是客户端工程思路：把埋点从“运行时补救”变成“编译期声明”。

2026 年的公开复盘则把重心移到语义层。美团基本否定了“数据集驱动的敏捷 BI”：百万级数据集带来口径混乱、性能不可控、指标无法跨集复用。新一代架构以指标平台为核心，用自动语义把业务语言翻译成逻辑表达，用智能物化做预计算，用多引擎路由做查询降级。规模口径是百余业务线、万级模型、十万级指标维度，日查询百万级、第三方 API 千万级/日，成功率 99.9%，Ad-hoc P90 分钟级、Serving P90 秒级（2026 年 BI 实践）。文中还给出云器 Lakehouse 对比 Trino 千核集群约 2 倍性能的双跑评测（84 张表、1000+TB 数据），但这是厂商合作场景，需打折看。

滴滴走的是另一条路：先把指标定义标准化，再把消费统一。指标字典阶段发现它只是“线上 wiki”，于是升级成带权责、审批、自动命名的指标管理工具，支持原子、派生、计算、复合指标；原子指标或修饰词变更，下游派生指标自动级联变更；T1 核心指标变更需要数据管理员与业务板块管理员双审批。最后用统一查询 DSL 和数据虚拟化收口各数据产品，走 headless BI 路线（2024 年指标标准化）。

端侧，滴滴把小桔棱镜开源，做操作回放、操作检测与数据可视化，基于自研的操作行为标识指令与 DSL，license 是 Apache-2.0（仓库、README）。它把“回放”定位成埋点的补充证据，而不是替代品。存储侧，滴滴数据湖用 Apache Ozone，ASF 博客称支撑数百 PB（ASF 博客）；但这是存储规模，不是事件量，两者不能混用。

判断：美团和滴滴代表同一种分工——采集层负责“采得全、改得动”，语义层负责“口径统一、定义即研发”。两层分开，才有可能让指标平台不被埋点的历史包袱拖住；合在一起，最后往往是一张谁也说不清的表。

5.6 小红书、B 站、快手：三种瓶颈，三种答案#

这三家公司的公开材料，恰好对应三种不同的自我诊断。

小红书诊断的是查询。它原来用自研存算分离的 ClickHouse，遇到三个问题：排序键随分析习惯失效、多表 Join 受限、取数方式单一。于是转向 Iceberg + StarRocks：单分区数据量从年初 100 亿行涨到 200 多亿行，用 10 个桶做分桶表支撑大表 Join，P90 查询提升 3 倍、稳定在 10 秒以内，存储相比 ClickHouse 存算分离版本减少一半。后续又用 StarRocks 审计日志推断排序列、异步跑 ZOrder 做“排序键保鲜”，DataCache 让 P90 再提升约 20%，大查询用 EXPLAIN ESTIMATE 预判并路由到小集群或 Spark（2025 年湖仓跃迁）。

这笔账算得细，但要看边界：P90 提升 3 倍是特定数据集与查询场景，不能外推；文章经 StarRocks 社区渠道发布，带厂商视角；小红书只公开了分析层，埋点采集、元数据、治理没有细节。它回答的是“分析引擎怎么换”，不是“埋点平台怎么建”。

B 站诊断的是元数据。它做了 SPMID 五段式命名（business_id、page_id、module_id、position_id、埋点类型），事件 ID 本身就是语义，例如 bili.homepage.top-tabbar.0.click。属性分三层：全局公共字段、类型通用字段、业务私有字段。元数据里记录命名规范、数据类型、空值/枚举/默认值、版本、优先级和安全等级（S/A/B/C/D）（2023 年埋点标准化）。

工具侧，北极星管埋点创建、属性管理、上报时机、抽样比例和远程停止采集；测试支持扫码连接、实时校验、可视化报告；分析用 ClickHouse，承接日增千亿级数据，一周数据量到万亿级（原文口径，是否含副本待核实）。B 站对曝光类埋点按 1%、10%、20% 采样上报，并把采样率记进元数据，分析时再还原。流程上，B 站把埋点当软件工程治理：DRD 需求文档、六环节四角色、版本与 DIFF、从元数据生成测试规则、分级存储。分享者明确短期不做对外 SaaS。局限也在这里：材料停在 2023 年，两篇官方专栏（埋点分析平台、ClickHouse 实践）在本次抓取中被风控拦截，只能确认标题与链接，正文未获取。

快手诊断的是迁移。它把百 PB 数据、200+ 集群、数千张表从 ClickHouse 迁到 Doris/Bleem：OneSQL 做查询透明路由与灰度，星移做 DDL 转换、任务复制、存量迁移、数据校验、SQL 回放、灰度切换和 ClickHouse 下线，KwaiFlow 做离线调度，SeaTunnel 做 ETL。迁移期双写双跑，Hive→ClickHouse 走 T+1/小时级覆盖，Kafka→ClickHouse 走分钟级（2026 年迁移实践）。

效果被拆成可验收的工程指标：单表人工操作从 8 小时降到约 5 分钟，任务复制 1 分钟内完成，存量导出约 1GB/s，双跑/补数任务约两天内启动、整体补数约 10 天。日均查询 20 亿次以上。长期目标是把底座收敛成统一多模湖仓，承载指标查询、即席分析、向量检索和面向 Agent 的自然语言分析。同样要标注：文章由 SelectDB 社区转载，带 Doris 厂商立场；“20 亿次/日”是查询量，不是事件量；快手的埋点采集与治理没有公开。

判断：三家公司给出的答案不同，但方法一致——先把瓶颈说成一个可测量的工程问题，再选组件。反过来，先选组件再找理由，最后都会变成一次昂贵的迁移。

5.7 京东、拼多多、网易：资产、黑箱与配置管理#

京东的公开材料最像“数据资产”这四个字。它原来按端（主站 App、M、PC、微信、垂站）和时效（实时/离线）分裂出 40+ 模型，统一后收敛为 4 个逻辑模型（曝光、点击、浏览、订单）、8 个实体模型。埋点解析 SDK 把 shp 映射为 shop_id、rtm 映射为 receive_ts，下游不再解析原始 JSON；Flink 集成解析 SDK，写入 JDQ，再写 Hudi，保证 Exactly-Once（2025 年流量资产湖仓）。

成本账也具体：Lambda 双链路每年多花约 100 万元计算资源，小时级加工又增加近 40 万元存储/计算；改造目标是分钟级可见、存算成本低于原表。曝光口径同样可操作——“单坑位 50% 露出 + 300ms 停留，且只上报页面内第一次曝光”，2024-03 起用 IntersectionObserver 改造（京东开放平台数据上报）。

局限是缺一个平台名。没有统一品牌，就很难判断这套东西是长期产品还是项目制交付；采集侧细节也少。但它证明了一件事：埋点语义统一最终会落到表模型上，40+ 变 4 个逻辑模型，比任何“治理规范”都更能约束下游。

拼多多在本次检索范围内没有公开工程材料——官网、技术博客、QCon/DataFun/InfoQ、GitHub 都没有。所以本章不写它的平台名，也不猜架构。这个空白本身就是结论：一家公司的自建能力可以很强，但完全不在公共知识里；任何“拼多多用了某架构”的说法，没有一手来源就应视为传闻。

网易的答案最有“软件工程”味道。云音乐的曙光埋点做多端一致的对象树、统一自动化埋点和链路追踪；管理平台把埋点元数据按版本管理：客户端每个大版本从 Master 拉出需求组，变更列表包含新增对象、新增血缘、修改参数、删除对象、删除血缘，支持部分变更上线；跨空间用“桥梁”对象挂载子空间埋点树。再配实时校验、线上稽查和代码模板，官方称线上埋点错误数下降 95%（2023 年全链路埋点平台）。

这几乎是把 Git 的工作流搬到埋点上：需求组是分支，DIFF 是变更集，rebase 解决“埋点停在开发分支、上线已过期”，桥梁解决多空间复用。它不需要大模型，只需要承认埋点是一种会演进的代码资产。

商业化侧的有数 BI 是另一回事。它支持 30+ 数据源、拖拽建模、报告/大屏/填报、指标异动分析与预警（有数个人版），定价也公开：个人版永久免费（1 个创作者），高级版 988 元/年/创作者，旗舰版 3888 元/年/创作者，阅览者 988 元/年，MPP 扩容 1G=10 元/年，私有化询价（有数定价）。但它是 BI，不是 UBA，不能当成同一产品；云音乐平台文章停在 2023 年，文末“贡献到开源社区”的承诺是否兑现，待核实。

5.8 横向对比与共性架构#

先看证据，再看结论。

再看“对外产品”和“内部平台”的边界。这是中国案例最容易被误读的地方：云产品页上的功能，不等于内部平台的全部；内部平台的复杂度，也不等于客户能买到的东西。

判断：能力可以外化，组织不能。客户能买到 SDK、看板、权限和计费，买不到“数据产品经理写 DRD、业务线认领埋点、平台方按成本结算”这套组织安排。把云产品当内部平台来对标，是选型时最常见的错位。

把它们压成五层，会看得更清楚。

五层里，第四层最容易买，第二层最难建。多数自建失败不是查询引擎撑不住，而是元数据没有成为唯一权威，导致第一层采上来的东西没人敢用。这个顺序，比任何组件选型都重要。

存储路线可以再压成四种。它们不是“谁更快”，而是“哪类负载放在哪一层”。

治理机制有六个，每家都能对上几项：设计即源头（字节，测试规则可从设计生成）、命名即语义（B 站、阿里，ID 可读可定位）、元数据版本化（网易云音乐，错误数下降 95%）、规则化测试（B 站、网易、字节，从元数据生成校验规则）、分级与采样（字节 P0/P2 的 TTL/SLA，B 站 1%/10%/20%）、血缘与成本（字节、滴滴、美团，按业务核算、评估变更影响）（字节 2023、B 站 2023）。

架构上也有共性。控制面是埋点元数据：定义、版本、owner、采样率、安全等级、血缘；数据面是采集网关、消息队列、实时 ETL、明细湖仓、OLAP、指标语义、分析 API。两边通过“下发”和“回写”连接：元数据下发到 SDK 与校验规则，运行时的质量、成本、血缘再回写到元数据。看起来像一条直线，实际是一个环——没有回写，元数据很快会与现实脱节。

埋点设计（元数据 / 版本 / owner）
        │ 下发
SDK / 服务端 API ──► 采集网关 ──► MQ ──► 实时 ETL ──► 明细湖/仓 ──► OLAP ──► 指标语义 ──► 分析 / API
        │                            │                              │
        └── 采样 / 分级 / 合规丢弃 ───┴── 血缘 / 成本 / 质量 ─────────┘

组织是最后一层，也最难外化。大厂通常有四类角色：平台团队做 SDK、采集、引擎、OLAP 与指标平台；数据产品经理写 DRD、管元数据、做评审验收；分析师消费指标并反馈口径；每个埋点有 owner。中型公司的缺口往往不是工具，而是第二类角色不存在——需求直接给开发，埋点没有主人，离职即失传。

5.9 对中型公司的可复用 pattern#

不需要 11 家公司的全部能力。可迁移的部分，是七个 pattern。

一，把埋点设计变成第一手资料。 字节的经验是，录入是第二手甚至第 N 手信息，设计才是源头；设计阶段就把类型、必填、枚举、取值范围定好，测试规则和代码模板都能自动生成。中型公司不必一上来做设计工具，但必须有一份机器可读的 tracking plan，而不是 Word 文档。

二，命名即语义，但别过度设计。 B 站的五段式可读性最好，代价是设计成本高，所以他们做了快速复制、一键导入、维表化下拉；阿里的 SPM 更适合页面型业务；字节的 bid/lab 更适合客户端控件。选一种，坚持三年，比每年换规范更重要。

三，属性分三层，别平铺二十个 param。 全局公共字段、类型通用字段、业务私有字段，是 B 站验证过的结构；美团的 lab 是业务字段的容器。平铺参数的扩展性差，后期治理成本高。

四，元数据要像代码一样版本化。 网易云音乐的 rebase、DIFF、桥梁，解决的是“埋点停在开发分支、上线时已经过期”；B 站的 DRD 加六环节四角色，解决的是“多方对不齐”。这两件事都不需要大模型，只需要把埋点当代码管。

五，测试规则从元数据生成，而不是人肉验收。 字节用设计约束生成测试用例，B 站用元数据生成 DQC 规则、测试机扫码后实时匹配，网易把实时校验做成上线卡点。这是投入产出比最高、也最容易被跳过的一环。

六，把成本货币化，再谈治理。 字节给业务看四个指标：上报总量、成本、无用埋点占比、埋点密度。中型公司算不出精确成本，也可以用“事件数 × 单价 × 保留天数”做一张估算表，先让业务看见钱。

七，指标层是长期归宿，但要先有事件层。 美团的指标平台建立在标准明细模型与统一聚合模型上，滴滴的 headless BI 建立在指标定义标准化、逻辑模型隔离、统一查询 DSL 上。没有事件层治理，指标层只是把混乱往上再堆一层。

按 6 个月、3–5 人算，可以把范围压到五件事。下表是裁剪建议，验收信号由本报告给出，不是大厂标准。

六个反模式，都能在公开案例里找到反证。

• 平台名先行：先起“XX 数据中台”的名字，再找团队填功能。大厂的平台名是事后总结，不是事前目标。
• 全埋点替代设计：美团 2017 年就说过无痕埋点只覆盖约 70% 的需求；把全埋点当默认，等于把治理成本推到未来。
• 只做报表，不做元数据：报表能交差，但回答不了“这个数从哪来、能不能改、下线影响谁”。
• 治理靠运动：字节的结论是业务不会主动看指标，必须系统监测、推送、负责人确认。
• 指标口径散落在 BI 数据集：美团和滴滴都踩过，百万级数据集带来的不是敏捷，是口径混乱。
• 盲目上 ClickHouse：单表快不等于多表快，排序键会随分析习惯失效，Join 和扩缩容是长期成本。快手和小红书都是用了几年才迁移。

还必须说清楚证据缺口。11 家里，字节、美团、小红书、快手、京东、网易有 2024–2026 年的一手材料；腾讯、阿里有 2024–2025 年的官方文档或产品页更新；B 站、网易云音乐的核心材料停在 2023 年；阿里缺少集团层面的官方架构文档；拼多多没有公开材料。所有“每天多少亿条/多少 PB”都是公司自报，口径不一——事件数、日志条数、查询次数、存储容量不能横向相加。组织与预算信息几乎空白：平台团队多少人、成本如何分摊、采购什么工具，公开材料很少提。

判断：可复制的是约束，不是平台。约束是“元数据必须唯一、事件必须有版本、成本必须可见”；平台只是在这些约束下长出来的形状。先有约束，再选 ClickHouse、Doris 还是湖仓，顺序反过来就会得到一套昂贵而没人敢用的系统。