ES 既不像 MySQL 这样有严格的 Schema，也不像 MongoDB 那样完全无 Schema，而是介于两者之间。

1️⃣ ES 的 Schema 模式
ES 默认是 Schema-less（无模式） 的，允许动态添加字段。
但 ES 也支持 Schema（映射 Mapping），可以手动定义字段类型，类似 MySQL。
区别： MySQL 需要提前定义表结构，ES 则可以自动识别字段类型（但推荐手动定义）。

2️⃣ ES vs MySQL vs MongoDB

特性	ES（Elasticsearch）	MySQL	MongoDB
Schema 约束	动态 Schema，可手动定义	严格 Schema（表必须有固定结构）	无 Schema（每条记录可有不同字段）
数据存储格式	JSON 文档	表行列存储	BSON 文档
索引方式	自动索引所有字段（全文检索优化）	索引需手动创建	可选索引
扩展性	分布式架构，横向扩展方便	主从复制，扩展有限	分片+副本，可扩展
查询方式	DSL 查询（类似 SQL）	SQL 查询	BSON 查询

3️⃣ ES 的 Schema 示例
💡 默认动态模式（Schema-less） 如果你没有手动定义 Mapping，ES 会自动推测字段类型：

PUT my_index/_doc/1
{
  "name": "iPhone",
  "price": 999.99,
  "release_date": "2025-02-11"
}

📌 ES 会自动创建 my_index 索引，并推测：
name: text
price: float
release_date: date

💡 手动定义 Schema

PUT my_index
{
  "mappings": {
    "properties": {
      "name": { "type": "keyword" },
      "price": { "type": "float" },
      "release_date": { "type": "date" }
    }
  }
}

📌 这样可以避免 ES 自动推测错误（例如 keyword vs text）。

4️⃣ 结论
✅ ES 既支持 Schema-less，也可以手动定义 Schema。
✅ 不像 MySQL 需要严格定义表结构，但比 MongoDB 更有 Schema 约束。
✅ 推荐手动定义 Mapping，避免数据类型推测错误。

🚀 ES 适用于大规模搜索场景，但不是严格关系型数据库的替代品！

在 Elasticsearch（ES）中，索引（Index） 相当于 关系型数据库中的表，它存储的是一组结构化的数据文档。每个索引包含多个 文档（Document），每个文档都有唯一的 ID，并且存储在多个 分片（Shard） 中。

📌 示例：广告投放日志索引
假设我们在 广告投放业务 中存储广告曝光日志，索引名为 ad_impressions_2025-02-11（按日期分索引）。

1️⃣ 定义索引（Mapping）

PUT ad_impressions_2025-02-11
{
  "settings": {
    "number_of_shards": 10,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "ad_id": { "type": "keyword" },
      "campaign_id": { "type": "keyword" },
      "user_id": { "type": "keyword" },
      "timestamp": { "type": "date" },
      "device_type": { "type": "keyword" },
      "country": { "type": "keyword" },
      "click": { "type": "boolean" },
      "cost": { "type": "float" }
    }
  }
}

📌 说明
索引名称：ad_impressions_2025-02-11（每天创建一个新索引）
分片：10 个（number_of_shards: 10，适用于大数据量）
副本：1 份（number_of_replicas: 1，保证数据安全）
字段类型：
ad_id、campaign_id、user_id：keyword（精准查询）
timestamp：date（时间筛选）
click：boolean（是否点击广告）
cost：float（广告投放成本）

2️⃣ 插入数据（广告曝光日志）

POST ad_impressions_2025-02-11/_doc/1
{
  "ad_id": "AD12345",
  "campaign_id": "CMP67890",
  "user_id": "U001",
  "timestamp": "2025-02-11T10:30:00Z",
  "device_type": "mobile",
  "country": "US",
  "click": true,
  "cost": 0.5
}

📌 插入了一条广告曝光数据：
AD12345 这条广告在 2025-02-11 10:30 被 U001 用户在美国的手机端浏览。
用户点击了广告（click: true）。
广告主付出了 0.5 美元（cost: 0.5）。

3️⃣ 查询数据
🔍 查询某个广告的曝光记录

GET ad_impressions_2025-02-11/_search
{
  "query": {
    "match": {
      "ad_id": "AD12345"
    }
  }
}

📌 返回 AD12345 这条广告的所有曝光数据。

🔍 统计某个广告的点击率（CTR）

