今天我们回归技术路线，讲讲Google三驾马车里的BigTable。以前有个说法叫做麻子不叫麻子，叫坑人。取其原意是满脸是坑的人，谐音表示人被坑了。我们知道水浒里面有李鬼装李逵然后遇到真李逵的段子。BigTable这篇论文非常的难懂，很大程度上是因为它选择了一些名为李逵实为李鬼的名字来装饰自己，从而使得通俗易懂的数据模型变得奇葩起来。 Google三架马车里面，唯独BigTable写得高深难懂，很多时候其实是你首先要理解BigTable里面的一些名字的基本概念。因为BigTable借用了很多的关系数据库的
如标题所言，这一篇文章简单介绍BigTable，其实个人更建议看LevelDB这款开源数据库，因为这数据库也是Bigtable的作者 JeffreyDean 设计的，很多内容不能说像简直就是一模一样。
有关系行数据库经验的人（比如我），在最初接触HBase这样的数据库时，对数据结构的理解容易遇到障碍。会不自觉的将HBase的行、列等概念映射成关系型数据库的行、列。为了加速理解HBase的一些概念，翻译了这篇文章《Understanding HBase and BigTable》（HBase官方文档推荐阅读文章）。
今天扯一下 Hbase ，我对 Hbase 的了解起源于两篇文章Understanding HBase and BigTable和《李逵麻子，李鬼坑人--BigTable的数据模型》；这两篇本质上还是一篇文章，《李逵麻子，李鬼坑人--BigTable的数据模型》类似于Understanding HBase and BigTable的中文版讲解。还好的是我是先读的这两篇文章，再去看 Hbase 的官方文档和使用 Hbase ，否则真有可能被 Hbase 的概念给糊弄进去了。要知道，对一个软件或者工具，要想深刻理解和使用它，第一印象很重要，它决定你学习的进度，要是弄错了，学习的时候就会很痛苦，怎么也无法理解这个工具怎么设计的。
关于昨天 Spanner 的文字，有人问 NewSQL 为什么会起名为 New，Spanner 的应用场景又是怎样的？那么这篇就顺着大数据的历史继续聊。
Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，
HBase是Apache Hadoop的数据库，能够对大型数据提供随机、实时的读写访问。HBase的目标是存储并处理大型的数据。HBase是一个开源的，分布式的，多版本的，面向列的存储模型，它存储的是松散型数据。
现在我们站在各个用例的角度上来考虑那种系统适合于这些用例。 你的意见是首先，我们要纵览各种数据模型。这些模型的分类方法来自于Emil Eifrem 和 NoSQL databases。 文档数据库 源起：受Lotus Notes启发。 数据模型：包含了key-value的文档集合 例子：CouchDB, MongoDB 优点：数据模型自然，编程友好，快速开发，web友好，CRUD。 图数据库 源起： 欧拉和图理论。 数据模型：节点和关系，也可处理键值对。 例子：AllegroGraph, InfoG
列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区。当列很多或者
在学习HBase（Google BigTable 的开源实现）的时候，我们面临的最为困难的地方就是需要你重构你的思路来理解 BigTable 的概念。
Bigtable是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：通常是分布在数千台普通服务器上的PB级的数据。Google的很多项目使用Bigtable存储数据，包括Web索引、Google Earth、Google Finance。这些应用对Bigtable提出的要求差异非常大，无论是在数据量上（从URL到网页到卫星图像）还是在响应速度上（从后端的批量处理到实时数据服务）。尽管应用需求差异很大，但是，针对Google的这些产品，Bigtable还是成功的提供了一个灵活的、高性能的解决方案。本论文描述了Bigtable提供的简单的数据模型，利用这个模型，用户可以动态的控制数据的分布和格式；我们还将描述Bigtable的设计和实现。
所谓海量，就是数据量很大，可能是TB级别甚至是PB级别，导致无法一次性载入内存或者无法在较短时间内处理完成。面对海量数据，我们想到的最简单方法即是分治法，即分开处理，大而化小，小而治之。我们也可以想到集群分布式处理。
Apache HBase 是以 hdfs 为数据存储的，一种分布式、可扩展的 NoSQL 数据库。
业界比较认可的几个分类：SAAS、PAAS、IAAS 1、SAAS（软件即服务） 就是提供一种软件池，池中包括这样那样的内容，就像水电一样可以自由取送，然后按量收费，这是saas的一个宗旨。 saas具有的几个特点： 1）按需使用，客户根据自身的需求来决定使用多少服务以及服务的时间长短。 现在很多公司都提出了这种模式，以租用的方式来销售软件，云邮件，云呼叫等，客户不必关心最终的服务是由什么开发，无论是java，.net，php，只需知道交纳费用就可以享受相应的服务，这就是saas的一个最大的特点。 2）能够
作为一个在虐狗节还奋笔疾书的公众号写手来说，最重要的是各位汪们不是汪的读者们的打赏。这篇文章就看大家怎么想啦。 今天不但是虐狗节还是世界癫痫日，还有，更大的新闻是Google宣布Spanner作为一个公有云的服务正式开始提供了。所谓几家欢喜几家愁，这永远都是真理。 我想Spanner大名鼎鼎，大家都知道，但是作为服务了狗狗家10余年的MegaStore，因为其出身不够正统，听说过的人就很有限了吧。很多时候我一直在想，到底是个人成就了公司还是公司成就了个人。每次看到Jeff Dean我就会觉得我和他比智商不
说到大数据技术不得不提起Hadoop，今天加米谷大数据就来简单介绍一下Hadoop的简史。
当您需要对大数据进行随机、实时的读写访问时，请使用Apache HBase™。这个项目的目标是在商用硬件集群上托管非常大的表——数十亿行X数百万列。Apache HBase是一个开源的、分布式的、版本化的、非关系型的数据库，它模仿了Chang等人的谷歌的Bigtable: A distributed Storage System for Structured Data。正如Bigtable利用了谷歌文件系统提供的分布式数据存储，Apache HBase在Hadoop和HDFS上提供了类似Bigtable的功能。
Bigtable 是一个用来管理结构化数据的分布式存储系统，具有很好的伸缩性，能够在几千台应用服务器上处理PB数量级数据。谷歌有许多项目都把数据存储在Bigtable中，包括web indexing,Google Earth, and Google Finance. 这些应用对Bigtable的侧重点不同，但是他们都是海量数据和实时性的应用。尽管需求变化多端，Bigtable很好的提供了一个灵活多变，高性能额解决方案。
Bigtable被称为谷歌的三驾马车之一，主要面向谷歌的结构化数据存储,其思想被许多nosql数据库继承。Bigtable建立于GFS和Chubby之上，而为MapReduce服务,可以说是承上启下。
云计算原理与应用 云计算服务包括：google文件系统GFS，分布式计算编程模形MapReduce，分布式锁服务Chubby，分布式结构化数据表Bigtable，分布式存储系统Megastore以及分布式监控系统Dapper等。 GFS提供了海量数据的存储和访问能力。 GFS 系统架构： 分为三类角色，client(客户端),Master(主服务器)和Chunk Server(数据块服务器) 1，使用的是中心服务器模块，可以任意添加chunk server. 2，不实现缓存，这是从必要性和可行性两方面考虑。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
今天给大家带来的是大数据开发-HBase关系对比，相信大家也都发现了，有很多框架的用处都差不多，为什么只用这个而不用那个呢？这就是两者之间的一些不同之处的对比，然后选择一个最适用的，本期就是关系对比，为什么它最适用！
HBase是一种非关系型的，分布式的，海量存储数据库。可用于大数据分析，如日志分析。来看看官网解释：
HBase的原型是Google的BigTable论文，受到了该论文思想的启发，目前作为Hadoop的子项目来开发维护，用于支持结构化的数据存储。 官方网站：http://hbase.apache.org – 2006年Google发表BigTable白皮书 – 2006年开始开发HBase – 2008年北京成功开奥运会，程序员默默地将HBase弄成了Hadoop的子项目 – 2010年HBase成为Apache顶级项目 – 现在很多公司二次开发出了很多发行版本，你也开始使用了。 HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群。 HBase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。 HBase是Google Bigtable的开源实现，但是也有很多不同之处。比如：Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。
1 hadoop中各工程包依赖简述 Google的核心竞争技术是它的计算平台。Google的大牛们用了下面5篇文章，介绍了它们的计算设施。 GoogleCluster： http://research.google.com/archive/googlecluster.html Chubby：http://labs.google.com/papers/chubby.html GFS：http://labs.google.com/papers/gfs.html B
在互联网和大数据的背景下，越来越多的网站、应用系统需要支撑海量数据存储、高并发请求、高可用、高可扩展性等特性要求。传统的关系型数据库 RDBMS 已经难以应对类似的需求，各种各样的 NoSQL（Not Only SQL）数据库凭借易扩展、大数据量和高性能以及灵活的数据模型成功的在数据库领域站稳了脚跟。本文将分析传统数据库的存在的问题，以及几类 NoSQL 如何解决这些问题。在不同的业务场景下，作出正确的数据存储技术选型。
在2010年4月，Google的网页索引更新实现了实时更新，在今年的OSDI大会上，Google首次公布了有关这一技术的论文。
大数据技术的发展是一个非常典型的技术工程的发展过程，荣辛通过对于谷歌经典论文的盘点，希望可以帮助工程师们看到技术的探索、选择过程，以及最终历史告诉我们什么是正确的选择。
从 Google 的 BigTable 开始，一系列可以进行海量数据存储与访问的数据库被设计出来，NoSQL 这一概念被提了出来。
Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
一 Hbase是个啥东东？ 在说Hase是个啥家伙之前，首先我们来看看两个概念。面向行存储和面向列存储。面向行存储。我相信大伙儿应该都清楚，我们熟悉的RDBMS就是此种类型的。面向行存储的数据库主要适合于事务性要求严格场合，或者说面向行存储的存储系统适合OLTP。可是依据CAP理论，传统的RDBMS。为了实现强一致性，通过严格的ACID事务来进行同步，这就造成了系统的可用性和伸缩性方面大大折扣。而眼下的非常多NoSQL产品，包含Hbase，它们都是一种终于一致性的系统，它们为了高的可用性牺牲了一部分的一致性。好像。我上面说了面向列存储，那么究竟什么是面向列存储呢？Hbase,Casandra,Bigtable都属于面向列存储的分布式存储系统。 看到这里，假设您不明确Hbase是个啥东东，不要紧，我再总结一下下： Hbase是一个面向列存储的分布式存储系统。它的长处在于能够实现高性能的并发读写操作，同一时候Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。 二 Hbase数据模型 HBase,Cassandra的数据模型很类似。他们的思想都是来源于Google的Bigtable，因此这三者的数据模型很类似，唯一不同的就是Cassandra具有Super cloumn family的概念，而Hbase眼下我没发现。好了。废话少说。我们来看看Hbase的数据模型究竟是个啥东东。 在Hbase里面有以下两个基本的概念，Row key,Column Family。我们首先来看看Column family,Column family中文又名“列族”，Column family是在系统启动之前预先定义好的，每个Column Family都能够依据“限定符”有多个column.以下我们来举个样例就会很的清晰了。 假如系统中有一个User表。假设依照传统的RDBMS的话。User表中的列是固定的，比方schema 定义了name,age,sex等属性。User的属性是不能动态添加的。可是假设採用列存储系统。比方Hbase。那么我们能够定义User表，然后定义info 列族。User的数据能够分为：info:name = zhangsan,info:age=30,info:sex=male等。假设后来你又想添加另外的属性。这样非常方便仅仅须要info:newProperty就能够了。 或许前面的这个样例还不够清晰，我们再举个样例来解释一下。熟悉SNS的朋友，应该都知道有好友Feed，一般设计Feed，我们都是依照“某人在某时做了标题为某某的事情”，可是同一时候一般我们也会预留一下keyword，比方有时候feed或许须要url，feed须要image属性等，这样来说。feed本身的属性是不确定的。因此假设採用传统的关系数据库将很麻烦。况且关系数据库会造成一些为null的单元浪费，而列存储就不会出现这个问题。在Hbase里，假设每个column 单元没有值，那么是占用空间的。
美国时间 2018年4月19日，苹果公司宣布开源FoundationDB。FoundationDB 本来是一个开源项目，于2015年被苹果收购以后，其代码从GitHub上删除进入闭源代状态，直到苹果宣布重新开源。
接着说谷歌，上篇文章提到了 GFS 。那么谷歌为什么要硬着头皮去啃分布式系统这块硬骨头呢？首先，我们要知道谷歌刚开始成立时是一家搜索公司，方便用户查询互联网上的信息。因此谷歌必须要存储整个互联网上的信息，那这个数据量是庞大的。对于这个需求，传统的数据库或者更深入地说，单机是远远不够的，必须要使用分布式系统搭建集群；但是那个时候要搭建集群，可供选择的方案大多像 Oracle 的 RAC 一样，需要昂贵的机器。因此谷歌必须要自行去解决这个问题：
从新闻 Twitter用户暴增20倍 计划弃用MySQL中看到了Cassandra数据库，网上查了一下这个Cassandra的资料，找到一篇较详细的中文资料： Cassandra数据模型 下面一段引自这篇文章： 各种NoSQL数据库有很多，我最关注的还是BigTable类型，因为它是一个高可用可扩展的分布式计算平台，用来处理海量的结构化数据，而数据库同样也是处理结构化数据，所以除了没有SQL，在数据模型方面有相似之处。Cassandra是facebook开源出来的一个版本，可以认为是BigTable的一个开
作者 | Steef-Jan Wiggers 译者 | 明知山 策划 | 丁晓昀 最近，谷歌宣布 Bigtable 联邦查询普遍可用，用户通过 BigQuery 可以更快地查询 Bigtable 中的数据。此外，查询无需移动或复制所有谷歌云区域中的数据，增加了联邦查询并发性限制，从而缩小了运营数据和分析数据之间长期存在的差距。 BigQuery 是谷歌云的无服务器、多云数据仓库，通过将不同来源的数据汇集在一起来简化数据分析。Cloud Bigtable 是谷歌云的全托管 NoSQL 数据库，主要用
基于HDFS: HDFS:hadoop distributed file system:分布式文件系统：多台服务器组成的服务器集群组成的一个文件系统。
将key相对分散，并且数据量小的表放在join的左边，这样可以有效减少内存溢出错误发生的几率；再进一步，可以使用map join让小的维度表（1000条以下的记录条数）先进内存。在map端完成reduce。 实际测试发现：新版的hive已经对小表JOIN大表和大表JOIN小表进行了优化。小表放在左边和右边已经没有明显区别。
Updating an index of the web as documents are crawled requires continuously transforming a large repository of existing documents as new documents arrive. This task is one example of a class of data processing tasks that transform a large repository of data via small, independent mutations. These tasks lie in a gap between the capabilities of existing infrastructure. Databases do not meet the storage or throughput requirements of these tasks: Google’s indexing system stores tens of petabytes of data and processes billions of updates per day on thousands of machines. MapReduce and other batch-processing systems cannot process small updates individually as they rely on creating large batches for efficiency.
我们在刚开始学习hive的时候,都知道hive可以降低程序员的学习成本和开发成本,具体表现就在于可以将SQL语句转换成MapReduce程序运行。
Spanner是Bigtable的魔改版，下面这张谷歌云的PPT几乎和intro一一对应。
GFS 作为其中一驾宝车，解决了大数据存储的难题。它能够把大量廉价的普通机器，聚在一起，充分让每台廉价的机器发挥光和热。其中在《从谷歌 GFS 架构设计聊开去》中我们针对 GFS 进行了管中窥豹，体会到其中一斑，不得不说是人多力量大，团结就是力量的体现。
随着计算机的飞速发展，网站产生了大量数据，数据规模远超传统数据库系统能够处理的规模，我们把具有量大，存储速度要求高，数据多样性丰富的特征的数据统称为大数据。
海量数据的威力 人们在形容一个事物非常大或者非常多的时候，往往喜欢用“海量”这个词，比如说某某某的酒量很大就称其为海量，所以在形容数据量非常大的时候，就有了“海量数据”一词，海量数据所表现出来的“大”绝对不是一般意义上的大，而是像大海一样趋于无限的“大”，是一种“大”到可怕的大，之所以会形成海量数据的主要原因在于现代社会人类快节奏的生活方式和信息互联网技术的高速发展，每天都会产生大量非结构化和半结构化的数据，这些数据中蕴含了许多潜在的商业价值和客观规律，所以只有进行了充分的分析和挖掘才能将有效的和有价值的信
最适合使用Hbase存储的数据是非常稀疏的数据（非结构化或者半结构化的数据）。Hbase之所以擅长存储这类数据，是因为Hbase是column-oriented列导向的存储机制，而我们熟知的RDBMS都是row- oriented行导向的存储机制（郁闷的是我看过N本关于关系数据库的介绍从来没有提到过row- oriented行导向存储这个概念）。在列导向的存储机制下对于Null值得存储是不占用任何空间的。比如，如果某个表 UserTable有10列，但在存储时只有一列有数据，那么其他空值的9列是不占用存储空间的（普通的数据库MySql是如何占用存储空间的呢？）。 Hbase适合存储非结构化的稀疏数据的另一原因是他对列集合 column families 处理机制。 打个比方，ruby和python这样的动态语言和c++、java类的编译语言有什么不同？ 对于我来说，最显然的不同就是你不需要为变量预先指定一个类型。Ok ，现在Hbase为未来的DBA也带来了这个激动人心的特性，你只需要告诉你的数据存储到Hbase的那个column families 就可以了，不需要指定它的具体类型：char,varchar,int,tinyint,text等等。 Hbase还有很多特性，比如不支持join查询，但你存储时可以用：parent-child tuple 的方式来变相解决。 由于它是Google BigTable的 Java 实现，你可以参考一下：google bigtable 。 下面3副图是Hbase的架构、数据模型和一个表格例子，你也可以从：Hadoop summit 上 获取更多的信息。
我们在工作中还是在学习中有都会遇到我们写的HQL语句执行效率不高，那我们该怎么提高查询效率那，这篇文章就带你从不同维度讲解,让你的HQL瞬间提高一个档次。记得收藏
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
