ITPub博客

在写这篇文章之前，Java 25正式发布，其中 JEP-508 Vector API 迎来了第10次孵化，旨在提供一种向量计算的接口，从而获得比等效标量计算更高的性能。传统的基于Java虚拟机（JVM）的执行引擎在处理大规模数据时逐渐显露出性能瓶颈 (标量计算) ，特别是在 CPU 密集型任务和内存管理方面。近年来，众多大数据计算引擎开始转向原生（Native）执行模型，采用

Flink 自1.1版本起通过 FLIP-49 Unified Memory Configuration for TaskExecutors 和 FLIP-116 Unified Memory Configuration for Job Managers对 TaskManager 和 JobManager 的内存模型进行了重大重构，统一了内存配置方式，本文详细介绍 Flink

前言在上一篇《主键表之合并引擎merge-engine》中的结尾，当 'merge-engine' = 'first-row'，开启流读的时候，会抛一下错误，提示要使用 lookup 或 full-campaction 这两种 changelog producer 才支持流读，input 模式也支持，但是只会返回输入的记录。changelog producer的作用

前言      当我们在讨论数据湖表格式(Table Format)，我们在讨论什么？没错，我们在讨论数据湖表格式- -！。言归正传，数据湖表格式的出现是为了解决什么问题呢？是为了融合传统数仓的一些特性，用于解决传统数据湖在数据管理、查询性能和事务支持上的不足。而表格式就是 Lakehouse 架构上的一个额外的组件 - 事务层，它是文件格式之上的附加层，这个额外的层

本文基于 Apache Flink 1.16 和 Apache Paimon 1.0.1，详细介绍如何配置 Paimon 环境、创建和使用追加表（Append-Only Table）与主键表（Primary-Key Table）的特点和使用。一. IDEA 环境准备下载官方paimon-1.0.1版本，本地编译选择对应的flink版本把对应的jar包安装到本地仓库：mvn install

题外话      在写《StarRocks 查询探秘》系列文章，有同学疑惑是否有必要研究底层代码？在我看来是有必要的，第一，深入理解一门技术，理解其原理和底层代码，对各种特性深入理解，知道针对业务场景如何使用，才能发挥出该技术/框架的最大能力；第二，很多时候线上问题往往是使用姿势不对造成，某种意义上就是对其理解不深刻，即使是线上bug，也要求我们拥有强悍的

用户提交的 SQL 查询文本在 FE 需要经过一系列处理，最终生成一个分布式执行计划分发给各个 BE 进行计算。如下图所示，经过这么几个核心的处理流程:1. Parser 解析，把一条文本 SQL 解析成一棵 AST 树；2. Analyze 分析，对 AST 树进行分析，比如表是否存在等；3. AST 树是怎么转成 Loagical Plan；4. 规则重写，基于一些规则重写 Logical P

问题背景在 StarRocks 中，通过 ETL 处理后的结果数据需导出到 HDFS，使用 INSERT INTO FILES 语句实现。导出过程中遇到以下问题：导出sql 因为 BE 内存超限导致查询失败。由于线上环境采用混部部署，BE 单机配置为 20 核 CPU 和 40GB 内存。怀疑 CPU 和内存配比不足导致内存超载，因此尝试降低并发度（设置 pipeli

问题背景为了加速数据即席查询，需要将离线 Hive 表数据通过 ETL 写入 StarRocks 内表，采用 INSERT INTO 按天分区导入数据。Hive 表各分区数据量相差不大，但导入耗时在 3～20 分钟之间波动。初步排查通过监控集群 CPU、内存、磁盘 IO 和网络 IO，未发现明显瓶颈。查看BE compaction score也是在一个合理的范围内。进一步检查

 Apache Paimon 是一种高性能的流批一体数据湖存储引擎，广泛用于实时和离线数据处理场景。它通常与HDFS（Hadoop Distributed File System）集成，作为底层存储系统，存储数据表的文件和元数据。Paimon 通过其表结构（如Append表和主键表）管理数据文件，并依赖HDFS的NameNode（NN）进行元数据的管理和文件操作（如create、dele

逻辑分片 tablet 和 副本Tablet 是表的逻辑分片。一张表可以有多个 Tablet，每个 Tablet 有 replication_num 个副本， 默认3个 replication。StarRocks 采用多版本并发控制（MVCC）技术，通过复制这些多版本数据的物理副本，保证版本修复的高效进行。StarRocks是以 tablet 这个维度进行数据的管理。数据导入事

在StarRocks中，用户提交的SQL查询文本在FE需要经过一系列处理，最终生成分布式执行计划并分发到各个Backend（BE）节点进行计算。核心流程包括以下五个步骤：Parser解析：将SQL文本解析为抽象语法树AST，表示其语法结构。Analyze分析：对AST进行语义分析，验证表、列是否存在，检查语法合法性等。Logical Plan生成：将AST转换为逻辑执行计划Logical Plan

使用StarRocks用于数据湖，实时或离线数仓表查询是一个常见的需求。而大部分湖仓（如Paimon、Iceberg、Hive 等）是Java生态，StarRocks 通过 JNI（Java Native Interface）Connector 支持与这些组件的交互。本文从一条简单的sql查询导致的 OutOfMemoryError，剖析 StarRocks 是在什么情况下会使用 JNI 读取器，

StarRocks元数据管理主要由 FE 节点负责，元数据内容包含Catalog、数据库、表、物化视图、节点、心跳、用户权限等信息，元数据的核心特点如下：内存存储：元数据主要存储在 FE 节点的内存中，通过 GlobalStateMgr 类管理，以保证低延迟的查询响应。高可用性：通过多 FE 节点的 Leader-Follower 架构实现元数据的同步和一致性。持久化机制：使用

在 StarRocks 中，SQL 查询的生命周期分为三个阶段：查询解析（Parsing）、查询规划（Planning）和查询执行（Execution）。查询计划由 Frontend (FE) 生成并拆分为多个 fragment，这些 fragment 被分发到多个 BE 节点并行执行。每个 BE 节点接收到的 fragment 包含具体的执行逻辑，例如扫描数据、执行算子（比如 JOIN、AGGR

  StarRocks 是一种高性能的分布式分析型数据库，广泛应用于实时数据分析场景。Apache Flink 作为流批一体化的计算框架，与 StarRocks 的结合能够高效处理大规模数据。为实现更高的读写性能，推荐使用 StarRocks 官方提供的 flink-connector-starrocks，而非 Flink 官方的 Flink JDBC Connect

 在大数据处理中，企业常面临成本高、系统复杂、维护困难的挑战。通过存算分离、湖仓一体和架构简化，可以显著降低成本、提升效率、简化管理。以下从三个方面详细说明如何实现这些目标。1. 降本增效：从硬件到人力全面优化（1）硬件成本：更低的存储和计算费用存算分离降低存储成本传统存算一体架构要求所有数据都存放在高性能 SSD 或 NVMe 磁盘上，以保证查询速度。但很多冷数据（如历史日志）访问频率

在当今数据驱动的时代，企业对数据管理和分析的需求日益增长。传统的数据仓库和数据湖架构在面对大规模、多样化数据时，逐渐暴露出各自的局限性。Lakehouse架构应运而生，旨在融合数据湖和数据仓库的优势，提供一种统一、高效的数据管理与分析平台。本文将深入探讨Lakehouse架构的演进历程与核心目标，并以Apache Flink、Apache Paimon和StarRocks为例，阐述如何构建企业级的Lakehouse架构。