ClickHouse在智能运维(AIOps)中的实践：大规模时序数据处理与实时决策案例分析

元数据框架

  • 标题：ClickHouse在智能运维(AIOps)中的实践：大规模时序数据处理与实时决策案例分析
  • 关键词：ClickHouse；智能运维(AIOps)；时序数据存储；实时异常检测；根因定位；分布式OLAP；MergeTree引擎
  • 摘要：
    智能运维(AIOps)的核心挑战是大规模时序数据的高效存储与实时分析，传统存储系统（如关系型数据库、Elasticsearch）难以兼顾高吞吐写入、低延迟查询和多维度关联需求。ClickHouse作为列式存储的分布式OLAP引擎，凭借其列式压缩、分布式架构、MergeTree索引优化等特性，成为AIOps系统的核心数据存储与分析引擎。本文结合真实企业案例，从概念基础、理论框架、架构设计、实现机制到高级考量，系统阐述ClickHouse在AIOps中的实践路径，涵盖时序数据建模、实时异常检测、跨域根因定位等关键场景，为企业构建高可用、高智能的AIOps系统提供可复制的技术方案。

1. 概念基础：AIOps与ClickHouse的核心逻辑关联

1.1 AIOps的背景与核心需求

智能运维(AIOps)是通过大数据、机器学习、自动化技术，替代传统人工运维的新一代运维模式，其核心目标是降低运维成本、提高故障响应速度、实现预测性运维。
AIOps的核心数据需求可总结为四点：

  • 高吞吐写入：需处理来自监控系统（Prometheus）、日志系统（ELK）、链路追踪（SkyWalking）的大规模时序数据（如100亿条/天的指标、日志）；
  • 低延迟查询：异常检测、根因定位需实时（秒级）获取数据，否则无法及时止损；
  • 多维度关联：故障分析需关联**指标（CPU使用率）、日志（ERROR信息）、链路（服务延迟）**等多源数据，传统存储难以高效支持跨域join；
  • 可扩展存储：时序数据随时间线性增长（如保留3个月数据需存储900亿条），需支持水平扩展以应对数据量增长。

1.2 ClickHouse的核心特性与AIOps的适配性

ClickHouse是Yandex开源的分布式列式存储OLAP引擎，其设计目标是支持PB级数据的实时分析，核心特性完美匹配AIOps的需求：

ClickHouse特性 AIOps场景适配性
列式存储 时序数据（如指标、日志）的查询多为按时间范围、维度过滤（如“查询主机A过去1小时的CPU使用率”），列式存储可跳过无关列，查询效率比行式存储高10-100倍。
分布式架构 通过**Sharding（数据分片）+ Replication（副本）**支持水平扩展，解决大规模数据存储与查询的 scalability问题。
MergeTree引擎 专为时序数据设计，支持主键排序、跳数索引（MinMax/Set/ Bloom Filter），优化时间范围查询与维度过滤。
SQL支持 兼容标准SQL，降低运维人员学习成本，可直接用于异常检测、根因定位等复杂查询。
高吞吐写入 支持批量写入（如每批1000条以上），写入性能可达100万条/秒（单节点），满足AIOps的高并发数据采集需求。

2. 理论框架：AIOps中ClickHouse的第一性原理分析

2.1 AIOps数据模型的第一性原理

AIOps的核心数据是时序数据（Time-Series Data），其本质是“时间戳+维度+值”的三元组（如(2024-05-01 12:00:00, host=server1, cpu_usage=85%)）。
时序数据的查询模式可抽象为：
Q=Filter(TimeRange)∩Filter(Dimensions)∩Aggregate(Values) Q = \text{Filter}(\text{TimeRange}) \cap \text{Filter}(\text{Dimensions}) \cap \text{Aggregate}(\text{Values}) Q=Filter(TimeRange)∩Filter(Dimensions)∩Aggregate(Values)
其中：

  • TimeRange\text{TimeRange}TimeRange：时间范围过滤（如过去1小时）；
  • Dimensions\text{Dimensions}Dimensions：维度过滤（如主机名、应用名）；
  • Aggregate\text{Aggregate}Aggregate：聚合操作（如求平均、计数）。

2.2 ClickHouse的时序数据优化逻辑

