大数据组件优缺点

flink on hudi?

痛点：

 1） flink on hudi Schema Evolution问题？
  Schema evolution 大致可以分为4种：
  Backwards compatible: 向后兼容，用新的 schema 可以读取旧数据，如果字段没值，就用 default 值，这也是 Hudi 提供的兼容方式。
  Forwards compatible: 向前兼容，用旧 schema 可以读取新数据，Avro 将忽略新加的字段，如果要向前兼容，删掉的字段必须要有默认值。
  Full compatible: 支持向前兼容，向后兼容，如果要全兼容，那么就需要只添加有默认值的字段，并且只移除有默认值的字段。
  No Compatibility Checking：这种情况一般来说就是需要强制改变某个字段的类型，此时就需要做全量的数据迁移，不推荐。
  
 解决方法：
    Hudi中使用DataStream API操作的类org.apache.hudi.streamer.HoodieFlinkStreamer。通过两次启动任务传入的修改后的Avro Schema，也能实现官方文档Schema Evolution中例子类似的功能。
    但是按这种方式，只能通过重新定义schema并重启Flink任务，才能将源表新增的列同步到目标Hive表中，无法在启动任务后自动同步schema中未定义的源表中新增的列。
 所以需要对HoodieFlinkStreamer的功能进行改进。
 
 先说方案，经过对HoodieFlinkStreamer分析，其中用到的一些主要Function(Source、Map、Sink等)都是在最初定义时传入参数配置类，要么在构造方法中、要么在open方法中，
 根据配置（包含schema）生成deserialer、converter、writeClient等对数据进行反序列化、转换、保存的实例，由于是根据最初schema生成的实例，即使数据中有新增的字段，
 转换后新增的字段也没有保留。所以采用的方式是，在各个Function处理数据的方法中，判断如果数据中的schema与当前Function中的schema不一致（一种简单的优化），
 就使用数据中的schema重新生成这些deserialer、converter、writeClient，这样数据经过处理后，就有新增的字段。 


 2)  不支持并发写入
 
 3）集成问题：虽然Hudi提供了对Flink的支持，但是由于两者的设计理念和架构差异，集成过程可能会遇到一些问题，如数据格式不兼容、API不匹配等。
 
 4）性能问题：Flink和Hudi在处理大规模数据时可能会出现性能瓶颈。例如，Flink的流处理模式可能会导致Hudi的写入性能下降。
 
 5）稳定性问题：Flink和Hudi都是开源项目，可能存在一些未知的bug或者稳定性问题。尤其是在高并发、大数据量的场景下，这些问题可能会更加明显。
 
 6）功能支持：虽然Hudi支持Flink，但是可能并不支持Flink的所有功能，例如Flink的某些窗口操作、CEP等高级功能。
 
 7）运维难度：Flink和Hudi的运维难度相对较高，需要有一定的大数据基础和经验。例如，需要对Flink的作业调度、Hudi的数据管理等有深入的理解。

kudu优缺点：

1. 优点：

 一个table由多个tablet组成，能够很好地支持分区查看、扩容和数据高可用。
 Kudu提供了一种简单的原生存储方式，可以在一个平台上进行快速的分析和实时的数据更新。
 Kudu的数据模型是基于列的，这使得它在处理大数据分析时非常高效。
 Kudu支持在数据插入、更新和删除操作中进行实时的数据分析。
 Kudu的存储和查询性能非常高，它可以在大规模并行处理（MPP）数据库上进行高效的扫描。
 与imapla集成或spark集成后(dataframe)可通过标准的sql操作，使用起来很便捷

2. 缺点：

只有主键可以设置range分区。
 如果是pyspark连接kudu，则不能对kudu进行额外的操作。
 kudu的shell客户端不提供表schema查看。
 Kudu不支持复杂的数据类型，如数组、映射和结构体。
 Kudu的数据复制策略是基于raft协议的，这意味着在大规模的集群中，Kudu可能会遇到一些性能问题。
 Kudu不支持事务，这可能会在需要保证数据一致性的场景中造成问题。
 Kudu的社区相对较小，这可能会影响到问题的解决速度和软件的更新速度。

