kudu翻译答题.docx

KUDU翻译 2 kudu概述 2.1 表和模式（schemas） 在使用者看来，kudu是一种基于表结构的数据存储系统。一个kudu集群拥有很多数量的表，每一个表都有很好的模式定义。模式包含一个有限的列数。每个列都有一个名字，类型（int32、string）和是否为空的选项。在这些列中有已经排序好的子集被叫做主键。行具有主键唯一约束性。针对行的主键可以进行唯一索引建立，这会提高行的更新删除性能。这种数据模型很像是关系型数据库，不同于很多分布式数据存储方式，如Cassandra，mongoDB，Riak，BigTable等等。 和传统的关系型数据库相比，用户需要在建立一个表的同时定义这个表的模式。在不建立模式的表进行插入操作会报错，同时也违反了主键唯一性原则。用户对表的主键列是不可以添加或删除的。 我们设计必须指定列的类型而不像其他NoSql类型使用的“everything is bytes”。这有以下两个出发点： 指定类型允许我们可以使用特定类型的列编码格式。例如使用整数的位填充。 指定类型允许我们使用类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，若干个tablet servers负责数据存储。有灾备控制，具有高可用性，使用日用级硬件，资源可水平扩展。 3.2分区 作为分布式数据库系统中的一员