【分享】大数据技术原理与应用

大数据是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。大数据技术的战略意义不在于掌握庞大的数据信息，而在于对这些含有意义的数据进行专业化处理。换言之，如果把大数据比作一种产业，那么这种产业实现盈利的关键，在于提高对数据的“加工能力”，通过“加工”实现数据的“增值”与大家分享来自在mooc上自学的课程，目前进度一半多。包括sql、hive、hbase、hdoop等。

5大数据技术原理与应用

• 大数据概述
  • 时代
    • 第三次信息浪潮：云计算、物联网、大数据 2010
      • 第一次信息浪潮：个人计算机 1980 第二次信息浪潮：互联网 1995
      • 技术支撑
        • 存储
          • 容量增加
            • 个人、企业数据越来越多
          • CPU处理能力提升
            • 4c 8c 16c…
          • 网络带宽不断增加
            • 2M 10M 100M
        • 计算
        • 网络
      • 数据产生的方式
        • 运营式系统阶段
        • 用户原创内容阶段
        • 感知式系统阶段
  • 概念、影响
    • 特性：4V
      • volume 大量化
        • 数据摩尔定律
        • 数据类型：10%结构化数据、90%非结构化数据
          • 结构化： 非结构化：图像图形
      • variety 多样化
        • web 1.0：文本、图像、视频
        • web 2.0：查询日志/点击流、wiki、twitter
        • 企业应用：email、文档文件；应用日志；交易记录
        • 科学研究：基因组；LHC加入器；地球与空间探索
      • velocity 快速化
        • eg:Google Dremel
          • 相关分析 http://www.yankay.com/google-dremel-rationale/
      • value 价值密度低
        • 商业价值高
    • 影响
      • 科学：第四范式，实验-理论-计算-数据
        • jim gray提出，第三个图灵获得者
      • 思维模式改变：全样而非抽样；效率而非精确；相关而非因果。
  • 应用
    • eg：拍电视剧、google预测流感
  • 关键技术&模式
    • 技术层面
      • 基础架构支持
        • 云计算平台
        • 云存储
        • 虚拟化
        • 网络技术
        • 资源监控技术
      • 数据采集
        • 利用ETL工具将分布的、异构数据源中的数据如关系数据、平面数据文件等，抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础； 或者也可以把实时采集的数据作为流计算系统的输入，进行实时处理分析。
        • 数据总线
        • ETL工具
      • *数据存储和管理
        • 利用分布式文件系统、数据仓库、关系数据库、NoSQL数据库、云数据库等，实现对结构化、半结构化和非结构化海量数据的存储和管理。
        • 分布式存储
          • 解决海量数据存储问题
          • 分布式数据库big table
          • 分布式文件系统GFS
      • *数据处理与分析
        • 分布式处理
          • 分布式并行处理技术MapReduce
      • 数据隐私与安全
    • 2大核心技术
      • 分布式存储
        • GFS\HDFSBigTable\HBaseNoSQL（键值、列族、图形、文档数据库）NewSQL（如：SQL Azure）
      • 分布式处理
        • MapReduce
    • 计算模式
      • 批处理计算
        • 批量处理
        • MapReduce
        • Spark
      • 流计算
        • 实时处理
        • S4
        • Storm
        • Flume
      • 图计算
        • Pregel (google )
      • 查询分析计算
        • Dremel(google )
        • Hive
        • Cassandra
        • Impala
    • 数据库
      • RDBMS 关系型数据库
        • MySQL、Oracle、DB2、SQL sever…
        • 关系型数据库 全是表
      • NoSQL 非关系型数据库
  • 大数据、云计算、物联网关系
    • 云计算
      • 关键技术
        • 虚拟化
          • Linux：hadoop
          • Windows：虚拟机
          • 硬件
        • 分布式存储
        • 分布式计算
        • 多租户
      • 3种模式
        • 公有云
          • eg:百度云
        • 私有云
          • eg 电信、联通
        • 混合云
      • 3种云服务
        • Iaas
          • aws:EC2；salesforce
        • Paas
          • sina app engine
        • Saas
      • 数据中心
        • 冷、电力丰富；地质结构稳定；凉爽舒适。
      • 应用
        • 政务云、教育云、医疗云、中小企业云
    • 物联网
      • 概念
        • 应用层
        • 处理层
        • 网络层
        • 感知层
      • 技术
        • 识别与感知（二维码、RFID等）
        • 网络与通信
        • 数据挖掘与融合
    • 联系
      • 云计算为大数据提供了技术基础 大数据为云计算提供用武之地
      • 云计算为物联网提供海量数据存储能力 物联网为云计算技术提供了广阔的应用空间
      • 物联网是大数据的重要来源 大数据技术为物联网数据分析提供支撑
• 大数据处理架构Hadoop
  • 概述
    • 简介
      • Hadoop是Apache软件基金会旗下的一个开源分布式计算平台，为用户提供了系统底层细节透明的分布式基础架构。
      • 是基于Java语言开发的，具有很好的跨平台特性，并且可以部署在廉价的计算机集群中
      • 被公认为行业大数据标准开源软件，在分布式环境下提供了海量数据的处理能力
      • 2大核心
        • HDFS：Hadoop Distributed File System
        • MapReduce
    • 发展简史
      • 源自始于2002年的Apache Nutch项目
        • Hadoop最初是由Apache Lucene项目的创始人Doug Cutting开发的文本搜索库。Hadoop源自始于2002年的Apache Nutch项目——一个开源的网络搜索引擎并且也是Lucene项目的一部分. • 在2004年，Nutch项目也模仿GFS开发了自己的分布式文件系统NDFS（Nutch Distributed File System），也就是HDFS的前身 • 2004年，谷歌公司又发表了另一篇具有深远影响的论文，阐述了MapReduce分布式编程思想 • 2005年，Nutch开源实现了谷歌的MapReduce • 到了2006年2月，Nutch中的NDFS和MapReduce开始独立出来，成为Lucene项目的一个子项目，称为Hadoop，同时，Doug Cutting加盟雅虎 • 2008年1月，Hadoop正式成为Apache顶级项目，Hadoop也逐渐开始被雅虎之外的其他公司使用 • 2008年4月，Hadoop打破世界纪录，成为最快排序1TB数据的系统，它采用一个由910个节点构成的集群进行运算，排序时间只用了209秒 •在2009年5月，Hadoop更是把1TB数据排序时间缩短到62秒。Hadoop从此名声大震，迅速发展成为大数据时代最具影响力的开源分布式开发平台，并成为事实上的大数据处理标准.
    • 特性
      • 高可靠性
      • 高效性
      • 高可扩展性
      • 高容错性
      • 成本低
      • 运行在Linux平台上
      • 支持多种编程语言
    • 应用现状
      • 互联网领域是其应用的主阵地
        • • 2007年，雅虎在Sunnyvale总部建立了M45——一个包含了4000个处理器和1.5PB容量的Hadoop集群系统 • Facebook作为全球知名的社交网站，Hadoop是非常理想的选择，Facebook主要将Hadoop平台用于日志处理、推荐系统和数据仓库等方面 • 国内采用Hadoop的公司主要有百度、淘宝、网易、华为、中国移动等，其中，淘宝的Hadoop集群比较大
    • Apache Hadoop版本演变
      • Hadoop 1.0
        • 0.20.x
          • 最后演化成1.0.x
        • 0.21.x
        • 0.22.x
      • Hadoop 2.0
        • •第二代Hadoop包含2个版本，分别是0.23.x和2.x，它们完全不同于Hadoop 1.0，是一套全新的架构，均包含HDFS Federation和YARN两个系统，相比于0.23.x，2.x 增加了NameNode HA和Wire-compatibility两个重大特性
        • 0.23.x
        • 2.x
    • Hadoop各种版本
      • 选择 Hadoop版本的考虑因素： •是否开源（即是否免费） •是否有稳定版 •是否经实践检验 •是否有强大的社区支持
      • Apache Hadoop
      • Hortonworks
      • Cloudera（CDH：Cloudera Distribution Hadoop）
      • MapR
  • 包括
    • HDFS 分布式文件系统 MapReduce 分布式并行编程模型 YARN 资源管理和调度器 Tez 运行在YARN之上的下一代Hadoop查询处理框架 Hive Hadoop上的数据仓库 HBase Hadoop上的非关系型的分布式数据库 Pig 一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin Sqoop 用于在Hadoop与传统数据库之间进行数据传递 Oozie Hadoop上的工作流管理系统 Zookeeper 提供分布式协调一致性服务 Storm 流计算框架 Flume 一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统 Ambari Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控 Kafka 一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据 Spark 类似于Hadoop MapReduce的通用并行框架
    • HDFS：存储数据
      • Hadoop Distributed File System 分布式文件系统
    • MapReduce：处理数据
    • Hbase：分布式数据库
  • 项目结构
    • YARN 资源管理和调度器
    • Tez 运行在YARN之上的下一代Hadoop查询处理框架
    • HBase Hadoop上的非关系型的分布式数据库
    • Pig 一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin
    • Sqoop 用于在Hadoop与传统数据库之间进行数据传递
    • Oozie Hadoop上的工作流管理系统
    • Zookeeper 提供分布式协调一致性服务
    • Storm 流计算框架
    • Flume 一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统
    • Ambari Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控
    • Kafka 一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据
    • Spark 类似于Hadoop MapReduce的通用并行框架
  • 安装与使用
  • 集群的安装与使用
