一些机缘巧合，让我的思维回到了csdn，看到了上百篇的文章，感受到之前可能自己是影响了一些人的， 突然很是感慨。 写这些blog的日子，应该是很幸福的，可以聚焦的做一些自己喜欢的事情，挥洒自己的热爱，心无旁鹭，在键盘上敲敲打打。 不确定看到过我blog的同学，还有多少目前依然在关注着，如果有，那么我想是否会再提笔重来。 如果提笔重来，我当然会写技术专栏，这个是我安生立命之本； 我应该会写技术领导力？ 毕竟我需要推动更多的人，一起来做更牛逼的事儿；我应该会写团队文化的构建，毕竟我要专注大家的技术成长，为大家的 ...继续阅读 (12)

本篇文章并不是介绍K8S 或者Docker的，而仅仅是使用过程中一些常见问题的汇总。重启策略：http://kubernetes.io/docs/user-guide/pod-states/， 对于一个服务，默认的设置是RestartAlways，而其他的比如Job，重启策略则是Never or OnFailure，如果docker重启，kubelet也要重启，否则pod的状态会变成Completed如果报错是报image找不到，可能是因为与docker registry的认证关系没有建立，可以通过docker login 来解决需要pause，可以docker tag修改源。需要升级内核至少3.10版本，只能使用root使用Nginx，尤其是对外网服务的时候可能会很管用。使用kubectl scale 进行服务副本数的管理，同时也可以设置自动化扩容缩容机制rolling-update 进行在线升级集群的HA需要关注，毕竟master挂了是个很麻烦的事情，组起码保证不了服务的可靠性如果指定机房：可以使用label机制。每个逻辑机房部署一整套环境OR所有逻辑机房使用一整套环境Docker的升级实际上会kill机器上所有的服务实例，因此kubernetes的解决：让该节点处于维护状态cordon Mark node as unschedulabledrain Drain node in ...继续阅读 (78)

最近一年的工作，有很大的比重在做云平台的事情，简单来说，就是为公司内用户提供一个PaaS，用户可以在我们的云平台上方便的将单机服务程序扩展为多实例程序，以平台服务化的方式对外提供。在这里简单分享一下。首先简单说一下我们解决了用户的什么需求，或者说痛点。基础算法直接以库的形式提供给应用方？用户提供了一个基础算法，这个算法可能以一个动态库的形式提供，那么使应用方需要关注编译依赖，需要关注词典等模型文件，开发成本比较高。尤其是如果这个基础算法需要升级，或者模型文件需要升级的时候，还需要通知应用方进行修改。而且，如果基础算法不稳定，有出core的行为，那么势必影响了应用方的服务质量。还有就是，如果基础算法非常耗资源，比如CPU，内存占得太多，可能会影响应用方程序对于资源的使用。基础算法的服务化为了避免基础算法以动态库提供给应用方的种种弊端，基础算法可以以网络服务的形式提供，这就是基础算法的服务化。就是说，基础算法是一个网络服务，用户直接访问这个网络服务即可。这样，基础算法的服务接口只要不变，不论它如何升级，都不需要应用方做任何修改。开源的Thrift，等等RPC的方案，都很好的满足了基础算法服务化的需求。服务化的质量如何衡量那么一个服务化的基础算法，如何保证上面所说的服务质量和延时上的要求呢。尤其是服务质量，或者说可靠性。如果我们假设机器永远无故障，网络设备也永远运行正常，服务也足够稳定， ...继续阅读 (52)

现在各大网站预售中，估计9月底就能到货发售！京东：http://item.jd.com/11770787.html当当：http://product.dangdang.com/23776595.html亚马逊：http://www.amazon.cn/SparkInternals前言和目录附上，以便有需要了解的同学：诞生于2005年的Hadoop解决了大数据的存储和计算问题，已经成为大数据处理的事实标准。但是，随着数据规模的爆炸式增长和计算场景的丰富细化，使得Hadoop越来越难以满足用户的需求。针对不同的计算场景，开源社区和各大互联网公司也推出了各种大数据分析的平台，旨在满足特定应用场景下的计算需求。但是，众多的平台使得用户不得不为平台开发类似的策略，增加了运维开发成本。2009年诞生于AMPLab的Spark，设计的目标就是为大数据的多种计算场景提供一个通用的计算引擎，同时解决大数据处理的4V，即Volume(海量)、Velocity(快速)、Variety(多样)、Value(价值)。如Spark的核心作者之一的Ion Stoica所说，“The goal is to build a newgeneration of data analytics software, to be used across academia and industry。 Hadoop之父Doug C ...继续阅读 (107)

