矛始-优快云博客

原创 hudi系列-schema evolution(一)

在非schema on read模式下对schema进行变更需要注意以下情况可以增加新字段，但是建议只是追加，而且新schema数据需写入成功后才进行查询可以删减字段，一般不建议不可以改变列的数据类型不支持更改列名。

2024-06-27 18:42:07 624

hudi对schema evolution进行了统一设计，在官网文档中也指明了从0.11版本开始，spark-sql ddl是支持schema evolution的，而flink-sql在旧版本中并不支持ddl方式对表结构，所以full schema evolution都隐藏在读写过程中。对于使用者，我们最终只关心表的读和写，但从实现层面来看，schema evolution需要覆盖不同的数据文件格式，还需要集成在各种hudi的表服务中。

2024-04-15 19:31:26 670

原创 hudi系列-KeyGenerator & 分区提取器

KeyGenerator和分区提取器都是插件化，并均提供了多种开箱即用实现，基本能覆盖常用的场景。两者的选择主要是依赖于分区的数量和数据类型。

2023-07-18 09:26:53 1240

原创 hudi系列-timeline service

Timeline Service（时间线服务）是hudi的一个组件，用于暴露接口给客户端，是一个基于Javalin+Jetty实现的web服务。当客户端使用远程文件系统视图()时，就是访问时间线服务http接口默认情况下，如果开启了时间线服务，则它运行在JobManager(如果是spark，则在driver中)，所有写任务都会向它发出请求。

2023-06-26 19:23:54 1707

原创 hudi系列-文件系统视图(FileSystemView)

hudi表的数据一直在演变过程中，存储在文件系统中的数据文件也在不断增加和版本迭代，hudi提供了的文件系统视图(filesystem view)来简单、直观地了解表中的数据分布情况、数据文件的状态和变化，以及数据的版本控制信息。SliceView当然，文件系统视图持续进行着自我更新、重置，以保持最新视图。

2023-06-13 14:08:01 2085

原创 hudi系列-append写过程

Append模式每次都生成新的parquet文件，不涉及数据修改、去重。cow+insert一直是append模式，mor+insert在0.13.1后也统一走append写流程append写过程比upsert简单直接得多，因此写入性能远优于upsert.

2023-06-08 14:51:38 2037

原创 hudi系列-小文件优化

hudi使用mvcc来实现数据的读写一致性和并发控制，基于timeline实现对事务和表服务的管理，会产生大量比较小的数据文件和元数据文件。大量小文件会对存储和查询性能产生不利影响，包括增加文件系统的开销、文件管理的复杂性以及查询性能的下降。对于namenode而言，当整个集群中文件数到了几千万，就已经会变得很不稳定了。

2023-06-05 15:04:48 2271

原创 hudi系列-upsert写过程

hudi有很多种写入流程，使用不同的表类型、写类型()、索引类型(IndexType)，流程上都会有所差异。使用flink流式写MOR表场景比较多，顺道梳理一下这个流程的细节。

2023-04-23 18:11:55 2064

原创 hudi系列-增量查询ckp超时

hudi在对mor进行增量查询时会出现首次checkpoint超时报错，从现象到原因分析，并提出几种解决方案进行对比。

2023-04-08 19:00:00 1664

原创 hudi系列-基于cdc应用与优化

曾经做数据同步受存储引擎和采集工具的限制，经常都是全量定时同步，亦或是以自增ID或时间作为增量的依据进行增量定时同步，无论是哪种，都存在数据延时较大、会重复同步不变的数据、浪费资源等问题。后来刚接触canal时还大感惊奇，基于mysql的binlog可以这么方便实时同步最新数据，然而历史数据的初始化仍然得使用第三方ETL工具来全量同步。直到flink cdc项目诞生，完全解决了前面的痛点。实时技术的发展已经不能满足于数据只能实时采集，还需要实时地进行数据建模和数据分析，即全链路实时。

2023-03-30 20:03:21 1378

原创 hudi系列-数据写入方式及使用场景

hudi支持多种数据写入方式：insert、bulk_insert、upsert、boostrap，我们可以根据数据本身属性(append-only或upsert)来选择insert和upsert方式，同时也支持对历史数据的高效同步并嫁接到实时流程。

2023-03-14 16:51:14 2654 2

原创 hudi系列-不支持flink计算列

有个hudi mor的事实表，需要与外部的维表进行关联以生成明细宽表，方案是基于flink sql对事实表进行增量查询，同时与外部的维表进行lookup join，除了无需编码之外，通过jdbc的方式连接外部表还能利用flink jdbc-connector的缓存功能。这种join方式要求事实表必须有一个处理时间(process time)属性，所以在定义事实表时增加了一个计算列从flink sql的角度来看，这并没什么毛病，但是直接查这个表的数据时就会报错。

2023-02-18 22:55:59 2055 1

原创 hudi系列-文件布局（file layout）

hudi的文件布局是能实现增量查询、数据更新等特性的基础，每个hudi表有一个固定的目录，存放元数据(.hoodie)以及数据文件，其中数据文件可以以分区方式进行划分，每个分区有多个数据文件(基础文件和日志文件)，这些数据文件在逻辑上被组织为文件组、文件分片上面的示例中，2023-02-15这个分区下有一个文件组，文件中组中有3个文件切片，其中一个只有log文件，一个只有base文件。

