郑州做网站wordpress adsense integrator

1.ClickHouse 在项目中扮演的是什么角色

ClickHouse 是一个高性能的实时分析型数据库，能够存储海量数据并且进行低延迟查询，并且支持复杂的聚合计算。

存储海量数据：列式存储+优秀的压缩能力，并且索引采用稀疏索引和跳数索引。

低延迟查询：数据都是顺序存储，并且会以压缩数据块的形式被写入.bin文件中，还支持向量化查询

支持复杂的聚合计算：通过 AggregatingMergeTree 表引擎或物化视图，提前按指定维度聚合数据，将复杂查询转换为语句和结果的简单合并。

ClickHouse支持从Kafka实时摄入日志或事件数据，可以直接通过SQL实现如漏斗分析、留存率计算等复杂需求，可以替代掉Hive+Spark的复杂流程。

ClickHouse也可以直接对接BI组件，实现即席查询等功能。

因此，ClickHouse 可以用于存储DW层及以上的数据并且能实现高速查询。

2.可不可以去掉 ClickHouse 这个组件，为什么

可以。

首先 ClickHouse 的主要定位是实时数据分析数据库，能存储海量数据、可以低延迟查询等等。虽然定位在实时数据分析，但实际上离线项目也可以使用ClickHouse。

在离线项目中，数据存储可以使用Hbase、Hive，复杂查询可以通过Spark作业来完成，或者使用Kylin来实现快速查询并对接BI工具等。

在实时项目中，数据可以全部存储在Kafka或是将ODS层放在Kafka，DW层及以上放在Doris等。

当然，具体需不需要去掉ClickHouse还是要根据业务需求来决定，例如数据量小且分析简单、对实时性要求低、业务没有复杂聚合等可以去掉ClickHouse；但是如果需要存储海量数据，并且具备复杂分析，还要实现高吞吐写入、低延迟查询等就可以选择使用ClickHouse或者是Doris了。

3.Flink 将计算结果写入 ClickHouse 如何实现数据一致性

首先我们知道，ClickHouse 是没有完整的事务支持的，那么想要保证数据一致性就需要其他方法来实现。

所需要的一致性级别要根据具体业务来进行选择：

如果是 允许幂等去重的场景（如统计求和） 可以使用Flink的 至少一次（At-Least-Once）+ 幂等写入来实现，核心就是允许Filnk重试导致的数据重复，然后通过 ClickHouse的 ReplacingMergeTree 实现去重。

如果是 要求严格一致的场景（如金融对账） 可以通过 Flink 的两阶段提交（2PC）或预写日志（WAL），然后因为ClickHouse没有完整的事务支持，所以我们可以选择 预写日志 + ReplacingMergeTree 实现插入的幂等性。

如果是 允许延迟的聚合场景（如预聚合表）那么ClickHouse的表引擎就可以实现： GROUP BY 去重或 FINAL查询，即 ClickHouse 保证的是最终一致性。

4.ClickHouse 的表引擎有哪些，各有什么特点和适用场景？

MergeTree系列作为ClickHouse 最核心的引擎家族，适用于大规模数据分析和高性能查询场景，支

持主键索引、数据分区、压缩及后台合并等特性。

ReplacingMergeTree：实现了一定程度上的数据去重

SummingMergeTree：适合预聚合统计

AggregatingMergeTree：存储预聚合中间状态，需配合物化视图使用

CollapsingMergeTree：适合记录状态变化的场景

VersionedCollapsingMergeTree：解决乱序数据写入问题

log系列的轻量级引擎，适用于小规模数据快速写入和批量读取。不支持索引、分区等高级特性，不支持并发读写等。

集成外部存储的引擎：用于与其他系统无缝集成，支持外部数据映射或实时同步，MySQL 引擎，HDFS 引擎，Kafka 引擎等，其中Kafka 引擎订阅 Kafka 消息流，支持实时数据消费，用于流式数据处理和实时分析。这些表引擎只负责元数据管理和数据查询。

外部引擎：Memory数据仅存储在内存中，重启后丢失，一般临时数据缓存或测试环境使用。

5.ClickHouse 提高查询性能的方法有哪些？

1）建表优化

数据类型：

在建表时能用数值类型和日期时间类型表示的字段就不要用字符串

ClickHouse底层在处理 DateTime 时会将其转成时间戳进行存储，我们不需要指定为UInt64来存储。DataTime本身不需要经过函数转换处理，执行效率高，可读性好

除了特殊情况不要将空值设定为Null，可以用一个不可能出现的默认值或是业务中无意义的来代指空

分区和索引：按照业务需求来确定分区粒度，通过 ORDER BY 来指定索引列的时候，应该指定查询中经常被用来充当筛选条件的列，如果是组合维度，索引列要满足查询频率大的在前原则

表参数：对于不需要保留全量历史数据的表，可以指定TTL

写入和删除优化：尽量不要执行单条或小批量删除、插入操作

2）查询优化：

使用合适的查询结构：

使用 LIMIT 和 OFFSET 控制查询结果的大小，避免全表扫描。

尽量避免使用 JOIN 操作，ClickHouse 是列式存储数据库，在复杂的 JOIN 操作中性能可能下降。

使用合适的 WHERE 子句过滤条件，可以减少扫描的数据量。特别是在大数据表中，适当的WHERE 条件可以避免全表扫描。

**使用物化视图**（**Materialized Views**）：在计算复杂查询结果时，可以使用物化视图缓存计算结果，从而避免每次查询时重复计算。

物化视图适用于频繁执行相同聚合、计算或者汇总的场景。

避免使用子查询：尽量避免在查询中使用子查询，因为 ClickHouse 的查询引擎会将子查询中的数据当做独立的查询来处理，可能会降低性能。

如果子查询结果比较小，可以考虑将其转化为临时表或物化视图。

利用合适的索引：虽然 ClickHouse 并不支持传统意义上的 B-Tree 索引，但可以通过主键（ PRIMARY KEY ）和 ORDER BY 来进行数据排序，从而提高查询性能。利用排序索引进行范围查询，可以避免全表扫描。

分片查询：如果查询是跨多个分区，可以使用 Distributed 引擎，将查询分发到多个节点并行执行，提高查询效率。

3）语法优化：

• 如果要统计一张表有多少行，可以直接使用 COUNT() 或 COUNT(*) 即可

• 谓词下推

• 消除子查询重复字段

• 聚合计算外推

• 聚合函数消除