创建表是引擎的必备基本能力，引擎有很多，Hive、Spark、Flink、Trino等等，我们姑且只关注这些，创建的表按照是否跟引擎绑定，分为两大类：managed table和external table。以这里举例的引擎为例，它们都可以将表元数据维护在Hive Metastore中，对引擎来讲，这些表以external table的形式存在。

Iceberg作为一种表格式管理规范，其数据分为元数据和表数据。元数据和表数据独立存储，元数据目前支持存储在本地文件系统、HMS、Hadoop、JDBC数据库、AWS Glue和自定义存储。表数据支持本地文件系统、HDFS、S3、MinIO、OBS、OSS等。元数据存储基于HMS比较广泛，在这篇文章中，表数据存储基于MinIO、元数据存储主要基于HM...

随着数字化的深入发展，企业内部数据呈现出大规模且多样性的增长态势，数据业务场景愈发复杂，需要面对海量大数据场景下的实时处理、非结构化数据治理等需求。在这样的背景下，湖仓一体技术热度不断攀升，越来越多企业推出相关产品或解决方案。

其实，Spark识别Hive，也是需要依赖Hive配置项的，配置项的来源可以是$HIVE_HOME环境变量，也可以从Spark的运行环境的classpath下加载Hive相关的配置文件。

案例分析2.1 发现问题的过程在项目使用中，发现对于Timestamp的类型进行toJSONString()方法调用的时候，输出结构并没有按照预想的接果进行展示，后续单独拆出demo来进行研究

-对于用户指定的每个zorder字段，生成对应的z值。-把所有zorder字段生成的z值进行比特位的交叉组值，生成最终的z值。-根据最终z值，对所有数据进行排序。

每个Iceberg文件的头部元数据信息中记录了当前文件每个列的最大最小值，比如下图中的parquet文件数据记录包含两列：year和uid，file1.parquet中列year的最大和最小值分别是2019和2018，列uid的最大和最小值分别是23000和12000。

遇到一个Linux系统 glibc内存分配导致的OOM问题，根源是内存回收出现问题，导致碎片太多，内存无法回收，系统认为内存不够用了。涉及到以下知识点：1、Linux中典型的64M内存区域问题2、glibc内存分配器ptmalloc2的底层原理3、glibc的内存分配原理（Arean、Chunk、bins等）4、malloc_trim对内存回收的影响

flink中比较重要的是时间和状态，学习flink的过程中对水位线的理解一直模糊，经过一段时间的消化，在此总结总结。本文主要把水位线是什么，怎么来的，有什么用描述清楚。

但在实际生产环境中，数据是一直在变化的，有可能会出现这种情况：在还未完成数据合并任务时，对之前的数据做出了修改，这就导致正在合并的数据与新数据可能会产生冲突。

Hudi（Hadoop Update Delete Incremental）官方介绍是为数据湖之上提供事务支持、行级别更新/删除（Row Level Update/deletes）和变更流（Change Stream）的一个数据湖框架，最早是由Uber开发于2016年，2017进入开源社区，并在2020年成为Apache 顶级项目。本文会从Hudi诞生背景条件出发，搞清楚Hudi最初是为了解决什么问...

上篇提到为了解决任务调度粒度控制不够的问题，React引入了Fiber架构。Fiber将一个DOM更新任务拆分为由多个原子化可调度的节点组成的集合，从而提供了细粒度的任务调度能力。

在Flink中根据数据集是否根据Key进行分区，将状态分为Keyed State和Operator State（Non-keyed State）两种类型 ，在之前的文章《Flink中基于KeyedState的计算开发方法》已经详细介绍了Keyed State的概念和用法，本文将继续介绍Operator State。

前言状态在Flink中叫作State，用来保存中间计算结果或者缓存数据。根据是否需要保存中间结果，分为无状态计算和有状态计算。对于流计算而言，事件持续不断地产生，如果每次计算都是相互独立的，不依赖于上下游的事件，则是无状态计算。如果计算需要依赖于之前或者后续的事件，则是有状态计算。

作者:王东阳前言ANSI-SQL 2011 中提出了Temporal 的概念，Oracle，SQLServer，DB2等大的数据库厂商也先后实现了这个标准。Temporal Table记录了历史上任何时间点所有的数据改动，Temporal Table具有普通table的特性，有具体独特的DDL/DML/QUERY语法，时间是其核心属性。历史意味着时间，意味着快照Snapshot。