ClickHouse通过MergeTree引擎的设计，直接针对时序数据的查询模式优化：

  1. 主键排序：MergeTree的主键默认包含时间戳+维度（如(timestamp, host, app)），数据按主键顺序存储，可快速定位时间范围与维度过滤的数据。
  2. 跳数索引（Skip Index）：
    • MinMax索引：存储每个数据块（Block）的时间戳、维度的最小值与最大值，查询时可跳过不包含目标范围的块；
    • Set索引：存储维度列的唯一值，如主机名的集合，查询“host=server1”时可快速定位包含该主机的块；
    • Bloom Filter索引：用于模糊查询（如日志中的关键词），减少数据扫描范围。
  3. 列式压缩：时序数据的维度列（如host）重复率高，列式存储可通过LZ4、ZSTD等算法实现高压缩比（通常5-10倍），降低存储成本。

2.3 传统存储方案的局限性对比

存储方案 高吞吐写入 低延迟查询 多维度关联 可扩展存储 适合场景
关系型数据库（MySQL） 差（行式存储，写入锁冲突） 差（索引碎片化） 一般（join性能低） 差（垂直扩展） 小批量结构化数据
Elasticsearch 中（文档存储，分词开销大） 中（倒排索引适合全文检索，但不适合聚合） 差（跨索引join性能低） 中（水平扩展但存储成本高） 日志全文检索
Hadoop（Hive） 中（批处理，延迟高） 差（MapReduce延迟分钟级） 一般（Hive SQL join） 好（水平扩展） 离线批处理分析
ClickHouse 好（列式存储，批量写入） 好（MergeTree索引优化） 好（分布式join） 好（水平扩展） 大规模时序数据实时分析

3. 架构设计：AIOps系统中的ClickHouse架构

3.1 AIOps系统整体架构

以下是基于ClickHouse的AIOps系统架构（Mermaid图表）：

数据采集层

数据存储层: ClickHouse

Prometheus: 指标采集

Fluentd: 日志采集

SkyWalking: 链路采集

分析层: 智能算法

异常检测: 3σ/LOF

根因定位: 关联分析/ML

应用层: 运维工具

Grafana: 可视化 Dashboard

Alertmanager: 告警系统

Argo CD: 自动修复

各层职责：

  • 数据采集层：通过Prometheus（指标）、Fluentd（日志）、SkyWalking（链路）采集多源时序数据；
  • 数据存储层：ClickHouse作为核心存储，存储指标、日志、链路数据，支持高吞吐写入与低延迟查询；
  • 分析层：基于ClickHouse的数据，通过异常检测算法（如3σ）识别故障，通过关联分析（如join）定位根因；
  • 应用层：通过Grafana展示监控数据，Alertmanager发送告警，Argo CD实现自动修复。

3.2 ClickHouse表设计：时序数据建模

3.2.1 指标数据模型（Prometheus）

指标数据的核心是“时间戳+指标名称+标签+值”，表结构设计如下：

CREATE TABLE IF NOT EXISTS metric_data (
    timestamp DateTime64(3) CODEC(Delta, ZSTD),  -- 时间戳（毫秒级），Delta压缩优化
    metric_name String CODEC(ZSTD),             -- 指标名称（如cpu_usage）
    tags Nested(                                -- 标签（如host、app）
        key String,
        value String
    ) CODEC(ZSTD),
    value Float64 CODEC(Gorilla, ZSTD)          -- 指标值（如85.5），Gorilla压缩优化时序数据
) ENGINE = MergeTree()
ORDER BY (metric_name, tags.key, tags.value, timestamp)  -- 排序键：优化维度过滤与时间范围查询
PRIMARY KEY (metric_name, tags.key, tags.value, timestamp)  -- 主键：与排序键一致，加速查询
TTL timestamp + INTERVAL 3 MONTH DELETE;       -- 数据保留3个月，自动删除旧数据

设计说明：

  • Nested类型：存储标签（key-value对），支持多标签查询（如tags.key='host' AND tags.value='server1'）；
  • 压缩算法：Delta压缩时间戳（时间戳递增，差值小），Gorilla压缩指标值（时序数据的变化率小），ZSTD压缩字符串（标签、指标名称）；
  • TTL：自动删除过期数据，避免存储成本无限增长。
3.2.2 日志数据模型（Fluentd）

日志数据的核心是“时间戳+日志内容+标签”，表结构设计如下：

