OceanBase统一数据底座：如何支撑3000万用户AI推荐与交易混合负载-平芜编程栈

最近在调研企业级数据库选型时，发现很多团队在评估传统数据库与新兴AI应用结合的可行性时，常常陷入两难：一方面，传统关系型数据库的事务和一致性能力是业务基石；另一方面，AI应用对向量检索、高并发实时分析的需求又迫使他们引入新的专用系统，导致架构复杂、数据割裂、运维成本飙升。

OceanBase近期公开的“灵光闪”应用实践，恰好为这个痛点提供了一个极具参考价值的答案。这个验证了3000万级用户规模的应用案例，清晰地展示了如何将一个原生分布式数据库，打造成同时支撑核心交易与智能推荐、风控等AI场景的统一数据底座。本文将深入拆解这一实践背后的技术逻辑、架构设计以及具体实现路径，无论你是正在为AI项目寻找合适存储方案的架构师，还是希望了解下一代数据库技术趋势的开发者，都能从中获得可直接复用的思路和避坑指南。

1. 背景与核心概念：为什么需要“AI数据库”？

在深入OceanBase的实践之前，我们首先要厘清“AI数据库”这个概念。它并非指一个全新的、只为AI而生的数据库品类，而是指一个数据库系统具备了高效支撑AI应用工作负载的关键能力。这些能力通常包括：

向量计算与检索：能够高效存储、索引和查询高维向量数据，这是实现相似性搜索（如图片、语音、语义搜索）的基础。
混合负载处理：在同一套数据上，既能处理高吞吐、低延迟的在线事务处理（OLTP），也能运行复杂的在线分析处理（OLAP）和机器学习推理。
实时数据管道：支持数据的实时流入、流转与更新，确保AI模型训练和推理所用数据的时效性。
弹性扩展与高可用：能够应对AI业务可能带来的数据量和查询量的指数级增长，并保证服务不间断。

传统的做法是“数据库+专用组件”（如“MySQL/PG + Redis + Elasticsearch + 向量数据库”），这种架构带来了数据同步延迟、一致性维护困难、运维复杂度高等问题。而OceanBase的实践核心在于，尝试通过一个统一的分布式数据库系统，内聚地提供上述所有能力，简化技术栈，降低总体拥有成本（TCO）。

“灵光闪”作为一个验证性应用，其场景非常典型：海量用户（3000万级）产生结构化交易数据（如订单、用户信息）和非结构化/半结构化数据（如用户行为日志、商品特征向量），需要实时进行用户画像分析、个性化推荐和风险控制。OceanBase在其中扮演的角色，就是同时作为交易记录系统和AI特征存储与计算引擎。

2. 环境与架构准备

要理解OceanBase如何支撑此类应用，我们需要先了解其基础架构和部署模型。OceanBase是一个原生分布式关系数据库，采用Shared-Nothing架构，核心组件包括：

OBServer：存储和计算节点，每个节点包含SQL引擎、事务引擎和存储引擎。
RootService：集群管理节点，负责元数据管理、负载均衡和调度。
OBProxy：智能路由代理，对应用透明，负责SQL解析和路由。

对于“灵光闪”这样的AI混合负载场景，OceanBase的部署架构需要特别考虑资源隔离和优先级调度。

2.1 部署模式与资源单元

OceanBase通过“资源单元（Resource Unit）”和“资源池（Resource Pool）”的概念来实现物理资源的逻辑隔离。这对于隔离OLTP和OLAP/AI查询至关重要。

-- 创建用于核心交易业务（TP）的资源单元，强调低延迟和稳定性 CREATE RESOURCE UNIT tp_unit MAX_CPU = 4, MIN_CPU = 4, MEMORY_SIZE = '16G', MAX_IOPS = 10000, MIN_IOPS = 10000, LOG_DISK_SIZE = '50G'; -- 创建用于AI分析业务（AP）的资源单元，强调高吞吐和大内存 CREATE RESOURCE UNIT ap_unit MAX_CPU = 8, MIN_CPU = 2, -- MIN_CPU可低于MAX_CPU，允许资源弹性 MEMORY_SIZE = '64G', MAX_IOPS = 5000, MIN_IOPS = 1000, LOG_DISK_SIZE = '100G'; -- 创建资源池并绑定到不同的Zone（可用区），实现物理隔离 CREATE RESOURCE POOL tp_pool UNIT = 'tp_unit', UNIT_NUM = 3, -- 每个Zone 3个UNIT ZONE_LIST = ('zone1', 'zone2', 'zone3'); CREATE RESOURCE POOL ap_pool UNIT = 'ap_unit', UNIT_NUM = 2, ZONE_LIST = ('zone1', 'zone2');

