Understanding HBase and BigTable 译文

有时间翻译一下这篇文章。http://jimbojw.com/#understan…Google BigTable论文可下载:https://ai.google/research/pu…在学习HBase(Google BigTable 的开源实现)的时候,我们面临的最为困难的部分就是你需要重构你的思路来理解BigTable的概念。非常不幸的是,在BigTable和HBase名称中出现的table和base这两个单词,很容易让我们与RDBMS(关系型数据库管理系统)中的概念相混淆。本文旨在从概念维度去描述清楚分布式数据存储系统的含义。我们希望在读完这篇文章之后,你能够更有经验去决定你到底需要的是HBase还是一个传统数据库系统。术语幸运的是,在论文Google’s BigTable Paper中已经清晰的解释了BigTable是什么。在Data Model章节的第一句话是:BigTable是一种稀疏的、分布式的、持久化的多维有序字典。论文继续解释到:BigTable由索引行、索引列以及时间戳组成,在字典中的每个值都是无解释的字节数组。在Hadoop wiki的HBaseArchitecture页面中指出:HBase使用了一种与Bigtable非常相似的数据模型。用户在标记表中存储数据行,数据行中有一个有序的key和任意数量的列。这张表的存储是稀疏的,所以如果用户喜欢的话,甚至可以在同一张表的每行中疯狂的存储差异巨大的列。上面提到的这些概念似乎很神秘,但其实如果你要是想明白的话这些说法都是有道理的。下面我们就按照顺序讨论一下几个主题:字典、持久化、分布式、有序、多维和稀疏。相比起试图直接描述一个完成的系统框架,我觉得描述清楚构建系统框架的核心要素更加容易理解。字典HBase 和 BigTable的核心是字典。根据你所使用的编程语言背景,你可能更加熟悉与之类似的词语是数组(PHP)、字典(Python)、哈希表(Ruby)和对象(JavaScript)。维基百科对字典的定义是:由一组关键字和值组成的抽象数据类型,其中每个关键字都关联一个值。使用JavaScript Object Notation语法,简单的字段示意如下所示:{ “zzzzz” : “woot”, “xyz” : “hello”, “aaaab” : “world”, “1” : “x”, “aaaaa” : “y”}持久化持久化意思是说添加到字典中的数据在系统创建或处理完成后永远存在,这个概念和其他各种持久化存储系统并无不同,比如存放在文件系统中的文件一样。分布式HBase 和 BigTable 构建在分布式文件系统之上以便底层文件存储能够在独立机器阵列中分布存储。HBase能够构建在Hadoop’s Distributed File System (HDFS)或者Amazon的Simple Storage Service (S3)上,而BigTable能够在Google File System (GFS)中使用。数据以一种类似于RAID系统的方式在多个参与节点中进行复制。本文的目标并不关心分布式系统的实现方式,本文要说明的重点是HBase和BigTable是分布式的,提供了一个保护层,如集群中某一节点故障。有序不像大多数字典的实现,在HBase/BigTable中键值对保持严格的字典序。即关键字『aaaaa』之后紧挨着『aaaab』,并且与『zzzzz』距离很远。考虑我们之前的例子,有序的版本看起来是这样的:{ “1” : “x”, “aaaaa” : “y”, “aaaab” : “world”, “xyz” : “hello”, “zzzzz” : “woot”}由于这些系统常常非常巨大而且是分布式的,有序特征实际上非常重要。相似的关键字的行紧密相邻,当你必须对表进行扫描时,你最感兴趣的条目之间彼此相邻。那么,选择什么样的行关键字就显得十分重要。举个例子,考虑一个表的关键字是主机名,那么最好的办法就是使用主机名的逆序列出他们,例如使用com.jimbojw.www而不是www.jimbojw.com,以便相同子域的那些行都与父域名称相邻。继续域名的例子,域名为mail.jimbojw.com的行将与名称为www.jimbojw.com的行紧邻,而不是mail.xyz.com。在HBase/BigTable中的有序并不意味着值是有序的。除了关键字外并没有任何自动的索引方式,这里的实现就和旧有的字典实现一样。多维到目前为止,我们还没有提到任何有关『列』的概念,处理『表』,而不是普通意义上的哈希表。『列』这个词也像是『table』和『base』的概念一样,承载了太多的RDBMS的情感在内。代替的,我们可以把它理解为一个多维字典——即字典中嵌套字典。在上面JSON示例中增加一维:{ “1” : { “A” : “x”, “B” : “z” }, “aaaaa” : { “A” : “y”, “B” : “w” }, “aaaab” : { “A” : “world”, “B” : “ocean” }, “xyz” : { “A” : “hello”, “B” : “there” }, “zzzzz” : { “A” : “woot”, “B” : “1337” }}在上面的例子里,你注意到每个key都指向含有两个key:A和B的字典。从这里开始,我们将顶级的键值对称之为行。在BigTable/HBase概念中,A和B被称之为『列簇』。表创建时列簇即被指定,之后不可能或者很难被修改。增加新的列簇也十分昂贵,因此最为明智的做法是在最开始就指定好列簇。幸运的是,列簇可以有任意列,由『标识符』或『标签』指定。下面是JSON示例的子集,其中包含列标识符:{// … “aaaaa” : { “A” : { “foo” : “y”, “bar” : “d” }, “B” : { "" : “w” } }, “aaaab” : { “A” : { “foo” : “world”, “bar” : “domination” }, “B” : { "" : “ocean” } },// …}注意表示的两个行,A列簇有两个列:foo和bar,B列簇仅有一个列,它的标识符是空字符。当向HBase/BigTable查询数据时,你必须提供全部列名,形式为:family:qualifier。对于这个例子,以上例子有三个列子:A:foo,A:bar和B:。注意,尽管列簇是静态的,列本身不是,考虑下面展开的行:{// … “zzzzz” : { “A” : { “catch_phrase” : “woot”, } }}在这个示例中,行zzzzz有一列『A:catch_phrase』。由于每一行都有任意数目不同的列,没有内建的方式查询所有行中的所有列的列表。为了获得信息,你需要做一次全表扫描。但是你可以查询所有列簇的列表,因为他们是不可变的。在HBase/BigTable中的最后一维是时间。所有数据要么使用整型时间戳,要么使用自定义的整型数据去标识版本。客户端在插入数据时可以指定时间戳。使用任意整型时间戳的例子:{// … “aaaaa” : { “A” : { “foo” : { 15 : “y”, 4 : “m” }, “bar” : { 15 : “d”, } }, “B” : { "" : { 6 : “w” 3 : “o” 1 : “w” } } },// …}每个列簇都有自己的规则规定了一个单元格最多能有多少个版本,在不给定时间戳的情况下,应用将请求被给定单元格数据。通常情况下,HBase/BigTable将返回最近的版本(即时间戳的值最大),因为它是按照时间逆序存储的。如果应用程序请求给定时间戳的给定行,HBase将返回时间戳等于或小于给定时间戳的单元格数据。使用我们想象的HBase表,请求"aaaaa"/“A:foo"返回"y”,请求"aaaaa"/“A:foo”/10返回"m",请求"aaaaa"/“A:foo”/2返回空结果。稀疏最后一点是稀疏。上面提到过了,在每个列簇中可以有任意数量的列,或者没有。另一种类型的稀疏是基于行的间隙,这仅仅意味着键之间可能存在间隙。当然,如果你以HBase/BigTable中基于字典的概念考虑的话就很好理解,而非RDBMS中相似的概念。结语希望本文能够帮助你从概念上理解HBase数据模型感觉是什么。就像总说的一样,我期待着你的想法、评论和建议。 ...

