比如，上图我上传了一张长着苹果脑袋的女孩和一张雪后故宫的照片，然后让Vidu生成一个“长着苹果脑袋的模特站在雪后的故宫里，身穿红黑色蕾丝晚礼服，修长的大腿，她面向前方迎面走来，优雅的姿态，脸带微笑，环绕拍摄的镜头，身后跟着两条拉布拉多犬。应该说，Vidu的新版本，带来了令人惊喜的能力升级，因为各家产品都在快速迭代，而且生成内容，侧重点，使用方式的不同，很难说谁一定最强，但Vidu的生成质量和独特的参考生视频能力，使其稳居国内类似产品前三的位置，那是没有什么问题的。更新后的产品主页明显跟上了时代。 ...继续阅读 (2)

ControlNet以及Lora是什么，玩过stable diffusion AI图像生成的同学应该都不陌生。一般来说，如果你用以SD 或 SDXL为基础的模型来生成图像，产出的图像往往非常随机，很难对图像的内容做相对精确的控制。尤其是原始的SD和SDXL的底模，拥有很好的图像泛化能力（也就是说能根据提示词输出各种类型的图像），但也使得图像的效果通常不是最佳的，对内容的定向精确化控制的能力往往也不足。比如你想让生成的图像更接近真人摄影风格一些（肤质，环境，灯光，胶片感等等） ...继续阅读 (20)

这篇文章是面向有一定理工科基础，能理解一些基本的工程逻辑或理工常识，但非数学或算法相关专业或职能的同学。他们可能对相关系统，架构感兴趣，想要从基本原理的角度去理解它的核心思想，进而希望做到能有自己的观点和判断，有理有据，不人云亦云。 ...继续阅读 (24)

以当前业界的情况来看，AI4DATA可以做些什么，生成式BI应该具备什么样的能力，适用于什么样的场景，呈现出什么样的产品形态，并没有明确的定义或共识，大体还处在一个集思广益，积极探索能力边界的阶段。以下仅根据笔者工作实践过程中，所接触到的客户需求，业界的产品为线索，结合个人的认知和理解，谈一下从满足用户BI工作链路需求的角度来看，生成式BI可能需要具备的各种能力。同时，按照各种能力对客户商业智能洞察这个终极目标需求的满足程度，智能化程度，做一下成熟度的阶段划分。 ...继续阅读 (16)

这篇实际上4年前就写了，但是一直没发在csdn上，是上一篇如何写好项目规划和方案设计文档_colorant的专栏-CSDN博客_项目方案的具体实践问题后续。 补发一下 上一篇，重点讲述的是撰写项目规划和方案设计文档的指导原则，要写成什么样子才能发挥它应有的价值。 具体如何做到，往往还需要实践经验和技术功底的支撑，仅仅知道方向，很可能也是心有余而力不足。 尽管如此，还是有一些在具体实践环节中通用的方法论和Checklist清单，可以帮助到大家。让大家在自己的能力范围内，将思考的过程变得标准化，... ...继续阅读 (14)

据说，因为太聪明，太理智，太勤奋，太优秀。。。所以，后来他们大部分都落到了穷困潦倒的地步。 我的天呐，这怎么可能？ 你不信，我也不信，直到最近看了一本书。书里大部分的章节写的就是这样的悲剧故事，认真读了一遍，不得不认同作者的观点，也顺便学习了一下如何避免这样的悲剧。（这样的书我也敢读，我想我是膨胀了。） 所以，这本书的名字叫做：《创新者的窘境》 人们通常认为，一些行业领先的企业如果未能保持其领... ...继续阅读 (21)

在工作中，很多时候，我们都需要就一个问题提出一个解决方案，这时候，我们很可能需要产出一个文档来供大家讨论，并指导下一步工作计划。 问题可大可小，形式上是否叫它为一个项目并不重要，重要的是为了解决这个问题，项目规划和方案设计的流程是一致的。就大数据平台构建的语言环境来说，它可以是整个平台体系的搭建方案，也可以是具体某个组件如调度系统的建设，还可以是某个具体的功能点或问题改进比如用户任务脚... ...继续阅读 (13)

