前五篇都在查,这篇来写:用 Flink CDC 3.6 把 MariaDB(mariadb-operator)和 PostgreSQL(CNPG)实时同步进 Doris 存算分离的 UNIQUE 内部表。跑通增删改 / upsert / schema 演进,量化延迟与 FE/BE 节点数的影响。结论:延迟被 Doris sink 刷新间隔主导(与源类型、节点数都无关);BE 扩容增吞吐、对延迟无效;schema 演进是 MySQL 与 PostgreSQL 唯一的分叉点。附 5 个真实工程坑。

存算分离的好处之一是算力可独立伸缩。把 Doris 的 compute group 从 2 一路扩到 8 个 BE,跑 TPC-H SF10,量化「加 BE 到底快多少」。结论:收益强烈双峰——重聚合/重 shuffle 近线性(TPC-H Q1 8BE 4.3×),轻量亚秒查询几乎不动甚至变慢;存在 ~300ms 协调地板加 BE 打不破;扫描受 bucket 数封顶。还补了 3/5/6/7 这些非 2^n 的点,验证不会有奇怪现象。

把冷数据(Iceberg/GCS 上的事实表)和关系维表(Doris 原生表)用 Trino 联邦 join,性能有多糟?该不该为冷数据单独立一个 Doris?实测三种跑法:Trino 联邦、Trino 全 Iceberg、专用 Doris 直读冷 Iceberg。结论:单表聚合能整段下推时联邦不亏,但 join 一重,单条 MySQL 流串行拉维表让联邦比专用 Doris 慢 3–4 倍——而且 Doris 只用了 1/7 的 CPU。

在同一张 Lakekeeper/GCS 上的 Iceberg 表(TPC-H SF10)上,横评 ClickHouse 26.5、Doris 4.1.1、StarRocks 4.1.1 的读性能:冷读 vs 热读、Trino 写 vs Spark 写、缓存深挖。StarRocks 热读最快但强依赖缓存;Doris 最稳、几乎不吃缓存;ClickHouse…

让 Doris / Trino / Spark / StarRocks 读写同一张 Iceberg 表,实测各自的 CRUD + MERGE 能力,以及"谁读得动谁的表"。核心发现:Doris 写出的 positional delete 文件缺少 Iceberg 保留 field-id,导致 Trino 等严格引擎报 position is…

用 Lakekeeper 作为 Iceberg REST Catalog、GCS 作数据仓、CloudNativePG 作元数据后端,在本地 kind 集群上搭一套 Lakehouse,并把 Doris / Trino / Spark / StarRocks / ClickHouse 五大引擎接到同一张目录上——逐个记录各引擎的接入配置与 GCS 认证踩坑。

新安装的debian 13 server系统默认不带sudo 使用 root 用户 apt install sudo -y 之后， sudo adduser [USERNAME] sudo 再用 [USERNAME] 用户登录就可以使用sudo了

DO NOT USE THE MOVE FUNCTION IN SETTINGS>APPLICATION it will move into encrypted WindowsApps folder and cause a lot of WSL2 failure. exmpale the correct way to do it is export…