专门做消防器材的网站,网站开发相关参考文献资料,wordpress文自定义栏目在哪里,800多块做网站1.事务性
从事务性上来说#xff0c;iceberg具有更高的数据质量。 因为iceberg本质是一种table format#xff0c;屏蔽了底层的存储细节#xff0c;写入数据时候需要严格按照schema写入。而hive可以先写入底层数据#xff0c;然后使用load partition的方式来加载分区。这样…1.事务性
从事务性上来说iceberg具有更高的数据质量。 因为iceberg本质是一种table format屏蔽了底层的存储细节写入数据时候需要严格按照schema写入。而hive可以先写入底层数据然后使用load partition的方式来加载分区。这样就可能造成hive的实际存储数据与schema不一致。 另外hive的分区数据生成以后还可以直接删掉hdfs路径的文件(包括代码有bug无意中删除数据等)这样经常会存在分区数据不存在的场景。而iceberg基于快照提供了事务处理能力使其实现了读写分离能力。iceberg在执行delete操作或者overwrite操作时不会将原有的数据进行直接删除而是新增了一个snapshot在这个snapshot中引用新的数据文件这样就实现了事务处理。
2.降低数据pipeline延时
hive针对数据进行update操作时需要先将数据读取出来修改后再重新写有极大的修正成本。Iceberg 所具有的修改、删除能力能够有效地降低开销提升效率。 同时传统数仓从数据ETL到数据入库入仓流程一般较长需要后续加入一些验证逻辑保证数据的准确性。因为流程长架构也较为复杂所以数据入库所需时间也较长。而iceberg的事务性设计可以保证流程的简易性降低整个数据pipeline的延时。
3.对接不同计算引擎
iceberg 上层可以支持 Spark、Flink、Presto等多种计算引擎当只需要进行离线批处理的时候我们可以直接将iceberg当hive 表来使用通过 Spark iceberg 搭建原来的离线数据计算流。
当有实时指标计算的需求时可以使用 flink 实时计算框架来构建近实时数仓而且iceberg 存储全量数据且仍然有批计算能力可以在流式计算作业运行的同时跑一个批作业来进行数据回溯或者数据纠正。
4.小文件处理
在传统的实时数仓中由于列式存储相对行式存储有较高的查询性能我们一般采用parquetorc等列存储数据格式。但是这种列式格式无法追加流式数据又无法等候太长时间等到文件够了一个hdfs block块大小再写入。所以不可避免的产生了一个令人头大的问题即小文件问题。大量小文件会对namenode造成巨大的压力极大影响hdfs服务的稳定与性能因此如何解决小文件问题也是传统的hive数仓面临的一个重要课题。
传统的流式数据入库的过程中对小文件进行合并会产生很多问题比如流式数据不断的往hive表进行写入如果同时有一个合并程序进行小文件的合并那么这时候对同一份数据进行读写。会不会产生问题。如何保证事务出错了怎么回滚呢这些都是很棘手的问题。
而在iceberg中提供了相应的API来进行小文件合并。
SparkActions.get(spark).rewriteDataFiles(icebergTable).execute()5.统一接入数据源
通过iceberg 数据湖方案构建的近实时数仓可以将基于hive 的离线数仓和基于kafka等消息队列构建的实时数仓进行统一。你可以将日志数据、changeLog数据统一存储在iceberg 中通过 iceberg 构建数仓只需要维护一套存储甚至是一套计算链路。 同时 iceberg 还具有很好的开放性。得益于 spark 和 flink 的丰富的生态可以将 MySQL Binlog数据、日志数据导入到 Iceberg 进行分析也可以将 Iceberg 中的数据导入到 Hive、Doris等其他存储中进行分析。将一份数据导入 Iceberg你永远不用担心在使用数据的时候取不出来。
