parquet

文章目录 1 Apache Iceberg 的底层数据组织 1.1 Apache Iceberg 用到的一些术语 1.1.1 数据文件（data files） 1.1.2 清单文件（Manifest file） 1.1.3 清单列表（Manifest list） 1.1.4 快照（Snapshot） 2 Apache Iceberg 表的数据组织 3 Apache Iceberg 时间旅行的实现 3.1 查询最新快照的数据 3.2 查询某个快照的数据 3.3 根据时间戳查看某个快照的数据 本文是《 Apache Iceberg 源码解析 》专题的第 2 篇，共 3 篇： Apache Iceberg 小文件合并原理及实践 Apache Iceberg 的时间旅行是如何实现的？ 一条数据在 Apache Iceberg 之旅：写过程分析 « 上一篇文章 下一篇文章 » 为了更好的使用 Apache Iceberg ，理解其时间旅行是很有必要的，这个其实也会对 Iceberg 表的读取过程有个大致了解。不过在介绍 Apache Iceberg 的时间旅行（Time travel）之前，我们需要了解 Apache Iceberg 的底层数据组织结构。 Apache Iceberg 的底层数据组织 我们在 《一条数据在 Apache Iceberg 之旅：写过程分析》

1、hdfs简介 1.1 什么是HDFS? HDFS（Hadoop Distributed File System）是hadoop生态系统的一个重要组成部分，是hadoop中的的存储组件，是最基础的一部分，MapReduce等计算模型都要依赖于存储在HDFS中的数据。HDFS是一个分布式文件系统，以流式数据访问模式存储超大文件，将数据分块存储到一个商业硬件集群内的不同机器上。 1.2 HDFS的设计目标 存储超大文件 HDFS适合存储大文件，单个文件大小通常在百MB以上 HDFS适合存储海量文件，总存储量可达PB,EB级 流式数据访问 为数据批处理而设计，关注数据访问的高吞吐量 硬件容错 基于普通机器搭建，硬件错误是常态而不是异常，因此错误检测和快速、自 动的恢复是HDFS最核心的架构目标 简单的一致性模型 一次写入，多次读取 一个文件经过创建、写入和关闭之后就不需要改变 不支持低时间延迟的数据访问 hdfs关心的是高数据吞吐量，不适合那些要求低时间延迟数据访问的应用。 本地计算 将计算移动到数据附近 1.3 HDFS的构成 数据块 文件以块为单位进行切分存储，块通常设置的比较大(最小6M，默认 128M) 块越大，寻址越快，读取效率越高，但同时由于MapReduce任务也是以 块为最小单位来处理，所以太大的块不利于于对数据的并行处理 一个文件至少占用一个块(逻辑概念) 冗余备份

这是【kudu pk parquet】的第二篇，query2在kudu和parquet上的对比解析，其中kudu包含有不能下发的谓词。 3台物理机，1T规模的数据集，impala和kudu版本是我们修改后支持runtime filter的版本，结果对比如下图： 纵坐标表示耗时，矮表示性能好，耗时短，响应差近三倍。 首先，来我们来看两者的执行计划，颜色越鲜艳表示越耗时： parquet kudu 可以看到kudu左右两边各有一个鲜艳的红色框（节点），说明这两个执行节点耗时比较长，放大来看： 左边部分： parquet kudu 上面两个图的执行计划红色圈起来部分，parquet的扫描（“05：SCAN KUDU”）和关联（“09：HASH JOIN”）分别只要1秒钟左右，而kudu则要7秒和11秒。 大家注意到了没有，“07：SCAN KUDU”这个节点在两个引擎上返回的数据量是不一样的，parquet只返回了5条记录，kudu则返回了25条。同时这个返回结果是作为runtime filter应用于“06：SCAN KUDU”的，所以可以看到“06：SCAN KUDU”节点上返回的数据量，呈现几何级的差异（条件宽泛，所以匹配的数据量就多了）。接着，过滤出来的结果再runtime filter应用于“05：SCAN KUDU”节点。为什么“05：SCAN KUDU

文章目录 1 spark.sql.adaptive.enabled 2 spark.sql.adaptive.minNumPostShufflePartitions 3 spark.sql.adaptive.shuffle.targetPostShuffleInputSize 4 spark.sql.allowMultipleContexts 5 spark.sql.autoBroadcastJoinThreshold 6 spark.sql.avro.compression.codec 7 spark.sql.broadcastTimeout 8 spark.sql.caseSensitive 9 spark.sql.cbo.enabled 10 spark.sql.cbo.joinReorder.enabled 11 spark.sql.cbo.starSchemaDetection 12 spark.sql.codegen.comments 13 spark.sql.codegen.factoryMode 14 spark.sql.codegen.fallback 15 spark.sql.codegen.hugeMethodLimit 16 spark.sql.codegen.useIdInClassName 17 spark.sql.codegen.maxFields

去年10月份放下了一手打造的缓存服务（NKV和NCR），投身到新成立的数据科学中心从事大数据存储相关的工作，新的部门、新的项目、新的知识，脚踏实地，从零开始。 第一款调研的对象是cloudera公司刚开源的kudu产品，可以将其理解为是hadoop系统中的hdfs，一个存储引擎，但是和hdfs的不同之处是它支持update操作，这点非常重要！ 可能是因为刚开源的缘故，文档中很多的的使用方式、操作步骤的描述都和cloudera manager（简称CM）紧紧的耦合在一起，所以一开始的时候，根本不清楚怎样独立部署kudu集群以及怎样是最佳部署方式。无奈，只好先从cloudera manager管理平台安装部署，然后等到熟悉以后再将其剥离出来，事实上后来剥离的kudu和impala的配置文件的配置参数就直接参考这里的。部署CM&CDH就花了九牛二虎之力，过程就不再细说，都是泪。 就像高富帅择偶一样，大公司cloudera出来的产品，对操作系统也是百般的挑剔，又要有绝对的话语权（root权限），所以一周又一周的要求sa帮忙续命（骚瑞啊，真的不是在耍你们，向sa们致以诚挚的敬意）。成功完成集群安装部署，面临着怎么来测试，用什么工具的尴尬，大家都没经验。 一开始，我们选择了ycsb来进行测试，有两种方式：一种是通过JDBC驱动的方式，另一种是通过kudu bind的方式