2023-02-16 09:17:33 2008

原创 hudi系列-索引机制

hudi的索引机制是为了加速upsert/delete操作，它维护着（分区 + key）-> fileID之间的映射关系，所以可以减少对非必要base文件的合并key是指索引key，可以是表的任意字段，在全局索引中常用主键key作为索引。

2023-01-03 09:50:15 2412

原创 hudi系列-设置合理清理策略

在中介绍了清理的大致流程，除了可以防止文件系统的无限膨胀，它是必须的。hudi提供三种查询方式：读优化、快照读、增量读，无论是哪种方式，由于hudi的文件组织是有版本的概念(FileGroup,FileSlice)，旧版本的文件持续在执行清理，如果被清理的文件正在读取或者即将被读取到，那岂不是很影响使用，所以我们需要设置合理的清理策略保障上层数据处理任务的平稳运行，提高系统的容错性。可以通过来配置使用以上哪一种清理策略。

2022-11-08 20:56:32 3571 1

原创 hudi系列-changelog的读写

hudi自身支持FULL & UPSERT 两种模式，两种模式分别在写入与读取有所差异。

2022-10-31 20:38:31 3077

原创 hudi系列-借助hudi优化架构

引入hudi使用整个构架就是变得简单了，可以实现分钟级别的实时数仓，数据统一存储减少一致性的风险

2022-10-27 17:55:28 3342 1

原创 flink smallint类型不兼容hudi

flink smallint类型不兼容hudi

2022-10-17 15:40:25 3201

原创 hudi系列-文件归档（archive）

hudi会不断生成commit、deltacommit、clean等类型的Instant从而形成活跃时间轴（ActiveTimeline），随着时间增长，时间轴变长，.hoodie元数据目录下的文件不断累积，为了限制元数据文件数量，需要对一些比较久远的元数据文件进行归档，保存到.hoodie/archived目录下，可以称之为归档时间轴（ArchivedTimeline）。

2022-09-16 15:43:18 6321

原创 hudi系列-文件压缩（compaction）

压缩（compaction）仅作用于MergeOnRead类型表，MOR表每次增量提交（deltacommit）都会生成若干个日志文件（行存储的avro文件），为了避免读放大以及减少文件数量，需要配置合适的压缩策略将增量的log file合并到base file（parquet）中。...

2022-08-17 17:13:17 8389

原创 hudi系列-旧文件清理（clean）

hudi采用的是mvcc设计，提供了清理工具cleaner来把旧版本的文件分片删除，默认开启了清理功能，可以防止文件系统的存储空间和文件数量的无限增长。

2022-08-04 15:30:00 8987

原创 hudi系列-流式增量查询

hudi的两大特性流式查询和支持upsert/delete，hudi的数据变更是基于timeline的，所以时间点(Instant)就成为了实现增量查询的依据。在与flink集成中，当开启了流式读，其实就是一个持续的增量查询的过程，可以通过配置参数read.start-commit和read.end-commit来指定一个无状态的flinkjob的初始查询范围。...............

2022-07-29 17:06:24 8545

原创 Spark序列化 & Encoders

spark序列化方式分布式的程序存在着网络传输，无论是数据还是程序本身的序列化都是必不可少的。spark自身提供两种序列化方式：java序列化：这是spark默认的序列化方式，使用java的ObjectOutputStream框架，只要是实现了java.io.Serializable接口的类都可以，这种方式虽然通用但是性能差，占用的空间也比较大kryo序列化：相比于java序列化，kryo更高效且序列化结果紧凑，占用空间小，但是不能序列化所有数据类型，且为更好的性能，需要在程序中注册需要序列化的类

2022-02-12 12:56:05 11138

原创 Spark数据格式UnsafeRow

1. 简介UnsafeRow是InternalRow的子类，它表示一个可变的基于原始内存(raw-memory)的二进制行格式，简单来说UnsafeRow代表一行记录，用于替代java对象（属于Tungsten计划的一部分，可以减少内存使用以及GC开销）InternalRow：spark sql内部使用的表示行的抽象类，对应表示输出的行有org.apache.spark.sql.Row/GenericRow/GenericRowWithSchema2. 类属性private Object base

2022-01-14 12:49:22 8881 2

原创 Spark统一内存划分

文章目录executor内存逻辑架构Executor 界面内存计算UnrollMemory理解参考executor内存逻辑架构堆内存，由JVM分配和回收，由spark.executor.memory控制大小，JVM中序列化的对象是以字节流形式，其占用内存大小可直接计算，对于非序列化对象，其占用的内存是通过周期性地采样近似估算，且被spark标记为释放的对象实例也有可能并没有被JVM回收，所以spark并不能准确记录实际可用堆内存，也就无法避免内存溢出非堆内存，不受JVM管理，有两部分，其中一部分通

2022-01-06 11:29:08 8619

c语言算法大全

常用中文停词

用来测试tf-idf的4个新闻

catalogd.INFO.rar

空空如也