通过上述配置，我们将交易负载和AI分析负载调度到不同的资源池，甚至不同的物理节点组上，避免相互干扰。

2.2 数据库租户与业务隔离

在OceanBase中，租户（Tenant）是一个独立的资源和服务实例，类似于一个独立的数据库实例。我们可以为不同的业务创建不同的租户。

-- 创建交易库租户，使用tp_pool资源 CREATE TENANT IF NOT EXISTS trade_tenant RESOURCE_POOL_LIST = ('tp_pool') SET ob_tcp_invited_nodes='%', -- 允许所有IP连接（生产环境需限制） PRIMARY_ZONE = 'zone1,zone2,zone3;zone1,zone2', -- 主副本优先分布在zone1,zone2,zone3 CHARSET = 'utf8mb4'; -- 创建AI特征库/分析库租户，使用ap_pool资源 CREATE TENANT IF NOT EXISTS ai_feature_tenant RESOURCE_POOL_LIST = ('ap_pool') SET ob_tcp_invited_nodes='%', PRIMARY_ZONE = 'zone1,zone2;zone1', CHARSET = 'utf8mb4';

在实际的“灵光闪”实践中，可能会采用“一个租户，多个资源池”的模式，将TP和AP表通过Table Group或Primary Zone属性分布到不同的资源单元上，实现更细粒度的混合部署。但核心思想不变：通过资源隔离保障核心交易链路的稳定性。

3. 核心能力拆解：OceanBase如何满足AI场景需求

3.1 向量数据存储与检索：并非外挂，而是原生扩展

这是AI数据库最受关注的能力。OceanBase并未在核心存储引擎中直接内置向量索引（如HNSW、IVF），但其强大的扩展能力允许以高效的方式支持向量操作。常见的实践路径有两种：

路径一：利用BLOB/JSON类型存储向量，应用层计算相似度。对于初期或向量维度固定且查询QPS不极高的场景，可以将向量序列化后存入BLOB或JSON字段。OceanBase对JSON提供了完善的GiN索引支持，可以加速某些过滤查询。

-- 在ai_feature_tenant租户下创建商品特征表 CREATE TABLE item_features ( item_id BIGINT PRIMARY KEY, item_name VARCHAR(255), -- 将512维的浮点数向量序列化为JSON数组存储 feature_vector JSON, -- 为该JSON字段创建函数索引，用于加速基于某些标量特征的过滤 INDEX idx_category ( (CAST(feature_vector->'$.category_id' AS UNSIGNED)) ), INDEX idx_vector_len ( (JSON_LENGTH(feature_vector->'$.vector')) ) -- 示例：向量维度检查 ) PRIMARY_ZONE='zone1,zone2' TABLEGROUP='ai_tg' -- 指定该表使用AI资源池所在的TableGroup; -- 插入数据 INSERT INTO item_features VALUES (1001, '智能手机X', '{"category_id": 3, "vector": [0.12, -0.05, ..., 0.78]}');

应用层（如Python服务）从数据库中查询出向量后，在内存中计算余弦相似度或欧氏距离。这种方式简单，但受限于网络传输和单机计算能力。

路径二（更接近“灵光闪”实践）：与AI生态紧密集成，使用外部向量索引。OceanBase通过其“外部表”功能或高效的批量数据导出能力，与专业的向量数据库（如Milvus、Proxima）或AI计算框架协同。OceanBase作为“源数据真理库”和特征管理平台，向量索引作为高性能检索的加速层。

