余璜的技术博客

本文梳理了数据湖技术的发展脉络，重点分析了Databricks的技术演进路线。从AWS S3开启云存储时代，到Parquet格式推动数据湖概念落地，再到Delta Lake等表格式解决数据更新问题。文章对比了Hudi、Iceberg和Delta Lake的技术特性，指出Delta Lake深度绑定Spark生态但小事务支持不足的特点。随着业务发展，Databricks推出Lakebase方案，通过PostgreSQL实现10秒级延迟的实时分析能力。图表展示了Databricks从Spark起家到构建完整La

当你把目标用户群体定义为“数据科学家”的时候，你绝不能只提供一个数据库后端给他，提供一个 OCP 也是远远不够，ODC 也不够。你必须围绕“数据科学家”的需求，给出一整套便捷的数据交互界面，给出做数据科学分析时必须的组件库、运行时环境，同时针对该群体对“交互延迟”的一般预期，设计一整套性能解决方案。我遇到这个问题的时候，尝试回答 OceanBase 过去很多年的目标用户是谁，发现居然一时语塞。如果你写云数据库，你一定要首先定义清楚，你的目标用户是谁。定义清楚了目标用户群，也就基本确定了商业能力的边界。

作为 CEO，你一定要坚守，要有定力，不能见钱眼开。

本文提出"单元容器"方案解决云资源弹性扩展难题。核心建议是将计算资源封装为8C的标准单元容器，通过横向增加容器数量实现扩容。这种设计既能向用户呈现无限资源的假象，又能规避底层物理机规格限制。相比传统按需分配整机的方式，单元容器方案提高了资源利用率，但要求软件架构预先支持多容器管理和资源隔离。Snowflake等系统已成功采用类似8C固定规格的设计，体现了资源抽象和通用化的重要价值。该方案的关键在于平衡架构复杂性和资源灵活性。

BYOC（自带云）是小厂商在云数据库领域的一种过渡方案，允许客户利用大企业的云资源折扣降低成本。尽管BYOC能帮助小厂商以更优惠的价格部署数据库，但它存在信任风险（需远程运维客户环境）、长期价值有限（厂商壮大后折扣优势消失），以及难以与云平台低价服务竞争等缺陷。这种中间态既无法像私有化部署那样安全，也不如SaaS模式便捷，主要吸引价格敏感但需求复杂的客户，长远来看并非理想的产品形态。

一些分布式数据库在这个方面就很吃亏，多副本，为了追求高可靠，就自然要把副本放到多个 AZ 中，这样一来，计算流量就很容易在多个 AZ 之间来回蹿，费用蹭蹭涨。所以啊，云原生的数据库，还是 Snowflake 玩得溜，卡了一个非常好的位，把这些乱七八糟的需求全部绕过了，一个 AZ 管够。那么，如果你在设计产品的时候，就需要时时刻刻把网络这件事情放在心上，最好，每一次查询涉及到的机器都不要跨 AZ。甚至，你知道吧，流量费还非常贵！而且，你知道吧，发送方计费，接收方还要计费，所谓“一鱼两吃”！

摘要：Neon注册流程简单快捷，支持Google登录并选择AWS/Azure云平台。用户下载客户端后完成授权，即可获取连接串对接AI工具，实现代码直连Neon数据库。整个过程仅需20分钟，最新版本还支持PostgreSQL作为后端，大幅提升开发效率。系统初始化后可直接查看所有数据，为开发者提供极大便利。

缺点：算子实现复杂，需要“带掩码”处理，某些 SIMD 优化较难。ClickHouse 每次 filter 都会生成新 column（物理拷贝），下游算子只处理“干净”的数据块。以前没怎么考虑过这个问题，实际写了一些带 selector 的代码，才知道每一步都物化的话，代码写起来有多爽。这些系统经常使用掩码（mask）或者 selection vector来表示哪些行有效，而不是立即拷贝数据。通常还是“逐行遍历+逐行判断”，不进行大规模批量拷贝，也不专门维护 selection vector。

本文对比了三种从1024字节数组中选取n(1-8)个字节组合成uint64_t的方法。方法1使用简单循环，方法2采用Duff's Device技术进行循环展开，方法3则完全暴力展开所有情况。测试结果表明：方法3性能最优，方法2次之，方法1最慢。这种性能差异源于分支预测和指令级并行优化，完全展开的代码能最大化利用CPU流水线。对于小规模循环(n≤8)，暴力展开是最高效的实现方式。

