破晓

From 0.11.0 release, we have upgraded the HBase version to 2.4.9, which is released based on Hadoop 2.x. Hudi’s metadata table uses HFile as the base file format, relying on the HBase library. When enabling metadata table in a Hudi table on HDFS using Hadoop 3.x, NoSuchMethodError can be thrown due to compatibility issues between Hadoop 2.x and 3.x. 简述hudi的metadata table使用HFile作为基础文件格式，HFile依赖于HBase库。在Hudi0.12.1中使用HBase2.4.9版本，HBase2.4.9默认构建在Hadoop2.X，因此在HDFS3.x上使用Hudi metadata table会出现兼容性问题。抛 ...

问题描述将从Kafka读取CDC日志写入Hudi的Flink SQL作业部署到集群后，发现Flink Job Manager频繁打印以下日志，差不多1000次每秒，非常恐怖。Job Manager日志文件快速膨胀，占用大量磁盘空间，已经影响到集群稳定性。 12342022-12-04 09:24:40,897 INFO org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient [] - SASL encryption trust check: localHostTrusted = false, remoteHostTrusted = false2022-12-04 09:24:40,899 INFO org.apache.hadoop.hdfs.protocol.datatransfer.sasl.SaslDataTransferClient [] - SASL encryption trust check: localHostTrusted = false, remoteHostTrusted ...

