大数据技术组件选型对比

中间件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因其快速的响应能力当之无愧作为首选查询分析工具。

一些常见优化：

1、 尽量将StateStore和Catalog单独部署到同一个节点，保证他们正常通信。
2、 通过对Impala Daemon内存限制（默认256M）及StateStore工作线程数，来提高Impala的执行效率。
3、 SQL优化，使用之前调用执行计划
4、 选择合适的文件格式进行存储，提高查询效率。
5、 避免产生很多小文件（如果有其他程序产生的小文件，可以使用中间表，将小文件数据存放到中间表。然后通过insert…select…方式中间表的数据插入到最终表中）
6、 使用合适的分区技术，根据分区粒度测算
7、 使用 compute stats进行表信息搜集，当一个内容表或分区明显变化，重新计算统计相关数据表或分区。因为行和不同值的数量差异可能导致impala选择不同的连接顺序时进行查询。
8、 网络io的优化：
–a.避免把整个数据发送到客户端
–b.尽可能的做条件过滤
–c.使用limit字句
–d.输出文件时，避免使用美化输出
–e.尽量少用全量元数据的刷新
9、 使用profile输出底层信息计划，在做相应环境优化

presto
presto是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可以对各种用户特征进行数据加工，制作成包含全部用户的一张或多张用户特征表，提供灵活的用户画像分析，支撑广告，圈人等业务需求等等。

starrocks
StarRocks 是新一代极速全场景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能力不足。

• 资源隔离还不完善，不支持容器化部署。

• 数据全内存计算，对内存要求较高。

单表查询：starrocks>开源doris>=clickhouse > impala > presto > sparksql > greeplum > hive

关联查询:  starrocks>开源doris>presto > impala > greeplum > clickhouse > sparksql > hive

推荐阅读：
世界的真实格局分析，地球人类社会底层运行原理
不是你需要中台，而是一名合格的架构师（附各大厂中台建设PPT）

企业IT技术架构规划方案

论数字化转型——转什么，如何转？

华为干部与人才发展手册（附PPT）

企业10大管理流程图，数字化转型从业者必备！

【中台实践】华为大数据中台架构分享.pdf

华为的数字化转型方法论

华为如何实施数字化转型（附PPT）

超详细280页Docker实战文档！开放下载

华为大数据解决方案（PPT）