之前的文章，整理了一下，补充了一些内容，做了一些更新，现已出版上市了。无耻的推广一下哈 ；） 淘宝，JD都有现货，Amazon貌似还是预售状态中感谢博文视点的@侠少，感谢各位替本书写推荐语软文的朋友们，感谢之前蘑菇街大数据团队的各位小伙伴。目录列表：第1章  大数据平台整体建设思想 11.1  什么是大数据平台 11.2  大数据平台的建设目标 31.2.1  别人的大数据平台是怎样的 31.2.... ...继续阅读 (11)

如果关注这个领域的同学可能知道，Ray其实在去年就已经在开源社区正式发布了，只不过后来就一直没有什么太大动静，前段时间也是因为机缘巧合，我又回头学习了解了一下，顺便总结如下：Ray是什么？Ray 是RISELab实验室（前身也就是开发Spark/Mesos等的AMPLab实验室）针对机器学习领域开发的一种新的分布式计算框架。按照官方的定义：“Ray is a flexible, high-perf... ...继续阅读 (9)

什么是元数据？在前面的集成开发环境建设相关文章中，我们也提到过，元数据MetaData狭义的解释是用来描述数据的数据，广义的来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。比如数据表格的Schema信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等等。管理这些附加MetaData信息的目的，一方面是为了让用户能够更高效的挖掘和使用... ...继续阅读 (9)

不论是在技术层面还是在产品层面，大数据平台环境下的权限管理工作都是一个让人伤脑筋的烫手山芋，它不仅仅是一个技术问题，还是一个业务问题，甚至还可能是一个人际沟通和权衡利益得失的哲学问题。。。所以，以下内容分两部分展开，先谈哲学问题，再谈技术问题。 ...继续阅读 (12)

日志采集这部分内容，其实在上一篇文章 阿里巴巴大数据实践-读书笔记 里面多多少少已经提到了一些。不过正如前文提到的，这部分内容，从技术的角度来说，未必有多么高深，但是从业务角度来说，要做到完善却也很难，特别是在分析用户行为链路的场景下，所以这篇专门来讨论一下这一块的内容。 ...继续阅读 (12)

大数据集群迁移这件事，不知道有多少同学做过。我说的不是把一个集群的数据备份到另一个集群上。我指的是整个数据平台与大数据相关的所有集群及业务的迁移工作，从一个机房到另一个机房。这事，我们已经做了三次了。。。 ...继续阅读 (16)

上一篇文章，讨论了作业调度系统的分类，流派，架构实现方案和各种方案的优缺点以及适用场景，最后还简单总结了理想中，一个完备的工作流作业调度系统，应该具备哪些功能特性。但是，纸上得来终觉浅，绝知此事要躬行。实践才是硬道理。我司刚巧在开发工作流作业调度系统这块有一些实践经验，所以这篇文章来和大家探讨一下过去两年多来，我司Jarvis调度系统的产品功能定位，架构实现以及经验教训。 ...继续阅读 (14)

前面放完建设四个现代化大数据平台乌托邦理想的大卫星，接下来的文章得谈谈具体组件的生产大跃进了。第一篇，先来讨论一下大数据开发平台的核心组件之一：作业调度系统。作业调度系统是一个相对复杂的系统，涉及的内容繁杂，针对的场景多种多样，实现的方案千差万别。本文重点谈理论，会先从大的场景划分的角度对市面上的各种调度系统进行分类讨论，然后再针对具体的作业调度系统，探讨一下各自的优缺点 ...继续阅读 (18)

流式计算框架编程接口的标准化，傻瓜化，SQL化，自打谷歌发表Dataflow编程模型的Paper起，就有走上台面的趋势。各家计算框架都开始认真考虑相关的问题，俨然成为大家竞争的热点方向。在过去一年多的时间里，Beam／Flink／Spark在这方面的努力和相关工作也逐渐落地成熟，实际线上成熟应用的日子看起来指日可待了。 所以，翻出一年多前阅读DataFlow Paper的旧文，更新一下部分过时信息 ...继续阅读 (16)