-- 1. 在OceanBase中维护特征元数据表 CREATE TABLE item_feature_meta ( item_id BIGINT PRIMARY KEY, feature_version INT, feature_checksum VARCHAR(64), export_time DATETIME, status VARCHAR(20) -- 'READY', 'EXPORTING', 'EXPIRED' ); -- 2. 定期将更新的特征向量从OceanBase导出到文件系统（如OSS） -- 可使用 ob_loader 或 程序化方式 -- 伪代码示例（Python + PyOceanBase）： import obpython conn = obpython.connect(...) cursor = conn.cursor() cursor.execute("SELECT item_id, feature_vector FROM item_features WHERE update_time > ?", last_export_time) batch_data = cursor.fetchmany(10000) # 将 batch_data 转换为向量数据库所需的格式（如numpy数组）并写入Parquet文件 # 上传至OSS

然后，由独立的向量索引构建服务消费OSS上的文件，更新Milvus等向量数据库中的索引。查询时，应用先通过OceanBase查询业务过滤条件（如“价格<1000的手机”），得到候选item_id列表，再将这个列表和查询向量发给向量数据库进行精排。OceanBase确保了特征数据与核心业务数据的事务一致性。

3.2 HTAP混合负载：一套数据，两种处理模式

这是OceanBase的强项。其存储引擎基于LSM-Tree，并实现了行列混合存储。对于同一张表，优化器可以根据查询的复杂性自动选择行存（适合点查、高并发TP）或列存（适合全表扫描、复杂聚合AP）格式进行访问。

在“灵光闪”场景中，用户行为日志表user_behavior_log可能同时用于：

TP：实时插入用户点击、购买事件（INSERT）。
AP/AI：每分钟/每小时跑一次批处理任务，计算用户实时兴趣向量（复杂聚合查询）。

-- 创建适合混合负载的表，指定行列存储属性（具体语法可能随版本变化） CREATE TABLE user_behavior_log ( user_id BIGINT, item_id BIGINT, behavior_type VARCHAR(10), -- 'click', 'purchase', 'view' behavior_time DATETIME DEFAULT CURRENT_TIMESTAMP, channel VARCHAR(50), -- 可以创建时间分区，便于管理 PRIMARY KEY(user_id, behavior_time, item_id) ) PARTITION BY RANGE COLUMNS(behavior_time) ( PARTITION p202405 VALUES LESS THAN ('2024-06-01'), PARTITION p202406 VALUES LESS THAN ('2024-07-01') ) ENABLE ROW STORAGE, ENABLE COLUMN STORAGE; -- 启用行列混合存储 -- TP类查询：快速插入和点查 INSERT INTO user_behavior_log (user_id, item_id, behavior_type) VALUES (123456, 1001, 'click'); SELECT * FROM user_behavior_log WHERE user_id = 123456 ORDER BY behavior_time DESC LIMIT 10; -- AP/AI类查询：批量分析用户兴趣 -- 计算过去一小时每个用户对各类别的点击权重 SELECT user_id, JSON_OBJECTAGG(i.category_id, COUNT(*)) as interest_weights -- 聚合为JSON特征 FROM user_behavior_log u JOIN item_features i ON u.item_id = i.item_id WHERE u.behavior_time > DATE_SUB(NOW(), INTERVAL 1 HOUR) AND u.behavior_type = 'click' GROUP BY user_id;

OceanBase的分布式优化器会将这个AP查询下推到各个存储节点并行执行列存扫描和聚合，最后在RootService上进行汇总，极大提升了分析效率。

3.3 实时数据流转：Change Data Capture (CDC)

AI模型需要新鲜的数据。OceanBase提供了多种实时数据导出方式，最常用的是通过OCP（OceanBase Cloud Platform）或开源工具oblogproxy捕获增量日志。

# 配置 oblogproxy 连接到 OceanBase 集群，订阅指定租户、数据库的增量数据 # 配置文件 config.yaml oblogproxy: server: port: 2983 datasource: - cluster_name: my_ob_cluster tenant_name: trade_tenant database_name: trade_db table_list: ["user_behavior_log"] # 订阅的表 start_timestamp: 0 # 从当前时间开始 sink: type: kafka # 输出到Kafka bootstrap_servers: "kafka-broker1:9092" topic: "ob_cdc_user_behavior"

增量数据（INSERT/UPDATE/DELETE）会实时推送到Kafka，下游的流式计算引擎（如Flink）或特征工程平台可以实时消费，计算用户实时特征并更新到特征库或向量索引中，形成闭环。

