目录
系统整体架构
1.1 分层架构设计
scss
┌──────────────────────────────────────────────────────────────┐
│ 数据消费层 (BI/应用) │
├──────────┬──────────────┬──────────────┬──────────────────────┤
│ 实时看板 │ 离线报表 │ API服务 │ 自动化决策 │
│ (秒级) │ (天级) │ (毫秒级) │ (自主优化) │
└──────────┴──────────────┴──────────────┴──────────────────────┘
↑
┌──────────────────────────────────────────────────────────────┐
│ 数据应用层 (ADS - Analysis Data Store) │
├─────────────────┬──────────────────┬──────────────────────────┤
│ 广告效果汇总 │ 用户行为分析 │ 算法模型输入特征 │
│ • 渠道汇总表 │ • 用户转化漏斗 │ • 用户embedding │
│ • 日报表 │ • 用户群体分布 │ • 特征工程输出 │
│ • 成本控制表 │ • 留存分析 │ • 模型预测结果 │
└─────────────────┴──────────────────┴──────────────────────────┘
↑
┌──────────────────────────────────────────────────────────────┐
│ 数据仓库层 (DWD/DWS/ODS) - Doris引擎 │
├────────────────┬──────────────────┬──────────────────────────┤
│ ODS原始层 │ DWD明细层 │ DWS汇总层 │
│ • raw_impr │ • fact_impression │ • daily_channel_stat │
│ • raw_click │ • fact_click │ • hourly_platform_stat │
│ • raw_conv │ • fact_conversion │ • user_conversion_path │
└────────────────┴──────────────────┴──────────────────────────┘
↑
┌──────────────────────────────────────────────────────────────┐
│ 数据集成层 (Kafka + Flink + Paimon) │
├────────────────┬──────────────────┬──────────────────────────┤
│ Kafka消息队列 │ Flink流处理 │ Paimon数据湖 │
│ • impr_topic │ • 实时清洗 │ • 湖表一体 │
│ • click_topic │ • 实时去重 │ • 版本控制 │
│ • conv_topic │ • 实时转化追踪 │ • 时间旅行 │
└────────────────┴──────────────────┴──────────────────────────┘
↑
┌──────────────────────────────────────────────────────────────┐
│ 数据采集层 (Data Source) │
├────────────┬──────────────┬──────────────┬──────────────────┤
│ API接口 │ SDK埋点 │ 日志上报 │ 第三方工具 │
│ • 百度API │ • 自有App │ • 服务器日志 │ • Mixpanel │
│ • 抖音API │ • Web埋点 │ • CDN日志 │ • Google │
│ • 快手API │ • 跨域追踪 │ • 数据库DML │ • 数据交换平台 │
└────────────┴──────────────┴──────────────┴──────────────────┘
↑
┌──────────────────────────────────────────────────────────────┐
│ 业务系统与数据源 (多平台/多渠道) │
├──────────────────────────────────────────────────────────────┤
│ 搜索广告 信息流 展示 视频 电商 社交 │
│ (百度) (抖快小红) (网站) (优爱腾) (淘抖) (微博)│
└──────────────────────────────────────────────────────────────┘1.2 分层的数据特性
makefile
┌────────────────────────────────────────────────────────────┐
│ 各层级的数据量级、延迟、维度对比 │
├─────────────┬──────────┬──────────┬────────┬──────────────┤
│ 层级 │ 数据量 │ 延迟 │ 维度数 │ 更新频率 │
├─────────────┼──────────┼──────────┼────────┼──────────────┤
│ 采集层 │ 百亿级 │ 秒级 │ 100+ │ 实时 │
│ 集成层 │ 十亿级 │ 分钟级 │ 80 │ 1-5分钟 │
│ DWD/ODS │ 亿级 │ 小时级 │ 60 │ 小时级 │
│ DWS/聚合 │ 千万级 │ 分钟级 │ 40 │ 5分钟-1小时 │
│ ADS/应用 │ 百万级 │ 秒级 │ 20 │ 实时-小时 │
└─────────────┴──────────┴──────────┴────────┴──────────────┘
数据流向特点:
├─ 采集→集成: 原始数据尽快进入系统, 支持高吞吐量
├─ 集成→仓库: 数据清洗、去重、标准化, 时间可以延迟到小时级
├─ 仓库→应用: 生成应用表、实时更新, 支持秒级查询
└─ 应用→消费: 直接查询应用表, 毫秒级响应时间核心技术选型
2.1 为什么选择 Doris 作为数据仓库
markdown
对标方案对比:
指标 Doris ClickHouse Presto Snowflake
─────────────────────────────────────────────────────────────────────────
部署方式 开源/自建 开源/自建 开源/自建 SaaS(付费)
实时更新 ✅ 支持(高效) ⚠️ 较差 ❌ 不支持 ✅ 可以
并发查询 ✅ >1000 QPS ⚠️ 200 QPS ❌ <50 QPS ✅ 支持
多维分析 ✅ Bitmap索引 ⚠️ Array类型 ✅ 支持 ✅ 支持
学习成本 ✅ MySQL兼容 ⚠️ 新语言 ⚠️ ANSI SQL ⚠️ SQL+组件
成本 ✅ 开源免费 ✅ 开源免费 ✅ 开源免费 ❌ 昂贵
集群管理 ⚠️ 中等复杂 ⚠️ 复杂 ❌ 很复杂 ✅ 托管
性能/成本比 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐
─────────────────────────────────────────────────────────────────────────
Doris适合广告数仓的理由:
1. 实时性: 广告数据需要分钟级更新, Doris支持高效的实时导入
2. 高并发: 多用户查询同一个看板, 需要支持高并发
3. 成本: 开源免费, 中等企业也能承受
4. 易用性: MySQL兼容, 原有SQL经验可直接上手
5. 性能: 列式存储, 广告数据通常只需要查询部分列2.2 为什么选择 Flink 作为实时引擎
markdown
流处理框架对比:
特性 Flink Spark Streaming Kafka Streams
────────────────────────────────────────────────────────────────
延迟 亚秒级(毫秒) 秒级(批处理) 毫秒级
状态管理 强大(RocksDB) 有限 有限
窗口支持 丰富 一般 基础
CheckPoint 强一致性 弱 弱
学习成本 中等 中等 低
社区活跃度 非常活跃 活跃 活跃
复杂计算 ✅ 支持 ✅ 支持 ❌ 不支持
───────────────────────────────────────────────────────────────
Flink适合广告数仓的理由:
1. 低延迟: 实时竞价需要毫秒级反馈
2. 复杂逻辑: 转化追踪、去重等需要复杂的状态管理
3. 准确性: 恰好一次(Exactly Once)语义保证数据准确
4. 灵活性: 支持多种窗口类型, 适应不同计算需求2.3 完整的技术栈
yaml
┌──────────────────────────────────────────────────────────────┐
│ 广告数仓技术栈 (Production-Ready) │
├──────────────────────────────────────────────────────────────┤
│ │
│ 数据存储层: │
│ ├─ Doris (OLAP数据库): 实时OLAP分析查询 │
│ ├─ Paimon (数据湖): 可选, 用于长期数据存档 │
│ ├─ HDFS/S3: 原始日志备份与归档 │
│ └─ Redis/Memcached: 热数据缓存加速 │
│ │
│ 流处理层: │
│ ├─ Kafka: 实时数据流传输 (消息队列) │
│ ├─ Flink: 实时流处理引擎 (数据清洗、去重、转化追踪) │
│ ├─ Spark: 可选, 用于复杂的批处理任务 │
│ └─ Airflow/DolphinScheduler: 任务调度与工作流管理 │
│ │
│ 数据集成: │
│ ├─ Datax/Seamless: 从源系统抽数到Kafka │
│ ├─ Python/Java SDK: 埋点数据的客户端SDK │
│ ├─ Filebeat/Logstash: 日志采集 │
│ └─ 自研API中间件: 各平台API调用与数据转换 │
│ │
│ 监控与管理: │
│ ├─ Prometheus: 系统监控 (CPU、内存、网络) │
│ ├─ Grafana: 监控可视化 │
│ ├─ ELK Stack: 日志聚合与分析 │
│ ├─ Alertmanager: 告警管理 │
│ └─ 自研管理平台: 数据质量、血缘关系、权限管理 │
│ │
│ 分析工具: │
│ ├─ Doris SQL: 直接SQL查询 │
│ ├─ Tableau/Metabase: BI工具与可视化 │
│ ├─ Jupyter/Zeppelin: 数据分析笔记本 │
│ └─ Python/R: 统计分析与机器学习 │
│ │
│ 机器学习: │
│ ├─ TensorFlow/PyTorch: 模型训练 │
│ ├─ XGBoost/LightGBM: 树模型 │
│ ├─ scikit-learn: 传统机器学习 │
│ └─ 模型服务: TensorFlow Serving/TorchServe │
│ │
└──────────────────────────────────────────────────────────────┘广告数据模型
3.1 维度与事实表设计
sql
核心事实表:
1. 展示事实表 (fact_impression)
列名 类型 维度 说明
────────────────────────────────────────────────────
impr_id STRING 无 展示唯一ID
timestamp DATETIME 时间维度 展示时间
advertiser_id INT 广告主维度 广告主ID
campaign_id INT 活动维度 活动ID
adgroup_id INT 广告组维度 广告组ID
creative_id INT 创意维度 创意ID
user_id STRING 用户维度 用户ID (UDID)
device_type STRING 设备维度 设备类型
platform_id INT 平台维度 平台ID
region_id INT 地域维度 地域ID
cost DECIMAL 无 展示成本
event_time DATETIME 无 事件时间戳
聚合方式: 按(impr_id, user_id, device_type)去重
2. 点击事实表 (fact_click)
列名 类型 维度
───────────────────────────────────────
click_id STRING 无
impr_id STRING 无
timestamp DATETIME 时间
advertiser_id INT 广告主
campaign_id INT 活动
user_id STRING 用户
device_type STRING 设备
platform_id INT 平台
cost DECIMAL 无
click_url STRING 无 (跳转链接)
关键: 通过impr_id与fact_impression关联
3. 转化事实表 (fact_conversion)
列名 类型 维度
───────────────────────────────────────
conv_id STRING 无
click_id STRING 无
impr_id STRING 无
user_id STRING 用户
advertiser_id INT 广告主
campaign_id INT 活动
conversion_type STRING 转化类型
(register/purchase/download/view)
conversion_value DECIMAL 转化价值
conversion_time DATETIME 转化时间
conversion_lag_hour INT 转化延迟(小时)
关键: 支持延迟转化(最长支持90天回归)
4. 维度表 (dimension_*)
维度表: dim_advertiser
├─ advertiser_id (PK)
├─ advertiser_name
├─ industry
├─ budget
├─ status
└─ created_date
维度表: dim_campaign
├─ campaign_id (PK)
├─ advertiser_id (FK)
├─ campaign_name
├─ objective (awareness/conversion/...)
├─ budget
├─ start_date
├─ end_date
└─ status
维度表: dim_platform
├─ platform_id (PK)
├─ platform_name (百度/抖音/快手/...)
├─ platform_type (search/feed/display/...)
├─ api_available
└─ data_latency_hour
维度表: dim_user
├─ user_id (PK)
├─ device_id
├─ device_type
├─ os_type
├─ region
├─ age_group (可选, 隐私考虑)
├─ interest_tag (可选)
└─ first_seen_date3.2 Doris表的建表语句示例
sql
-- 展示事实表 (fact_impression)
CREATE TABLE fact_impression (
impr_id STRING,
timestamp DATETIME,
advertiser_id INT,
campaign_id INT,
adgroup_id INT,
creative_id INT,
user_id STRING,
device_type STRING,
platform_id INT,
region_id INT,
cost DECIMAL(10, 4),
event_time DATETIME
)
DUPLICATE KEY (impr_id, user_id, device_type)
PARTITION BY RANGE (timestamp) (
PARTITION p_20250101 VALUES LESS THAN ("2025-01-02"),
PARTITION p_20250102 VALUES LESS THAN ("2025-01-03")
)
DISTRIBUTED BY HASH (impr_id) BUCKETS 256
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-30",
"dynamic_partition.end" = "1",
"dynamic_partition.prefix" = "p_",
"dynamic_partition.buckets" = "256"
);
-- 点击事实表 (fact_click)
CREATE TABLE fact_click (
click_id STRING,
impr_id STRING,
timestamp DATETIME,
advertiser_id INT,
campaign_id INT,
user_id STRING,
device_type STRING,
platform_id INT,
cost DECIMAL(10, 4),
click_url STRING
)
UNIQUE KEY (click_id)
PARTITION BY RANGE (timestamp) (...)
DISTRIBUTED BY HASH (click_id) BUCKETS 256;
-- 转化事实表 (fact_conversion)
CREATE TABLE fact_conversion (
conv_id STRING,
click_id STRING,
impr_id STRING,
user_id STRING,
advertiser_id INT,
campaign_id INT,
conversion_type STRING,
conversion_value DECIMAL(10, 2),
conversion_time DATETIME,
conversion_lag_hour INT
)
UNIQUE KEY (conv_id)
PARTITION BY RANGE (conversion_time)
DISTRIBUTED BY HASH (conv_id) BUCKETS 256;
-- 广告主维度表
CREATE TABLE dim_advertiser (
advertiser_id INT,
advertiser_name STRING,
industry STRING,
budget DECIMAL(12, 2),
status STRING,
created_date DATE
)
DUPLICATE KEY (advertiser_id)
DISTRIBUTED BY HASH (advertiser_id) BUCKETS 64;数据管道与ETL
4.1 多源数据采集方案
markdown
数据源分类与采集方案:
1. 平台官方API (推荐优先级最高)
└─ 百度/抖音/快手等官方API
└─ 频率: 每小时/每天拉取一次
└─ 延迟: 4-24小时
└─ 准确性: 最高
└─ 实现: Python脚本或Java应用 + Kafka
2. 自有埋点SDK (推荐优先级次高)
└─ 在自有App/Web上埋点
└─ 频率: 实时
└─ 延迟: 秒级
└─ 准确性: 高
└─ 实现: 客户端SDK + 服务器收集 + Kafka
3. 第三方转化追踪工具
└─ Mixpanel/AppsFlyer/Adjust等
└─ 频率: 实时
└─ 延迟: 秒-分钟级
└─ 准确性: 高(通常)
└─ 实现: 第三方Webhook + Kafka
4. 日志系统
└─ 服务器日志、CDN日志等
└─ 频率: 实时/分钟级
└─ 延迟: 秒-分钟级
└─ 准确性: 中
└─ 实现: Filebeat + Logstash + Kafka
5. 数据交换与合作伙伴
└─ 与其他平台的数据共享
└─ 频率: 日级/周级
└─ 延迟: 小时级
└─ 准确性: 中
└─ 实现: 文件传输 + ETL导入4.2 ETL流程设计
sql
完整的ETL流程:
┌─────────────────────────────────────────────────────────┐
│ 第1步: 数据采集 (Extract) │
├─────────────────────────────────────────────────────────┤
│ • 从各个数据源获取原始数据 │
│ • 推送到Kafka的raw_impr/raw_click/raw_conv topics │
│ • 保留原始格式, 便于问题回溯 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 第2步: 数据清洗与标准化 (Transform - Flink) │
├─────────────────────────────────────────────────────────┤
│ • 字段校验 (必填字段、数据类型) │
│ • 格式转换 (时间戳标准化、字符编码) │
│ • 去重 (按event_id/impr_id) │
│ • 异常值处理 (成本为负值、时间错误等) │
│ • 维度补全 (user_id补全、地域编码等) │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 第3步: 转化追踪与关联 (Advanced Transform - Flink) │
├─────────────────────────────────────────────────────────┤
│ • 展示→点击关联 (通过impr_id) │
│ • 点击→转化关联 (通过click_id, 支持延迟90天) │
│ • 归因分析 (first-touch/last-touch/linear等) │
│ • 用户旅程构建 (展示→点击→转化的完整链路) │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 第4步: 数据导入 (Load - Doris) │
├─────────────────────────────────────────────────────────┤
│ • 批量导入到Doris ODS层 (原始数据表) │
│ • 支持秒级/分钟级导入 │
│ • 处理重复记录 (UPDATE或INSERT IGNORE) │
│ • 验证导入完整性 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 第5步: 数据汇总与计算 (Aggregate - Doris SQL) │
├─────────────────────────────────────────────────────────┤
│ • ODS → DWD (明细数据清洗) │
│ • DWD → DWS (按维度汇总) │
│ • 计算关键指标: │
│ ├─ 展示数、点击数、点击率 │
│ ├─ 转化数、转化率、转化成本 │
│ ├─ ROI、毛利率、预算消耗 │
│ └─ 按时间、维度、平台等多维度 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 第6步: 数据应用 (Application) │
├─────────────────────────────────────────────────────────┤
│ • DWS → ADS (生成应用表) │
│ • 实时看板 (秒级更新) │
│ • 离线报表 (日级/周级) │
│ • API服务 (毫秒级查询) │
│ • 自动化决策 (竞价、预算分配等) │
└─────────────────────────────────────────────────────────┘实时计算引擎
5.1 Flink实时处理架构
arduino
Flink作业拓扑 (Streaming Topology):
┌──────────────────────────────────────────────────────────┐
│ Kafka Source (multiple topics) │
│ ├─ raw_impression_topic │
│ ├─ raw_click_topic │
│ └─ raw_conversion_topic │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 数据清洗与标准化 (Stateless Operators) │
│ • 解析JSON, 字段校验 │
│ • 格式转换 (时间戳、坐标等) │
│ • 异常值过滤 │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 分流处理 (Stream Branching) │
├──────────────────────────────────────────────────────────┤
│ ├─ 展示流 (Impression Stream) │
│ │ ├─ 去重 (按impr_id) │
│ │ ├─ 维度补全 │
│ │ └─ 输出到clean_impression_topic │
│ │ │
│ ├─ 点击流 (Click Stream) │
│ │ ├─ 去重 (按click_id) │
│ │ ├─ 与展示关联 (impr_id lookup) │
│ │ └─ 输出到clean_click_topic │
│ │ │
│ └─ 转化流 (Conversion Stream) │
│ ├─ 去重 (按conv_id) │
│ ├─ 延迟转化处理 (最长90天) │
│ ├─ 与点击关联 (click_id lookup) │
│ ├─ 归因计算 (first-touch/multi-touch) │
│ └─ 输出到clean_conversion_topic │
│ │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 窗口聚合与实时指标 (Windowed Aggregation) │
│ • 滚动窗口: 1小时、1天 │
│ • 滑动窗口: 5分钟滑动 │
│ • Session窗口: 用户会话分析 │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ Sink到Doris (Doris Sink Connector) │
│ • 写入到ODS层原始表 │
│ • 批量写入优化吞吐量 │
│ • 支持EXACTLY_ONCE语义 │
│ • 自动失败重试与超时处理 │
└──────────────────────────────────────────────────────────┘5.2 关键Flink作业代码示例
java
// 伪代码示例: Flink展示数据清洗与导入
public class ImpressionProcessingJob {
public static void main(String[] args) throws Exception {
StreamExecutionEnvironment env =
StreamExecutionEnvironment.getExecutionEnvironment();
// Source: Kafka
DataStream<String> kafkaSource = env
.addSource(new FlinkKafkaConsumer<>(
"raw_impression_topic",
new SimpleStringSchema(),
kafkaProps
))
.name("KafkaSource_Impression");
// Transform: 解析和清洗
DataStream<ImpressionRecord> cleanedStream = kafkaSource
.flatMap(new ImpressionParser())
.name("Parser")
.filter(new ImpressionValidator())
.name("Validator")
.map(new ImpressionEnricher()) // 补全维度
.name("Enricher");
// Dedup: 按impr_id去重 (使用State)
DataStream<ImpressionRecord> dedupStream = cleanedStream
.keyBy(ImpressionRecord::getImprId)
.flatMap(new DeduplicationOperator(
stateTTL = 3600 // 1小时
))
.name("Deduplication");
// Sink to Doris
dedupStream
.sinkTo(new DorisSink<>(
URL = "doris-fe:8030",
database = "adtech_dwh",
table = "fact_impression",
batchSize = 10000,
flushInterval = 5000 // 5秒
))
.name("DorisSink_Impression");
env.execute("ImpressionProcessingJob");
}
}
// 关键类定义
class ImpressionRecord {
String imprId;
Long timestamp;
Integer advertiserId;
Integer campaignId;
String userId;
String deviceType;
Integer platformId;
BigDecimal cost;
// getters/setters...
}数据存储策略
6.1 Doris表优化策略
sql
存储优化:
1. 分区策略 (Partition)
├─ 时间分区: 按日期分区, 便于删除过期数据
├─ 动态分区: 自动创建新分区, 无需手工维护
├─ 分区保留: 通常保留30天热数据, 90天总数据(可配置)
└─ 示例:
PARTITION BY RANGE(timestamp) (
PARTITION p_20250101 VALUES LESS THAN ("2025-01-02"),
PARTITION p_20250102 VALUES LESS THAN ("2025-01-03")
)
2. 分桶策略 (Bucket/Distribution)
├─ 分桶键: 选择查询最常见的过滤条件
├─ 分桶数: 根据数据量确定, 通常256-512个桶
├─ 好处: 并行查询, 提升性能
└─ 示例:
DISTRIBUTED BY HASH(advertiser_id, timestamp) BUCKETS 256
3. 副本策略 (Replication)
├─ 副本数: 3副本保证高可用
├─ 引擎: 使用UNIQUE KEY模型, 支持更新
└─ 冗余度: 成本/可靠性权衡
4. 索引优化
├─ Bitmap索引: 用于低基数列 (platform_id, device_type等)
├─ 前缀索引: 用于WHERE条件频繁的列
├─ 存储格式: V2格式提升读性能
└─ 示例:
ALTER TABLE fact_impression
ADD INDEX idx_advertiser(advertiser_id) USING BITMAP;
5. 列式存储优化
├─ 选择列数据类型: INT<BIGINT<DECIMAL<STRING
├─ 避免NULL值: 使用默认值替代
├─ 字符串压缩: 使用DICTIONARY类型
└─ 数值精度: 使用DECIMAL(10,2)而不是DECIMAL(18,4)
6. 磁盘与内存权衡
├─ 热表: 高频查询表使用高性能磁盘SSD
├─ 温表: 中频表使用普通HDD
├─ 冷表: 低频表压缩存储或归档
└─ 缓存: 常用查询结果缓存到Redis6.2 成本控制与扩展计划
ini
存储成本估算:
日数据生成量估算:
├─ 展示数: 5亿条 / 日
│ ├─ 平均大小: 0.5KB / 条
│ └─ 日成本: 500GB
├─ 点击数: 5000万条 / 日
│ ├─ 平均大小: 0.8KB / 条
│ └─ 日成本: 40GB
├─ 转化数: 500万条 / 日
│ ├─ 平均大小: 1.0KB / 条
│ └─ 日成本: 5GB
└─ 合计: ~550GB / 日
存储总成本:
├─ 30天热数据: 550GB × 30 = 16.5TB (3副本 = 50TB物理)
├─ 90天全数据: 550GB × 90 = 50TB (3副本 = 150TB物理)
├─ 硬件成本: 约¥20-30万 (中等规模)
└─ 年度运维: 约¥5-10万
可选成本优化:
├─ 压缩: 启用ZSTD压缩, 减少40-50%存储
├─ 分层存储: 冷表迁移到Paimon/S3, 节省50%成本
├─ 数据采样: 非关键维度采样存储, 节省20-30%
└─ 定期清理: 清理冗余/过期数据总结
架构设计实现了:
- 实时性: 秒级数据延迟, 分钟级指标更新
- 可靠性: 3副本Doris集群, 99.9%可用性
- 可扩展性: 支持从日5亿条到50亿条的增长
- 成本优化: 开源技术栈, 合理的存储分层
- 易用性: MySQL兼容的Doris, 学习成本低
下一阶段将详细描述:
- 03: 部署与基础设施方案
- 04: 指标计算与应用方案
- 05: 监控告警与SLA保障
- 06: 成本与ROI评估