2015年以来自己的确是疏于打理博客了。当然工作忙永远是推脱很多事情的最好借口。但是，自己的确是很忙。今天登陆，突然发现访问量过百万，而且，访问数量是1001001，一个完美的回文数。今天没有什么好话题，为了避免该文过于水，还是计划一下接下来的关注点吧：继续关注Spark的技术发展，包括架构实现的细节关注如何使用Go写出可靠，不亚于C/C++性能的分布式系统关注机器级别的系统调优，先期关注基于系统自带参数的调优关于Container的技术细节，关于轻量级资源隔离的实现我现在负责的工作，是构建公司内部的云计算平台，希望下半年能在公司内部推广这个平台。人手很少，工作很多，因此基本上最近几个月的时间都会耗在这个上面。接下来的一个月，会有个惊喜。这个惊喜，到时候再说。 ...继续阅读 (27)

2015年以来自己的确是疏于打理博客了。当然工作忙永远是推脱很多事情的最好借口。但是，自己的确是很忙。 今天登陆，突然发现访问量过百万，而且，访问数量是1001001，一个完美的回文数。 ...继续阅读 (10)

上周六去北京参加了OSTC 2015开源技术大会，并分享了《Spark技术内幕》，主要涵盖了Spark Core的核心实现。我主要以WordCount为例，讲解了任务调度的具体实现，资源分配和Shuffle细节，也对Storage模块进行了概述。短短的45分钟实际上包含不了更多的内容，但是从大家的提问看，大家还是非常关注系统实现的，并且也希望从系统实现来为自己的服务提供更有力的支撑。回来后，有人说，如果没有Apache，那么是不是对资深码农更好？。。。Apache是互联网的基石，没有了Spark，互联网最少要倒退几年吧。还有，就是开源社区的商业模式，实际上，并不是有太多的公司可以独立开发一套新系统的，中国的话BAT除外吧。比如Mysql，与其花费不少的代价雇佣一个高级的DBA，不如买个service，不单专业，而且靠谱；再说了，牛人不一定去所谓的小公司的。去赶高铁了。最近太忙了，大家别来无恙。。 ...继续阅读 (78)

13年底，自己在CSDN开始新的博客，博客定位干货有深度。一年以来，写了100篇文章，本文是第101篇。大部分的文章已经达到自己的标准，而草稿箱也躺着几十篇未完成的稿件，他们估计会成为压箱底的，只不过这个压箱底有的是因为拿不出手，有的是和自己专注的方向不太匹配，等等。自己的坚持也取得了漂亮的数据，一年来，博客访问量超过80w，拥有超过500位粉丝。其中，专栏《Spark技术内幕》收录了25篇博文，整体访问量超过20w。被评为2014博客之星，自己诚惶诚恐，唯有坚持。最近半年，自己非常忙，没有周末，没有假期。春节的今天，工作继续，希望坚持两个月后，达到自己理想的结果。羊年大吉，心想事成！ ...继续阅读 (24)

Storage模块负责了Spark计算过程中所有的存储，包括基于Disk的和基于Memory的。用户在实际编程中，面对的是RDD，可以将RDD的数据通过调用org.apache.spark.rdd.RDD#cache将数据持久化；持久化的动作都是由Storage模块完成的。包括Shuffle过程中的数据，也都是由Storage模块管理的。可以说，RDD实现了用户的逻辑，而Storage则管理了用户的数据。本章将讲解Storage模块的实现。1.1 模块整体架构org.apache.spark.storage.BlockManager是Storage模块与其他模块交互最主要的类，它提供了读和写Block的接口。 这里的Block，实际上就对应了RDD中提到的partition，每一个partition都会对应一个Block。每个Block由唯一的Block ID（org.apache.spark.storage.RDDBlockId） 标识，格式是"rdd_" + rddId + "_" + partitionId。BlockManager会运行在Driver和每个Executor上。而运行在Driver上的BlockManger负责整个Job的Block的管理工作；运行在Executor上的BlockManger负责管理该Executor上的Block，并且向Driver的 ...继续阅读 (36)

Storage模块负责了Spark计算过程中所有的存储，包括基于Disk的和基于Memory的。用户在实际编程中，面对的是RDD，可以将RDD的数据通过调用org.apache.spark.rdd.RDD#cache将数据持久化；持久化的动作都是由Storage模块完成的。包括Shuffle过程中的数据，也都是由Storage模块管理的。可以说，RDD实现了用户的逻辑，而Storage则管理了用户 ...继续阅读 (11)