4. 完整实战案例：构建一个简化的“AI推荐数据底座”

假设我们要为一个电商推荐场景构建后端，核心需求是：1）记录用户实时行为；2）存储商品向量特征；3）实时生成用户兴趣向量；4）提供“召回+精排”的推荐查询接口。

4.1 系统架构设计

应用层 (Python/Java) <--> OBProxy <--> OceanBase 集群 | | (CDC) v Kafka <--> Flink (实时特征计算) | v Milvus (向量索引)

OceanBase：作为唯一可信数据源，存储user_profiles（用户画像）、items（商品信息）、user_behavior_log（行为日志）。
Flink：消费OceanBase的CDC日志，实时计算用户短期兴趣向量，写回OceanBase的user_latest_interest表。
Milvus：定期从OceanBase同步items表的商品特征向量，构建向量索引。
应用服务：处理推荐请求。先根据用户画像从OceanBase中做基于规则的召回（如“同城”“相似价格段”），得到候选商品ID列表，再用该列表和用户的实时兴趣向量去Milvus中进行向量相似度检索排序。

4.2 OceanBase 表结构设计与初始化

-- 在 trade_tenant 租户下创建数据库和表 CREATE DATABASE IF NOT EXISTS rec_sys; USE rec_sys; -- 1. 用户基础画像表 (TP) CREATE TABLE user_profiles ( user_id BIGINT PRIMARY KEY, city VARCHAR(50), age_group VARCHAR(10), avg_purchase_amount DECIMAL(10,2), last_active_time DATETIME, INDEX idx_city (city) ) PRIMARY_ZONE='RANDOM' TABLEGROUP='tp_tg'; -- 2. 商品表 (TP/AP) CREATE TABLE items ( item_id BIGINT PRIMARY KEY, title VARCHAR(200), category_id INT, price DECIMAL(10,2), -- 静态特征向量 (JSON格式) static_features JSON, -- 动态统计特征，由离线任务更新 click_count_7d INT DEFAULT 0, update_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_category_price (category_id, price) ) PRIMARY_ZONE='RANDOM' TABLEGROUP='tp_tg'; -- 3. 用户行为日志表 (TP/AP，分区表) CREATE TABLE user_behavior_log ( log_id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT, item_id BIGINT, behavior VARCHAR(20), extra_info JSON, log_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user_time (user_id, log_time), INDEX idx_item_time (item_id, log_time) ) PARTITION BY RANGE COLUMNS(log_time) ( PARTITION p202405 VALUES LESS THAN ('2024-06-01') ) ENABLE ROW STORAGE, ENABLE COLUMN STORAGE; -- 4. 用户实时兴趣表 (由Flink实时更新) CREATE TABLE user_latest_interest ( user_id BIGINT PRIMARY KEY, interest_vector JSON COMMENT '实时兴趣向量，JSON数组', version BIGINT COMMENT '版本号，用于乐观锁', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ) PRIMARY_ZONE='RANDOM' TABLEGROUP='ap_tg';

4.3 核心业务逻辑SQL示例

实时行为写入 (TP)：

-- 用户点击商品 INSERT INTO user_behavior_log (user_id, item_id, behavior, extra_info) VALUES (123, 1001, 'click', '{"from": "homepage", "session_id": "abc123"}'); -- 更新用户最后活跃时间 UPDATE user_profiles SET last_active_time = NOW() WHERE user_id = 123;

批量特征计算 (AP - 用于离线训练或缓存预热)：

-- 计算商品过去24小时的点击热度（用于更新items.click_count_7d） SELECT item_id, COUNT(*) as recent_clicks FROM user_behavior_log WHERE behavior = 'click' AND log_time > DATE_SUB(NOW(), INTERVAL 24 HOUR) GROUP BY item_id; -- 生成用户历史兴趣向量（简化版） SELECT u.user_id, JSON_ARRAYAGG( JSON_OBJECT( 'category', i.category_id, 'weight', COUNT(*) / total.total_actions ) ) as historical_interest FROM user_behavior_log u JOIN items i ON u.item_id = i.item_id CROSS JOIN ( SELECT user_id, COUNT(*) as total_actions FROM user_behavior_log GROUP BY user_id ) total ON u.user_id = total.user_id WHERE u.log_time > DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY u.user_id;

