一起挑战极限|Hadoop疯狂的技术体系全系列

好，文章就这么简简单单、

清清爽爽的开始了

请开始这次旅行！

Hadoop 是耳熟能详的卓越开源分布式文件存储及处理框架，

它能让用户轻松地开发处理海量数据的应用程序，其主要优点有：

Hadoop 2.0由HDFS、MapReduce和YARN三个系统组成，其中YARN是一个资源管理系统，负责集群资源管理和调度，2.0中YAR允许每个节点（NodeManager）配置可用的CPU和内存资源总量，而中央调度器则会根据这些资源总量分配给应用程序。

HDFS

HDFS(Hadoop Distributed File System) ，Hadoop上的分布式文件系统，适合PB级大量数据的存储，扩展性强，容错性高（默认3副本）。

如图所示HDFS是Master/Slave结构，有NameNode、Secondary NameNode、DataNode这几个角色，理解其架构及工作原理需要弄清的概念：

NameNode：Master节点，管理数据块映射；处理客户端的读写请求；配置副本策略；管理HDFS的名称空间；

Secondary NameNode：分担namenode工作量；是NameNode的冷备份；合并fsimage和fsedits然后再发给namenode。

DataNode：Slave节点，负责存储client发来的数据块block；执行数据块的读写操作。

热备份：b是a的热备份，如果a坏掉。那么b马上运行代替a的工作。

冷备份：b是a的冷备份，如果a坏掉。那么b不能马上代替a工作。但是b上存储a的一些信息，减少a坏掉之后的损失。

Fsimage：元数据镜像文件（文件系统的目录树。）

edits：元数据的操作日志（针对文件系统做的修改操作记录）

机架：HDFS集群由分布在多个机架上的大量DataNode组成，不同机架之间节点通过交换机通信，HDFS通过机架感知策略，使NameNode能够确定每个DataNode所属的机架ID，使用副本存放策略，来改进数据的可靠性、可用性和网络带宽的利用率。

数据块(block)：HDFS最基本存储单元，默认128M，用户可自行设置。

元数据：指HDFS文件系统中，文件和目录的属性信息。HDFS实现时采用镜像文件（Fsimage） + 日志文件（EditLog）的备份机制。

1）文件的镜像文件中内容包括：修改时间、访问时间、数据块大小、组成文件的数据块的存储位置信息。 

2）目录的镜像文件内容包括：修改时间、访问控制权限等信息。

3）日志文件记录的是：HDFS的更新操作。NameNode启动的时候，会将镜像文件和日志文件的内容在内存中合并。把内存中的元数据更新到最新状态。

HDFS读文件

1）客户端显式调用open()函数打开文件。

2）后台通过RPC调用NN服务，获取欲打开文件的文件块信息和文件所在的数据节点。 

3）客户端显式调用read()函数，从第一个数据块开始读取数据，并选择离客户端最近的那个副本。 

4）选择离客户端最近的副本后，客户端直接从DN读取数据。 

5）当前数据块读完后继续连接此文件下一个数据块最近副本所在的DN。 

6）读完数据时，客户端显式调用close()函数。相对于读取本地文件系统数据，HDFS读取数据流程较复杂，但对客户端而言，需显式调用的函数仅为open()、read()和close()，与读取本地文件系统数据的方法基本相同。

HDFS写文件

1）客户端调用create()来创建文件。

2）后台通过RPC调用NN服务，在文件系统的命名空间中创建新文件。 

3）客户端开始写入数据。先将数据写到本地临时文件中，当累积到1个数据块大小时，客户端会从NN获取1个DN列表，同时后台会将该文件块切分成多个数据包（packet）。 

4）每个packet 以流水线方式写入到NN 返回的DN。 

5）最后一个DN 针对每个packet，朝着写入流水线的反方向返回ACK，确认packet成功写入所有DN。 

6）客户端调用close()函数关闭文件，剩余所有数据将写入DN，并关闭与DN的连接。 

7）通知NN写入完毕。

Mapreduce

MapReduce非常简单，易于实现且扩展性强。可以通过它轻易地编写出同时在多台主机上运行的程序，可以使用Ruby、Python、PHP和C++等非Java类语言编写map和reduce程序。MapReduce适合于处理大量的数据集，因为它会同时被多台主机一起处理，这样通常会有较快的速度。

Hadoop 中数据处理核心是MapReduce 程序设计模型。一个Map/Reduce 作业（job） 通常会把输入的数据集切分为若干数据块，对于独立的数据块，由 map任务（task）以完全并行的方式处理它们。框架会对map的输出先进行排序， 然后把结果输入给reduce任务。通常作业的输入和输出都会被存储在文件系统中。因此，编程主要是 mapper阶段和reducer阶段。

图. MapReduce控制流和数据流

图. MapReduce数据流

单词计数

计算出文件中各个单词的频数。输出结果按照单词的字母顺序进行排序。

数据去重

reduce的输入应该以数据作为key，而对value-list则没有要求。当reduce接收到一个时就直接将key复制到输出的key中，并将value设置成空值。