February 27, 2019 · 1 min · jiezi

Kubernetes对卷快照Alpha支持的现况

作者:Jing Xu(谷歌)、Xing Yang(华为)、Saad Ali(谷歌)Kubernetes v1.12引入了卷快照(volume snapshot)支持作为alpha功能。在Kubernetes v1.13,它仍然是alpha功能,但增加了一些强化和一些重大更改。这篇文章总结了这些变化。重大更改CSI spec v1.0对卷快照功能进行了一些重大更改。CSI驱动程序维护者在升级其驱动程序以支持v1.0时,应该了解这些更改。SnapshotStatus替换为Boolean ReadyToUse在CSI v0.3.0,CreateSnapshotResponse中定义了SnapshotStatus枚举(enum),表示快照是READY,UPLOADING,还是ERROR_UPLOADING。在CSI v1.0,SnapshotStatus已从CreateSnapshotResponse中删除,并替换为布尔值(boolean)ReadyToUse。ReadyToUse值为true,表示完成后快照处理(post snapshot processing),例如上载,并且快照已准备好用作创建卷的源。需要进行后快照处理的存储系统(例如在快照完成后上传),应该在快照完成后返回成功的CreateSnapshotResponse,并将ReadyToUse字段设置为false。这表示容器箱编排系统(Container Orchestration System,CO),可以恢复因为进行快照而停顿的任何工作负载。然后,CO可以重复调用CreateSnapshot,直到ReadyToUse字段设置为true,或该调用返回一个错误,指示处理中出现问题。CSI ListSnapshot调用可以与snapshot_id过滤一起使用,以确定快照是否可以使用,但不推荐使用这个方式,因为它无法在处理过程中检测错误(ReadyToUse字段只是无限期地保持为false)。CSI外部快照边车容器(external-snapshotter sidecar container)的v1.x.x版本,已通过调用CreateSnapshot,而不是ListSnapshots来处理此更改,以检查快照是否可以使用。当升级驱动程序到CSI 1.0时,驱动程序维护者应使用相应的1.0兼容边车(sidecar)容器。为了与CSI规范的更改保持一致,VolumeSnapshot API对象中的Ready字段已重命名为ReadyToUse。当执行kubectl describe volumesnapshot以查看快照的详细信息时,用户可以看到此更改。时间戳数据类型快照的创建时间作为VolumeSnapshotContent API对象的一部分可供Kubernetes管理员使用。该字段使用CSI CreateSnapshotResponse中的creation_time字段填充。在CSI v1.0中,此creation_time字段类型已更改为.google.protobuf.Timestamp,而不是int64。将驱动程序升级到CSI 1.0时,驱动程序维护者必须相应地进行更改。CSI外部快照程序边车容器的v1.x.x版本已更新以处理此更改。弃用以下VolumeSnapshotClass参数已被弃用(deprecated),将在以后的版本中删除。它们将替换为下面Replacement“替换”部分中列出的参数。弃用csiSnapshotterSecretName,替换csi.storage.k8s.io/snapshotter-secret-name弃用csiSnapshotterSecretNameSpace,替换csi.storage.k8s.io/snapshotter-secret-namespace新功能SnapshotContent删除/保留(Deletion/Retain)政策如在宣布快照alpha的初始博客文章中所述,Kubernetes快照API类似于PV/PVC API:就像卷(volume),由绑定的PVC和PV对表示一样,快照由绑定的VolumeSnapshot和VolumeSnapshotContent对表示。对于PV/PVC对,当用户完成使用卷时,他们可以删除PVC。PV上的回收政策决定PV之后的处理(是删除,还是保留)。在最初的alpha版本中,快照不支持指定回收政策的功能。当删除快照对象时,它总是导致快照被删除。在Kubernetes v1.13中,添加了快照内容DeletionPolicy。它使管理员,能够配置VolumeSnapshotContent在绑定的VolumeSnapshot对象被删除后的处理方式。卷快照的DeletionPolicy可以是Retain(删除)或Delete(保留)。如果未指定该值,则缺省值取决于SnapshotContent对象,是通过静态绑定,还是动态配置创建的。Retain(保留)Retain(保留)政策允许手动回收资源。如果是静态创建并绑定VolumeSnapshotContent,则默认的DeletionPolicy为Retain。删除VolumeSnapshot时,VolumeSnapshotContent继续存在,VolumeSnapshotContent被视为“已释放”(“released”)。但它不能用于绑定到其他VolumeSnapshot对象,因为它包含数据。由管理员决定如何处理剩余的API对象和资源清理。Delete(删除)Delete(删除)政策允许从Kubernetes自动删除绑定的VolumeSnapshotContent对象,以及外部基础结构中的关联存储资产(例如AWS EBS快照,或GCE PD快照等)。动态配置的快照会继承其VolumeSnapshotClass的删除政策,该政策默认为Delete。管理员应使用所需的保留政策配置VolumeSnapshotClass。创建政策后,通过修补(patching)对象,可以更改单个VolumeSnapshotContent的政策。以下示例演示如何检查动态调配的VolumeSnapshotContent的删除政策。$ kubectl create -f ./examples/kubernetes/demo-defaultsnapshotclass.yaml$ kubectl create -f ./examples/kubernetes/demo-snapshot.yaml$ kubectl get volumesnapshots demo-snapshot-podpvc -o yamlapiVersion: snapshot.storage.k8s.io/v1alpha1kind: VolumeSnapshotmetadata: creationTimestamp: “2018-11-27T23:57:09Z”…spec: snapshotClassName: default-snapshot-class snapshotContentName: snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 source: apiGroup: null kind: PersistentVolumeClaim name: podpvcstatus:…$ kubectl get volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -o yamlapiVersion: snapshot.storage.k8s.io/v1alpha1kind: VolumeSnapshotContent…spec: csiVolumeSnapshotSource: creationTime: 1546469777852000000 driver: pd.csi.storage.gke.io restoreSize: 6442450944 snapshotHandle: projects/jing-k8s-dev/global/snapshots/snapshot-26cd0db3-f2a0-11e8-8be6-42010a800002 deletionPolicy: Delete persistentVolumeRef: apiVersion: v1 kind: PersistentVolume name: pvc-853622a4-f28b-11e8-8be6-42010a800002 resourceVersion: “21117” uid: ae400e9f-f28b-11e8-8be6-42010a800002 snapshotClassName: default-snapshot-class volumeSnapshotRef: apiVersion: snapshot.storage.k8s.io/v1alpha1 kind: VolumeSnapshot name: demo-snapshot-podpvc namespace: default resourceVersion: “6948065” uid: 26cd0db3-f2a0-11e8-8be6-42010a800002用户可以使用补丁(patch)更改删除政策:$ kubectl patch volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -p ‘{“spec”:{“deletionPolicy”:“Retain”}}’ –type=merge$ kubectl get volumesnapshotcontent snapcontent-26cd0db3-f2a0-11e8-8be6-42010a800002 -o yamlapiVersion: snapshot.storage.k8s.io/v1alpha1kind: VolumeSnapshotContent…spec: csiVolumeSnapshotSource:… deletionPolicy: Retain persistentVolumeRef: apiVersion: v1 kind: PersistentVolume name: pvc-853622a4-f28b-11e8-8be6-42010a800002…保护使用中的快照对象“保护使用中的快照对象”(Snapshot Object in Use Protection)功能的目的,是确保不会从系统中删除正在使用的快照API对象(因为这可能会导致数据丢失)。有两种情况需要“使用中”(“in-use”)保护:如果卷快照正在被PVC作为创建卷的源。如果VolumeSnapshotContent API对象绑定到VolumeSnapshot API对象,会认为该内容对象正在使用中。如果用户删除PVC正在使用的VolumeSnapshot API对象,VolumeSnapshot对象不会被立即删除。删除VolumeSnapshot对象被推迟,直到任何PVC不再使用VolumeSnapshot。同样,如果管理员删除了绑定到VolumeSnapshot的VolumeSnapshotContent,VolumeSnapshotContent不会被立即删除。删除VolumeSnapshotContent被推迟,直到VolumeSnapshotContent没有绑定到VolumeSnapshot对象。哪些卷插件支持Kubernetes快照?快照仅在CSI驱动程序支持(不适用于树内“in-tree”或Flexvolume)。要使用Kubernetes快照功能,请确保在群集上部署实现快照的CSI驱动程序。截至本博文发布时,以下CSI驱动程序支持快照:GCE Persistent Disk CSI DriverOpenSDS CSI DriverCeph RBD CSI DriverPortworx CSI DriverGlusterFS CSI DriverDigital Ocean CSI DriverEmber CSI DriverCinder CSI DriverDatera CSI DriverNexentaStor CSI Driver其他驱动程序的快照支持正在等待阶段,应该很快就可以使用。阅读“Kubernetes的容器存储接口(CSI)GA了”博客文章,了解有关CSI以及如何部署CSI驱动程序的更多信息。下一步?根据反馈和采用情况,Kubernetes团队计划将CSI Snapshot实施在1.15或1.16版本推向beta。我们感兴趣的一些功能包括一致性组(consistency group)、应用程序一致性快照、工作负载停顿、就地恢复等。怎样才能了解更多?快照API和控制器的代码存储库位于:https://github.com/kubernetes…在此处查看有关快照功能的其他文档:http://k8s.io/docs/concepts/s…://kubernetes-csi.github.io/docs/怎样参与?像所有Kubernetes一样,这个项目是许多来自不同背景的贡献者共同努力的结果。特别感谢所有帮助增加CSI v1.0支持,并改进此版本快照功能的贡献者,包括Saad Ali(saadali)、Michelle Au(msau42)、Deep Debroy(ddebroy)、James DeFelice(jdef)、John Griffith (j-griffith)、Julian Hjortshoj(julian-hj)、Tim Hockin(thockin)、Patrick Ohly(pohly)、Luis Pabon(lpabon)、Cheng Xing(verult)、Jing Xu(jingxu97)、Shiwei Xu(wackxu)、Xing Yang(xing-yang)、Jie Yu(jieyu)、David Zhu(davidz627)。有兴趣参与CSI或Kubernetes存储系统任何部分的设计和开发的人士,请加入Kubernetes存储特别兴趣小组(SIG)。我们正在快速成长,一直欢迎新的贡献者。我们还定期召开SIG-Storage Snapshot工作组会议。欢迎新的参与者加入设计和开发的讨论。2019年KubeCon + CloudNativeCon中国论坛提案征集(CFP)现已开放KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂,面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导,和我们一同探讨云原生生态系统发展方向。2019年中国开源峰会提案征集(CFP)现已开放在中国开源峰会上,与会者将共同合作及共享信息,了解最新和最有趣的开源技术,包括 Linux、容器、云技术、网络、微服务等;并获得如何在开源社区中导向和引领的信息。大会日期:提案征集截止日期:太平洋标准时间 2 月 15 日,星期五,晚上 11:59提案征集通知日期:2019 年 4 月 1 日会议日程通告日期:2019 年 4 月 3 日幻灯片提交截止日期:6 月 17 日,星期一会议活动举办日期:2019 年 6 月 24 至 26 日2019年KubeCon + CloudNativeCon + Open Source Summit China赞助方案出炉啦 ...