GET ad_impressions_2025-02-11/_search
{
  "size": 0,
  "aggs": {
    "total_views": { "value_count": { "field": "ad_id" } },
    "total_clicks": { "filter": { "term": { "click": true } } }
  }
}

📌 计算某个广告的 CTR = 点击次数 / 曝光次数。

4️⃣ 滚动索引（按日期管理索引）
每天数据量很大，按日期创建索引，例如：
ad_impressions_2025-02-10
ad_impressions_2025-02-11
ad_impressions_2025-02-12
可以用 索引别名（Alias） 进行查询：

POST _aliases
{
  "actions": [
    { "add": { "index": "ad_impressions_2025-02-*", "alias": "ad_impressions" } }
  ]
}

总结

概念	说明
索引（Index）	类似数据库的表，每天创建一个
文档（Document）	ES 中的具体记录（类似数据库行数据）
字段（Field）	ES 文档的属性（类似数据库列）
分片（Shard）	数据存储在多个分片中，分片可以分布到多个节点
副本（Replica）	备份数据，提升查询性能，提高容灾能力

广告业务 每天索引 1 亿+ 数据，ES 需要 按日期拆分索引，并优化 查询和存储策略 以保证高效查询。
🚀 这样，ES 就能高效存储广告曝光数据，并支持 CTR 计算、广告点击查询等复杂业务需求！

广告数据为什么不用 Mysql 来存储?

广告数据通常不适合存储在 MySQL，主要原因是数据量巨大、查询需求复杂、实时性要求高。相比之下，Elasticsearch（ES）和 Kafka 更适合广告业务的存储和处理需求。

1️⃣ 广告数据的特点
✅ 高并发写入
每天产生亿级别广告日志（曝光、点击、转化等）。
MySQL 在高并发写入时容易成为瓶颈，需要分库分表，运维复杂。
✅ 大数据存储
广告数据是时间序列数据，每天新增大量数据，不断累积。
MySQL 存储成本高，而 ES 和 Hadoop/Hive 更适合处理大数据。
✅ 实时查询和分析
查询模式复杂：需要按 广告 ID、时间、用户行为等维度检索。
ES 具有全文检索和聚合分析能力，比 MySQL 快 10 倍以上。
✅ 实时计算
广告推荐、投放监控、竞价等业务需要实时计算。
Kafka + Flink 实时处理流数据，ES 实时查询，性能更优。

2️⃣ MySQL 的问题

问题	为什么 MySQL 不适合广告数据？
数据量大	单表 存储上限（分区表也有限），MySQL 读写性能下降
高并发写入	写入 TPS（事务/秒）低，无法承受 亿级日志
查询性能	多字段查询慢，无法快速检索大数据
复杂分析	不擅长实时数据聚合、时间窗口计算
扩展性	水平扩展难，需要手动分库分表，ES 可自动扩展

3️⃣ 更好的技术方案
🚀 Kafka + Flink + Elasticsearch
Kafka：实时接收广告日志，缓冲高并发数据流。
Flink / Spark Streaming：实时计算广告点击、转化率等指标。
Elasticsearch：存储索引数据，支持快速查询、聚合分析。
📌 示例：广告点击数据处理流程
用户点击广告，日志发送到 Kafka。
Flink 从 Kafka 读取数据，计算实时点击率。
计算结果存入 Elasticsearch，提供实时查询。
MySQL 只存储核心统计数据（如每日汇总）。

4️⃣ 什么时候用 MySQL？
用户账户、广告配置等结构化数据（少量数据）。
财务结算、历史订单（数据量适中，查询稳定）。
数据汇总表（每天生成的聚合数据）。

5️⃣ 结论
✅ 广告日志数据：Kafka + ES 更合适，MySQL 处理不了大规模数据流
✅ 如果数据量不大（百万级），可以用 MySQL，但难以扩展到亿级
✅ MySQL 适用于结构化数据存储，ES 适用于大规模广告查询分析

🚀 广告业务最常见的存储方案：Kafka + Flink + Elasticsearch！

广告数据为什么不用 Redis 来存储?

Redis 也不适合存储广告数据！ 🚫
Redis 主要用于缓存和高性能 KV 存储，但广告数据有大规模存储、复杂查询、实时分析的需求，Redis 在这些方面不太适用。

1️⃣ Redis 不适合存广告数据的原因