• 分布式文件系统HDFS
  • 解决分布式存储问题
  • 简介
    • 集群
      • HDFS把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群。
    • 物理结构
      • 分布式文件系统在物理结构上是由计算机集群中的多个节点构成的.
      • 主节点Master Node/名称节点NameNode
      • 从节点Slave Node/数据节点DataNode
    • 目标
      • 兼容廉价的硬件设备
      • 流数据读写
      • 大数据集
      • 简单的文件模型
      • 强大的跨平台兼容性
    • 局限性
      • 不适合低延迟数据访问
      • 无法高效存储大量小文件
      • 不支持多用户写入及任意修改文件
  • 概念
    • 块
      • HDFS默认一个块64MB，一个文件被分成多个块，以块作为存储单位 块的大小远远大于普通文件系统，可以最小化寻址开销。
      • 大小
        • 一个块64MB
          • why64兆? 支持大规模存储。 降低分布式节点的寻址开销。 是不是越大越好？ MR以块为单位处理数据，如果块过大，会导致MapReduce就一两个任务在执行，牺牲的MR并行度，没能体现分布式并行处理效果。
      • 优点
        • 支持大规模文件存储
          • 文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上。 因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。
        • 简化系统设计
          • 首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块； 其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。
        • 适合数据备份
          • 每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性
    • 2大组件
      • 主节点/名称节点
        • 相当于一个数据目录。 存储元数据； 元数据保存在内存中； 保存文件,block、DataNode之间映射关系。 名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog.
        • 数据结构
          • Fslmage：用于维护文件系统树以及文件树中所有的文件和文件夹的元数据。
            • •FsImage文件包含文件系统中所有目录和文件inode的序列化形式。 每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据。 •FsImage文件没有记录块存储在哪个数据节点。而是由名称节点把这些映射保留在内存中，当数据节点加入HDFS集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告知操作，以确保名称节点的块映射是最新的。
          • EditLog：记录了所有针对文件的创建、删除、重命名等操作。
        • 第二名称节点SecondaryNameNode
          • 名称节点的冷备份
          • 对Editlog处理
      • 从节点/数据节点
        • 存储实际数据。（文件内容） 文件内容存储在磁盘里； 维护了blockID到DataNode本地文件的映射关系。 数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。
        • 存
        • 取
  • 体系结构
    • 命名空间
      • 目录
      • 文件
      • 块
    • 通信协议
      • 构建在TCP/IP协议基础之上的
        • 客户端通过一个可配置的端口向名称节点主动发起TCP连接，并使用客户端协议与 名称节点进行交互 • 名称节点和数据节点之间则使用数据节点协议进行交互 • 客户端与数据节点的交互是通过RPC（Remote Procedure Call）来实现的。在设 计上，名称节点不会主动发起RPC，而是响应来自客户端和数据节点的RPC请求。
    • 客户端
      • 客户端是用户操作HDFS最常用的方式，HDFS在部署时都提供了客户端
        • HDFS客户端是一个库，暴露了HDFS文件系统接口，这些接口隐藏了HDFS实现中的 大部分复杂性 • 严格来说，客户端并不算是HDFS的一部分 • 客户端可以支持打开、读取、写入等常见的操作，并且提供了类似Shell的命令行 方式来访问HDFS中的数据 • 此外，HDFS也提供了Java API，作为应用程序访问文件系统的客户端编程接口
    • 局限性
      • 命名空间限制
        • 名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制
      • 性能瓶颈
        • 整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。
      • 隔离问题
        • 由于集群中只有一个名称节点，只有一个命名空间，因此，无法对不同应用程序进行隔离。
      • 集群的可用性
        • 一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。
  • 存储原理
    • 冗余数据保存
      • 方式：多副本
      • 具体：通常一个数据块的多个副本会被分布到不同的数据节点上。
      • 多副本的优点
        • 加快数据传输速度
        • 容易检查数据错误
        • 保证数据可靠性
    • 数据存取策略
      • 存放
        • 第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点。 第二个副本：放置在与第一个副本不同的机架的节点上。 第三个副本：与第一个副本相同机架的其他节点上。 更多副本：随机节点。
      • 读取
        • 就近读取。HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID.
          • 当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包 含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据.
    • 数据错误与恢复
      • 名称节点出错
        • 备份机制，第二名称节点
          • 名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage 和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。 因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当 名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和 Editlog数据进行恢复。
      • 数据节点出错
        • 每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。
          • •每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态 •当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求 •这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子 •名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本 •HDFS和其它分布式文件系统的最大区别就是可以 调整冗余数据的位置 。
      • 数据出错
        • 网络传输和磁盘错误等因素，都会造成数据错误。客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据。
          • •客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据 •在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面 •当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块
  • 读写过程
    • 读数据的过程
    • 写数据的过程
  • 实践
