茶网站源码,游戏开发学什么专业,长沙做推广的公司有多少,成都建设局官方网站ES 既不像 MySQL 这样有严格的 Schema#xff0c;也不像 MongoDB 那样完全无 Schema#xff0c;而是介于两者之间。
1️⃣ ES 的 Schema 模式 ES 默认是 Schema-less#xff08;无模式#xff09; 的#xff0c;允许动态添加字段。 但 ES 也支持 Schema#xff08;映射 …ES 既不像 MySQL 这样有严格的 Schema也不像 MongoDB 那样完全无 Schema而是介于两者之间。
1️⃣ ES 的 Schema 模式 ES 默认是 Schema-less无模式 的允许动态添加字段。 但 ES 也支持 Schema映射 Mapping可以手动定义字段类型类似 MySQL。 区别 MySQL 需要提前定义表结构ES 则可以自动识别字段类型但推荐手动定义。
2️⃣ ES vs MySQL vs MongoDB
特性ESElasticsearchMySQLMongoDBSchema 约束动态 Schema可手动定义严格 Schema表必须有固定结构无 Schema每条记录可有不同字段数据存储格式JSON 文档表行列存储BSON 文档索引方式自动索引所有字段全文检索优化索引需手动创建可选索引扩展性分布式架构横向扩展方便主从复制扩展有限分片副本可扩展查询方式DSL 查询类似 SQLSQL 查询BSON 查询
3️⃣ ES 的 Schema 示例 默认动态模式Schema-less 如果你没有手动定义 MappingES 会自动推测字段类型
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 适用于大规模搜索场景但不是严格关系型数据库的替代品
在 ElasticsearchES中索引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_idkeyword精准查询 timestampdate时间筛选 clickboolean是否点击广告 costfloat广告投放成本
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类似数据库的表每天创建一个文档DocumentES 中的具体记录类似数据库行数据字段FieldES 文档的属性类似数据库列分片Shard数据存储在多个分片中分片可以分布到多个节点副本Replica备份数据提升查询性能提高容灾能力
广告业务 每天索引 1 亿 数据ES 需要 按日期拆分索引并优化 查询和存储策略 以保证高效查询。 这样ES 就能高效存储广告曝光数据并支持 CTR 计算、广告点击查询等复杂业务需求
广告数据为什么不用 Mysql 来存储?
广告数据通常不适合存储在 MySQL主要原因是数据量巨大、查询需求复杂、实时性要求高。相比之下ElasticsearchES和 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 更高水平扩展不如 ESMongoDB 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、转化率分析广告效果。 例如
SELECTad_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 是一个 大数据处理框架包含了 HDFSHadoop 分布式文件系统 和 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 和 ClickHouseHadoop 的集群管理、调优和查询更复杂通常需要更多的技术投入。延迟写入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 消费 KafkaDataStreamString adLogStream env.addSource(new FlinkKafkaConsumer(ad_logs, new SimpleStringSchema(), kafkaProps));// 数据转换模拟广告效果统计曝光、点击率计算DataStreamMapString, Object processedStream adLogStream.map(log - {MapString, 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 配置ListHttpHost httpHosts Collections.singletonList(new HttpHost(localhost, 9200, http));ElasticsearchSinkMapString, Object esSink new Builder(httpHosts, (MapString, Object element, RequestIndexer indexer) - {IndexRequest indexRequest Requests.indexRequest().index(ad_reports).type(_doc).source(element);indexer.add(indexRequest);}).build();// 写入 ElasticsearchprocessedStream.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 任务的状态确保其长期稳定运行。