Redis 限制	为什么不适合广告数据？
存储空间有限	Redis 数据存内存，广告数据每天 新增 100GB+，成本高
查询能力弱	只能按 key 查询，不支持复杂搜索（多条件、聚合、排序等）
数据持久化风险	RDB/AOF 方式不能承受大规模数据存储，恢复慢
高并发写入瓶颈	Redis 主要用于 低延迟查询，不擅长 高吞吐写入
数据过期管理困难	广告日志数据 每天增长，Redis 需要定期删除，管理麻烦

2️⃣ Redis 在广告业务中的合适场景
虽然 Redis 不能存广告日志数据，但可以用来优化广告业务中的部分功能 👇

✅ 1. 广告投放缓存
存储广告策略、广告素材，减少数据库查询压力。
例如：

{
  "ad_123": { "title": "iPhone 15 Pro", "budget": 500, "bid": 2.5 }
}

业务场景：前端请求广告时，直接从 Redis 读取投放策略，速度更快。

✅ 2. 频次控制（防止刷广告）
限制同一用户短时间内多次点击广告。
用 Redis + 计数器 实现限流：

INCR ad_click:user_123
EXPIRE ad_click:user_123 60

业务场景：防止恶意刷广告点击，提高投放精准度。

✅ 3. 实时 CTR（点击率）缓存
计算 广告点击率（CTR），避免 MySQL 高并发查询。
方案：Redis 计数器，每次点击增加计数：
业务场景：广告主需要实时监测广告效果，CTR 计算可先存 Redis，定期同步 MySQL。

3️⃣ 结论
🚫 Redis 不能存储大规模广告日志（存储成本高，查询能力弱）
✅ Redis 适用于缓存广告投放策略、限流、存实时 CTR 数据
✅ 广告日志数据推荐 Kafka + Flink + Elasticsearch 方案
如果你是做广告业务，Redis 不是核心存储方案，而是辅助缓存和限流工具！ 🚀

广告数据为什么不用 Mongodb 来存储?

MongoDB 也不太适合存储广告日志数据。

1️⃣ MongoDB 适合广告数据存储吗？
🚫 不太适合，但可以用在部分场景。
🚫 MongoDB 的劣势

MongoDB 限制	为什么不适合广告日志？
写入性能瓶颈	MongoDB 单机写入性能有限，高并发写入不如 Kafka + ES
索引管理复杂	海量数据查询慢，需要手动优化索引，维护成本高
查询性能不足	不支持倒排索引，广告搜索和聚合分析比 ES 慢
存储成本高	BSON 格式比 JSON 体积大，存储成本比 ES 更高
水平扩展不如 ES	MongoDB Sharding 扩展性不如 ES，高 QPS 下索引查询压力大

📌 MongoDB 适用于：
小规模数据（千万级以内）。
JSON 结构复杂的广告元数据（例如：广告创意、投放规则）。
MongoDB 聚合适用于简单的数据分析，但不如 ES 高效。

2️⃣ MongoDB 适用于哪些广告业务场景？
MongoDB 适合存广告系统中的部分数据，但不是日志存储的最佳方案。

✅ 1. 广告投放规则存储
广告配置、投放条件、目标受众（比 MySQL 更灵活）。
示例：

{
  "ad_id": "ad_123",
  "title": "iPhone 15 Pro",
  "budget": 500,
  "bid": 2.5,
  "targeting": {
    "location": "US",
    "age": { "$gte": 18, "$lte": 35 },
    "interests": ["technology", "smartphones"]
  }
}

为什么用 MongoDB？
目标受众、投放条件是复杂的 JSON 结构，MongoDB 存储更灵活。

✅ 2. 用户画像（User Profile）
存储用户兴趣、历史行为、个性化推荐数据。
查询复杂度高，但数据量相对较小（千万级）。
适用于：广告推荐系统。

✅ 3. 归档历史广告数据
MongoDB 适合存过期的广告投放记录，供后续分析。
不适合实时查询广告数据（ES 更快）。

3️⃣ 最优广告数据存储方案
📌 广告日志（曝光、点击、转化） -> 不建议 MongoDB！
✔ 推荐 Kafka + Flink + Elasticsearch：
Kafka：存储广告日志流，提供高吞吐写入。
Flink：实时计算CTR、转化率、ROI。
Elasticsearch：支持实时查询、分析。

📌 广告配置信息 -> 可以用 MongoDB
✔ MongoDB 适用于广告配置、目标受众匹配，但查询性能比 ES 差。