摘要：文章提出将数据库作为AI开发的核心控制平面，通过声明式API统一管理数据、特征和模型元数据。关键设计包括：1)SQL扩展支持AI原语 2)集中式元数据管理 3)强制治理策略 4)可插拔执行后端。MVP建议从向量查询、推理API和模型注册入手。该方案面临的主要挑战包括开发者习惯改变、性能优化、生态兼容性以及组织变革阻力。（149字）

在这个基础上，我们还可以进一步定制 forEach，比如添加循环展开的模板参数，指导 forEach 做编译期循环展开，可以进一步提升循环遍历性能。isConstantArray 这个条件，是在 Vector 初始化阶段就定好了的，但它又不是一个模板参数，所以很难用模板特化的方式解决。循环里有大量的分支跳转，流水线早就被打得四分五裂了，forEach 已经带来不了什么好处，更不用提应用循环展开。但这个需要一定的设计来配合，比如，在 OceanBase 中，就不太容易应用这个技术。

答：因为 Flink 的计算有时间窗口的概念，比如：每个整点，计算上一个小时的销售额。因为队列延迟、网络出错、重试导致数据重复等原因，会让 Kafka 等队列中的数据不能完全被信任，上一个小时的数据不一定真的全了，可能有一些数据要等几分钟才到，也有可能永远不到。原因如下，特别是第一条，会让业务运营存在不确定性，为了应对这种不确定性，可能需要预留出业务余量，造成浪费。简而言之：因为实时数据不准确，那么 Serving 的到的数据肯定也不准确。• 结果第二天离线数据跑完，真实注册是 1100，实际早就达成了。

在 Snowflake 和 Databricks 的语境中，"Data Analytics revenue" 和 "Data Engineering revenue" 虽然并非官方财报中的标准分类，但在业务拓展和市场细分中具有重要意义。Data Analytics 收入主要来源于客户将平台用于数据分析、BI 报表、探索性分析等场景，而 Data Engineering 收入则来自数据管道开发、ETL/ELT 工作流、数据清洗等工程类任务。尽管数据分析和数据工程在数据生

如果只有一个元素，静态unroll 了多个元素，那就会越界访问了。如果编译器知道 bound.end() 和 bound.start() 之间有1024 个元素，那么它就敢大胆 unroll 了。理论上是可以，如果元素多，就走 unroll 分支，元素少就不走 unroll 分支。但是，要知道，编译器并不知道我们这是一个向量化的计算，它怎么会轻易做这样的优化呢？在数据库实现中，我们有一个认知误区：当我们把数据结构组织成向量后，只要写好 for 循环，编译器就会自动帮我们做好 SIMD 优化。

基于这样一个事实，在部分场景下我们可以对空闲的高 16 位加以利用，存储一些辅助 flag，这样可以让内存结构更加紧凑。为什么高 16 位总是为 0？这是因为，就目前的应用程序需求来说，只使用低 48 位已经足够。位数越少，CPU 构建成本越低。对于 ARM 处理器，可以看到下面的描述。也就是说，48 bit 不是定数，未来也可能变化。如此这样，我们就可以在 HashSlot 里存下更多信息了。的指针地址默认都只使用低 48 位，高16 位总是 0。在 Intel CPU 和 Arm CPU 中，

今天来熟悉汇编指令。

此时，我个人理解是：编译器先假设 a 总是可以信任寄存器中的值，当 b 写着块内存时，a 可以读不到最新的修改，当 b 读这块内存时，a 也不需要做任何写回操作使得 b 能读到最新数据。不过，在我们的例子里，我们通过 restrict 关键字欺骗了编译器，实际上 x 和 y 指向了同一片内存，这也导致了最终的结果错误。也是非常考验人的，需要深刻地认识到调整分支概率后编译器可能的行为是什么，才能有的放矢，不然，编译器认为，y 是以指针的形式传入函数体内，说明外部也有指针引用了 y，并且，

创建一个新表，想让他的字符集是 gbk，怎么弄?

在，最末尾提到了 FDW。FDW 到底是什么呢？