所以map阶段要完成的任务就是在采用Hadoop默认的作业输入方式之后，将value设置成key,并直接输出（这里输出中的value为空值）。

单表关联

眼睛是不是已经花了？

看表结构就好了，不必纠结具体符号了

在Map阶段，将父子关系与相反的子父关系，同时在各个value前补上前缀-与+标识此key-value中的value是正序还是逆序产生的，之后进入context。MapReduce会自动将同一个key的不同的value值，组合在一起，推到Reduce阶段。在value数组中，根据前缀，我们可以轻松得知，哪个是grandparent，哪个是child。

多表关联

在Map阶段，把所有数据标记成的形式，其中key是id，value则根据来源不同取不同的形式：来源于A的记录，value的值为"a#"+name；来源于B的记录，value的值为"b#"+score。

在reduce阶段，先把每个key下的value列表拆分为分别来自表A和表B的两部分，分别放入两个向量中。然后遍历两个向量做笛卡尔积，形成一条条最终的结果。

Hadoop流

Hadoop流提供给了API允许用户使用任何脚本语言编写map函数或reduce函数。Hadoop流的关键是，它使用UNIX标准流作为程序与Hadoop之间的接口。

因此，任何程序只要可以从标准输入流中读取数据，并且可以写入数据到标准输出流，那么就可以通过Hadoop流使用其他语言编写MapReduce程序的map函数或reduce函数。

bin/Hadoop jar contrib/streaming/Hadoop-0.20.2-streaming.jar –input input –output output –mapper /bin/cat –reducer usr/bin/wc

从这个例子中可以看到，Hadoop流引入的包是Hadoop-0.20.2-streaming.jar，并且具有如下命令：

-input   指明输入文件路径 

-output  指明输出文件路径 

-mapper 制定map函数 

-reducer 指定reduce函数

Hadoop流的工作原理

当一个可执行文件作mapper时，每一个map任务会以一个独立的进程启动这个可执行文件，然后在map任务运行时，会把输入切分成行提供给可执行文件，并作为它的标准输入（stdin）内容。

当可执行文件运行出结果时，map从标准输出（stdout）中收集数据，并将其转化为对，作为map输出。

reduce与map相同，如果可执行文件作为reducer时，reduce任务会启动这个可执行文件，并且将转化为行来作为这个可执行文件的标准输入（stdin）。

然后reduce会收集这个可执行文件的标准输出（stdout）内容，并把每一行转化为对，作为reduce输出。

map与reduce将输出转化为的默认方法是，将每行的第一个tab符号（制表符）之前的内容作为key，之后的内容作为value。如果没有tab符号，那么这一行的所有内容作为key，而value值为null，可以更改。

Hadoop流的命令

Hadoop流命令的具体内容如下表所示：

Hadoop流通用命令是用来配置Hadoop流的Job的。需要注意的是，如果使用这部分配置，则必须将其置于流命令配置之前，否则命令会失败。

Hadoop Streaming 的优缺点

优点：

1. 可以使用自己喜欢的语言来编写 MapReduce 程序（不必非得使用 Java）

2. 不需要像写 Java 的 MR 程序那样 import 一大堆库，在代码里做很多配置，很多东西都抽象到了 stdio 上，代码量显著减少。

3. 因为没有库的依赖，调试方便，并且可以脱离 Hadoop 先在本地用管道模拟调试。

缺点：

1. 只能通过命令行参数来控制 MapReduce 框架，不像 Java 的程序那样可以在代码里使用 API，控制力比较弱。

2. 因为中间隔着一层处理，效率会比较慢。

Hadoop Streaming 比较适合做一些简单的任务，比如用 Python 写只有一两百行的脚本。如果项目比较复杂，或者需要进行比较细致的优化，使用 Streaming 就容易出现一些束手束脚的地方。

Yarn

在没有YARN之前，Hadoop 1.0版本时候， MapReduce做很多的事情，Job Tracker(作业跟踪者)既做资源管理又做任务调度/监控，Task Tracker资源划分过于粗，MapReduce 实现任务分配、资源分配、批量计算的框架图如下：

首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心。

1）他首先做任务分配，需要知道数据分布在哪里，这意味着要和HDFS Metadata Server通讯； 

2）其次要根据数据分布，分配任务给实际机器，这里又基本有两个步骤，先确定有哪些机器是存活的、资源还剩余多少； 

3）另外，根据他们和数据的分布关系，做出任务分配策略；然后开始分配任务，要将MapReduce逻辑分发到各台机器上； 

4）然后，要监控各个机器上Mapper、Reducer实例的任务进度，如果失败要回收资源并重新分配资源，指定数据索引，重新执行

总结下：他需要与集群中的机器定时通信 (heart beat)，需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作，还需要和数据元数据中心通讯，了解数据分布等等。

TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。T

askTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heart beat发送给JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。

风险：JobTracker 是 Map-reduce 的集中处理点，管理事情多，存在单点故障，状态一致性不便保障，很难做到Secondary Standby，从而不便做HA，JobTracker 完成太多的任务造成过多的资源消耗，当 MR job 非常多的时候，会造成很大的内存开销，也增加了 JobTracker failed 风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。

