BigTable

如何优雅的理解HBase和BigTable

最后都变了- 提交于 2020-10-06 02:32:14
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 学习 HBase 最难的地方在于要让你的脑子真正理解它是什么。 HBase:Google BigTable 的开源实现 我们经常会把关系型数据库(RDBMS,比如 MySQL)和 HBase 搞混,因为在这两个系统中都包含 table 和 base(HBase,Database)。 这篇文章的目标是从概念上来说清楚 HBase 这个分布式的数据存储系统。读完后,你应该可以很清楚的知道什么情况下 HBase 更好,什么情况下传统的关系型数据库更好。 关于一些术语 幸运的是,Google 的 BigTable论文清楚的解释了 BigTable 到底是什么。下面是论文中数据模型章节的第一句话: BigTable 是一个稀疏的、分布式的、可持久化的多维有序 map。 在这个节骨眼上,我想给读者一个机会,让他们在读到最后一行字时,能够收集到他们脑壳里的活动信息(这可能是个笑话,但我没懂^v^)。 论文中,继续解释如下: map 通过 rowKey,columnKey 和时间戳进行索引,map 中的每个值都是一个连续的字节数组。 注:rowKey 是记录的主键,唯一标识一行记录 在 Hadoop 的官方文档中,也对 HBase 的架构做了说明: HBase 使用了与 BigTable

《MapReduce: Simplified Data Processing on Large Clusters》论文研读

[亡魂溺海] 提交于 2020-10-02 21:28:47
MapReduce 论文研读 说明 :本文为论文 《MapReduce: Simplified Data Processing on Large Clusters》 的个人理解,难免有理解不到位之处,欢迎交流与指正 。 论文地址 : MapReduce Paper 1. MapReduce 编程模型 MapReduce 是 Google 提出的一种用于处理和生成大数据集的 编程模型 ,具象地可以理解成一个 框架 。 该框架含有两个由用户来实现的接口: map 和 reduce , map 函数接收一个键值对,生成一个中间键值对集合, MapReduce 框架会将所有共用一个键的值组合在一起并传递给 reduce 函数, reduce 函数接收此中间键以及该键的值的集合,将这些值合并在一起,生成一组更小的值的集合 。 该编程模型中,数据形式变换可由以下模式表示: map: (k1, v1) -> list(k2, v2) reduce: (k2, list(v2)) -> list(v3) 注 :论文中该模式第二行表示为 reduce: (k2, list(v2)) -> list(v2) ,个人认为由于通常情况下 reduce 会对 list<v2> 做一些处理(特殊情况下不做任何处理,即 reduce 为恒等函数),生成一些不同的值,所以用 list<v3>

Google Cloud Bigtable backup and recovery

爷,独闯天下 提交于 2020-08-22 04:34:12
问题 I am new to Google Cloud Bigtable and have a very basic question as to whether the cloud offering protects my data against user error or application corruption? I see a lot of mention on the Google website that the data is safe and protected but not clear if the scenario above is covered because I did not see references to how I can go about restoring data from a previous point-in-time copy. I am sure someone on this forum knows! 回答1: Updated 7/24/2020 : Bigtable now supports both backups and

如何优雅的理解HBase和BigTable

与世无争的帅哥 提交于 2020-08-20 05:32:20
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 学习 HBase 最难的地方在于要让你的脑子真正理解它是什么。 HBase:Google BigTable 的开源实现 我们经常会把关系型数据库(RDBMS,比如 MySQL)和 HBase 搞混,因为在这两个系统中都包含 table 和 base(HBase,Database)。 这篇文章的目标是从概念上来说清楚 HBase 这个分布式的数据存储系统。读完后,你应该可以很清楚的知道什么情况下 HBase 更好,什么情况下传统的关系型数据库更好。 关于一些术语 幸运的是,Google 的 BigTable论文清楚的解释了 BigTable 到底是什么。下面是论文中数据模型章节的第一句话: BigTable 是一个稀疏的、分布式的、可持久化的多维有序 map。 在这个节骨眼上,我想给读者一个机会,让他们在读到最后一行字时,能够收集到他们脑壳里的活动信息(这可能是个笑话,但我没懂^v^)。 论文中,继续解释如下: map 通过 rowKey,columnKey 和时间戳进行索引,map 中的每个值都是一个连续的字节数组。 注:rowKey 是记录的主键,唯一标识一行记录 在 Hadoop 的官方文档中,也对 HBase 的架构做了说明: HBase 使用了与 BigTable

