kudu翻译

KUDU翻译2kudu概述2.1表和模式（schemas）在使用者看来，kudu是一种基于表结构的数据存储系统。一个kudu集群拥有很多数量的表，每一个表都有很好的模式定义。模式包含一个有限的列数。每个列都有一个名字，类型（int32、string）和是否为空的选项。在这些列中有已经排序好的子集被叫做主键。行具有主键唯一约束性。针对行的主键可以进行唯一索引建立，这会提高行的更新删除性能。这种数据模型很像是关系型数据库，不同于很多分布式数据存储方式，如Cassandra，mongoDB，Riak，BigTable等等。和传统的关系型数据库相比，用户需要在建立一个表的同时定义这个表的模式。在不建立模式的表进行插入操作会报错，同时也违反了主键唯一性原则。用户对表的主键列是不可以添加或删除的。我们设计必须指定列的类型而不像其他NoSql类型使用的“everythingisbytes”。这有以下两个出发点：1.指定类型允许我们可以使用特定类型的列编码格式。例如使用整数的位填充。2.指定类型允许我们使用类SQL的元数据传输到其他系统，例如使用常用的BI或数据处理工具。与其他关系型数据库不同的是kudu现在不支持第二索引或者有其他类似主键的具有唯一性的存在。当前，kudu需要为每个表都定义主键，将来我们希望kudu可以自动生成自适应的唯一性主键。2.2写操作建表之后，用户使用插入，更新和删除的APIs更改表。在这些场景下，用户必须指明一个主键。主键是删除更新等高等级操作的唯一依赖。Kudu提供Java、C++和python接口。这些接口允许准确控制批量异步的错误处理以平摊执行或操作批量数据处理的损耗。例如数据的装载和更新。最近kudu取消了对任意多行事务apis。每次概念的更新都是因为性能提升的需求。当行数据修改对比多行的修改在原子性上表现更好。2.3读操作Kudu只提供扫描操作来从表中检索数据。在扫描时，用户可以设置多个过滤策略来获得结果。最近，我们提供两种策略类型：在列与值之间的比较，在主键范围内的综合比较。这些判断比较策略在APIs内都提供了，可以高效的在磁盘和网络间传输数据。为了能够使用这个策略，用户需要为一个扫描制定一个规划。这个规划必须包含被检索的列的子集。因为kudu是基于磁盘的列式存储，指定一个子集能够提高定型的分析工作性能。2.5一致性模型Kudu客户端有两种一致性模型的选项。默认的一致性选择是快照（snapshot）一致性。扫描是一种快照的实现形式。这是假设在没有错误的情况下的。现实情况可能正好相反。这在单客户节点是“读你所写”一致性的可靠实现。默认情况下，kudu不提供外部一致性策略。也就是说，如果客户端执行写操作，同时另一个客户端通过外部机器也执行写操作，这将导致数据非一致。这时用户读只能得到后来的写结果。基于我们的实践，使用其他系统的保障数据一致性的手段（比如利用HBase）在很多场景下也是不可靠的。然而，对用户而言，他们需要一个健壮性强的策略，kudu提供一个选项让用户自定义在客户端之间传输时间戳：在写操作后，用户在客户端请求一个令牌时间戳，这个token可以通过外部通信传输到另外的客户端，在APIs处理数据的时候就能够获得不同客户端对同一数据的写操作的前后关系。（向量时钟S3使用此处理最终一致性）如果tokens在传输中过于复杂，kudu会作为spanner（掌管者）随意对某token启动“提交等待”。在一个写操作执行后，提交等待功能变为可获取，此时这个客户端被延后提交以确保接下来的写操作能够顺利执行。缺少可信时间制造的硬件的情况下，即只使用本身的NTP控制器，有100-1000ms的延时或误差。期望用户谨慎选择一致性策略。值得注意的是，使用spanner和基于真实时间时钟的策略还是有优势的。能够提供集群多有机器的全局时间同步还是一种奢望。作为一种辅助策略，时间戳是基于一种叫做HibridTime的时钟算法。2.6时间戳Kudu不允许用户手动设置时间戳。这是和其他系统（Hbase和Cassandra）不同的。那些系统是将时间戳作为数据模型的第一层次的重要组成。在我们使用这些系统时，发现不同用户对时间戳规划的手段各有高低，甚至有部分用户错误的制定时间戳规则。特别是在基于语义的依赖时间的插入删除处理场景。但是在读操作上允许用户指定时间戳。这有利于用户对历史数据的断点查询。同时也确保了分布式多任务在读一致性快照时能够建立统一的查询任务。3.架构3.1集群角色一个master负责metedata，若干个tabletservers负责数据存储。有灾备控制，具有高可用性，使用日用级硬件，资源可水平扩展。3.2分区作为分布式数据库系统中的一员，表在kudu里被水平分区。Kudu，就像BigTable，称这种水平分区方式为tablets。任一行依据主键值可以被精确map到一个tablet，这确保了每次插入更新操作只针对一个tablet。对于大表，吞吐量只一个重点，我们建议一台机器布置10-100个tablets，每个tablet10GB。与BigTable不同的是，它只提供基于Key的分区。也不像Cassandra，它是基于hash表分区。Kudu支持一种灵活的分区方案。在建表时，用户为这个表选择一种分区模式。这种分区原理就是把主键元组映射到分区key。每个tablet包含一组连续的分区keys的范围值。这样，客户端在执行读写操作时能够很容易的决定哪个tablet会持有被给与的key，客户端也能够很容易的依照这个key发送请求。这个分区模式是建立在0到多个hash分区规则的基础上的，这些规则属于自定义的范围分区规则：一个hash分区规则包含主键列的子集和一个桶号。例如，执行一段sql语句：DISTRIBUTEBYHASH(hostname,ts)INTO16BUCKETS。规则会首先根据连续的列值把元祖tuples转换成二进制key，接着计算请求返回桶号的hash码。这些产生的桶号会被编码成32bit整数放进生成的分区key。一个范围分区规则包含主键列的子集。规则中tuples被映射到二进制string流。这些strings是一组连续的被选列值，这些值使用order-preserving（保序）编码。使用这些分区规则，用户可以很容易的进行并发查询。用户可以自定义分区规则。例如，在一个时间序列的应用场景下，数据列形式是host，metric，time，value。每次插入操作总会自动添加一个时间值。选择根据时间的hash分区规则是一种最优负载选择。但是，在一个很短的时间段内查找一个特定host的一个元数据就需要扫描全部tablets，这限制了并发的发生。这时用户就会选择基于时间戳的范围分区。同时对metic和host字段进行分别的hash分区。这样会对并发读写带来很好的性能。用户必须知道分区概念才能很好的使用kudu。分区编码后的key和其传输细节对用户都是透明的。编码后的key对API不是暴露的。用户总是使用特定的行、分区分列点，key区间使用已经构造好的行对象或者sql有序的tuple。这些灵活的分区策略是典型的“NoSql”特性。这使得MPP分析数据库的用户和管理员能够很快入手kudu。3.3复制Kudu以table为单元来组织复制策略。Master作为中央控制器保障复制策略的正常执行。Kudu使用Raft一致性算法保障tablets的不同副本的一致性。Raft是基于每个tablet的逻辑操作（插入更新删除）日志来控制的。Raft保证leader的数据是最新的。客户端的写请求，会先找到这份数据的leader然后发送rpc通信去操作数据。如果客户端的leader信息是陈旧的或者找的节点不是leader，那么请求会被拒绝。客户端必须刷新它的元数据缓存并发送请求到newleader。如果一个副本是leader那么他会启动一个本地锁来串行化其他并行操作，取得一个MVCC（多版本并发控制）时间戳，通过raft将操作发给followers。大多数的follower副本执行完写操作并且在日志内留下记录后（WAL）。写操作可以被认为是成功的，并会告知所有副本。值得注意的一点是，对leader副本没有限制它必须完成写操作和日志写。这考虑到leader副本处可能会出现磁盘性能瓶颈。如果其他副本操作失败，leader副本还是可以继续执行操作和日志写，但如果leader副本也失效后，raft算法会立即选举出newleader。默认情况下，kudu使用500毫秒的心跳间隔和1500毫秒的选举间隔。因此，一个leader的失败，newleader会在几秒内被选举出来。Kudu对raft算法进行了一些小调节来增强性能：1.我们使用了一种指数回退函数，这主要用在leader选举失败之后。我们发现，把raft的持久化元数据保存在硬盘内，这样是必要的，可以确保在一个繁忙的集群内也可以顺利选举收敛。2.Kudu的leader每次分发它的操作日志都会回溯上一次操作，直到找到已经被分发过的操作点为止。这样可以确保信息在一次回传后被确认，减少了网络的占用。Kudu不备份磁盘上的tablet，只备份tablet的操作日志。Tablet的物理存储是相互隔离的。这带来了以下好处：1.考虑以下场景，一个副本在物理层级上进行溢写或者压缩操作，其他节点同时对这个tablet进行操作的可能性很低。因为raft算法是在大多数节点副本操作commit之后才认定一次操作成功。这减少了客户端写操作的延迟。将来，会引入预实现技术。例如，在并行读写负载时，此技术会进一步减少读请求的延迟（taillatencies）。2.在开发期间，我们也考虑了一些Kudutablet在物理层级的小概率操作场景。因为存储层和副本之间的脱钩，我们必须保证数据在这些特殊情况下不会永久性丢失。在这些场景下，我们发现副本在出现问题或者在被分发时会被修复。3.3.1配置变化在每个选民的配置变化都会导致Raft配置中选民数量的变化。为了保证3副本配置到5副本配置的变化，会产生3-4、4-5的分步变化和提交。Kudu通过一个叫做远程辅助引导的过程实现新服务的添加。在我们的设计中，为了添加一个新副本，必须把它作为一个新的成员添加到Raft配置中。这个动作是在通知目的服务端一个新副本将要被复制进来的之前。这个配置变化被提交之后，当前的Raftleader副本会触发一个开启远程辅助引导的rpc，让目的服务端从当前leader处获取一个tablet数据和日志的快照。传输完成后，这个新服务端会打开这个tablet。此tablet会根据日志在数据上重演一边全部操作，之后，此tablet会和leader的状态一致。之后它会作为一个从属完全状态副本与Raft进行rpc通信。在当前的实现中，新服务端的加入会立即成为选举者副本。在副本复期间，副本对应的tablet是只读的。为了处理这个缺点，我们计划实现一种叫做前选举者复制状态。在这个状态下，leader会向目标副本发送更新信息并触发远程辅助引导。但这没有考虑一个选举者会计算或者获得多数配置的状态。为了能够获取预选举者是否完成追加所有的更新操作到日志里，leader会自动的提交另一个配置变化传输到这个新副本，最终让它变成一个完全选举者。当删除一个tablet的副本时，当前leader会改变另一个节点的配置项（跟将要被移除副本的节点没有关系）。这个动作提交后，剩余节点将不在给这个移除节点发信息，尽管将被移除的节点不知道它已经被移除。配置变化被提交之后，剩余节点会向master报告配置变化，这时，才会master才会移除孤立副本。3.4kudumasterKudu的中央master的主要作用为：1.作为一个目录管理者，追踪哪些tablet的存在与否。同时存储这些tablet的概要信息，存储他们的副本等级和其他元数据信息。在表的建立、更改、删除时master通过tablet协调这些动作并确保这些动作的最终完成。2.作为一个集群调解者，追踪集群中server是否活着，并且在s