在 TaskTracker 端，以 map/reduce task 数目作为资源衡量标准过于简单，没有考虑到 CPU/内存的占用，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。

在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。

源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。

从操作的角度看MapReduce 框架在有任何重要/不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。

更糟的是，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间，长期以往这就要从优秀的开源系统名单中除名。

Hadoop 2.0中的MapReduce则专门处理数据分析，YARN做为资源管理器存在，YARN主要由Resource Manager、Node Manager、Application Master和Container等组件构成，它是一个master/slave结构，如图：

Resource manager是master，Node manager是slave节点。Resource manager负责对各个node manger上资源进行统一管理和调度。

当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的Application Master，它负责向Resource Manager申请资源，并要求Node Manger启动可以占用一定资源的任务。由于不同的Application Master被分布到不同的节点上，因此它们之间不会相互影响。

Resource Manager是Master上一个独立运行的进程，负责集群统一的资源管理、调度、分配等；Node Manager是Slave上一个独立运行的进程，负责上报节点的状态；App Master和Container是运行在Slave上的组件，Container是yarn中分配资源的一个单位，包涵内存、CPU等资源，yarn以Container为单位分配资源。

Client向Resource Manager提交的每一个应用程序都必须有一个Application Master，它经过Resource Manager分配资源后，运行于某一个Slave节点的Container中，具体做事情的Task，同样也运行与某一个Slave节点的Container中。RM，NM，AM乃至普通的Container之间的通信，都是用RPC机制。

Resource manager

RM是一个全局的资源管理器，集群中只有一个该角色，负责整个系统的资源管理和分配，包括处理客户端请求、启动/监控APP master、监控node manager等。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（Applications Manager，ASM）。

调度器

调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源分配给各个正在运行的应用程序。

需要注意的是，该调度器是一个“纯调度器”，它不再从事任何与具体应用程序相关的工作，比如不负责监控或者跟踪应用的执行状态，也不负责重启因应用执行失败或硬件故障产生的失败任务，这些均交由应用程序相关的Application Master完成。

调度器仅根据各个应用程序的资源需求进行资源分配，而资源分配单位用一个抽象概念“资源容器”（Resource Container，简称Container）表示，Container是一个动态资源分配单位，它将内存、CPU、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。

此外，该调度器是一个可插拔的组件，用户可根据自己的需要设计新的调度器，YARN提供了多种直接可用的调度器，比如Fair Scheduler和Capacity Scheduler等。

应用程序管理器（Application Master）

应用程序管理器负责管理整个系统中所有应用程序，包括应用程序提交、与调度器协商资源以启动Application Master、监控Application Master运行状态并在失败时重新启动它等。

Application Master（AM）

• 管理YARN内运行的应用程序的每个实例。

• 完成数据切分，并为应用程序申请资源并进一步分配给内部任务。

• 负责协调来自resource manager的资源，并通过node manager监视容易的执行和资源使用情况。

Node Manager（NM）

Node manager整个集群有多个，负责每个节点上的资源和使用。负责单个节点上的资源管理和任务，处理来自于resource manager的命令，处理来自域app master的命令。

Node manager管理着抽象容器，这些抽象容器代表着一些特定程序使用针对每个节点的资源。Node manager定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态（CPU和内存等资源）

Container

Container是YARN中的资源抽象，它封装了某个节点上的多维度资源，如内存、CPU、磁盘、网络等，当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container，且该任务只能使用该Container中描述的资源。

需要注意的是，Container不同于MR v1中的slot，它是一个动态资源划分单位，是根据应用程序的需求动态生成的。目前为止，YARN仅支持CPU和内存两种资源，且使用了轻量级资源隔离机制Cgroups进行资源隔离；

Zookeeper

参考文献：https://blog.csdn.net/gs80140/article/details/51496925

在大数据时代，应用服务由很多个独立的程序组成， 这些独立的程序运行在形形色色、千变万化硬件上，如何让一个应用中多个独立的程序协同工作是一件困难的事情。

开发这样的应用容易让开发人员陷入如何使多个程序协同工作的逻辑中，最后导致没时间思考和实现应用程序逻辑；又或者开发人员对协同逻辑关注不够，开发了简单脆弱的主协调器，导致不可靠的单一失效点。

ZooKeeper是分布式系统/软件的协调者，其设计保证分布式程序的健壮性，使得应用开发人员可以更多关注应用本身逻辑，而不是协同工作，ZK是集群的管理者，监视着集群各节点状态，并根据节点的反馈进行下一步合理操作，最终将简单易用的接口和性能高效、功能稳定的系统提供给用户。

分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、配置维护，名字服务、分布式同步、分布式锁和分布式队列等功能。

Hadoop中使用Zookeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等；HBase使用Zookeeper的事件处理确保整个集群只有一个HMaster，察觉HRegionServer联机和宕机，存储访问控制列表等；Kafka使用ZK监控节点状态、存储偏移量，并选择主broker。

角色

构成

简单的说，zookeeper=文件系统+通知机制。