4️⃣ 结论
❌ MongoDB 不适合存储海量广告日志（写入压力大，查询性能不如 ES）。
✅ 适合存广告元数据，如投放策略、用户画像、历史归档数据。
🚀 广告日志查询，还是 Kafka + ES 更高效！

Hive 呢

Hive 适合存储广告数据，但也有局限性。Hive 更适合 大规模数据存储和批量处理，而广告数据通常对 实时性和查询效率要求较高，因此在广告业务中，Hive 主要用于离线存储和批处理，不太适合做 实时查询和快速响应。

1️⃣ Hive 的优势
✅ 1. 大规模数据存储
Hive 存储大规模的广告数据，如曝光、点击、转化记录，适合离线批量处理。
广告数据通常按天、周、月分区，Hive 能够高效地存储、压缩这些时间序列数据。
✅ 2. 离线数据分析
Hive 支持 SQL 风格查询，并能与 Hadoop 集群和 Spark 集成，适合大规模广告数据分析，如计算 CTR（点击率）、转化率、**ROI（投资回报率）**等。
分析场景：
每天或每周批量处理广告曝光、点击数据，生成统计报告。
进行广告效果分析，基于用户群体、时间段、地域等维度生成报告。
✅ 3. 可扩展性强
Hive 基于 Hadoop 和 HDFS，支持分布式存储和计算，能横向扩展处理海量数据。
广告平台生成的 亿级日志数据，Hive 可以高效地存储和处理。

2️⃣ Hive 的劣势

Hive 限制	为什么不适合广告实时数据存储？
实时性差	Hive 是 批处理，不适合 实时查询。广告业务往往需要实时计算和展示（如实时点击率、实时广告排名）。
查询性能低	Hive 的查询速度不如 Elasticsearch，无法高效处理复杂的搜索和实时聚合。
写入延迟高	Hive 写入数据存在较高的延迟，通常用于数据分析场景而非实时存储。
复杂查询优化困难	Hive 中进行复杂的聚合查询时，可能导致性能瓶颈，需要手动优化查询计划。

3️⃣ Hive 在广告数据中的适用场景
Hive 更适合做 离线处理和分析，不适合实时查询。
✅ 1. 离线广告数据存储
存储广告曝光、点击、转化等日志，便于日后分析和计算。
如：每天的广告曝光量、点击量、转化量，生成汇总表存储。

✅ 2. 大规模广告数据分析
对广告效果进行深度分析，比如：
每周、每月按渠道、广告主、地域等维度生成 广告效果分析报告。
示例：计算每个广告位的平均点击率、转化率、ROI。

✅ 3. 历史广告数据归档
存储 历史广告数据（例如，3-6 个月前的广告投放记录），供后续查询或计算。

4️⃣ 最优广告数据存储方案
实时广告数据存储：
使用 Kafka + Flink + Elasticsearch，支持实时写入、查询、分析，性能更优。

Kafka 处理高并发广告日志数据流。
Flink 进行广告效果实时计算。
Elasticsearch 存储广告数据，支持高效查询和聚合分析。
离线广告数据分析：
使用 Hive + Hadoop 存储和批量分析海量广告数据。

Hive 适合大规模日志存储和离线数据计算，进行广告效果的周期性批量分析。

5️⃣ 结论
✅ Hive 适合存储广告数据的离线日志、批量分析场景，如存储广告曝光、点击、转化日志，进行定期报表生成和效果分析。
🚫 不适合做实时广告数据存储、查询和分析，这些场景需要使用 Kafka + Flink + Elasticsearch。

🚀 如果需要实时性和高查询性能，Hive 不适合，应该结合 Kafka、Flink 和 Elasticsearch 进行数据流处理和实时查询。

ClickHouse 呢

ClickHouse 适合存储广告数据！ ✅
ClickHouse 是一种列式数据库，非常适合进行 大规模数据存储、实时分析 和 快速查询，因此在广告数据存储方面，ClickHouse 非常合适，尤其适用于高吞吐量的数据写入和复杂的聚合查询。