也就是说，Postgres 基于 pg_lakehouse 做数据湖分析，计算能力主要靠 pg_lakehouse 提供，而不是主要依赖 Postgres 自身的计算引擎能力。它的出现，使得 Postgres 能够轻松访问 S3 等对象存储，轻松访问 Delta Lake 上的表格，具备数据湖分析能力。所以，从原来上看， pg_lakehouse 提供了一组访问数据湖的方法，并将这些方法和 DataFusion 的计算能力结合起来，帮助 Postgres 获得分析数据湖数据的能力。

插件机制是个好东西。为了你的系统能够获得这个好东西，最好是系统在第一天设计的时候就做好抽象，把每一类系统功能都抽象成集合，每一类功能都支持“运行时可寻址”。在 OceanBase 中，最容易插件化的是系统函数，因为它数量众多，客观上从第一天起就逼迫 OceanBase 把它做成易扩展、易寻址的样子。

在数据仓库（Data Warehouse）和更广泛的数据工程领域中，“Serving”通常指的是将处理和优化后的数据提供给最终用户或应用程序的过程。这包括数据的查询、检索、展示等操作，使得数据能够在决策支持、报告、分析、或机器学习等应用中被有效使用。简而言之，数据“Serving”强调的是数据的最终用途及其可用性。

理解了 Hologres 和 MaxCompute 的关系，就理解了数据仓库（DW）和数据服务（Serving）之间的关系，也有助于理解试试数仓和离线数仓之间的关系。那么，Hologres 的优势是什么呢？回答这个问题之前，我们再看 MaxCompute 和 Hologres 的一个区别：存储成本。可以看到，MaxCompute 可以拥有更低的存储成本，适合海量数据存储。可以看到，MaxCompute 可以拥有更低的计算成本，适合海量数据计算。低存储成本，低计算成本，这正好满足海量数据的数仓的成本需求。

此句话表明使用 Provisioned IOPS 卷能够提供更一致的性能，相较于其他类型如通用目的SSD或各种优化的HDD，在处理随机和顺序磁盘访问时，可以预期更好的表现，这对于性能敏感的应用是十分重要的。IOPS 买太大通常是浪费，要因地制宜，不大不小是最好的。确定合适的 IOPS 的方式，在 AWS 上是在 CloudWatch 上看 VolumnQueueLength 指标，如果这个指标比分配的 IOPS 大，同时我们又比较关注延迟，那么就应该增加一些 IOPS。

为了尽可能解决稀疏编号导致的 bitmap 膨胀，引入了 RoaringBitmap。之前写过一篇 bitmap 应用场景的文章。

读到了一篇非常好的写数仓分层的文章，这个作者是把数仓设计真吃透了，很懂业务。

数据在两个数据库之间流转时，从源端做 Extract，在目的端做 Load 操作。那么，在一个数据库内部，ETL 是怎样的？在一个数据库内部，ETL（Extract, Transform, Load）作为数据处理的过程，同样涉及三个主要步骤：Extract (提取)：这一步骤涉及从数据库中提取所需的数据，这可能是来自数据库的不同表或不同行的数据。Transform (转换)：在这个阶段，提取出来的数据将会经过一系列转换操作，以便适合特定的业务规则和需求。

OceanBase 并行执行的消息处理框架是很有意思的，里面用到了不少面向对象编程思想，值得分析。本文介绍 DTL 消息处理。

本文介绍 Collation Level 在数据库中的用途。

在并行计算中，遇到建 HASH 表的场景，我们通常会认为左侧数据会随着建 HASH 表的过程，全部物化到驱动算子中。这个假设并不总是成立！

沙箱上头，继续聊沙箱。今天这个沙箱叫 minijail，是。一搜不得了，是 Google 官方维护的沙箱，用在了 Chrome 中。

今天轮到讨论安全问题了。python 代码中包含有害内容该怎么办？常用技术是沙箱（Sandboxing）。本文从一些基础设施讲起。

本节研究如何对 import 做白名单。

本节记录一下多线程、多进程中调用 Python 解析器。

和 python 交互，最繁琐的部分应该就是参数处理，本文演示了基础数据结构的输入输出。

本文测试在 C++ 中调用 Pandas 库来执行 Python 程序。

实现 Python UDF 中的一步就是学习如何在 C++ 语言中调用 python 解析器。本文做一个记录和讨论。

本文记录了 Photon 中的若干向量化技术

凡是涉及到排序，就能看到一个概念：Permutation（排列）。本文探究一下这个概念背后的实现。

本文简单介绍了 ClickHouse 行是否为 Null 判断的方法。