• 分布式数据库HBase
  • 概述
    • 从BigTable说起
      • BigTable是一个分布式存储系统
        • 处理海量数据：用谷歌MapReduce分布式并行计算模型
        • 底层数据存储：谷歌分布式文件系统GFS
        • 协同服务管理：Chubby
        • 特点：广泛应用性、可扩展性、高性能和高可用性等。可扩展到PB级别的数据和上千台机器。
        • 应用：谷歌的许多项目都存储在BigTable中，包括搜索、地图、财经、打印、社交网站Orkut、视频共享网站YouTube和博客网站Blogger等
      • 起初用于解决典型的互联网搜索问题
        • 建立互联网索引
          • 1 设计一个网页爬虫。爬虫持续不断地抓取新页面，这些页面每页一行地存储到BigTable里
          • 2 运行MapReduce，生成索引，为网络搜索应用做准备
        • 搜索互联网
          • 3 用户发起网络搜索请求
          • 4 网络搜索应用查询建立好的索引，从BigTable得到网页
          • 5 搜索结果提交给用户
    • HBase简介
      • 特点
        • 高可用
        • 高性能
        • 面向列
        • 可伸缩
      • 主要存储
        • 非结构化和半结构化的松散数据。
      • 目标
        • 处理非常庞大的表。通过水平扩展方式，利用廉价计算机集群处理 由超过10亿行数据和数百万列元素组成的 数据表。
      • why?关系数据库已流行很多年，且Hadoop已有HDFS、MapReduce，为什么需要HBase?
        • Hadoop无法满足大规模数据 实时处理应用 的需求。Hadoop能很好解决大规模数据的离线批量处理问题，但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制。
        • HDFS面向批量访问模式，不是随机访问模式
        • [传统的通用关系型数据库]无法应对在数据规模剧增时,导致的系统扩展性和性能问题（分库分表也不能很好解决）
        • [传统关系数据库]在数据结构变化时一般需要停机维护；空列浪费存储空间
        • (HBase已经成功应用于：互联网服务领域和传统行业的众多 在线式数据分析处理系统中)
      • HBase、BigTable底层技术对比
        • 文件存储系统
          • HBase：HDFSBigTable：GFS
        • 海量数据处理
          • HBase：Hadoop MapReduceBigTable：MapReduce
        • 协同服务管理
          • HBase：ZookeeperBigTable：Chubby
    • HBase与传统关系数据库的对比分析
      • 数据类型
        • ·关系数据库：采用关系模型，具有丰富的数据类型和存储方式·HBase：采用数据模型（更加简单），它把数据存储为未经解释的字符串
      • 操作
        • ·关系数据库：操作丰富，会涉及复杂的多表连接·HBase：只有简单的插入、查询、删除、清空等，不存在复杂的表与表之间的关系，因为在设计上就避免了复杂的表和表之间的关系
      • 存储
        • ·关系数据库：基于行模式存储·HBase：基于列存储。每个列族都由几个文件保存，不同列族的文件是分离的
      • 索引
        • ·关系数据库：通常可针对不同列 构建复杂的多个索引，以提高数据访问性能。·HBase：只有一个索引——行键。通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来
      • 维护
        • ·关系数据库：更新操作时，会用[最新的当前值]去替换[记录中原来的旧值]，旧值被覆盖后就不会存在。·HBase：更新操作时，不删除数据旧的版本，而是生成一个新的版本，保留旧版本。
      • 可伸缩性
        • ·关系数据库：很难实现横向扩展，纵向扩展的空间也比较有限。·HBase、BigTable这些分布式数据库：为实现灵活的水平扩展而开发的，能轻易通过在集群中 增加或者减少硬件数量 来实现性能的伸缩
          • 纵向扩展？ 如，增加CPU，单核→双核，双核→四核，增加内存，增加磁盘
  • 访问接口
    • Native Java API
      • 特点：最常规和高效的访问方式
      • 场合：适合Hadoop MapReduce作业并行批处理HBase表数据
    • HBase Shell
      • 特点：HBase的命令行工具，最简单的接口
      • 场合：适合HBase管理使用
    • Thrift Gateway
      • 特点：利用Thrift序列化技术，支持C++、PHP、Python等多种语言
      • 场合：适合其他异构系统在线访问HBase表数据
    • REST Gateway
      • 特点：解除语言限制
      • 场合：支持REST风格的Http API访问HBase
    • Pig
      • 特点：使用[Pig Latin流式编程语言]来处理HBase中的数据
      • 场合：数据统计
    • Hive
      • 特点：简单
      • 场合：当需要以类似SQL语言方式来访问HBase时
  • 数据模型
    • 概述
      • HBase是一个稀疏、多维度、排序的映射表，这张表的索引：行键、列族、列限定符、时间戳
      • 每个值：是一个未经解释的字符串，没有数据类型
      • 用户在表中存储数据，每一行都有一个可排序的行键、任意多的列
      • 列族支持动态扩展。
        • ·可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型。
        • ·所有列均以字符串形式存储，用户需要自行进行数据类型转换。
      • HBase中执行更新操作时，并不会删除数据旧版本，而是生成一个新版本，旧版本仍保留（这是和HDFS 只允许追加不允许修改 的特性相关的）
    • 概念
      • 表
        • HBase采用表来组织数据，表由行、列组成，列划分为若干个列族
      • 行
        • 每个HBase表都由若干行组成，每个行由行键（row key）来标识。
      • 列族
        • 有点像列上合并单元格后的总标题，总类目
        • 一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元
      • 列限定符/列
        • 像是每列类目，标题blabla
        • 列族里的数据通过列限定符（或列）来定位
      • 单元格
        • 具体存数据的地方。
          • 在HBase表中，通过行、列族、列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]
      • 时间戳
        • 以时间为维度，存单元格的每版内容
        • 每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引
    • 坐标
      • “四维坐标”，即[行键, 列族, 列限定符, 时间戳]
    • 概念视图
    • 物理视图
    • 面向列的存储
      • 数据压缩率高
  • 实现原理
    • HBase功能组件
      • • 不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信 息后，直接从Region服务器上读取数据 • 不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户 端甚至从来不和Master通信，这种设计方式使得Master负载很小
      • 库函数
        • 链接到每个客户端
      • Master主服务器（1个）
        • 负责管理、维护HBase表的分区信息
        • 维护Region服务器列表
        • 分配Region
        • 负载均衡
        • 整个集群中，有哪些Region服务器在工作
      • Region服务器（许多个）
        • 负责存储不同Region。存储、维护分配给自己的Region，处理来自客户端的读写请求
    • 表和Region
      • 本只有一个Region，后来不断分裂
        • Region拆分操作非常快，接近瞬间。因为拆分之后的Region读取的仍然是原存储文件，到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件
      • Region大小
        • •每个Region默认大小：100MB-200MB（06年以前的硬件配置）
        • 每个Region最佳大小：建议1GB-2GB（13年以后的硬件配置）
        • •每个Region的最佳大小：取决于单台服务器的有效处理能力
      • •同一个Region不会被分拆到多个Region服务器
      • •每个Region服务器存储10-1000个Region
    • Region的定位
      • HBase设置三层结构来定位寻址 三级寻址：zookeeper文件→“-ROOT-表”→“.META.表”→“用户数据表" •为加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题。 •寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器。
      • Zookeeper文件
        • 记录了-ROOT-表的位置
      • 根数据表/-ROOT-表
        • 记录了.META.表的Region位置信息-ROOT-表只能有一个Region。通过-ROOT-表，就可以访问.META.表中的数据
      • 元数据表/.META.表
        • 记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息
  • 运行机制
    • HBase系统架构
      • 客户端
        • 包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程
      • Zookeeper服务器
        • 可帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题
        • 大量用于:分布式计算，提供配置维护、域名服务、分布式同步、组服务等。
      • Master
        • 管理表和Region
          • 管理用户对表的增加、删除、修改、查询等操作
          • 实现不同Region服务器之间的负载均衡
          • 在Region分裂或合并后，负责重新调整Region的分布
          • 对发生故障失效的Region服务器上的Region进行迁移
      • Region服务器
        • 是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求
    • Region服务器工作原理
      • 用户读写数据过程
        • 写
          • 被分配到相应Region服务器去执行
          • 首先被写入到MemStore和Hlog中
          • 只有当操作写入Hlog之后，commit()调用才会将其返回给客户端
        • 读
          • Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找
      • 刷新缓存
        • 系统会周期性地把[MemStore缓存里的内容]刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
        • 每次刷新都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件
        • 每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；
          • 如果发现更新，则先写入MemStore，再刷写StoreFile，最后删除旧的Hlog文件，开始为用户提供服务
      • 合并StoreFile
        • why？
          • 每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
        • 操作
          • 调用Store.compact()把多个合并成一个
          • 合并操作比较耗费资源，只有数量达到一个阈值才启动合并
    • Store工作原理
      • Store是Region服务器的核心
        • 多个StoreFile合并成一个
        • 单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region
    • HLog工作原理
      • 作用
        • 因分布式环境必须要考虑系统出错，故HBase采用HLog保证系统恢复
      • 工作原理
        • [HBase系统]为[每个Region服务器]配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）
        • 用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到[MemStore缓存内容对应的日志]已经写入磁盘，该缓存内容才能被刷写到磁盘
  • 应用方案
    • HBase实际应用中的性能优化方法
      • 行键（Row Key）
        • 行键是按字典序存储，因此，设计行键时，要充分利用这个排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块。
          • 举个例子：如果最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳 作为行键的一部分，由于是字典序排序，所以可以使用Long.MAX_VALUE - timestamp作为行键，这样能保证新写入的数据在读取时可以被快速命中。
      • InMemory
        • 创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放到Region服务器的缓存中，保证在读取的时候被cache命中。
      • Max Version
        • 创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。
      • Time To Live
        • 创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除，例如如果只需要存储最近2天的数据，那么可以设置setTimeToLive(2 * 24 * 60 * 60)。
    • HBase性能监视
      • Master-status(自带)
        • HBase Master默认基于Web的UI服务端口为60010，HBase region服务器默认基于Web的UI服务端口为60030.如果master运行在名为master.foo.com的主机中，mater的主页地址就是http://master.foo.com:60010，用户可以通过Web浏览器输入这个地址查看该页面。可以查看HBase集群的当前状态
      • Ganglia
        • UC Berkeley发起的一个开源集群监视项目，用于监控系统性能
      • OpenTSDB
        • Open time series data base 开发时间序列数据库
        • 可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的metrics并进行存储、索引以及服务，从而使得这些数据更容易让人理解，如web化，图形化等
      • Ambari
        • 是创建、管理、监视 Hadoop 的集群
    • 在HBase之上构建SQL引擎
      • why？在NoSQL数据存储HBase上提供SQL接口
        • NoSQL区别于关系型数据库的一点就是NoSQL不使用SQL作为查询语 言
        • 1.易使用。使用诸如SQL这样易于理解的语言，使人们能够更加轻松地使用HBase。
        • 2.减少编码。使用诸如SQL这样更高层次的语言来编写，减少了编写的代码量。
      • 方案
        • Hive整合HBase
          • Hive与HBase的整合功能从Hive0.6.0版本已经开始出现，利用两者对外的API接口互相通信，通信主要依靠hive_hbase-handler.jar工具包(Hive Storage Handlers)。由于HBase有一次比较大的版本变动，所以并不是每个版本的Hive都能和现有的HBase版本进行整合，所以在使用过程中特别注意的就是两者版本的一致性。
        • Phoenix
          • Phoenix由Salesforce.com开源，是构建在Apache HBase之上的一个SQL中间层，可以让开发者在HBase上执行SQL查询。
    • 构建HBase二级索引
      • 二级索引，又名辅助索引。
      • HBase只有一个针对行健的索引。访问HBase表中的行，只有3种方式：
        • 通过单个行健访问
        • 通过一个行健的区间来访问
        • 全表扫描
      • 使用其他产品为HBase行健提供索引功能
        • 原理：采用HBase0.92版本之后引入的Coprocessor特性
        • Coprocessor构建二级索引
          • 2个实现
            • endpoint
              • 相当于关系型数据库的存储过程
            • observer
              • 相当于触发器
          • 在插入数据时同步写入索引表
            • 优
              • 非侵入性：引擎构建在HBase之上，既没有对HBase进行任何改动，也不需要上层应用做任何妥协
            • 缺
              • 每插入一条数据需要向索引表插入数据，即耗时是双倍的，对HBase的集群的压力也是双倍的
        • Hindex二级索引（华为）
          • 华为公司开发的纯 Java 编写的HBase二级索引，兼容 Apache HBase 0.94.8。
          • 特性
            • 多个表索引
            • 多个列索引
            • 基于部分列值的索引
        • HBase+Redis
          • HBase+Redis
            • Coprocessor构建二级索引
            • Redis做客户端缓存
            • 将索引实时更新到Redis等KV系统中，定时从KV更新索引到HBase的索引表中
        • HBase+solr
          • Solr+HBase
            • Solr是一个高性能，采用Java5开发，基于Lucene的全文搜索服务器。同时对其进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文搜索引擎。
            • Solr保存索引
  • 编程实践
    • 安装与配置
    • 常用Shell命令
      • create：创建表
      • list：列出HBase中所有的表信息
      • put：向表、行、列指定的单元格添加数据
      • scan：浏览表的相关信息
      • get：通过表名、行、列、时间戳、时间范围和版本号来获得相应单元格的值
      • enable/disable：使表有效或无效
      • drop：删除表
    • 常用Java API及应用实例
