HBase是一种面向列的数据库，它常常会被拿来和传统的关系型数据库（RDBMS）进行比较。两者在实现和设计上的出发点差别很大，下面小鸟就客观的讲一讲两者的区别。

一、存储的量级

在传统的关系型数据库中，随着数据量的增大，查询速度会越来越慢，一张有上百个字段的数据表在有千万级别的数据量时，响应速度会变的非常缓慢。

而HBase是一个分布式的数据存储系统，他的建立是基于HDFS的。其设计的初衷就是为了解决传统关系型数据库在处理海量数据时，速度太慢的问题。

二、数据的灵活度

HBase是面向列存储的，其存储结构是一种key-value的方式，因此在数据有新的字段需求的时候可以随意增加。

而传统关系型数据库则只能通过关联表的方式，通过增加外键和索引来处理新的字段，因此极为不便。

三、响应的速度

传统关系型数据库读写数据是需要考虑主键、外键和索引等因素的，随着数据的剧增其响应速度也是梯度下降的。

而Hbase则不会有这样的问题，其写数据的性能和表的大小无关，并且由于其key-value的存储格式等原因，其读数据的速度也几乎不会下降。

四、良好的扩容

HBase的扩容只需要在集群上简单的增加节点。其新增节点的代价很小，HBase中增加一个节点服务器只需要3万不到，并且由于节点很多，某个节点宕机并不会对整个集群造成巨大影响。

而传统关系型数据库只能通过升级硬件来升级服务，单台高性能的服务器价格是非常昂贵的。

五、索引的支持

传统关系型数据库则会随着数据量的增加，出现索引膨胀的问题。

HBase是不支持索引的，在降低了查询便利度的同时增加了响应性能。

六、自动分区

HBase中的数据表会自动分裂，存入合适的RegionServer上。

传统关系型数据库则需要手动操作来实现分区。

如果传统型数据库已经成为了公司隐患的话，那么就应该好好考虑是否需要转型HBase了。并且这也意味着公司的规模越来越大了，毕竟只有海量的数据才需要使用到HBase，在数据量不大的时候，传统关系型数据库还是一个优先级更高的选择。

与其说HBase和传统关系型数据库各有优势，不如说HBase是大数据发展的必然产物，毕竟谁也不愿意忍受糟糕的延迟。

希望这篇文章能帮助到各位小伙伴们，关注小鸟，每天都有新的知识点！

489034603

由于大数据的迅猛发展，数据正在呈指数级增长，各种传感器的剧增，高清晰度的图像和视频都是数据爆炸的原因。腾讯、淘宝掌握了大量的用户数据，力图描绘出用户的整体“画像”。面对大数据的汹涌来袭，传统的数据存储和数据库技术已经难以应对，那么，大数据技术如何存储海量数据并提高系统容错性？目前，较为主流的海量文件存储技术有Google的GFS和Hadoop的HDFS，HDFS是GFS的开源实现。它们均采用分布式存储的方式存储数据，用冗余存储的模式保证数据的可靠性。

下面我们通过几个问题，来让大家更好的了解数据存储应该如何解决？

1、大数据的处理流程包括了哪些环节？每个环节有哪些主要工具？

数据采集： 半结构日志文件可使用flume； 结构化数据可以使用传统的E TL工具如，datastage、kettle 等等

数据存储：hadoop hdfs存储海量数据；也可用传统的oracle、sysbase iq等数据仓库解决方案

数据统计： 使用hive、impala对hadoop进行统计分析；

数据挖掘：可使用mahout进行数据挖掘

2、大数据的数据库相比于传统数据库有何变化？出现了哪些新的大数据的数据管理方式？

量大、结构多样、速度要求高等特点； 出现了以hadoop为代表的分布式存储和nosql等数据存储管理方案

3、大数据工程师应该都知道，现在处理大数据文件的存储，比较典型的有Google的Big Table和Hadoop的HBase，它们有哪些相似点和不同点？

Hadoop的HBase是Google的Big 的开源实现，每个人都可以下载来使用，也可以根据自己需要进行修改和完善

以上都为个人观点，谨供大家参考一下，如果感觉写的可以，即可给自己一个比较准确的定位，为以后的学习找准正确的方向。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

数据库测试： 之前写的数据库测试代码稍微有点繁杂，现在我们将这些代码进行简化一下，将备份、还原数据的方法单独写在一个类里，然后测试类继承于这个类。

代码示例：

测试类代码示例：

测试类的代码稍微更改了一下，让测试的覆盖率提高

测试结果：

测量测试覆盖率：

测量测试覆盖率就是测量测试代码运行了多少个测试分支，如果测试代码的全部分支都被运行了，那么测试覆盖率就是100%。

打个比方就是一个猎人挖了100个不同的陷阱，猎人需要一个个的去触碰这些陷阱以确保陷阱没有问【学Java，到凯哥学堂kaige123】题能够捕捉到猎物，这个阶段就是测试环节。而最终猎人总共触碰了多少个陷阱，这就是测试覆盖率，猎人把所有的陷阱都触碰过了并且陷阱都没有问题的话，那么测试覆盖率就是100。如果猎人只触碰了80个陷阱，那么测试覆盖率就是80%。

