本文是我在阅读大数据基础时做的笔记。
几种不同的数据库之间的比较
数据库的方向 - 行vs列
在行式数据库中，每一行中的每一块数据都是紧挨着另一块数据存放在硬盘中。一般情况下，你可以认为每一行存贮的内容就是硬盘中的一组连续的字节。
为了方便我们的讨论，我们假设每一行都包含一个用户的信息，每个用户的所有属性都整块儿存储在硬盘上。
在上边的例子中，Alice的所有信息都存储在一个页面中。如果需要获取或更新Alice的信息，那么某一时刻在内存中仅需存储关于Alice的单一页面。
如果是基于列的数据库，所有的数据都是以列的形式存储的。回到之前的例子，假设每一列的存储对应一个页面。如下图所示，所有的ZIP code将会存储到一个页面中，而所有的“2013 Total Order”则会存储在另一个页面中。
所以，如果你使用的是行式数据库，那么你对一行数据进行操作时，数据库的性能会是最好的。在上面的例子中，仅一个页面被放到了内存中。（这只是一个示例，事实上，操作系统会带来不止一页的数据，稍后详细说明）
另一方面，如果你的数据库是基于行的，但是你要想得到所有数据中，某一列上的数据来做一些操作，这就意味着你将花费时间去访问每一行，可你用到的数据仅是一行中的小部分数据。
可关键在于你使用列式数据库时，当你想要得到Alice的所有信息时，你又必须要读取大量的列（页面）来获取所有的数据。
OLTP工作负载是数据库现有业务的关键业务。一般而言，这些应用程序在使用行数据库时会有更好的表现，因为其工作负载趋向于单一实体的多个属性（存储在很多的列中）。由于这些应用程序都是基于行工作的，所以在使用时，从硬盘中获取的页面数量是最小的。
在线分析处理（OLAP）工作负载常常需要收集列中的数据。当你使用基于列的数据库时，你可以将这一列放到内存中并统计所有值。但当使用的是基于行的数据库时，就必须去访问每一行而获取对应的数据。
对比
数据修改：行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入
数据读取：行存储通常将一行数据完全读出，如果只需要其中几列数据的情况，就会存在冗余列；列存储每次读取的数据是集合的一段或者全部，如果读取多列时，就需要移动磁头，再次定位到下一列的位置继续读取。
行存储的写入是一次性完成，消耗的时间比列存储少，并且能够保证数据的完整性，缺点是数据读取过程中会产生冗余数据，如果只有少量数据，此影响可以忽略；数量大可能会影响到数据的处理效率。列存储在写入效率、保证数据完整性上都不如行存储，它的优势是在读取过程，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。
如果以保存数据为主，行存储的写入性能比列存储高很多。在需要频繁读取单列集合数据的应用中，列存储是最合适的。
若采用列存储方案，为保证读写入效率，每列数据尽可能分别保存到不同的磁盘上，多个线程并行读写各自的数据，这样避免了磁盘竞用的同时也提高了处理效率。
改进
行存储的改进：减少冗余数据首先是用户在定义数据时避免冗余列的产生；其次是优化数据存储记录结构，保证从磁盘读出的数据进入内存后，能够被快速分解，消除冗余列。
列存储的两点改进：1.在计算机上安装多块硬盘，以多线程并行的方式读写它们。多块硬盘并行工作可以减少磁盘读写竞用，这种方式对提高处理效率优势十分明显。缺点是需要更多的硬盘，这会增加投入成本，在大规模数据处理应用中是不小的数目，运营商需要认真考虑这个问题。2.对写过程中的数据完整性问题，可考虑在写入过程中加入类似关系数据库的“回滚”机制，当某一列发生写入失败时，此前写入的数据全部失效，同时加入散列码校验，进一步保证数据完整性。
频繁的小量的数据写入对磁盘影响很大，更好的解决办法是将数据在内存中暂时保存并整理，达到一定数量后，一次性写入磁盘，这样消耗时间更少一些。
hbase
hbase 是 noSql数据库的一种，最常见的应用场景就是采集的网页数据的存储，由于是key-value型数据库，可以再扩展到各种key-value应用场景，如日志信息的存储，对于内容信息不需要完全结构化出来的类CMS应用等。注意hbase针对的仍然是OLTP应用为主。
而HBase表是物理表，适合存放非结构化的数据。
hive
对于hbase当前noSql数据库的一种，最常见的应用场景就是采集的网页数据的存储，由于是key-value型数据库，可以再扩展到各种key-value应用场景，如日志信息的存储，对于内容信息不需要完全结构化出来的类CMS应用等。注意hbase针对的仍然是OLTP应用为主。
Hive中的表是纯逻辑表，就只是表的定义等，即表的元数据。Hive本身不存储数据，它完全依赖HDFS和MapReduce。这样就可以将结构化的数据文件映射为为一张数据库表，并提供完整的SQL查询功能，并将SQL语句最终转换为MapReduce任务进行运行。
hive一般只用于查询分析统计，而不能是常见的CUD操作
Hive是基于MapReduce来处理数据,而MapReduce处理数据是基于行的模式；HBase处理数据是基于列的而不是基于行的模式，适合海量数据的随机访问。
Hbase和Hive在大数据架构中处在不同位置，Hbase主要解决实时数据查询问题，Hive主要解决数据处理和计算问题，一般是配合使用。
基础-HDFS
Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。
HDFS（Hadoop Distributed FileSystem）的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。
HDFS、MapReduce、Hive、
存的下数据之后，你就开始考虑怎么处理数据。虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。一台机器慢慢跑也许需要好几天甚至好几周。那么我如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。这就是MapReduce / Tez / Spark的功能。
MapReduce是第一代计算引擎，Tez和Spark是第二代。MapReduce的设计，采用了很简化的计算模型，只有Map和Reduce两个计算过程（中间用Shuffle串联），用这个模型，已经可以处理大数据领域很大一部分问题了。
第二代的Tez和Spark除了内存Cache之类的新feature，本质上来说，是让Map/Reduce模型更通用，让Map和Reduce之间的界限更模糊，数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。
有了MapReduce，Tez和Spark之后，程序员发现，MapReduce的程序写起来真麻烦。他们希望简化这个过程。这就好比你有了汇编语言，虽然你几乎什么都能干了，但是你还是觉得繁琐。你希望有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Pig和Hive。Pig是接近脚本方式去描述MapReduce，Hive则用的是SQL。它们把脚本和SQL语言翻译成MapReduce程序，丢给计算引擎去计算。
自从数据分析人员开始用Hive分析数据之后，它们发现，Hive在MapReduce上跑，真慢！于是Impala，Presto，Drill诞生了（当然还有无数非著名的交互SQL引擎，就不一一列举了）。三个系统的核心理念是，MapReduce引擎太慢，因为它太通用，太强壮，太保守，我们SQL需要更轻量，更激进地获取资源，更专门地对SQL做优化，而且不需要那么多容错性保证（因为系统出错了大不了重新启动任务，如果整个处理时间更短的话，比如几分钟之内）。这些系统让用户更快速地处理SQL任务，牺牲了通用性稳定性等特性。
上面的介绍，基本就是一个数据仓库的构架了。底层HDFS，上面跑MapReduce／Tez／Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。这解决了中低速数据处理的要求。
如果我是一个类似微博的公司，我希望显示不是24小时热博，我想看一个不断变化的热播榜，更新延迟在一分钟之内，上面的手段都将无法胜任。于是又一种计算模型被开发出来，这就是Streaming（流）计算。Storm是最流行的流计算平台。流计算的思路是，如果要达到更实时的更新，我何不在数据流进来的时候就处理了？比如还是词频统计的例子，我的数据流是一个一个的词，我就让他们一边流过我就一边开始统计了。流计算很牛逼，基本无延迟，但是它的短处是，不灵活，你想要统计的东西必须预先知道，毕竟数据流过就没了，你没算的东西就无法补算了。因此它是个很好的东西，但是无法替代上面数据仓库和批处理系统。
- 存储，海量的数据怎样有效的存储？主要包括hdfs、Kafka；
- 计算，海量的数据怎样快速计算？主要包括MapReduce、Spark、Flink等；
- 查询，海量数据怎样快速查询？主要为Nosql和Olap，Nosql主要包括Hbase、 Cassandra 等，其中olap包括kylin、impla等，其中Nosql主要解决随机查询，Olap技术主要解决关联查询；
Hadoop
Hadoop包括三大部分，分别是hdfs、MapReduce和hbase：
- hdfs解决大数据的存储问题。
- mapreduce解决大数据的计算问题。
- hbase解决大数据量的查询问题。