- 关系型数据库拓展的瓶颈
- cap理论
- 想了解数仓需要哪些能力以及这些能力靠哪些大数据技术实现。
大数据是具有4V,即Volume、Velocity、Variety、Veracity特征的数据集合,用中文简单描述就是大、快、多、真。
- Volume——生成和存储的数据量大
随着技术的发展,人们收集信息的能力越来越强,随之获取的数据量也呈爆炸式增长。例如百度每日处理的数据量达上百PB,总的数据量规模已经到达EP级。- Velocity——数据产生和处理速度快
指的是销售、交易、计量等人们关心的事件发生的频率。例如,2015年双十一当天,支付宝的峰值交易数为每秒8.59万笔。- Variety——数据源和数据种类多样
现在要处理的数据源包括各种各样的关系数据库、NoSQL、平面文件、XML文件、机器日志、图片、音视频流等,而且每天都会产生新的数据格式和数据源。- Veracity——数据的真实性和高质量
诸如软硬件异常、应用系统bug、人为错误等都会使数据不正确。大数据处理中应该分析并过滤掉这些有偏差的、伪造的、异常的部分,防止脏数据损害到数据分析结果的准确性。
hadoop处理数据的能力
关系数据库主要的问题是不好扩展,或者说扩展的成本非常高,因此面对当前4Vs的大数据问题时显得能力不足。在大多数情况下,Hadoop生态圈的工具能够比关系数据库处理更多的数据,因为数据和计算都是分布式的。
通过MapReduce时的那个例子进行说明:
在一个10TB的Web日志文件中,找出单词‘ERROR’的个数。解决这个问题最直接的方法就是查找日志文件中的每个单词,并对单词‘ERROR’的出现进行计数。做这样的计算会将整个数据集读入内存。
假设系统从磁盘到内存的数据传输速率为每秒100MB,这意味着在单一计算机上要将10TB数据读入内存需要27.7个小时。如果我们把数据分散到10台计算机上,每台计算机只需要处理1TB的数据。它们彼此独立,可以对自己的数据分片中出现的‘ERROR’计数,最后再将每台计算机的计数相加。
在此场景下,每台计算机需要2.7个小时读取1TB数据。因为所有计算机并行工作,所以总的时间也近似是2.7个小时。
这种方式即为线性扩展——可以通过增加机器数量来减少处理数据花费的时间。以此类推,使用100台计算机,做这个任务只需0.27个小时。
Hadoop背后的核心观点是:如果一个计算可以被分成小的部分,每一部分工作在独立的数据子集上,并且计算的全局结果是独立部分结果的联合,那么此计算就可以分布在多台计算机中并行执行。
可扩展性就是能够通过增加资源来提升容量,并保持系统性能的能力。可扩展性可分为向上扩展(Scale up)和向外扩展(Scale out)。
- 向上扩展有时也称为垂直扩展,比如通过增加CPU、内存、磁盘等方式提高处理能力。
- 向外扩展有时也称为横向扩展或水平扩展,由多台廉价的通用服务器实现分布式计算,分担某一应用的负载。关系数据库的向外扩展主要有Shared Disk和Shared Nothing两种实现方式。
- Shared Disk的各个处理单元使用自己的私有CPU和内存,共享磁盘系统,典型的代表是Oracle RAC。
- Shared Nothing的各个处理单元都有自己私有的CPU、内存和硬盘,不存在共享资源,各处理单元之间通过协议通信,并行处理和扩展能力更好,MySQL Fabric采用的就是Shared Nothing架构。
关系型数据拓展的瓶颈在哪里?
Oracle RAC是Oracle的集群解决方案。
其架构的最大特点是共享存储架构(Shareddisk),整个RAC集群建立在一个共享的存储设备之上,节点之间采用高速网络互连。Oracle RAC提供了较好的高可用特性,比如负载均衡和透明应用切换。
- RAC的扩展能力有限,32个节点的RAC已算非常庞大了。随着节点数的不断增加,节点间通信的成本也会随之增加,当到达某个限度时,增加节点不会再带来性能上的提高,甚至可能造成性能下降。
- RAC的另外一个问题是,整个集群都依赖于底层的共享存储,因此共享存储的I/O能力和可用性决定了整个集群可以提供的能力。
2. MySQL Fabric(主要实现了HA和分片)
- HA:ing
- 分片:
当单个MySQL服务器(或HA组)的写性能达到极限时,可以使用Fabric把数据分布到多个MySQL服务器。
分片键与分片映射:管理员指定每个表上的哪些列作为分片键,MySQL Fabric使用分片键计算(range或hash)一个表的特定行应该存在于哪个分片上。单一事务可以访问一个分片中的所有数据(ing)。
传统数据库难以拓展的根本原因:
数据库的可扩展性存在很大的局限。虽然这种情况随着分布式数据库技术的出现而有所缓解,但还是无法像Hadoop一样轻松在上千个节点上进行分布式计算。究其原因,就不得不提到CAP理论。
CAP理论指的是:任何一个分布式计算系统都不能同时保证如下三点:
- Consistency(一致性):所有节点上的数据时刻保持同步。
- Availability(可用性):每个请求都能接收到一个响应,无论响应成功或失败。
- Partition tolerance(分区容错性):系统应该能持续提供服务,无论网络中的任何分区失效。
高可用、数据一致是很多系统设计的目标,但是分区又是不可避免的。
- CA without P:如果不要求P(不允许分区,即单机情况,不存在数据同步的问题),则C(强一致性)和 A(可用性)是可以保证的。传统关系型数据库大都是这种模式。但涉及到大数据模式下,分区是一定存在的。
- CP without A:如果不要求A(高可用),相当于每个请求都需要在节点之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式,当处理大数据量时,这种性能会很低。
- AP wihtout C:要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。或者我们保证弱一致性,这样全局数据也会一样,虽然有延迟。
当数据仓库应用的规模和数据量大到一定程度,关系数据库已经不再适用,此时Hadoop是开发数据仓库项目的可选方案之一。
如下图,一个常规数据仓库由两类存储和6个主要功能模块组成。下面我们就介绍与这8个部分对应的Hadoop相关组件或产品。
- RDS是原始数据存储,其数据是从操作型系统抽取而来。它有两个作用,一是充当操作型系统和数据仓库之间的过渡区,二是作为细节数据查询的数据源。
- TDS是转换后的数据存储,也就是数据仓库,用于后续的多维分析或即席查询。
这两类数据(只是)逻辑上分开,物理上可以通过在Hive上建立两个不同的数据库来实现,最终所有数据都被分布存储到HDFS上。
这里的抽取过程指的是把数据从操作型数据源抽取到RDS的过程,这个过程可能会有一些数据集成的操作,但不会做数据转换、清洗、格式化等工作。
Hadoop生态圈中的主要数据摄取工具是Sqoop和Flume。
Sqoop被设计成支持在关系数据库和Hadoop之间传输数据,而Flume被设计成基于流的数据捕获,主要是从日志文件中获取数据。使用这两个工具可以完成数据仓库的抽取。
如果数据源是普通的文本和CSV文件,抽取过程将更加简单,只需用操作系统的scp或ftp命令将文件拉取到Hadoop集群的任一节点,然后使用HDFS的put命令将已在本地的文件上传到HDFS,或者使用Hive的load data将文件装载进表里就可以了。
这里flinkx对文本和csv提供了抽取的能力,简化了数据摄取对工具使用的复杂度。
转换与装载过程是将数据从RDS迁移到TDS的过程,期间会对数据进行一系列的转换和处理。经过了数据抽取步骤,此时数据已经在Hive表中了,因此Hive可以用于转换和装载。
ETL过程自动化是数据仓库成功的重要衡量标准,也是系统易用性的关键。
Hadoop生态圈中过程管理和自动化调度工具有:
- Falcon是数据治理工具,能让用户建立定义好的ETL流水线。
- Oozie是Hadoop的工作流调度系统,可以使用它将ETL过程封装进工作流自动执行。
其他可参考:
大数据调度平台分类大对比(Oozie/Azkaban/AirFlow/XXL-Job/DolphinScheduler)
数据目录存储的是数据仓库的元数据,主要是描述数据属性的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
数据目录管理工具:
HCatalog 提供了一个统一的元数据服务,允许不同的工具如 Pig、MapReduce 等通过 HCatalog 直接访问存储在 HDFS 上的底层文件。
HCatalog 是 Apache 的顶级项目,从 Hive0.11.0 开始,HCatalog 已经合并到 Hive 中。也就是说,如果是通过 binary 安装的 Hive0.11.0 之后的版本,HCatalog 已经自动安装了,不需要再单独部署。
因为 HCatalog 使用的就是 Hive 的元数据,因此对于 Hive 用户来说,不需要使用额外的工具来访问元数据。
其他可参考:六种元数据管理工具。
查询引擎和SQL层主要的职责是查询和分析数据仓库里的数据。
Hadoop生态圈中的主要SQL查询引擎有
- 基于MapReduce的Hive、
- 基于RDD的SparkSQL
- Cloudera公司的Impala。
Hive可以在四种主流计算框架的三种,分别是Tez、MapReduce和Spark(还有一种是Storm)上执行类SQL查询。
数据分析的结果最终要以业务语言和形象化的方式展现给用户。数据仓库的最终用户界面通常是一个BI仪表盘或类似的一个数据可视化工具提供的浏览器页面。
Hadoop生态圈中比较知名的数据可视化工具是Hue和Zeppelin。
https://gethue.com/
参考:
《Hadoop构建数据仓库实战》