通过上面的架构和源码实现的分析，不难得出Shuffle是Spark Core比较复杂的模块的结论。它也是非常影响性能的操作之一。因此，在这里整理了会影响Shuffle性能的各项配置。尽管大部分的配置项在前文已经解释过它的含义，由于这些参数的确是非常重要，这里算是做一个详细的总结。1.1.1 spark.shuffle.manager前文也多次提到过，Spark1.2.0官方支持两种方式的Shuffle，即Hash Based Shuffle和Sort Based Shuffle。其中在Spark 1.0之前仅支持Hash Based Shuffle。Spark 1.1的时候引入了Sort Based Shuffle。Spark 1.2的默认Shuffle机制从Hash变成了Sort。如果需要Hash Based Shuffle，可以将spark.shuffle.manager设置成“hash”即可。如果对性能有比较苛刻的要求，那么就要理解这两种不同的Shuffle机制的原理，结合具体的应用场景进行选择。Hash Based Shuffle，就是将数据根据Hash的结果，将各个Reducer partition的数据写到单独的文件中去，写数据时不会有排序的操作。这个问题就是如果Reducer的partition比较多的时候，会产生大量的磁盘文件。这会带来两个问题：1) ...继续阅读 (33)

通过上面的架构和源码实现的分析，不难得出Shuffle是Spark Core比较复杂的模块的结论。它也是非常影响性能的操作之一。因此，在这里整理了会影响Shuffle性能的各项配置。尽管大部分的配置项在前文已经解释过它的含义，由于这些参数的确是非常重要，这里算是做一个详细的总结。1.1.1  spark.shuffle.manager前文也多次提到过，Spark1.2.0官方支持两种方式的Shuf ...继续阅读 (4)

回忆一下，每个Stage的上边界，要么需要从外部存储读取数据，要么需要读取上一个Stage的输出；而下边界，要么是需要写入本地文件系统（需要Shuffle），以供childStage读取，要么是最后一个Stage，需要输出结果。这里的Stage，在运行时的时候就是可以以pipeline的方式运行的一组Task，除了最后一个Stage对应的是ResultTask，其余的Stage对应的都是ShuffleMap Task。而除了需要从外部存储读取数据和RDD已经做过cache或者checkpoint的Task，一般Task的开始都是从ShuffledRDD的ShuffleRead开始的。本节将详细讲解Shuffle Read的过程。先看一下ShuffleRead的整体架构图。org.apache.spark.rdd.ShuffledRDD#compute 开始，通过调用org.apache.spark.shuffle.ShuffleManager的getReader方法，获取到org.apache.spark.shuffle.ShuffleReader，然后调用其read()方法进行读取。在Spark1.2.0中，不管是Hash BasedShuffle或者是Sort BasedShuffle，内置的Shuffle Reader都是 org.apache.spark.shuffle.h ...继续阅读 (51)

本文详细讲解Shuffle Read的整个过程，包括如何获得Block的元数据信息，进行网络，本地读取。通过一个整体的流程架构图，详细大家可以对整个过程有一个更加深刻的把握 ...继续阅读 (5)

