1 数据仓库介绍
1.1 数据仓库简介
数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，主要针对来自多个数据源的历史数据进行细粒度、多维度的分析，输出用于企业的数据分析、数据挖掘、数据报表等方向，帮助管理者或业务分析人员做出商业战略决策。
数据仓库可概括为四个特点：
面向主题：数据仓库都是基于某个明确主题，仅需要与该主题相关的数据，其他的无关细节数据将被排除掉。不同于传统数据库对应某一个或多个项目，数据仓库根据使用者实际需求，将不同数据源的数据在一个较高的抽象层次上做整合，所有数据都围绕某一主题来组织。比如对于滴滴出行，“司机行为分析”就是一个主题，对于链家网，“成交分析”就是一个主题。
集成的：从不同的数据源采集数据到同一个数据源，此过程会有一些ETL操作
随时间变化：关键数据隐式或显式的基于时间变化
信息本身相对稳定：数据装入以后一般只进行查询操作，没有传统数据库的增删改操作。
在这解释下主题的概念，主题是根据分析的要求来确定的，这与按照数据处理或应用的要求来组织数据是不同的。如在生产企业中，同样是材料供应，在操作型数据库系统中，人们所关心的是怎样更方便和更快捷地进行材料供应的业务处理；而在进行分析处理时，人们就应该关心材料的不同采购渠道和材料供应是否及时，以及材料质量状况等。数据仓库面向在数据模型中已经定义好的公司的主要主题领域。典型的主题领域包括顾客、产品、订单和财务或是其他某项事务或活动。
1.2 数据仓库架构
数据采集层
参考我前面写的文章，大数据架构之端到端方案综述（1）数据采集。
数据存储与分析
以HDFS+MR的离线分析为主，参考我前面写的文章，大数据架构之端到端方案综述（2）数据处理。
数据共享
使用Hive、MR、Spark、SparkSQL分析和计算的结果，仍存储于HDFS，但大多业务和应用不能直接从HDFS获取数据，此时需要一个数据共享的地方，即关系型数据库如MySql或非关系型数据库NoSQL，使得各业务和产品能方便的获取数据。
数据应用
报表：报表所使用的数据，一般是已经统计汇总好的，存放于数据共享层。
接口：接口的数据都是直接查询数据，从共享层获取。
即席查询：即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层HDFS直接查询，一般都是直接操作SQL获取。
在这解释下报表&接口，与即席查询的区别：
批处理
又称批处理脚本。在数据仓库系统中，根据应用程序的需求，需要对源数据进行加工，这些加工过程往往是固定的处理原则，这种情况下，可以把数据的增删改查SQL语句写成一个批处理脚本，由调度程序定时执行。
特点：由于批处理脚本中的SQL语句是固定的，所以可以提前完成SQL语句的调优工作，使得批处理脚本的运行效率达到最佳。
即席查询
在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。
即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成返回响应的结果，例如返回用户自定义的统计报表。
特点：即席查询与批处理脚本/普通应用查询最大的不同是普通的应用查询是定制开发的（即查询语句是预先写好的，不会临时变化），而即席查询是由用户自定义查询条件的。
即席查询与普通查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，普通查询在系统设计和实施时是已知的，所有可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，无法人工预先优化这些查询，需要数据库内部实时自动优化，所以即席查询也是评估数据仓库的一个重要指标。在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。
1.3 数据仓库设计步骤
1、确定主题
主题与业务密切相关，所以设计数仓之前应当充分了解业务有哪些方面的需求，据此确定主题
2、确定量度
在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。量度是要统计的指标，必须事先选择恰当，基于不同的量度将直接产生不同的决策结果。
3、确定数据粒度
考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。例如，如果知道某些数据细分到天就好了，那么设置其粒度到天；但是如果不确定的话，就将粒度设置为最小，即毫秒级别的。
4、确定维度
设计各个维度的主键、层次、层级，尽量减少冗余。
5、创建事实表
事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多(粒度最小)，而描述性信息尽量少。
事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发生的事情。事实表中存储数字型ID以及度量信息。维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的，事实表和维表通过ID相关联。
1.4 应用场景
尽管数据仓库建模方法论是一致的，但由于所面临的行业、场景的不同，在互联网领域，基于大数据的数据仓库建设无法按照原有的项目流程、开发模式进行，更多的是需要结合新的技术体系、业务场景进行灵活的调整，以快速响应需求为导向。
传统的数仓建设周期长，需求稳定，面向DSS、CRM、BI等系统，时效性要求不高。
基于大数据的数据仓库建设要求快速响应需求，同时需求灵活、多变，对实时性有不同程度的要求，除了面向BI等传统应用外，还包括：
1.数据分析、数据挖掘、人工智能、机器学习、风险控制、无人驾驶
2.数据化运营、精准运营
3.广告精准、智能投放
2 数据仓库之Hive
2.1 Hive简介
From
1、Hive 由 Facebook 实现并开源
2、是基于 Hadoop 的一个数据仓库工具
3、可以将结构化的数据映射为一张数据库表
4、并提供 HQL(Hive SQL)查询功能
5、底层数据是存储在 HDFS 上
6、Hive的本质是将 SQL 语句转换为 MapReduce 任务运行
7、使不熟悉 MapReduce 的用户很方便地利用 HQL 处理和计算 HDFS 上的结构化的数据，适用于离线的批量数据计算，Hive 依赖于 HDFS 存储数据，Hive 将 HQL 转换成MapReduce 执行，所以说 Hive 是基于 Hadoop 的一个数据仓库工具，实质就是一款基于 HDFS 的 MapReduce 计算框架，对存储在 HDFS 中的数据进行分析和管理。
为什么使用Hive
直接使用 MapReduce 所面临的问题：
1、人员学习成本太高
2、项目周期要求太短
3、MapReduce实现复杂查询逻辑开发难度太大
使用 Hive好处：
1、更友好的接口：操作接口采用类 SQL 的语法，提供快速开发的能力
2、更低的学习成本：避免了写 MapReduce，减少开发人员的学习成本
3、更好的扩展性：可自由扩展集群规模而无需重启服务，还支持用户自定义函数
Hive优点
1、可扩展性,横向扩展，Hive 可以自由的扩展集群的规模，一般情况下不需要重启服务 横向扩展：通过分担压力的方式扩展集群的规模 纵向扩展：一台服务器cpu i7-6700k 4核心8线程，8核心16线程，内存64G => 128G
2、延展性，Hive 支持自定义函数，用户可以根据自己的需求来实现自己的函数
3、良好的容错性，可以保障即使有节点出现问题，SQL 语句仍可完成执行
Hive缺点
1、Hive 不支持记录级别的增删改操作，但是用户可以通过查询生成新表或者将查询结 果导入到文件中（当前选择的 hive-2.3.2 的版本支持记录级别的插入操作）
2、Hive 的查询延时很严重，因为 MapReduce Job 的启动过程消耗很长时间，所以不能 用在交互查询系统中。
3、Hive 不支持事务（因为不没有增删改，所以主要用来做 OLAP（联机分析处理），而 不是 OLTP（联机事务处理），这就是数据处理的两大级别）。
2.2 Hive架构
从上图看出hive的内部架构由四部分组成：
1、用户接口: shell/CLI, jdbc/odbc, webui Command Line Interface
CLI，Shell 终端命令行（Command Line Interface），采用交互形式使用 Hive 命令行与 Hive 进行交互，最常用（学习，调试，生产）
JDBC/ODBC，是 Hive 的基于 JDBC 操作提供的客户端，用户（开发员，运维人员）通过 这连接至 Hive server 服务
Web UI，通过浏览器访问 Hive
2、跨语言服务 ： thrift server 提供了一种能力，让用户可以使用多种不同的语言来操纵hive
Thrift 是 Facebook 开发的一个软件框架，可以用来进行可扩展且跨语言的服务的开发， Hive 集成了该服务，能让不同的编程语言调用 Hive 的接口
3、底层的Driver： 驱动器Driver，编译器Compiler，优化器Optimizer，执行器Executor
Driver 组件完成 HQL 查询语句从词法分析，语法分析，编译，优化，以及生成逻辑执行 计划的生成。生成的逻辑执行计划存储在 HDFS 中，并随后由 MapReduce 调用执行
Hive 的核心是驱动引擎， 驱动引擎由四部分组成：
(1) 解释器：解释器的作用是将 HiveSQL 语句转换为抽象语法树（AST）
(2) 编译器：编译器是将语法树编译为逻辑执行计划
(3) 优化器：优化器是对逻辑执行计划进行优化
(4) 执行器：执行器是调用底层的运行框架执行逻辑执行计划
4、元数据存储系统 ： RDBMS MySQL
元数据，通俗的讲，就是存储在 Hive 中的数据的描述信息。
Hive 中的元数据通常包括：表的名字，表的列和分区及其属性，表的属性（内部表和 外部表），表的数据所在目录
Metastore 默认存在自带的 Derby 数据库中。缺点就是不适合多用户操作，并且数据存 储目录不固定。数据库跟着 Hive 走，极度不方便管理
解决方案：通常存我们自己创建的 MySQL 库（本地 或 远程）
Hive 和 MySQL 之间通过 MetaStore 服务交互
执行流程
HiveQL 通过命令行或者客户端提交，经过 Compiler 编译器，运用 MetaStore 中的元数 据进行类型检测和语法分析，生成一个逻辑方案(Logical Plan)，然后通过的优化处理，产生 一个 MapReduce 任务。
Hive的数据组织
1、Hive 的存储结构包括数据库、表、视图、分区和表数据等。数据库，表，分区等等都对 应 HDFS 上的一个目录。表数据对应 HDFS 对应目录下的文件。
2、Hive 中所有的数据都存储在 HDFS 中，没有专门的数据存储格式，因为 Hive 是读模式 （Schema On Read），可支持 TextFile，SequenceFile，RCFile 或者自定义格式等
3、 只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据
Hive 的默认列分隔符：控制符 Ctrl + A，\x01 Hive 的
Hive 的默认行分隔符：换行符 \n
4、Hive 中包含以下数据模型：
database：在 HDFS 中表现为${hive.metastore.warehouse.dir}目录下一个文件夹
table：在 HDFS 中表现所属 database 目录下一个文件夹
external table：与 table 类似，不过其数据存放位置可以指定任意 HDFS 目录路径
partition：在 HDFS 中表现为 table 目录下的子目录
bucket：在 HDFS 中表现为同一个表目录或者分区目录下根据某个字段的值进行 hash 散 列之后的多个文件
view：与传统数据库类似，只读，基于基本表创建
5、Hive 的元数据存储在 RDBMS 中，除元数据外的其它所有数据都基于 HDFS 存储。默认情 况下，Hive 元数据保存在内嵌的 Derby 数据库中，只能允许一个会话连接，只适合简单的 测试。实际生产环境中不适用，为了支持多用户会话，则需要一个独立的元数据库，使用 MySQL 作为元数据库，Hive 内部对 MySQL 提供了很好的支持。
6、Hive 中的表分为内部表、外部表、分区表和 Bucket 表
内部表和外部表的区别：
删除内部表，删除表元数据和数据
删除外部表，删除元数据，不删除数据
内部表和外部表的使用选择：
大多数情况，他们的区别不明显，如果数据的所有处理都在 Hive 中进行，那么倾向于 选择内部表，但是如果 Hive 和其他工具要针对相同的数据集进行处理，外部表更合适。
使用外部表访问存储在 HDFS 上的初始数据，然后通过 Hive 转换数据并存到内部表中
使用外部表的场景是针对一个数据集有多个不同的 Schema
通过外部表和内部表的区别和使用选择的对比可以看出来，hive 其实仅仅只是对存储在 HDFS 上的数据提供了一种新的抽象。而不是管理存储在 HDFS 上的数据。所以不管创建内部 表还是外部表，都可以对 hive 表的数据存储目录中的数据进行增删操作。
分区表和分桶表的区别：
Hive 数据表可以根据某些字段进行分区操作，细化数据管理，可以让部分查询更快。同时表和分区也可以进一步被划分为 Buckets，分桶表的原理和 MapReduce 编程中的 HashPartitioner 的原理类似。
分区和分桶都是细化数据管理，但是分区表是手动添加区分，由于 Hive 是读模式，所以对添加进分区的数据不做模式校验，分桶表中的数据是按照某些分桶字段进行 hash 散列 形成的多个文件，所以数据的准确性也高很多。
2.3 Hive应用场景
Hive 并不适合那些需要低延迟的应用，Hive 的最佳使用场合是大数据集的批处理作业。
数据挖掘
- 用户行为分析
- 兴趣分区
- 区域展示
非实时分析
- 日志分
- 文本分析
数据汇总
- 每天/周用户点击情况
- 流量统计
作为数据仓库
- 数据抽取
- 数据加载
- 数据转换
3 Hive和Hbase
3.1 Hbase简介
HBase是一种Hadoop数据库，经常被描述为一种稀疏的，分布式的，持久化的，多维有序映射，它基于行键、列键和时间戳建立索引，是一个可以随机访问的存储和检索数据的平台。它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。HBase不限制存储的数据的种类，允许动态的、灵活的数据模型，不用SQL语言，也不强调数据之间的关系。HBase被设计成在一个服务器集群上运行，可以相应地横向扩展。Hbase处在Hadoop生态的位置。Hive详解可参考：。
Hbase的使用场景：
- 互联网搜索问题：爬虫收集网页，存储到BigTable里，MapReduce计算作业扫描全表生成搜索索引，从BigTable中查询搜索结果，展示给用户。
- 抓取增量数据：例如，抓取监控指标，抓取用户交互数据，遥测技术，定向投放广告等
- 内容服务
- 信息交互
Hbase的架构图如下图所示：
从图中可以看出Hbase是由Client、Zookeeper、Master、HRegionServer、HDFS等几个组建组成，下面来介绍一下几个组建的相关功能：
Client
Client包含了访问Hbase的接口，另外Client还维护了对应的cache来加速Hbase的访问，比如cache的.META.元数据的信息。
Zookeeper
Hbase通过Zookeeper来做master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。具体工作如下：
通过Zoopkeeper来保证集群中只有1个master在运行，如果master异常，会通过竞争机制产生新的master提供服务
通过Zoopkeeper来监控RegionServer的状态，当RegionSevrer有异常的时候，通过回调的形式通知Master RegionServer上下限的信息
通过Zoopkeeper存储元数据的统一入口地址
Hmaster
master节点的主要职责如下：
为RegionServer分配Region
维护整个集群的负载均衡
维护集群的元数据信息
发现失效的Region，并将失效的Region分配到正常的RegionServer上
当RegionSever失效的时候，协调对应Hlog的拆分
HregionServer
HregionServer直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如下：
管理master为其分配的Region
处理来自客户端的读写请求
负责和底层HDFS的交互，存储数据到HDFS
负责Region变大以后的拆分
负责Storefile的合并工作
HDFS
HDFS为Hbase提供最终的底层数据存储服务，同时为Hbase提供高可用（Hlog存储在HDFS）的支持，具体功能概括如下：
提供元数据和表数据的底层分布式存储服务
数据多副本，保证的高可靠和高可用性
3.2 Hive和Hbase区别
Apache Hive是一个构建在Hadoop基础设施之上的数据仓库。通过Hive可以使用HQL语言查询存放在HDFS上的数据。HQL是一种类SQL语言，这种语言最终被转化为Map/Reduce。虽然Hive提供了SQL查询功能，但是Hive不能够进行交互查询，因为它只能够在Haoop上批量的执行Hadoop。
Apache HBase是一种Key/Value系统，它运行在HDFS之上。和Hive不一样，Hbase的能够在它的数据库上实时运行，而不是运行MapReduce任务。Hive被分区为表格，表格又被进一步分割为列簇。列簇必须使用schema定义，列簇将某一类型列集合起来（列不要求schema定义）。例如，“message”列簇可能包含：“to”, ”from” “date”, “subject”, 和”body”. 每一个 key/value对在Hbase中被定义为一个cell，每一个key由row-key，列簇、列和时间戳。在Hbase中，行是key/value映射的集合，这个映射通过row-key来唯一标识。Hbase利用Hadoop的基础设施，可以利用通用的设备进行水平的扩展。
Hive帮助熟悉SQL的人运行MapReduce任务。因为它是JDBC兼容的，同时，它也能够和现存的SQL工具整合在一起。运行Hive查询会花费很长时间，因为它会默认遍历表中所有的数据。虽然有这样的缺点，一次遍历的数据量可以通过Hive的分区机制来控制。分区允许在数据集上运行过滤查询，这些数据集存储在不同的文件夹内，查询的时候只遍历指定文件夹（分区）中的数据。这种机制可以用来，例如，只处理在某一个时间范围内的文件，只要这些文件名中包括了时间格式。
HBase通过存储key/value来工作。它支持四种主要的操作：增加或者更新行，查看一个范围内的cell，获取指定的行，删除指定的行、列或者是列的版本。版本信息用来获取历史数据（每一行的历史数据可以被删除，然后通过Hbase compactions就可以释放出空间）。虽然HBase包括表格，但是schema仅仅被表格和列簇所要求，列不需要schema。Hbase的表格包括增加/计数功能。
Hive目前不支持更新操作。另外，由于hive在hadoop上运行批量操作，它需要花费很长的时间，通常是几分钟到几个小时才可以获取到查询的结果。Hive必须提供预先定义好的schema将文件和目录映射到列，并且Hive与ACID不兼容。
HBase查询是通过特定的语言来编写的，这种语言需要重新学习。类SQL的功能可以通过Apache Phonenix实现，但这是以必须提供schema为代价的。另外，Hbase也并不是兼容所有的ACID特性，虽然它支持某些特性。最后但不是最重要的--为了运行Hbase，Zookeeper是必须的，zookeeper是一个用来进行分布式协调的服务，这些服务包括配置服务，维护元信息和命名空间服务。
Hive适合用来对一段时间内的数据进行分析查询，例如，用来计算趋势或者网站的日志。Hive不应该用来进行实时的查询。因为它需要很长时间才可以返回结果。
Hbase非常适合用来进行大数据的实时查询。Facebook用Hbase进行消息和实时的分析。它也可以用来统计Facebook的连接数。
Hive和Hbase是两种基于Hadoop的不同技术--Hive是一种类SQL的引擎，并且运行MapReduce任务，Hbase是一种在Hadoop之上的NoSQL 的Key/vale数据库。当然，这两种工具是可以同时使用的。就像用Google来搜索，用FaceBook进行社交一样，Hive可以用来进行统计查询，HBase可以用来进行实时查询，数据也可以从Hive写到Hbase，设置再从Hbase写回Hive。
总结下：Hive提供了与HBase的集成，使得能够在HBase表上使用HQL语句进行查询和插入操作以及进行Join和Union等复杂查询。并构建低延时的数据仓库。Hbase，其实作为一种数据库。
1. 将ETL操作的数据存入HBase
2. HBase作为Hive的数据源
3. 构建低延时的数据仓库
结语：最后以之前给某个客户做的大数据架构作为结尾（数据计算处理和数据存储两块的顺序，不是完全的左右结构，数据计算处理，有时会做ETL中T的工作中；另外，Hbase即可放在数据存储层，也可放在数据共享层），其实BAT、京东、头条以及滴滴等等，在数据采集、数据计算和数据存储方面，都有自己经过优化和改良的工具，但万变不离其宗，逻辑架构大同小异。接下来，我会在云计算和AI方面，再做一些解决方案层面的汇总和分析，谢谢大家。