CREATE TABLE IF NOT EXISTS log_data (
    timestamp DateTime64(3) CODEC(Delta, ZSTD),
    log_level String CODEC(ZSTD),               -- 日志级别（如ERROR、WARN）
    app_name String CODEC(ZSTD),                -- 应用名称
    host String CODEC(ZSTD),                    -- 主机名
    log_content String CODEC(ZSTD)              -- 日志内容
) ENGINE = MergeTree()
ORDER BY (app_name, host, log_level, timestamp)
PRIMARY KEY (app_name, host, log_level, timestamp)
TTL timestamp + INTERVAL 7 DAY DELETE;         -- 日志保留7天

设计说明：

  • 日志级别索引：将log_level作为排序键的一部分，加速“查询ERROR日志”的需求；
  • 短保留期：日志数据的价值随时间快速衰减，保留7天可降低存储成本。
3.2.3 链路数据模型（SkyWalking）

链路数据的核心是“时间戳+链路ID+服务名称+延迟”，表结构设计如下：

CREATE TABLE IF NOT EXISTS trace_data (
    timestamp DateTime64(3) CODEC(Delta, ZSTD),
    trace_id String CODEC(ZSTD),                -- 链路ID
    service_name String CODEC(ZSTD),            -- 服务名称
    span_name String CODEC(ZSTD),               --  span名称（如/api/user）
    delay Float64 CODEC(Gorilla, ZSTD)          -- 延迟（毫秒）
) ENGINE = MergeTree()
ORDER BY (service_name, span_name, timestamp)
PRIMARY KEY (service_name, span_name, timestamp)
TTL timestamp + INTERVAL 1 MONTH DELETE;       -- 链路数据保留1个月

3.3 分布式架构设计

为支持大规模数据存储与查询，ClickHouse采用**分布式表（Distributed Table）**架构：

  1. Sharding策略：按**指标名称（metric_name）或服务名称（service_name）**分片，确保同一指标/服务的数据存储在同一节点，减少跨节点查询的开销；
  2. Replication策略：每个分片设置2-3个副本，通过ZooKeeper实现副本同步，提高数据可用性；
  3. 分布式表定义： 
    CREATE TABLE IF NOT EXISTS distributed_metric_data
ENGINE = Distributed('clickhouse_cluster', 'default', 'metric_data', rand())  -- rand()为分片键（示例）
AS SELECT * FROM metric_data;

说明：distributed_metric_data是分布式表，底层映射到clickhouse_cluster集群中的metric_data本地表，查询时会自动路由到对应的分片节点。

4. 实现机制：ClickHouse在AIOps中的关键场景实践

4.1 实时异常检测：基于ClickHouse窗口函数

异常检测是AIOps的核心功能之一，目标是实时识别指标的异常波动（如CPU使用率突然飙升）。

4.1.1 算法选择：3σ法则

3σ法则是一种简单有效的异常检测算法，假设数据服从正态分布，异常值定义为超出均值±3倍标准差的数据点。

4.1.2 ClickHouse实现
WITH
  -- 计算滑动窗口（60秒）的均值与标准差
  movingAvg(value, 60) AS avg_60,
  movingStdDev(value, 60) AS std_60
SELECT
  timestamp,
  metric_name,
  tags.value[1] AS host,  -- 假设tags.key[1]='host'
  value,
  avg_60,
  std_60,
  -- 判断是否为异常（1=异常，0=正常）
  IF(value > avg_60 + 3*std_60 OR value < avg_60 - 3*std_60, 1, 0) AS is_anomaly
FROM
  distributed_metric_data
WHERE
  metric_name = 'cpu_usage'  -- 过滤CPU使用率指标
  AND timestamp >= now() - INTERVAL 1 HOUR  -- 过去1小时的数据
  AND tags.key[1] = 'host'  -- 过滤host标签
ORDER BY
  timestamp;

说明：

  • movingAvg：计算滑动窗口（60秒）的均值；
  • movingStdDev：计算滑动窗口的标准差；
  • tags.value[1]：获取host标签的值（假设tags.key[1]='host'）；
  • 该查询可实时（秒级）返回过去1小时的CPU使用率异常点。

4.2 跨域根因定位：基于ClickHouse关联查询