1️⃣ ClickHouse 的优势
✅ 1. 高效的实时数据分析
ClickHouse 采用 列式存储，对于广告数据中的 聚合查询（如：点击量、转化率、CTR）非常高效。
广告数据通常以时间序列为主，ClickHouse 在这方面的性能表现特别突出。可以进行 秒级实时查询，适用于广告平台上的 实时展示、广告效果分析等。
✅ 2. 高吞吐量写入
ClickHouse 支持 高并发写入，可以 快速处理广告曝光、点击等日志数据，适合 每天数亿条广告日志写入的场景。
示例：广告曝光日志、点击日志等，可以高效存储和实时写入 ClickHouse。
✅ 3. 强大的聚合查询能力
由于 ClickHouse 是列式存储，对于需要聚合分析的广告数据（如 CTR、ROI、点击量）非常合适，比传统的行式数据库要快得多。
可以使用 SQL 进行高效的 数据聚合、分组统计、多维度分析，例如按广告渠道、时间段、用户群体计算广告效果。
✅ 4. 支持水平扩展
ClickHouse 支持 水平扩展，能随着数据量增长而扩展集群，处理海量广告数据。
适应广告平台增长的需求，随着广告数据量的增加，可以轻松扩展 ClickHouse 集群，保证性能。

2️⃣ ClickHouse 在广告数据中的应用场景
ClickHouse 非常适合用于广告业务中的 日志数据存储与实时分析。以下是一些典型的应用场景：
✅ 1. 广告曝光与点击日志存储
将 广告曝光、点击、转化日志 等高并发数据存储到 ClickHouse。
可以通过 SQL 聚合计算广告的 点击率（CTR）、转化率，分析广告效果。
例如：

SELECT
  ad_id,
  COUNT(*) AS clicks,
  SUM(CASE WHEN conversion = 1 THEN 1 ELSE 0 END) AS conversions,
  COUNT(*) / SUM(CASE WHEN impression = 1 THEN 1 ELSE 0 END) AS ctr
FROM ad_logs
WHERE event_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY ad_id

✅ 2. 广告投放效果分析
存储广告投放数据并对其进行实时分析，计算广告的 ROI、CPC（点击成本）、CPL（潜在客户获取成本） 等。
可以做 多维度分析，例如按 地域、用户特征、时间段 等分析广告效果。

✅ 3. 广告流量监控与实时报警
用 ClickHouse 存储广告 流量数据，实时监控广告平台的流量表现、点击量等，结合 Flink 或 Kafka 实现实时数据处理和报警。

✅ 4. 归档历史广告数据
ClickHouse 也可以用于存储广告的 历史数据，并定期生成广告效果报表，供广告主和运营团队查看。

3️⃣ ClickHouse 的劣势

限制	原因
写入延迟	虽然 ClickHouse 可以高效写入，但它仍然是一个 OLAP 数据库，写入延迟和 流式写入（如 Kafka） 相比会稍慢。
事务支持	ClickHouse 不支持复杂事务，如果广告业务涉及到复杂的多表事务操作（如跨多个表的更新），ClickHouse 可能不是最合适的选择。
实时性与存储平衡	ClickHouse 更适合 批量查询和分析，如果你的广告平台需要非常 高频的、实时的、低延迟查询，它可能不如 Elasticsearch 或 Kafka + Flink 高效。

4️⃣ 最优广告数据存储方案
实时广告数据存储：
如果是 实时广告数据流，可以通过 Kafka + Flink + ClickHouse 实现。Kafka 作为数据流管道，Flink 用于实时计算和处理数据，最终存储在 ClickHouse 中进行聚合分析。
广告日志查询与分析：
ClickHouse 作为 广告数据的主要分析引擎，存储广告曝光、点击日志，并实时或周期性进行复杂查询和数据分析。
多维度广告效果分析：
使用 ClickHouse 进行广告效果分析，如 CTR、ROI、点击量、转化率 等聚合查询，快速响应广告主需求。

5️⃣ 结论
ClickHouse 非常适合存储和分析广告数据，尤其是大规模日志数据（如广告曝光、点击、转化），适用于 实时数据写入 和 高效的聚合分析。
如果你需要高吞吐量写入、高并发查询和实时分析，ClickHouse 是一个非常好的选择，特别适合广告数据分析和实时广告效果监控。

🚀 推荐方案：广告日志数据存储在 Kafka + Flink + ClickHouse 中，实时分析广告效果，广告报告生成。

Hadoop 呢

Hadoop 是一个 大数据处理框架，包含了 HDFS（Hadoop 分布式文件系统） 和 MapReduce 等组件，广泛应用于存储和处理 海量数据。对于广告数据，尤其是 批量处理 和 大规模数据存储，Hadoop 是非常合适的。但对于 实时查询 和 快速响应，Hadoop 可能不如 ClickHouse 或 Elasticsearch。