文件系统：Zookeeper维护一个类似文件系统的数据结构：

每个子目录项如 NameService 都被称作为 znode，和文件系统一样，能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的，znode有四种类型的：

• PERSISTENT-持久化目录节点

客户端与zookeeper断开连接后，该节点依旧存在

• PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

• EPHEMERAL-临时目录节点：

客户端与zookeeper断开连接后，该节点被删除

• EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号；

通知机制：客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

配置

ZK通过配置文件来进行控制管理（zoo.cfg配置文件），某些参数是可选的，某些参数是必须的。这些必须的参数就构成了ZooKeeper配置文档的最低配置要求，原生的conf目录中没有zoo.cfg；

啊！！！让人抓狂的家伙们

终于要出现了.....

挺住！

它们来了！！！！

Zoo.cfg的配置：

# the port at which the clients will connect

//zookeeper对外通信端口，默认不用修改

clientPort=2181

# The number of milliseconds of each tick

//Zookeeper服务器心跳时间，单位毫秒

tickTime=2000   

# The number of ticks that the initial

# synchronization phase can take

//投票选举新leader的初始化时间

initLimit=10   

# The number of ticks that can pass between

# sending a request and getting an acknowledgement

//Leader与Follower之间的最大响应时间单位，响应超过syncLimit*tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer

syncLimit=5    

# the directory where the snapshot is stored.

# do not use /tmp for storage, /tmp here is just

# example sakes.

//数据持久化目录，也保存有节点的ID信息，需要自己创建指定

dataDir=/home/xxxx/zookeeperxxxx/data 

//日志保存路径，这个目录必须手工创建指定，否则启动报错。

dataLogDir=/home/xxx/zookeeper/logs

//Session超时时间限制，如果客户端设置的超时时间不在这个范围，那么会被强制设置为最大或最小时间。默认的Session超时时间是在2 *tickTime ~ 20 * tickTime这个范围

maxSessionTimeout=120000

# The number of snapshots to retain in dataDir

//这个参数和下面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个。(No Java system property)New in 3.4.0

autopurge.snapRetainCount=2

# Purge task interval in hours

# Set to "0" to disable auto purge feature

//在上文中已经提到，3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能，但可以运行bin/zkCleanup.sh来手动清理zk日志。

autopurge.purgeInterval=3

//配置zookeepe集群各节点之间通信和选举的端口，其中2888端口号是zookeeper服务之间通信的监听端口，而3888是zookeeper选举通信端口。server.N  N代表这个节点的ID编号，需要用户手工指定各节点对应的编号，编号不能有重复；

server.1=namenode:2888:3888

server.2=datanode1:2888:3888

server.3=datanode2:2888:3888

配置集群节点编号myid

新建文件myid(在zoo.cfg配置的dataDir目录下，此处为/home/xxx/zookeeperxxx/data)，使得myid中的值与server的编号相同，比如namenode上的myid：1;datanode1上的myid：2，以此类推；

配置log4j.properties：

在~/zookeeper/conf/路径下有log4j.properties文件，需要修改host及其他的log路径配置信息；

zoo.cfg 优化

参考 https://www.cnblogs.com/fanweiwei/p/4517012.html

1：默认jvm没有配置Xmx、Xms等信息，可以在conf目录下创建java.env文件

export JVMFLAGS="-Xms512m -Xmx512m   $JVMFLAGS"

2：log4j配置，由于zk是通过nohup启动的，会有一个zookeeper.out日志文件，该文件中记录的是输出到console的日志。log4j中只要配置输出到console即可，zookeeper.out日积月累会不断变大，要放在容量大的磁盘上。

3：zoo.cfg文件中，dataDir是存放快照数据的，dataLogDir是存放写前日志的。这两个目录不要配置成一个路径，要配置到不同的磁盘上。如果磁盘是使用了raid，系统就一块磁盘，那配置到一块磁盘上也可以。写前日志的部分对写请求的性能影响很大，保证dataLogDir所在磁盘性能良好。

4：zoo.cfg文件中skipACL=yes，忽略ACL验证，可以减少权限验证的相关操作，提升一点性能。

5：zoo.cfg文件中forceSync=no，这个对写请求的性能提升很有帮助，是指每次写请求的数据都要从pagecache中固化到磁盘上，才算是写成功返回。当写请求数量到达一定程度的时候，后续写请求会等待前面写请求的forceSync操作，造成一定延时。如果追求低延时的写请求，配置forceSync=no，数据写到pagecache后就返回。但是机器断电的时候，pagecache中的数据有可能丢失。

6：zk的dataDir和dataLogDir路径下，如果没有配置zk自动清理，会不断的新增数据文件。可配置成zk系统自动清理数据文件，但是最求系统最高性能的话，建议人工手动清理文件：zkCleanup.sh -n 3 这样保留三份文件。

7：查看zk节点状态。重新启动zk节点前后，一定要查看状态

echo ruok | nc host port

echo stat | nc host port

