anzhsoft的技术专栏

本文主要介绍5个典型的HDFS流程，这些流程充分体现了HDFS实体间IPC接口和stream接口之间的配合。Client和NameNode，主要是介绍了Client对NN的各种文件系统目录树元数据的操作。还通过源码分析了HDFS在读取文件时，Client，NN和DN发生的事件和这些事件的顺序。 即使不考虑出现错误的情况，写文件也是HDFS最复杂的流程。本文通过创建一个新文件并向文件写入数据，结束后关闭这个文件为例，分析文件写入时各个节点之间的配合。还讨论了DN的启动及其与NN之间的交互。包括DN从启动到

对于大规模的集群，相信都有一整套比较完善的自动化部署方案。自动化部署有很多问题值得思考，比如如何均衡的利用每个节点的资源，保证整个集群的负载打散；如果方便的加入新机器，如何在机器物理故障时下线它，然后将部署的任务迁移到其他的备机，有点资源管理的意味了。本文不会讨论这些问题。只涉及一个很简单的场景：如何将应用部署到一定数量的机器，然后启动它。比如你在上线前，需要压力测试，需要评测性能，都可能需要人工的部署几十台机器。如果纯人工，那么可能需要scp，或者wget，或者hadoop client，将应用下载到

SparkContext是开发Spark应用的入口，它负责和整个集群的交互，包括创建RDD，accumulators and broadcast variables。理解Spark的架构，需要从这个入口开始。

在一个RDD触发了一个action（比如count，collect）时，任务是如何被提交到？什么是Stage？DAGScheduler的作用是什么?它是如何划分Stage的？本文将基于源码，进行深入分析。

在上文《Spark技术内幕：Stage划分及提交源码分析》中，我们分析了Stage的生成和提交。但是Stage的提交，只是DAGScheduler完成了对DAG的划分，生成了一个计算拓扑，即需要按照顺序计算的Stage，Stage中包含了可以以partition为单位并行计算的Task。我们并没有分析Stage中得Task是如何生成并且最终提交到Executor中去的。这就是本文的主题。

通过上面一系列文章，我们知道在集群启动时，在Standalone模式下，Worker会向Master注册，使得Master可以感知进而管理整个集群；Master通过借助ZK，可以简单的实现HA；而应用方通过SparkContext这个与集群的交互接口，在创建SparkContext时就完成了Application的注册，Master为其分配Executor；在应用方创建了RDD并且在这个RDD上进行了很多的Transformation后，触发action，通过DAGScheduler将DAG划分为不同的St

本文主要关注ShuffledRDD的Shuffle Read是如何从其他的node上读取数据的。上文讲到了获取如何获取的策略都在org.apache.spark.storage.BlockFetcherIterator.BasicBlockFetcherIterator#splitLocalRemoteBlocks中。可以见注释。

通过Hash Based Shuffle和Sort Based Shuffle的源码，可以得出使用Spark Pluggable框架开发一个第三方的Shuffle Service是比较容易的；这个容易是指功能实现方面。但是这个实现必须要考虑超大规模数据场景下的性能问题，资源消耗问题。

中国大数据技术大会（Big Data Technology Conference，BDTC）是目前国内最具影响、规模最大的大数据领域的技术盛会。大会的前身是Hadoop中国云计算大会（Hadoop in China，HiC）。从2008年仅60人参加的技术沙龙到当下的数千人技术盛宴，作为业内极具实战价值的专业交流平台，已经成功举办七届的中国大数据技术大会忠实地描绘了大数据领域内的技术热点，沉淀了行业实战经验，见证了整个大数据生态圈技术的发展与演变。

1.2.0 was released on 12/18, 2014在2014年5月30日发布了Spark 1.0 和9月11日发布了Spark1.1.后，Spark 1.2 终于在12月18日发布。作为1.X时代的第三个release，它有什么重要更新呢？