如何进行测量测试覆盖呢？我们需要用到一个插件叫做cobertura，这个插件能够很好的帮助我们测量测试覆盖率，这个插件需要插入Maven的生命周期中，在执行Maven测试的时候能够运行这个插件。测试成功后这个插件会生成html文件，从这些文件中可以查看代码的测试覆盖率。 配置语法：

执行Maven测试，正在下载插件：

测试成功：

生成的html文件在这里：

右键使用web方式打开：

点击All，在这里可以查看类和包的测试覆盖率：

虽然这是个很不错的插件，但是使用的人不多，如果遇上需要测量测试覆盖率的业务，这个插件能帮很大忙。

代码习惯：

一般大部分情况下，进行项目的开发，都是先从功能实现的角度进行构思，先分析业务需求、绘制项目模型，然后一步步得编写实现代码，在最后项目代码开发完成后再进行相应的测试，这是普遍的项目开发习惯。

在此外还有一种开发方式是：先分析这个项目可能会出现的错误、bug，从而有针对性的去编写测试用例，然后再根据测试用例去编写实现代码，这种方式用得好的话可以事先避免很多代码可能出现的错误，有点逆向思维的味道。

除了以上两种方式之外，还有一种合作式的开发方式：一个人单独编写测试用例，分析实现代码可能出现的错误，另一个人同时分析项目业务需求和功能实现，然后再根据写好的测试用【学Java，到凯哥学堂kaige123】例编写实现代码。这种方式使用得当开发效率会比前两个方法要高，这种方式有点像是前两个方法的结合体。

测试总结：

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化。为了获得稳定的执行性能，SQL语句越简单越好。对复杂的SQL语句，要设法对之进行简化提高它的解决效率。

489034603

当看到一个SQL语句带来了性能问题的时候，首先要看看它的执行计划。看看他是否走了你所期望的索引。物理读逻辑读是不是在合理的范围之内？对于这类的性能问题，可以追溯到表的设计阶段，例如，为 了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余，然而，为了提高系统的响应时间，合理的数据冗余也是必要的。设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。下面我们来谈谈优化的技巧：

【1】表设计的优化

1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。

2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的。

3、对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。

4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。

5、字段顺序对存储效率也有不小的影响。在做表结构设计的时候，我们往往不会去考虑字段的摆放顺序。但是，实际上字段的摆放顺序对数据库操作的性能是有影响的。

6、针对各种类型的表来存储各种类型的数据

【2】 语句的查询优化

1、保证在实现功能的基础上，尽量减少对数据库的访问次数；

2、通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；

3、在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；

4、在查询时，不要过多地使用通配符如SELECT * FROM T1语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；

5、在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。

6、在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。

7、在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。

8、合理的使用临时表。例如表A 的 ID 字段有索引，并且这个表的数据有很多。这时候要查询这个ID 的最大值与最小值，如果能合理使用临时表，速度将大幅度提高！

9、多层的子查询需要进行简单化。

【3】建立高效的索引

创建索引一般有以下两个目的：维护被索引列的唯一性和提供快速访问表中数据的策略。大型数据库有两种索引即簇索引和非簇索引，一个没有簇索引的表是按堆结构存储数据，所有的数据均添加在表的尾部，而建立了簇索引的表，其数据在物理上会按照簇索引键的顺序存储，一个表只允许有一个簇索引，因此，根据B树结构，可以理解添加任何一种索引均能提高按索引列查询的速度，但会降低插入、更新、删除操作的性能，尤其是当填充因子（Fill Factor）较大时。所以对索引较多的表进行频繁的插入、更新、删除操作，建表和索引时因设置较小的填充因子，以便在各数据页中留下较多的自由空间，减少页分割及重新组织的工作。据说大部分的数据库性能问题都可以采用索引技术得到解决。

【4】 强制查询转换

有时候oracle 的优化器未必能走正确的查询路线，这个时候就需要添加一些hint 之类的来规定他的执行路线。当然了，这个未必是最好的处理方案。因为虽然现在走这个路线是对的，以为因为数据的变化到这这个HINT 变得不可取！

【经验之谈】

在日常我们开发的系统中有很多的SQL 语句被写成N层嵌套，我们应该在了解了业务之后，将复杂的SQL 改成多个简单的语句逐步处理，再或者用with as 语法，这个可以解决不少的性能的问题。再者，很多朋友不会使用分析函数，认为它会带来一定的性能问题，其实这是错的。使用分析函数的查询，不但语法简洁，查询效率来看比自己拼得多层查询的效率要好很多。

以上为个人观点，供大家参考，因为每个公司的业务逻辑不同，所采用的方法也不尽相同，我们只能做的让它变的更好，在大数据领域没有最好。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