8：配置fsync.warningthresholdms=20，单位是毫秒，在forceSync=yes的时候，如果数据固化到磁盘的操作fsync超过20ms的时候，将会在zookeeper.out中输出一条warn日志。这个目前zk的3.4.5和3.5版本有bug，在zoo.cfg中配置不生效。我的做法是在conf/java.env中添加java系统属性：

export JVMFLAGS="-Dfsync.warningthresholdms=20 $JVMFLAGS"

我能预感到这篇文章虽然是干货

但阅读量会很低

大多数人几乎没有能力读完

你如果有耐心看到这里

不是疯了就是爱我

要么就是传说中真正的技术大牛

zkcli的使用

由于zookeeper类似文件系统的特性，因此，zkCli的操作也类似文件系统中的常用操作：增删改查、资源管理、权限控制等等。

建立会话连接：./zkCli.sh  -timeout 0  -r  -server  ip:port

-timeout：指定当前会话的超时时间。zookeeper依靠与客户端之间的心跳判断一个会话是否有效，timeout指服务器如果在timeout指定的时间内没有收到客户端的心跳包，就认为这个客户端失效。单位毫秒。 

-r：read-only。zookeeper的只读模式指zookeeper的服务器如果和集群中半数或半数以上的服务器失去连接以后，该服务器就不在处理客户端的请求了，但这种故障发生时，机器可以向外提供读服务，情况下可以使用只读模式。

-server: 表示想要连接的服务器地址和端口。

进入界面后开始使用zkClient，按h查看使用帮助：可知，zkClient常用操作和文件系统大致相同，包括查看、新增、修改、删除、配额、权限控制等。

zkClient的查询包括节点的数据和节点的状态。主要有使用stat列出节点的状态；使用get获得节点的数据；使用ls列出节点的子节点列表；使用ls2同时列出子节点的列表和节点的状态；

获取节点的状态，使用方法：stat path

在zookeeper中，每一次对数据节点的写操作（如创建一个节点）被认为是一次事务，对于每一个事务系统都会分配一个唯一的id来标识这个事务，cZxid就表示事务id，表示该节点是在哪个事务中创建的；

ctime：表示节点创建的时间； 

mZxid：最后一次更新时的事务id； 

mtime：最后一次更新时的时间; 

pZxid: 表示该节点的子节点列表最后一次被修改的事务的id（为当前节点添加子节点，从当前节点的子节点中删除一个或多个子节点都会引起节点的子节点的列表的改变，而修改节点的数据内容则不在此列）;cversion = -1,dataVersion = 0,aclVersion = 0在第一篇博客中已经有过介绍，分别表示子节点列表的版本，数据内容的版本，acl版本....

获取节点的子节点列表及stat该节点，使用方法：ls path或ls2 path

获取节点的数据，其结果是当前节点的值和stat该路径的值放在一起。使用方法：get path

使用delete path删除无子节点的node，删除含有子节点的节点：rmr path；

ACL权限管控

ACL全称为Access Control List 即访问控制列表，用于控制资源的访问权限。ZK 类似文件系统，Client 可以在上面进行创建、更新、删除等权限控制，5种操作权限为：CREATE、READ、WRITE、DELETE、ADMIN ，即增、删、改、查、管理权限，这5种权限简写为crwda(每个单词的首字符缩写)；

在传统的文件系统中，文件或子目录默认会继承自父目录的ACL。而在Zookeeper中，znode的ACL是没有继承关系的，每个znode的权限都是独立控制的，只有客户端满足znode设置的权限要求时，才能完成相应的操作。

Zookeeper的ACL，分为三个维度：scheme、id、permission，通常表示为scheme:id:permission，schema代表授权策略，id表用户，permission表权限。

Schemescheme对应于采用哪种方案来进行权限管理，zookeeper的scheme的分类如下： 

world：默认方式，相当于全世界都能访问； 

auth：代表已经认证通过的用户(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)digest：即用户名:密码这种方式认证，这也是业务系统中最常用的； 

ip：使用Ip地址认证

1）增加一个认证用户

addauth digest 用户名:密码明文例：addauth digest user1:password1

2）设置权限

setAcl /path auth:用户名:密码明文:权限

例：setAcl /test auth:user1:password1:cdrwa

3）查看Acl设置：getAcl /path

id

id是验证模式，不同的scheme，id的值也不一样。scheme为ip时，id的值为客户端的ip地址。scheme为world时，id的值为anyone。scheme为digest时，id的值为：username:BASE64(SHA1(password))。

permission

zookeeper目前支持下面一些权限：

CREATE(c): 创建权限，可以在在当前node下创建child node，即对子节点Create操作 

DELETE(d): 删除权限，可以删除当前的node，即对子节点Delete操作

READ(r): 读权限，可以获取当前node的数据，可以list当前node所有的child nodes，即对本节点GetChildren和GetData操作 

WRITE(w): 写权限，可以向当前node写数据，即对本节点SetData操作ADMIN(a): 管理权限，可以设置当前node的permission，即对本节点setAcl操作

Hbase

HBase是一个构建在HDFS上的分布式列存储系统，主要用于海量结构化数据存储，从逻辑上讲，HBase将数据按照表，列，行进行存储。