• NoSQL数据库
  • not only sql
  • 简介
    • 特性
      • 灵活的可扩展性
      • 灵活的数据模型
      • 与云计算机密结合
  • 兴起原因
    • 关系数据库已经无法满足Web2.0的需求
      • 无法满足 海量数据 的管理需求
      • 无法满足 数据高并发 的需求
        • 动态数据没法提前生成一个静态网页让用户访问，只能是是根据用户请求来实时生成数据；实时生成的数据，对数据库的负载非常高；基本上用关系型数据库是没办法满足高并发需求。
      • 无法满足 高可扩展性和高可用性 的需求
    • 数据模型的局限性。“One size fits all”模式很难适用于截然不同的业务场景
      • 关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的
      • Hadoop就是针对数据分析
      • MongoDB、Redis等是针对在线业务，两者都抛弃了关系模型
    • Web2.0关系型数据库的关键特性（完善的事务机制、高效的查询机制）没有发挥。
      • Web2.0网站系统通常不要求严格的数据库事务
      • Web2.0并不要求严格的读写实时性
      • Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）
  • NoSQL与关系数据库的比较
    • 具体
      • 可维护性
        • 关系数据库
          • 复杂
            • 需要专门的数据库管理员(DBA)维护
        • NoSQL数据库
          • 复杂
            • 虽然没有DBMS复杂，也难以维护
      • 一致性
        • 关系数据库
          • 强一致性
            • 严格遵守事务ACID模型，可以保证事务强一致性
        • NoSQL数据库
          • 弱一致性
            • 放松了对事务ACID四性的要求，而是遵守BASE模型，只能保证最终一致性
      • 数据完整性
        • 关系数据库
          • 易实现
            • 比如通过主键或者非空约束来实现实体完整性，通过主键、外键来实现参照完整性，通过约束或者触发器来实现用户自定义完整性
        • NoSQL数据库
          • 很难实现
      • 数据库原理
        • 关系数据库
          • 完全支持
            • 完备的关系代数理论作为基础
        • NoSQL数据库
          • 部分支持
            • 缺乏理论基础
      • 数据规模
        • 关系数据库
          • 大
            • 很难实现横向扩展，纵向扩展的空间也比较有限，性能会随着数据规模的增大而降低
        • NoSQL数据库
          • 超大
            • 可很容易 通过添加更多设备来 支持更大规模数据
      • 数据库模式
        • 关系数据库
          • 固定
            • 需定义数据库模式，严格遵守数据定义和相关约束条件
        • NoSQL数据库
          • 灵活
            • 不存在数据库模式，可自由灵活定义并存储各种不同类型的数据
      • 查询效率
        • 关系数据库
          • 快
            • 借助于索引机制可以实现快速查询（包括记录查询和范围查询）
        • NoSQL数据库
          • 没有面向复杂查询的索引，虽然NoSQL可使用MapReduce来加速查询，但在复杂查询方面的性能仍然不如RDBMS
      • 扩展性
        • 关系数据库
          • 一般
            • 很难实现横向扩展，纵向扩展的空间也比较有限
        • NoSQL数据库
          • 好
            • 设计之初就充分考虑了横向扩展的需求，可以很容易通过添加廉价设备实现扩展
      • 可用性
        • 关系数据库
          • 好
            • 在任何时候都以保证数据一致性为优先目标，其次才是优化系统性能，随着数据规模的增大，RDBMS为了保证严格的一致性，只能提供相对较弱的可用性
        • NoSQL数据库
          • 很好
      • 标准化
        • 关系数据库
          • 是
            • RDBMS已经标准化（SQL）
        • NoSQL数据库
          • 否
            • NoSQL还没有行业标准，不同的NoSQL数据库都有自己的查询语言，很难规范应用程序接口
      • 技术支持
        • 关系数据库
          • 高
            • 经过几十年的发展，已经非常成熟，Oracle等大型厂商都可以提供很好的技术支持
        • NoSQL数据库
          • 低
            • 仍然处于起步阶段，还不成熟，缺乏有力的技术支持
    • 总结
      • 关系数据库
        • 优
          • 以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持
        • 劣
          • 可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等
        • 应用
          • 电信、银行 等领域的关键业务系统，需要保证强事务一致性
      • NoSQL数据库
        • 优
          • 可支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等
        • 劣
          • 缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等
        • 应用
          • 互联网企业；传统企业的非关键业务（比如数据分析）
  • 四大类型
    • 键值数据库
      • 产品
        • Redis、Memcached、Riak、SimpleDB、Chordless、Scalaris
      • 数据模型
        • 键 是一个字符串对象
        • 值 可以是任意类型的数据，比如整型、字符型、数组、列表、集合等
      • 应用
        • 涉及 频繁读写、拥有简单数据模型 的应用
        • 内容缓存 如会话、配置文件、参数、购物车等
        • 存储配置、用户数据信息 的移动应用
      • 优
        • 扩展性好，灵活性好，大量写操作时性能高
      • 缺
        • 无法存储结构化信息，条件查询效率较低
      • 不适用
        • 不是通过键而是通过值来查：键值数据库根本没有通过值查询的途径
        • 需要存储数据之间的关系：在键值数据库中，不能通过2个或2个以上的键来关联数据
        • 需要事务的支持：在一些键值数据库中，产生故障时，不可以回滚
      • 使用者
        • 百度云数据库（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Redis和Memcached）、StackOverFlow（Redis）、Instagram （Redis）Youtube（Memcached）、Wikipedia（Memcached）
    • 列族数据库
      • 产品
        • BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
      • 数据模型
        • 列族
      • 应用
        • 分布式数据存储与管理
        • 数据在地理上分布于多个数据中心的应用程序
        • 可以容忍副本中存在短期不一致情况的应用程序
        • 拥有动态字段的应用程序
        • 拥有潜在大量数据的应用程序，大到几百TB的数据
      • 优
        • 查找速度快，可扩展性强，容易进行分布式扩展，复杂性低
      • 缺
        • 功能较少，大都不支持强事务一致性
      • 不适用
        • 需要ACID事务支持的情形，Cassandra等产品就不适用
      • 使用者
        • Ebay（Cassandra）、Instagram（Cassandra）NASA（Cassandra）、Twitter（Cassandra and HBase）、Facebook（HBase）、Yahoo!（HBase）
    • 文档数据库
      • 产品
        • MongoDB、CouchDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit
      • 数据模型
        • 键/值值（value）是版本化的文档
      • 应用
        • 存储、索引并管理面向文档的数据或者类似的半结构化数据比如，用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序
      • 优
        • 性能好（高并发），灵活性高，复杂性低，数据结构灵活
        • 提供嵌入式文档功能，将经常查询的数据存储在同一个文档中
        • 既可以根据键来构建索引，也可以根据内容构建索引
      • 缺
        • 缺乏统一的查询语法
      • 不适用
        • 在不同的文档上添加事务。文档数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。
      • 使用者
        • 百度云数据库（MongoDB）、SAP （MongoDB）、Codecademy（MongoDB）、Foursquare （MongoDB）、NBC News （RavenDB）
    • 图形数据库
      • 产品
        • Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB
      • 数据模型
        • 图结构
      • 应用
        • 专门用于处理具有高度相互关联关系的数据，比较适合于 社交网络、模式识别、依赖分析、推荐系统以及路径寻找 等问题
      • 优
        • 灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱
      • 缺
        • 复杂性高，只能支持一定的数据规模
      • 使用者
        • Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）
  • 三大基石
    • CAP
      • Consistency
        • 一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据
      • Availability
        • 可用性，是指快速获取数据，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应；
      • Tolerance of Network Partition
        • 分区容忍性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。
    • BASE
      • Basically Available
        • 基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现
      • Soft state
        • “软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。
      • Eventual consistency
        • 二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。
        • 强一致性
          • 当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据
        • 弱一致性
          • 不能保证后续访问，读到的都是更新后的最新数据
          • 最终一致性 是弱一致性的一种特例，允许后续的访问操作可暂时读不到更新后的数据，但经过一段时间之后，必须最终读到更新后的数据。
            • 最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到最新的值。
    • 最终一致性
      • 类别
        • 因果一致性
          • 如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的最终一致性规则
        • “读己之所写”一致性
          • 可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值
        • 单调读一致性
          • 如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值
        • 会话一致性
          • 它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话
        • 单调写一致性
          • 系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了
      • 如何实现各种类型的一致性？
  • 从NoSQL到NewSQL数据库
    • 数据库发展
      • OldSQL
        • 事务型应用
      • NoSQL
        • 互联网应用
      • NewSQL
        • 分析性应用
    • NewSQL
      • 特性
        • 非常好的水平扩展性
        • 强一致性
        • 事务一致性
        • 支持SQL查询
        • 支持海量数据存储
      • eg
        • Amazon RDS
        • SQL Azure
  • 文档数据库MongoDB
    • 简介
      • -由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。-旨在为WEB应用提供可扩展的高性能数据存储解决方案。-将数据存储为一个文档，数据结构由键值(key=>value)对组成。-MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。
    • 特点
      • 提供了一个面向文档存储，操作起来比较简单、容易
      • 可设置任何属性的索引 来实现更快的排序
      • 有较好的水平可扩展性
      • 支持丰富的查询表达式，可轻易查询文档中内嵌的对象及数组
      • 可以实现替换完成的文档（数据）或者一些指定的数据字段
      • MongoDB中的Map/Reduce主要是用来对数据进行批量处理和聚合操作
      • 支持各种编程语言:RUBY，PYTHON，JAVA，C++，PHP，C#等语言
      • 安装简单
    • 概念
      • database
        • 数据库
          • 一个mongodb中可以建立多个数据库。
          • 默认数据库为"db"，该数据库存储在data目录中
          • 单个实例可以容纳多个独立的数据库，每一个都有自己的集合和权限，不同的数据库也放置在不同的文件中。
      • collection
        • 数据库表/集合
          • 集合就是 MongoDB 文档组，类似于 RDBMS 中的表格。
          • 存在于数据库中，没固定结构。可插入不同格式和类型的数据
      • document
        • 数据记录行/文档
          • 文档是一个键值(key-value)对(即BSON)。
          • 不需要设置相同的字段，并且相同的字段不需要相同的数据类型
      • field
        • 数据字段/域
      • index
        • 索引
      • primary key
        • 主键,MongoDB自动将_id字段设置为主键
    • 访问MongoDB
      • 使用 MongoDB shell访问MongoDB
      • 使用Java程序访问 MongoDB