要事第一，《大数据务虚杂谈》的二维码： ：）很久以前，就有在CSDN博客上写技术文章的习惯，尽管三天打鱼半年晒网，但好歹写了快十年了。 但是在公众号上写技术文章，我其实一直是拒绝的。原因很简单，大家在微信上碎片化的阅读习惯，让我一直觉得，它压根就不适合用来传播需要花点时间动脑思考（枯燥）的技术类文章，加上阅后即弃的瀑布式阅读模式，简直就是技术类文章的大敌。所以，我的第一个公众号，写的是偏生活娱乐类文章，关于生活中的一些兴趣爱好，比如乐高，桌游，摄影，旅行 ；） ---- 可是时代在变，人也会变 ：） 当微信成为一个主流传播渠道之一时，在上面的阅读习惯也在演进，比如我自己，就订阅了不少居然胆敢把大部分文章写到五千到一万字以上的公众号。。。而我自己，也很少像过往一样，写一篇比如像“深入剖析YAFFS2文件系统”这样深入Internal细节的文章（如果你一脸懵逼，YAFFS2是Yet Another Flash File System version 2 “又一个闪存文件系统版本二”的缩写，十年前很新的一个在手机上使用的文件系统），从内部数据结构一直讲到外部构建工具。 同样，在这个“务虚”的“技术类”公众号中，我也不打算写任何类似XXX代码详解，XXX优化，XXX问题的解决这类涉及具体实操的文章（事实上，即使是在博客上，我好像也就几乎没写过这类文章，个人尤其痛恨代码解读这类不加全局理论抽 ...继续阅读 (14)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/整体概念复杂的产品不可持续TODO：我们有哪些产品在功能设计方面，已经超过了它应有的复杂度？需要重点关注改进，或者抽象简化的？为主流用户设计，而非专家用户主流用户和专家用户的划分，需要根据业务具体分析，比如自定义查询的主流用户和开发平台的主流用户，可能就不是一个人群，何谓主流功能和专家功能，定义就可能不一样再比如即使只服务BI／数仓／开发同学的平台，哪些同学的需求，是其中偏少数派的需求，属于专家用户而非主流用户的，在听取客户建议时，也需要反复提醒自己，甄别需求。对业务和系统最熟悉的同学的意见，并不一定是主流意见。要避免为了满足专家用户的需求，把系统搞得过于复杂，但也不能完全忽略，这就需要根据以下的四个策略原则来具体解决了。实际操作中，如何识别那些是专家用户需求，哪些是主流用户需求，可能，更多的还要依靠数据的反馈，及时的调整，毕竟大范围的调查成本很高，不是所有的功能开发流程都能这样实施，特别是大众用户对自己的需求很可能也不明确的时候简单意味着控制，要让用户感觉自己掌控了一切个人理解，功能，界面不要让用户迷茫是一回事。就掌控一切的角度来说，在交互反馈上，还需要注意：任何操作，都需要有明确的结果反馈，比如：我们提交完一个任务以 ...继续阅读 (15)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/下面的内容，仔细想想，好像是一篇鸡汤文章，而我，最讨厌做烂大街的事，所以，为什么还要写？这，是个问题。。。本质上，鸡汤这玩意，看着有理，但知易行难，如果不实践，或者没有切身体会，，再多都是陈词滥调。君不见，先贤们都总结了五千年了，时下，毒鸡汤反倒成了一股“清流”跑题了，为什么要写，还是因为切身体会吧。数据平台，做为底层服务，技术难度不小，稳定性要求高，而同时，不论上游依赖还是下游业务，都是错综复杂的，数据本身和上层业务又紧密相关，应用场景复杂，加上我们团队能力的确有限，因此，历来都是被抱怨的重灾区。当然，这一切只是原因，不是理由，所以，在过去的一年里，如何直面现实，从观念入手，更好的改进我们的服务，也就成了我无法逃避的问题。以下内容，更多的是教训和体会，然后，感受最深的，就抽象成几句话。我自己做得也并不如意，和大家共勉。主观即是客观客户就是上帝呗，我一向如此，除了上帝犯错的时候 ：）本质上，想想我们之所以有时候不把客户的意见和抱怨当一回事，很可能是在一些场景下，我们认为，客户的意见，是没有道理的！ 比如：这种错误都会犯，太奇葩了，就不能好好学习，多谷歌一下吗？怎么使用，说明文档上都写了，也培训过好多遍了，群里都说过了，怎 ...继续阅读 (10)