　　一个TB的规模是巨大的。我们很难从这个角度来看待这个问题，所以让我们试着从空间和时间两个角度来理解它。　　一英里不长，一立方英里相对于整个地球来说并不算大。 所以，如果听说全世界的人口都能容纳一立方英里的空间，你可能会感到惊讶。 荷兰裔美国作家亨德里克·威廉·范·龙（Hendrik Willem van Loon）曾在他的一本书中写过这篇文章。　　Teradata是一个著名的数据库仓储产品供应商。在处理大量数据时，品牌名称的设计令人印象深刻。那是20年前的事了。今天，用户以及供应商正在谈论数据量为TB的数据。 通常有数十甚至将近100TB的数据量，甚至是PB级的数据量都是很常见的，因此，一个TB的数据变得不寻常，而且有几个或几十个TB级的数据看起来一点都不吓人。　　实际上，一个TB和一个立方英里的规模是巨大的。 我们很难从这个角度来看待这个问题，所以让我们从两个角度去理解它。

　　首先，我们来看空间。　　大部分的数据分析和计算是在结构化数据上进行的，其中不断增加的事务数据占用最大的空间。 每笔交易数据的大小不大， 它可以从几十个字节到大约100个字节。 例如，银行交易信息将包括账户，日期和金额； 而电信的通话记录将包括电话号码，时间和持续时间。 假设每个记录占用100个字节，或者0.1KB，一个TB容量可以容纳10G行，或者100亿个记录。　　这个是什么意思？一年有超过3000万秒，一年累积1 TB数据需要在时钟上每秒生成超过300条记录。　　这不是一个荒谬的巨大规模。 在美国这样的大国，像国家电信运营商，国家银行和互联网巨头这样的企业很容易达到这个规模。 但是，对于全市乃至全州的一些机构来说，获得1TB的数据是非常困难的。 地方税务局收集的税务信息，本地连锁店的购买数据或城市商业银行的交易数据每秒都可以成倍增长。此外，许多组织的数据只在工作日或工作日生成。有几十个甚至100百万兆字节数据，业务量应该是一个或两个数量级更大的。　　一个TB的数据可能太抽象了，我们无法理解它。 但通过将其翻译成业务量，我们可以得到一个更清晰的想法。 数据量和大数据分析和计算产品所采用的技术之间有着密切的联系，因此组织对其数据量进行精确的评估对于构建大数据平台至关重要。　　如果音频和视频数据等非结构化数据被卡住，或者用于备份原始数据，则一兆兆字节的空间会变得很小。 但通常我们只执行存储管理任务或者搜索这些数据。 由于不需要进行直接的分析和计算，大数据平台是不必要的。 网络文件系统足以执行这些操作，这可以大大降低成本。

　　我们要看的第二种方法是基于时间的。　　处理1TB数据需要多长时间？一些厂商声称他们的产品可以在几秒钟内处理它。这是用户所期望的。但是有可能吗？　　在操作系统下从硬盘检索数据的速度约为每秒150MB（硬盘制造商提供的技术参数不能完全实现）。 SSD的数据检索速度更快，每秒钟的加倍速度为300MB。 检索1TB数据需要花费将近一个小时的时间，而不需要执行任何其他操作。 1TB的数据如何在数秒内处理？ 这只需要添加更多的硬盘即可完成。 使用1000个硬盘，可以在3秒钟内检索1TB的数据。　　这是一个理想的估计。在大多数情况下，在现实中，数据并没有被整齐地存储--当从硬盘中检索到不连续的数据时，性能就会变得很糟糕。对于集群，显然，1000个硬盘不能安装在一台机器上--这是网络延迟。有些计算可能需要重写操作(分组使用大型结果集和排序操作)。而且，几秒钟内的数据访问常常伴随着并发请求。考虑到所有这些因素，数据检索可能会慢几倍也就不足为奇了。　　现在我们意识到，TB级的数据意味着需要数小时的数据检索，或者1000个硬盘。你可以想象几十兆或100兆兆字节的数据会带来什么。　　您可能会认为，由于硬盘太慢，所以我们应该使用内存来代替。　　实际上，内存比硬盘快得多，适合执行并行处理。但是拥有大内存的机器也很贵(成本不会线性增加)。更糟的是，通常内存使用率较低。对于通常使用的基于java的计算平台来说，如果没有使用数据压缩技术，JVM的内存使用率只有20%左右。这意味着从硬盘上装载1TB的数据需要5TB的内存。那将会太贵，因为需要很多机器。　　有了关于1TB数据的一些知识，我们可以在遇到多TB数据时，对交易类型，节点数量和部署成本有一个快速和相当好的想法，并且能够在规划计算平台或选择产品时做出明智的决定。 即使在今天，“teradata”这个词仍然具有生动的意义。

　　更多阅读

　　课课家 Word2016 论文排版精讲教程-毕业必学篇

　　课课家2018软考之密码学基础与应用课程

　　双十二又双叒叕来袭！

俺黑君够黑，慎关注！