Shuffle Map Task运算结果的处理这个结果的处理，分为两部分，一个是在Executor端是如何直接处理Task的结果的；还有就是Driver端，如果在接到Task运行结束的消息时，如何对Shuffle Write的结果进行处理，从而在调度下游的Task时，下游的Task可以得到其需要的数据。Executor端的处理在解析BasicShuffle Writer时，我们知道ShuffleMap Task在Executor上运行时，最终会调用org.apache.spark.scheduler.ShuffleMapTask的runTask：override def runTask(context: TaskContext): MapStatus = { // 反序列化广播变量taskBinary得到RDD val ser = SparkEnv.get.closureSerializer.newInstance() val (rdd, dep) = ser.deserialize[(RDD[_], ShuffleDependency[_, _, _])]( ByteBuffer.wrap(taskBinary.value),Thread.currentThread.getContextClassLoader) //省略一些非核心代码 val mana ...继续阅读 (43)

Shuffle Map Task运算结果的处理这个结果的处理，分为两部分，一个是在Executor端是如何直接处理Task的结果的；还有就是Driver端，如果在接到Task运行结束的消息时，如何对Shuffle Write的结果进行处理，从而在调度下游的Task时，下游的Task可以得到其需要的数据。Executor端的处理在解析BasicShuffle Writer时，我们知道ShuffleM ...继续阅读 (7)

在Spark 0.6和0.7时，Shuffle的结果都需要先存储到内存中（有可能要写入磁盘），因此对于大数据量的情况下，发生GC和OOM的概率非常大。因此在Spark 0.8的时候，Shuffle的每个record都会直接写入磁盘，并且为下游的每个Task都生成一个单独的文件。这样解决了Shuffle解决都需要存入内存的问题，但是又引入了另外一个问题：生成的小文件过多，尤其在每个文件的数据量不大而文件特别多的时候，大量的随机读会非常影响性能。Spark 0.8.1为了解决0.8中引入的问题，引入了FileConsolidation机制，在一定程度上解决了这个问题。由此可见，Hash Based Shuffle在Scalability方面的确有局限性。而Spark1.0中引入的Shuffle Pluggable Framework，为加入新的Shuffle机制和引入第三方的Shuffle机制奠定了基础。在Spark1.1的时候，引入了Sort Based Shuffle；并且在Spark1.2.0时，Sort Based Shuffle已经成为Shuffle的默认选项。但是，随着内存成本的不断下降和容量的不断上升，Spark Core会在未来重新将Shuffle的过程全部是in memory的吗？我认为这个不太可能也没太大必要，如果用户对于性能有比较苛刻的要求而Shuffle的过程的 ...继续阅读 (140)

在Spark 0.6和0.7时，Shuffle的结果都需要先存储到内存中（有可能要写入磁盘），因此对于大数据量的情况下，发生GC和OOM的概率非常大。因此在Spark 0.8的时候，Shuffle的每个record都会直接写入磁盘。一直到1.2.0，Shuffle的数据是一定会写入本地文件系统的，那么对于性能要求非常苛刻的用户，如何获得更好的性能呢？ ...继续阅读 (6)

前几天发生个很有意思的事情。就是在我的博客被各大不知名的所谓聚合网站收录后，某个比较畅销的技术书籍竟然也引用了我其中一篇博客。这个细节就不详细讲了。大概就是我讲了一件事情，角度还算是新颖，绝对是原创；然后其中有两个非常重要的地方漏掉了，那边博客是半年前写的，当时对于这块知识的确是掌握的不充分。然后这位同仁抄的时候也没有大改；照搬也就算了，还不纠正我的错误，因此我对该书的水平产生了深深的质疑。在朋友圈发布这个消息后，各位同事和同学都积极响应，甚至有个南开法律系的美女同学说要帮我维权，好吧，哥现在已经都有孩子了，做事不能那么激进，尤其哥要以身作则为小公主表率，因此这个事情就算是过去了，也算是开年的一件乐事。别拿博客不当回事。你引用也得注明出处吧。或者你私信我，我可能直接就把原图给你了。还省得你去画。还有，写博客一来为了总结自己的心得，提升自己；二来自己也算是0.5个知识分子，要有点情怀。如果在这之外能够帮助过一些人，幸甚。2014博客之星，能够排在很靠前的位置，感谢大家；没想到能得到那么多陌生人的支持，小得意一把。 ...继续阅读 (37)

首先介绍一下需要实现的接口。框架的类图如图所示（今天CSDN抽风，竟然上传不了图片。如果需要实现新的Shuffle机制，那么需要实现这些接口。1.1.1 org.apache.spark.shuffle.ShuffleManagerDriver和每个Executor都会持有一个ShuffleManager，这个ShuffleManager可以通过配置项spark.shuffle.manager指定，并且由SparkEnv创建。Driver中的ShuffleManager负责注册Shuffle的元数据，比如Shuffle ID，map task的数量等。Executor中的ShuffleManager 则负责读和写Shuffle的数据。需要实现的函数及其功能说明：1) 由Driver注册元数据信息defregisterShuffle[K, V, C](shuffleId: Int,numMaps: Int,dependency:ShuffleDependency[K, V, C]): ShuffleHandle一般如果没有特殊的需求，可以使用下面的实现，实际上Hash BasedShuffle 和Sort BasedShuffle都是这么实现的。override def registerShuffle[K, V, C](shuffleId: Int,numMaps: I ...继续阅读 (62)

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

在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。这个方式的选择是在org.apache.spark.SparkEnv完成的：// Let the user specify short names forshuffle managers val shortShuffleMgrNames = Map( "hash" ->"org.apache.spark.shuffle.hash.HashShuffleManager", "sort" ->"org.apache.spark.shuffle.sort.SortShuffleManager") val shuffleMgrName =conf.get("spark.shuffle.manager", "sort") //获得Shuffle Manager的type，sort为默认 val shuffleM ...继续阅读 (60)

在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 ...继续阅读 (4)

正在细读Shuffle和Storage， network的源码。过几天会将相关的成果奉献给大家。正如您看到我博客的侧边栏和下边栏，我正在家2014博客之星的评选，感谢各位的支持。现在已经是第8名。已经超过400票了。谢谢大家。这个元旦很忙，一直在查阅资料，一直在画图；感谢老婆，使用ppt帮我画了很多很棒的图，图的质量绝对秒杀我原来画的。昨天（1月2号），宝贝闺女的大声的笑让我突然感觉快半岁的闺女长大了。原来虽然笑，但是没有这么开心的笑过。等忙过这一个月，一定会把尽可能多的时间留给你，不错过你任何成长的瞬间。还有，妈妈在给你写日课，记录你每天的成长。我爱你，会为你一直努力。更新博客的脚步不会停止，加油！ ...继续阅读 (35)

正在细读Shuffle和Storage， network的源码。过几天会将相关的成果奉献给大家。正如您看到我博客的侧边栏和下边栏，我正在家2014博客之星的评选，感谢各位的支持。 ...继续阅读 (12)

我的400多位CSDN粉丝们，大家动一下鼠标给我投一票吧。衔接：http://vote.blog.csdn.net/blogstar2014/details?username=anzhsoft2008#content对于非粉丝并且未登录的，可以使用QQ，微博，linkedin, google, github, 百度账号等第三方登陆。谢谢一不小心发了100篇博文了，本来计划第100篇得写个总结啥的。没想到啊没想到。不过最近忙，累，等等。到春节前看看是否有时间总结一下。写于2015年1月18号 ...继续阅读 (22)

我的400多位CSDN的粉丝们，大家动一下鼠标给我投一票吧。衔接： http://vote.blog.csdn.net/blogstar2014/details?username=anzhsoft2008#content 对于非粉丝并且未登录的，可以使用QQ，微博，百度账号等第三方登陆。谢谢 ...继续阅读 (21)

最近在做系统升级，由于当时设计的局限，导致系统不停服，保证服务的做法非常麻烦。当时再定方案的时候，由于自己在这方面没有经验，导致有些乐观。到了实际做的时候，预期时间至少比预想的多了一周的时间，要知道，在互联网公司，一周的时间是个非常长的时间。而这一周，还包括了OT。在这里总结一下分布式系统设计的大忌，本来想试着分一下级，但是还是算了，一来标准太多，无法制定一个合适的规则来界定；二来自己的经验也在增长，低调一下是自己也没详细的研究过超过5个分布式系统；三来做事情还是要严谨，不做没有十足把握的事情。1. 服务接口的设计至关重要虽然大家口口声声说对于一个集群来说，每台机器都可能出故障。但是做方案设计的时候，某些资源却向用户直接暴漏了服务的实际地址。对于一个服务几年的服务器来说，故障的可能性非常大，尤其是如果这个服务器的平时负载比较高的话。我不清楚一台服务器的平均保修时间是多少，但是绝对不可能是几个小时能搞定的，这个时间少则一天，多则半个月甚至更长。对于一些高级的用户，它会使用本地的cache，或者其他的策略来屏蔽调用服务不可用带来的影响，但是，几天的停服对于用户方的影响是无论如何不可能忽略的。这种问题发现后，可能简单的发布一个新版本的api，或者一个简单的配置文件就可以纠正。但是对于线上用户来说，他们运行的是一个一直都在running状态的服务。这个简单的改正可能需要他们服务重启，这对于 ...继续阅读 (19)

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

What’s new in Spark 1.2.01.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，它有什么重要更新呢？1. Spark Core：性能和易用性的改进对于超大规模的Shuffle，Spark Core在性能和稳定性方面做了两个重要的更新：一） Communication Manager使用Netty实现在1.1 之前，对于Shuffle的结果回传，有两种方式，对于较小的结果，直接使用akka的消息传递机制；对于较大的结果，则采用BlockManager。采用BlockManager是不错的设计，可以避免Driver占用过多的内存而OOM并且减少了GC的风险。但是，BlockManger的处理是低效的：它先从Disk中将结果读取到kernel的buffer，然后到用户空间的buffer，然后又到了kernel的send buffer，这期间有多次的内存拷贝和kernel space到user space的切换代价。着不单单是占用了JVM的不必要的内存，而且还增加了GC的频率。不过，使用FileChannel.transferTo，可以做到zero copy。具体可见htt ...继续阅读 (29)