《大数据日知录》的读后感10篇
《大数据日知录》是一本由张俊林著作，电子工业出版社出版的平装图书，本书定价：69.00元，页数：404，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
十一放假期间过了这本书一遍，读完最大的感受是有助于建立大数据技术的整体大局观。这书从大数据基本理论、各种架构组件以及算法几个角度归纳了目前常见的大数据技术，理论部分讲的还挺透彻，也包括了方方面面的技术点，真挺全面，可以当个工具书。
其中的数据结构、集群资源管理和图数据库这三章感觉最好，有完整的理论归纳也有具体小栗子，体系感强也好理解。机器学习的内容虽然非常实用，覆盖了多数常用的互联网应用，也是实际使用中的常用算法，但缺点也很明显，感觉对于初学者有点深，要具备一些基本的机器学习知识恐怕才能理解，最好先找本机器学习入门书学下再看这块内容。总体还是推荐。
《大数据日知录》读后感(二)：大数据日知录读书笔记
第1章 数据分片与路由
• 主流的大数据存储与计算系统采用横向扩展（Scale Out）的方式支持系统可扩展性，通过增加机器数目来获得水平扩展能力。因此，对于待存储处理的海量数据，需要通过数据分片（Shard/Partition）来将数据进行切分并分配到各个机器中去，数据分片后，如何能够找到某条记录的存储位置称为数据路由。
• 数据分片实现系统的水平扩展，数据复制来保证数据的高可用性
• 哈希分片
○ Round Robin：Round Robin就是哈希取模法。假设有K台物理机，通过一下哈希函数实现数据分片：H（key）=hash（key）mod K
§ 优点：实现简单。但缺乏灵活性，新增一台物理机要把所有数据按改编后的函数再次分配一遍
○ 虚拟桶（Virtual Buckets）：Membase（现更名为Couchbase）是一个内存分布式NoSQL数据库，在待存储记录和物理机之间引入了虚拟桶层，所有记录首先通过哈希函数映射到对应的虚拟桶，记录和虚拟桶是多对一的映射关系，即一个虚拟桶包含多个记录信息；第二层映射是虚拟桶和物理机之间的映射关系，也是多对一的映射，一个物理机可以容纳多个虚拟桶，即Membase通过内存表管理这层映射关系。Membase的虚拟桶层就是对应的“数据分片”层，一个虚拟桶即是一个数据分片。Key-Partition映射采用哈希函数，而Partition-machine采用表格管理实现。
§
§ 与Round Robin相比，Membase引入了虚拟桶层，将原先由记录直接到物理机的单层映射解耦为两级映射，加强了系统的扩展灵活性。当新加入机器时，将某些虚拟桶从原先分配的机器重新分配给新机器，只需要修改Partition-machine映射表受影响的个别条目就能实现扩展，具有较强的灵活性。
○ 一致性哈希（consistent hashing）：分布式哈希表（DHT）是P2P网络和分布式存储中厂常用的技术，是哈希表的分布式扩展，即在多机分布环境，每台机器承载部分数据的存储情形下，如何通过哈希方式对数据进行增删改查等操作的方法。一致性哈希是DHT的一种实现方法：
§ 一致性哈希可以将海量数据分布到集群中的不同机器节点中，实现数据分片功能。下图是将哈希空间表示为长度为5的二进制数值（m=5）的“一致性哈希”算法的示意图。因为m=5，所以其哈希空间可以表达的数值范围为0～31，“一致性哈希”算法将哈希数值空间按照大小组成一个首尾相接的环状序列。对于每台机器，可以根据其IP和端口号经过哈希函数映射到哈希数值空间内，这样不同的机器就成了环状序列中的不同节点（图1-4中环上的5个大圆即代表不同的机器，分别用Ni来代表，其中的i代表其哈希空间对应的数值），而这台机器则负责存储落在一段有序哈希空间内的数据，比如N14节点就存储主键经过哈希后落在6～14范围内的键值数据，而N5节点则存储30～31以及0～5范围内的键值数据。同时，每个机器节点记录环中的前趋节点和后继节点地址位置，使之成为一个真正的有向环。
§
§ 路由问题：在每个机器节点配置路由表（Finger Table），路由表存储m条路由信息（m为哈希空间的二进制数值比特位长度，上面例子中m=5），其中第i项（0≤i≤m−1）路由信息代表距离当前节点为2i的哈希空间数值所在的机器节点编号。
□
§ 加入新节点：
§ 如果P2P网络中新加入一个机器节点Nnew，首先Nnew必须能够和目前P2P网络中任意一个节点Nx建立联系，通过Nx按照“路由问题”所述路由算法查询Nnew的对应哈希值H（Nnew）=new，可以找到Nnew的后继节点Ns，假设Ns的前趋节点为Np，那么为了能够将Nnew加入P2P网络，需要做以下两件事情：
□ 改变Np、Nnew和Ns对应已经发生变化的前趋节点和后继节点记录，以体现新的网络架构。
□ 其二，数据的重新分片与分布，具体而言就是将Ns节点中存储的应该由Nnew承载的数据（即Ns节点上哈希值小于等于new的记录）迁移到Nnew节点上。
§ 相比于Round Robin数据分片方法，由于其将集群机器数目这一变量从哈希函数中移出，转而将机器及记录主键都映射到哈希数值空间，以此来建立机器与数据记录之间的映射关系。这相当于解除了机器与数据分布函数之间的直接耦合，加入了哈希空间作为解耦层（key-partition和partition-machine映射采用同一个哈希函数），这样不论是新加入机器还是机器故障导致某些机器失效，都只影响当前机器的后继节点上的数据分布，对于集群中其他机器中的数据无任何影响，所以大大增强了数据分片的灵活性。当然，由于其管理P2P网络的复杂性，也导致一致性哈希算法维护成本很高，这是其为提高数据分片灵活性带来的代价。
• 范围分片首先将所有记录的主键进行排序，然后在排好序的主键空间里将记录划分成数据分片，每个数据分片存储有序的主键空间片段内的所有记录。在实现具体存储系统时，往往保持一个数据分片的映射表，记录表每一项记载数据分片的最小主键及其对应的物理机地址（如图）。在对记录／增／删／改时，查找映射表就可以找到对应存储这个记录所在数据分片的物理机，至于数据分片在物理机的管理方式往往采用LSM树（Log Structured Merge Tree），这是一种高效写入的数据索引结构
○
• LSM树：设计思想非常朴素：将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘，不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近修改操作，所以写入性能大大提升，读取效率较低。基于LSM树实现的HBase的写性能比Mysql高了一个数量级，读性能低了一个数量级。
○ LSM树原理把一棵大树拆分成N棵小树，它首先写入内存中，随着小树越来越大，内存中的小树会flush到磁盘中，磁盘中的树定期可以做merge操作，合并成一棵大树，以优化读性能。
○ hbase在实现中，是把整个内存在一定阈值后，flush到disk中，形成一个file，这个file的存储也就是一个小的B+树，因为hbase一般是部署在hdfs上，hdfs不支持对文件的update操作，所以hbase这么整体内存flush，而不是和磁盘中的小树merge update，这个设计也就能讲通了。内存flush到磁盘上的小树，定期也会合并成一个大树。整体上hbase就是用了lsm tree的思路。
第2章 数据复制与一致性
• CAP
○ CAP是对“Consistency/Availability/Partition Tolerance”的一种简称，其分别代表：强一致性、可用性和分区容忍性。对于一个大规模分布式数据系统来说，CAP三要素不可兼得，同一个系统至多只能实现其中的两个，而必须放宽第3个要素来保证其他两个要素被满足。
§ 强一致性：即在分布式系统中的同一数据多副本情形下，对于数据的更新操作体现出的效果与只有单份数据是一样的。
§ 可用性：客户端在任何时刻对大规模数据系统的读／写操作都应该保证在限定延时内完成。
§ 分区容忍性：在大规模分布式数据系统中，网络分区现象，即分区间的机器无法进行网络通信的情况是必然会发生的，所以系统应该能够在这种情况下仍然继续工作。
○ 在绝大多数系统未产生网络分区的情形下，应该尽可能保证AC两者兼得，也即大多数情况下考虑CAP三者兼得，当发生网络分区时，系统应该能够识别这种状况并对其进行正确处理，具体而言，应该分为3个步骤：首先能够识别网络分区发生，然后在网络分区场景下进入明确的分区模式，此时可能会限制某些系统操作，最后在网络分区解决后能够进行善后处理，即恢复数据的一致性或者弥补分区模式中产生的错误。
• ACID原则，ACID是关系数据库系统采纳的原则
○ 原子性（Atomicity）：是指一个事务要么全部执行，要么完全不执行。也就是不允许一个事务只执行了一半就停止。以银行转账为例，这是一个典型的事务，它的操作可以分成几个步骤：首先从A账户取出要转账的金额，A账户扣除相应的金额，之后将其转入B账户的户头，B账户增加相同的金额。这个过程必须完整地执行，否则整个过程将被取消，回退到事务未执行前的状态。不允许出现从A账户已经扣除金额，而没有打入B账户这种情形。
○ 一致性（Consistency）：事务在开始和结束时，应该始终满足一致性约束条件。比如系统要求A+B=100，那么事务如果改变了A的数值，则B的数值也要相应修改来满足这种一致性要求；这里需要注意的是，尽管CAP和ACID都有关于一致性的定义，但是两者的含义是不同的，即两个C代表了不同含义，这点要特别注意。
○ 事务独立（Isolation）：如果有多个事务同时执行，彼此之间不需要知晓对方的存在，而且执行时互不影响，不允许出现两个事务交错、间隔执行部分任务的情形，也即事务之间需要序列化执行。
○ 持久性（Durability）：事务的持久性是指事务运行成功以后，对系统状态的更新是永久的，不会无缘由地回滚撤销。
• 大多数大数据环境下的云存储系统和NoSQL系统则采纳BASE原则
○ 基本可用（Basically Available）。在绝大多数时间内系统处于可用状态，允许偶尔的失败，所以称为基本可用。
○ 软状态或者柔性状态（Soft State），是指数据状态不要求在任意时刻都完全保持同步，到目前为止软状态并无一个统一明晰的定义，但是从概念上是可理解的，即处于有状态（State）和无状态（Stateless）之间的中间状态。
○ 最终一致性（Eventual Consistency）。与强一致性相比，最终一致性是一种弱一致性，尽管软状态不要求任意时刻数据保持一致同步，但是最终一致性要求在给定时间窗口内数据会达到一致状态。
○
○ 强一致性：对于连接到数据库的所有进程，看到的关于某数据的数据值是一致的，如果某进程对数据进行了更新，所有进程的后续读操作都会以这个更新后的值为基准，直到这个数据被其他进程改变为止。
○ 最终一致性是一种弱一致性。它无法保证某个数值x做出更新后，所有后续针对x的操作能够立即看到新数值，而是需要一个时间片段，在这个时间片段之后可以保证这一点，而在这个时间片段之内，数据也许是不一致的，这个系统无法保证强一致性的时间片段被称为“不一致窗口”（Inconsistency Window）。
○ 因果一致性：发生在进程之间有因果依赖关系的情形下。当进程A将x的数值更新为v2后，会通过Notify(A,B,x,v2）来通知进程B数值已经做出改变，进程B在接收到通知后，之后的操作会以新值作为基础进行读／写，即进程A和进程B保持了数据的因果一致性。而对进程C来说，在不一致窗口内可能还是会看到x的旧数值v1。
○ “读你所写”一致性：是因果一致性的特例：进程A把数据x更新为数值v2后，立即给自己发出了一条通知Notify(A,A,x,v2)，所以进程A之后的操作都是以新数值v2作为基础。其他进程未受影响，在不一致窗口内仍旧可能会看到x的旧数值v1。
○ 单调读一致性：是最终一致性的另外一种变体。它保证如果某个进程读取到数据x的某个版本数据v2，那么系统所有后续的读取操作都不能看到比v2更老版本的数值
○ 单调写一致性：对于某个进程来说，单调写一致性可以保证其多次写操作的序列化，如果没有这种保证，对于应用开发者来说是很难进行程序开发的。
• 副本更新策略：
○ 同时更新：
§ 不通过任何一致性协议直接同时更新多个副本数据。此时存在同时更新的数据不一致问题
§ 通过某种一致性协议预先处理，一致性协议用来唯一确定不同更新操作的执行顺序，这样可以保证数据一致性，但是由于一致性协议有处理成本，所以请求延时会有所增加。
○ 主从式更新：数据的多副本中存在一个主副本（Master Replica），其他副本为从副本，则可被称为主从式更新策略。
§ 同步方式：主副本等待所有从副本更新完成之后才确认更新操作完成，这可以确保数据的强一致性，但是会存在较大请求延时
§ 异步方式：
□ 所有读请求都要通过主副本来响应，即任意一个副本接收到读请求后将其转发给主副本
□ 任意一个副本都可以响应读请求，那么请求延时将会大大降低，但是这可能导致读结果不一致的问题，因为有些副本还存着旧版本的数据信息
§ 混合方式：主副本首先同步更新部分从副本数据，然后即可确认更新操作完成，其他副本通过异步方式获得更新，消息系统Kafka在维护数据副本一致性时即采取此种混合方式。
○ 任意节点更新：数据更新请求可能发给多副本中的任意一个节点，然后由这个节点来负责通知其他副本进行数据更新。所以其特殊性在于：有可能有两个不同客户端在同一时刻对同一个数据发出数据更新请求，而此时有可能有两个不同副本各自响应。
§ 同步通知其他副本
§ 异步通知其他副本
• 一致性协议：
○ 两阶段提交协议（Two-Phrase Commit，2PC）：保证在分布式事务中，要么所有参与进程都提交事务，要么都取消事务，即实现ACID中的原子性（A）的常用手段。
第3章 大数据常用的算法与数据结构
• 布隆过滤器（Bloom Filter，BF）：常被用来检测某个元素是否是巨量数据集合中的成员，具有很好的空间和时间效率，尤其是空间效率极高。BF会产生误判（如果某个成员不在集合中，有可能BF会得出其在集合中的结论），但是不会发生漏判（False Negative）的情况，即如果某个成员确实属于集合，那么BF一定能够给出正确判断。
• SkipList（跳跃表）：是一种可替代平衡树的数据结构，不像平衡树需要强制保持树的平衡，SkipList依靠随机生成数以一定概率来保持数据的平衡分布。
尽管在最坏情况下SkipList的效率要低于平衡树，但是大多数情况下其效率仍然非常高，其插入、删除、查找数据的时间复杂度都是O(log(N))。除了高效外其实现和维护也非常简单，所以在很多大数据系统中在维护有序列表高效读／写的场景下会采用SkipList。就是在插入节点的时候，随机决定该节点应该有多少个指向后续节点的指针，有几个指针就称这个节点是几层的（Level）
• LSM树（Log-structured Merge-tree）的本质是将大量的随机写操作转换成批量的序列写，这样可以极大地提升磁盘数据写入速度，所以LSM树非常适合对写操作效率有高要求的应用场景。但是其对应付出的代价是读效率有所降低，这往往可以引入Bloom Filter或者缓存等优化措施来对读性能进行改善。
• Merkle哈希树：用来在海量数据下快速定位少量变化的数据内容（变化原因可能是损毁、篡改或者正常变化等）。比如在P2P下载系统BitTorrent、Git版本管理工具、比特币以及Dynamo、Riak、Cassandra等NoSQL系统中都得到了应用。
• Snappy是Google开源出的高效数据压缩与解压缩算法库，其目标并非是最高的数据压缩率，而是在合理的压缩率基础上追求尽可能快的压缩和解压缩速度，其压缩和解压缩速度极快，可以在单核处理器上达到250MB/s的压缩效率和500MB/s的解压缩效率。与此同时，Snappy相比其他压缩方案占用CPU时间更少。
• Cuckoo哈希：可以有效解决哈希冲突（Hash Collisions）问题。Cuckoo哈希具有很多优良特性，比如可以在O（1）时间复杂度查找和删除数据，可以在常数时间内插入数据等。其有大约50%的哈希空间利用率。SILT存储系统使用Cuckoo哈希的变体来作为外存数据的索引。SILT的全称是“小索引大表”（Small Index Large Table），这是CMU（美国卡内基·梅隆大学）设计的高效利用内存的高性能基于Flash的KV存储系统，其在Flash存储KV数据，在内存建立数据索引，其存储效率极高，单机可以存储十亿量级的数据并提供很高的读写性能。
第4章 集群资源管理与调度
• 采用独立的资源管理与调度系统而非静态划分资源有如下好处：
○ 集群整体资源利用率高
○ 可增加数据共享能力
○ 支持多类型计算框架和多版本计算框架。
• 资源管理抽象模型：从概念上讲，资源管理与调度系统的主要目的是将集群中的各种资源通过一定策略分配给用户提交到系统里的各种任务，常见的资源主要包括内存、CUP、网络资源与磁盘I/O资源4类。而这个概念模型主要强调三要素：资源组织模型、调度策略和任务组织模型。不同的资源管理与调度系统基本遵循上述概念模型，但是具体在三要素的实现方式上有差异。
○
○ 通用资源管理框架
§
• 调度系统设计的基本问题：
○ 异质性往往指的是组成元素构成的多元性和相互之间较大的差异性。在资源管理与调度场景下，往往有两类异质性需要考虑：资源异质性和工作负载（Workload）异质性
§ 资源异质性：从系统所拥有的资源角度来看的，要考虑这种硬件的资源差异性，一般通过将资源分配单位细粒度划分为较小单元来解决这个问题。
§ 工作负载异质性：因为各种服务和功能特性各异，对资源的需求差异也很大
○ 数据局部性（Data Locality）：为海量数据分布在大规模集群的不同机器中，如果移动数据会产生大量低效的数据网络传输开销，而计算代码相比而言数量小得多，所以移动计算代码到数据所在地而非移动数据到计算任务所在地。
§ 在资源管理与调度语境下，有3种类型的数据局部性：
□ 节点局部性（Node Locality：可以将计算任务分配到数据所在的机器节点，这是数据局部性最优的一种情形，因为完成计算无须任何数据传输）
□ 机架局部性（Rack Locality：虽然计算任务和所需数据分属两个不同的计算节点，但是这两个节点在同一个机架中，这也是效率较高的一种数据局部性，因为机架内机器节点间网络传输速度要明显高于机架间网络传输速度）
□ 全局局部性（Global Locality：需要跨机架进行网络传输，会产生较大的网络传输开销）
○ 抢占式调度与非抢占式调度
§ 抢占式调度是指对于某个计算任务来说，如果空闲资源不足或者出现不同任务共同竞争同一资源，调度系统可以从比当前计算任务优先级低的其他任务中获取已分配资源，而被抢占资源的计算任务则需出让资源停止计算，在后续步骤中继续重新申请新资源来完成后续计算，有时甚至需要废弃已经完成的计算任务重新执行。Omega调度系统采用了抢占式调度方式。
§ 非抢占式调度则只允许从空闲资源中进行分配，如果当前空闲资源不足，则须等待其他任务释放资源后才能继续向前推进。Mesos采用了非抢占式调度。
§ 对于强调高优先级任务执行效率的调度策略来说，往往会采纳抢占式调度方式，以此来保证这些任务即使在资源不足的情况下也能快速完成。而对于更强调资源分配公平性的调度策略来说，往往会采纳非抢占式调度方式。
○ 资源分配粒度（Allocation Granularity）：大数据场景下的计算任务往往由两层结构构成：作业级（Job）和任务级（Task）。一个作业由多个并发的任务构成，任务之间的依赖关系往往形成有向无环图（DAG），典型的MapReduce任务则是一种比较特殊的DAG关系。
§ 一种极端的情况是需要将作业的所有所需资源一次性分配完成，这常被称为“群体分配”（Gang Scheduler）或者“全分或不分”（All-or-Nothing）策略。MPI任务就是一种典型的需要采纳群体分配策略的任务类型。
§ 分配粒度是采取增量满足式分配策略，即对于某个作业来说，只要分配部分资源就能启动一些任务开始运行，随着空闲资源的不断出现，可以逐步增量式分配给作业其他任务以维持作业不断地向后推进，以MapReduce为代表的批处理任务一般采用增量满足式分配策略。
§ 有一种特殊的增量满足式分配策略被称作“资源储备”（Resource Hoarding）策略。这是指只有分配到一定量的资源作业才能启动，但是在未获得足够资源的时候，作业可以先持有目前已分配的资源，并等待其他作业释放资源，这样从调度系统不断获取新资源并进行储备和累积，直到分配到的资源量达到最低标准后开始运行。采取“资源储备”策略的调度，在作业启动前，已分配给该作业的资源一直处于闲置状态。
○ 饿死（Starvation）与死锁（Dead Lock）问题
§ 计算任务“饿死”现象，指的是这个计算任务持续长时间无法获得开始执行所需的最少资源量，导致一直处于等待执行的状态。
§ 死锁问题则是由于资源调度不当导致整个调度系统无法继续正常执行。
§ 调度系统出现死锁必然表现为某些作业处于“饿死”状态，但是有计算任务处于“饿死”情形并不一定意味着调度系统处于死锁状态。
○ 资源隔离方法：资源隔离最常用的手段是Linux容器（Linux Container，LXC），YARN和Mesos都采用了这种方式来实现资源隔离。LXC是一种轻量级的内核虚拟化技术，可以用来进行资源和进程运行的隔离，通过LXC可以在一台物理主机上隔离出多个相互隔离的容器，目前有开源版本。LXC在资源管理方面依赖于Linux内核的cgroups子系统，cgroups子系统是Linux内核提供的一个基于进程组的资源管理的框架，可以为特定的进程组限定可以使用的资源。
• 资源管理与调度范型：
○
○ 集中式调度器（Monolithic Scheduler）：在整个系统中只运行一个全局的中央调度器实例，所有之上的框架或者计算任务的资源请求全部经由中央调度器来满足，因此，整个调度系统缺乏并发性且所有调度逻辑全部由中央调度器来实现。
○ 两级调度器（Two-Level Scheduler）：Mesos、YARN和Hadoop On Demand系统是3个典型的两级调度器系统。
§ 中央调度器：可以看到集群中所有机器的可用资源并管理其状态，它可以按照一定策略将集群中的所有资源分配给各个计算框架，中央调度器级别的资源调度是一种粗粒度的资源调度方式
§ 框架调度器：只能看到由中央调度器分配给自己的资源。各个计算框架在接收到所需资源后，可以根据自身计算任务的特性，使用自身的调度策略来进一步细粒度地分配从中央调度器获得的各种资源。
§ 两级调度器由于在计算框架层面存在第二级资源调度，而这可以提供一种比较天然的并发性，所以整体调度性能较好，也适合大规模集群下的多任务高负载计算情形，具有较好的可扩展性。但是由于中央调度器的存在，使得这种并发是一种悲观并发控制，即中央调度器在做出将某些资源分配给哪个框架的决策过程中，必须依次顺序进行，并需要对目前待决策的资源加锁以避免不同框架的资源申请冲突。而这种悲观并发性会影响系统的整个并发性能。
○ 状态共享调度器（Shared-State Scheduler）：每个计算框架可以看到整个集群中的所有资源，并采用相互竞争的方式去获取自己所需的资源，根据自身特性采取不同的具体资源调度策略，同时系统采用了乐观并发控制手段解决不同框架在资源竞争过程中出现的需求冲突。
• 资源调度策略：
○ FIFO策略：最简单的资源调度策略，提交的作业按照提交时间先后顺序或者根据优先级次序将其放入线性队列相应位置，在资源调度时按照队列先后顺序，先进先出地进行调度与资源分配。FIFO是Hadoop默认的调度策略，很明显这种策略过于简单，在多用户场景下，新加入的作业很容易出现长时间等待调度的现象。
○ 公平调度器（Fair Scheduler）是Facebook为Hadoop开发的多用户多作业调度器。其将用户的任务分配到多个资源池（Pool），每个资源池设定资源分配最低保障和最高上限，管理员也可以指定资源池的优先级，优先级高的资源池会被分配更多的资源，当一个资源池资源有剩余时，可以临时将剩余资源共享给其他资源池。
○ 能力调度器（Capacity Scheduler）是Yahoo为Hadoop开发的多用户调度器，适合用户量众多的应用场景，与公平调度器相比，其更强调资源在用户之间而非作业之间的公平性。
○ 延迟调度策略（Delay Scheduling）往往会作为其他调度策略的辅助措施来增加调度的数据局部性，以此来增加任务执行效率。
○ 主资源公平调度策略（Dominant Resource Fair Scheduling）是Mesos中央调度器采用的公平调度策略，也是最大最小公平算法的一个具体体现。最大最小公平算法的基本思想是：最大化目前分配到最少资源量的用户或者任务的资源量。这个算法常常用来对单个资源进行公平分配，而DRF则将其扩展到了多个资源的公平分配场景下。
• Mesos是美国加州大学伯克利分校AMPLab实验室推出的资源管理与调度系统，从其范型来讲是一个典型的两级调度器。Mesos的设计哲学吸收了类似操作系统中微内核的思想，在中央调度器一级采取极简功能和极小接口，只是根据一定策略决定分配给各个框架多少资源，将数据局部性保证等具体资源调度策略下推到各个框架，这样可以减少中央调度器的负载，增加调度效率，同时也因为其极简设计策略，使得中央调度器支持将来新出现的框架改动最小化，增加了调度系统的可扩展性和健壮性。
• YARN是Hadoop 2.0的重要组成部分，其全称是“另一个资源协调器”（Yet Another Resource Negotiator）。YARN的整体架构图如图4-6所示，其最主要的构件包括：唯一的资源管理器（RM）、每个作业一个的“应用服务器”（AM）以及每个机器一个的“节点管理器”（Node Manager，NM）。RM负责全局的资源管理工作，其内部主要功能部件包括：调度器、AM服务器（AMService/ApplicationMasters，AMS）、Client-RM接口以及RM-NM接口。调度器主要提供各种公平或者能力调度策略，支持可插拔方式，系统管理者可以制定全局的资源分配策略。Client-RM接口负责按照一定协议管理客户提交的作业；RM-NM接口主要和各个机器的NM通过心跳方式进行通信，以此来获知各个机器可用的容器资源以及机器是否产生故障等信息；AMS负责系统内所有AM的最初启动与运行状态管理。
○
○
第5章 分布式协调系统
• Chubby锁服务：由Google公司研发的针对分布式系统协调管理的粗粒度锁服务，一个Chubby实例大约可以负责1万台4核CPU机器相互之间对资源的协同管理。这种锁服务的主要功能是让众多客户端程序进行相互之间的同步，并对系统环境或者资源达成一致认知。
○ Chubby的设计哲学是强调协调系统的可靠性与高可用性及语义易于理解，而不追求处理读／写请求的高吞吐量及在协调系统内存储大量数据。
○ Chubby的理论基础是Paxos一致性协议，Paxos是在完全分布环境下，不同客户端能够通过交互通信并投票，对于某个决定达成一致的算法
○ Chubby与ZooKeeper相比，两者设计思想有重大差异，即ZooKeeper强调系统的高吞吐而Chubby并不追求这一点。
○
○ 从客户端程序来看，Chubby类似于文件系统的目录和文件管理系统，并在此基础上提供针对目录和文件的锁服务。Chubby的文件主要存储一些管理信息或者基础数据，Chubby要求对文件内容一次性地全部读完或者写入，这是为了尽可能地抑制客户端程序写入大量数据到文件中，因为Chubby的目的不是数据存储，而是对资源的同步管理，所以不推荐在文件中保存大量数据。
○ Chubby的会话机制工作如下：客户端向主控服务器发出KeepAlive消息（一个RPC调用），服务器在接收到KeepAlive消息后，阻塞这个RPC调用，直到客户端原先的租约接近过期为止。此时，服务器解除RPC阻塞，KeepAlive调用返回，同时服务器通知客户端说你拥有一个新的租约；客户端在接收到返回信息后立即再次向服务器发出KeepAlive消息，如此循环往复
○ Chubby允许客户端在本地缓存部分服务器数据，而由Chubby来保证缓存数据和服务器端数据完全一致。在很多情况下，客户端所需数据从本地缓存即可读出，这样大大减轻了客户端对服务器的通信压力。为了保持数据一致性，“主控服务器”维护一个缓存表，记录了哪个客户端缓存了什么数据信息；当“主控服务器”接收到某项数据的修改请求时，首先阻塞这个修改数据请求，并查询该缓存表，通知所有缓存该数据的客户端该数据从此无效；客户端在接收到通知后向服务器确认收到该通知，当“主控服务器”接收到所有相关客户端的确认信息后继续执行数据修改请求操作。
• ZooKeeper是Yahoo开发并开源出的一套可扩展高吞吐分布式协调系统，目前已经在各种NoSQL数据库及诸多开源软件中获得广泛使用。正确地使用ZooKeeper可以很方便地解决各种分布式系统的管理协调问题
○ ZooKeeper服务由若干台服务器构成，每台服务器内存中维护相同的类似于文件系统的树形数据结构，其中的一台通过ZAB原子广播协议选举作为主控服务器，其他的作为从属服务器。客户端可以通过TCP协议连接任意一台服务器，如果客户端是读操作请求，则任意一个服务器都可以直接响应请求；如果是更新数据操作（写数据或者更新数据），则只能由主控服务器来协调更新操作；如果客户端连接的是从属服务器，则从属服务器会将更新数据请求转发到主控服务器，由其完成更新操作。
§
○ Zookeeper的内存数据模型类似于传统的文件系统模式，由树形的层级目录结构组成，其中的节点称为Znode，Znode可以使文件，也可以是目录。
§
○ ZooKeeper被广泛使用在各种分布式数据存储与管理系统中，应用开发者可以组合ZooKeeper提供的接口原语来完成各种分布式环境下的协调工作。
§ 领导者选举Leader Election：分布式系统中的主从结构，主控制器负责全局管理控制工作，从节点负责具体的任务计算或数据存储管理。架构清晰、分工明确，但存在主控制器单点的问题。为防止单点失效，往往采取一主一备或一主多备，当主控制器发生故障，由某个台备机接管并成为新的主控机，称为领导者选举。
§ 配置管理Configuration Management：配置文件存储在ZooKeeper某节点Zc中，分布式系统ongoing中的客户端进程在启动时从Zc中读取配置信息，并设置观察标记。若配置沃森将内容在以后被改变，客户端进程会接收到Zc的变化通知，再次读取Zc节点内容以捕获变化点并同时再次设置观察标记，这样以后每次配置文件的变化客户端阿斗可以及时收到通知。
§ 组成员管理Group Membership：动态监控一个组内成员的变化情况。ZooKeeper可以使用临时节点来进行。
§ 任务分配：将不同的任务负载分别分配到多台可用服务器。对于监控进程来说，可以创建任务队列管理节点tasks，所有新进入系统的任务都可以在tasks节点下创建子节点，监控进程观察tasks节点的变化。当有新增任务task-j时ZooKeeper通知监控进程，监控进程找到新增任务并将其分配给机器i，然后在machines目录下对应的m-i节点创建子节点task-j，这意味着将task-j任务分配给了机器m-i。每台工作服务器在machines节点下创建对应子节点，并监听这个子节点的变化，当m-i发现有新增子节点task-j时说明有新分配的任务，可以读出任务信息并执行任务；在执行完task-j后，机器m-i将machines/m-i下的task-j子节点删除，也同时删除tasks节点下的task-j子节点，代表任务已经执行完成，监控进程通过监听tasks可以获知这一情况。通过这种方式可以在监控进程和不同服务器间相互同步来完成任务的分配工作。
§ 锁管理（Locks）：
○ ZooKeeper的实际应用：
§ ZooKeeper在HBase的使用场景包括主控服务器选举与主备切换，作为配置管理在ZooKeeper中存储系统启动信息，发现新的子表服务器及侦测子表服务器是否依然存活等。
§ Twitter的流式计算系统Storm利用ZooKeeper作为主控进程和工作进程状态信息存储场所，使得即使系统出现故障，也可以将进程快速切换到备份机运行。
第6章 分布式通信
• 序列化与远程过程调用框架：
○ 远程过程调用（Remote Procedure Call，RPC）：允许程序调用位于网络中其他机器上的进程，当机器A上的进程调用机器B上的进程时，A上的调用进程被挂起，而B上的被调用进程开始执行，调用方可以通过参数将信息传递给被调用方，然后通过B上的进程返回的结果得到所需的信息。RPC通过以上机制可以隐藏下层的具体通信过程，这大大简化并透明化了网络间进程调用过程，是大规模分布式系统中位于不同机器上进程间通信的黏合剂。RPC框架会融合数据序列化与反序列化功能，以实现高效的数据存取与通信。很多应用直接使用JSON或者XML来作为数据通信的格式。相比较专门的序列化与反序列化框架来说，因为其必须反复传输相同的数据Schema信息，所以在通信效率方面不如专用序列化框架高。
○ 通用的序列化与RPC框架都支持以下特性：接口描述语言（Interface Deｓｃｒｉｐｔion Language，IDL）、高性能、数据版本支持以及二进制数据格式。
○ Protocol Buffer（PB）：是在Google内部广泛使用的序列化与RPC框架，是几乎所有Google服务的黏合剂，开源版本被更多地应用于数据序列化方面。与JSON、XML及Thrift等相比，PB对数据的压缩率是最高的。比如ActiveMQ就使用PB作为消息存取工具。
○ Thrift则是Facebook开源出的序列化与RPC框架，在Facebook内部也得到了广泛的使用。因为RPC功能以及IDL语言比PB表达能力更强（Thrift支持List/Set/Map复杂数据结构，PB不支持），所以Thrift的使用场景更丰富，很多开源系统融入Thrift作为RPC构件，比如Hadoop/HBase/Cassandra/Hypertable/ Scribe等。
○ PB和Thrift在使用流程方面大致相同：首先，使用IDL定义消息体以及PRC函数调用接口。其次，使用工具根据上步的IDL定义文件生成指定编程语言的代码。最后，即可在应用程序中链接使用上一步生成的代码。对于RPC功能来说，调用方和被调用方同时引入后即可实现透明网络访问，如果调用方和被调用方采取不同的语言，只要分别根据IDL定义文件生成不同语言库即可实现两者的编码语言解耦。
○ Avro是Apache开源的序列化与RPC框架，使用在Hadoop的数据存储与内部通信中。Avro使用JSON作为IDL定义语言，可以灵活地定义数据Schema及RPC通信协议，提供了简洁快速的二进制数据格式，并能和动态语言进行集成。
• 消息队列：分布式系统构件之间通过传递消息可以解除相互之间的功能耦合，这样可以减轻子系统之间的依赖，使得各个子系统或者构件可以独立演进、维护或者重用。消息队列是在消息传输过程中保存消息的容器或中间件，其主要目的是提供消息路由并保障消息可靠传递。消息是指构件之间信息传递的单位。
○ 消息中间件都支持两种模式的队列
§ 消息队列模式即消息生产者将消息存入队列，消息消费者从队列消费消息
§ Pub-Sub模式则是消息生产者将消息发布到指定主题的队列中，而消息消费者订阅指定主题的队列消息，当订阅的主题有新消息时，消息消费者可以通过拉取（Pull）或者消息中间件通过推送（Push）的方式将消息消费掉
○ Kafka：是Linkedin开源的采用Pub-Sub机制的分布式消息系统，其具有极高的消息吞吐量，较强的可扩展性和高可用性，消息传递低延迟，能够对消息队列进行持久化保存，且支持消息传递的“至少送达一次”语义。
§ 整体架构：主要由3种类型角色构成：消息生产者（Producer）、代理服务器（Broker）和消息消费者（Consumer）。消息生产者产生指定Topic（主题）的消息并将其传入代理服务器集群，代理服务器集群在磁盘存储维护各种Topic的消息队列，订阅了某个Topic的消息消费者从代理服务器集群中拉取（Pull）出新产生的消息并对其进行处理。消费者可以自主控制消费速率，避免采用推送（Push）方式的弊端：如果消费者处理速度跟不上消息生产者产生消息的速度时，消息会大量积压。
□
§ 消息的Topic代表其所属类型，即在内部对应某个名字的消息队列
§ ISR副本管理机制：Kafka通过消息副本机制提供了高可用的消息服务，其副本管理单位不是Topic消息队列，而是Topic的数据分片（Partition）。在配置文件里可以指定数据分片的副本个数，在多个副本里，其中一个作为主副本（Leader），其他作为次级副本（Slave）。所有针对这个数据分片的消息读／写请求都由主副本来负责响应，次级副本只是以主副本数据消费者的方式从主副本同步数据；当主副本发生故障时，Kafka将其中某个次级副本提升为主副本，以此来达到整个消息系统的高可用性。Kafka使用ISR（In-Sync Replicas）机制来保证数据一致性，这个集合备份数据的特点是即时和主副本数据保持一致，而另外一个集合的备份数据允许其消息队列落后于主副本的数据。在做主备切换时，只允许从ISR集合中选择候选主副本，这样即可保证切换后新的主副本数据状态和老的主副本保持一致。在数据分片进行消息写入时，只有ISR集合内所有备份都写成功才能认为这次写入操作成功。在具体实现时，Kafka利用ZooKeeper来保存每个ISR集合的信息，当ISR集合内成员变化时，相关构件也便于通知。
§ Kafka能够高效处理大批量消息的一个重要原因就是将读／写操作尽可能转换为顺序读／写，Kafka涉及将文件内容通过网络进行传输，为了提升效率，Kafka采用了Linux操作系统的SendFile调用。使用SendFile，则可以避免多次数据复制，操作系统可以直接将数据从内核页缓存中复制到网卡缓存，这样可以大大加快整个过程的速度。
□ 正常的网络传输的数据通道：
® 首先，操作系统将数据从磁盘复制到操作系统内核的页缓存中。
® 其次，应用将数据从内核缓存复制到应用空间的缓存中。
® 再次，应用将数据写回内核中的Socket缓存区。
® 最后，操作系统将数据从Socket缓存区复制到网卡的缓存，然后将其通过网络发出。
• 应用层多播通信（Application-Level Multi-Broadcast）：指分布式应用系统内各个节点组织成一定的组织结构，在此结构上实现多接收方的数据通信。
○ Gossip协议：也被称为“感染协议”（Epidemic Protocol），用于研究网络环境下尤其是P2P环境下的多播通信问题
§ 信息传播模型：Gossip协议用来尽快地将本地更新数据通知到网络中的所有其他节点。
□ 全部通知模型（Best Effort或Direct Mail）：当某个节点有更新消息，则立即通知所有其他节点；其他节点在接收到通知后，判断接收到的消息是否比本地消息要新（可以通过时间戳或者版本信息来判断），如果是的话则更新本地数据，否则不采取任何行为。此种信息传播方式简单但是容错性不佳，比如信息发送者如果在通知过程中发生故障抑或消息在通信过程中丢失，都会造成集群中有些节点无法获知最新数据更新内容。
□ 反熵模型（Anti-Entropy）：是最常用的“Gossip协议”，比如Dynamo就用其来进行故障检测。之所以称之为“反熵”，因为我们知道“熵”是信息论里用来衡量系统混乱无序程度的指标，熵越大说明系统越无序、包含的有用信息含量越少；而“反熵”则反其道而行，因为更新的信息经过一定轮数（Round）的传播后，集群内所有节点都会获得全局最新信息，所以系统变得越来越有序，这就是“反熵”的物理含义。
® 在反熵模型中，节点P随机选择集群中另外一个节点Q，然后与Q交换更新信息；Q如果信息有更新，则类似P一样传播给任意其他节点（此时P也可以再传播给其他节点），这样经过一定轮数的信息交换，更新的信息就会快速传播到整个网络节点。其传播过程就是我们常说的“一传十，十传百”的模式。在反熵模型中，P和Q交换信息的方法有以下3种。
◊ Push模式。P将更新信息推送给Q，Q判断是否比本地信息要新
◊ Pull模式。P从Q获取其信息，如果比P本地信息要新，则P更新本地信息
◊ Push-Pull模式。P和Q同时进行Push和Pull操作，即两者同时互相通知对方更新
◊ Push模式与Pull模式相比，其传播效率是刚开始快，但是到后来逐渐变慢，所以整体而言Pull模式传播效率要高于Push模式。实验表明Push-Pull是传播效率最高的，Pull次之，Push相对效率最低
□ 散布谣言模型（Rumor Mongering）：和反熵模型相比，增加了传播停止判断。被拒绝的次数越多越沉默，但它不能保证所有节点都能最终获得更新。更新过程如下：
《大数据日知录》读后感(三)：又是一本笔记型技术书
从覆盖面上看，这本书还是涉及到很广的知识点。但从编排和讲解角度看，除了很多清单图谱也都是直接抓现成的。当然也不能全怪作者，毕竟讲逻辑的东西如果要画图细说那这本书估计再写个几年也完不成。
现在世面上十分流行这种笔记型的技术书。作者们把自己多年掌握的知识、技能、心得整理一下，总结写下来就能出书了，然后找些名人写个推荐序。其实这些书更像是集大成的博客。如果以“能从书中找到自己需要的内容”这个角度看，那么无疑这些书都算对得起标题和价钱。但要说好不好，我觉得就得看这本书有没有留下思考的痕迹，而我在这本书里似乎看到更多是各种内容的拼接。
我觉得如果就大数据思路进行深入的讲解，可以把架构和算法分开细说，尤其是算法多介绍基础即可。这本书对大部分人来说恐怕都直接用不上，比较适合深入提高时候作为目录指引。
《大数据日知录》读后感(四)：很难得的大数据技术类书籍
因为做这方面的工作，所以之前买过几本大数据方面的书，有《大数据时代》这种概念普及书，也有几本技术书，比较下来技术书还是推荐这本，内容比较全，大部分章节也比较深入，个别章节写得有些简略，感觉没展开，可能跟篇幅有关系，要是都展开讲估计得再多好几百页了，好在关键点都提到了，如果需要可以找对应参考文献了解细节。说实话大数据的水不是一般的深，国内能整理出这种书也算不容易，作者的付出还是能看得出的，附录里推荐的必读文献质量也都很高。不过我觉得其实作者费这么大劲写得很全面是吃力不讨好，搞算法的看架构看得一头雾水，搞架构的看算法估计也不会太明白，毕竟这两个方向思维模式还是有很大差异。
《大数据日知录》读后感(五)：由此入门，登堂大数据
一、什么是大数据？
“大数据”成为社会流行词汇，已经有两三年了，2015年9月国家发布《促进大数据发展行动纲要》，2017年12月，中共中央政治局再次就实施国家大数据战略进行集体学习。那么究竟什么是大数据？数据大到什么程度才算大数据呢？正本清源，“大数据”词汇最早出现在上个世纪90年代，但真正的爆发式流行是最近几年的事情。“随着IT技术的快速发展，我们逐步买入了GB时代、TB时代，而现在正处于从PB到EB的迁移阶段。（P2G4L5-6）” 下图是权威机构预测的全球数据总量趋势。
关于大数据的概念，我们常常见到nV的表达，其缘起于IBM，后来一再被延展，到现在Wikipedia上已经扩展为了Volume、Variety、Velocity、Value、Variability、Veracity等等。实际上，大数据还应注意到这种表述“规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合”，这才是大数据的本质所在。
大数据已经从一个词汇，成为了一个技术词汇，逐渐发展到当前的妇孺皆知，其涉及内容之广、覆盖人群之多，恐怕也是史无前例的。
二、大数据涉及哪些内容
大数据作为社会热词，已经从一个技术词语，逐渐发展成为了事关国计民生、甚至每一个人的具有丰富内涵的内容聚合体。但就社会而言，关注度可以从两个方面去切分，一是大数据技术的从业者，二是大数据的利用者，虽然二者不能严格的区分，但我们可以大致归类一下，前者应该关注大数据技术，而后者基本不需要，只需要利用大数据技术的成果即可。
从这两个角度来分，再看大数据涉及的内容，也能够相对清晰了：大数据的技术，以及利用大数据技术衍生的社会化应用。下图是对大数据技术的一个概览图。
大数据技术内容很丰富，而大数据应用的场景和需求更加复杂多样，每一个关心大数据的人都能够从找到自己领域的海量信息。
三、大数据技术应该关注哪些点
上图呈现了相对完善的大数据技术体系，内容看来也是令人头皮发紧，作为技术人员介入仿佛困难重重。
电子工业出版社的《大数据日知录》一书，紧抓时代脉搏，为国内学者、技术人员、学生系统梳理总结和详细讲解了大数据的核心技术：大数据理论基础、体系结构、存储、处理，全书共17章，以及硬件体系结构及常用性能指标、大数据必读文献两个附录。主要内容框架如下图。
实事求是的讲，《大数据日知录》是一本有一定深度的入门书。通过阅读和实践书中的代码段或案例，有助于读者尽快习得相应的知识并进入该领域，但要成为真正的技术大牛，还需要在各个知识点深度学习。
《大数据日知录》读后感(六)：大数据技术索引
对大数据的初步感官是使用hive(hadoop SQL接口)查询，等结果等的很焦急 ,然后陆续接触到了NoSQL存储（mongodb http://danqingdani.blog.163.com/blog/static/1860941952014110756412/ http://danqingdani.blog.163.com/blog/static/1860941952014214112153146/ ，redis http://danqingdani.blog.163.com/blog/static/18609419520142196591588/），但基本都只使用了查询功能，再就是与数据团队的合作知道了Spagobi,Pentaho等报表工具，周会上知道了日志传输平台容易出数据丢失不同步机器down掉的Bug——kafka消息系统与flume日志收集系统，然后在察看日志分析相关工具（我总是从工具入手来学习某一领域的知识），知道了elasticsearch 与 sphinx搜索引擎，漂亮的kibana前端web UI，在动手进行日志分析的时候，知道了hadoop取数据，序列化数据的解析（protocolBuffer， PB格式的听说却是三年前来自网游通信协议设计，还愚蠢地抱怨为啥不是标准的json格式，不好进行下一步处理）MapReduce批处理方式与Storm流式处理方式。而这本书正好将我陆续知道的一些零星概念串起来了，并确认了自己在大数据处理中的定位是数据分析（计算），不是数据存储，不是数据通信。
如果你仅仅是想在大数据中书皮学一下，看本书第0章的两幅图就OK了。
最后，作者估计是王菲的粉丝，开章语中有5首王菲的歌，我也很喜欢。
《大数据日知录》读后感(七)：大数据日知录
大数据是当前最为流行的热点概念之一，其已由技术名词衍生到对很多行业产生颠覆性影响的社会现象，作为最明确的技术发展趋势之一，基于大数据的各种新型产品必将会对每个人的日常生活产生日益重要的影响。
《大数据日知录：架构与算法》从架构与算法角度全面梳理了大数据存储与处理的相关技术。大数据技术具有涉及的知识点异常众多且正处于快速演进发展过程中等特点，其技术点包括底层的硬件体系结构、相关的基础理论、大规模数据存储系统、分布式架构设计、各种不同应用场景下的差异化系统设计思路、机器学习与数据挖掘并行算法以及层出不穷的新架构、新系统等。《大数据日知录：架构与算法》对众多纷繁芜杂的相关技术文献和系统进行了择优汰劣并系统性地对相关知识分门别类地进行整理和介绍，将大数据相关技术分为大数据基础理论、大数据系统体系结构、大数据存储，以及包含批处理、流式计算、交互式数据分析、图数据库、并行机器学习的架构与算法以及增量计算等技术分支在内的大数据处理等几个大的方向。通过这种体系化的知识梳理与讲解，相信对于读者整体和系统地了解、吸收和掌握相关的优秀技术有极大的帮助与促进作用。
《大数据日知录：架构与算法》的读者对象包括对NoSQL 系统及大数据处理感兴趣的所有技术人员，以及有志于投身到大数据处理方向从事架构师、算法工程师、数据科学家等相关职业的在校本科生及研究生。