3. 常见优化点

https://zhuanlan.zhihu.com/p/426901943

4. 应用场景缺点

 读性能
  kudu的适用场景非常苛刻，必须走主键，否则，scan非主键列带来的是高CPU。
 大量写
  kudu是牺牲了写性能而提高读性能，主要体现在主键，所以在批量更新的时候会有大量的读。
  kudu可能更适用于实时场景，不断地写，这样对服务器的负载会低很多。
 合并小文件
  这个机制相对于Hive其实是优点，但合并小文件的负载同样不低，取决于你底层产生的小文件有多少，也是不读地读和写。 

impala优缺点：

1. 优点

基于内存运算，中间结果不需要落盘，节省了大量 I/O 开销
 无需转换为 MapReduce，直接访问存储在 HDFS，HBase 中的数据进行作业调度，查询速度快
 使用了数据本地化的 I/O 调度机制，尽可能将数据和计算分配在
 同一台机器上进行，减少了网络开销
 丰富的文件格式支持，如 TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet
 可以访问 hive 的 metastore，可以对 hive 数据直接做数据分析

2. 缺点

对内存的依赖较大，且完全依赖于 hive
 只能读取文本文件，而不能直接读取自定义二进制文件
 每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新

3.常见优化点

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

presto优缺点：

1. 优点

完全基于内存的并行计算
支持多种数据源接入，一条Presto查询可以将多个数据源的数据进行合并，可以跨越整个组织进行分析。
完全支持ANSI SQL标准，用户可以直接使用 ANSI SQL 进行数据查询和计算。
减少阶段间的等待时间，Mapreduce不支持DAG，maptask未完成，不能执行reduce，Presto采取管道式传输的方式，边清理内存，边计算。

2. 缺点

没有容错性：不支持单个query内部执行容错（query 中包含多个 Task,如果某个Task 失败了，会导致整个Query 失败，而不会进行把 task 在移动到其他工作节点处理重试）
不支持事务：不是数据库，不进行数据存储，不支持在线事务
内存限制: 基于内存计算，当内存空间不足时，不会将一部分结果保存到磁盘上，直接就查询失败，不适合大表的join操作。虽然能够处理 PB 级别的海量数据分析，但不是代表 Presto 把 PB 级别都放在内存中计算的。而是根据场景，如 count，avg 等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。但是连表查询，就可能产生大量的临时数据，因此速度会变慢，反而 Hive此时会更擅长。
并行限制：多个task 并行在worker节点进行计算，当其中一台worker计算缓慢，会让整个query流程效率变慢
并发限制：因为全内存操作+内存限制，能同时处理的数据量有限，因而导致并发能力不足。高并发支持不够，coordinator 容易成为瓶颈。
维护性：数据关联组件多、维护成本高。
查询性能：相较于doris、starrocks等MPP数据库，查询性能一般，无法满足业务方希望能快速获取数据的需求。
缺少 Bitmap 数据类型，在标签计算方面存在一些不足。

3. 优化点 https://mp.weixin.qq.com/s/Sc2ueamy5oYtI7x1kl4Omg https://zhuanlan.zhihu.com/p/162809568

clickhouse 优缺点:

1. 优点

为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
写入速度非常快，50-200M/s，对于大量的数据更新非常适用。
很强的单表查询性能，适合基于大宽表的OLAP多维分析查询。
包含丰富的MergeTree Family，支持预聚合。
非常适合大规模日志明细数据写入分析。

2. 缺点

不支持事务，事务可以是一条SQL语句或一组SQL语言或者整个程序，只要中间有任何错误这个事务的所有操作都要撤销。
缺少完整的UPDATE DELETE操作， 对于工具自动生成的语句不支持，必须通过变通的方式来完成这两类操作，仅能用于批量删除或者修改数据。
部分技术支持待完善，支持有限的操作系统，驱动程序不够完善，市面主流工具对其支持不全。
不支持BIOB DOCUMENT 类型数据，聚合结果必须小于一台机器的内存大小。
不支持高并发，官方建议qps为100，可以通过修改config.xml的max_concurrent_queries配置。
不支持二级索引
有限的SQL支持，join实现与众不同
不支持窗口功能
元数据管理需要人工干预维护，运维起来比较麻烦。
多表join效率性能比较低

