中间件pulsar vs kafka
Flink CDC vs Debezium
Flink CDC更灵活，支持DataStream API和SQL两种方式同步数据，便于对数据做⼀些ETL,
Flink CDC分布式架构不仅仅体现在数据读取能⼒的⽔平扩展 上，更重要的是在⼤数据场景下分布式系统接⼊能⼒。例如 Flink CDC 的数据⼊湖或者⼊仓的时候，下游通常 是分布式的系统，如 Hive、HDFS、Iceberg、Hudi 等。另外，在⽣态⽅⾯，这⾥指的是下游的⼀些数据库或者数据源的⽀持。Flink CDC 下游有丰富的 Connector，例如写⼊到 TiDB、MySQL、Pg、Hbase、Kafka、ClickHouse 等常⻅的⼀些系统，也⽀持各种⾃定义 connector。
但是 DataX、Debezium 等则需要通过脚本或者模板去做，所以⽤户的使⽤⻔槛会⽐较⾼
数据湖三剑客对比
Databricks 最近开发了一个类似的功能，他们称之为Change Data Feed，他们一直持有该功能，直到最终在 Delta Lake 2.0 中开源。Iceberg 有增量读取，但它只允许您读取增量附加，没有更新/删除，这对于真正的变更数据捕获和事务数据至关重要。
Apache Iceberg 经常强调的一个特性是隐藏分区，它解锁了所谓的分区演化。基本思想是当您的数据开始演变，或者您只是没有从当前分区方案中获得所需的性能价值时，分区演变允许您更新分区以获取新数据而无需重写数据。当你进化你的分区时，旧数据会留在旧的分区方案中，只有新数据会随着你的进化而分区。如果用户不了解演化历史，则以多种方式分区的表会将复杂性推给用户，并且无法保证一致的性能。
在最近的版本中，Apache Hudi 为 Lakehouse 创建了首创的高性能索引子系统，我们称之为Hudi 多模式索引。Apache Hudi 提供了一种异步索引机制，允许您在不影响写入延迟的情况下构建和更改索引。这种索引机制具有可扩展性和可扩展性，可以支持任何流行的索引技术，例如 Bloom、Hash、Bitmap、R-tree 等。
这些索引存储在Hudi 元数据表中，该表存储在数据旁边的云存储中。在这个新版本中，元数据以优化的索引文件格式编写，与 Delta 或 Iceberg 通用文件格式相比，点查找的性能提高了 10-100 倍。在测试真实世界的工作负载时，这个新的索引子系统可将整体查询性能提高 10-30 倍
各种OLAP引擎对比
Druid
Druid同kylin一样，是采用预计算的方式。主要解决的是对于大量的基于时序的数据进行聚合查询。
是一个实时处理时序数据的OLAP数据库，因为它的索引首先按照时间分片，查询的时候也是按照时间线去路由索引。
- 需要预计算，将数据存储在druid的Segment文件中，占用一部分存储资源
- 需要与现场确认是否能提供
- 对sql支持不友好，需要用他自己的方言书写
Druid 是一个分布式的支持实时分析的数据存储系统，具有以下几个特点
- 亚秒级 OLAP 查询，包括多维过滤、Ad-hoc 的属性分组、快速聚合数据等等。
- 实时的数据消费，真正做到数据摄入实时、查询结果实时。
- 高效的多租户能力，最高可以做到几千用户同时在线查询。
- 扩展性强，支持 PB 级数据、千亿级事件快速处理，支持每秒数千查询并发。
- 极高的高可用保障，支持滚动升级。
实时数据分析是 Apache Druid 最典型的使用场景。该场景涵盖的面很广，例如：
- 实时指标监控
- 推荐模型
- 广告平台
- 搜索模型
Kylin
kylin是一种OLAP数据引擎，支持大数据生态圈的数据分析业务，主要是通过预计算的方式将用户设定的多维度数据立方体(cube)缓存起来，达到快速查询的目的。应用场景应该是针对复杂sql join后的数据缓存。
缺点：
集群依赖较多，如Hbase和Hive等，属于重量级方案，因此运维成本也较高。
查询的维度组合数量需要提前确定好，不适合即席查询分析.
预计算量大，集群依赖较多，资源消耗多.
适用场景：
数据仓库，用户行为分析，流量（日志）分析，自助分析平台，电商分析，广告效果分析，实时分析，数据服务平台等各种场景 。如：
- 用户数据存在于Hadoop HDFS中，利用Hive将HDFS文件数据以关系数据方式存取，数据量巨大，在500G以上
- 每天有数G甚至数十G的数据增量导入
- 有10个以内较为固定的分析维度
impala
Impala是Cloudera开发并开源的，能查询存储在HDFS和Hbase中的数据。同Hive一样，也是一种SQL on Hadoop解决方案。但Impala抛弃了MapReduce,使用更类似于传统的MPP数据库技术来提高查询速度。impala中间结果不写入磁盘
优点：
1)基于内存运算，不需要把中间结果写入磁盘，省掉了大量的I/O开销。
2)无需转换为Mapreduce，直接访问存储在HDFS，Hbase中的数据进行作业调度，速度快。
3)使用支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器进行，减少了网络开销。
4)支持各种文件格式，如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。
5)可以访问hive的metastore，对hive数据直接做数据分析。
缺点：
- 不支持用户定义函数 UDF。
- 不支持 text 域的全文搜索。
- 不支持 Transforms。
- 不支持查询期的容错。
- 对内存要求高,且完全依赖于hive。
- 实践中，分区超过1万，性能严重下降。
- 只能读取文本文件，而不能直接读取自定义二进制文件。每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新
适用场景：
在一些实时性要求很高的场景中，一方面满足实时性要求，一方面提升用户体验。Impala因其快速的响应能力当之无愧作为首选查询分析工具。
一些常见优化：
prestopresto是Facebook开源的大数据查询引擎，为了解决hive查询慢产生。使用java编写，数据全部在内存中处理。
优点：
- 完全基于内存的并行计算
- 支持多种数据源接入，一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。
- 完全支持ANSI SQL标准，用户可以直接使用 ANSI SQL 进行数据查询和计算。
缺点：
1）虽然能够处理PB级别的海量数据分析，但不是代表Presto把PB级别都放在内存中计算的。而是根据场景，如count，avg等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。
但是连表查询，就可能产生大量的临时数据，因此速度会变慢，反而Hive此时会更擅长。
2）为了达到实时查询，可能会想到用它直连MySql来操作查询，这效率并不会提升，瓶颈依然在MySql，此时还引入网络瓶颈，所以会比原本直接操作数据库要慢。
3) 对内存依赖非常大
4）不支持UDF
应用场景：
1、Presto 支持 SQL 并提供了一个标准数据库的语法特性，但其不是一个通常意义上的关系数据库。
2、Presto 是一个可选的工具，可以用来查询 HDFS
3、被设计为处理数据仓库和分析：分析数据，聚合大量的数据并产生报表，这些场景通常被定义为 OLAP
Impala的计算速度是其一大优点，多表查询性能和Presto差不多，单表查询方面却不如Presto好。而且Impala不支持update、delete操作，不支持Date数据类型，不支持ORC文件格式等，并且Impala在查询时占用的内存很大。相比于Impala,Presto综合性能要更好一些，无论是查询性能还是支持的数据源和数据格式方面都要突出一些。占用的内存比Impala也要少一些，比如多表join需要很大的内存，Impala占用的内存比presto要多。
clickhouse
Clickhouse是一个用于在线分析处理（OLAP）的列式数据库管理系统（DBMS）。
优点：
- 为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
- 数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
- 索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
- 写入速度非常快，50-200M/s，对于大量的数据更新非常适用。
- 很强的单表查询性能，适合基于大宽表的OLAP多维分析查询。
- 包含丰富的MergeTree Family，支持预聚合。
- 非常适合大规模日志明细数据写入分析。
缺点：
- 不支持真正的删除/更新支持 不支持事务
- 不支持二级索引
- 有限的SQL支持，join实现与众不同
- 不支持窗口功能
- 元数据管理需要人工干预维护，运维起来比较麻烦。
- 多表join效率性能比较低
- 不支持高并发，官方建议qps为100，可以通过修改config.xml的max_concurrent_queries配置。
- 建议1000条以上批量的写入，不建议单条记录修改和删除。
适用场景：
第一，用户行为分析。ClickHouse将用户行为分析表制作成一张大的宽表，减少join的形式，实现路径分析、漏斗分析、路径转化等功能。除此之外，它还能支撑广告，营销和AB实验。
第二，实时BI报表。ClickHouse可以根据业务需求，实时制作及时产出，查询灵活的BI报表，包括订单分析，营销效果分析，大促活动分析等等。
第三，监控。ClickHouse可以将系统和应用监控指标通过流式计算引擎Flink,Spark streaming清洗处理以后，实时写入ClickHouse。结合Grafna进行可视化展示。
第四，用户画像。ClickHouse可以对各种用户特征进行数据加工，制作成包含全部用户的一张或多张用户特征表，提供灵活的用户画像分析，支撑广告，圈人等业务需求等等。
starrocksStarRocks 是新一代极速全场景MPP数据库。StarRocks 的架构简洁，采用了全面向量化引擎，并配备全新设计的 CBO 优化器，查询速度快。
StarRocks 能很好地支持实时数据分析，并能实现对实时更新数据的高效查询。StarRocks 还支持现代化物化视图，以进一步加速查询。
使用 StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各类模型。
StarRocks 兼容 MySQL 协议，支持标准 SQL 语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。
优点：
- 单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。
- 支持高并发查询。
- 支持实时数据微批ETL处理。
- 流式和批量数据写入都能都比较强。
- 兼容MySQL协议和标准SQL。
- 能够保证数据的exactly-once
- 支持多种分布式Join方式，支持多种数据模型
- 架构简单，易于维护，无侵入式弹性伸缩与扩容
缺点：
- 大规模ETL能力不足。
- 资源隔离还不完善。
- 数据全内存计算，对内存要求较高。
适用场景：
StarRocks 可以满足企业级用户的多种分析需求，包括 OLAP 多维分析、定制报表、实时数据分析和 Ad-hoc 数据分析等。
doris
Apache Doris 是一款由百度开源的高性能MPP数据库。支持实时数据分析；分布式架构简洁，易于运维，可以支持10PB以上的超大数据集；可以满足多种数据分析需求，例如固定历史报表，实时数据分析，交互式数据分析和探索式数据分析等。
优点：
- 使用更简单，如建表更简单，SQL标准支持更好， Join性能更好，导数功能更强大
- 运维更简单，如灵活的扩缩容能力，故障节点自动恢复，社区提供的支持更好
- 分布式更强，支持事务和幂等性导数，物化视图自动聚合，查询自动路由，全面元数据管理
- 流式和批量数据写入都能都比较强。
缺点：
- 大规模ETL能力不足。
- 资源隔离还不完善，不支持容器化部署。
- 数据全内存计算，对内存要求较高。