1️⃣ Hadoop 的优势
✅ 1. 大规模数据存储
Hadoop 适用于 海量广告数据的存储，如 广告曝光、点击日志、转化数据 等。HDFS 提供了 分布式存储，可以将广告数据按 时间、渠道、广告主 等维度分片存储。
适用于存储 历史广告数据，并能根据 需要 扩展存储容量。
✅ 2. 离线批量处理
Hadoop 的 MapReduce 处理框架适合 批量数据处理，可以用来执行广告数据的 批量计算和分析，如计算 点击率、转化率、广告投放效果等。
例如，定期计算某段时间内所有广告的总曝光量、点击量、转化量等。
✅ 3. 高度可扩展性
Hadoop 集群可以 横向扩展，当广告数据量剧增时，可以增加更多的节点来处理更多的数据。
支持 TB 级、PB 级别的数据存储和计算，广告平台中 历史广告数据 的存储可以依赖 Hadoop 处理。

2️⃣ Hadoop 在广告数据中的应用场景
Hadoop 适合用于 大规模广告数据的批量存储与处理，以下是一些典型的应用场景：

✅ 1. 离线广告数据存储
存储 广告曝光、点击、转化等日志，按时间分区，便于后续分析和计算。
使用 Hadoop 处理和存储历史广告数据，如存储近三个月的广告日志。

✅ 2. 离线广告效果分析
使用 MapReduce 执行广告效果分析，如计算 每个广告的点击率、转化率、ROI 等指标。
可以对所有广告主、广告类型、地域等维度进行 大规模聚合计算，生成日报、周报或月报。

✅ 3. 数据归档与报告生成
将不再需要频繁访问的广告数据归档到 Hadoop 集群中，定期生成广告效果报告。
为广告主提供 广告投放效果分析报告，支持长期存储和高效的 离线查询。

✅ 4. 深度分析与挖掘
基于 Hadoop 的 MapReduce 或 Spark，进行 深度数据分析和挖掘，如分析用户的广告行为、偏好，进行 用户画像 和 精准广告推荐。

3️⃣ Hadoop 的劣势

限制	原因
实时性差	Hadoop 主要是 批量处理框架，不适合实时写入和查询，广告数据通常需要实时处理和分析，而 Hadoop 不支持 低延迟查询。
查询性能较低	Hadoop 中存储的数据往往不适合 快速查询，查询效率相对较低，无法应对 高频繁、复杂的交互式查询。
复杂性高	相比 Elasticsearch 和 ClickHouse，Hadoop 的集群管理、调优和查询更复杂，通常需要更多的技术投入。
延迟写入	Hadoop 的写入操作存在较高的延迟，尤其在 广告数据流式写入时，延迟较高，不适合实时广告监控和反馈。

4️⃣ Hadoop 在广告数据中的适用场景
Hadoop 主要适用于 离线数据处理和分析，例如：

✅ 1. 广告数据归档与存储
将广告数据存储在 Hadoop HDFS 中，并定期将历史广告数据归档，避免占用实时数据库的存储空间。

✅ 2. 离线分析与报表
对广告数据进行批量处理和聚合分析，计算广告效果指标，如 CTR、CPC、ROI，生成月度、季度、年度报告。

✅ 3. 广告投放效果分析
分析广告投放效果，使用 Hadoop 来处理和分析海量数据，比如通过 MapReduce 执行广告效果的 多维度分析（如按渠道、地域、时间段等进行聚合分析）。

5️⃣ Hadoop 的最优广告数据存储方案
离线广告数据存储：
使用 Hadoop HDFS 存储海量的广告数据，适合存储 历史日志数据，并可随时扩展存储空间。

离线广告分析：
使用 MapReduce 或 Apache Spark 对广告数据进行大规模的批量计算和分析，生成广告效果报告，或者进行用户行为分析。

广告数据归档：
对历史数据进行归档，使用 Hadoop 存储 长期历史数据，并进行周期性报告的生成。

6️⃣ 结论
Hadoop 非常适合存储和处理大规模的广告数据，尤其适用于 批量存储、离线分析和大规模计算。如果广告平台有大量的历史广告数据需要存储、归档和分析，Hadoop 是一个不错的选择。

🚫 但不适合实时广告数据处理和高频查询，如需要快速响应广告效果、实时数据反馈等场景，推荐使用 ClickHouse 或 Elasticsearch。

