说明：本资料由哈尔滨工业大学（深圳）大数据专业某同学在复习时总结，大部分内容是手动码字。主要参考了林子雨的《大数据技术原理与应用》（第三版）和王斌老师的ppt资料。标★是自认为的主观题重点。由于我们不考查任何代码，所以有关编程实践的部分该资料都不会涉及。此外，本资料注重对知识点的理解和记忆，具有应试性，这导致部分定义可能会缺乏一些严谨性，但多数是为了方便理解。本资料仅供参考，如有错误，恳请指正。第一篇 大数据基础第一章 大数据概述1.1 大数据时代三次信息化浪潮信息化浪潮时间标志解决的问题代表企业第一次1980前后个人计算机信息处理微软、惠普、联想第二次1995前后互联网信息传输阿里巴巴、腾讯、百度第三次2010前后大数据、云计算和物联网信息爆炸阿里云、谷歌信息科技为大数据时代提供技术支撑存储设备容量不断增加CPU处理能力大幅提升网络带宽不断增加数据产生方式的几个阶段运营式系统阶段：满足企业的业务需求，如医疗系统、超市销售系统用户原创内容阶段：互联网允许用户原创内容，如微博、抖音感知式系统阶段：物联网的大量传感器每天都在产生数据大数据的发展历程萌芽期：1990-2000：数据理论的探索阶段成熟期：2000-2010：商业软件的开发，hadoop，MapReduce大规模应用期：2010-：渗透各行各业1.2 大数据概念大数据的特点——4V特点数据量大(Volume)数据类型繁多(Variety)消费者大数据、金融大数据、医疗大数据、城市大数据、工业大数据总体来说分为两大类：结构化数据（10%）和非结构化数据（90%）处理速度快(Velocity)价值密度低(Value)：大数据看起来很牛逼，但是数据价值密度远远比传统关系数据库中的低，也就是说大部分的数据都是无用的，只有极少部分数据是有用的。1.3 大数据的影响对科学研究的影响实验科学-理论科学-计算科学-数据密集型科学产生了数据密集型科学，一切都以数据为中心，用数据做决策对思维方式的影响大数据时代人们的思维方式有三大改变：全样而非抽样：以前数据处理能力有限，只能抽样，现在可以全样效率而非精确：传统追求算法，现代追求数据相关而非因果：传统解释一个问题需要找因果，现在人们更追求相关性，更多地交给大数据自己分析因果对社会发展的影响大数据决策成为新的决策方式大数据应用促进信息技术和各行业的深度融合大数据开发推动新技术和新应用不断涌现对就业市场的影响数据科学家成为热门人才对人才培养的影响改变中国高校信息技术相关专业的现有教学和科研体制1.4 大数据应用无处不在1.5 大数据关键技术定义（大数据技术） 伴随着大数据的采集、存储、分析和结果呈现，使用非传统的工具来对大量结构化、半结构化数据进行处理、分析和预测的一系列技术。大数据基本处理流程：数据采集、存储、分析和结果呈现大数据技术：数据采集与预处理数据存储和管理：分布式文件系统数据处理和分析：分布式计算框架数据安全和隐私保护两大核心技术：分布式存储、分布式处理1.6 大数据计算模式（大数据关键技术）批处理计算：大规模数据的批量计算：MapReduce、Spark流计算：流数据的实时计算：Flink、Storm图计算：图结构的处理：Pregel、GraphX查询分析计算：数据存储结构和查询分析：Hive、Dremel1.7 大数据产业一切与大数据相关的产业，各个组成部分IT基础设施层：硬件、软件、网络支持，如惠普、戴尔数据源层：数据提供者，各行各业数据管理层：分布式文件管理系统、数据库工具如，如HDFS数据分析层：分布式计算框架、数据挖掘、统计分析，如MapReduce，SPSS数据平台层：提供处理好的数据，一些企业，如阿里巴巴、谷歌数据应用层：智能产品1.8 大数据与云计算、物联网云计算的理解用户通过网络随时随地获得各种IT资源，如Google colabs云计算的三种服务模式基础设施即服务平台即服务软件即服务云计算的类型公有云：面向所有用户私有云：只为特定用户，如企业内部云混合云：既有公有又有私有云计算的关键技术虚拟化：构建虚拟计算机分布式存储：Hadoop分布式计算：MapReduce多租户：大量用户共享同一软硬件资源云计算的载体数据中心：为云计算提供计算、存储、带宽等各种硬件资源云计算产业链硬件与设备制造——基础设施运营——软件与解决方案供应商——基础设施即服务——平台即服务——软件即服务物联网的概念物物相连的互联网物联网的四个层次感知层：传感器，感知物理世界获取数据网络层：互联网，传输数据处理层：数据存储、批量处理平台应用层：面向用户物联网关键技术物联网关键技术应用举例识别和感知技术二维码、传感器网络与通信技术互联网数据挖掘与融合技术处理数据不包括：信息处理一体化技术物联网的应用智能+交通、医疗、家居、物流、农业...物联网产业链核心感应器件提供商——感知层末端设备提供商（将感应器件开发成设备）——网络运营商——软件与行业解决方案提供商——系统集成商——运营及服务提供商★大数据、云计算、物联网的关系区别：从定义出发，大数据从海量数据中挖掘价值，云计算提供IT资源，物联网实现物物相连，三者根本不是一个东西联系：大数据很多技术都来自云计算，大数据是云计算的应用场景，物联网产生数据，物联网借助大数据和云计算发展第二章 大数据处理架构Hadoop2.1 Hadoop概述简介Apache软件基金会旗下的开源分布式计算平台，为用户提供底层细节透明的分布式基础架构基于java语言开发核心是Hadoop分布式文件系统（HDFS）和MapReduce大数据行业标准开源软件吃比萨，请认准这头黄象（doge）发展简史最初是由Doug Cutting开发的文本搜索库特性高可靠性高效性：速度快高可扩展性：源于多个DataNode高容错性：冗余存储策略成本低运行在Linux操作系统上支持多种编程语言应用现状应用非常广泛版本1.02.0：增加YARN3.02.2 Hadoop生态系统核心：HDFS，MapReduce其他：Zookeeper，HBase，Hive，Pig，Mahout，Flume，Sqoop，AmbariHDFSHadoop分布式文件系统（HDFS）是Hadoop的两大核心之一，是谷歌文件系统GFS的开源实现优点：处理超大数据、流式处理、运行在廉价服务器上HBase提供高可靠性、高性能、可伸缩、实时读写、分布式的列式数据库，采用HDFS作为底层数据存储系统MapReduceHadoop分布式并行编程模型（MapReduce）是针对谷歌MapReduce的开源实现抽象为两个函数：Map和ReduceHive基于Hadoop的数据仓库工具，用于对文件的数据集进行整理、查询和分析存储提供类似于SQL的查询语言——HiveQL自身可以转化为MapReduce任务，因而高效Pig数据流语言，提供类SQL的Pig Latin语言，简化了Hadoop的常见工作任务，在MapReduce的基础上创建了更简单抽象的脚本语言，可以代替Hive使用Mahout提供可扩展的机器学习领域经典算法的实现Zookeeper针对谷歌Chubby的开源实现，主要用于协调数据处理（很多事情都要用到它）Flume日志采集、聚合和传输系统SqoopSQL to Hadoop的缩写，可以将数据从传统关系数据库中导入hadoopAmbari一种基于Web的工具2.3 Hadoop的安装与使用2.4 Hadoop集群的部署与使用MapReduce的作业从磁盘或网络中读取数据，即IO密集工作计算数据，即CPU密集工作Hadoop集群的整体性能取决于CPU，内存，网络以及存储之间的性能平衡★Hadoop集群包括的节点功能Namenode协调集群中的数据存储。提供整个HDFS的命名空间管理服务DataNode存储被拆分的数据块JobTracker协调数据计算任务TaskTracker执行由JobTracker指派的任务SecondaryNameNode帮助NameNode收集文件系统运行的状态信息在集群中，大部分的机器设备是作为Datanode和TaskTracker工作的Hadoop不仅可以运行在企业内部的集群中，也可以运行在云计算环境中第二篇 大数据存储与管理第三章 分布式文件系统HDFS3.1 分布式文件系统计算机集群结构把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群结构计算机集群由普通硬件构成，大大降低成本分布式文件系统的结构主节点（Master Node）也叫名称结点（NameNode）：管理文件和目录名称从结点（Slave Node）也叫数据结点（DataNode）：由名称节点分配存储位置，负责数据的读取与存储3.2 HDFS简介开源实现了谷歌文件系统GFSHDFS要实现以下目标兼容廉价的硬件设备流数据读写大数据集简单的文件模型强大的跨平台兼容性实现较高水平扩展能力：主从结构HDFS的局限性不适合低延迟数据访问：HDFS是为大量数据批处理设计的，意味着有较高的延迟无法高效存储大量小文件：访问大量小文件的速度远低于访问几个大文件的速度不支持多用户写入及任意修改文件：只允许有一个写入者除此以外，还有几条局限性是这里没讲，但是以后会遇到的，总结在一起：会出现单点故障问题：只有单一名称节点，一旦发生故障就必须停机命名空间有限：只有单一命名空间，大小受限性能有限：HDFS读写数据的性能很大程度上取决于单一名称节点的吞吐量不支持随机访问，只支持批量访问模式：这一点可以由HBase来解决3.3 HDFS的相关概念块概念HDFS默认一个块128MB（2.7开始）★采用块存储的好处：支持大规模文件存储：大规模文件被拆成若干文件块发送到不同节点简化系统设计：简化了存储管理适合数据备份：每个文件块都被冗余存储到多个节点上（冗余存储：将数据在多个地方同时存储★名称节点名称节点（NameNode）负责管理命名空间（Namespace），存储元数据（记录数据的数据）。含有两个核心的数据结构，即FsImage和EditLogFsImage：维护文件树以及其中文件和文件夹的元数据（描述数据的数据）FsImage文件：包含文件系统所有目录和文件的innode序列化形式。即元数据FsImage文件没有记录每个块存储在哪个数据节点。由名称节点存储EditLog：操作日志文件，记录针对文件的创建、删除、重命名等操作名称节点的启动：将FsImage文件加载到内存中，再执行EditLog文件的各项操作。一旦在内存中成功建立元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件。名称节点启动后，文件元数据的更新操作会写到EditLog而不是FsImage中，这是因为FsImage比EditLog大得多。EditLog不断变大的问题：HDFS的更新操作直接写入EditLog，会造成其不断变大。解决问题：SecondaryNameNode 第二名称节点，用来保存名称节点中对HDFS元数据信息的备份，减少名称节点重启的时间。一般是单独运行在一台机器上。SecondaryNameNode工作流程：定期和NameNode通信，请求其停止使用EditLog文件通过HTTPGET方式从NameNode上获取到并下载FsImage和EditLog文件EditLog和FsImage文件合并：将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使FsImage保持最新执行完之后，会通过post方式将新的FsImage文件发送到NameNode节点上NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了数据结点数据节点（DataNode）是分布式文件系统HDFS的工作节点，负责数据的存储和读取根据客户或名称节点的调度进行数据的存储和检索定期向名称节点发送存储信息每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中3.4 HDFS体系结构概述采用主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点和若干数据结点名称节点是中心服务器，负责文件系统命名空间的管理数据结点在名称节点的统一调度下进行操作命名空间管理HDFS命名空间就是指所有命名内容所包括的空间。包含目录、文件和块通信协议基于网络传输，构建在TCP/IC协议基础上客户端用户操作HDFS最常用的方式，HDFS在部署时都提供了客户端HDFS客户端是一个库，暴露了HDFS文件系统接口严格来说，客户端并不算是HDFS的一部分客户端可以支持打开、读取、写入等常见的操作HDFS也提供了Java API★局限性（受限于只有一个名称节点）命名空间的限制：命名空间有自身大小，不能存储过多对象性能的瓶颈：受限于名称节点的吞吐量隔离问题：只有一个命名空间，无法对不同应用程序进行隔离集群的可用性（单点故障问题）：名称节点一旦发生故障，整个集群就不可用了3.5 HDFS存储原理冗余数据保存多副本存储，具有以下优点：加快数据传输速度容易检查数据错误保证数据可靠性数据存取策略数据存放：默认冗余复制因子是3，每一个文件块会被同时保存到3个地方：客户端指定或随机挑选——与上一个不同的机架上——与第一个相同的机架上不同节点上数据读取：优先选择与客户端同一机架内的数据副本进行读取，除此以外再随机选择副本读取数据错误与修复名称节点出错：HDFS设置备份机制，将核心元数据信息赋值备份到SecondaryNameNode上数据节点出错：数据节点故障时会标记成“宕机”，副本数量小于冗余因子时启动数据冗余复制生成新的副本。HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置数据出错：网络传输和磁盘错误等因素造成数据错误。HDFS有一套机制来修复3.6 HDFS数据读写过程读数据的过程写数据的过程3.7 HDFS编程实践略第四章 分布式数据库HBase4.1 概述BigTableBigTable是分布式存储系统，期初用于解决典型问题的互联网搜索问题。爬虫持续不断地抓取新页面，这些页面每页一行地存储到BigTable里MapReduce计算作业运行在整张表上，生成索引，为网络搜索应用做准备用户发起网络搜索请求网络搜索应用查询建立好的索引，从BigTable得到网页搜索结果提交给用户利用谷歌的MapReduce分布式并行计算模型来处理海量数据利用谷歌分布式文件系统GFS作为底层数据存储采用Chubby提供协同服务管理可扩展到PB级别和上千台机器，具有广泛应用性、可扩展性、高性能和高可用性谷歌的许多项目都在BigTable中HBase简介HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，具有低延迟的特点，是BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。目标：处理非常庞大的表，通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表BigTable和HBase对比BigTableHBase文件存储系统GFSHDFS数据处理模型谷歌MapReduceHadoop MapReduce协同服务管理ChubbyZookeeper★传统关系数据库已经流行很多年，并且Hadoop已经有了HDFS和MapReduce，为什么需要HBase？传统关系数据库无法应对数据量剧增时导致的性能问题传统关系数据库在数据结构变化时一般需要停机维护，浪费存储空间传统关系数据库可扩展性差Hadoop无法满足大规模数据实时处理的需求HDFS面向批量访问模式，不是随机访问模式（HBase可以通过索引直接访问）传统关系数据库和HBase的区别关系数据库HBase数据类型关系模型简单的数据模型，把数据存储解释为未经解释的字符串数据操作丰富的操作只有简单的插入、查询、删除、清空等存储模式行模式存储列存储数据索引复杂的索引只有一个索引——行键数据维护用新值覆盖旧值生成新值，并不会删除旧值可伸缩性很难扩展就是为了扩展而开发的4.2 HBase访问接口Native Java API：适合Hadoop MapReduce作业并行批处理HBase表数据HBase Shell：适合HBase管理使用Thrift Gateway：适合其他异构系统在线访问HBase表REST GatewayPig：Pig Latin流式编程语言来访问，适合做数据统计Hive：简单，以类似SQL的语言方式访问4.3 HBase数据模型HBase是一个稀疏、多维度、排序的映射表，表的索引是行键、列族、列限定符和时间戳表由行和列组成，行由行键来标识，列划分为若干个列族，列族里面有任意多个列，列由列限定符来定位单元格由行、列族和列限定符和时间戳四者共同确定，每个值是一个字符串，没有其他数据类型执行更新操作时并不会删除旧的版本，每个单元格都保存数据的多个版本，这些版本用时间戳索引列族支持动态扩展4.4 HBase的实现原理HBase的功能组件（各个功能的实现方法）库函数：链接到各个客户端一个Master主服务器：管理和维护表信息，分配和维护Region服务器许多个Region服务器：处理来自客户端的读写请求，存储到各自的Region客户端并不依赖Master（甚至不与Master通信），而是通过Zookeeper获得Region服务器，直接从Region服务器上读取数据Region的分裂一开始只有一个Region，后来不断分裂，Region的最佳大小取决于单台服务器的有效处理能力，一个Region服务器存储10-1000个Region。同一个Region不会被拆分到多个Region服务器。★Region的定位层次名称作用第一层Zookeeper文件记录-ROOT-表的位置第二层-ROOT-表（根数据表）记录了.META.表的Region位置信息，只有一个Region第三层.META.表（元数据表）存储了Region服务器和各个Region之间的映射关系，可以分裂成多个RegionRegion的定位客户端访问数据：三级寻址，只需要询问Zookeeper服务器，不需要连接Master4.5 HBase运行机制★HBase系统架构客户端：访问HBase的接口Zookeeper服务器：协调Master的运行配置维护域名服务分布式同步组服务Master主服务器管理用户对表的增加、删除、修改、查询等操作实现不同Region服务器之间的负载均衡在Region分裂或合并后，负责重新调整Region的分布对发生故障失效的Region服务器上的Region进行迁移Region服务器：Hbase最核心的模块，包含了一系列Region对象和一个Hlog文件（磁盘上的记录文件）。每个Region对象由多个Store组成，每个Store对应一个列族。每个Store又包含了一个MemStore（缓存）和若干个StoreFile（磁盘中的文件）。★Region服务器工作原理用户读写数据过程：被写入MemStore和Hlog中，读取数据时，Region服务器会首先访问MEMStore缓存，如果找不到，再去磁盘上的StoreFile上找缓存的刷新，周期性地将MEMStore缓存生成到StoreFile，清空缓存。StoreFile的合并。每次刷写都生成一个新的StoreFile，数量太多，影响查找速度。所以要进行StoreFile的合并。合并操作比较耗费资源，只有数量达到一个阈值才启动合并StoreRegion服务器的核心，可以将多个StoreFile合并成一个，单个StoreFile过大时又可以将父Region分裂成两个子RegionHLog分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复每个Region服务器配置了一个HLog文件Zookeeper会实时监测每个Region服务器的状态，当某个Region服 务器发生故障时，Zookeeper会通知Master，Master首先会处理该故障Region服务器上面遗留的HLog文件4.6 HBase应用方案HBase性能优化HBase性能监视：Master-status，Ganglia，OpenTSDB，Ambari在HBase上构建SQL引擎（Hive）构建HBase二级索引第五章 NoSQL数据库5.1 NoSQL简介定义：NoSQL是一种不同于关系数据库的数据库管理系统设计方式，是对非关系型数据库的一类统称，他采用的数据模型是非关系型的数据模型，例如键值、列族、文档和图等非关系模型。NoSQL数据库具有以下几个特点：灵活的可扩展性灵活的数据模型与云计算紧密融合★5.2 NoSQL兴起的原因1、传统关系数据库已经无法满足Web2.0（2004年后互联网发展的新阶段，交互式）的需求：无法满足海量数据的管理需求无法满足数据高并发（同一时间大量客户同时访问）的需求（HBase也不能满足高并发）无法满足高可扩展性和高可用性的需求数据结构死板，发生改变时需要停机维护2、MySQL集群也无法完全解决问题，因为：复杂性：部署、管理、配置复杂数据库复制不方便扩容复杂容易出错动态数据迁移很难做到自动化3、“One size fits all”模式很难适用于截然不同的业务场景4、关系数据库的关键特性（完善的事务机制和高效的查询机制）在Web2.0时代成为了鸡肋：Web2.0网站系统通常不要求严格的数据库事务Web2.0并不要求严格的读写实时性Web2.0通常不包含大量复杂的SQL查询5.3 NoSQL和关系数据库的比较比较标准关系数据库（RBDMS）NoSQL数据库原理支持部分支持数据规模大超大数据库模式固定灵活查询效率快简单查询很快，复杂查询慢一致性强一致性弱一致性数据完整性容易实现很难实现扩展性一般好可用性好很好标准化有无技术支持高低可维护性复杂复杂★总结优势劣势应用场景关系数据库以关系代数理论为支持，有严格的标准，技术成熟，可以高效实现复杂查询，有专业公司的技术支持①无法较好支持海量数据，②可扩展性差，③无法支持高并发，④数据模型死板，⑤综上无法较好支持Web2.0应用电信，银行等关键业务系统，需要保持事务强一致性（ACID属性）NoSQL数据库超大规模数据存储，灵活数据模型，完美支持Web2.0应用，有强大的横向扩展能力①缺乏数学理论基础，②复杂查询性能低，③技术不成熟，④很难实现数据完整性，⑤缺乏专业团队技术支持等互联网企业和传统企业的非关键业务★5.4 NoSQL四大类型1、键值数据库：Redis,SimpleDB, riak，Chordless优点：扩展性好，灵活性好，写操作性能高缺点：无法存储结构化信息（结构体），条件查询效率低，无法通过值来查询。2、列族数据库：HBase，BigTable优点：查询速度快，可扩展性强，复杂性低缺点：功能较少，不支持事务强一致性，不支持ACID事务3、文档数据库:
mongoDB文档：本质上也是键值：HTML，JSON等优点：性能好，高并发，灵活性高，复杂性低，数据结构灵活，既可以通过键来构建索引，也可以根据内容构建索引缺点：缺乏统一的查询语法，不支持文档间的事务4、图数据库:
Infinite Graph, Neo4j优点：灵活性高，支持复杂的图算法，可用于构建复杂的关系图谱缺点：复杂性高，只能支持一定的数据规模★5.5 NoSQL三大基石1、★CAP理论：一个分布式系统不可能同时满足C、A、P，最多同时满足两个C:Consistency，一致性，任何一个读操作总是能够读到之前写操作的结果，也就是所有节点在同一时间有相同的数据A:Availablity，可用性，快速获取数据，在确定时间内返回操作结果，不管请求成功或失败都会相应P:Tolenrance of Network Partition:分区容忍性，网络出现分区时（系统的节点通信故障），分离的系统也可以正常运行。系统的任意信息丢失不会影响系统的继续运作CA：放弃分区容忍性，将所有事务内容放到一台机器上，可扩展性较差。传统关系数据库。CP：放弃可用性，出现网络分区影响时，受影响的服务需要等待数据一致，期间无法对外提供服务。BigTable，HBase，Redis，MongoDB等AP：放弃一致性，允许系统返回不一致的数据。Dynamo，CouchDB，Riak等2、★BASE数据库事务的ACID四性Atomicity：原子性，原子工作单元，每一个任务要么全部执行，要么全部不执行Consistency：一致性，事务在完成时，必须使所有的数据都保持一致状态Isolation：隔离性，并发事务所做的修改必须与任何其它事务隔离Durable：持久性，事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持BASEBasically Available：基本可用性，允许分区失败情形出现，分布式系统一部分不可用时其他部分仍可用Soft state：软状态，有一段时间允许数据不同步，即数据具有一定滞后性。（硬状态就是数据一直是正确的）Eventually consistency：最终一致性，包括强一致性和弱一致性，即只要保证数据最终是一致的就可以了3、最终一致性因果一致性：没有因果关系的节点绝对不互相访问“读己之所写”一致性：绝不会看到旧值，只会看到最新写入的值会话一致性：会话还在，系统就保证一致性单调读一致性：如果之前看到了一个值，那之后绝不会看到这个值之前的值单调写一致性：系统按照写操作的顺序执行，这是必须保证的5.6 从NoSQL到NewSQL数据库NewSQL数据库不仅满足NoSQL处理海量数据的能力，还满足传统关系型数据库的ACID的性质。5.7 文档数据库MongoDB简介由C++编写，旨在为WEB应用提供高可扩展的高性能数据存储方案，数据结构由键值对组成，类似于JSON对象。优点：面向文档，操作简便任意索引，更快排序较好的水平扩展性丰富的查询表达式支持多种编程语言安装简单，支持Windows和linux第六章 云数据库6.1 云数据库概述云计算是云数据库兴起的基础云计算含义：通过整合、管理、调配分布在网络各处的计算资源，通过互联网以统一界面，同时向大量的用户提供服务云计算八大优势：按需服务，随时服务，通用性，高可靠性，极其廉价，超大规模，虚拟化，高扩展性举例：Google colabs云数据库概念部署和虚拟化在云计算环境中的数据库云计算大背景下发展起来的新兴方法具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点云数据库特点（1）动态可扩展 （2）高可用性 （3）较低的使用代价 （4）易用性 （5）高性能 （6）免维护 （7）安全★为什么说云数据库是个性化数据存储需求的理想选择（云数据库所带来的影响）？首先，云数据库可以满足大企业的海量数据存储需求其次，云数据库可以满足中小企业的低成本数据存储需求另外，云数据库可以满足企业动态变化的数据存储需求并且，前期零投入、后期免维护的数据库服务可以很好满足他们的需求选择自建数据库还是云数据库？对于一些大型企业，通常采用自建数据库对于一些财力有限的中小企业，IT预算有限，通常使用云数据库这种前期零投入、后期免维护的数据库服务云数据库与其他数据库具有哪些联系？云数据库并非一种全新的数据库技术，而只是以服务的方式提供数据库功能。通常使用关系模型（阿里云等），也可以是非关系模型（Amazon Dynamo云等）。6.2 云数据库产品传统：Oracle涉及市场的云供应商：Amazon，阿里，百度新兴厂商：EnerpriseDBAmazon云数据库市场的先行者。Amazon RDS：云中的关系数据库Amazon SimpleDB：云中的键值数据库Amazon DynamoDB：云中的NoSQL数据库Amazon Redshift：云中的数据仓库Amazon ElastiCache：云中的分布式内存缓存GoogleGoogle Cloud SQL是谷歌推出的基于MySQL的云数据库MicrosoftSQL Azure是微软推出的关系型数据库。属于关系型数据库支持存储过程支持大量数据类型支持云中的事务阿里云2009年阿里云诞生，2017年阿里云发布PolarDB6.3 云数据库系统架构（以UMP系统为例）有点偏，还很难，我觉得不会考，可以最后看UMP系统是低成本和高性能的MySQL云数据库方案。遵循以下原则:保持单一的系统对外入口，并且为系统内部维护单一的资源池消除单点故障，保证服务的高可用性保证系统具有可伸缩性，能够动态增删与存储节点保证分配给用户的资源具有可伸缩性，资源间相互隔离UMP系统架构依赖的开源组件：Mnesia：分布式数据库管理系统，支持事务，支持透明的数据分片，数据库模式(schema)可在运行时动态重配置RabbitMQ：工业级消息队列产品，作为消息传输的中间组件，通过读写队列消息实现可靠的消息传送Zookeeper：高效可靠的协同工作系统，提供分布式锁等基本服务，构建分布式应用。发挥以下三个作用：作为全局的配置服务器提供分布式锁监控所有MySQL实例LVS：即Linux虚拟服务器，虚拟服务器集群系统。UMP系统借助于LVS来实现集群内部的负载均衡Controller服务器向UMP集群提供各种管理服务其上运行了一组Mnesia分布式数据库服务当其它服务器组件需要获取用户数据时，可以向Controller服务器发送请求获取数据部署了多台Controller服务器，避免单点故障，保证高可用性Web控制台：向用户提供系统管理界面Proxy服务器：向用户提供访问MySQL数据库的服务Agent服务器：管理每台物理机上的MySQL实例日志分析服务器：存储和分析Proxy服务器传入的用户访问日志信息统计服务器：将各种信息用RDDtool进行统计，并在Web控制台上可视化愚公系统UMP系统功能容灾：为每个用户创建两个MySQL实例，在系统出现故障时，通过备份、冗余、备援等手段保证系统的可用性和可靠性。读写分离：充分利用主从库实现用户读写操作的分离，实现负载均衡分库分表：UMP支持对用户透明的分库分表资源管理：UMP系统采用资源池机制来管理数据库服务器上的计算资源，并在资源池内进行统一分配。资源池是为MySQL实例分配资源的基本单位。资源调度：针对不同规格的用户，UMP系统会分配不同的MySQL资源。资源隔离：多个用户共享同一个MySQL或多个MySQL共存在同一物理及上时就需要资源隔离。两种资源隔离方式：用Cgroup限制MySQL进程资源、在Proxy服务器端限制QPS。数据安全：使用多种机制保证数据安全：SSL数据库连接、数据访问IP白名单、记录用户操作日志、SQL拦截6.4 Amazon AWS和云数据库6.5 微软云数据库SQL Azure第三篇 大数据处理与分析第七章 MapReduce7.1 概述分布式并行编程模型摩尔定律：CPU性能每隔18-24个月翻一番，2005年起失效思路：运行在大规模计算机集群上，可以并行执行大规模数据处理任务，从而获得海量计算能力。Hadoop MapReduce：是谷歌MapReduce的开源实现，门槛也更低比较传统并行计算框架MapReduce集群架构共享式，容错性差非共享式，容错性好硬件刀片机，硬件昂贵，扩展性差普通PC机，扩展性好编程难度what-how模式，难上手what模式，简单易学适用实时、计算密集型批处理、非实时、数据密集型MapReduce模型思路高度抽象为两个函数：Map和Reduce，编程容易，不需要掌握分布式并行编程的细节采用“分而治之”策略，将大规模数据集切片“计算向数据靠拢”采用Master/Slave架构，一个Master和若干个Slave。Master上运行JobTracker，Slave上运行TaskTracker框架由Java实现，但MapReduce应用程序支持多种编程语言Map和Reduce函数函数输入输出Map<行号，"a, b, c"><"a", 1>,<"b",2>,<"c",3>Reduce<"a", <1, 1, 1>><"a", 3>Map：分成多个键值对Reduce：将具有同一键的键值对组合起来★7.2 MapReduce体系结构Client（客户端）用户编写的MapReduce程序通过Client提交到JobTracker端用户可通过Client提供的一些接口查看作业运行状态JobTracker（三大功能：资源管理，任务调度，任务监控）负责资源监控和作业调度监控所有TaskTracker与Job的健康状况，一旦发现失败，就将相应的任务转移到其他节点跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler）TaskTracker周期性地通过“心跳”将本节点上资源的使用情况和任务的运行进度汇报给JobTracker接收JobTracker 发送过来的命令并执行相应的操作（如启动新任务、杀死任务等）使用“slot”等量划分本节点上的资源量（CPU、内存等），分为Map slot和Reduce slot两种，分别供Map Task和Reduce Task使用 Task：分为Map Task 和Reduce Task 两种，均由TaskTracker 启动7.3 MapReduce工作流程概述不同的Map任务之间不会进行通信不同的Reduce任务之间也不会发生任何信息交换用户不能显式地从一台机器向另一台机器发送消息所有的数据交换都是通过MapReduce框架自身去实现的全过程：从分布式文件系统（HDFS）读入数据执行Map任务输出中间结果通过Shuffle阶段把中间结果分区、排序整理后发送给Reduce任务执行Reduce任务得到最终结果并写入分布式文件系统MapReduce工作原理Split（分片）MapReduce 处理单位是split。split是一个逻辑概念，只包含元数据信息：数据起始位置、数据长度、数据所在节点等Map任务的数量split 的多少决定了Map任务的数目Reduce任务的数量最优的Reduce任务个数取决于集群中可用的reduce任务槽(slot)的数目，通常设置比Reduce任务槽数目稍微小一些的Reduce任务个数（预留错误空间）★Shuffle过程Map端输入数据和执行Map任务Map任务的输出结果写入缓存溢写：每个Map任务分配的缓存大小默认是100M，缓存快满时（溢写比例0.8）启动溢写操作，将缓存中的数据一次性写入磁盘，并清空缓存。文件归并：每次溢写都会生成一个新的磁盘文件，随着Map任务的执行，会生成多个溢写文件，Map任务结束前，这些溢写文件被归并成一个大的磁盘文件可选：文件合并（Combine），将相同键的值加起来通知相应的Reduce任务来“领取”属于自己处理的数据Reduce端通过RPC向JobTracker询问Map任务是否已经完成，若完成，则“领取”数据，写入缓存溢写领取的数据来自不同Map机器，先归并，再合并，写入磁盘多个溢写文件归并成一个或多个大文件，文件中的键值对是排好序的当数据很少时，不需要溢写到磁盘，直接在缓存中归并输出给Reduce7.4 实例分析：WordCountMapReduce7.5 MapReduce的具体应用关系代数运算分组与聚合运算矩阵-向量乘法矩阵乘法MapReduce的作业主要包括：从磁盘或网络中读取数据，即IO密集工作计算数据，即CPU密集工作第八章 Hadoop架构再探讨8.1 Hadoop的优化与发展Hadoop1.0的核心组件（MapReduce和HDFS）有哪些不足？抽象层次低，需人工编码（由Pig解决）表达能力有限需要开发者自己管理作业（Job）之间的依赖关系（由Ooize解决）难以看到程序整体逻辑执行迭代操作效率低（由Spark，Hadoop2.0的YARN解决）资源浪费（Map和Reduce分两阶段执行）实时性差（适合批处理，不支持实时交互式）（由Spark解决）Hadoop的优化与发展体现在两大方面：自身两大核心组件MapReduce和HDFS的架构设计改进组件1.0的问题2.0的改进HDFS单一名称节点，存在单点故障问题HDFS HA，节点热备机制HDFS单一命名空间，无法实现资源隔离HDFS Federation，管理多个命名空间MapReduce资源管理效率低资源管理框架YARNHadoop生态系统其它组件的不断丰富，加入Pig、Tez、Spark和Kafka等新组件组件功能解决的问题Pig处理大规模数据的脚本语言，自动转换为MapReduce作业1.抽象层次低，需要手动编写大量代码的问题Spark基于内存的分布式并行编程框架，具有较高实时性，支持迭代计算5.7.实时性差，不适合迭代计算的问题Oozie工作流和协作服务引擎，协调Hadoop上运行的不同任务3.需要开发者自己管理作业（Job）之间的依赖关系Tez支持DAG作业的计算框架不同的MapReduce任务之间存在重复操作，降低了效率Kafka分布式发布订阅消息系统，企业大数据分析平台的数据交换枢纽Hadoop生态系统中各个组件和其他产品之间缺乏数据交换中介8.2 HDFS2.0的新特性★HDFS HAHDFS 1.0只有一个名称节点，节点发生故障时就会产生单点故障问题。（虽然有第二名称节点，但是也无法实时对外提供服务，任然需要停机）HDFS 2.0采用了HA架构（高可用High Availability），设置了两个名称节点——“活跃”和“待命”HA架构的待命名称节点提供了“热备份”，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点两种名称节点的状态同步借助于一个共享存储系统来实现Zookeeper确保只有一个名称节点在对外服务名称节点维护映射信息，数据节点同时向两个名称节点汇报信息★HDFS FederationHDFS1.0存在的问题单点故障问题水平扩展能力有限（可以水平扩展，但是能力不好）性能的限制：系统整体性能受限于单个名称节点的吞吐量隔离问题：单个名称节点难以提供不同程序之间的隔离性无法高效存储大量小文件不支持高并发不支持实时读写HDFS Federation设计了多个相互独立的名称节点，使得HDFS的命名服务能够水平扩展，这些命名空间之间是联盟的关系（federation）所有名称节点共享底层数据节点的存储资源，数据节点向所有名称节点汇报属于同一个命名空间的块构成一个“块池”HDFS Federation的访问方式：采用客户端挂载表对多个命名空间进行数据共享和访问HDFS Federation相对于HDFS 1.0的优势集群可扩展，命名空间不受限性能更高效，多个名称节点，吞吐量更大良好的隔离性，多个命名空间HDFS Federation并不能解决单点故障问题，也就是需要为每个名称节点部署一个后备名称节点。8.3 新一代资源管理调度框架YARN★MapReduce1.0的缺陷（资源管理效率低）存在单点故障问题，只有一个JobTracker，一旦发生故障就需要停机维护JobTracker“大包大揽”导致任务过重（三大功能：资源管理、任务调度、任务监控）容易出现内存溢出（TaskTracker分配资源只考虑MapReduce任务数，不考虑CPU、内存）资源划分不合理（强制划分为slot ，包括Map slot和Reduce slot）YARN设计思路：将JobTracker三大功能拆分YARN思路ResourceManager包含Scheduler和Application Manager，主要负责：处理客户端请求启动/监控ApplicationMaster监控NodeManager资源分配和调度ApplicationMaster为应用程序申请资源，分配给内部任务任务调度、监控与容错NodeManager单个节点上的资源管理处理来自ResourceManger和ApplicationManager的命令★YARN的工作流程用户编写应用端程序并向YARN提交ResourceManager负责接受用户的请求，分配一个容器，并与该容器的NodeManager通信，进行ApplicationMaster的启动工作ApplicationMaster创建后向ResourceManager注册并通过轮询方式申请资源ResourceManager以容器形式为ApplicationMaster分配资源ApplicationMaster收到资源后，立即与NodeManager通信要求其启动任务任务启动后，ApplicationMaster还会与NodeManager保持交互通信进行应用程序的运行、监控和停止；此外，ApplicationMaster还会定时向ResourceManager发送“心跳”消息，报告资源的使用情况和应用的进度信息当作业完成时，ApplicationMaster向ResourceManager注销容器，执行周期完成。★YARN相比于MapReduce1.0的优势大大减少了承担中心服务功能的ResourceManager（书上写的是ResourceManager，但是私以为是JobTracker更合适）的资源消耗MapReduce1.0既是一个计算框架，又是一个资源管理调度框架，而YARN是一个纯粹的资源调度管理框架YARN中的资源管理比MapReduce1.0更加高效YARN的发展目标是实现“一个集群多个框架”，为什么？一个企业当中同时存在各种不同的业务应用场景，需要采用不同的计算框架如果采用“一个框架一个集群”，企业就需要把内部的服务器拆分成多个集群，分别安装运行不同的计算框架，导致集群资源利用率低等若干问题由YARN为这些计算框架提供统一的资源调度管理服务8.4 Hadoop生态系统中具有代表性的功能组件Pig提供了类似SQL的Pig Latin语言允许用户通过编写简单的脚本来实现复杂的数据分析，不需要编写复杂的MapReduce程序会自动把用户编写的脚本转换成MapReduce作业在Hadoop集群上运行用户在编写Pig程序的时候，不需要关心程序的运行效率通过配合使用Pig和Hadoop，比使用Java、C++等语言编写MapReduce程序的难度要小很多，代码量更少应用场景数据查询只面向相关技术人员即时性的数据处理需求。可以用pig很快编写脚本运行TezApache开源的支持DAG作业的计算框架，直接源于MapReduce框架核心思想是将Map和Reduce两个操作进一步拆分Map被拆分成Input、Processor、Sort、Merge和OutputReduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等分解后的元操作可以任意灵活组合，产生新的操作，经过一些控制程序组装后，可形成一个大的DAG作业通过DAG作业的方式运行MapReduce作业，可以减少不必要操作SparkHadoop的MapReduce计算延迟高，无法胜任实时、快速计算的需求Spark最初诞生于伯克利大学的APM实验室，是一个可应用于大规模数据处理的快速、通用引擎Spark很好地解决了MapReduce的问题基于内存计算，带来了更高的迭代运算效率基于DAG的任务调度执行机制，优于MapReduce的迭代执行机制Spark正以其结构一体化、功能多元化的优势，逐渐成为当今大数据领域最热门的大数据计算平台Kafka一种高吞吐量的分布式发布订阅消息系统可以同时满足在线实时处理和批量离线处理Kafka可以作为数据交换枢纽，实现和Hadoop各个组件之间的不同类型数据的实时高效交换第九章 数据仓库Hive9.1 概述企业信息化程度越来越高，数据越来越多了，常用的数据处理方法：将已失效的历史数据简单删除，减少磁盘空间占用对历史数据通过介质进行备份后删除，可按需查看建立一个数据仓库系统，对业务系统及其他档案系统中有分析价值的数据进行存储。数据仓库的概念数据仓库就是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化的（Time Variant）数据集合，通常用于辅助决策支持。数据仓库的组成数据源数据挖掘：就是从大量数据中获取有效的、新颖的、潜在有用的、最终可理解的模式的非平凡过程直接数据挖掘：建立模型和算法间接数据挖掘：利用某种关系数据存储和管理数据服务：OLAP联机事务处理（OLTP）：传统关系型数据库管理系统的主要任务联机分析处理（OLAP）：数据仓库系统的主要任务，主要进行数据分析和决策数据应用传统数据仓库面临的挑战无法满足快速增长的海量数据存储的需求无法有效处理不同类型的数据计算和处理能力不足Hive简介构建于Hadoop顶层的数据仓库工具，最初由Facebook开发可以看作是用户编程接口，本身不存储和处理数据依赖分布式文件系统HDFS存储数据依赖分布式并行计算模型MapReduce处理数据定义了简单的类SQL 查询语言——HiveQL用户可以通过编写的HiveQL语句运行MapReduce任务是一个可以提供有效、合理、直观组织和使用数据的模型具有以下特点：采用批处理方式处理海量数据提供适合数据仓库操作的工具支持水平扩展Hive与Hadoop生态系统其他组件的关系Hive本身不存储数据，依赖于HDFS 存储数据Hive本身不处理数据，依赖于MapReduce 处理数据Pig可以作为Hive的替代工具HBase 提供数据的实时访问，Hive只能处理静态数据，可以互补Hive与传统数据库的对比Hive与传统数据库的对比9.2 Hive系统架构组成模块用户接口模块：CLI、HWI、JDBC、ODBC、Thrift Server等驱动模块元数据存储模块工作原理SQL语句转换成MapReduceSQL查询转换成MapReduce作业从外部访问Hive的典型方式CLI和HWI工具KarmasphereHueQubole公司提供了“Hive即服务”的方式9.3 Hive的应用Hadoop数据仓库框架Hive和Pig主要应用在报表中心上，Hive主要用于报表分析，Pig主要用于报表中数据的转换工作HBase主要用于在线业务，因为HDFS缺乏随机读写操作，而HBase正是为此开发的，支持实时访问数据。Mahout常用于BI（商务智能），提供一些机器学习经典算法的实现。Hive HA原理在Hadoop集群上构建的数据仓库由多个Hive进行管理由HAProxy（Hive HA）提供一个接口，对Hive实例进行访问由Hive处理后得到的各种数据信息，或存放在MySQL数据库中，或直接以报表的形式展现不同人员会根据所需数据进行相应工作将若干个hive 实例纳入一个资源池，然后对外提供一个唯一的接口对于程序开发人员，就把它认为是一台超强“hive"。每次它接收到一个HIVE查询连接后，都会轮询资源池里可用的hive 资源9.4 Impala简介Impala是由Cloudera公司开发的新型查询系统提供SQL语义，能查询存储在Hadoop的HDFS和HBase上的PB级大数据与Hive类似，Impala也可以直接与HDFS和HBase进行交互Hive底层执行使用的是MapReduce，所以主要用于处理长时间运行的批处理任务。Impala可以直接从HDFS或者HBase中用SQL语句查询数据，从而大大降低了延迟，主要用于实时查询。Impala和Hive采用相同的SQL语法、ODBC 驱动程序和用户接口Impala系统架构ImpaladImpalad是Impala的一个进程State StoreState Store会创建一个statestored进程CLICLI给用户提供查询使用的命令行工具★Impala与Hive的比较不同点：Hive适合长时间的批处理查询分析，Impala适合实时交互式SQL查询Hive依赖于MapReduce计算框架，执行计划组合成管道型的MapReduce任务模式进行执行，Impala把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询。Hive在执行过程中，如果内存放不下所有数据，则会使用外存；而Impala在遇到内存放不下数据时，不会利用外存，所以Impala目前处理查询时会受到一定的限制。相同点：使用相同的存储数据池，都支持把数据存储于HDFS和HBase中使用相同的元数据对SQL的解释处理比较相似，都是通过词法分析生成执行计划9.5 Hive编程实践Hive的数据类型TINYINT, SMALLINT, INT, BIGINT, FLOAT, DOUBLE, BOOLEAN, STRING, BINARY第十章 Spark10.1 Spark概述简介Spark最初由美国加州伯克利大学（UCBerkeley）的AMP实验室于2009年开发，是基于内存计算的大数据并行计算框架，可用于构建大型的、低延迟的数据分析应用程序Spark在2014年打破了Hadoop保持的基准排序纪录Spark用十分之一的计算资源，获得了比Hadoop快3倍的速度特点运行速度快：使用DAG执行引擎以支持循环数据流与内存计算容易使用：支持多种编程语言，也可以使用Spark Shell交互式编程通用性：Spark提供了完整而强大的技术栈运行模式多样：可运行于独立的集群模式中，可运行于Hadoop中，也可以运行于云环境Scala简介Scala是Spark的主要编程语言，但Spark还支持Java、Python、R作为编程语言Scala的优势是提供了REPL（Read-Eval-Print Loop，交互式解释 器），提高程序开发效率Scala特性：具备强大的并发性（同一时间执行多个任务），支持函数式编程，可以更好地支持分布式系统语法简洁，能提供优雅的API兼容Java，运行速度快，且能融合到Hadoop生态圈中★与Hadoop MapReduce对比，Spark为什么更优秀？Hadoop MapReduce（2.0）缺点（回忆1.0的缺点）表达能力有限磁盘IO（写入 读出）开销大延迟高（任务之间的衔接均涉及IO开销，必须等前一个任务执行完才能执行）Spark优点计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比Hadoop MapReduce更灵活提供了内存计算（内存的读写速度比磁盘快得多），可将中间结果放到内存中，对于迭代运算效率更高基于DAG的任务调度执行机制，要优于Hadoop MapReduce的迭代执行机制（非常耗资源）10.2 Spark生态系统实际大数据处理包括三种类型：复杂的批量数据处理、历史数据的交互式查询、实时数据流的数据处理，三种处理的时间跨度可以从毫秒级到小时级，如果三者同时存在，就需要同时部署三种不同软件（例如MapReduce/Impala/Storm），这是非常麻烦的。Spark解决这个问题Spark的设计遵循“一个软件栈满足不同应用场景”的理念，逐渐形成了一套完整的生态系统既能够提供内存计算框架，也可以支持SQL即席查询、实时流式计算、机器学习和图计算等可以部署在资源管理器YARN之上，提供一站式的大数据解决方案因此，Spark所提供的生态系统足以应对上述三种场景，即同时支持批处理、交互式查询和流数据处理Spark生态系统Spark Core：复杂的批量数据处理Spark SQL：基于历史数据的交互式查询Spark Streaming（流）：基于实时数据流的数据处理MLLib（machine learning）：基于历史数据的数据挖掘（机器学习算法）GraphX：图结构数据的处理10.3 Spark架构★基本概念RDD：是Resillient Distributed Dataset（弹性分布式数据集）的简称，是分布式内存的一个抽象概念，提供了一种高度受限的共享内存模型DAG：是Directed Acyclic Graph（有向无环图）的简称，反映RDD之间的依赖关系Executor：是运行在工作节点（WorkerNode）的一个进程，负责运行Task。相比于Hadoop MapReduce，有两个优点：利用多线程来执行具体的任务，减少任务的启动开销Executor中有一个BlockManager存储模块，会将内存和磁盘共同作为存储设备，有效减少IO开销Application：用户编写的Spark应用程序Task：运行在Executor上的工作单元Job：一个Job包含多个RDD及作用于相应RDD上的各种操作Stage：是Job的基本调度单位，一个Job会分为多组Task，每组Task被称为Stage，或者也被称为TaskSet，代表了一组关联的、相互之间没有Shuffle依赖关系的任务组成的任务集Spark架构集群资源管理器（Cluster Manager）运行作业任务的工作节点（Worker Node）每个应用的任务控制节点（Driver）每个工作节点上负责具体任务的执行进程（Executor）Spark运行基本流程看一下书，还是挺重要的，只不过我没时间看了当时Spark运行架构特点每个Application都有自己专属的Executor进程，并且该进程在Application运行期间一直驻留。Executor进程以多线程的方式运行TaskSpark运行过程与资源管理器无关，只要能够获取Executor进程并保持通信即可Task采用了数据本地性和推测执行等优化机制RDD运行原理设计背景许多迭代式算法（比如机器学习、图算法等）和交互式数据挖掘工具，共同之处是，不同计算阶段之间会重用中间结果目前的MapReduce框架都是把中间结果写入到HDFS中，带来了大量的数据复制、磁盘IO和序列化开销RDD就是为了满足这种需求而出现的，它提供了一个抽象的数据架构，我们不必担心底层数据的分布式特性，只需将具体的应用逻辑表达为一系列转换处理，不同RDD之间的转换操作形成依赖关系，可以实现管道化，避免中间数据存储和磁盘IO消耗RDD的概念分布式对象集合，本质上是一个只读的分区记录集合每个RDD可分成多个分区，每个分区就是一个数据集片段RDD提供了一种高度受限的共享内存模型，即RDD是只读的记录分区的集合，不能直接修改Spark使用RDD后为什么能高效计算？高效的容错机制：不需要通过冗余复制来容错中间结果持久化到内存存放的数据可以是Java对象，避免了不必要的对象序列化与反序列化10.4 Spark SQL从Hadoop+Storm架构转向Spark架构有哪些优点？实现一键式安装和配置、线程级别的任务监控和告警降低硬件集群、软件维护、任务监控和应用开发的难度便于做成统一的硬件、计算平台资源池10.5 Spark部署与应用方式Spark支持三种部署方式：StandaloneSpark on MesosSpark on YARN10.6 Spark编程实践第十一章 流计算流数据：数据以大量、快速、时变的流形式持续到达流数据具有如下特征：数据快速持续到达，潜在大小也许是无穷无尽的数据来源众多，格式复杂数据量大，但是不十分关注存储，一旦经过处理，要么被丢弃，要么被归档存储注重数据的整体价值，不过分关注个别数据数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素的顺序批计算——静态数据，实时计算——流数据批量计算：充裕时间处理静态数据，如Hadoop流数据不适合采用批量计算，因为流数据不适合用传统的关系模型建模流数据必须采用实时计算，响应时间为秒级数据量少时，不是问题，但是，在大数据时代，数据格式复杂、来源众多、数据量巨大，对实时计算提出了很大的挑战。因此，针对流数据的实时计算——流计算，应运而生流计算实时获取来自不同数据源的海量数据，经过实时分析处理，获得有价值的信息秉承一个基本理念，即数据的价值随着时间的流逝而降低对于一个流计算系统来说，它应达到如下需求：高性能：处理大数据的基本要求，如每秒处理几十万条数据海量式：支持TB级甚至是PB级的数据规模实时性：保证较低的延迟时间，达到秒级别，甚至是毫秒级别分布式：支持大数据的基本架构，必须能够平滑扩展易用性：能够快速进行开发和部署可靠性：能可靠地处理流数据流计算的处理流程包括三个阶段：数据实时采集、数据实时计算、实时查询服务数据实时采集Agent：主动采集数据，并把数据推送到Collector部分Collector：接受多个Agent的数据，并实现有序、可靠、高性能的转发Store：存储Collector转发过来的数据（对于流计算不存储数据）数据实时计算实时查询服务流处理系统与传统数据处理系统有哪些不同？– 流处理系统处理的是实时的数据，而传统的数据处理系统处理的是预先存储好的静态数据 – 用户通过流处理系统获取的是实时结果，而通过传统的数据处理系统，获取的是过去某一时刻的结果 – 流处理系统无需用户主动发出查询，实时查询服务可以主动将实时结果推送给用户流处理的应用场景？实时分析实时交通Twitter Storm是开源流计算框架整合性：Storm可方便地与队列系统和数据库系统进行整合简易的API：Storm的API在使用上即简单又方便可扩展性：Storm的并行特性使其可以运行在分布式集群中容错性：Storm可自动进行故障节点的重启、任务的重新分配可靠的消息处理：Storm保证每个消息都能完整处理支持各种编程语言：Storm支持使用各种编程语言来定义任务快速部署：Storm可以快速进行部署和使用免费、开源：Storm是一款开源框架，可以免费使用Storm主要术语Streams、Spouts、Bolts、Topology和Stream GroupingsStreams：流数据本身，流数据Stream描述成一个无限的Tuple序列Spouts：流数据的源头Bolt：Streams的状态转换过程，可以处理Tuple，也可以将处理后的Tuple作为新的Streams发送给其他Bolt。Bolt可以执行过滤、函数操作、Join、操作数据库等任何操作Topology：Spouts和Bolts组成的网络抽象而成。里面的每一个组件都是并行运行的Stream Groupings：用于告知Topology如何在两个组件间（如Spout和Bolt之间，或者不同的Bolt之间）进行Tuple的传送。1）Shuffle grouping：Tuples 随机的分发到每个 Bolt 的每个 Task 上，每个 Bolt 获取到 等量的 Tuples。 2）Fields grouping：Streams 通过 grouping 指定的字段 (field) 来分组。假设通过 userid 字段进行分区，那么具有相同 user-id 的 Tuples 就会发送到同一个 Task。 3）Partial Key grouping：Streams 通过 grouping 中指定的字段 (field) 来分组，与 Fields Grouping 相似。但是对于两个下游的 Bolt 来说是负载均衡的，可以在输入数据 不平均的情况下提供更好的优化。 4）All grouping：Streams 会被所有的 Bolt 的 Tasks 进行复制。由于存在数据重复处理 ，所以需要谨慎使用。 5）Global grouping：整个 Streams 会进入 Bolt 的其中一个 Task，通常会进入 id 最小 的 Task。 6）None grouping：当前 None grouping 和 Shuffle grouping 等价，都是进行随机分发 。 7）Direct grouping：Direct grouping 只能被用于 direct streams 。使用这种方式需要由 Tuple 的生产者直接指定由哪个 Task 进行处理。 8）Local or shuffle grouping：如果目标 Bolt 有 Tasks 和当前 Bolt 的 Tasks 处在同一 个 Worker 进程中，那么则优先将 Tuple Shuffled 到处于同一个进程的目标 Bolt 的 Tasks 上，这样可以最大限度地减少网络传输。否则，就和普通的 Shuffle Grouping 行为一致。Hadoop架构与Storm的区别MapReduce作业最终会完成计算并结束运行，而Topology将持续处理消息（直到人为终止）Storm框架Master—Worker的节点方式Storm使用Zookeeper来作为分布式协调组件★Storm工作流程Storm客户端提交ToPology任务到NimbusNimbus将提交的ToPology进行分片，分成一个个Task，指定相应的Supervisor，并把Task和Supervisor的信息提交到Zookeeper集群Supervisor去Zookeeper集群上认领自己的Task，并通知Worker执行任务Worker收到具体任务后开始进行Task的处理Spark Streaming开源的分布式实时流数据处理框架，基于Apache Spark计算引擎构建而成，可以实现高吞吐量、低延迟的实时数据处理。基本原理：是将实时输入数据流以时间片（秒级）为单位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据最主要的抽象是DStreamSpark Streaming与Storm的比较最大的区别：Spark Streaming无法实现毫秒级的流计算，而Storm可以实现毫秒级响应第十二章 Flink简介Flink是Apache软件基金会的一个顶级项目，是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架，并且可以同时支持实时计算和批量计算。Flink的主要特性包括：批流一体化、精密的状态管理、事件时间支持以及精确一次的状态一致性保障等Flink 不仅可以运行在包括 YARN、 Mesos、Kubernetes等在内的多种资源管理框架上，还支持在裸机集群上独立部署Flink 已经可以扩展到数千核心，其状态可以达到 TB 级别，且仍能保持高吞吐、低延迟的特性。世界各地有很多要求严苛的流处理应用都运行在 Flink 之上。大数据lambda架构包含两层，批处理层和实时处理层。在批处理层中，采用MapReduce、Spark等技术进行批量数据处理，而在 实时处理层中，则采用Storm、Spark Streaming等技术进行数据的实时处理。流处理架构消息传输层：Kafka流处理层：Flink★流处理架构正在逐步取代传统数据处理架构和Lambda架构，成为大数据处理架构的一种新趋势。一方面，由于流处理架构中不存在一个大型集中式数据库，因此，避免了传统数据处理架构中存在的“数据库不堪重负”的问题。另一方面，在流处理架构中，批处理被看成是流处理的一个子集，因此，就可以用面向流处理的框架进行批处理，这样就可以用一个流处理框架来统一处理流计算和批量计算，避免了Lambda架构中存在的“多个框架难管理”的问题。Flink的优势（1）同时支持高吞吐、低延迟、高性能 （2）同时支持流处理和批处理 （3）高度灵活的流式窗口 （4）支持有状态计算 （5）具有良好的容错性 （6）具有独立的内存管理 （7）支持迭代和增量迭代为什么Flink是良好的流计算框架？流处理架构需要具备低延迟、高吞吐和高性能的特性，而目前从市场上已有的产品来看，只有Flink可以满足要求。Storm虽然可以做到低延迟，但是无法实现高吞吐，也不能在故障发生时准确地处理计算状态。Spark Streaming通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实时处理能力。Flink实现了Google Dataflow流计算模型，是一种兼具高吞吐、低延迟和高性能的实时流计算框架，并且同时支持批处理和流处理。此外，Flink支持高度容错的状态管理，防止状态在计算过程中因为系统异常而出现丢失。因此，Flink就成为了能够满足流处理架构要求的理想的流计算框架。Flink应用事件驱动型应用（某一件事一旦发生，系统就会运转）反欺诈、异常检测、基于规则的报警、业务流程监控、Web 应用（社交网络）数据分析应用（侧重于分析）电信网络质量监控、移动应用中的产品更新及实验评估分析、消费者技术中的实时数据即席分析、大规模图分析数据流水线应用（日常性的操作，给定一些数据，就要做一些事情）实时查询索引构建、电子商务中的持续ETLFlink技术栈物理部署层Runtime核心层APIS & Library层Flink体系架构JobManagerTaskManagerFlink编程模型（不同级别的抽象）第十三章 图计算这一部分建议也看一下书，我也没怎么学明白图结构型数据图数据结构很好地表达了数据之间的关联性许多非图结构的大数据，也常常会被转换为图模型后进行分析关联性计算是大数据计算的核心传统图计算算法的不足之处（1）常常表现出比较差的内存访问局部性 （2）针对单个顶点的处理工作过少 （3）计算过程中伴随着并行度的改变可能的解决方案（1）为特定的图应用定制相应的分布式实现：通用性不好（2）基于现有的分布式计算平台进行图计算：在性能和易用性方面往往无法达到最优（3）使用单机的图算法库：比如BGL、LEAD、NetworkX、JDSL、Standford GraphBase和FGL等，但是，在可以解决的问题的规模方面 具有很大的局限性（4）使用已有的并行图计算系统：比如，Parallel BGL和CGM Graph，实现了很多并行图算法，但是，对大规模分布式系统非常重要的一些方面（比如容错），无法提供较好的支持图计算软件基于遍历算法的、实时的图数据库以图顶点为中心的、基于消息传递批处理的并行引擎。主要是基于BSP模型实现的并行图处理系统BSP——并行计算模型一个超步包括：局部计算：使用局部数据进行计算通信：将计算结果发送给相邻节点栅栏同步：各个节点等待所有其他节点完成计算和通信操作后再进入下一个超步Pregel简介Pregel是一种基于BSP模型实现的并行图处理系统Pregel作为分布式图计算的计算框架，主要用于图遍历、最短路径、 PageRank计算等等Pregel图计算模型以有向图作为输入顶点包含的信息：Vertex Value：顶点的值，即顶点在计算中需要处理的数据。messages：接收到的消息，即其他顶点发送给该顶点的消息。Out edges：出边列表，即连接到该顶点的边的列表。Active flag：激活标志，用于指示该顶点是否需要进行计算。采用MapReduce实现PageRank的计算过程包括三个阶段：第一阶段：解析网页分析一个页面的链接数并赋初值第二阶段：PageRank分配多次迭代计算页面的PageRank值第三阶段：收敛阶段由一个非并行组件决定是否达到收敛一般判断是否收敛的条件是所有网页的PageRank值不再变化，或者 运行30次以后我们就认为已经收敛了PageRank算法在Pregel和MapReduce中实现方式的区别Pregel将PageRank处理对象看成是连通图，而MapReduce则将其看成是键值对Pregel将计算细化到顶点，同时在顶点内控制循环迭代次数，MapReduce则将计算批量化处理，按任务进行循环迭代控制图算法如果用MapReduce实现，需要一系列的MapReduce的调用。从一个阶段到下一个阶段，它需要传递整个图的状态，会产生大量不必要的序列化和反序列化开销。而Pregel使用超步简化了这个过程第四篇 大数据应用第十五、十六、十七章 大数据应用互联网 生物医学 其他领域1 互联网推荐系统推荐系统是自动联系用户和物品的一种工具。通过研究用户的兴趣偏好，进行个性化计算。推荐系统可发现用户的兴趣点，帮助用户从海量信息中去发掘自己潜在的需求长尾理论：在大量可供选择的产品或服务中，超过80%的销售额来自于那些销售量少、但种类繁多的“长尾”产品或服务，而不是那些销售量大、但种类少的“热门”产品或服务热门推荐：无法实现长尾商品的推荐个性化推荐：发掘用户的行为记录，找到用户的个性化需求推荐系统包括以下几类：专家推荐基于统计的推荐：统计信息，热门推荐基于内容的推荐：机器学习算法，基于内容发现相似内容协同过滤推荐：利用相似用户或相似商品推荐混合推荐：结合多种推荐算法推荐系统包括3个组成模块：用户建模模块：分析用户需求推荐对象建模模块：分析对象种类推荐算法模块：将推荐结果展示给用户★协同过滤基于用户的协同过滤（UserCF）：推荐系统最古老的办法，根据用户之间的相似度来进行推荐，即找到与目标用户兴趣相似的其他用户，把这些用户喜欢的商品推荐给目标用户。关键步骤：计算用户与用户之间的兴趣相似度，常用算法：泊松相关系数、余弦相似度、调整余弦相似度缺点：随着用户数目的增大，用户相似度计算复杂度越来越高；相关性较弱，难以对推荐结果作出解释，容易受大众影响而推荐热门物品基于物品的协同过滤（ItemCF）：目前运用最多的办法，根据商品之间的相似度来进行推荐，即找到与目标商品相似的其他商品，把这些商品推荐给用户。缺点：往往会出现多样性不足、推荐新颖度较低的问题二者的区别：UserCF算法的推荐更偏向社会化，而ItemCF算法的推荐更偏向于个性化2 生物医学3 其他应用