所谓Catalog即数据目录，简单讲，Catalog是企业用于管理数据资产的方式，Catalog借助元数据来管理数据，包括数据收集、组织、访问、发现和治理。可见，Catalog在数据资产管理中处于核心位置。元数据本身内容非常丰富，包括技术元数据、业务元数据和操作元数据，本文仅仅研究大数据计算存储框架本身的技术元数据，比如数...

Iceberg作为凌驾于HDFS和S3等存储系统之上的数据组织框架，提供了数据写入、读取、文件管理和元数据管理等基本功能，虽然Iceberg提供了丰富的API接口，但是面向API开发需要使用方比较了解其原理和实现细节，还是显得门槛过高。此外，在面向实时数据读写场景，需要有一个桥接框架来自动完成数据的读写，于是Iceberg和Flin...

在计算机科学中，排序和二分搜索是非常常见的一种算法，在上篇文章《leveldb memdb源码分析(下)之Rust实现篇》中，就可以看到里面很多方法都用到了二分搜索来实现。本文将会对比 Go 和 Rust 语言中排序和搜索方法中的一些特性和不同，对于Go主要使用数字切片 []int 作为例子， 对于 Rust 主要使用 Vec 作为例子 。

假设有一种数据源（比如CDC binlog Events、Kafka 实时数据流等），需要实时展示时序数据的摄入数量趋势，并能查看任意时间范围内的数据分布质量（比如每个字段的数据密度、总取值数量、去重后的数据取值总量等），最小时间范围间隔为1分钟，最大范围不限制。展示样例见下图，如何在计算资源有限的情况下（不使用分布式M...

使用Flink实时消费kafka数据时候，涉及到offset的状态维护，为了保证Flink作业重启或者运行时的Operator级别的失败重试，如果要做到“断点续跑”，需要Flink的Checkpoint的支持。问题是，如果简单的开启Flink的Checkpoint机制，而不需要额外的编码工作，是否能达到目的？为回答该问题，本文首先要研究Flink的Checkpoint的...

leveldb是一个写性能十分优秀的存储引擎，是典型的LSM树(Log Structured-Merge Tree)实现。LSM树的核心思想是将随机写转化为连续写，从而提升写操作的吞吐能力，整体架构如下：

将Flink流式计算引擎作为实时计算作业的标配带来的重大挑战之一是资源占用问题，因为大量的Flink作业一旦启动，将一直占用分配的CPU和内存资源，而不会自动释放（除非是批处理模式），并且不会随着处理负载自动伸缩。本文探讨如何在计算资源有限的情况下，如何最大化利用计算资源。基本思路是将流式计算任务中基于时间触...

Hive是一个建立在Apache Hadoop之上建立的一个数仓系统，Hive使用Hadoop中的HDFS组件存储数据文件。在使用hive时通常会遇到小文件问题，即存储在HDFS上的数据文件是明显小于HDFS文件块大小的。小文件问题通常会带来以下影响。

相信大部分有接触前端开发的朋友对var关键字非常的熟悉，但是到现代工程中你会发现var关键字正在舍弃，有的甚至使用lint（eslint no-var）工具明确禁用var，var关键字正在消失。

在本文中我们将从一个简单的算法题引出Rust语言中迭代器相关的几个方法，帮助大家理解chars,all ,try_fold,enumerate,try_for_each,char_indices的用法。 ​

greenplum 是一个 MPP 架构的数据库，由一个 master 和多个 segment 组成（还可选配置一个 standby master），其数据会根据设置的分布策略分布到在不同的 segment 上。

前言leveldb中memdb模块使用skiplist作为一个kv的内存存储，相关代码实现非常漂亮。在上文介绍了下面内容：对比c++和golang版本中查询、插入、删除的实现分析golang版本中可以优化的地方，然后对rust版本进行优化然后在本文中将会介绍如何参考goleveldb的版本使用rust重写memdb（arena版本）使用rust重写一个非arena版本...

在golang中提供了for range 语法糖帮助我们方便的遍历数据或切片，也可以遍历map和channel；在rust中则提供了 for in 语法糖帮助我们方便的遍历Array，Vector或切片，也可以遍历map。本文将会通过多种类型的例子介绍两种语言中这些语法糖背后的机制以及使用不当可能遇到的陷阱。

前言最近在研究学习leveldb的源码，并且尝试用Rust进行重写leveldb-rs，leveldb中memdb模块是使用skiplist作为一个kv的内存存储，相关代码实现非常漂亮，所以有了这篇文章。 leveldb通过使用Arena模式来实现skiplist。简单来说，就是利用线性数组来模拟节点之间的关系，可以有效避免循环引用。

kafka的go客户端，使用最多的应该是sarama，但以前老的sarama版本不支持消费者组的消费方式，所以大多数人都用sarama-cluster。