🚀 推荐方案：
实时广告数据流：使用 Kafka + Flink + ClickHouse 或 Kafka + Flink + Elasticsearch 进行实时处理和查询。
历史广告数据存储与离线分析：使用 Hadoop HDFS + Spark/MapReduce 执行大规模数据分析和生成周期性报告。

HBase 呢

HBase 适合存储需要 快速读写 和 随机访问 的大规模广告数据，尤其是 实时数据存储 和 快速查询 的场景。

1️⃣ HBase 的优势
✅ 1. 高效的随机读写
HBase 是一个 列式存储 数据库，特别适合快速读取和写入 海量广告数据，如广告的 点击、曝光、转化记录 等。
它可以提供 高吞吐量 的写入性能，适合 广告平台需要实时写入数据，例如广告曝光和点击日志。
✅ 2. 高可扩展性
HBase 的 横向扩展 能够支持从 TB 到 PB 级别的存储，并可以在集群中增加节点来应对数据量的快速增长。
它适合广告平台随着时间增长， 持续扩展 存储容量和处理能力。
✅ 3. 实时查询和低延迟
HBase 支持 快速随机读写，适合需要 低延迟访问 的场景，如快速查询某个广告的 曝光量、点击量、转化率 等数据。
对于广告投放平台，能提供实时查询用户行为、广告效果等指标的能力。
✅ 4. 强一致性
HBase 提供 强一致性，确保广告数据在读取时的正确性，特别是广告展示和点击量等需要精确的一致性数据。

2️⃣ HBase 在广告数据中的应用场景
HBase 适合用于 实时广告数据存储和查询，尤其在 高吞吐量写入和低延迟查询 的场景中，以下是一些典型的应用场景：

✅ 1. 实时广告数据存储
存储广告的 曝光、点击、转化、用户行为 数据，支持高效的 实时数据写入和读取。
对广告曝光量、点击量等进行 动态更新 和 查询，例如按 广告ID、时间戳、用户ID 等多维度进行查询。

✅ 2. 实时广告效果监控
用于 广告投放效果的实时监控，例如计算 广告投放的点击率（CTR） 和 转化率，并支持根据 广告主、时间、地区 等维度进行实时数据查询。

✅ 3. 实时行为分析
分析广告主和用户的 实时互动行为，如广告点击后用户的行为路径，提供 实时反馈，帮助广告主调整投放策略。

✅ 4. 用户行为日志存储
存储用户与广告互动的 实时日志数据，包括广告浏览、点击、跳转、转化等行为，支持根据用户ID进行快速查询和分析。

3️⃣ HBase 的劣势

限制	原因
复杂的管理与调优	HBase 需要更多的 配置和管理，尤其是在 集群扩展 和 性能调优 方面。需要熟悉 HBase 的 架构 和 操作管理。
高存储开销	与 传统关系数据库 比较，HBase 的存储效率较低。数据存储在多个副本上，增加了存储开销，适合大规模数据存储但不适合资源有限的环境。
不适合复杂查询	HBase 更适合 简单的查询和检索，对于复杂的 联结查询 和 聚合查询，性能可能较差。
低效的多表操作	HBase 适合存储结构化数据，但由于是 列式存储，对于跨表的数据关联查询性能较差，不如传统的 关系型数据库 或 NoSQL 数据库。

4️⃣ HBase 在广告数据中的适用场景
HBase 特别适合 广告平台 在以下几种场景中使用：
✅ 1. 广告数据的实时存储
在广告投放中，可以使用 HBase 存储广告曝光量、点击量、转化量等数据，数据的写入速度和读取速度都很高。
广告数据通过 HBase 表 存储，并根据广告ID、日期、渠道等维度进行 查询和更新。
✅ 2. 实时数据查询与分析
通过 HBase 的随机读写能力，可以实现广告平台中的 实时查询，例如，广告投放后，立即计算其 点击率、转化率 等。
可以根据 广告ID、时间、地域、广告主 等维度，快速查询广告的 实时效果。
✅ 3. 实时广告效果监控
广告平台可以实时监控 广告投放效果，如广告的 曝光、点击、转化量，并可以根据这些指标进行 数据反馈 和 调整投放策略。

5️⃣ 结论
HBase 是非常适合存储广告数据的系统，尤其在 实时广告数据存储、查询和快速写入 的场景中。它可以为广告平台提供 高吞吐量的写入能力 和 低延迟的查询性能。