HBase与HDFS对比

两者都具有良好的容错性和扩展性，都可以扩展到成百上千个节点。HDFS适合批处理场景，不支持数据的随机查找，不适合增量数据处理，不支持数据更新；

HBase特点

大：一个表可以有数十亿行，上百万列。

无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同列。

面向列：面向列（族）的存储和权限控制，列（族）独立检索。

稀疏：对于空（null）的列，并不占用存储空间，表可以设计的非常稀疏。

数据多版本：每个单元中的数据可以有多个存储版本，默认情况下版本号自动分配，是单元格插入时间的时间戳。

数据类型单一：HBase中的数据都是字符串，没有类型。

HBase架构

Client：包含访问HBase的接口，并维护cache来加快对HBase的访问；

Zookeeper：保证任何时候集群中只有一个Master，存贮所有Region的寻址入口，实时监控Region server的上线和下线信息，并通知给Master，存储HBase的schema和table元数据；

Master：为Region server分配region；负责Region server的负载均衡，发现失效的Region server并重新分配其上的region，管理用户对table的增删改查操作；

Region server：Region server维护region，处理对这些region的IO请求；Region server负责切分在运行过程中变的过大的region；

HBase数据模型

HBase是基于Google BigTable模型开发的典型的key/value系统。

HBase逻辑视图

RowKey：是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要；

Column Family：列族，拥有一个名称(string)，包含一个或多个相关列；

Column：属于某一个columnfamily，familyName:columnName，每条记录可动态添加；

Version Number：类型为Long，默认值是系统时间戳，可由用户自定义；

Value(Cell)：Byte array。

你居然能读到这里，必须送你一幅....

要么就是已经看不懂了

要么就是已经晕了，哈哈

此时文章在你眼里已经是浮云

forget about it

一切重新认识！

表 webtable包含两行（com.cnn.www 和 com.example.www）以及名为contents、anchor 和 people 的三个列族。对于第一行（com.cnn.www），anchor 包含两列（anchor:cssnsi.com，anchor:my.look.ca），并且 contents 包含一列（contents:html）。

本行键 com.cnn.www 的行有5个版本， com.example.www 的行有一个版本。contents:html列限定符包含给定网站的整个 HTML。anchor列族的限定符每个包含与该行所表示的站点链接的外部站点以及它在其链接的锚点（anchor）中使用的文本。people列族代表与该网站相关的人员。

按照约定，列名由其列族前缀和限定符组成。例如，列内容: html 由列族contents和html限定符组成。冒号字符（:）从列族限定符分隔列族。

webtable表如下所示：

此表中显示为空的单元格在 HBase 中不占用空间或实际上存在。这正是使 HBase “稀疏”的原因。表格视图并不是查看 HBase 数据的唯一可能的方法，甚至是最准确的。

HBase物理视图

每个column family存储在HDFS上的一个单独文件中，空值不会被保存。Key 和 Version number在每个column family中均有一份；HBase为每个值维护了多级索引，

即：；表在行的方向上分割为多个Region；Region是Hbase中分布式存储和负载均衡的最小单元，不同Region分布到不同RegionServer上。Region按大小分割的，随着数据增多，Region不断增大，当增大到一个阀值的时候，Region就会分成两个新的Region；

Region虽然是分布式存储的最小单元，但并不是存储的最小单元。每个Region包含着多个Store对象。每个Store包含一个MemStore或若干StoreFile，StoreFile包含一个或多个HFile。MemStore存放在内存中，StoreFile存储在HDFS上。

尽管在 HBase 逻辑视图中，表格被视为一组稀疏的行的集合，但它们是按列族进行物理存储的。可以随时将新的列限定符（column_family：column_qualifier）添加到现有的列族。

ColumnFamily anchor表：

ColumnFamily contents 表：

HBase 逻辑视图中的空单元不存储。因此对时间戳为 t8 的 contents:html 列值的请求将不返回任何值。同样，在时间戳为 t9 中一个anchor:my.look.ca 值的请求也不会返回任何值。

但是，如果未提供时间戳，则会返回特定列的最新值。给定多个版本，最近的也是第一个找到的，因为时间戳按降序存储。

因此，如果没有指定时间戳，则对行 com.cnn.www 中所有列的值的请求将是: 时间戳 t6 中的 contents:html，时间戳 t9 中 anchor:cnnsi.com 的值，时间戳 t8 中 anchor:my.look.ca 的值。

HBase表、行与列族

HBase 中表是在 schema 定义时被预先声明的，可以使用以下的命令来创建一个表，在这里必须指定表名和列族名。在 HBase shell 中创建表的语法如下所示：

HBase中的行是逻辑上的行，物理模型上行是按列族(colomn family)分别存取的，行键是未解释的字节，行是按字母顺序排序的，最低顺序首先出现在表中。空字节数组用于表示表命名空间的开始和结束。

Apache HBase 中的列被分组为列族。列族的所有列成员具有相同的前缀。