推荐查询接口 (混合查询)：

-- 第一步：基于业务规则从OceanBase召回候选商品 (TP+AP) -- 例如：找到与用户同城、同年龄段常买、价格带相似的商品 SELECT i.item_id, i.static_features FROM items i JOIN user_profiles up ON i.city = up.city OR i.category_id IN (用户偏好品类) WHERE up.user_id = ? AND i.price BETWEEN up.avg_purchase_amount * 0.5 AND up.avg_purchase_amount * 1.5 LIMIT 1000; -- 召回1000个候选 -- 第二步（应用层执行）： -- 将上一步得到的1000个item_id和它们的static_features（向量）， -- 与从`user_latest_interest`表查出的用户实时兴趣向量， -- 一并发送给Milvus进行向量相似度计算和精排。 -- 最终返回Top-N个商品ID给前端。

4.4 实时特征更新管道 (Flink + CDC)

这是一个简化的Flink作业代码片段，用于消费OceanBase的CDC日志，计算用户短期兴趣。

// 伪代码，基于Flink DataStream API public class UserInterestStreamJob { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); // 1. 从Kafka消费OceanBase CDC数据 DataStream<String> cdcStream = env.addSource(new FlinkKafkaConsumer<>( "ob_cdc_user_behavior", new SimpleStringSchema(), props )); // 2. 解析CDC日志，过滤出'click'行为 DataStream<UserClickEvent> clickEvents = cdcStream .map(new ParseCdcLogFunction()) .filter(event -> "click".equals(event.getBehavior())); // 3. 滑动窗口（例如，过去1小时），按用户聚合点击物品 DataStream<UserInterest> windowedInterests = clickEvents .keyBy(UserClickEvent::getUserId) .window(SlidingProcessingTimeWindows.of(Time.hours(1), Time.minutes(5))) .aggregate(new AggregateUserClicks()); // 4. 关联商品表（维表关联，从OceanBase或缓存中获取商品特征） DataStream<UserInterestWithFeatures> interestsWithFeatures = windowedInterests .connect(itemFeatureBroadcastStream) // 商品特征广播流 .process(new EnrichWithItemFeaturesProcessFunction()); // 5. 计算加权平均向量，生成用户实时兴趣向量 DataStream<UserLatestInterest> latestInterest = interestsWithFeatures .map(new ComputeInterestVectorFunction()); // 6. 写回OceanBase (通过JDBC Sink) latestInterest.addSink(new OceanBaseJdbcSink()); env.execute("Real-time User Interest Calculation"); } }

5. 常见问题与性能调优指南

在“灵光闪”这类大规模AI数据底座实践中，会遇到一些典型问题。

5.1 典型问题排查

问题现象	可能原因	排查思路与解决方案
AP查询慢，影响TP事务	资源未隔离，AP大查询占用了TP事务所需的CPU/IO资源。	1. 检查`resource pool`和`unit`配置，确保TP和AP负载使用不同的UNIT。 2. 使用`SHOW PROCESSLIST;`查看当前慢查询，并用`KILL`终止异常AP查询。 3. 为AP查询设置`SET ob_query_timeout = 300;`防止长时间运行。
向量相似度计算性能瓶颈	在OceanBase内用UDF或应用层循环计算，数据量大时慢。	1.推荐方案：将向量检索卸载到专用向量数据库（Milvus等）。 2. 如果必须在OB内计算，确保向量字段和过滤条件有有效索引，并限制计算数据集大小（先粗筛）。 3. 考虑使用OceanBase的并行查询能力，将计算分散到多个节点。
CDC延迟高	`oblogproxy`处理不过来或网络瓶颈。	1. 监控`oblogproxy`的消费延迟指标。 2. 增加`oblogproxy`实例数，并行消费不同分区的表。 3. 检查Kafka集群健康状况和吞吐量。 4. 调大`oblogproxy`的`fetch.size`等参数。
存储空间增长过快	行为日志等数据未清理，或LSM-Tree的SSTable合并不及时。	1. 对时间分区表，建立自动删除旧分区的机制。 2. 执行`ALTER SYSTEM MAJOR FREEZE;`触发全局合并，回收存储空间。 3. 检查表的副本数，非核心表可考虑减少副本（如从3副本降为2副本）。
连接数不足	AI特征计算任务或Flink作业创建大量短连接。	1. 在应用端使用连接池（如HikariCP, Druid）。 2. 调整OceanBase租户的`max_connections`参数。 3. 检查是否有连接泄漏（未正确关闭）。