究竟什么是大数据？如何对大数据进行定义？大数据有哪些特征？了解了这些才能更好的知道自己学习是怎样的一门技术，以及它的前景如何。本文达妹就带大家一起了解大数据。

DT时代，人人言必称大数据，所有的新系统几乎都是基于大数据，有人认为用了MongoDB就是大数据，也有人用了Hadoop就是大数据，或者认为数据量大就是大数据。

更有甚者，笔者看到一篇新闻报道，说某企业成功实施大数据项目，结果只是SQL-Server集群……天呐，这可是上世纪的技术了！

说了这么多到底什么是大数据呢，其实大数据并没有教科书式的明确定义，但是却有比较公认的特性描述，符合这些特性的就可以称作大数据，即大数据的4个V。

第一个V——高容量

这个最好理解，数据量一定要大，才好意思称自己为大数据嘛。大到什么程度呢？依目前行情来看，至少也要到TB级，很多案例都是PB甚至更高。但如果是GB级，非说自己是大数据也不是不可以，就是有点无颜见江东父老啊……

第二个V——多样化

这个很关键了！是区别于以往海量数据挖掘的最主要特征。它有两层含义，一是数据来源多样化，系统数据、设备日志、传感器、文件系统等等来源。二是数据结构多样化，这是核心特征！要包含结构化数据、非结构数据（包括所谓半结构化数据）。

总结起来就是，多源异构。这就是为什么有人认为使用NoSQL数据库（如MongoDB）就是大数据了，因为满足了多样化的特征，但其实还不够。

第三个V——高速

即时效性，基本上至少也要达到亿级数据一秒查询，做的比较好的可以达到千亿级数据一秒查询。这个特征几乎决定了传统技术架构无法满足要求，因此Hadoop架构的出现催化了大数据的发展，也是有人认为Hadoop就是大数据的原因。

第四个V——价值

这个很好理解，数据一定要有价值、而后才能产生价值。就好比存商品的叫才能仓库，存垃圾的叫垃圾填满坑一样。没价值的数据就像一个垃圾填满坑，这也是为什么数据治理在大数据实施中非常重要的原因之一。

最后，也是最重要的，以上4个V是逻辑与的关系，即需同时、注意是同时满足上述四个特征，就可以放心的说自己是大数据了！

文版权归原作者所有。转载文章仅为传播更多信息之目的，如有侵权请与我们联系，我们将及时处理。

1.获取指定数据库的表的数量

SELECT COUNT(*) TABLES, table_schema FROM information_schema.TABLES GROUP BY table_schema;

2.获取mysql下所有数据库表的数量

SELECT COUNT(*) TABLES, table_schema FROM information_schema.TABLES

WHERE table_schema = '数据库名' GROUP BY table_schema;

盖娅广告匹配系统（GaeaAD）用于支撑盖娅互娱全平台实时广告投放系统，需要将广告数据和游戏 SDK 上报的信息进行近实时匹配，本质上来说需要实时的根据各个渠道的广告投放与相应渠道带来的游戏玩家数据进行计算，实现广告转化效果分钟级别的展现及优化。

初期的 MySQL 存储方案

在系统设计之初，基于对数据量的预估以及简化实现方案考虑，我们选用了高可用的 MySQL RDS 存储方案，当时的匹配逻辑主要通过 SQL 语句来实现，包含了很多联表查询和聚合操作。当数据量在千万级别左右，系统运行良好，基本响应还在一分钟内。

MySQL RDS 存储方案架构图

遭遇瓶颈，寻找解决方案

然而随着业务的发展，越来越多游戏的接入，盖娅广告系统系统接收数据很快突破千万/日，高峰期每次参与匹配的数据量更是需要翻几个番，数据库成为了业务的瓶颈。由于此时，整个技术架构出现了一些问题：

1.单次匹配耗时已从原本的 10 秒左右增加到 2 分钟以上，最慢的聚合查询甚至达到 20 分钟，时效性受到严重挑战。而且 MySQL 的问题是查询的时间随着数据量的增长而增长，以至于数据量越大的情况下查询越慢。

2.随着历史数据的积累，单表数据很快达到亿级别，此时单表的读写压力已经接近极限。

3.由于第一点提到的查询性能问题以及单机的容量限制，需要定时删除数据，对于一些时间跨度较长的业务查询需求没法满足。

根据数据量的增长情况来看，分布式数据库会是很好的解决方案。首先考虑的是业务的垂直及水平拆分或者基于 MySQL 的数据库中间件方案和一些主流的 NoSQL 方案。

但是仔细评估后，最先排除掉的是业务水平拆分的方案，因为业务逻辑中包含大量的关联查询和子查询，如果拆表后这些查询逻辑就没有办法透明的兼容，而且是比较核心的业务系统，时间精力的关系也不允许整体做大的重构。中间件的问题和分库分表的问题类似，虽然解决了大容量存储和实时写入的问题，但是查询的灵活度受限，而且多个 MySQL 实例的维护成本也需要考虑。

