“工业流水线”的鼻祖，福特 T 型汽车的电机装配，将组装过程拆成 29 道工序，将装备时间由平均二十分钟降到五分钟，效率提升四倍 ，下图图源。

这种流水线的思想在数据处理过程中也随处可见。其核心概念是：

1. 标准化的数据集合：对应待组装对象，是对数据处理中各个环节输入输出的一种一致性抽象。所谓一致，就是一个任意处理环节的输出，都可以作为任意处理环节的输入。
2. 可组合的数据变换：对应单道组装工序，定义了对数据进行变换的一个原子操作。通过组合各种原子操作，可以具有强大的表达力。

则，数据处理的本质是：针对不同需求，读取并标准化数据集后，施加不同的变换组合。

最近翻 DuckDB 的执行引擎相关的 PPT(Push-Based-Execution) 时，发现了这篇论文：Morsel-Driven Parallelism: A NUMA-Aware Query Evaluation Framework for the Many-Core Age。印象中在执行引擎相关的文章中看到他好几次；且 NUMA 架构对于现代数据库架构设计非常重要，但我对此了解尚浅，因此便找来读一读。

从题目中也可以看到，论文最主要关键词有两个：

1. NUMA-Aware
2. Morsel-Driven

据此，大致总结下论文的中心思想：

1. 多核时代，由于部分 CPU 和部分内存的绑定关系，CPU 访问内存是不均匀（NUMA）的。也即，对于某一个 CPU 核来说，本机上一部分内存访问延迟较低，另一部分内存延迟要高。
2. 传统火山模型，使用 Exchange 算子来进行并发。其他算子并不感知多线程，因此也就没办法就近内存调度计算（硬件亲和性）。也即，非 NUMA-local。
3. 为了解决此问题，论文在数据维度：对数据集进行水平分片，一个 NUMA-node 处理一个数据分片；对每个分片进行垂直分段（Morsel），在 Morsel 粒度上进行并发调度和抢占执行。
4. 在计算维度：为每个 CPU 预分配一个线程，在调度时，每个线程只接受数据块（Morsel）分配到本 NUMA-node 上的任务；当线程间子任务的执行进度不均衡时，快线程会”窃取“本应调度到其他线程的任务，从而保证一个 Query 的多个子任务大约同时完成，而不会出现”长尾“分片。

这是我第一次在 b 站直播分享，录屏地址 https://www.bilibili.com/video/BV1Fz4y1u79v ，主要是从我的求职经历以及面试经历角度聊了一些关于 infra 找工作的注意点，并回答了同学一些现场问题。

🐎 求职准备

软素质

💁‍♂️ 沟通。面试时无论是经历描述，系统设计甚至写代码，沟通都是第一位的，这是面试各个环节顺利展开的前提。

把一件事说清楚：

1. 上下文：先和面试官对齐上下文，不要默认他比你知道的多。
2. 条理性：背景 → 需求 → 方案 → 挑战点 → 结果
3. 简洁性：就跟写文章一样，多过几遍就好了。

🧠 思维。主要是抽象和联想。

1. 抽象。也可以说是归纳，或者叫知识聚簇。以树来做类比，就是遍历几个子节点，抽象出其共通的父节点的特质，然后进而推演出新的子节点。比如调度问题（CPU 调度、分布式任务调度）。
2. 联想。也可以说是关联，或者叫跨域跳联。以图来做类比，就是对于几个连通子图，在新的维度上给其建立通路。比如文字是思想的一种序列化。

RocksDB 是很多分布式数据库的底层存储，如 TiKV、CRDB、NebulaGraph 等等。在 DataDog 工作的 Artem Krylysov 写了一篇文章来对 RocksDB 做了一个科普，通俗易懂，在这里翻译下分享给大家。

导语

近几年，RocksDB 的采用率急速上升，俨然成为内嵌型键值存储（以下简称 kv 存储）的不二之选。

目前，RocksDB 在 Meta、Microsoft、Netflix 和 Uber 等公司的生产环境上运行。在 Meta，RocksDB 作为 MySQL 部署的存储引擎，为分布式图数据库（TAO）提供支持存储服务。

大型科技公司并非 RocksDB 的仅有用户，像是 CockroachDB、Yugabyte、PingCAP 和 Rockset 等多个初创企业都构建在 RocksDB 基础之上。

我在 Datadog 工作了 4 年时间，在生产环境中构建和运行了一系列基于 RocksDB 的服务。本文将就 RocksDB 的工作原理进行概要式讲解。

国内很多大学的计算机专业，比较偏重基础和理论的“灌输”（就我当年上学的体验，现在可能会好一些），对于代码能力，虽然也有一些课程实验，但往往不太够用。于是，在进入正式工作前，很多同学就会对自己代码水平不太自信。下面我就根据我自身的写代码经历提供一些建议。

概述

Facebook Velox 是一个针对 SQL 运行时的 C++ 库，旨在统一 Facebook 各种计算流，包括 Spark 和 Presto，使用推的模式、支持向量计算。