• 云数据库
  • 概述
    • 背景
      • 云计算是云数据库兴起的基础
    • 概念
      • 部署和虚拟化在云计算环境中的数据库
    • 优点
      • 增强数据库的存储能力，消除人员、硬件、软件的重复配置，让软、硬件升级变得更加容易。
    • 特性
      • 动态可扩展
      • 高可用
      • 较低使用代价
      • 易用性
      • 高性能
      • 免维护
      • 安全
    • 云数据库是个性化数据存储需求的理想选择
      • 大企业：海量数据需求
      • 中小企业：低成本数据存储
      • 动态变化数据存储
    • 与其他数据库的关系
      • 云数据库没专属的数据模型，RDBMS、NoSQL的数据模型都有。
      • 云数据库并非一种全新的数据库技术，而只是 以服务的方式 提供数据库功能
      • 许多公司在开发云数据库时，后端数据库都是 直接使用现有的 各种关系数据库或NoSQL数据库产品
  • 产品
    • 概述
      • AWS
        • Dynamo、SimpleDB、RDS
      • GOOGLE
        • Google Cloud SQL
      • Microsoft
        • Microsoft SQL Azure
      • Oracle
        • Oracle Cloud
      • Yahoo！
        • PNUTS
      • Vertica
        • Analytic Database v3.0 for the Cloud
      • EnerpriseDB
        • Postgres Plus in the Cloud
      • 阿里
        • 阿里云RDS
      • 腾讯
        • 腾讯云数据库
    • AWS
      • RDS
        • 关系数据库
      • SimpleDB
        • 键值数据库
      • DynamoDB
        • NoSQL数据库
      • Redshift
        • 数据仓库
      • ElastiCache
        • 分布式内存缓存
    • GOOGLE
      • Google Cloud SQL
        • 基于MySQL的云数据库
    • Microsoft
      • SQL Azure
        • 属于关系型数据库
        • 支持存储过程
        • 支持大量数据类型
        • 支持云中的事务
          • 支持局部事务，但是不支持分布式事务
  • 系统架构
    • UMP：Unified MySQL Platform
    • 概述
      • 简介
        • 低成本&高性能的MySQL云数据库方案
      • 设计原则
        • 保持单一的系统对外入口，并为系统内部维护单一的资源池
        • 消除单点故障，保证服务的高可用性
          • SPOF：single point of failure 单点故障，指系统中一点失效，就会让整个系统无法运作的部件，换句话说，单点故障即会整体故障。 解决：一般可以透过 冗余 的方式增加多个相同机能的部件，只要这些部件没有同时失效，系统（或至少部分系统）仍可运作，这会让可靠度提高，不过也增加成本和某些设计难度。
        • 保证系统具有良好的可伸缩，能够动态地增加、删减计算与存储节点
        • 保证分配给用户的资源也是 弹性可伸缩的，资源之间相互隔离，确保应用和数据安全
    • 架构
      • 角色
        • Controller服务器
          • 管理。实现集群成员管理、元数据存储、MySQL实例管理、故障恢复、备份、迁移、扩容等功能
            • 运行了一组Mnesia分布式数据库服务。其中存储了各种系统元数据，eg:集群成员、用户的配置和状态信息，以及用户名到后端MySQL实例地址的映射关系（或称为“路由表”）等
            • 当其它服务器组件需要获取用户数据时，可以向Controller服务器发送请求获取数据
          • UMP系统中部署了多台Controller服务器，然后，由Zookeeper的分布式锁功能来帮助选出一个“总管”，负责各种系统任务的调度和监控
        • Proxy服务器
          • 提供访问MySQL数据库的服务
            • 可使用 已有的MySQL客户端 连接到 Proxy服务器，Proxy服务器通过用户名获取到 用户的认证信息、资源配额的限制(例如QPS、IOPS（I/O Per Second）、最大连接数等)，以及后台MySQL实例的地址，然后，用户的SQL查询请求会被转发到相应的MySQL实例上。
          • 功能
            • 数据路由、屏蔽MySQL实例故障、读写分离、分库分表、资源隔离、记录用户访问日志
        • Agent服务器
          • -部署在运行MySQL进程的机器上-来管理每台物理机上的MySQL实例。
          • 功能
            • 主从切换、创建、删除、备份、迁移，收集和分析MySQL进程的统计信息、慢查询日志（Slow Query Log）和bin-log
        • Web控制台
          • 提供系统管理界面
        • 日志分析服务器
          • 存储、分析 Proxy服务器传入的 用户访问日志，并支持实时查询 一段时间内的慢日志和统计报表
        • 信息统计服务器
          • 定期将[采集到的用户的连接数、QPS数值以及MySQL实例的进程状态]用RRDtool进行统计
            • 可在 Web界面上可视化展示统计结果
            • 也可把统计结果作为 今后实现弹性的资源分配、自动化的MySQL实例迁移 的依据
        • 愚公系统
          • 全量复制 结合bin-log分析 进行增量复制的工具
          • 可在不停机的情况下 动态扩容、缩容和迁移
      • 开源组件
        • Mnesia
          • Why Is the DBMS Called Mnesia? The original name was Amnesia. One of our bosses didn’t like the name. He said, 　　“You can’t possibly call it Amnesia—you can’t have a database that forgets things!” 　　So, we dropped the A, and the name stuck.
          • 简介
            • 是一个分布式数据库管理系统
          • 特性
            • 支持事务，支持透明的数据分片，利用两阶段锁实现分布式事务，可线性扩展到至少50个节点。
            • 数据库模式(schema)可在运行时动态重配置，表能被迁移或复制到多个节点 来改进容错性
        • LVS
          • 简介
            • Linux Virtual Server （Linux虚拟服务器），是一个虚拟的服务器集群系统
            • LVS集群采用 IP负载均衡技术 和 基于内容请求分发技术
            • 调度器是LVS集群系统的唯一入口点。-调度器具有很好的吞吐率，将请求均衡地转移到不同服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器
            • 整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序
          • 作用
            • UMP系统借助于LVS来实现集群内部的 负载均衡
        • RabbitMQ
          • "MQ" Message Queue
          • 工业级的消息队列产品
          • 节点间消息通讯
        • ZooKeeper
          • 简介
            • 协同工作系统
          • 作用
            • 全局的配置服务器
            • 提供分布式锁（选出一个集群的“总管”）
            • 监控所有MySQL实例
    • 功能
      • 容灾
        • what
          • 为每个用户创建2个MySQL实例，一个主库，一个从库
          • 主从库状态由Zookeeper负责维护
        • how
          • 主从切换过程
            • -[Zookeeper]探测到主库故障，通知[Controller服务器]-[Controller服务器]启动主从切换时，会修改“路由表”，即用户名到后端MySQL实例地址的映射关系-把主库标记为不可用-借助于[消息中间件RabbitMQ]通知所有[Proxy服务器]修改用户名到后端MySQL实例地址的映射关系
          • 宕机后的主库再次上线过程
            • -在主库恢复时，会把从库的更新复制给自己-当主库的数据库状态 快要达到 和从库一致的状态时，[Controller服务器]就会命令从库停止更新，进入不可写状态，禁止用户写入数据-等到主库更新到和从库完全一致的状态时,[Controller服务器]就会发起主从切换操作，并在路由表中 把主库标记为可用状态-通知[Proxy服务器]把写操作切回主库上，用户写操作可以继续执行，之后再把从库修改为 可写状态
      • 读写分离
        • UMP系统实现了对于用户透明的读写分离功能，当整个功能被开启时，[负责向用户提供访问MySQL数据库服务的Proxy服务器]，就会对用户发起 的SQL语句进行解析.
        • 读
          • 被均衡地发送到主库、从库上执行
        • 写
          • 主库
      • 分库分表
        • how
          • 1.[Proxy服务器]解析用户SQL语句，提取出 重写和分发SQL语句 所需要的信息
          • 2.对SQL语句进行重写，得到多个针对相应MySQL实例的子语句，然后把子语句分发到对应的MySQL实例上执行
          • 3.接收来自各个MySQL实例的SQL语句执行结果，合并得到最终结果
      • 资源管理
        • 总
          • 采用资源池机制来管理数据库服务器上的CPU、内存、磁盘等计算资源，所有的计算资源都放在资源池内进行统一分配，资源池是为MySQL实例分配资源的基本单位。
        • 具体
          • 整个集群中的所有服务器会根据其机型、所在机房等因素被划分多个资源池，每台服务器会被加入到相应的资源池中
          • 对于每个具体MySQL实例，管理员会根据应用部署在哪些机房、需要哪些计算资源等因素，为该MySQL实例具体指定主库和从库所在的资源池，然后，系统的实例管理服务会本着负载均衡的原则，从资源池中选择负载较轻的服务器来创建MySQL实例
      • 资源调度
        • 多个小规模用户：共享同一个MySQL实例
        • 中等规模的用户：独占一个MySQL实例
        • 分库分表的用户：占有多个独立的MySQL实例
      • 资源隔离
        • 用Cgroup限制MySQL进程资源
          • 场合
            • 多个MySQL实例共享同一台物理机
          • 方式
            • 限制用户的MySQL进程最大可以使用的CPU使用率、内存和IOPS等
        • 在Proxy服务器端限制QPS
          • 场合
            • 多个用户共享同一个MySQL实例
          • 方式
            • [Controller服务器]监测用户的MySQL实例的资源消耗情况。-如果明显超出配额，就通知[Proxy服务器]通过[增加延迟的方法]去限制用户的QPS，以减少用户对系统资源的消耗。
      • 数据安全
        • SSL数据库连接
          • SSL(Secure Sockets Layer)是为网络通信提供安全及数据完整性的一种安全协议，它在传输层对网络连接进行加密。
          • [Proxy服务器]实现了完整的MySQL客户端/服务器协议，可以与客户端之间建立SSL数据库连接
        • 数据访问IP白名单
          • 可把允许访问云数据库的IP地址放入“白名单”，只有白名单内的IP地址才能访问，其他IP地址的访问都会被拒绝，从而进一步保证账户安全
        • 记录用户操作日志
          • 用户的所有操作记录都会被记录到[日志分析服务器]，通过检查用户操作记录，可以发现隐藏的安全漏洞
        • SQL拦截
          • [Proxy服务器]可以根据要求拦截多种类型的SQL语句，比如全表扫描语句“select *”
  • Amazon AWS和云数据库
    • AWS
      • AWS Global Infrastructure
        • Region
          • 每个Region是相互独立的，自成一套云服务体系，分布在全球各地。目前全球有10个Region（比如 北京）
        • Availability Zone
          • 每个Region又由数个可用区组成，每个可用区可以看做一个数据中心，相互之间通过光纤连接
        • Edge Locations
          • 全球目前有50多个边缘节点，是一个内容分发网络（CDN，Content Distrubtion Network），可以降低内容分发的延迟，保证终端用户获取资源的速度
      • Networking
        • Direct Connect
          • 支持企业自身的数据中心直接与AWS的数据中心直连，充分利用企业现有的资源
        • VPN Connection
          • 通过VPN连接AWS，保证数据的安全性
        • Virtual Private Cloud
          • 私有云，从AWS云资源中分一块给你使用，进一步提高安全性
        • Route 53
          • 亚马逊提供的高可用的可伸缩的云域名解析系统。高效地将用户请求连接到 AWS 中运行的基础设施，如Amazon EC2 实例、ELB 负载均衡器或 Amazon S3 存储桶
      • Compute
        • EC2：Elastic Compute Cloud
          • 虚拟机。支持Windows和Linux的多个版本，支持API创建和销毁，有多种型号可供选择，按需使用。并且有自动扩展功能(5分钟即可新建一个虚拟机)，有效解决应用程序性能问题
          • 架构
            • EC2实例（AMI）
            • 弹性块存储
            • 弹性负载均衡
        • ELB：Elastic Load Balancing
          • 负载均衡器。可以和EC2无缝配合使用，横跨多个可用区，可以自动检查实例的健康状况，自动剔除有问题的实例，保证应用程序的高可用性
      • Storage
        • S3：Simple Storage Service
          • 对外提供的对象存储服务。不限容量，单个对象大小可达5TB，可实现高达99.999999999%的可用性
        • EBS：Elastic Block Storage
          • 弹性块存储服务，Amazon EBS可以为Amazon EC2的虚拟机创建卷volumns。 EBS相当于一个分布式块设备，可以直接挂载在EC2实例上，用于替代EC2实例本地存储，从而增强EC2可靠性
          • EBS通过卷来组织数据，每个EBS卷只能挂载到一个EC2实例
          • EBS卷并不与实例绑定，而是与用户帐号绑定
        • Glacier
          • 用于较少使用的存储存档文件和备份文件，价格便宜量又足，安全性高
      • Database
        • SimpleDB：基于云的键 / 值数据存储服务
        • DynamoDB： DynamoDB是亚马逊自主研发的No SQL数据库，性能高，容错性强，支持分布式
        • RDS：Relational Database Service，关系型数据库服务。支持MySQL，SQL Server和Oracle等数据库
        • Amazon ElastiCache： 数据库缓存服务
      • Application Service
        • Cloud Search: 一个弹性的搜索引擎，可用于企业级搜索
        • Amazon SQS： 队列服务，存储和分发消息
        • Simple Workflow：一个工作流框架
        • CloudFront：世界范围的内容分发网络（CDN）
        • EMR： Elastic MapReduce，一个Hadoop框架的实例，可用于大数据处理
      • Deployment & Admin
        • Elastic BeanStalk: 一键式创建各种开发环境和运行时
        • CloudFormation：采用JSON格式的模板文件来创建和管理一系列亚马逊云资源
        • OpsWorks： OpsWorks允许用户将应用程序的部署模块化，可以实现对数据库、运行时、服务器软件等自动化设置和安装
        • IAM： Identity & Access Management，认证和访问管理服务。用户使用云服务最担心的事情之一就是安全问题。亚马逊通过IAM提供了立体化的安全策略，保证用户在云上的资源绝对的安全
    • 云数据库
      • Amazon RDS
        • 借助 AWS 数据库迁移服务及其附带模式转换工具，客户可选择从本地部署向AWS 迁移相同数据库引擎
      • Amazon SimpleDB
        • what
          • AWS上的第一个NoSQL数据库服务（键值数据库）
        • how
          • 把数据进行多副本存储，支持高并发读取
          • 更新操作只能针对主副本进行，但可以快速传播到其他副本，提供最终一致性
        • 应用
          • 存储小型、碎片化的零散数据
        • 缺陷
          • 单表限制
            • SimpleDB 数据模型由域、项目、属性和值组成，每个域最多只能保存10GB的数据，所以得自己分区以免超过此限制
          • 性能不稳定
            • SimpleDB以简单为设计目标，SimpleDB并不需要用户指定主键，也不需要用户创建索引，会默认对所有属性创建索引。
          • 一致性问题
            • 设计时采用的是最终一致性模型
      • Amazon DynamoDB
        • what
          • 采纳了SimpleDB中成功的托管服务形式及灵活的数据模型
        • how
          • 提供了一致性读功能
          • 限制了系统的功能，只能通过主键去操作记录，不能进行批量更新，使得系统可以保证 可伸缩性及任何时候的高性能
          • 全面使用SSD来提升系统性能
      • Amazon Redshift
      • Amazon ElastiCache
  • 微软云数据库SQL Azure
    • 逻辑模型
      • 概念
        • 一个表格组：一个逻辑数据库
        • 行组：表格组中所有划分主键相同的行集合
      • 只支持同一个行组内的事务，同一个行组的数据逻辑上会分布到一台服务器，以此规避分布式事务
      • 通过 主备复制 将数据复制到多个副本，保证高可用性
    • 物理模型
      • what
        • 在物理层面，每个 有主键的表格组 根据划分主键列 有序地分成多个数据分区。每个行组属于唯一分区
        • 分区：SQL Azure复制、迁移、负载均衡的基本单位。每个分区包含多个副本（默认为3），每个副本存储在一台物理的SQL Server上
          • Primary 主副本（1个）
            • 处理查询、更新事务，并以操作日志的形式，将事务同步到Secondary
          • Secondary 从副本（其他）
            • 接收Primary发送的事务日志，并应用到本地数据库
    • 体系架构
      • SQL Server实例
        • 一个运行着SQL Server的物理进程。
        • 每个物理数据库 包含 多个子数据库，它们之间相互隔离。子数据库是一个分区，包含用户的数据、schema信息
      • 全局分区管理器
        • 维护分区映射表信息
      • 协议网关
        • 将用户的 数据库连接请求 转发到 相应的主分区上
      • Fabric 分布式基础部件
        • 维护机器上下线状态，检测服务器故障并为集群中的各种角色执行选取主节点操作
      • 虚拟机簇
        • 根据工作负载的变化，动态增加/减少虚拟机的数量
        • 每台虚拟机SQL Server VM安装了SQL Server 数据库管理系统，以关系模型存储数据
        • 通常，一个数据库会被散存储到3~5台SQL Server VM中
  • 实践