根因定位是AIOps的难点，需关联指标、日志、链路数据，找到故障的根本原因（如“应用响应时间升高是因为服务A的延迟过高”）。

4.2.1 场景描述

假设某应用的**响应时间（app_response_time）**突然升高，需定位根因：

  1. 检查该应用的**错误日志（log_level=ERROR）**数量是否增加；
  2. 检查该应用的**链路延迟（service_delay）**是否升高。
4.2.2 ClickHouse实现
-- 步骤1：查询响应时间异常的应用
WITH anomaly_app AS (
  SELECT
    timestamp,
    app_name,
    response_time
  FROM
    distributed_metric_data
  WHERE
    metric_name = 'app_response_time'
    AND response_time > 1000  -- 响应时间超过1秒（异常阈值）
    AND timestamp >= now() - INTERVAL 10 MINUTE  -- 过去10分钟
)
-- 步骤2：关联错误日志（log_level=ERROR）
JOIN (
  SELECT
    timestamp,
    app_name,
    count(*) AS error_count
  FROM
    distributed_log_data
  WHERE
    log_level = 'ERROR'
    AND timestamp >= now() - INTERVAL 10 MINUTE
  GROUP BY
    timestamp,
    app_name
) log_data
ON anomaly_app.app_name = log_data.app_name AND anomaly_app.timestamp = log_data.timestamp
-- 步骤3：关联链路延迟（service_delay>100毫秒）
JOIN (
  SELECT
    timestamp,
    app_name,
    service_name,
    avg(delay) AS service_delay
  FROM
    distributed_trace_data
  WHERE
    delay > 100
    AND timestamp >= now() - INTERVAL 10 MINUTE
  GROUP BY
    timestamp,
    app_name,
    service_name
) trace_data
ON anomaly_app.app_name = trace_data.app_name AND anomaly_app.timestamp = trace_data.timestamp
-- 步骤4：输出结果（按时间排序）
SELECT
  anomaly_app.timestamp,
  anomaly_app.app_name,
  anomaly_app.response_time,
  log_data.error_count,
  trace_data.service_name,
  trace_data.service_delay
FROM
  anomaly_app
ORDER BY
  anomaly_app.timestamp;

说明：

  • 该查询通过三次join关联了指标、日志、链路数据，快速定位响应时间升高的根因（如“应用A的响应时间升高是因为服务B的延迟达到200毫秒，且错误日志数量增加了5倍”）；
  • ClickHouse的分布式join性能优于Elasticsearch（通过协处理器实现并行join），可支持千万级数据的关联查询。

4.3 性能优化：ClickHouse的查询加速技巧

4.3.1 物化视图（Materialized View）

物化视图是预先计算并存储聚合结果的视图，可将常用的聚合查询（如“每小时的CPU平均使用率”）的时间复杂度从O(n)降低到O(1)。
示例：创建每小时CPU平均使用率的物化视图：

CREATE MATERIALIZED VIEW IF NOT EXISTS hourly_cpu_usage
ENGINE = MergeTree()
ORDER BY (host, hour)
PRIMARY KEY (host, hour)
AS SELECT
  tags.value[1] AS host,
  toStartOfHour(timestamp) AS hour,
  avg(value) AS avg_cpu_usage
FROM
  distributed_metric_data
WHERE
  metric_name = 'cpu_usage'
  AND tags.key[1] = 'host'
GROUP BY
  host,
  hour;

查询物化视图：

SELECT
  host,
  hour,
  avg_cpu_usage
FROM
  hourly_cpu_usage
WHERE
  host = 'server1'
  AND hour >= now() - INTERVAL 1 DAY;

效果：查询时间从10秒缩短到1秒（数据量越大，效果越明显）。

4.3.2 跳数索引（Skip Index）

跳数索引可快速跳过不包含目标数据的块，优化维度过滤查询。
示例：为log_data表的log_level列添加Set索引：

ALTER TABLE log_data
ADD INDEX log_level_index log_level TYPE set(100) GRANULARITY 1;

查询效果：查询“log_level=ERROR”的日志时，ClickHouse会通过log_level_index快速定位包含ERROR的块，数据扫描范围减少80%。

4.3.3 批量写入（Batch Insert）

ClickHouse的写入性能与批量大小密切相关，批量越大，写入性能越高（单节点可达100万条/秒）。
示例：用Python的clickhouse-driver实现批量写入：