Velox 接受一棵优化过的 PlanNode Tree，然后将其切成一个个的线性的 Pipeline，Task 负责这个转变过程，每个 Task 针对一个 PlanTree Segment。大多数算子是一对一翻译的，但是有一些特殊的算子，通常出现在多个 Pipeline 的切口处，通常来说，这些切口对应计划树的分叉处，如 HashJoinNode，CrossJoinNode， MergeJoinNode ，通常会翻译成 XXProbe 和 XXBuild。但也有一些例外，比如 LocalPartitionNode 和 LocalMergeNode 。

不知道为何，今年朋友圈分享年终总结的朋友格外多。我挺喜欢这个形式，一来，我很爱看别人的年终总结，看故事之余还能看到一些不同路径；二来，每年定期回顾下，也确实能帮着梳理下思路，简单做下展望。

古代知识垄断的时代，只有帝王将相才能有纪传；而今信息爆炸的世代，人人皆可记之，为自己代言。于短期来说，年岁渐长，思虑日增，很多事不记下来，旬月便忘，通过年终回顾，日后回头追踪下自己思想变迁轨迹，也算三省吾身，冀有新得；于长期来说，我们终将作古，若借助互联网能留下个一鳞半爪，博后世一笑，也算雁过留声。

知乎上有个问题：如何实现一个数据库？手痒忍不住又水了一篇。以计算机中最常用的分析、理解问题的思想，我们可以从两个维度：逻辑和物理，来思考如何实现一个数据库。

逻辑维度

数据模型（对外，面向用户）

想要实现一个数据库，首先你得定义给给用户什么样的数据模型？在前些年，这些可能不是个问题，彼时，数据库约等于关系型数据，约等于 Oracle/SQLServer/MySQL/PostgreSQL 。但随着数据量的不断增大、用户需求的不断细化，关系模型已经不能一招鲜、吃遍天。

DDIA 读书分享会，会逐章进行分享，结合我在工业界分布式存储和数据库的一些经验，补充一些细节。每两周左右分享一次，欢迎加入，Schedule 和所有文字稿在这里。我们有个对应的分布式&数据库讨论群，每次分享前会在群里通知。如想加入，可以加我的微信号：qtmuniao，简单自我介绍下，并注明：分布式系统群。另外，我的公众号：“木鸟杂记”，有更多的分布式系统、存储和数据库相关的文章，欢迎关注
本书第一部分讲单机数据系统，第二部分讲多机数据系统。

冗余（Replication） 是指将同一份数据复制多份，放到通过网络互联的多个机器上去。其好处有：

1. 降低延迟：可以在地理上同时接近不同地区的用户。
2. 提高可用性：当系统部分故障时仍然能够正常提供服务。
3. 提高读吞吐：平滑扩展可用于查询的机器。

本章假设我们的数据系统中所有数据能够存放到一台机器中，则本章只需考虑多机冗余的问题。如果数据超过单机尺度该怎么办？那是下一章要解决的事情。

知乎上有个问题，如何辨别一个程序员水平的高低？就这几年 Review 代码的体感，忍不住就工程素养这个话题吐两句槽，正好作为好好写代码系列的第二篇。

思维体系

水平差的程序员往往在“抽象”上做的不好。

什么是抽象能力呢？简言之，就是分门别类、触类旁通的能力。通过大量实践和书籍输入，将所解决过的问题进行正交分解，分解过的元知识多具有很好地复用性；再利用这些元知识，进行组合推演，创造性的解决新遇到的问题。即归纳和演绎。

概述：流控为啥重要

上云的好处在于池化资源，让多租户共享，然后按需分配，从而降低成本。但进行：

1. 多租户隔离：用户要求可以使用其买到的流量，并且不会被其他租户影响。
2. 资源共享：资源只能逻辑隔开，不能物理隔开，否则无法充分动态分配（超发）。

是一对相对矛盾的事情，我认为，也是云原生数据库最要解决的问题。不把这个问题解决好，则数据库：

1. 要么平台不赚钱：比如资源静态预留，虽然可以让用户满意，总能随时用到卖给他的资源配额，但会存在巨大资源浪费，要么价格贵，要么用户不买单。
2. 要么用户不满意：多用户共享物理资源，但非常容易进行互相影响，造成用户不能用到平台声称的配额。

DynamoDB 从静态分配开始，逐步演化出一套全局和局部组合的准入控制机制，从而实现了物理上资源共享，但又在逻辑上给用户以配额隔离，从而实现了数据库真正的云原生。下面，我依据 Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service 这篇论文披露的细节，对其流控机制的演进过程做一个梳理，以飨诸君。

水平所限，谬误之处，欢迎随时指出。

Google LevelDB 是一个 LSM-Tree 的实现典范。但在开源出来后，为了保持轻量、简洁的风格，除了修修 Bug 之外，一直没有做太大的更新迭代。为了让其能够满足工业环境中多样性的负载， Facebook（Meta） 在 Fork 了 LevelDB 之后，做了多方面的优化。硬件方面，可以更有效地利用现代硬件，如闪存和快速磁盘、多核 CPU等；软件方面，针对读写路径、Compaction 也做了大量优化，如 SST 索引、索引分片、前缀 Bloom Filter、列族等。

本系列文章，依据 RocksDB 系列博客，结合源码和一些使用经验，分享一些有趣的优化点，希望能对大家有所启发。水平所限，不当之处，欢迎留言讨论。

本篇是 RocksDB 优化系列第一篇，为了优化深层查询性能，将不同层级的 SST 通过一定方式索引起来。