第二个方案就是采用 NoSQL，因为此系统需要接收业务端并发的实时写入和实时查询，所以使用类似 Greenplum，Hive 或者 SparkSQL 这样的系统不太合适，因为这几个系统并不是针对实时写入设计的， MongoDB 的问题是文档型的查询访问接口对业务的修改太大，而且 MongoDB 是否能满足在这么大数据量下高效的聚合分析可能是一个问题。

所以很明显，我们当时的诉求就是能有一款数据库既能像 MySQL 一样便于使用，最好能让业务几乎不用做任何修改，又能满足分布式的存储需求，还要保证很高的复杂查询性能。

当时调研了一下社区的分布式数据库解决方案，找到了 TiDB 这个项目，因为协议层兼容 MySQL，而且对于复杂查询的支持不错，业务代码完全不用修改直接就能使用，使迁移使用成本降到极低。

技术转身，使用 TiDB

在部署测试的过程中，我们使用 TiDB 提供的 Syncer 工具将 TiDB 作为 MySQL Slave 接在原业务的 MySQL 主库后边观察，确保读写的兼容性以及稳定性，经过一段时间观察后，确认读写没有任何问题，业务层的读请求切换至 TiDB，随后把写的流量也切换至 TiDB 集群，完成平滑的上线。

GaeaAD 系统从 2016 年 10 月上线以来，已经稳定运行了一季度多，结合实际的使用体验，我们总结了 TiDB 带来的收益，主要有以下几点：

TiDB 架构图

1.用3 个节点组成的 TiDB 集群替换了原先的高可用 MySQL RDS 后，同样数据量级下，单次匹配平均耗时从 2 分钟以上降到了 30 秒左右，后续随着 TiDB 工程师的持续优化，达到了10 秒左右。另外，我们发现，TiDB 在数据规模越大的情况下，对比 MySQL 的优势就越明显，应该是 TiDB 自研的分布式 SQL 优化器带来的优势。不过在数据量比较轻量的情况下，因内部通信成本，优势相比 MySQL 并不明显。

TiDB 与 MySQL 在不同数据量下的查询时间对比

2.TiDB 支持自动 Sharding，业务端不用切表操作，TiDB 也不需要像传统的数据库中间件产品设定 Sharding key 或者分区表什么的，底层的存储会自动根据数据的分布，均匀的分散在集群中，存储空间和性能可以通过增加机器实现快速的水平扩展，极大地降低了运维成本。

3.TiDB 支持在线不中断的滚动升级，至今直接在线升级已有 10 余次左右，没出现过一起导致线上服务中断的情况，在可用性上体验不错。

4.TiDB 支持和 MySQL 的互备，这个功能很好的解决了我们业务迁移时候的过渡问题。

当前我们正在着手把 storm 集群上的 BI 系统的实时计算业务的数据存储系统从 MongoDB 替换成 TiDB（因 MongoDB 的使用门槛相对较高，运维成本大，查询方式不如传统的 SQL 灵活），后续也计划把实时性要求高、数据存储量大且存储周期较长的业务都迁移到 TiDB 上来，看上去是一个比较合适的场景。

TiDB 工程师点评

盖娅的业务使用 TiDB 做了如下优化：

1.支持更多表达式下推，充分利用 TiKV 多实例的计算资源，加快计算速度；同时也尽可能将不需要用到的数据过滤掉，减小网络传输。

2.TiDB 默认支持 HashJoin，将算子尽可能并行化，能够利用整个集群的计算资源。

3.TiDB 采用流水线的方式读取数据，并且优化过 IndexScan 算子，降低整个流程的启动时间。

作者简介：刘玄，盖娅互娱数据平台高级开发工程师，主要负责实时数据业务和数据流方向。毕业于湖南大学软件工程系，曾任百度高级运维工程师，负责大搜建库运维。

未来几年，全球数据量将呈指数级增长。据IDC统计，到2020年，全球数据总量将达到44ZB，中国数据量将达到8060EB，占全球数据总量的18%。数据，已然对当下的商务、生活乃至方方面面都产生了深远的影响。可众所周知，各行各业数据生产的速度要远远大于数据消化的速度。数据分析处理的不及时，必然造成大量具有时效性数据的浪费，日积月累，这样的不匹配性会越来越严重。

如何消除这样的不匹配性？归根结底，我们需要一种能够对更大规模数据做到更实时更迅捷的分析工具。

顺势而生的GPU数据库

2015年，已经在甲骨文公司工作了6年的星爵意识到，传统的数据库系统需要革新了。传统CPU数据库的发展主要面临两大瓶颈，一是数据计算速度，二是数据访问速度。而负责算力的CPU，目前停留在数十核的规模，这已经接近它的物理极限了。数据库计算领域，是时候该添加新鲜血液了。