January 23, 2019 · 2 min · jiezi

手把手教你如何通过 KubeSphere 玩转 Kubernetes 存储

青云知行学院最新课程出炉啦,欢迎订阅,还有青云优惠券放送!!主题: KubeSphere 系列培训课程(二)- 如何通过 KubeSphere 玩转 Kubernetes 存储时间:1 月 23 日 20:00 —— 21:30本期内容介绍:本节课主要介绍KubeSphere 存储的特点,如何配置存储类型,如何使用存储功能。本次课程内容如下:Kubernetes 存储现状(静态分配/动态分配,in-tree/out-of-tree, Flex/CSI)KubeSphere 存储特点(ks存储选型,支持多种存储的对接,青云自主存储产品对接,扩展的 API)如何设置KubeSphere 存储类型 (ks 不同部署方式存储支持类型,ks安装时设置存储类型,ks运行时设置存储类型)一步步详细体验KubeSphere 存储(创建存储卷,工作负载使用存储卷,查询存储类型,查询存储卷,工作负载卸载存储卷,删除存储卷)听课福利:在课程中留言“来自SF”的前 3 名同学将获得青云QingCloud T 恤一件。数量有限,赶快来唠吧学习方式:千聊知行学院,扫码即可报名????

January 17, 2019 · 1 min · jiezi