• MapReduce
  • 概述
    • 分布式并行编程
      • why?
        • CPU性能大约每隔18个月翻一番，从2005年开始摩尔定律逐渐失效 ，需要处理的数据量快速增加，开始借助分布式并行编程来提高程序性能
        • 谷歌公司最先提出了分布式并行编程模型MapReduce
      • MapReduce & 传统的并行计算框架 对比
        • 集群架构/容错性
          • 传统并行计算框架
            • 共享式(共享内存/共享存储)，容错性差
          • MapReduce
            • 非共享式，容错性好
        • 硬件/价格/扩展性
          • 传统并行计算框架
            • 刀片服务器、高速网、SAN，价格贵，扩展性差
          • MapReduce
            • 普通PC机，便宜，扩展性好
        • 编程/学习难度
          • 传统并行计算框架
            • what-how，难
          • MapReduce
            • what，简单
        • 适用场景
          • 传统并行计算框架
            • 实时、细粒度计算、计算密集型
          • MapReduce
            • 批处理、非实时、数据密集型
    • MapReduce模型简介
      • Hadoop框架是用Java实现的，但是，MapReduce应用程序则不一定要用Java来写
      • 函数
        • Map
          • 输入
            • <k1,v1>如：<行号,”a b c”>
          • 输出
            • List(<k2,v2>)如：<“a”,1><“b”,1><“c”,1>
          • 说明
            • 1.将小数据集进一步解析成一批<key,value>对，输入Map函数中进行处理2.每一个输入的<k1,v1>会输出一批<k2,v2>。<k2,v2>是计算的中间结果
        • Reduce
          • 输入
            • <k2,List(v2)>如：<“a”<1,1,1>>
          • 输出
          • 说明
            • 输入的中间结果<k2,List(v2)>中的List(v2)表示是一批属于同一个k2value
      • 策略：分而治之
        • 一个存储在 分布式文件系统 中的大规模数据集，会被切分成 许多独立的分片（split），这些分片可以被多个Map任务并行处理
      • 理念：计算向数据靠拢
        • 因为 移动数据需要大量的网络传输开销
      • 架构
        • 一个Master
          • JobTracker
        • 若干个Slave
          • TaskTracker
    • Map和Reduce函数
      • Map是过滤一些原始数据， Reduce则是处理这些数据
      • Map
        • 输入
          • <k1,v1>如：<行号,”a b c”>
        • 输出
          • List(<k2,v2>)如：<“a”,1><“b”,1><“c”,1>
        • 说明
          • 1.将小数据集进一步解析成一批<key,value>对，输入Map函数中进行处理2.每一个输入的<k1,v1>会输出一批<k2,v2>。<k2,v2>是计算的中间结果
      • Reduce
        • 输入
          • <k2,List(v2)>如：<“a”<1,1,1>>
        • 输出
        • 说明
          • 输入的中间结果<k2,List(v2)>中的List(v2)表示是一批属于同一个k2value
  • 体系结构
    • 1）Client，用来提交 MapReduce作业。 2）jobtracker，用来 协调 作业的运行。 3）tasktracker，用来 处理 作业划分后的任务。 4）HDFS，用来在其它实体间 共享 作业文件。
    • Client
      • 提交 用户编写的MapReduce程序 到JobTracker端
      • 通过Client提供的一些接口 查看作业运行状态
    • JobTracker
      • 资源监控
        • 监控所有TaskTracker、Job的健康状况，一旦发现失败，就将相应的任务转移到其他节点
      • 作业调度
        • 跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler），而调度器会在资源出现空闲时，选择合适的任务去使用这些资源
    • TaskTracker
      • 1、周期性地 通过“心跳” 将本节点上资源的使用情况&任务的运行进度 汇报给JobTracker；2、接收JobTracker 发送过来的命令，并执行相应的操作（如启动新任务、杀死任务等）
      • 1、用“slot”等量划分 本节点上的资源量（CPU、内存等）。2、一个Task 获取到一个slot 后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。
    • Task
      • Map Task
      • Reduce Task
  • 工作流程
    • 流程概述： 1）作业的提交 2）作业的初始化 3）任务的分配 4）任务的执行 5）进程和状态的更新 6）作业的完成 具体： 1.有一个待处理的大数据，被划分成大小相同的数据库(如64MB)，以及与此相应的用户作业程序。 2.系统中有一个负责调度的主节点(Master)，以及数据Map和Reduce工作节点(Worker). 3.用户作业提交个主节点。 4.主节点为作业程序寻找和配备可用的Map节点，并将程序传送给map节点。 5.主节点也为作业程序寻找和配备可用的Reduce节点，并将程序传送给Reduce节点。 6.主节点启动每一个Map节点执行程序，每个Map节点尽可能读取本地或本机架的数据进行计算。(实现代码向数据靠拢，减少集群中数据的通信量)。 7.每个Map节点处理读取的数据块，并做一些数据整理工作(combining,sorting等)并将数据存储在本地机器上；同时通知主节点计算任务完成并告知主节点中间结果数据的存储位置。 8.主节点等所有Map节点计算完成后，开始启动Reduce节点运行；Reduce节点从主节点所掌握的中间结果数据位置信息，远程读取这些数据。 9.Reduce节点计算结果汇总输出到一个结果文件，即获得整个处理结果。 --------------------- 作者：fanxin_i 来源：CSDN 原文：https://blog.csdn.net/fanxin_i/article/details/80388221 版权声明：本文为博主原创文章，转载请附上博文链接！
    • 工作流程
      • 提交
      • 初始化
      • 分配
        • 1、MapReduce库先把user program的输入文件划分为M份（M为用户定义），每一份通常有16MB到64MB，如图左方所示分成了split0~4；-然后使用fork将用户进程拷贝到集群内其它机器上。
        • 2、user program的副本中有一个称为master，其余称为worker，master是负责调度的，为空闲worker分配作业（Map作业或者Reduce作业），worker的数量也是可以由用户指定的。
      • 执行
        • 3、被分配了Map作业的worker，开始读取对应分片的输入数据，Map作业数量是由M决定的，和split一一对应；-Map作业从输入数据中抽取出键值对，每一个键值对都作为参数传递给map函数，map函数产生的中间键值对被缓存在内存中。
        • 4、缓存的中间键值对会被定期写入本地磁盘，而且被分为R个区，R的大小是由用户定义的，将来每个区会对应一个Reduce作业；-这些中间键值对的位置会被通报给master，master负责将信息转发给Reduce worker。
        • 5、master通知分配了Reduce作业的worker它负责的分区在什么位置（肯定不止一个地方，每个Map作业产生的中间键值对都可能映射到所有R个不同分区），当Reduce worker把所有它负责的中间键值对都读过来后，先对它们进行排序，使得相同键的键值对聚集在一起。-因为不同的键可能会映射到同一个分区也就是同一个Reduce作业（谁让分区少呢），所以排序是必须的。
        • 6、reduce worker遍历排序后的中间键值对，对于每个唯一的键，都将键与关联的值传递给reduce函数，reduce函数产生的输出会添加到这个分区的输出文件中。
      • 更新
      • 完成
        • 当所有的Map和Reduce作业都完成了，master唤醒正版的user program，MapReduce函数调用返回user program的代码。
    • Shuffle过程详解
      • input
        • map task执行的时候，数据的来源是HDFS上的block，在MapReduce概念中，读取的是split，split和block是对应的。
      • map阶段
        • 经过自定义的map函数的处理后，结果将以key/value的形式输出，但是这些结果要送到以后的哪一个reduce去执行，需要partition来决定。
      • partition
        • 内存缓冲区的概念 每个map任务都有一个内存缓冲区，用于存储任务的输出，默认缓冲区的大小是100M，这个值是可以通过io.sort.mb来调整。由于缓冲区的空间大小有限，所以，当map task的输出结果很多的时候，内存缓冲区就装不下这么多的数据，也就需要将数据写到磁盘去。因此需要一个阈值（io.sort.spill.percent，默认是80%），当内存达到阈值以后，就会有一个单独的后台线程，负责将内存中的数据写到磁盘，这个过程叫做溢写，由于是由单独的线程来负责溢写，所以，溢写过程不会影响map结果的输出，但是，如果此期间缓冲区被写满，map就会阻塞知道写磁盘过程完成。 为什么要设置内存缓冲区？ -批量收集map的结果，减少磁盘IO次数，提高效率。 --------------------- 作者：Genius_zz 来源：CSDN 原文：https://blog.csdn.net/Genius_zz/article/details/77988754 版权声明：本文为博主原创文章，转载请附上博文链接！
        • 根据key或者value的值，以及reduce的数量，来决定当前的这对输出数据要交到那个reduce task去处理
      • sort
        • 按照字典顺序进行排序，而不是按照数值大小进行排序，举个栗子，就是说，a一定排在d的后面。
      • combine
        • 溢写磁盘需要注意的地方： 如果map的输出结果很大，有多次溢写发生的话，磁盘上就会存在多个溢写文件（每次溢写都会产生一个溢写文件），在map task真正的完成是时，会将所有的溢写文件都Merge到一个溢写文件中，这个过程就叫Merge。 比如，从一个map读取过来的是，另外一个map读取的是。相同的key，就会merge成一个group{aaa，[5, 8...]}，这个数组中的不同的值，就是从不同的溢写文件中读取过来的，然后把这些值加起来。 所有的合并是为了什么？ 因为map节点和reduce节点之间的数据拷贝是通过网络进行拷贝的，数据量越小，拷贝的越快，相应的处理也就越快。合并的目的就是减少map的输出数据量，是网络拷贝尽可能快。 --------------------- 作者：Genius_zz 来源：CSDN 原文：https://blog.csdn.net/Genius_zz/article/details/77988754 版权声明：本文为博主原创文章，转载请附上博文链接！
        • 将排好序的数据，按照键相同的合并在一起的规则，进行值的合并。比如两个<aaa,1>合并以后，就编程了一个<aaa，2>。
  • 实例分析：WordCount
  • 具体应用
    • 关系代数运算
    • 分组与聚合运算
    • 矩阵-向量乘法
    • 矩阵乘法
  • 编程实践