例如，courses:history 和 courses:math 都是 courses 列族的成员。冒号字符（:）从列族限定符中分隔列族。列族前缀必须由可打印字符组成。限定尾部，列族限定符可以由任意字节组成。必须在 schema 定义时提前声明列族，而列不需要在 schema 时定义，但可以在表启动并运行时动态地变为列。

在物理上，所有列族成员一起存储在文件系统上。由于调音（tunings）和存储（storage）规范是在列族级完成的，因此建议所有列族成员具有相同的一般访问模式和大小特征。

由{row key, column( = + ), version} 唯一确定的单元。cell 中的数据是没有类型的，全部是字节码形式存储。

ROOT表和META表

HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。

所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示。

-ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。

如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。

最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

HBase数据模型操作

HBase 中有四个主要的数据操作，分别是：Get、Put、Scan 和 Delete。

Get（读取）：Get 指定行的返回属性。读取通过 Table.get 执行。

Get 操作的语法如下所示：

在以下的 get 命令示例中，我们扫描了 emp 表的第一行：

读取指定列：下面给出的是使用 get 操作读取指定列语法：

在下面给出的示例表示用于读取 HBase 表中的特定列：

Put（写）：Put 可以将新行添加到表中（如果该项是新的）或者可以更新现有行（如果该项已经存在）。Put 操作通过 Table.put（non-writeBuffer）或 Table.batch（non-writeBuffer）执行。

Put 操作的命令如下所示，在该语法中，你需要注明新值：

新给定的值将替换现有的值，并更新该行。

Put操作示例：假设 HBase 中有一个表 EMP 拥有下列数据：

以下命令将员工名为“raju”的城市值更新为“Delhi”

更新后的表如下所示：

Scan（扫描）：Scan 允许在多个行上对指定属性进行迭代。Scan 操作的语法如下：

Delete（删除）：Delete 操作用于从表中删除一行。Delete 通过 Table.delete 执行。HBase 不会修改数据，因此通过创建名为 tombstones 的新标记来处理 Delete 操作。这些  tombstones，以及没用的价值，都在重大的压实中清理干净。使用 Delete 命令的语法如下：

下面是一个删除特定单元格的例子：

删除表的所有单元格：使用 “deleteall” 命令，可以删除一行中所有单元格。下面给出是 deleteall 命令的语法：

这里是使用“deleteall”命令删除 emp 表 row1 的所有单元的一个例子。

使用 Scan 命令验证表。表被删除后的快照如下：

HBase读写流程

HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。

与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。

StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。

当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。

写操作

1、Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。 

2、数据被写入Region的MemStore，直到MemStore达到预设阈值。 

3、MemStore中的数据被Flush成一个StoreFile。 

4、随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。 

5、StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile...

可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高机能。

读操作

1、Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。

2、从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。

3、通过RegionServer获取需要查找的数据。

4、Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

5、寻址过程：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client

Hive

架构

Hive 是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具用来数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。

Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapReduce 开发者的开发自定义的 mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。

Hive 的结构可以分为以下几部分：

① 用户接口：包括 CLI, Client, WUI

②元数据存储：通常是存储在关系数据库如 mysql, derby 中

③ 解释器、编译器、优化器、执行器

④ Hadoop：用 HDFS 进行存储，利用 MapReduce 进行计算

Redis

Redis是一个开源的，使用ANSI C语言编写的、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库。用作数据库、缓存和消息代理。

它通常被称为数据结构服务器，Redis支持存储的Value类型包括String(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型），这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。

Redis具有内置复制、Lua脚本、LRU收回、事务和不同级别的磁盘上持久性，并通过Redis Sentinel和Redis群集的自动分区提供高可用性。

Redis持久化

Redis有两种持久化方案：RDB和AOF；

RDB：按照一定的时间间隔对数据集创建基于时间点的快照。RDB持久化是把当前Redis内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。默认情况下，Redis保存数据集快照到磁盘，名为dump.rdb的二进制文件。恢复时是将快照文件直接读到内存里。

AOF：比快照方式有更好的持久化性，由于在使用aof持久化方式时Redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当Redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉Redis我们想要通过fsync函数强制os写入到磁盘的时机。

Value数据类型

Redis的Key是字符串类型，由于Key不是binary safe的字符串，所以像“my key”和“mykey\n”这样包含空格和换行的Key是不允许的。

过期策略

Redis的过期策略就是指当Redis中缓存的Key过期了，Redis如何处理。过期策略通常有以下三种：

定时过期：每个设置过期时间的Key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

惰性过期：只有当访问一个Key时，才会判断该Key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期Key没有再次被访问，从而不会被清除，占用大量内存。

定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的Key，并清除其中已过期的Key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

expires字典会保存所有设置了过期时间的Key的过期时间数据，其中，Key是指向键空间中的某个键的指针，Value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。

Redis中同时使用了惰性过期和定期过期两种过期策略。

过期策略存在的问题：由于Redis定期删除是随机抽取检查，不可能扫描清除掉所有过期的Key并删除，然后一些Key由于未被请求，惰性删除也未触发。这样Redis的内存占用会越来越高。此时就需要内存淘汰机制 。

兄弟姐妹们

现在是我已经坚持不下去了

我没法再安慰你们了

太难啦...555

别人只关注我飞的高不高

你们关注我累不累，对不对

嗯嗯，容我喝杯茶，缓一缓

再坚持一下下

内存淘汰策略

Redis的内存淘汰策略是指Redis用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

最大内存的设置是通过设置maxmemory来完成的，格式为maxmemory bytes ，当目前使用的内存超过了设置的最大内存，就要进行内存释放了，当需要进行内存释放的时候，需要用某种策略对保存的的对象进行删除。Redis有六种策略。

Redis中当内存超过限制时，按照配置的策略，淘汰掉相应的Key-Value，使得内存可以继续留有足够的空间保存新的数据。Redis 确定驱逐某个键值对后，会删除这个数据并将这个数据变更消息发布到本地（AOF 持久化）和从机（主从连接）。

volatile-lru：使用LRU算法进行数据淘汰，只淘汰设定了有效期的Key ；

（LRU算法: Least Recently Used的缩写,淘汰上次使用时间最早的，且使用次数最少Key）

allkeys-lru：使用LRU算法进行数据淘汰，所有Key都可以被淘汰； 

volatile-random：随机淘汰数据，只淘汰设定有效期的Key； 

allkeys-random：随机淘汰数据，所有Key都可以被淘汰； 

volatile-ttl：淘汰剩余有效期最短的Key； 

no-enviction：不删除任意数据，但Redis还会根据引用计数器进行释放),这时如果内存不够时，会返回错误 。