from clickhouse_driver import Client
import time

client = Client(host='localhost')

# 生成测试数据（100万条）
data = [
    (time.time(), 'cpu_usage', ['host', 'app'], ['server1', 'web'], 85.5)
    for _ in range(1000000)
]

# 批量写入（每批1000条）
batch_size = 1000
for i in range(0, len(data), batch_size):
    batch = data[i:i+batch_size]
    client.execute(
        'INSERT INTO metric_data (timestamp, metric_name, tags.key, tags.value, value) VALUES',
        batch
    )

效果：批量写入的性能比单条写入高10-100倍。

5. 实际应用：某互联网公司AIOps系统案例

5.1 企业背景

某互联网公司拥有1000台服务器、50个应用，每天产生5亿条指标数据、10亿条日志数据、2亿条链路数据，传统运维模式（人工监控+Elasticsearch）存在以下问题：

  • 异常检测延迟高（5分钟以上），无法及时止损；
  • 根因定位困难（需手动关联指标、日志、链路数据，耗时1小时以上）；
  • 存储成本高（Elasticsearch存储100亿条数据需100TB磁盘空间）。

5.2 解决方案：基于ClickHouse的AIOps系统

5.2.1 系统架构

采用3.1节的架构，数据采集层用Prometheus（指标）、Fluentd（日志）、SkyWalking（链路），数据存储层用ClickHouse（3节点集群，每节点16核、64GB内存、1TB SSD），分析层用ClickHouse的窗口函数（异常检测）和关联查询（根因定位），应用层用Grafana（可视化）、Alertmanager（告警）。

5.2.2 实施效果
指标 传统方案（Elasticsearch） ClickHouse方案
数据存储成本 100TB 20TB（压缩比5:1）
异常检测延迟 5分钟 1秒
根因定位时间 1小时 5分钟
查询响应时间（1亿条） 10秒 1秒
写入性能（单节点） 10万条/秒 100万条/秒

5.2.3 关键优化点

  1. 表设计优化：指标表用Nested类型存储标签，日志表用log_level作为排序键，链路表用service_name作为分片键；
  2. 物化视图优化：创建了每小时CPU平均使用率、每天错误日志数量等10个物化视图，将常用查询的时间缩短到1秒以内；
  3. 跳数索引优化：为指标表的tags.value列添加Set索引，为日志表的log_level列添加Set索引，减少数据扫描范围；
  4. 分布式架构优化：按metric_name分片，确保同一指标的数据存储在同一节点，减少跨节点查询的开销。

6. 高级考量：ClickHouse在AIOps中的扩展与伦理

6.1 扩展动态：应对数据量增长

当数据量增长到100亿条/天时，需通过以下方式扩展ClickHouse集群：

  • 增加节点：通过ZooKeeper添加新节点，重新分片（如将3节点扩展到6节点）；
  • 分层存储：将冷数据（如超过3个月的指标数据）存储到S3（用ClickHouse的S3引擎访问），热数据存储在SSD中，降低存储成本；
  • 数据归档：将历史数据（如超过1年的日志数据）导出到Hive，用于离线分析。

6.2 安全影响：数据权限管理

ClickHouse的权限管理需满足AIOps的最小权限原则（如运维人员只能访问自己负责的应用的数据）：

  • 角色管理：创建ops_role角色，授予metric_data表的SELECT权限（仅能查询）；
  • 行级权限：通过row_policy限制运维人员只能查询自己负责的应用的数据（如app_name = 'web'）；
  • 加密传输：启用SSL/TLS加密，确保数据在传输过程中的安全。

6.3 伦理维度：异常检测的误报率控制

异常检测的误报率过高会导致运维人员忽视告警（“狼来了”效应），需通过以下方式控制误报率：

  • 动态阈值：用机器学习算法（如LOF、Isolation Forest）替代固定阈值（如3σ），适应数据的变化；
  • 多指标关联：结合多个指标（如CPU使用率、内存使用率、磁盘IO）判断异常，减少单指标误报；
  • 人工反馈：将运维人员的反馈（如“该异常是误报”）纳入模型训练，优化异常检测算法。

6.4 未来演化向量：结合LLM的智能根因分析