最近在做系统升级，由于当时设计的局限，导致系统不停服，保证服务的做法非常麻烦。当时再定方案的时候，由于自己在这方面没有经验，导致有些乐观。到了实际做的时候，预期时间至少比预想的多了一周的时间，要知道，在互联网公司，一周的时间是个非常长的时间。而这一周，还包括了OT。在这里总结一下分布式系统设计的大忌，本来想试着分一下级，但是还是算了，一来标准太多，无法制定一个合适的规则来界定；二来自己的经验也在增

在Spark 1.2.0中，Spark Core的一个重要的升级就是将默认的Hash Based Shuffle换成了Sort Based Shuffle，即spark.shuffle.manager 从hash换成了sort，对应的实现类分别是org.apache.spark.shuffle.hash.HashShuffleManager和org.apache.spark.shuffle.sort.SortShuffleManager。那么Sort BasedShuffle“取代”Hash BasedS

我的优快云专访。摘要：EMC公司作为全球信息存储及管理产品方面的领先公司，不久前，EMC宣布收购DSSD加强和巩固了其在行业内的领导地位，日前我们有幸采访到EMC中国的张安站，他就大数据、商业存储、Spark等给大家分享了自己的看法。

如果自己的公司需要打造一个适合自己公司内部使用的PaaS，亦或是你想了解一下一个云平台是怎么构建出来的，这篇文章会比较适合你。

记录了使用k8s过程中遇到的一些问题，不过货有点太干，接下来有时间会写一下关于架构原理和更详细的实践分享

RDD是Spark最基本，也是最根本的数据抽象。http://www.cs.berkeley.edu/~matei/papers/2012/nsdi_spark.pdf 是关于RDD的论文。如果觉得英文阅读太费时间，可以看这篇译文：http://shiyanjun.cn/archives/744.html 本文也是基于这篇论文和源码，分析RDD的实现。第一个问题，RDD是什么？Resilient Distributed Datasets（RDD，） 弹性分布式数据集。RDD是只读的、分区记录的集合。RD

当用户应用new SparkContext后，集群就会为在Worker上分配executor，那么这个过程是什么呢？本文以Standalone的Cluster为例，详细的阐述这个过程。

使用ZK作为HA方案的Master是如何快速故障恢复的呢？本文为你详细解读。最后给出的流程图，可以清楚的理解恢复过程的数据流程和处理逻辑。

Lease 的机制：hdfs支持write-once-read-many，也就是说不支持并行写，那么对读写的互斥同步就是靠Lease实现的。Lease说白了就是一个有时间约束的锁。客户端写文件时需要先申请一个Lease，对应到namenode中的LeaseManager，客户端的client name就作为一个lease的holder，即租约持有者。LeaseManager起什么作用呢？读写过程的容错是怎么做的？数据块是如何复制的？数据块的恢复机制？本文都有涉及。

HDFS，为Hadoop这个分布式计算框架提供高性能、高可靠、高可扩展的存储服务。HDFS的系统架构是典型的主/从架构，早期的架构包括一个主节点NameNode和多个从节点DataNode。 HDFS HA的解决方案可谓百花齐放，Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shared NAS+NFS，因为简单易用，但是需要提供一个HA的共享存储设备。而

Hadoop框架中最核心设计就是：HDFS和MapReduce。HDFS提供了海量数据的存储，MapReduce提供了对数据的计算。HDFS在Hadoop中扮演了非常基础的作用，以文件系统的形式为上层应用提供海量数据的存储服务。 HDFS作为一个分布式文件系统，具有高容错的特点。它可以部署在廉价的通用硬件上，提供高吞吐率(Throughput)的数据访问，特别适合那些需要处理海量数据集的应用程序。它没有遵循POSIX的要求，不支持ls，cp这样标准的UNIX命令，也不支持fopen和fread这

本文详细讲解了Spark在Standalone模式下的Master的HA的源码分析。为了解决Standalone模式下的Master的SPOF，Spark采用了ZooKeeper提供的选举功能。Spark并没有采用ZooKeeper原生的Java API，而是采用了Curator，一个对ZooKeeper进行了封装的框架。采用了Curator后，Spark不用管理与ZooKeeper的连接，这些对于Spark来说都是透明的。Spark仅仅使用了100行代码，就实现了Master的HA。当然了，Spark是