• Hive
  • 为简化编写MapReduce程序而生。 -hive是基于hadoop实现的数据仓库，适合存储海量全量数据，支持类SQL操作，性能相对较差，数据存储有一定的限制，不支持更新、索引等事务。适合海量数据的挖掘和分析。 -通俗来说，hive其实就是借助mysql等数据库在hadoop上层套了一个壳，来实现对hdfs上结构化数据的映射，为上层提供sql服务。 --------------------- 作者：zx8167107 来源：CSDN 原文：https://blog.csdn.net/zx8167107/article/details/79265537 版权声明：本文为博主原创文章，转载请附上博文链接！ -使用MapReduce做过数据分析的人都知道，很多分析程序除业务逻辑不同外，程序流程基本一样。 在这种情况下，就需要hive这样的用戶编程接口。Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑，就是些表的定义等，也就是表的元数据。使用SQL实现Hive是因为SQL大家都熟悉，转换成本低，类似作用的Pig就不是SQL。
  • 概述
    • Data Warehouse（数据仓库）概念
      • 一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。
    • 传统数据仓库缺点
      • 无法满足快速增长的海量数据存储需求
      • 无法有效处理不同类型的数据
      • 计算和处理能力不足
    • Hive简介
      • 构建于Hadoop顶层的数据仓库工具
        • · 支持大规模数据存储、分析，具有良好的可扩展性。 •某种程度上可以看作是用户编程接口，本身不存储和处理数据 •依赖HDFS存储数据 •依赖MapReduce处理数据 •定义了简单的类似SQL 的查询语言——HiveQL •用户可以通过编写的HiveQL语句运行MapReduce任务 •可很容易把原来构建在关系数据库上的数据仓库应用程序移植到Hadoop 平台上 •是一个可以提供有效、合理、直观组织和使用数据的分析工具
      • 特点
        • 批处理方式处理海量数据
          • 把HiveQL语句转换成MapReduce任务进行运行
          • 数据仓库存储的是静态数据，对静态数据的分析适合采用批处理方式
        • 提供适合数据仓库操作的工具
          • Hive本身提供了一系列 对数据进行提取、转换、加载（ETL） 的工具，可存储、查询和分析存储在Hadoop中的大规模数据
    • Hive与(Hadoop生态系统中其他组件)的关系
      • •Hive依赖于HDFS 存储数据•Hive依赖于MapReduce 处理数据•在某些场景下Pig可以作为Hive的替代工具•HBase 提供数据的实时访问
    • Hive与传统数据库的对比分析
      • 数据插入
        • Hive
          • 批量
        • 传统数据库
          • 单条、批量
      • 数据更新
        • Hive
          • 不支持
        • 传统数据库
          • 支持
      • 索引
        • Hive
          • 支持
        • 传统数据库
          • 支持
      • 分区
        • Hive
          • 支持
        • 传统数据库
          • 支持
      • 执行延迟
        • Hive
          • 高
        • 传统数据库
          • 低
      • 扩展性
        • Hive
          • 好
        • 传统数据库
          • 有限
    • Hive在企业中的部署和应用
  • 系统架构
    • 用户接口
      • CLI
        • shell命令行
      • JDBC/ODBC
        • Hive的JAVA实现
      • WebGUI
        • 通过浏览器访问Hive
      • HWI
    • Driver 驱动模块
      • -包括解释器、编译器、优化器、执行器。-负责把HiveSQL语句 转换成 一系列MapReduce作业
    • Metastore 元数据存储模块
      • -独立的关系型数据库（自带derby数据库，或MySQL数据库）-Hive将元数据（表的名字，列和分区及其属性，属性，所在目录等。）存储在数据库中。
  • Hive基本原理
    • SQL语句 转换成 MapReduce
      • join的实现原理
      • group by的实现原理
        • 存在一个分组（Group By）操作，其功能是把表Score的不同片段按照rank和level的组合值进行合并，计算不同rank和level的组合值分别有几条记录：select rank, level ,count(*) as value from score group by rank, level
    • Hive中SQL查询转换成MapReduce
      • • 当启动MapReduce程序时，Hive本身是不会生成MapReduce算法程序的 • 需要通过一个表示“Job执行计划”的XML文件驱动执行内置的、原生的Mapper和Reducer模块 • Hive通过和JobTracker通信来初始化MapReduce任务，不必直接部署在 JobTracker所在的管理节点上执行 • 通常在大型集群上，会有专门的网关机来部署Hive工具。网关机的作用主要是远程操作和管理节点上的JobTracker通信来执行任务 • 数据文件通常存储在HDFS上，HDFS由名称节点管理
      • 1、将SQL转换成抽象语法树
        • 由 Hive驱动模块中的编译器 对 用户输入的SQL语言 进行词法和语法解析，将SQL语句转化为抽象语法树的形式
      • 2、将抽象语法树转换成查询块
        • 抽象语法树的结构仍很复杂，不方便直接翻译为MapReduce算法程序，因此，把抽象语法书转化为查询块
      • 3、将查询块转换成逻辑查询计划
        • 把查询块转换成逻辑查询计划，里面包含了许多逻辑操作符
      • 4、重写逻辑查询计划
        • 重写逻辑查询计划，进行优化，合并多余操作，减少MapReduce任务数量
      • 5、将逻辑计划转成物理计划
        • 将逻辑操作符转换成需要执行的具体MapReduce任务
      • 6、选择最佳的优化查询策略
        • 对生成的MapReduce任务进行优化，生成最终的MapReduce任务执行计划
      • 输出
        • 由Hive驱动模块中的执行器，对最终的MapReduce任务进行执行输出
  • Hive HA（High Availability）基本原理
    • 由多个Hive实例进行管理的，这些Hive实例被纳入到一个资源池中，并由HAProxy提供一个统一的对外接口
  • Impala
    • 简介
      • 查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase上的PB级大数据，在性能上比Hive高出3~30倍
      • 运行依赖Hive的元数据
      • 参照 Dremel系统设计
      • 采用了与商用并行关系数据库类似的分布式查询引擎，可直接与HDFS和HBase进行交互查询
      • 和Hive采用相同的SQL语法、ODBC驱动程序和用户接口
    • 系统架构
      • Impalad
        • -协调客户端提交的查询的执行-与HDFS的数据节点（HDFS DN）运行在同一节点上-给其他Impalad分配任务，收集其他Impalad的执行结果进行汇总-Impalad也会执行其他Impalad给其分配的任务，主要就是对本地HDFS和HBase里的部分数据进行操作
        • 组成
          • Query Planner
          • Query Coordinator
          • Query Exec Engine
      • State Store
        • -创建一个statestored进程；-收集分布在集群中各个Impalad进程的资源信息，用于查询调度。
      • CLI
        • 提供查询使用的命令行工具
        • 提供Hue、JDBC及ODBC的使用接口
    • 查询执行过程
      • 0 注册&订阅
        • 提交查询前，Impala先创建一个Impalad进程，该进程向Impala State Store提交注册订阅信息，State Store会创建一个statestored进程，statestored进程通过创建多个线程来处理Impalad的注册订阅信息。
      • 1 提交查询
        • 用户通过CLI客户端提交一个查询到impalad进程，Impalad的Query Planner对SQL语句进行解析，生成解析树；然后，Planner把这个查询的解析树变成若干PlanFragment，发送到Query Coordinator
      • 2 获取元数据与数据地址
        • Coordinator通过从MySQL元数据库中 获取元数据，从HDFS的名称节点中 获取数据地址，以得到存储这个查询相关数据的所有数据节点。
      • 3 分发任务
        • Coordinator初始化相应impalad上的任务执行，即把查询任务 分配给 所有存储这个查询相关数据的数据节点。
      • 4 汇聚结果
        • Query Executor通过流式交换中间输出，并由Query Coordinator汇聚来自各个impalad的结果。
      • 5 返回结果
        • Coordinator把汇总后的结果返回给CLI客户端。
    • 与Hive的比较
      • 区别
        • 处理
          • hive
            • 长时间的批处理查询分析
          • Impala
            • 实时交互式SQL查询
        • 执行
          • hive
            • 依赖于MapReduce计算框架
          • Impala
            • 把执行计划表现为一棵完整的执行计划树，直接分发执行计划到各个Impalad执行查询
        • 内存
          • hive
            • 如果内存放不下所有数据，则会使用外存，以保证查询能顺序执行完成
          • Impala
            • 内存放不下数据时，不会利用外存，所以Impala目前处理查询时会受到一定的限制
      • 相同
        • 相同的存储数据池，把数据存储于HDFS和HBase中
        • 相同的元数据
        • 对SQL的解释处理比较相似，都是通过词法分析生成执行计划
      • 总结
        • -配合使用效果最佳-先使用Hive进行数据转换处理，之后再使用Impala在Hive处理后的结果数据集上 进行快速的数据分析
  • 实践