3. 优化点

（1）关闭虚拟内存，物理内存和虚拟内存的数据交换，会导致查询变慢
（2）为每一个账户添加join_use_nulls配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值
（3）JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表
（4）批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致ClickHouse无法及时对新导入的数据进行合并，从而影响查询性能
（5）尽量减少JOIN时的左右表的数据量，必要时可以提前对某张表进行聚合操作，减少数据条数。有些时候，先GROUP BY再JOIN比先JOIN再GROUP BY查询时间更短
（6）ClickHouse的分布式表性能性价比不如物理表高，建表分区字段值不宜过多，防止数据导入过程磁盘可能会被打满
（7）CPU一般在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要非常关注

更多： https://blog.csdn.net/lxk199266/article/details/121778726

doris/starrocks优缺点？

1. 优点

单表查询和多表查询性能都很强，可以同时较好支持宽表查询场景和复杂多表查询。
支持高并发查询。
支持实时数据微批ETL处理。
流式和批量数据写入都能都比较强。
兼容MySQL协议和标准SQL。
能够保证数据的exactly-once
支持多种分布式Join方式，支持多种数据模型
架构简单，易于维护，无侵入式弹性伸缩与扩容
新版本支持存算分离，尽可能的减少依赖外部组件

2. 缺点

数据导入性能：虽然Doris/StarRocks支持多种数据导入方式，但在大数据量的情况下，数据导入性能可能会成为瓶颈。
数据更新：Doris/StarRocks的数据更新操作相对复杂，需要通过DELETE+INSERT的方式进行，这可能会影响到数据更新的效率。
数据一致性：在分布式环境中，保证数据的一致性是一大挑战。尽管Doris/StarRocks有一套完整的数据一致性保证机制，但在某些情况下，可能还是会出现数据不一致的问题。
内存消耗：Doris/StarRocks在处理大数据量的查询时，可能会消耗大量的内存，这可能会对系统的稳定性造成影响。
ETL能力：大规模ETL能力不足
flink-doris-connector写入是单并行度写入的，flink-connector-starrocks写入是可以支持多并行度写入的，多并行度情况下需要考虑如何保证数据有序性。

3. 极致的查询性能是如何保证的？

列式存储
索引
MPP分布式执行
pipeline并行执行框架
向量化执行引擎
CBO优化器
Global Runtime Filter
Metadata Cache
Local Data Cache
MATERIALIZED VIEW

4. 优化点

1：建表优化，选择合理的表模型，分区分桶，索引设计
2：CBO优化器开启
3：join优化，选择合理的join方式

4：明显数据导入时利用聚合模型优化统计数据
5：利用物化视图加速查询
6：利用bitMap类型，实现秒级海量用户标签圈选
7：利用query cache缓存中间计算结果
8: Sorted streaming aggregate完成有序的排序聚合
9：存算分离，实现数据的持久化
10：选择Zstd作为压缩格式
11：根据业务特点和需求调整Compaction相关参数
12：参数调优
    BE、FE内存，并行度、buffer缓冲大小、线程数等

https://mp.weixin.qq.com/s?__biz=Mzg4NDYzNjQ1Ng==&mid=2247493829&idx=1&sn=56c606fbc02160e82e369edbe5d81f5d&chksm=cfb78682f8c00f94a05262b6df6cc678ef040775d2ffd40a6c5248072298cf327d1fa3919ac7&token=1811615309&lang=zh_CN#rd
https://mp.weixin.qq.com/s?__biz=Mzg4NDYzNjQ1Ng==&mid=2247493559&idx=1&sn=708977c7765114595621df6f4a0aab17&chksm=cfb789f0f8c000e6ef222eb4a9bf76de0611a526ccff242e6271227b1c96661da88f48e6d015&token=1811615309&lang=zh_CN#rd

本文由 mdnice 多平台发布