2013年，深度学习技术的崛起让人们看到了GPU的力量。在这之前，GPU的主要功能是图片渲染，通过模拟现实场景生成接近于真实景象的图片，主要被应用于游戏领域。而深度学习技术，使GPU“大规模并行计算”的能力得以展现，人们对它的认知终于不再是游戏机，GPU，也可以成为像CPU一样的服务器。而星爵，更是坚定的认为，GPU处理大数据已经成为一种趋势。各种深度学习的软件框架例如TensorFlow，需要运行在计算设备上，与CPU相比，GPU更能让其高效的工作，在性价比以及计算力上都有较大的优势。

没有犹豫，星爵离开甲骨文，回国创立了Zilliz，他要做人工智能时代的数据库系统。

星爵认为，在过去数十年间，人工智能因为CPU架构下计算能力的限制而裹足不前，OLAP数据库技术也因为同样的原因而发展缓慢。就像华岩资本合伙人黄志玮所认为的，我们需要一个基于众核处理器硬件加速的、面向人工智能的新一代OLAIP（On-Line Analytical and Intellegent Processing）数据库系统，而这正是Zilliz在研发的产品。

Zilliz使用众核处理器上的成千上万个处理核心进行超大规模并行数据处理，实现数据库操作的加速，同时提供数据库系统和人工智能计算框架之间的直接数据通道。Zilliz将人工智能处理引擎融合进数据库执行引擎，提供集数据存储、分析、管理、和人工智能处理与一身的OLAIP数据库系统。

星爵向亿欧介绍，Zilliz基于GPU的数据库系统可以比CPU数据库的性能提高100倍，可大范围的应用于金融、电信、互联网以及政府领域。

在商业模式上，Zilliz为各行业的头部客户和互联网公司提供了不同的方案。对于头部客户，Zilliz即可以为其提供私有部署，同时还有基于一体机的解决方案；对于互联网公司，尤其是那些将数据部署在云端的客户，Zilliz可以为其提供SaaS的方案，使用各大云厂商提供的GPU，在云端为客户提供服务，从而使客户无需采购GPU硬件设备便可以使用。

新技术的新“麻烦”

大多数人有这样一个疑问——

即便GPU数据库的使用性能和性价比，与原有系统相比更有优势，但是要让用户将存储在CPU服务器上的数据快速迁移到GPU服务器中，可行性有多大？

这关乎到Zilliz的未来，也是星爵自公司创立之初就在解决的问题。星爵表示，Zilliz并不是要替代原有的CPU方案，而是要在大规模数据的实时性分析方面开创一个新的蓝海市场。

人工智能时代下，数据量将会呈指数型增长。在这样的情况下，各行各业的业务想要得到更好的发展，实时数据分析能力以及实时数据驱动运营能力将是其核心的竞争力，因此，Zilliz产品的存在是有其合理性的。

Zilliz投资人云启资本执行董事陈昱表示，在大数据时代，企业需要一个更大、更快、更强的数据库，人工智能技术的加入，是一种对传统数据库的革新，使数据库产生了更高的效率，这无疑是当下各公司最迫切的需求。

另外，星爵希望将数据库软件做成一个标准件。作为一个底层的数据库软件，需要对外提供标准化的查询语言接口，理想状态应当是用户在接入新数据库的时候，其业务层面不发生改变。因此Zilliz通过产品化与标准化，为用户提供标准SQL接口以及各种ETL工具，从而降低用户在数据迁移过程中的成本，尽量做到“无感迁移”。对于用户来说，相当于更换了一个数据库的软件和引擎，但是其业务层并不会受到影响。

星爵还向亿欧透露，为了更加快速的在CPU处理器与GPU处理器之间进行数据交换，Zilliz与IBM合作生产了数据库一体机，使用NvLink技术，能够大大提升不同类型处理器芯片之间的数据传输速度。

资本认可，行业进入爆发期

目前世界范围内做OLAP GPU数据库加速的公司仅有4家：

星爵介绍，在这一领域，国外从2006年就已经开始有所研究，然而，当时的市场认知度不足，用户对于GPU还停留在游戏处理器的认知上，且高端GPU的市场存量较少，并没有基于GPU部署数据库系统的实力。另一方面，整个生态系统还处于早期的发展状态，各种相关工具及配套软件比较缺乏。基于以上两点原因，国外公司在这一方面并没有太多优势。

到2016年，市场认知才有所好转。从业人员开始意识到GPU也可以做与企业相关的工程（例如深度学习），同时，GPU服务器已经成为常态，各种GPU的生态体系也逐渐完善，种种原因使得2016年成为GPU数据库的元年，至此，资本市场逐渐认可这一领域，GPU数据库进入爆发期。

然而爆发并不意味着竞争，靖亚资本创始人郑靖伟向亿欧介绍，数据库这样底层技术的门槛很高，国内少有人研究。产品的研发与验证都需要一定时间，而对于一般的大型中型公司来说，更换数据库系统需要进行很多的测试来评估流程，一旦被验证，很难再次更换数据库系统提供商。

而2018年，将是GPU数据库在各行各业应用更为广泛的一年。

日常一提数据分析和可视化，就想到这个工具操作要多简单易用，图表要多美多炫，然而总是忽略背后的数据支撑。