Redis集群

Redis在3.0版本之前是不支持集群的，3.0版本之前想要搭建Redis集群需要中间件来找到存值和取值的对应节点。

Redis 集群中内置了 16384个哈希槽，当需要在 Redis 集群中放置一个 Key-Value 时，Redis 先对 Key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 Key 都会对应一个编号在 0-16383 之间的哈希槽，Redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

Redis集群中有多台Redis服务器不可避免会有服务器挂掉。Redis集群服务器之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了。

主从结构

Redis支持三种主从结构，分别是：

一主对一从：常用于写请求量很大，并且需要持久化时，只在从节点开启AOF持久化，这样既保证了主节点的性能又保证了数据的安全性；但是当重启主节点时需要注意先断开从节点的复制关系，否则当主节点重启后由于没有持久化数据，所以主节点的数据为空，而此时从节点再同步主节点的数据就会丢失之前持久化的数据。

一主对多从：多用于读请求很高的情况，通过读写分离把读请求交给从节点来分担主节点压力；同时对于开发中的一些危险或耗时的操作也可以在从节点上执行；弊端：当从节点过多时，会导致主节点的一份数据要发给很多从节点，所以会导致主节点负载与带宽消耗较大。

树状主从结构：这种结构很好的解决了上面提到的从节点过多时主节点带宽消耗过大的问题，主节点把数据写给较少的从节点，然后从节点再同步给其自己的从节点。

主从复制

要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点，主从复制的作用：

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。

高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

从节点开启主从复制，有3种方式：

1、配置文件：在从服务器的配置文件中加入：

slaveof。

2、启动命令：redis-server启动命令后加入：

slaveof。

3、客户端命令：Redis服务器启动后，直接通过客户端执行命令：

slaveof，则该Redis实例成为从节点。

通过 info replication 命令可以看到复制的一些信息。

主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。

主从配置之后的日志记录也可以看出这个流程。

1、保存主节点（master）信息：执行 slaveof 后 Redis 会打印如下日志：

2、从节点与主节点建立网络连接

从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。

从节点与主节点建立网络连接。从节点会建立一个 socket 套接字，从节点建立了一个端口为51234的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

若从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone取消复制。

关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志；

3、发送 ping 命令：连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：

1. 检测主从之间网络套接字是否可用。

2. 检测主节点当前是否可接受处理命令。

如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

从节点发送的 ping 命令成功返回，Redis 打印日志，并继续后续复制流程：

4、权限验证：如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。

5、同步数据集：主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

6、命令持续复制：当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

你读到这里了吗？！

嗯！我们成功挑战了极限！

完胜！

大数据的分布式技术也就这样！

--------------

※ 点赞+在看+转发的转型都能成功！

— 热门推荐阅读 —

⊕【专家Insight】企业数字化转型战略完整指南

⊕【专家Insight】产业数字化转型的价值维度与理论逻辑

⊕ 城市大脑数据中台总体架构方案（PPT）

⊕ 116页智慧矿山建设最佳实践方案（PPT下载）

⊕ 202页|城市大脑：智慧城管篇|最佳实践（PPT下载）

⊕ 92页PPT全方位解析：制造业到底需要什么样的互联网思维？

⊕ 关于数据中台的争议！10页PPT即可阐析

⊕ 前华为高管透析华为灰度管理|读书笔记（134页PPT）

⊕ 工程院院士解析|智慧城市数字孪生重构方案（PPT）

⊕【Insight】让人震惊的大数据全球市场（附36页PPT）

⊕【Insight】老业务要转型，新业务如何孵化？

【球迷Long笔记】Insight丨人生丨足球丨商业丨深度