随着大语言模型（LLM）的发展，未来AIOps系统可通过ClickHouse+LLM实现更智能的根因分析：

  • 历史数据训练：用ClickHouse存储的历史故障数据（指标、日志、链路）训练LLM，让LLM学习故障模式；
  • 实时数据推理：将实时异常数据（如CPU使用率飙升）喂给LLM，让LLM自动生成根因分析报告（如“CPU使用率飙升是因为服务A的线程池满了，导致请求排队”）；
  • 自动修复建议：LLM根据根因分析结果，生成自动修复建议（如“重启服务A的线程池”），通过Argo CD执行。

7. 综合与拓展：ClickHouse在AIOps中的价值与未来

7.1 跨领域应用：从AIOps到IoT、金融

ClickHouse的时序数据处理能力不仅适用于AIOps，还可扩展到以下领域：

  • 物联网（IoT）：存储传感器数据（如温度、湿度），实时检测设备异常；
  • 金融：存储交易数据（如股票价格、成交量），实时监控风险；
  • 电商：存储用户行为数据（如点击、购买），实时推荐商品。

7.2 研究前沿：ClickHouse的实时分析优化

当前ClickHouse的研究前沿包括：

  • 向量搜索：支持向量数据的存储与查询（如LLM的嵌入向量），用于相似性搜索；
  • 流处理：通过Kafka引擎支持流处理（如实时计算指标的均值），减少数据延迟；
  • 机器学习集成：支持在ClickHouse中运行机器学习模型（如用ONNX引擎），实现实时预测。

7.3 开放问题：待解决的技术挑战

  • 高维度时序数据处理：当标签数量超过100个时，ClickHouse的查询性能会下降，需优化Nested类型的存储与查询；
  • 实时写入与查询的平衡：高吞吐写入会占用磁盘IO，影响查询性能，需优化写入与查询的资源调度；
  • 多租户隔离：当多个团队共享ClickHouse集群时，需实现资源隔离（如CPU、内存），避免相互影响。

7.4 战略建议：企业实施AIOps的路径

  • 第一步：选择合适的存储系统（如ClickHouse），解决大规模时序数据的存储与查询问题；
  • 第二步：构建数据采集 pipeline（如Prometheus+Fluentd+SkyWalking），整合多源数据；
  • 第三步：实现基础的异常检测与根因定位（如用ClickHouse的窗口函数与关联查询）；
  • 第四步：结合机器学习（如LLM），实现更智能的运维决策；
  • 第五步：持续优化（如物化视图、跳数索引），提高系统性能与稳定性。

结语

ClickHouse作为大规模时序数据处理的利器，完美匹配AIOps的核心需求（高吞吐写入、低延迟查询、多维度关联）。通过本文的实践案例与技术分析，企业可快速构建基于ClickHouse的AIOps系统，实现从“被动运维”到“主动运维”的转型。未来，随着LLM、向量搜索等技术的融合，ClickHouse在AIOps中的价值将进一步提升，成为企业数字化转型的核心支撑技术。

参考资料

  1. ClickHouse官方文档：https://clickhouse.com/docs/
  2. 《智能运维（AIOps）技术实践》，机械工业出版社；
  3. 某互联网公司AIOps系统实践报告（内部资料）；
  4. 《ClickHouse性能优化指南》，阿里云开发者社区；
  5. 《时序数据存储与分析》，O’Reilly Media。
# clickhouse # 运维
Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

探索Nginx：深入理解Nginx基础组件的使用

Nginx的每个进程内部都有一个自己的ngx_cycle。展开代码语言：C自动换行AI代码解释void *tag;*/ };

avatar 2048 AI社区

Nginx模块开发：自定义HTTP过滤器filter

展开代码语言：C自动换行AI代码解释char *name;void *ctx;

avatar 2048 AI社区

C++使用HTTP库和框架轻松发送HTTP请求

对于macOS系统：代码语言：Bash自动换行AI代码解释。编写一个C++代码示例来使用Curl库发送HTTP请求。将以下代码保存为.cpp文件（例如curl.cpp展开代码语言：C++自动换行AI代码解释。代码语言：Bash自动换行AI代码解释然后，运行生成的可执行文件：代码语言：Bash自动换行AI代码解释./example这里只是发送一个简单的GET请求到指定的URL，并打印任何响应数据。

avatar 2048 AI社区