修复dolphinscheduler2.0.5中http-alert plugin丢失告警信息的Bug http-alert告警插件仅仅发送用户预定义好的post body信息，丢失最重要Task运行告警信息。这是一个非常简单的Bug：https://github.com/apache/dolphinscheduler/commit/6021c228a1261a45ba8d02606f7132cd0a9b4c25 git clone dolphinscheduler项目，然后切到2.0.5-release分支，执行mvn -U clean package -Prelease -Dmaven.test.skip=true进行编译打包。打包成功后，将生成的dolphinscheduler\dolphinscheduler-alert\dolphinscheduler-alert-plugins\dolphinscheduler-alert-http\target\dolphinscheduler-alert-http-2.0.6-SNAPSHOT.jar替换掉原来的jar包。 启停 A ...

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. 基本概念： 1、Netty是对JDK NIO进行的一系列封装，使得更容易更快速的编写出高性能的安全的网络应用程序。 2、Java NIO与BIO一个重要的不同点是非阻塞，在Linux中，Java NIO依赖于Linux的epoll实现. 3、epoll是Linux中的专有名词或实现：epoll是一种I/O事件通知机制，是linux 内核实现IO多路复用的一个实现。 Linu主要通过暴漏三个系统调用供上层应用使用epoll：int epoll_create(int size)、 int epoll_ctl(int epfd， int op， int fd， struct epoll_event *event)、int epoll_wait(int epfd， st ...

前言 TCP是一个流协议，就是没有界限的一长串二进制数据。TCP作为传输层协议并不不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。面向流的通信是无消息保护边界的。 UDP：本身作为无连接的不可靠的传输协议（适合频繁发送较小的数据包），他不会对数据包进行合并发送（也就没有 Nagle 算法之说了），他直接是一端发送什么数据，直接就发出去了，既然他不会对数据合并，每一个数据包都是完整的（数据+UDP 头+IP 头等等发一 次数据封装一次）也就没有粘包一说了。 1、客户端要发送的数据小于TCP发送缓冲区的大小，TCP为了提升效率，将多个写入缓冲区的数据包一次发送出去，多个数据包粘在一起，造成粘包； 2、服务端的应用层没有及时处理接收缓冲区中的数据，再次进行读取时出现粘包问题； 3、数据发送过快，数据包堆积导致缓冲区积压多个数据后才一次性发送出去； 4、拆包一般由于一次发送的数据包太大，超过MSS的大小，那么这个 ...

前言在Apache Hadoop3.x社区二进制发行版中已经包含hadoop-snappy，同时Centos7已经自带snappy本地库。因此Hadoop3.x+Centos7无需配置snappy本地库。可运行hadoop checknative -a检查snappy本地库是否可用。 看了网上繁琐的Hadoop Snappy配置过程，配置了半天，才发现是白费功夫。原来是Hive的一个Bug。 Hive3.1.2中orc文件snappy压缩的BugBug描述 创建一个Hive表，存储为orc文件，同时启用snappy压缩。 12345678CREATE TABLE `default`.`user_orc` ( `tid` INT, `userid` STRING)STORED AS orcTBLPROPERTIES ( "orc.compress"="SNAPPY"); Insert overwrite进一些数据 1insert overwrite table user_orc select * from user_1; 会在HDFS ...

Kyuubi 将 Spark ThriftServer 的使用扩展为基于统一接口的多租户模型，并依靠多租户的概念与集群管理器交互，最终获得资源共享/隔离和数据安全的能力。Kyuubi Server 和 Engine 的松耦合架构大大提高了服务本身的并发性和服务稳定性。 What-Kyuubi是什么Apache Kyuubi (Incubating)，一个分布式和多租户网关，用于在 Lakehouse 上提供 Serverless SQL。 简单的来说Kyuubi就是一个SQL网关，用来将用户需要执行的SQL交给对应的计算引擎执行，如Spark、Flink等。作为一个优秀的网关，Kyuubi理所当然的实现了负载均衡、HA、多租户等功能。 正是这些功能，保证了Spark SQL可以真正的在企业内可用、好用、稳定的运行。 Why-为什么需要Kyuubi 当然是Spark Thrift Server不好用，甚至可以说在生产上不可用（不支持HA和多租户），Spark SQL无法大展拳脚，因此诞生了Kyuubi。 HowHow: Kyuubi on Spark最佳实践 spa ...

read/write读常规文件是不会阻塞的，不管读多少字节，read一定会在有限的时间内返回。从终端设备或网络读则不一定，如果从终端输入的数据没有换行符，调用read读终端设备就会阻塞，如果网络上没有接收到数据包，调用read从网络读就会阻塞，至于会阻塞多长时间也是不确定的，如果一直没有数据到达就一直阻塞在那里。同样，写常规文件是不会阻塞的，而向终端设备或网络写则不一定。 现在明确一下阻塞（Block）这个概念。当进程调用一个阻塞的系统函数时，该进程被置于睡眠（Sleep）状态，这时内核调度其它进程运行，直到该进程等待的事件发生了（比如网络上接收到数据包，或者调用sleep指定的睡眠时间到了）它才有可能继续运行。与睡眠状态相对的是运行（Running）状态，在Linux内核中，处于运行状态的进程分为两种情况： 正在被调度执行。CPU处于该进程的上下文环境中，程序计数器（eip）里保存着该进程的指令地址，通用寄存器里保存着该进程运算过程的中间结果，正在执行该进程的指令，正在读写该进程的地址空间。 就绪状态。该进程不需要等待什么事件发生，随时都可以执行，但CPU暂时还在执行另一 ...

虚拟内存可以提高系统的稳定性和安全性，主要通过以下两点： 1、控制物理内存的访问权限。 例如，Text Segment被只读保护起来，防止被错误的指令意外改写，内核地址空间也被保护起来，防止在用户模式下执行错误的指令意外改写内核数据。这样，执行错误指令或恶意代码的破坏能力受到了限制，顶多使当前进程因段错误终止，而不会影响整个系统的稳定性。 2、让每个进程有独立的地址空间。 所谓独立的地址空间是指，不同进程中的同一个VA被MMU映射到不同的PA，并且在某一个进程中访问任何地址都不可能访问到另外一个进程的数据，这样使得任何一个进程由于执行错误指令或恶意代码导致的非法内存访问都不会意外改写其它进程的数据，不会影响其它进程的运行，从而保证整个系统的稳定性。 虚拟内存 + 共享库可以大大节省内存。比如libc共享库，系统中几乎所有的进程都映射libc到自己的进程地址空间，而libc的只读部分在物理内存中只需要存在一份，就可以被所有进程共享，这就是“共享库”这个名称的由来了。 虚拟内存方便给分配和释放内存带来方便，物理地址不连续的几块内存可以映射成虚拟地址连续的一块内存。虚拟内存带 ...

前言 随着数据量不断膨胀，基于Oracle的ETL和BI报表可视化业务越来越慢，难以保证数据服务的SLA，为了减少整个大数据平台的复杂度，决定开始调研-‘以 Apache Doris 为核心建设一站式数据中台’。 展望： 1、所有业务数据通过Flink实时导入到Doris 2、ETL全部在Doris中完成 3、ETL后，基于Doris的ad-hoc能力，可以直接作为ADS层对外提供服务。 遇到的问题 由于业务非常复杂，ETL过程也非常繁琐，往往涉及数十张表的Join，这非常考验Doris的查询优化器。同时ETL SQL中常常需要开窗排序，非常容易造成内存溢出，导致ETL SQL无法完成。以应对大查询，做了以下参数方面的优化。 SET enable_profile = true; SET query_timeout = 30000; SET enable_spilling = true; SET exec_mem_limit = 10 * 1024 * 1024 * 1024; SET parallel_fragment_exec_inst ...