Loading... ## 第一章：大数据概述 ### 一、信息科技需要处理的三大核心问题 1. 信息存储 2. 信息传输 3. 信息处理 #### 为大数据时代到来提供的技术支撑 1. 存储设备容量不断增加 2. CPU处理能力大幅提升 3. 网络带宽不断增加 ### 二、数据产生方式的变革  ### 三、大数据4V概念(能简要概括) * **数据量大(Volume)**：根据IDC作出的估测，数据一直都在以每年50%的速度增长，也就是说每两年就增长一倍（大数据摩尔定律）；人类在最近两年产生的数据量相当于之前产生的全部数据量。 * **数据类型繁多(Variety)**：大数据是由结构化和非结构化数据组成的。其中10%的结构化数据，存储在数据库中。而90%的非结构化数据，它们与人类信息密切相关。 * **处理速度快(Velocity)**：从数据的生成到消耗，时间窗口非常小，可用于生成决策的时间非常少。因此，数据处理和分析的速度通常要达到秒级响应，这一点与传统的数据挖掘有着本质的不同，后者通常不要给出实时分析结果。 * **价值密度低(Value)**：价值密度低，商业价值高。 ### 四、大数据对思维方式的影响 1. 全样而非抽样 2. 效率而非精确 3. 相关而非因果 ### 五、大数据技术的不同层面及其功能  ### 六、大数据计算模式  ### 七、云计算关键技术 * **虚拟化**：是将一台计算机虚拟为多台相互独立的逻辑计算机。虚拟化的资源可以是硬件也可以是软件 虚拟化技术：`VMware`<br>容器虚拟化技术：`Docker` * **分布式存储**：基于分布式文件系统 `GFS`，在此基础上又实现了 `HDFS`、`BigTable`、`HBase` * **分布式计算**：并行编程模型 `MapReduce`，把一个大数据集切分成多个小数据集，分不到不同的机器上进行并行处理，极大提高了数据处理速度，可以有效满足许多应用对海量数据的批处理需求。 * **多租户**：目的在于使大量用户能够共同享用一堆栈的软硬件资源，每个用户按需使用资源，能够对软件服务器进行客户化配置，而不影响其他用户使用。 核心包括：数据隔离、客户化配置、架构扩展和性能定制。 ### 八、物联网关键技术 * **识别和感知技术**：包括二维码、RFID、传感器等 * **网络与通信技术**：包括短距离无线通信（蓝牙、Wi-Fi、RFID、ZigBee、NFC等）和远程通信技术（互联网、移动通信网络、卫星通信网络等） * **数据挖掘与融合技术** --- ## 第二、三章：大数据处理架构Hadoop、HDFS ### 一、分布式文件系统概念 **分布式文件系统**是一种通过网络实现文件在多台主机上进行分布式存储的文件系统。 分布式文件系统的设计一般采用“客户机/服务器”（Client/Server）模式，客户端以特定的通信协议通过网络与服务器建立连接，提出文件访问请求，客户端和服务器可以通过设计访问权限来限制请求方对底层数据存储块的访问。 ### 二、HDFS文件块 HDFS默认一个块**64MB**，一个文件被分成多个块，以块作为存储单位块的大小远远大于普通文件系统，可以**最小化寻址开销**。 **抽象块概念的好处（意义）：** * **支持大规模文件存储**：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量。 * **简化系统设计**：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据。 * **适合数据备份**：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性 ### 三、名称节点、数据节点的功能与工作原理 #### 功能  #### 工作原理 **（1）NameNode** 在HDFS中，名称节点（`NameNode`）负责管理分布式文件系统的命名空间（`Namespace`），保存了两个核心的数据结构，即 `FsImage`(**镜像**)和 `EditLog`(**日志**) * FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据 * 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作 在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。 一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件。 名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新。 **（2）DataNode** 数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。 ### 四、第二名称节点的意义与功能 #### 意义 2NN 并非 NN 的热备。当 NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。它是用来保存名称节点中对 HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode 一般是单独运行在一台机器上。 #### 功能 1. 辅助NameNode，分担其工作量。 2. 定期合并 fsimage 和 fsedits，并推送给 NameNode。 3. 在紧急情况下，可辅助恢复 NameNode。 #### 原理  ### 五、HDFS冗余存储的定义与意义 #### 定义 作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上。 #### 意义 1. 加快数据传输速度 2. 容易检查数据错误 3. 保证数据可靠性 ### 六、HDFS数据存放策略、读取策略 #### 数据存放策略 * 第一个副本：放置在上传文件的数据节点；如果是集群外提交，则随机挑选一台磁盘不太满、CPU不太忙的节点。 * 第二个副本：放置在与第一个副本不同的机架的节点上。 * 第三个副本：与第一个副本相同机架的其他节点上。 * 更多的副本：随机节点。 一般情况下副本系数为**3**，这种方式减少了机架间的写流量，从而提高了写的性能。机架故障的机率远小于节点故障。这种方式并不影响数据可靠性和可用性的限制，并且它确实减少了读操作的网络聚合带宽，因为文件块仅存在两个不同的机架，而不是三个。 #### 数据读取策略 * HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID * 当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据 ### 七、HDFS三种数据错误及其恢复方法 #### 1.名称节点出错 名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。 #### 2.数据节点出错 每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。 这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子。名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本。 * HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置。 #### 3.数据出错 网络传输和磁盘错误等因素，都会造成数据错误。客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据。 在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面。当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块 --- ## 第四章：分布式数据库HBase ### 一、HBase生态系统   ### 二、HBase的数据模型相关概念 1. **表**：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。 2. **行**：每个HBase表都由若干行组成，每个行由行键（row key）来标识。 3. **列族**：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元。 4. **列限定符**：列族里的数据通过列限定符（或列）来定位。 5. **单元格**：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]。 6. **时间戳**：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。  ### 二、数据坐标的含义 HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即**`[行键, 列族, 列限定符, 时间戳]`** 如上图 | 键 | 值 | | ------------------------------------------ | ------------- | | ["201505003","Info","email",1174184619081] | "xie@qq.com" | | ["201505003","Info","email",1174184620720] | "you@163.com" | ### 三、概念视图与物理视图的实际含义 * **概念视图**：概念视图是HBase的逻辑视图，我们可以把HBase的表视为一个稀疏、多维的映射关系，通过“四维坐标”定位特性数据。 HBase是稀疏存储的，因此某些列可以是空白的。（需要注意的是，在概念视图上面有些列是空白的，这样的列实际上并不会被存储，当请求这些空白的单元格时，会返回null值。如果在查询的时候不提供时间戳，那么会返回距离现在最近的那一个版本的数据，因为在存储的时候，数据会按照时间戳来排序。） * **物理视图**：物理视图是HBase的实际存放方式，基于列的存储方式，一个列族的数据一起存放。 ### 四、HBase三层结构  --- ## 第五章：NoSQL数据库 ### 一、NoSQL数据库的含义与特点 #### 含义  #### 特点 1. 灵活的可扩展性 2. 灵活的数据模型 3. 与云计算紧密融合 ### 二、关系数据库在WEB 2.0时代的局限 与 WEB 2.0不适用关系型数据库的原因 #### 关系数据库在WEB 2.0时代的局限 1. 无法满足海量数据的管理需求 2. 无法满足数据高并发的需求 3. 无法满足高可扩展性和高可用性的需求 #### WEB 2.0不适用关系型数据库的原因 1. Web2.0网站系统通常不要求严格的数据库事务 2. Web2.0并不要求严格的读写实时性 3. Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能） ### 三、四大类型NoSQL数据库的定义,特点,代表性产品 #### 键值数据库 **键值数据库**会使用哈希表，表中有一个特定的Key和一个指针指向特定的Value。Key可以用来存储和检索具体的Value。Value对数据库不可见，且可以存储任意类型数据。  #### 列族数据库 **列族数据库**一般采用列族数据模型，数据库有多个行构成，每个行包含多个列族，不同的行可以具有不同数量的列族，属于同一列族的数据会被存放在一起。每行数据通过一个行键进行定位，与这个行键对应的是一个列族。  #### 文档数据库 **文档数据库**通过键来定位一个文档。文档是此数据库的最小单位。“文档”其实是一个数据记录，这个记录能够对包含的数据类型和内容进行“自我描述”。XML文档、HTML文档和JSON 文档就属于这一类。文档数据库可以根据键或基于文档内容来构建索引，主要用于存储并检索文档数据。  #### 图数据库 图是数学概念，图用来表示一个对象集合，包括定点以及连接定点的两边。 **图数据库**使用图作为数据模型来存储数据，可以高效地存储不同顶点之间的关系。图数据库专门用于处理具有高度相关关联关系的数据，可以高效的处理实体之间的关系。  ### 四、NOSQL的三大基石 #### CAP * **`C（Consistency）`**：**一致性**，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据 * **`A:（Availability）`**：**可用性**，是指快速获取数据，可以在确定的时间 内返回操作结果，保证每个请求不管成功或者失败都有响应； * **`P（Tolerance of Network Partition）`**：**分区容忍性**，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。 **CAP问题选择：** * **`CA`**：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差 * **`CP`**：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对外提供服务 * **`AP`**：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据  #### BASE BASE的基本含义是基本可用（Basically Availble）、软状态（Softstate）和最终一致（Eventual consistency）： * **基本可用** 基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。 * **软状态** “软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。 * **最终一致性** 一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到最新的值。 #### 最终一致性 * **因果一致性**：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守一般的最终一致性规则 * **“读己之所写”一致性**：可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值 * **单调读一致性**：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值 * **会话一致性**：它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话 * **单调写一致性**：系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性，否则就非常难以编程了 --- ## 第六章：云数据库 ### 一、云数据库的概念 **云数据库**是部署和虚拟化在云计算环境中的数据库。云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法，它极大地增强了数据库的存储能力，消除了人员、硬件、软件的重复配置，让软、硬件升级变得更加容易。云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点。 ### 二、云数据库的特性 1. **动态可扩展**：理论上具有无限可扩展性，满足不断增加的数据存储需求。 2. **高可用性**：不存在单点失效问题。 3. **较低的使用代价**：通常用“多租户”的方式，共享资源可以节省开销且不会产生不必要的资源浪费。 4. **易用性**：只需要一个有效的URL就可以使用云数据库。 5. **高性能**：采用大型分布式存储服务集群，支撑海量数据访问，多机房自动冗余备份，自动读写分离。 6. **免维护**：由云数据库服务商提供专业服务，无需用户去维护。 7. **安全**：提供数据隔离，不同应用的数据会存在不同的数据库中而不会相互影响；提供安全性检查，可以及时发现并拒绝恶意攻击性访问；数据提供多点备份，确保不会发生数据丢失。 --- ## 第七、八章：MapReduce 和 Hadoop再讨论 ### 一、MapReduce基本概念与“计算向数据靠拢” #### MapReduce基本概念 MapReduce是一种并行编程模型，用于大规模数据集（大于1TB）的并行计算，它将复杂的、运行于大规模集群上的并行计算过程高度抽象到两个函数：Map和Reduce。MapReduce极大地方便了分布式编程工作，编程人员在不会分布式并行编程的情况下，也可以很容易将自己的程序运行在分布式系统上，完成海量数据集的计算。 #### “计算向数据靠拢” 因为移动数据需要大量的网络传输开销，尤其是在大规模数据环境下，这种开销尤为惊人。所以，移动计算要比移动数据更加经济。 在一个集群中，只要有可能，MapReduce框架就会将Map程序就近地在HDFS数据所在的节点运行，即将计算节点和存储节点放在一起运行，从而减少了节点间的数据移动开销。 ### 二、MapReduce工作流程与各个执行阶段工作 #### 工作流程 把一个大的MapReduce作业，先拆分成许多个Map任务在多台机器上并行执行，每个Map任务通常运行在数据存储的节点上。（这样，计算和数据就可以放在一起运行，不需要额外的数据传输开销。）当Map任务结束后，会生成以<key,value>形式表示的许多中间结果。然后，这些中间结果会被分发到多个Reduce任务在多台机器上并行执行，具有相同key 的<key,value>会被发送到同一个Reduce任务那里，Reduce任务会对中间结果进行汇总计算得到最后结果，并输出到分布式文件系统中。  #### 各个执行阶段 1. MapReduce框架使用InputFormat模块做Map前的预处理，比如验证输人的格式是否符合输人定义，然后，将输人文件切分为逻辑上的多个InputSplit，InputSplit是 MapReduce对文件进行处理和运算的输人单位，只是一个逻辑概念，每个InputSplit并没有对文件进行实际切割，只是记录了要处理的数据的位置和长度。 2. 因为InputSplit是逻辑切分而非物理切分，所以还需要通过RecordReader(RR）根据InputSplit中的信息来处理InputSplit 中的具体记录，加载数据并转换为适合Map任务读取的键值对，输入给 Map任务。 3. Map任务会根据用户自定义的映射规则，输出一系列的<key,value>作为中间结果。 4. 为了让Reduce可以并行处理Map的结果,需要对Map的输出进行一定的分区(Portition )、排序(Sort)、合并(Combine)、归并(Merge）等操作，得到<key,value-list>形式的中间结果，再交给对应的Reduce进行处理，这个过程称为Shuffle。从无序的<key,value>到有序的<key,value-list>，这个过程用Shuffle（洗牌）来称呼是非常形象的。 5. Reduce 以一系列<key,value-list>中间结果作为输入，执行用户定义的逻辑，输出结果给OutputFormat模块。 6. OutputFormat模块会验证输出目录是否已经存在以及输出结果类型是否符合配置文件中的配置类型，如果都满足，就输出Reduce的结果到分布式文件系统。   ### 三、MapReduce的WORDCOUNT执行实例计算过程 ```Java public class WordCount { public static class TokenizerMapper /** * Mapper<输入key, 输入value, 输出key, 输出value> * 输入key：当前读取某一行数据 距离文件起始为值的 偏移量 * 输入value：当前某一行数据的内容 * 输出key：某个单词 * 输出value：某个单词出现的次数 */ extends Mapper<Object, Text, Text, IntWritable>{ //计数器 private final static IntWritable one = new IntWritable(1); //文本获取，相当于String private Text word = new Text(); /** *map(输入key, 输入value, Context context) * @param key：某一行偏移量 * @param value：某一行内容 * @param context：上下文对象：map -shuffle-reduce */ public void map(Object key, Text value, Context context ) throws IOException, InterruptedException { //以空白字符为分隔符拆分 StringTokenizer itr = new StringTokenizer(value.toString()); //迭代每个元素 while (itr.hasMoreTokens()) { //类型转换String->Test word.set(itr.nextToken()); //给每个元素标“1”，传给下一个阶段shuffle(默认):key-单词，value-单词对应1的数组集[1,1,1],再到Reduce context.write(word, one); } } } public static class IntSumReducer /** * Reducer<输入key, 输入value（元素类型 1）, 输出key, 输出value> */ extends Reducer<Text,IntWritable,Text,IntWritable> { private IntWritable result = new IntWritable(); /** * reduce(输入key, 输入values（集合 [1,1,1]）,Context context) */ public void reduce(Text key, Iterable<IntWritable> values, Context context ) throws IOException, InterruptedException { //出现次数 int sum = 0; for (IntWritable val : values) { //累加数组中的每个 1 sum += val.get(); } result.set(sum); context.write(key, result); } } public static void main(String[] args) throws Exception { //自动加载配置文件 Configuration conf = new Configuration(); String[] otherArgs = new GenericOptionsParser(conf, args).getRemainingArgs(); //输入、输出参数判断 if (otherArgs.length < 2) { System.err.println("Usage: wordcount <in> [<in>...] <out>"); System.exit(2); } Job job = Job.getInstance(conf, "word count"); job.setJarByClass(WordCount.class); job.setMapperClass(TokenizerMapper.class); job.setCombinerClass(IntSumReducer.class); job.setReducerClass(IntSumReducer.class); job.setOutputKeyClass(Text.class);//字符串类型 job.setOutputValueClass(IntWritable.class);//次数类型 //输入路径 for (int i = 0; i < otherArgs.length - 1; ++i) { FileInputFormat.addInputPath(job, new Path(otherArgs[i])); } //输出路径 FileOutputFormat.setOutputPath(job, new Path(otherArgs[otherArgs.length - 1])); System.exit(job.waitForCompletion(true) ? 0 : 1); } } ``` 假设执行单词统计任务的MapReduce作业中，有3个执行Map任务的Worker和1个执行Reduce任务的Worker。一个文档包含3行内容，每行分配给一个Map任务来处理。 Map操作的输入是<key,value>形式，其中，key是文档中某行的行号，value是该行的内容。Map操作会将输入文档中每一个单词。以<key,value>的形式作为中间结果进行输出，如下图所示：  然后，在Map端的Shuffle过程中，如果用户没有定义Combiner函数，则Shuffle过程会把具有相同key的键值对归并(Merge)成一个键值对，如下图所示。具体而言，对于若干个具有相同key的键值对<k1,v1>,<k2,v2>…<kn,vn>，会被归并成一个新的键值对<k1,<v1,v2,…,vn>>。比如，在上图最上面的Map任务输出结果中,存在key都是"World"的两个键值对<"World",1>,经过Map端的Shuffle过程以后,这两个键值对会被归并得到一个键值对<"World",<1,1>>,这里不再给出Reduce端的Shuffle结果。然后，这些归并后的键值对会作为Reduce任务的输人，由Reduce任务为每个单词计算出总的出现次数。最后，输出排序后的最终结果就会是:<"Bye",3>、<"Hadoop",4>、<"Hello"3>、<"World",2>。  在实际应用中，每个输人文件被Map函数解析后，都可能会生成大量类似<"the"，1>这样的中间结果，很显然，这会大大增加网络传输开销。在前面介绍Shuffle过程时，我们曾经提到过，对于这种情形，MapReduce支持用户提供Combiner函数来对中间结果进行合并后再发送给Reduce任务，从而大大减少网络传输的数据量。对于图7-7中的Map输出结果，如果存在用户自定义的Combiner函数，则Reduce过程如下图所示。  ### 四、MapReduce实现关系运算 #### 关系的自然运算  --- ## 第九章：Spark ### 一、Spark与Hadoop的对比Spark高性能的原因 1. Spark的计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比Hadoop MapReduce更灵活。 2. Spark提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更高。 3. Spark基于DAG的任务调度执行机制，要优于Hadoop MapReduce的迭代执行机制。 ### 二、大数据处理的三种类型与其适用的Spark技术栈  ### 三、RDD的设计与运行原理P179-183 RDD采用惰性调用，在RDD的执行过程中，真的的计算发生在RDD的“行动”操作，对于“行动”之前的的所有“转换”操作，Sprak只记录下相互之间的依赖关系，而不会出发真正的计算。 --- ## 第十章：流计算 ### 一、流数据的特征 1. 数据快速持续到达，潜在大小也许是无穷无尽的 2. 数据来源众多，格式复杂 3. 数据量大，但是不十分关注存储，一旦经过处理，要么被丢弃，要么被归档存储 4. 注重数据的整体价值，不过分关注个别数据 5. 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素的顺序 ### 二、批量计算与实时计算的含义 对**静态数据**和**流数据**的处理，对应着两种截然不同的计算模式：**批量计算**和**实时计算** * **批量计算**：以“静态数据”为对象，在充裕时间对海量静态数据进行批处理，如Hadoop。 * **实时计算**：能够实时得到计算结果，一般要求响应时间为秒级。 流数据不适合采用批量计算，因为流数据不适合用传统的关系模型建模。 对于流数据，数据量少时，实时计算不是问题，但是，在大数据时代，数据格式复杂、来源众多、数据量巨大，对实时计算提出了很大的挑战。因此，针对流数据的实时计算——流计算，应运而生。 ### 三、流计算的要求，Hadoop不适用于流计算的原因 #### 流计算系统应达到需求： * 高性能：处理大数据的基本要求，如每秒处理几十万条数据 * 海量式：支持TB级甚至是PB级的数据规模 * 实时性：保证较低的延迟时间，达到秒级别，甚至是毫秒级别 * 分布式：支持大数据的基本架构，必须能够平滑扩展 * 易用性：能够快速进行开发和部署 * 可靠性：能可靠地处理流数据 #### Hadoop不适用于流计算的原因 Hadoop设计的初衷是面向大规模数据的批量处理，每台机器并行运行MapReduce任务，最后对结果进行汇总输出。 MapReduce是专门面向静态数据的批量处理的，内部各种实现机制都为批处理做了高度优化，不适合用于处理持续到达的动态数据。 **结论：** 鱼和熊掌不可兼得，Hadoop擅长批处理，不适合流计算 ### 四、流计算处理流程 流计算的处理流程一般包含三个阶段：**数据实时采集**、**数据实时计算**、**实时查询服务**  #### 数据实时采集 数据实时采集阶段通常采集多个数据源的海量数据，需要保证实时性、低延迟与稳定可靠。 数据采集系统的基本架构一般有以下三个部分： * Agent：主动采集数据，并把数据推送到Collector部分。 * Collector：接收多个Agent的数据，并实现有序、可靠、高性能的转发。 * Store：存储Collector转发过来的数据（对于流计算不存储数据）。  #### 数据实时计算 数据实时计算阶段对采集的数据进行实时的分析和计算，并反馈实时结果。 经流处理系统处理后的数据，可视情况进行存储，以便之后再进行分析计算。在时效性要求较高的场景中，处理之后的数据也可以直接丢弃。  #### 实时查询服务 实时查询服务：经由流计算框架得出的结果可供用户进行实时查询、展示或储存。 传统的数据处理流程，用户需要主动发出查询才能获得想要的结果。而在流处理流程中，实时查询服务可以不断更新结果，并将用户所需的结果实时推送给用户。虽然通过对传统的数据处理系统进行定时查询，也可以实现不断地更新结果和结果推送，但通过这样的方式获取的结果，仍然是根据过去某一时刻的数据得到的结果，与实时结果有着本质的区别。 Last modification：August 14, 2022 © Allow specification reprint Like 1 喵ฅฅ
3 comments
爱了
大佬太强了吧