大数据技术组件选型对比

中间件pulsar vs kafka

大数据技术组件选型对比_第1张图片 

Flink CDC vs Debezium

大数据技术组件选型对比_第2张图片
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引擎对比

 大数据技术组件选型对比_第3张图片

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

大数据技术组件选型对比_第4张图片

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能力不足。

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

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

大数据技术组件选型对比_第5张图片

大数据技术组件选型对比_第6张图片
大数据技术组件选型对比_第7张图片
大数据技术组件选型对比_第8张图片

单表查询: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)

你可能感兴趣的:(数据库,大数据,分布式,编程语言,hadoop)