excel 几十万行数据就卡死崩，谈何数据透视表、可视化？近千万行的数据，订单提交数据库，sql sever处理要5分多钟，如果频繁入库/取数的话.....

要知道，为了支撑起业务人员的数据分析，以及日常不考虑计算逻辑和技术难度，IT人员也是要花费很大的心血和精力啊（心疼运维人员n秒）。

随着公司业务的发展，数据量变大是必然的事实。那么，数据部门要做分析，业务部门要看报表，要跑数据，要用BI，大数据量（千万级及以上）的分析，性能该如何优化？

这里借某公司的真实案例，来阐述一下方案。

----------------------------------

作为公司的科技部门人员，经常听到业务部门对自己使用的数据库各种吐槽：

竟然存放在mongoDB中啊，震惊(ΩДΩ)。

数据库慢慢熟悉了还好啊，但是现在每天的数据量越来越大，而且还在增加啊，增加大家很开心，然而数据库并不开心啊，简单的查询统计10多分钟还出不来结果，更不用说有稍微复杂点的统计分析了。

我天天找DBA优化啊，然而并没有什么水花。

数据量还在不断增长，到现在都上亿啦，全量查询统计根本出不来结果啊。

... ...

最终业务人员找到科技部门提需求要弄个BI系统给处理下。

对mongodb瞄了一大通，这就是个业务库。那直接对接mongodb自然不行，速度慢不说，mongodb挂了，分析系统也瘫了。自然就想到了使用中间库，emm mysql oracle 倒是有，可以跑调度抽过来，但是速度依旧不快呢，还要花功夫优化，性价比不高。公司有自己的hadoop平台，将数据抽过来再对接倒是可以，但是要花很大精力跑调度，而且这个数据库不能随意给这个业务部门提供，万一玩挂了可就得不偿失。假设有个具备离线数据存储功能的BI工具，岂不美哉。

于是将市面上有离线数据存储功能的BI工具翻了个遍。期望找到个性能好，可以支持大数据量数据分析的BI工具。

Tableau的hyper功能看起来OK，经不起实际使用，数据量过了亿，等了好久数据抽不好，pass；

其他某BI工具有mpp离线存储，看起来很棒，还能横向扩展，不错。抱有最大期望的用，结果数据量一上亿，直接崩了，崩了，pass；

另一个BI工具去看了看，咦，数据是放在vertica里面的......

后来，找到了FineBI的分布式计算引擎方案，拿的『定制的 Alluxio』作为分布式内存存储框架，内存存储有数据安全性的担心，所以持久化层存储用了HDFS。为了数据分析嘛，自然是列式存储的。计算核心则以熟知的Spark，加上自研算法来处理的。使用熟知的zookeeper整合框架，并用于调度通信。

分布式嘛，横向扩展自然不在话下。而列式存储、并行内存计算、计算本地化加上高性能算法，在FineBI中数据展示速度超快。有意思的是其计算本地化的操作，能减少不必要的shuffle，节省数据传输的消耗，提升数据计算速度。

以下记录利用FineBI4.1工具的系统建设过程。

一、需求分析

针对以上的需求，可以预估到，18年内，常用分析预计最大数据量会达到4.7kw，不常用分析会达到3亿到4亿（包含淡季），数据总的体量最多会达到100G。后面的情况难以预估，就需要系统可横向扩展节点。

二、方案描述

1.系统架构

根据官方推荐，将FineBI的web应用端与数据存储的分布式引擎放在一个机器上（处于安全考虑，也可以分开。这里不涉及太多部门使用，放一起即可），架构如下所示。

架构图难以理解的话，可以看看灵魂画手的杰作~

结合分布式引擎说明的技术原理，将各个机器再细分化各个组件的作用。

以上，将系统架构规划完成，即可具体完成系统。

2.完成从MongoDB取数

在使用BI工具对接MongoDB的时候，使用MongoDB的BI连接器。

感兴趣可以看：MongoDB Download Center

方案原理：mongodb是非结构的数据库，而要想BI来连接，通过建模的方式取表，拆表，建模来分析。通过MONGODB CONNECTOR FOR BI连接器的方式，使用mysql的JDBC驱动来获取数据。

实现过程：

第一步：安装MONGODB CONNECTOR FOR BI

从官网选择版本：MongoDB Download Center

第二步：生成DRDL文件

mongodrdl是生成该文件的主命令。通过添加monogdb的相关参数来获取其中的表生成drdl文件。从官方文档上我们可以找到生成DRDL文件命令的范式：

1 mongodrdl --host myhost.example:27017 \2 --username dbUser \3 --password myPassword \4 --db reports \5 --authenticationDatabase admin \6 --out schema.drdl

范式说明：

--host 是mongodb的ip+端口号，通常可为127.0.0.1:27017--username 是mongodb的用户，需具备相关的数据权限--password 是username的密码--db 是要生成DRDL的数据库实例名--authenticationDatabase 是指定创建用户的数据库。即username创建时被指定到的数据库名。--out 是DRDL输出文件定义。值使用.drdl的文件即可。