5.2 性能调优建议

索引策略：
- TP类查询：为主键查询、高选择性等值查询（user_id,order_id）创建主键或唯一索引。
- AP类查询：为分组（GROUP BY）、连接（JOIN）字段创建索引。利用复合索引覆盖查询。
- 向量/JSON字段：对JSON中常用于过滤的标量路径创建函数索引（如(CAST(feature_vector->'$.category' AS INT))）。
- 谨慎使用索引：索引会降低写入速度。对于AP大表，写入前可考虑禁用索引，写入后再重建。
SQL编写规范：
- **避免 SELECT ***：只查询需要的列，特别是涉及向量等大字段时。
- 用好分区剪枝：在查询条件中带上分区键（如log_time），让查询只扫描相关分区。
- 批处理操作：对于数据导入、更新，使用INSERT INTO ... VALUES (...), (...), ...或LOAD DATA语句，减少网络往返。
- 解释执行计划：对复杂查询，使用EXPLAIN命令查看执行计划，确保走了正确的索引和分区。
混合负载资源管理：
- 使用ALTER SYSTEM SET ob_sql_work_area_percentage = 30;限制AP查询使用的内存工作区，防止挤占TP缓存。
- 通过OCP或系统视图__all_virtual_sysstat监控active_sessions,sql_exec_per_second等指标，及时发现资源热点。

6. 最佳实践与工程建议

基于“灵光闪”及类似项目的经验，总结以下工程化建议：

明确数据分层与生命周期：
- 热数据：最近几天的用户行为、实时特征。存放在OceanBase主存储，保证低延迟访问。
- 温数据：历史行为、周期性统计特征。可存放在OceanBase的列存分区或归档到低成本OSS，通过外部表查询。
- 冷数据：超过一定时间（如一年）的明细数据。定期从OceanBase导出到OSS/HDFS，释放数据库空间。确保有清晰的元数据管理，知道数据在哪。
特征管理平台化：
- 不要在应用代码中散落着生成特征的SQL。建立统一的特征注册、计算、发布平台。
- 所有特征的定义、版本、数据血缘、质量监控都应可查。OceanBase可以作为特征元数据表和特征值主存储。
向量检索架构选型：
- 评估标准：数据规模（千万级？亿级？）、QPS要求（每秒千次？万次？）、召回率与延迟的权衡、运维复杂度。
- 小规模起步：向量数据少（<百万），QPS低（<100），可直接在应用层或OceanBase内计算。
- 大规模生产：务必引入专业的向量数据库。OceanBase与其分工明确：OB管一致性、事务和业务逻辑过滤；向量数据库管高性能相似度检索。
监控与可观测性：
- 数据库层：监控OceanBase集群的CPU、内存、磁盘IO、网络IO、慢SQL、活跃会话数。设置关键指标告警（如磁盘使用率>80%）。
- 业务层：监控推荐接口的P99延迟、召回率、点击通过率（CTR）。将业务指标与数据库性能指标关联分析。
- 数据流水线：监控CDC延迟、Flink作业反压、特征计算耗时、向量索引更新延迟。
安全与权限：
- 为不同的服务或团队创建不同的数据库用户，并授予最小必要权限。例如，Flink作业用户只有SELECT和INSERT特定表的权限。
- 敏感特征数据（如用户购买力评分）在OceanBase中加密存储，或在查询时进行脱敏。
- 做好SQL审计，记录所有数据访问行为。

通过这套架构和最佳实践，OceanBase能够有效地扮演“AI数据底座”的角色，将交易系统的稳定可靠与AI系统的灵活高效结合起来，为像“灵光闪”这样的大规模智能应用提供了坚实的数据基础。这种统一数据平台的思路，对于降低系统复杂性、保障数据一致性、提升研发效率具有长远价值。在实际落地时，建议从小范围试点开始，验证性能和数据流，再逐步扩大规模。