Apache Spark™is a fast and general engine for large-scale data processing： 一种快速通用可扩展的数据分析引擎。如果想要搞清楚Spark是什么，那么我们需要知道它解决了什么问题，还有是怎么解决这些问题的。本文将带领你进入Spark的世界，首先阐述了为什么Spark能够在众多的大数据分析平台中脱颖而出：通用，易用，高性能和与Hadoop的有效整合。Spark All in One的解决方案使用一个通用栈解决了流式，交互式，实时查询，迭代

Spark1.0.0发布一个多月了，那么它有多少行代码（Line of Code, LOC）？

对于在Linux下开发的同学来说，Shell可以说是一种基本功。对于运维的同学来说，Shell可以说是一种必备的技能，而且应该要非常熟练的书写Shell。对于Release Team，软件配置管理的同学来说，Shell也起到了非常重要的作用。尤其是分布式系统发展的如火如荼，很多开源项目都开展的如火如荼（好像不是分布式的系统都不好意思拿出来说事）。分布式系统的配置，管理，Shell也起到了非常重要的作用，虽然只是简单的文件拷贝，但是谁让Shell天生是做这些的呢？当然了，以上不是本文的主题。本文的主题是

本文分析了Spark1.0.0的Client，Master和Worker之间是如何通信的。通过对通信的分析，可以清楚的理解各个角色的作用和责任，和它在集群中扮演的不同角色。当然了，为了便于源码分析，本文开始分析了akka，一个非常优秀的actor的实现：高性能，易于编程，可扩展和弹性无中心。

搜索技术是互联网最核心的技术之一。但是移动互联网迅猛发展的今天，互联网产生的数据已经不是简单的网页搜索所能涵盖的了。比如微信公众号，产生了许多优质的内容，如果这些公众号仅仅将这些内容发布到微信平台，那么你通过“传统的互联网搜索引擎”是无法获知这部分资源的。当然了，微信搜索其实只是一个例子，而且去年整合了腾讯搜搜的搜狗已经于今年发布了微信公众号的搜索。其实还有一部分内容没有涵盖，那就是优秀的APP产生的内容。现在很多的APP是依托于网站的，这些APP发布的内容如果也同步于网站，那么这部分内容就不是信心的孤

Worker所起的作用有以下几个：1. 接受Master的指令，启动或者杀掉Executor2. 接受Master的指令，启动或者杀掉Driver3. 报告Executor/Driver的状态到Master4. 心跳到Master，心跳超时则Master认为Worker已经挂了不能工作了5. 向GUI报告Worker的状态

最近我在做流式实时分布式计算系统的架构设计，而正好又要参见优快云博文大赛的决赛。本来想就写Spark源码分析的文章吧。但是又想毕竟是决赛，要拿出一些自己的干货出来，仅仅是源码分析貌似分量不够。因此，我将最近一直在做的系统架构的思路整理出来，形成此文。为什么要参考Storm和Spark，因为没有参照效果可能不会太好，尤其是对于Storm和Spark由了解的同学来说，可能通过对比，更能体会到每个具体实现背后的意义。本文对流式系统出现的背景，特点，数据HA，服务HA，节点间和计算逻辑间的消息传递，存储模型，

主要包含使用maven和sbt编译spark源码。还有配置idea等。

写了5篇文章。其中3篇初赛，其中两篇进了决赛，另外1篇忘记微博推广了，导致网友投票没有超过50。决赛的两篇文章，第一篇我准备了挺久，虽然文字性的东西较多，但是如果仔细读的话，相信对大家会有所帮助。另外一篇写的仓促，在这里感谢各位投票的网友了。

本周接手了一个Cassandra系统的维护工作，有一项是需要将应用方的数据导入我们维护的Cassandra集群，并且为应用方提供HTTP的方式访问服务。这是我第一次接触KV系统，原来只是走马观花似的看过KV啊，NoSQL啊。但是实际上没有实际的使用经验。经过两天的学习和接手，终于搞明白了在生产环境中的使用方式。在此简要的笔记一下。本文主要包括的内容有：Cassandra的简介，Cassandra的相关CLICassandra的Python API，并且给出一个批量导入数据的例子。