大数据平台架构设计说明书

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