🚀 推荐方案：
实时广告数据存储与查询： 使用 HBase 存储广告平台中的 实时曝光、点击、转化等数据，并通过 HBase 的快速读取能力 实现对广告效果的实时分析和反馈。
🚫 不适合复杂查询： 如果需要 复杂的多表查询 或 聚合分析，可能需要结合 Elasticsearch 或 ClickHouse 等工具来提供更高效的查询能力。

示例代码

Kafka 作为广告日志数据的消息队列，持续接收高并发数据流。
Flink 订阅 Kafka 数据流，进行广告效果的实时计算（例如广告点击率、曝光次数）。
Elasticsearch 作为存储引擎，支持高效查询和聚合分析，将 Flink 处理后的数据存入 ES。

import org.apache.flink.api.common.serialization.SimpleStringSchema;
import org.apache.flink.streaming.api.datastream.DataStream;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.connectors.elasticsearch.ElasticsearchSink;
import org.apache.flink.streaming.connectors.elasticsearch.RequestIndexer;
import org.apache.flink.streaming.connectors.elasticsearch6.ElasticsearchSink.Builder;
import org.apache.flink.streaming.connectors.kafka.FlinkKafkaConsumer;
import org.apache.http.HttpHost;
import org.elasticsearch.action.index.IndexRequest;
import org.elasticsearch.client.Requests;

import java.util.*;
import java.util.concurrent.ThreadLocalRandom;

public class KafkaFlinkElasticsearch {
    public static void main(String[] args) throws Exception {
        final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        // Kafka 配置
        Properties kafkaProps = new Properties();
        kafkaProps.setProperty("bootstrap.servers", "localhost:9092");
        kafkaProps.setProperty("group.id", "ad-log-group");

        // Flink 消费 Kafka
        DataStream<String> adLogStream = env.addSource(
                new FlinkKafkaConsumer<>("ad_logs", new SimpleStringSchema(), kafkaProps));

        // 数据转换：模拟广告效果统计（曝光、点击率计算）
        DataStream<Map<String, Object>> processedStream = adLogStream.map(log -> {
            Map<String, Object> adData = new HashMap<>();
            adData.put("ad_id", UUID.randomUUID().toString());
            adData.put("timestamp", System.currentTimeMillis());
            adData.put("views", ThreadLocalRandom.current().nextInt(100, 1000));
            adData.put("clicks", ThreadLocalRandom.current().nextInt(1, 100));
            return adData;
        });

        // Elasticsearch 配置
        List<HttpHost> httpHosts = Collections.singletonList(new HttpHost("localhost", 9200, "http"));

        ElasticsearchSink<Map<String, Object>> esSink = new Builder<>(httpHosts, (Map<String, Object> element, RequestIndexer indexer) -> {
            IndexRequest indexRequest = Requests.indexRequest()
                    .index("ad_reports")
                    .type("_doc")
                    .source(element);
            indexer.add(indexRequest);
        }).build();

        // 写入 Elasticsearch
        processedStream.addSink(esSink);

        env.execute("Kafka to Flink to Elasticsearch");
    }
}

在生产环境中，这个 Kafka + Flink + Elasticsearch 任务应该作为一个长期运行的实时流处理 Job，通常由任务调度框架管理，例如：

Flink 自身的 JobManager + TaskManager
直接部署 Flink 集群，提交 Job 后，由 Flink 进行调度和容错管理。

Kubernetes (K8s) + Flink Operator
使用 Flink Kubernetes Operator 在 K8s 集群中管理 Flink 任务，可以自动恢复失败的 Job。

YARN / Mesos 资源调度
如果使用 Hadoop 生态，可以运行在 YARN session 或 per-job cluster 模式下，由 YARN 进行资源管理。

任务调度系统 (Airflow, DolphinScheduler, Azkaban, etc.)
通过 Apache Airflow 或 DolphinScheduler 调度 Flink Job，确保任务按照 SLA 运行，支持重试和监控。

如何在生产环境运行？
如果你要让这个 Flink Job 在生产环境中长期运行，建议采用 Standalone / Kubernetes / YARN 方式部署。例如：

flink run -m yarn-cluster -p 4 -c com.example.KafkaFlinkElasticsearch kafka-flink-es.jar

或

kubectl apply -f flink-job.yaml

并结合 Grafana + Prometheus 监控 Flink 任务的状态，确保其长期稳定运行。