RC ORC Parquet 格式比较和性能测试作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/为什么要比较这三者为什么要比较，起因是为了提高Hadoop集群的存储和计算效率，尤其是离线Hive作业的效率，为什么比较的是这三者，是因为三者是目前Hive离线作业中正在大规模使用或可能大规模使用的三种主流的相对成熟的文件格式对于ORC性能的评测，Hortonworks发过一篇被广泛传播和引用的博客 :ORCFILE IN HDP 2: BETTER COMPRESSION, BETTER PERFORMANCE这篇文章在ORC改进原理等方面说的比较客观，但是实际的benchmark比较数据，即使不说是有故意偏颇的嫌疑，至少也是不科学不客观的，特别是下面这张文件尺寸比较，带有很大的误导性。这个测试的数据集，看起来用了TPC－DS的数据，貌似很专业的样子但是首先，这里的测试方法明显的就不科学，压缩算法并不相同有什么好比的（Snappy侧重性能，Zlib侧重压缩率）？不知道作者对RCFile采用了什么压缩算法，但是Parquet＋Snappy，ORC＋Zlib，这种比较的基调就不公正（当然，这个问题，作者说是因为这是它们默认的压缩格式，但是科学严谨的来说，benchmark应该 ...继续阅读 (15)

StartFragment作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/主要介绍一下Dataflow编程模型的基本思想，后面再简单比较一下spark2.0structuredstreaming的编程模型==是什么== 谷歌Dataflow首先是一个服务https://cloud.google.com/dataflow，为用户提供以流式或批量模式处理海量数据的能力，该服务的编程接口模型（或者说计算框架）也就是下面要讨论的dataflowmodel 流式计算框架处理框架很多，也有大量的模型／框架号称能较好的处理流式和批量计算场景，比如Lambda模型，比如Spark等等，那么dataflow模型有什么特别的呢？ 这就要要从流式（streaming）和批量（batch）这两个词的语意说起，简单的说，谷歌的同学认为目前的各种计算框架模型以及用户在一定程度上对这两个词的语意的使用姿势不够恰当，或者说用这两个词来区分应用场景，进而给计算框架分类并不合适。而这种分类给框架的应用甚至设计带来了一定的认识的误解和偏差。 谷歌的同学认为，当大家谈论到流式计算，或者流式数据时，内心想表达的场景，实际上更准确的说法应该是unbounded data( ...继续阅读 (25)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/StartFragment## ==是什么== Kudu是ToddLipcon@Cloudera带头开发的存储系统，其整体应用模式和HBase比较接近，即支持行级别的随机读写，并支持批量顺序检索功能。 那既然有了HBase，为什么还需要Kudu呢，简单的说，就是嫌弃HBase在OLAP场合，SQL／MR类的批量检索场景中，性能不够好。通常这种海量数据OLAP场景，要不走预处理的路，比如像EBAY麒麟这样走Cube管理的，或者像谷歌Mesa这样按业务需求走预定义聚合操作。再有就是自己构建数据通道，串接实时和批量处理两种系统，发挥各自的特长。 但是OLAP是个复杂的问题，场景众多，必然不可能有完美的通用解决方案，Kudu定位于应对快速变化数据的快速分析型数据仓库，希望靠系统自身能力，支撑起同时需要高吞吐率的顺序和随机读写的应用场景（可能的场景，比如时间序列数据分析，日志数据实时监控分析），提供一个介于HDFS和HBase的性能特点之间的一个系统，在随机读写和批量扫描之间找到一个平衡点，并保障稳定可预测的响应延迟 那为什么不能想办法改进HBase呢？Todd自己做为HBase的重要贡献者 ...继续阅读 (19)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/StartFragment==目标问题== 谷歌Mesa是一个服务于谷歌广告业务的近实时分析型数据仓库，其设计目标包括： 原子更新操作一致性高可用性近实时海量数据更新海量查询下的低延迟水平拓展在线数据／元数据变更（不影响线上读写业务） ==基本业务模型== Mesa不是一个完全从头构建的系统，而是构建在谷歌已有的几个分布式系统服务至上，它使用Bigtable存储元数据，GFS／Colossus存储Data，MapReduce进行批量计算 对用户而言，其基本数据模型就是一个类KV型数据仓库，Mesa表里面的每一行数据，由一组维度（key）／和度量值（value）来定义，基本对应的一张事实表的概念，如下图例：  基于Mesa服务的广告系统Metrics数据普遍的可聚合性，Mesa要求对值空间的的每个字段定义一个聚合函数，聚合函数要求满足结合律，最好具备交换律。 数据本身的存储，采用MVCC的模式进行版本标识，在数据更新和查询时，需要指定版本。 Mesa最基本的查询操作是指定查询版本N，以及Key的过滤条件，其返回结果是满足查询条件的Ke ...继续阅读 (20)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/是什么 简单的说，OMID就是Yahoo构建在HBase上的一个分布式事务解决方案，用来拓展HBase所不支持跨行跨表级别的事务。其定位目标是OLTP类型的事务。类似的系统也有不少，他们或多或少都借鉴了谷歌的Percolator的思想，而omid则有较大的区别，具体区别在哪，下文详细分析。 以下关于Omid的理解主要参考Omid的各种文档和相关Paper，因为没有详细参考Omid的最新代码去比较文档描述的流程，所以如果理解有误的地方烦请指出 总体架构思想 同多数构建在类HBase的NoSqlKV数据库上的分布式事务实现方案类似，OMID的总体思想是通过HBase提供的多版本数据支持，借助于MVCC来实现分布式事务，理论上只要是提供多版本数据支持的DataStore都能套用OMID的实现。与Percolator不同的是，Percolator通过BigTable自身存储锁信息进行两阶段提交来完成事务支持，而Omid的事务实现方式是基于中心服务器仲裁的无锁方案，下面具体看看他是怎么实现的。 首先和多数MVCC方案一样，OMID需要一个TO（TimeOracle时间服务）来提供MVCC所需要的递增时间戳，在此基础上，OM ...继续阅读 (188)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/StartFragment最近了解了一下基于HBase的分布式事务的实现方案，首先当然是要看一下google的percolator的paper了，顺便了解了一下几个相似的开源实现。 关键字 Percolator,BigTable,分布式事务,增量计算 ==目标问题== Percolator的目标是在海量规模的数据集上提供增量更新的能力，并通过支持分布式的事务来确保增量处理过程的数据一致性和整体系统的可扩展性。 这个目标的需求来源于对谷歌的网页索引系统的改进，此前谷歌的网页索引系统采用的是基于MapReduce的全量批处理流程，所有的网页内容更新，都需要将新增数据和历史全量数据一起通过MapReduce进行批处理，带来的问题就是网页索引的更新频率不够快（从爬虫发现网页更新到完成索引进入检索系统，需要2-3天或者更长的周期） ==核心思想== 构建这样的系统，本质的需求是 首先，底层的存储系统中，数据集本身必须是可以水平扩展，并支持增量更新的其次，要保证增量处理的吞吐率，必然需要支持大量并发的数据更新操作（这点和基于MR的处理过程不一样），在这种应用场景下，分布式事务的支持也就成为了一个必须要支持的特性，通过分布式事务的支持 ...继续阅读 (189)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/随着Spark的逐渐成熟完善,越来越多的可配置参数被添加到Spark中来,本文试图通过阐述这其中部分参数的工作原理和配置思路,和大家一起探讨一下如何根据实际场合对Spark进行配置优化。由于篇幅较长，所以在这里分篇组织，如果要看最新完整的网页版内容，可以戳这里：http://spark-config.readthedocs.org/，主要是便于更新内容schedule调度相关调度相关的参数设置，大多数内容都很直白，其实无须过多的额外解释，不过基于这些参数的常用性（大概会是你针对自己的集群第一步就会配置的参数），这里多少就其内部机制做一些解释。spark.cores.max一个集群最重要的参数之一，当然就是CPU计算资源的数量。spark.cores.max这个参数决定了在Standalone和Mesos模式下，一个Spark应用程序所能申请的CPU Core的数量。如果你没有并发跑多个Spark应用程序的需求，那么可以不需要设置这个参数，默认会使用spark.deploy.defaultCores的值（而spark.deploy.defaultCores的值默认为Int.Max，也就是不限制的意思）从而应用程序可以使用所 ...继续阅读 (38)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/随着Spark的逐渐成熟完善,越来越多的可配置参数被添加到Spark中来,本文试图通过阐述这其中部分参数的工作原理和配置思路,和大家一起探讨一下如何根据实际场合对Spark进行配置优化。由于篇幅较长，所以在这里分篇组织，如果要看最新完整的网页版内容，可以戳这里：http://spark-config.readthedocs.org/，主要是便于更新内容压缩和序列化相关spark.serializer默认为org.apache.spark.serializer.JavaSerializer,可选org.apache.spark.serializer.KryoSerializer,实际上只要是org.apache.spark.serializer的子类就可以了,不过如果只是应用,大概你不会自己去实现一个的。序列化对于spark应用的性能来说,还是有很大影响的,在特定的数据格式的情况下,KryoSerializer的性能可以达到JavaSerializer的10倍以上,当然放到整个Spark程序中来考量,比重就没有那么大了,但是以Wordcount为例，通常也很容易达到30%以上的性能提升。而对于一些Int之类的基本类型数据， ...继续阅读 (291)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/随着Spark的逐渐成熟完善,越来越多的可配置参数被添加到Spark中来,本文试图通过阐述这其中部分参数的工作原理和配置思路,和大家一起探讨一下如何根据实际场合对Spark进行配置优化。由于篇幅较长，所以在这里分篇组织，如果要看最新完整的网页版内容，可以戳这里：http://spark-config.readthedocs.org/，主要是便于更新内容Storage相关配置参数spark.local.dir这个看起来很简单，就是Spark用于写中间数据，如RDD Cache，Shuffle，Spill等数据的位置，那么有什么可以注意的呢。首先，最基本的当然是我们可以配置多个路径（用逗号分隔）到多个磁盘上增加整体IO带宽，这个大家都知道。其次，目前的实现中，Spark是通过对文件名采用hash算法分布到多个路径下的目录中去，如果你的存储设备有快有慢，比如SSD+HDD混合使用，那么你可以通过在SSD上配置更多的目录路径来增大它被Spark使用的比例，从而更好地利用SSD的IO带宽能力。当然这只是一种变通的方法，终极解决方案还是应该像目前HDFS的实现方向一样，让Spark能够感知具体的存储设备类型，针对性的使用。需要注意的 ...继续阅读 (32)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/随着Spark的逐渐成熟完善,越来越多的可配置参数被添加到Spark中来,在Spark的官方文档http://spark.apache.org/docs/latest/configuration.html中提供了这些可配置参数中相当大一部分的说明.但是文档的更新总是落后于代码的开发的,还有一些配置参数没有来得及被添加到这个文档中,最重要的是在这个文档中,对于许多的参数也只能简单的介绍它所代表的内容的字面含义,如果没有一定的实践基础或者对其背后原理的理解,往往无法真正理解该如何针对具体应用场合进行合理配置。本文试图通过阐述这其中部分参数的工作原理和配置思路,和大家一起探讨一下如何根据实际场合对Spark进行配置优化。需要注意的是，理论上，没有绝对正确的配置（否则也就不需要对应的配置参数了，Spark框架内部直接写死就好了），所以请结合自己的实际情况，辩证的看下面的内容。由于本文主要针对和性能相关的一些配置参数进行阐述，所以基本不会覆盖其它和性能没有太多关系的配置参数。由于篇幅较长，所以在这里分篇组织，如果要看最新完整的网页版内容，可以戳这里：http://spark-config.readthedocs.org/，主要是便 ...继续阅读 (28)

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/Dryad的论文是微软早在2007年就发布的，Tez的核心思想来源于Dryad，差不多可以算是Dryad的开源实现吧。最近正好看到几个有趣的项目是基于Tez实现的，于是顺便追本溯源，学习了一下Dryad的理论基础==目标问题==Dryad的设计目标和当时先后出现的各种分布式运算框架一样，是为了简化大规模分布式编程的难度，提供给用户一个简单通用的分布式运算框架。和其它分布式运算框架解决的问题类似，不外乎就是用户不需要考虑分布式运算所涉及的众多繁琐的问题，例如资源分配，并发调度，系统容错等等，而只需要关注核心运算逻辑。==核心思想==按照官方定义，Dryad是一个通用的粗颗粒度的分布式计算和资源调度引擎，这里所说的粗颗粒度，自然指的是针对批量数据进行处理的这种应用模式，当然批处理的粒度可大可小。Dryad的核心数据模型由Vertex计算节点和Channel数据通道两部分组成，用户通过实现自定义的Vertex节点来执行定制的运算逻辑，而节点之间通过各种形式的数据通道传输数据，用户的运算逻辑本身通常是顺序执行的，而与分布式相关的逻辑则由Dryad框架来实现。如图所示的是Dryad的系统架构框图。Dryad的作业管理 ...继续阅读 (51)