Python 编码规范 Google Edtion

ε祈祈猫儿з 提交于 2020-08-20 01:14:35
styleguide Google Python Style Guide 1 Background Python is the main dynamic language used at Google. This style guide is a list of dos and don’ts for Python programs. To help you format code correctly, we’ve created a settings file for Vim . For Emacs, the default settings should be fine. Many teams use the yapf auto-formatter to avoid arguing over formatting. 2 Python Language Rules 2.1 Lint Run pylint over your code. 2.1.1 Definition pylint is a tool for finding bugs and style problems in Python source code. It finds problems that are typically caught by a compiler for less dynamic

选择正确的云计算数据库服务的4个技巧

删除回忆录丶 提交于 2020-08-16 10:42:01
关系数据库的应用已经有了半个世纪的历史,其各种子类别(如文档、键值数据库和缓存数据库)是IT领域中长期存在的部分。很多人可能会认为数据库创新的时代已经过去了。但是,云计算基础设施和服务的兴起为这个原本停滞不前的市场注入了新的活力。 主要的云计算提供商最初将数据库作为应用程序使用,以便在通用计算实例上运行,但很快就开始使用更高级别的应用程序服务来扩展其IaaS产品。云计算数据库已经成为技术开发的关键领域,云计算提供商可以通过启动不同类型的数据库来满足业务需求来进行竞争。 1. 了解市场 调研机构Gartner公司认为,云计算是数据库市场的未来。该公司预测,到2022年,将有75%的数据库部署在云中。这一数字基于客户对新应用程序和现有应用程序的查询和访问,这些应用程序正在以越来越快的速度向云端迁移,预计这一趋势将会加速。 例如,在Gartner公司发布的2019年数据库市场份额排名中,AWS公司排名第三,高于2013年的第七位。事实上,AWS公司数据库分析师收到大部分查询信息都与云平台有关。而且,由于托管公共云服务的弹性、可扩展性以及按需性质,在云中进行的创新可能无法在内部部署复制。 此外,Gartner公司估计,2018年云计算数据库收入占整体数据库软件和服务收入增长的68%,其中AWS和Microsoft的收入占到绝大部分。 2. 熟悉数据库选项 为了规划这个以云计算为中心的未来

大数据相关资料论文小结

流过昼夜 提交于 2020-08-15 07:54:49
前言 不知不觉,2020年已经过去一半了,最近突然反应过来自己也看了不少文献资料了,就想着把看过的文献和觉得比较好的书籍做一个总结,基本都是大数据分布式领域的,回顾自己学识的同时,也给想从事或这个领域的小伙伴一些参考 😃。最后顺便把接下来要看的东西列个列表,也会将自己学习的心得和经验分享出来,有需要的童鞋可以参考参考。 另外有些文献看完我会进行整理和输出,这部分链接我一并附在文献的介绍后面,后面看的书或是文献也会保持这种习惯,如果觉得有兴趣欢迎各位大佬交流,顺便也可以点波关注~~ 论文总结 MapReduce 《MapReduce Simplified Data Processing on Large Clusters》 从现在的眼光来看,Mapreduce可以说可圈可点。但在那个年代,这个思想可以说是相当先进的。不得不说Google一直引领技术潮流,包括近几年流行的k8s也是Google主导。 这篇文章主要介绍了Mapreduce的流程还有一些细节方面的介绍,如果已经有使用过Mapreduce编程的小伙伴应该看一遍就能懂。另外,看完如果想加以巩固的话,推荐做MIT6.824的Lab1,用go实现一个Mapreduce。至于什么是Mit6.824,百度一下就知道喔。我以前也有写过一篇介绍MR,有兴趣的童鞋不妨看看: 从分治算法到 Hadoop MapReduce 。 地址:

Hive的压缩存储和简单优化

戏子无情 提交于 2020-08-13 06:42:34
一、Hive的压缩和存储 1,MapReduce支持的压缩编码 压缩格式 工具 算法 文件扩展名 是否可切分 对应的编码/解码器 DEFLATE 无 DEFLATE .deflate 否 org.apache.hadoop.io.compress.DefaultCodec Gzip gzip DEFLATE .gz 否 org.apache.hadoop.io.compress.GzipCodec bzip2 bzip2 bzip2 .bz2 是 org.apache.hadoop.io.compress.BZip2Codec LZO lzop LZO .lzo 是 com.hadoop.compression.lzo.LzopCodec Snappy 无 Snappy .snappy 否 org.apache.hadoop.io.compress.SnappyCodec 2,文件压缩格式:   TEXTFILE和SEQUENCEFILE的存储格式都是基于 行式存储 的;   ORC和PARQUET是基于 列式存储 的。 a> TextFile格式:    默认格式,数据不做压缩,磁盘开销大,数据解析开销大。可结合Gzip、Bzip2使用,但使用Gzip这种方式,hive不会对数据进行切分,从而无法对数据进行并行操作。 b> Orc格式:    Hive 0

理解 LSM 树:写入密集型数据库的秘诀

我的未来我决定 提交于 2020-08-09 13:24:12
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 日志结构的合并树(log-structured merge-tree LSM 树)通常是在处理大量写任务时使用的数据结构。通过顺序写来优化写入路径。 LSM 树是许多数据库(包括 BigTable, Cassandra, Scylla,和 RocksDB)背后的核心数据结构。 排序字符串表 LSM 树使用排序字符串表(Sorted Strings Table 简称 SSTable)的格式保存到磁盘。如名称所示,SSTables 是一种用于存储键-值对的格式,其中键按有序排列。SSTable 将由多个名为段(Segments)的有序文件组成。一旦将这些数据段写入磁盘后,就是不可变的。简化示例如下: 我们可以看到,每个段中的键-值对都是按键排序的。接下来看看什么是片段以及它是如何生成的。 写数据 回想一下,LSM 树只执行顺序写入。我们可能想知道,当值以任意顺序写入时,如何以有序格式的顺序写入数据?这可以通过使用内存中的树结构来解决。通常被称为内存表(memtable),但底层数据结构通常是某种形式的排序树,如红黑树。当写入数据时,将添加到此红黑树中。 我们的写入将存储在这个红黑树中,直到树达到预定义的大小。一旦红黑树有足够的条目,它就会按有序的顺序作为磁盘上的一个段刷新到磁盘

【分布式】Chubby与Paxos

六月ゝ 毕业季﹏ 提交于 2020-08-07 09:53:50
一、前言   在上一篇理解了Paxos算法的理论基础后,接下来看看Paxos算法在工程中的应用。 二、Chubby   Chubby是一个面向松耦合分布式系统的锁服务,GFS(Google File System)和Big Table等大型系统都是用它来解决分布式协作、元数据存储和Master选举等一些列与分布式锁服务相关的问题。Chubby的底层一致性实现就是以Paxos算法为基础,Chubby提供了粗粒度的分布式锁服务,开发人员直接调用Chubby的锁服务接口即可实现分布式系统中多个进程之间粗粒度的同控制,从而保证分布式数据的一致性。    2.1 设计目标   Chubby被设计成为一个 需要访问中心化的分布式锁服务 。   ① 对上层应用程序的侵入性更小,使用一个分布式锁服务的接口方式对上层应用程序的侵入性更小,应用程序只需调用相应的接口即可使用分布式一致性特性,并且更易于保持系统已有的程序结构和网络通信模式。   ② 便于提供数据的发布与订阅,在Chubby进行Master选举时,需要使用一种广播结果的机制来向所有客户端公布当前Master服务器,这意味着Chubby应该允许其客户端在服务器上进行少量数据的存储和读取(存储主Master地址等信息),也就是对小文件的读写操作。数据的发布与订阅功能和锁服务在分布式一致性特性上是相通的。   ③ 开发人员对基于锁的接口更为熟悉