V1.0版
目录
目
录 ............................................................................................................................................ 2
4
I.1.2.3.II.1.2.3.4.5.
简介................................................................................
目的 ............................................................................................................................................................. 4词汇表 ......................................................................................................................................................... 4引用 ............................................................................................................................................................. 4整体介绍............................................................................
系统环境 ..................................................................................................................................................... 5软件介绍 ..................................................................................................................................................... 5用途 ............................................................................................................................................................. 6简介 ............................................................................................................................................................. 6核心技术 ..................................................................................................................................................... 7
大规模并行处理
MPP ................................................................................................................... 7
5
行列混合存储 ................................................................................................................................ 8数据库内压缩 ................................................................................................................................ 8内存计算 ........................................................................................................................................ 9
6.7.III.1.2.3.4.IV.1.2.
ASTER NODEM................................................................................................................................................... 9
DATA NODE...................................................................................................................................................... 9
MASTER NODE..................................................................
10
简介 ........................................................................................................................................................... 10CONTROL 模块.............................................................................................................................................. 10SQL模块.................................................................................................................................................... 10ACTIVE-PASSIVE SOLUTION............................................................................................................................. 16DATA NODE..........................................................................
19
简介 ........................................................................................................................................................... 19重要模块 ................................................................................................................................................... 19
第 2 页共 31 页
3.4.V.1.2.3.4.VI.VII.
数据存储 ................................................................................................................................................... 20数据导入 ................................................................................................................................................... 21分布式机制.........................................................................
23
概括 ........................................................................................................................................................... 23数据备份和同步 ....................................................................................................................................... 24时间同步机制 ........................................................................................................................................... 27分布式
LEASE机制查询过程备忘
.............................................................................................................. 27
2930
内存管理机制.......................................................................
V3.0版的初步设计思路
........................................................
第 3 页共 31 页
I.简介
1.目的
本文详细描述了DreamData数据库系统。介绍了系统的目标、功能、系统接口、系统行为、系统约
束以及系统如何响应。本文面向系统参与者以及系统开发人员。
2.词汇表
术语
作者
定义
提交被审查文档的人。为了防止多个作者的情况出现，这个术语指全程参与文档制作的主要作者。
3.引用
第 4 页共 31 页
II.整体介绍
1.系统环境
图 1 –系统环境
2.软件介绍
DreamData是在从分布式数据库的基础上发展而来，同时加入一些实时分析分布式数据库，并且支持内存计算。
NoSQL的基因的新一代大数据
DreamData最大的特色就是大而快，它能极快地导入和处理海量的数据，并在这个基础上能极快地进行用户所需数据统计和分析。相对传统数据库上，并且随着节点数量的增加，整体性能会同步提升。
Oracle而言，DreamData的单机性能要高出
50倍以
第 5 页共 31 页
3.用途
实时决策能力；提高业务效率；
快速智能发现新观点和商业机会；提供业务产出；提升IT效率；软件架构
4.简介
图 2 –系统架构图
第 6 页共 31 页
5.核心技术
DreamData采用了大量最新的技术成果，最核心的技术包括：大规模并行处理MPP、行列混合存
储、数据库内压缩和内存计算。这些技术之间并不是孤立存在，而是相互关联，形成一个高效的系统。
大规模并行处理MPP
DreamData被设计为能在可用内核的数量，和跨越主机分配使用的并行执行上很好地进行扩展。如图3所示。
图3. 并行处理原理示意
一张大表拆分成多个
Tablet，被复制分布存储在不同的节点上以便并行处理；通过内存本地化处理
把大数据量和计算量分散到不同处理器；同时任何节点宕机将不影响数据完整和业务连续性，提供了系统的高可用性。
MPP系统不共享资源，处理单元可获得全部计算资源，处理效率高；处理单元之间互不影响，当通信占比较小时
MPP优于传统的SMP数据库架构，更适合数据分析与决策的场景。
第 7 页共 31 页
行列混合存储
DreamData主要面向大数据的实时处理，为了提高数据处理效率，尤其是常用的聚合、扫描和快速搜索功能，系统采用行列混合存储的方式，按行分区保留数据的关联性，按列组织提高数据压缩效率和快速聚合能力。
从概念上来说，一张数据库表是一个二维的数据结构，以行和列形式组织单元。而计算机内存则是以线性顺序组织。对于存储至线性存储器中的表，如图效率和快速聚合能力。
3中所示，列式数据组织方式意味着更高的压缩
图4. 列式数据组织的优势
数据库内压缩
采用经典的高效无损压缩算法技术，进一步提高性能，并极大地节省了数据存储空间。用户可获得10倍以上的空间节省，并且同时获得相应有效算法减少压缩/解压时间。
I/O性能提升。系统无需解压即可访问数据，轻量级压缩
第 8 页共 31 页
内存计算
硬件上得益于近年来性能的提升，
CPU普遍采用多核架构（每块
CPU 8Core），X86服务器硬件成
本较低，可采用多服务器或多刀片大规模并行扩展。同时加上DreamData软件技术上的创新，包括行列
混合存储技术、高效压缩、数据分片、快速索引、增量插入等方法手段，允许系统实现内存计算：
将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能；采用列式存储可以将更多的数据装进内存；
数据装进内存里的同时也会同步写入硬盘，即使宕机也不会丢失数据。
6.Master Node
现在主要包括
掘，并支持
R语言的
Control模块和SQL模块这两个部分，在这个基础上加入专门用于解析数据挖
Data Mining模块，为了可用性，安全性，以及性能，一个集群中可以有多个
Master Node之间会采用负载均衡的方式
Master Node处
Master Node，在SQL和Data Mining这两个功能层面上，每个来进行调度，但在于 Passive模式。
Control 功能方面将会只有一个
Master Node处于Active状态，其他的
7.Data Node
Data Node是实际对数据进行存储，并且能够对数据进行初步处理和过滤，以仅可能少的数据返回给Master Node端，Data Node存储数据的单位是
Tablet，并且一个
Data Node会有多个Tablet，并且他
Data
们是扁平的，在底层存储数据的时候用到了行列混合存储以及深度压缩和浅度压缩技术。还有Node提供多线程技术的设置，通过来进行加速。
第 9 页共 31 页
III.
1.简介
Master Node
Master Node主要包括Control和SQL这两个模块，并且在多个Passive的备份方法。
Master Node之间支持Active和
2.Control 模块
用于管理这个集群基础的元数据，包括表结构和和Data Node 注册信息，比如，某个来。
DataNode信息，还有负责集群中异常事件的处理
Control Server会通过Lease机制
Date Node 突然离线或者宕机了，
表分布策略
当Control模块收到建表的
SQL命令后，会根据命令中的
TabletGroup分片请求个数，从保持连接
Data Node，如果挑选出的合格Data Node上建立此分片。如果副
1的Data Node上建立相应的副本。当分
的Data Node中，根据一定策略选出最合适的符合分片请求个数的多个Data Node个数小于要求的分片个数，则报错返回，反之则在相应的本数量要求大于
1，则会以之前主分片为模板，在间隔步长为
Data Node上。
片数为1时，副本则被安排在其他选出的
3.SQL 模块
本质是一个经过我们云人团队修改的PostgreSQL，版本号，它主要用于在这个集群的前段接收来
JDBC/ODBC等方式调用的
SQL指令。
自命令行YSQL的SQL指令，并且也接受通过
当SQL模块接收到查询语句后，首先将其传递到查询分析模块，进行词法、语法和语义分析。若是命令则将其分配到功能性命令处理模块；对于复杂命令则要为其构建查询树，然后交给查询重写模块。查询重写模块接收到查询树后，按照规则和视图进行查询树的重写，生成新的查询树。生成路径模
第 10 页共 31 页
块依据新的查询树，考虑访问方式等问题，生成最优访问路径。最后最优路径生成可执行计划，并将其传递到查询执行模块执行。
在查询执行阶段，将根据执行计划进行数据提取、处理、存储等一系列活动，以完成整个查询执行过程。查询执行器分为策略选择（
Portal）、辅助处理（
ProcessUtility）、执行器（Executor）和特定功
能子模块。查询执行器会首先在策略选择模块根据输入执行计划选择对应的处理方式（辅助处理、执行器）。选择执行策略后，会将执行控制流程交给相应的处理模块。执行器输入包含了一个查询计划树，用于实现针对于数据表中元组的增删查改等操作。而辅助处理模块则处理其他各种情况。执行过程中会涉及表达式计算、投影运算和元组操作等功能，并且整个查询执行中会被重复调用，把他们单独划分为特定功能子模块。
第 11 页共 31 页
查询执行策略
执行流程进入查询执行阶段后，会为每种执行计划选择相应的处理过程，执行相应的处理，最后根据要求返回结果。
SQL语句会被查询编译器转换成两种基本类型的数据结构（执行计划树和非执行计划
DML语句会被查询编译器
树），并在执行过程中为其选择合适的执行部件（执行器或者辅助处理）。转换成执行计划树，因为
DML语句的执行过程十分相近，并且都可以使用统一的数据结构加以表示和
处理，所以被作为一种特殊的方式，单独进行优化和处理。其他类型的语句被归为非计划树操作，使用另一处理流程进行处理。然而，有些复杂的
SQL语句不能简单的归类为一种基本处理类型，会将其解
析成两种基本类型数据结构的序列，并将其顺序执行来完成请求操作。
执行器
查询计划树会由执行器统一进行处理。其输入时包含查询计划树的数据结构相关执行信息和结果数据。如果希望执行某个计划树，则仅需构造包含此计划树的
QueryDesc，输出则是QueryDesc，并依此
调用ExecutorStart、ExecutorRun、ExecutorEnd三个过程即能完成相应的处理过程。
第 12 页共 31 页
执行器对于查询计划树的处理，最终被转换为针对计划树上每一个节点的处理。每种节点表示一种物理代数的操作。节点的处理呗设计为需求驱动的模式，父节点使用孩子节点提供的数据作为输入，并向上层节点返回处理结果。实际执行时，从根节点开始处理，每个节点的执行过程会根据需求自动调用孩子节点的执行过程来获取输入数据，从而层层递归执行，实现整个计划树的遍历执行过程。
计划节点
查询执行的主要内容是对各个节点进行处理，由于使用了节点表示、递归调用、统一接口等设计，计划节点的功能相对、代码总体流程相似。
计划节点分为，控制节点、扫描节点、物化节点、连接节点。
控制节点：用于处理特殊情况的节点，用于实现特殊流程。
扫描节点：用于扫描表等对象以获取元组。
物化节点：这类节点种类比较复杂，主要特点是，能够缓存执行结果到辅助存储中。物化节点会在第一次执行时生成其中的所有结果元组，然后将结果元组缓存起来，等待上层节点取用；二非物化节点则是每次被执行时生成一个结果元组并返回给上层。例如：并更具制定属性进行排序，并将结果缓存起来，等上层节点从
第 13 页共 31 页
Sort节点能够获取下层节点返回的所有元组Sort节点取元组。
连接节点：此类节点对应于关系代数中的连接操作，可以实现多种连接方式，每种节点实现一种连接算法。例如：hash join。
元组操作
使用元组（HeapTuple）存储所有信息，包括各种系统信息、数据。执行器在执行过程中需要进行投影和属性选择判断，此时需要快速获取元组数据。另外物化节点缓存元组时，要求元组体积更小，以节省空间，因此定义了
MinimalTuple去掉事务相关信息。
表达式计算
处理SQL语句中的函数调用、计算式和条件表达式时需要用到表达式计算。表达式的表示方式与查询计划树的计划节点类似，用各种表达式计划节点来完成相应操作。表达式状态公共根类为ExprState，定义了类型
type、辅助表达式节点指针
expr以及用于实现该节点操作的函数指针
evalfunc。
投影操作
投影操作本身也是通过表达式计算来实现。投影操作时一种属性过滤过程，该操作队元组的属性进行精简，把那些在上层计划节点中不需要用到的属性从元组中去掉，从而构造一个精简版本的元组。投影操作中那些被保留下来的属性保存在查询计划的目标属性中，也被称为投影属性。
本节描述了对于各种SQL语句的一般执行流程。对于用户输入的SQL语句，优化器将为可优化的
语句生成计划树，最终策略选择器会通过判断选择执行器来处理，而数据描述语句则在执行过程中由策略选择器使其统一进入辅助处理器执行。
作为查询执行部分的入口，策略选择器提供对外的调用接口：对内提供了执行流程和部件的选择。外层通过调用
ProtalStart、ProtalRun、ProtalEnd，
Protal的接口，将计划器输出的执行计划传输给
Protal，Protal通过对于链表中操作的类型和链表长度等信息来决定选择怎样的执行过程，对于简单的查询语句则直接调用执行器，对于需要缓存输出到直到执行完成的语句则需要为其增加缓存结构和输出过程，对于更为复杂的过程提供了更为通用的复杂处理流程。无论哪种执行过程，可优化语句最终都会生成查询计划树并由执行器来处理，而其他数据描述语句的功能由辅助处理器来完成。
第 14 页共 31 页
对于种类繁多的数据描述语句，每种都有一个Stmt类型的数据结构保存其语法分析的信息。通过
对Stmt类型的判断，辅助处理会为其调用相应的语法解析和执行处理过程。
可优化语句提供了Plan类型的子类对象构成的计划树，每个计划节点数据结构共同继承于Plan节
点，计划树的每种节点对应了四类操作中的一种。
Plan只是一个查询计划，初始化过程中为这个计划中的每个节点生成状态节点并构造状态树，保存执行的相关信息。最总通过执行器执行每种节点的执行函数来实现各种节点的功能操作，在执行中利用状态树中信息处理相关数据。各个节点的执行过程中普遍包含了投影和选择操作，以及对下层节点的处理过程调用。
执行器通过迭代的调用每个节点处理过程，从下层计划节点对应的执行流程中获取数据，并经过各种节点的处理流程，得到最终的输出结果。对于修改元组的相关操作则是在获取到元组后通过调用相关存储操作接口实现的。
第 15 页共 31 页
4.Active-Passive solution
图 3 – Active-Passive overview
Master node可以被配置为主备模式。分别在两台不同的主机上安装相同版本的软件统，PGPool-II，Control模块，SQL 模块)。主Master Node 通过控制虚拟Node 通过异步/同步数据流备份的方式在主
(包括操作系
Master
IP 对外提供服务。
Master Node和副Master Node之间进行数据复制。
第 16 页共 31 页
图 4 – Master node 数据复制
Master node数据流的复制分为同步复制和异步复制，大部分操作流程都相同，主要的区别在于同步模式是主
Master节点会将每个操作在副
Master节点操作成功后才返回结果，而异步模式则在主节点
操作成功后就立即返回，随后在副节点上重复这个操作。
异步复制过程主要有如下几步：
当master节点启动后，发现自己处于副节点模式，会启动一个志信息，如果有新的操作发生，则在本节点上执行相应的操作。
wal进程，其向主节点的接收wal日
当主节点接收到副节点需要节点发过来的
wal日志信息的请求，则会开始检测主节点上的wal日志信息，根据副
cursor信息，把新的操作日志发送过去。
因为Master Node并不能自动进行主备切换，所以这里引入了个看门口狗的角色，当
PGPool-II发现本机的
PGPool-II。PGPool-II在这里扮演一
PGPool-II发IP的所有权会
Master node不能提供服务，或者副节点上的
Master Node切换到主模式。并且虚拟
第 17 页共 31 页
现主节点PGPool-II已经宕机，会触发副节点上的
从原来的主节点转让给原来的副节点。此时原来的副节点顺利切换成主节点并继续提供一致的服务，原来的主节点则可以进行检测修复等操作。对于用户而言，完全察觉不出任何的区别上。
第 18 页共 31 页
IV.Data Node
1.简介
是实际对数据进行存储，并且能够对数据进行初步处理和过滤，以仅可能少的数据返回给Server端，DataNode存储数据的单位是
Tablet，并且一个
SQL
DataNode会有多个Tablet，并且他们是扁平
的。还有DataNode可以使用多线程技术来进行加速。
图 5 – Data Node Architecture
2.重要模块
DB
也就是数据库，其包含多个
来说，其实
Table，DB这个概念还是偏管理的，资源隔离和用户管理，理论上
DB的资源，也就是说，某些
DataNode只能用于某个
Table和DataNode都是属于某个
DB共享；
DB，并不能像现在那样全集群所有
Table
在DreamData中，现在主要是通过
Hash算法将一个
Table分为多个
Tablet Group，每个Tablet
第 19 页共 31 页
Group包含一定的Hash Slot个数，这个Hash Slot和这个Table的Distributed Column相关，任何行到底
Distributed Column列的Hash值获得的，一般选择比较常用和
Table的Hash Slot个数虽然现在大多采用一个固定的算
filter的场景，在性能方面会更好。
属于具体HashSlot，都通过计算这个行的重复几率较低的列，比如主键。还有具体每个法，但是如果
HashSlot多的话，可能压缩率会低一点，但是对于带
Tablet Group
不仅像上面说的那样，
Tablet Group不仅包含属于一定
Hash Slot的数据。并且它可以有多个
Tablet
作为备份，但是现在暂时只有做为主备份的这样做法一致性会比较容易做到，具有多个
Tablet接受查询请求，这样的做法核心还是一致性的问题，Tablet在Tablet Group中备份的顺序和
Order一致；
Tablet
每个Tablet应该包括其所属
Tablet Group的所有的数据，每个
Tablet在技术层面，主要包括
WAL，Memstore和YFile这三个结构，具体可以看附录；
Tablet Order
主要用来表示异步备份的顺序的异步到Tablet 1，之后异步到
Pipeline，也就是假设有三个
Tablet，新的数据先到
Tablet 0，之后
Tablet 2；
TableInfo
这个数据结构件包含所有
Table相关的元数据，无论
DataNode还是
Client端都主要通过从
ControlServer获取其TableInfo，并且通过处理这个TableInfo获取其Tablet Order。
3.数据存储
分析一下用于存储和分析数据的写入的时候，数据会首先写到这个
DataNode节点，每个DataNode会运行和存储多个Tablet，当数据
Tablet的WAL日志上，接着会写入至一个位于内存的数据结构
Memstore中，WAL全称为“Write-Ahead Log”，主要用于暂存那些最新的数据更新请求，以避免当Tablet中的Memstore被意外关闭时所造成的数据丢失。接着，当
第 20 页共 31 页
Memstore存储的数据达到一定的阀值
时，它会将数据整理一下，之后批量写入硬盘，写入格式为性能好的特性。最后，系统会清空
YFile。所以这样能有效地利用硬盘顺序读
WAL日志中那些已经写入的数据。
在底层结构方面，除等操作，直接加一个
WAL是比较简单的，就是对任何对数据有影响的操作，比如，插入、更新和删header写入到底层
WAL文件中。Memstore和YFile在架构方面有点类似，都主
HashSlot所
YFile的
要由HashSlotBlock和ColumnBlock这两层次组成。HashSlotBlock主要是用于存储对应那个有的数据，而且目录，对于每个
HashSlotBlock包含所有列的
ColumnBlock。每个YFile会在tablet目录中生成
HashSlotBlock会生成xxx.yfile的文件。
4.数据导入
概括
目前集群的数据倒入分三种：
1.单条/多条记录插入。2.单个文件导入。3.批量文件导入。这三种方
式最终使用的机制都是类似的，最后被当成多条数据记录的导入操作。
当导入数据的时候，先对导入数据的格式进行解析，把一条数据记录转换成对应特定表的各个属性的值，如果该列的值不存在，则对应的列为空。每条数据记录会按照一定策略分组，每组数据会分发到不同的数据节点进行存储。在整个导入操作开始前，会为此次导入操作贴上一个标签，如果整个导入操作成功，则为有效。如果导入操作失败，则该标签下的数据无效并被删除。
多节点的Loading
首先，Loading主要的控制操作在
Master Node中，Master Node中的有专门控制
Loading的模块，
它会根据Loading具体的情况，把具体的请求和实际的数据地址发给对应的几个Data Node；
其次，当到导入数据时候，发生导入问题（比如，某个节点突然宕机时），本次数据导入过程中之前已经导入的
Data Node的数据；
Master Node会rollback
还有，当导入数据的时候，本Master Node宕机时，这个导入操作会向其他操作一样同步到passive
第 21 页共 31 页
Master Node中。
第 22 页共 31 页
V.分布式机制
图 6 –分布式机制
1.概括
心跳是分布式里面判断一个节点是否失效的方式之一，有两种方式：时间发送心跳给
Data Node，用来判断
1、Master Node主动间隔一段
Data Node是否存活。Master Node为发送方，Data Node为接收
Data Node心跳
方；2、datanode主动发送心跳给Master Node。Master Node维护一张心跳表纪录最后的
的时间。Master Node后台线程检查心跳表以处理心跳过期的节点。为主动发送方。目前比如当支持多个
DreamData使用的是第二种。
Master Node为接收方，Data Node
lease应该有独占的概念。
(lease和心跳的区别在于，
Master Node时，只有拿着lease的Master Node才有权限修改表)。
对于heartbeat机制，DataNode会起一个单独Node发送心跳，并且可以设定新的心跳长度（也就意味着，当
Thread，这个Thread的主要作用就是间隔向Master
Length），比如DataNode向Master Node申请10分钟，
10分钟内，ControlServer在任何情况下，都不能认为
DataNode完成这个申请之后，在
这个DataNode有问题，一般常见的时间的是5-10秒。
第 23 页共 31 页
其次，当发现一个者，或者连接第三方的置在其所在
DataNode 失效的情况下，也就是心跳过期，Master Node会发邮件通知给管理
Monitoring系统。这个时候，Master Node会将这个DataNode所有的Tablet放
Working Status设置成false，数据会按照新的DataNode，等修复完成，这个
Tablet Group
TabletGroup的末尾，并且将其
的Order来写入。之后，用户可以选择修复给Master Node，
DataNode会发送renew信息
对DataNode主要调用方SQL 模块，当SQL 模块无法连接作为这个它会等待几秒（这个时间长度应该设定为和的TableInfo（目前最多重复尝试链接是在CAP中，优先选择
Tablet Group的Master Tablet，
Master Node检查心跳状态的时间相关），之后去请求最新
Consistency，也就
SQL 模块Master Tablet并
datanode3次），这样的做好主要是为了数据的
CP，而不是A，但是如果今后有更好的做法，可以优化一下。假设
TableInfo发送，但对于新的
从Master Node收到最新的Table Info之后，它会按照新的不知道现在他现在已经被
Promote了，当新的Master Tablet收到Query这样只能由Master Tablet处理的
promote这个事实，它会从
Master Node端获取最新的
TableInfo，来确认
请求时，它应该不知道自己被自己是不是最新的
Master Tablet，如果的确有变化的，它会更新自身的
Master Tablet将会返回错误的
TableInfo和Order，并继续处理
新的请求，如果没有变化的话，status code。
在Table最初始的时候，整个弃这个
Tablet和Tablet Group部署由Scheduler来生成。假设用户准备立刻放
ControlServer会自动去尝试利用
DataNode相关的Tablet。或
DataNode，这个时候用户可以执行命令来去掉，当去掉之后，
DataNode的资源来创建最新的
最空的那几个Tablet来替换和那个被放弃的
者过了一天（时间可设置），DataNode还不renew。会自动放弃这个DataNode，这个时候，ControlServer会创建新的程都通过Scheduler来做。
Tablet来替换那个
DataNode之前所有的
Tablet，并且所有替换新
Tablet的过
2.数据备份和同步
关于数据备份，主要是通过异步的的话，处理的方式会和Info，核心在
pipeline让DataNode一个一个传，如果碰到下个节点出现问题
control server获取最新的
Table
SQL Server一致，DataNode会等待几秒，并从
Tablet Send，如果在一定时间内都无法得到传送成功，数据会暂时
第 24 页共 31 页
drop掉，DataNode会
打印日志，并停止传送。
关于数据的同步，主要是针对将属于这个Tablet Group原始数据导入到新加入的
SYNC，以让属于一个
Tablet中，因为数
据同步量比较大的原因，所以会在每天特定时间进行Tablet Group的多个Tablet
都能有同一份完整的数据，一般是不忙的时间，每次同步数据的依据在于最后插入或者更新数据的时间，比如说主
Tablet上面YFile和WAL，一般分两种情况，一种情况是，目标
Tablet是全新的，这样
比较简单，直接将所有的YFile和WAL拷贝来就是，需要忽略一些会导致数据更新的命令，因为这些
renew之后的Tablet，它包含之前已经有部分数据，对
YFile都需要重新从源节点YFile了，那么本地的Tablet而言，它所属的
WALData
命令之前已经处理过了。另一个情况是，目标是
于YFile部分，主要还是看最后的更新的时间，只要更新时间是宕机之后的复制过来，同时对于
WAL部分，如果在源节点中
WAL部分已经被写入到
需要被废弃。为了简化现有的代码，整个SYNC过程会加锁。并且对于新
Node因为它是新加入的，并且替换之前出问题的DataNode，所以有可能它会有多个新Tablet，这样会
导致SYNC Storm这个问题，这个有可能需要一个顺序，进行优化。
主备份与副备份的区别
元数据层面，主备份主要通过其份，副备份也是一样的情况。
Tablet本身的存储的
TableInfo来知道自己是否是主备份还是副备
写YFile的时候，像YFile这样数据文件在主备份中会通过的话，YFile这样的数据文件会在系统的数据文件会以存；
Buffer I/O来写入，这样如果内存空间大
YFile这样的
Page Cache中有一个备份，而在副备份的情况下，
Direct I/O的形式写入，这样YFile这样的数据文件不会在，这样做法的好处是节省内
YFile的元数据和Index，主备份和副备份都会将这些加载到内存中，当然dense index的确有点占
内存，今后会考虑多个备份同时修改，现在好像副备份只加载
serve请求，当然数据一致性方面需要考虑一下，还有现在的实现需要trailer部分；
对于主备份而言，Tablet会尽可能地利用内存，首先，它会有Memstore来缓存所有的输入数据，
第 25 页共 31 页
并且有WAL日志，并且会通过备份不同的是，主备份会将
Buffer Write机制将生成的YFile放置在内存中的Page Cache，并且与副
YFile
YFile所有元数据和index都会读入到内存中，而副备份，则只会将
的Trailer（最上层的元数据信息）读入到内存，其他元数据都不会保存到内存中，已节省副备份节点内存的使用。
对于副备份而言，它会接收主备份过来的实时输入数据，并写入到的工作，这部分副备份的份，当第一副备份收到这个
Tablet将不参与，主要是由主备份将新生成的
WAL日志中。对于生成YFile
YFile作为内存块发给第一副备
YFile内存块的时候。它会做三件事：其一，它会将继续接力，将这个内存
YFile以Direct I/O形式，而不是以
Buffer I/O方式写入到内WAL日志文件。
块给下一个副备份；其二，副备份会将这个存中，这样可以不占用内存中的
Page Cache空间；其三，副备份会清除之前的
查询部分，对处理查询请求。
2.0版而言，现在对于查询主要的策略是，只让主备份处理查询请求，副备份默认不
查询tablet层面的元数据信息，对2.0版而言，现在也只有主备份处理相关的元数据查询请求。
插入数据部分，插入到主备份的数据，这个请求不会带有last append timestamp, 因为那个last
append timestamp本身是由主备份生成的，当副备份接受到插入数据的时候，这个时候这份插入数据会附带一个last append timestamp。在更新和删除部分，主和副都差不多。
当出现下面这些情况，会触发副备份去问备份收到查询请求；其二是，当副备份收到没带
Control Server，它是否已经被promote了，其一是，当副
last append timestamp的插入请求。
ASYNC的机制
就是通过现；
tablet_send接口去异步传输数据，现在应该只有插入相关的代码，更新和删除还没有实
当源Tablet异步发数据给目标Tablet失败的时候，这个时候，源Tablet也会像SQL Server那样，
向Control Server申请最新的TableInfo来获取期最新的部署情况。
第 26 页共 31 页
SYNC的机制
基本一些机制已经在底层tablet sync模块中实现，其他待补充
3.时间同步机制
对于分布式系统而言，时间是非常关键，等2.1版引入事务之后，各个节点之间必须进行统一，
主要是下面这三点：
首先，在每个初起始的时间以
Master Node所在服务器上都会起一个NTP（Network Time Protocol）服务，当然最
Active那个Master Node上面那个NTP为准；
其次，每个新加入的地系统时间方面，这个
Data Node在加入到集群中或者已经失效的Data Node重新加入集群中，在本
DataNode会自动和Active Master Node上面的NTP服务进行同步；
还有，当Active Master Node宕机的时候，整个集群的系统时间将以新的Active Master Node的
Active
NTP服务所提供的时间为准，并且因为新的Master Node同步了，所以新的宕机的时候，新的
Active Master Node之前已经在时间方面和过去
Active Master Node的系统时间和之前一致，还有当Passive Master Node
Passive Master Node所在的服务器会在时间方面和Active Master Node同步。
4.分布式lease机制查询过程备忘
DataNodeInfo中的lease_end_timestamp是用于记录lease情况的，DataNode有一个线程叫data_node_apply_new_lease_thread（现在还没有正式启用），这个线程会不断地根据设定的Master Node Apply新的Lease，在Master Node中，它会在那些DataNode已经过期了，之后在找个这个Group，Lease End的Tablet将发在最后，这个
interval来向
go_through_data_node_info这个方法中发现
Tablet和其所在的对应的
Tablet
DataNode的对应的那些
Lease End的Tablet将会放在整个Tablet Group最后面，
并设置working为false。对于Tablet Group而言，本来在这个Lease End的Tablet之后的Tablet的Order
Lease End的
会自动进一。最后，由于现在整体还比较初级的原因，所以采取比较保守的方式，对于
第 27 页共 31 页
Data Node暂不删除；
DataNode之间主要有两种同步，其中平时新数据的同步，主要是通过数据异步地从
tablet_send这个源文件来将
Tablet Order 0传到1， 1传到2，还有一种同步是大数据级别的同步，特别是需要将旧数
Tablet Group的Tablet，这方面的代码主要在1，1到2，具体备份时间在
tablet_sync.c中，具体备份顺序先
begin_sync_hour和
据备份给一个新加入的从Order 0备份到
Data Node里面设置，分别是
last_sync_day这两个参数；
现在当出现lease end的Data Node时候，只是记录一下，并没有一个方法来使用剩余的
Data node的空白。
Data Node
来trigger新的scheduler plan来填补那个问题
第 28 页共 31 页
VI.内存管理机制
在内存使用方面，对于
DreamData这样需要长时间运行的服务器进程而已，如何做好相关的内存管
理是极为关键的，特别是要面对四种挑战：其一是内存泄露，任何微小内存的泄露，随着发生次数的积累，都会导致大量内存的泄露；其二是内存碎片，传统的
Malloc机制，主要擅长小块和短生命周期的
内存，如果经常分配大块内存的话，会造成大量内存碎片，最终的后果就是内存被用完了；其三是性能问题，有些大块内存，可能在某些逻辑里面被重复的使用，如果总是的系统调用，这对性能会产生影响，一般性能差别会在也就是Linux系统自带的完善；
malloc和free的话，会造成过大
PTMalloc的效率，PTMalloc
PTMalloc都不够
5%左右；其四是
Malloc程序，无论是在内存的回收，还是在多线程场景下，
为了应对好上面提到那四个挑战，我们这边主要采用下面四个措施：其一是对于内存泄露，主要是采用业界标准的
Valgrind程序来跑几个
DreamData主要的测试用例，来对内存的泄露情况进行测试，并
Valgrind；其二是对于内存碎片这个问题，我们对于那些
MMAP程序来从系统的内存池里面
且每次代码有更新，内部大块（一般
Jenkins都会跑一下
8K以上）内存，并且有一点生存期的情况下，会使用
直接获取，并且用完之后，直接释放；其三是性能问题，对于那些特别常用的大块内存，并且频繁使用的，一般会使用内存池来缓存那些大块内存；其四对于认自带的
PTMalloc的效率问题，我们采用了
BSD系统默PTMalloc好很
JeMalloc，JeMalloc不仅在内存的回收，还是在多线程场景上面，都效率比
BSD系统自带的，所以它的稳定性也是有保障的。
多，同时因为它是
第 29 页共 31 页
VII.V3.0版的初步设计思路
之前2.1版，在整体方面，产品整体架构主要暴露了下面这四个问题：
1.对SQL语言的完美支持；
2.对多种查询进行优化，包括两个大表
进行优化；
3.简化数据的同步和灾备的机制，之前的
2.1的机制非常复杂，并且不易于长期的维护；
ACID不需要全部支持，但是
A原子
Join的优化，以及在海量数据情况下，对各种单表的查询
4.插入和导入数据都无法做到原子化，或者单行事务，虽然
化还是需要支持的；
现阶段，对于v3.0版主要提出下面这四个思路：
1.讲Postgres的处理引擎整合到
操作，这个还需要对2.在整体架构层次方面，在
YD内，或者直接基于Postgres的Scan部分进行修改，具体如何
Postgres代码进行进一步深入；
Table下面引入Column Group的概念，具体见下面的介绍；
YD端，这样也能减轻
YD方面的压
3.新一代的导入思路，将会把主要机制写在导入端，而不是
力，已经实现的复杂度；4.考虑在数据在存储的时候，导入
务化；
timestamp或者epoch的概念，从而实现数据插入的原子化和事
Column Group
一个Table可以有多个Column至少存在一个
Column Group，每个Column Group包含的具体的
Column Group可以看作一张
Column不定，但是每个Mini Table，并且每个
Column Group中，每个
Column Group都可以按照某一列分布，同时按某列进行分布，按某列进行排序，并且分布和排序的列，可以不一致的。除了们之间使用
Column Group之外，还有
Co-Locate的概念可以考虑，就是假设多个表，他
PK/FK来进行连接，这个时候可以使这两个表默认使用同一个分布方式来进行分布，这样
第 30 页共 31 页
两个表的Join可以在YD本地完成。
同步
同步可以完全基于客户端，多个driver）来进行传送，只要多个
duplicate的数据，都可以通过客户端（也包括Master Node里面的
duplicate都接收完成，这批数据才能算commit成功，并且节点失效后的
恢复，也通过客户端来进行检测，不断地打印实时恢复的进度。这样设计，虽然会对导入性能有所影响，但是对整体的架构简化了很多，并且就算性能降低，但是导入已经很快了，大多数情况下，应该都不是瓶颈。
Timestamp
给Table默认加入一个类似子或者事务这样的操作。
Timestamp的列，记录一下commit成功的信息，这样方便今后加入原
第 31 页共 31 页
因篇幅问题不能全部显示，请点此查看更多更全内容