parquet

1. 项目背景 传统数仓的组织架构是针对离线数据的OLAP（联机事务分析）需求设计的，常用的导入数据方式为采用sqoop或spark定时作业逐批将业务库数据导入数仓。随着数据分析对实时性要求的不断提高，按小时、甚至分钟级的数据同步越来越普遍。由此展开了基于spark/flink流处理机制的（准）实时同步系统的开发。 然而实时同步数仓从一开始就面临如下几个挑战： 小文件问题。不论是spark的microbatch模式，还是flink的逐条处理模式，每次写入HDFS时都是几M甚至几十KB的文件。长时间下来产生的大量小文件，会对HDFS namenode产生巨大的压力。 对update操作的支持。HDFS系统本身不支持数据的修改，无法实现同步过程中对记录进行修改。 事务性。不论是追加数据还是修改数据，如何保证事务性。即数据只在流处理程序commit操作时一次性写入HDFS，当程序rollback时，已写入或部分写入的数据能随之删除。 Hudi是针对以上问题的解决方案之一。以下是对Hudi的简单介绍，主要内容翻译自官网。 2. Hudi简介 2.1 时间线（Timeline） Hudi内部按照操作时刻（instant）对表的所有操作维护了一条时间线，由此可以提供表在某一时刻的视图，还能够高效的提取出延后到达的数据。每一个时刻包含： 时刻行为：对表操作的类型，包含： commit：提交

【一】SparkSQL数据源 【1】Spark SQL的DataFrame接口支持多种数据源的操作 一个DataFrame可以进行RDDs方式的操作，也可以被注册为临时表，把DataFrame注册为临时表之后，就可以对该DataFrame执行SQL查询 【2】 Spark SQL的默认数据源为 Parquet格式 。数据源为Parquet文件时，Spark SQL可以方便的执行所有的操作。修改配置项spark.sql.sources.default，可修改默认数据源格式 val df = sqlContext.read.load ( "examples/src/main/resources/users.parquet" ) df.select ( "name" , "favorite_color" ) .write.save ( "namesAndFavColors.parquet" ) 【3】当数据源格式不是parquet格式文件时，需要手动指定数据源的格式。数据源格式需要指定全名（例如：org.apache.spark.sql.parquet），如果数据源格式为内置格式，则只需要指定简称定json, parquet, jdbc, orc, libsvm, csv, text来指定数据的格式 可以通过SparkSession提供的 read.load 方法用于通用加载数据，使用

【推荐阅读】微服务还能火多久？>>> 本文以流式数据入库的场景为基础，介绍引入 Iceberg 作为落地格式和嵌入 Flink sink 的收益，并分析了当前可实现的框架及要点。 应用场景 流式数据入库，是大数据和数据湖的典型应用场景。上游的流式数据，如日志，或增量修改，通过数据总线，经过必要的处理后，汇聚并存储于数据湖，供下游的应用（如报表或者商业智能分析）使用。 上述的应用场景通常有如下的痛点，需要整个流程不断的优化： 支持流式数据写入 ，并保证端到端的不重不丢（即 exactly-once）； 尽量减少中间环节 ，能支持更实时（甚至是 T+0）的读取或导出，给下游提供更实时更准确的基础数据； 支持 ACID ，避免脏读等错误发生； 支持修改已落地的数据 ，虽然大数据和数据湖长于处理静态的或者缓慢变化的数据，即读多写少的场景，但方便的修改功能可以提升用户体验，避免用户因为极少的修改，手动更换整个数据文件，甚至是重新导出； 支持修改表结构 ，如增加或者变更列；而且变更不要引起数据的重新组织。 引入 Iceberg 作为 Flink sink 为了解决上述痛点，我们引入了 Iceberg 作为数据落地的格式。Iceberg 支持 ACID 事务、修改和删除、独立于计算引擎、支持表结构和分区方式动态变更等特性，很好的满足我们的需求。 同时，为了支持流式数据的写入，我们引入 Flink

一、自适应框架能解决什么问题 1、目前SparkSQL中reduce阶段的task个数取决于固定参数spark.sql.shuffle.partition(默认值200)，一个作业一旦设置了该参数，它运行过程中的所有阶段的reduce个数都是同一个值。 而对于不同的作业，以及同一个作业内的不同reduce阶段，实际的数据量大小可能相差很大，比如reduce阶段要处理的数据可能是10MB，也有可能是100GB, 如果使用同一个值对实际运行效率会产生很大影响，比如10MB的数据一个task就可以解决，如果spark.sql.shuffle.partition使用默认值200的话，那么10MB的数据就要被分成200个task处理，增加了调度开销，影响运行效率。 SparkSQL自适应框架可以通过设置shuffle partition的上下限区间，在这个区间内对不同作业不同阶段的reduce个数进行动态调整。 通过区间的设置，一方面可以大大减少调优的成本(不需要找到一个固定值)，另一方面同一个作业内部不同reduce阶段的reduce个数也能动态调整 参数如下： spark . sql . adaptive . enabled 默认false 自适应执行框架的开关 spark . sql . adaptive . minNumPostShufflePartitions 默认为1