第三步：启动连接器，连接上monogdb

启动连接器的主命令服务是mongosqld，由于mongodb开启用户认证了（auth=true）。从官方文档上可知，连接器的启动需要使用-auth参数，再使用auth参数的情况下，mysql驱动来取数就需要SSLl加密认证。

所以第一步需要配置mongosqld的SSL认证；才能启动连接器来取数！！！！！！！！！！这一步神坑，也是踩了多少坑，才找到的解决办法。

此处认证关系是FineBi端的mysql连接与mongosqld的连接之间的SSL认证。在认证时，只需要配置单向SSL的认证即可（mongosqld认证FineBI的连接）。

（1）生成SSL认证文件

SSL认证文件通常采用openSSL来生成，先看看是否安装了openSSL；执行命令：

rpm -qa|grep -i openssl

如安装了会返回信息，未安装需要自行安装OpenSSL。

采用以下命令来生成证书：（由于是测试，就直接自己生成证书，密钥）

openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key

命令返回会让填写一些值，在后面填写即可。

一般情况下，文件会生成到你所使用的linux用户的要根目录下：比如我用的root用户，就到/root下面查找。

再使用以下命令，将key合到.pem的文件里。

cat mongodb-cert.key mongodb-cert.crt >mongodb.pem

将该文件移动/etc/ssl下面用于验证使用：

mv mongodb.pem /etc/ssl

（2）启动连接器&SSL

再来看官方文档，从所有的参数命令里面，找一找需要的参数；得出以下的范式，在bin目录下启动即可。

mongosqld --auth --sslMode --sslPEMKeyFile --sslAllowInvalidCertificates --defaultAuthSource --mongo-uri --mongo-username --mongo-password --mongo-authenticationSource --schema

说明：

--auth 是开启用户认证的参数，默认值是true--sslMode是开启SSL的标识，如开启可以选择值为“requireSSL”--sslPEMKeyFile是SSL认证文件，一般为.pem结尾的文件；单向认证的时候。--sslAllowInvalidCertificates--defaultAuthSource是mongosqld使用username指向mongodb的有权限的库，默认值是admin--mongo-uri是mongodb的host，一般为ip+端口号--mongo-usrname是drdl生成的用户名--mongo-password是drdl生成的密码--mongo-authenticationSource指定用户的创建库--schema是要连接的drdl文件。

注：一般还是要用nohup 的命令来生成，保证shell断掉，连接器依然可用。

第四步：启动FineBI连接到连接器上

启动FineBI，打开FineBI>数据配置>数据连接：添加数据连接选择mysql，配置如下：

连接名：mongodbURL：jdbc：mysql：//127.0.0.1:3307/test?ssl-key=/etc/ssl/mongodb.pem用户名：密码：注：URL：jdbc：mysql://ip+3307/dbname?ssl-key=xx.pem，后面ssl-key是ssl参数

点击测试连接即可。

过程坑点：mongodb的BI连接器神坑，官网文档不多，踩过了几脚坑。

（1）mongosqld按ssl认证开启成功，打印也不错，但是BI连接的时候，还是抛错1043 SQLSTATE: 08S01 (ER_HANDSHAKE_ERROR):this server only allows SSL xxxxx该抛错是mysql抛出来的，握手不良的错误。按道理SSL已经开启了，不应该是这样。后来查了mysql的文档，mysql5.5以上的版本才支持SSL；更换新的driver驱动，使用的是5.1.44完全没问题的。

（2）BI连接的时候抛错 handshake error: ERROR 1043 (08S01): error performing authentication: unable to authenticate conversation 0: unable to authenticate using mechanism "SCRAM-SHA-1": (AuthenticationFailed) Authentication failed.

该抛错的意思，使用“SCRAM-SHA-1”的认证方式，没有认证成功。SCRAM-SHA-1是指用户名密码的方式，这里看是不是用户名/密码错误，注意mongosqld启动时的使用的用户名/密码

（3）一定要开启SSL认证啊！！！

（4）期间有设计器无故死掉的情况，发现是由于内存不足导致。记得空闲内存要足够！！

三.系统效果

1.数据更新

（1） 单个表先全量抽取，之后每天对单表依据时间戳，做增量增加。其中有错误数据做增量删除即可。

（2）有些内部使用的实时性较高的表，设定每2小时更新一次，从上午9点到下午6点。直接从业务库抽取其实是有风险的，当时数据库压力大，抽取比较慢，因此这部分仅作为非重点用户需求场景。

2.数据展示速度

做了一个简单的依据时间的group by，时间在1s之内，翻页速度也很快。

至此，对接mongodb完成，一个用户可以随便玩的系统就好了。即使偶尔mongodb发疯修整，有离线数据在，也不担心业务部门来嚷嚷了。而且速度超快，体验很棒~

最后

如果你也在寻求一个高性能展示分析、数据分析的BI工具的话，不妨尝试下FineBI。