colorant的专栏

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

所以，你要问，做为大数据务虚系列文章的第一篇，就想搞个大新闻，放一个有中国特色的四个现代化的社会主义大数据平台的卫星么？

分布式一致性协议Raft & Paxos 简单 v.s. 完美

开个公众号： 大数据务虚杂谈

RC ORC Parquet 格式比较和性能测试作者：刘旭晖 Raymond 转载请注明出处 Email：colorant at 163.com BLOG：http://blog.csdn.net/colorant/为什么要比较这三者为什么要比较，起因是为了提高Hadoop集群的存储和计算效率，尤其是离线Hive作业的效率，为什么比较的是这三者，是因为三者是目前Hive离线作业中正在大规模使用或

Kudu是Todd Lipcon@Cloudera带头开发的存储系统，其整体应用模式和HBase比较接近，即支持行级别的随机读写，并支持批量顺序检索功能。定位于应对快速变化数据的快速分析型数据仓库，希望靠系统自身能力，支撑起同时需要高吞吐率的顺序和随机读写的应用场景（可能的场景，比如时间序列数据分析，日志数据实时监控分析），提供一个介于HDFS和HBase的性能特点之间的一个系统，在随机读写和批量扫描之间找到一个平衡点，并保障稳定可预测的响应延迟

Mesa并不是一个从底层开始重新构建的系统，它依托Colossus提供分布式数据存储服务，依托Bigtable做元数据存储。使用MapReduce进行批量数据处理工作。之所以能实现它所声称的这些底层系统所不具备的综合能力（高一致性＋原子更新＋低延时＋近实时＋海量吞吐率），其原因还是因为它针对了广告数据的应用场景，采用了各种类似系统的最佳实践和一些特定的Tradeoff策略

Percolator的目标是在海量规模的数据集上提供增量更新的能力，并通过支持分布式的事务来确保增量处理过程的数据一致性和整体系统的可扩展性。

OMID是Yahoo构建在HBase上的一个分布式事务解决方案，用来拓展HBase所不支持跨行跨表级别的事务。其定位目标是OLTP类型的事务。类似的系统也有不少，他们或多或少都借鉴了谷歌的Percolator的思想，而omid则有较大的区别，具体区别在哪，下文详细分析。

随着Spark的逐渐成熟完善, 越来越多的可配置参数被添加到Spark中来, 本文试图通过阐述这其中部分参数的工作原理和配置思路, 和大家一起探讨一下如何根据实际场合对Spark进行配置优化。－storage篇

随着Spark的逐渐成熟完善, 越来越多的可配置参数被添加到Spark中来, 本文试图通过阐述这其中部分参数的工作原理和配置思路, 和大家一起探讨一下如何根据实际场合对Spark进行配置优化。- 压缩与序列化篇

随着Spark的逐渐成熟完善, 越来越多的可配置参数被添加到Spark中来, 本文试图通过阐述这其中部分参数的工作原理和配置思路, 和大家一起探讨一下如何根据实际场合对Spark进行配置优化。

随着Spark的逐渐成熟完善, 越来越多的可配置参数被添加到Spark中来, 本文试图通过阐述这其中部分参数的工作原理和配置思路, 和大家一起探讨一下如何根据实际场合对Spark进行配置优化。－　任务调度篇

Dryad的论文是微软早在2007年就发布的，Tez的核心思想来源于Dryad，差不多可以算是Dryad的开源实现吧。最近正好看到几个有趣的项目是基于Tez实现的，于是顺便追本溯源，学习了一下Dryad的理论基础

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/在Spark中作业调度的相关类最重要的就是DAGScheduler，DAGScheduler顾名思义就是基于DAG图的SchedulerDAG全称 DirectedAcyclic

以“荣耀”的名义

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

主要介绍一下Dataflow编程模型的基本思想，再简单比较一下spark 2.0 structured streaming的编程模型

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

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

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

幸福的家庭都是一样的，不幸的家庭各有各的不幸 - 如何成为一名糟糕的大数据平台开发工程师？

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

同步一切

全家桶，来一份？

大数据之路-阿里巴巴大数据实践 读书笔记

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

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

前面说完了大数据开发平台的核心组件，作业调度系统，接下来讨论一下大数据开发平台的脸面之一，数据可视化平台。

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

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

同志们辛苦了，为人民服务～

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/Tachyon是AmpLab的Li Haoyuan所开发的一个基于内存的分布式文件系统，出发点是作为AMPLAB的BDAS的一个组成部分 总体设计思想 从Tachyon的设计目

Memcached和Redis作为两种Inmemory的key-value数据库，在设计和思想方面有着很多共通的地方，功能和应用方面在很多场合下(作为分布式缓存服务器使用等) 也很相似，在这里把两者放在一起做一下对比的介绍

这段时间在做HBase的MR Scan的时候遇上了一个Random Lag behind Task的问题，花了很长时间Trouble shooting，其间使用各种工具，脚本profile了各种参数，过程大致Share如下，很长，有兴趣的同学随便看看,一开始用英文写的，太长，懒得用中文再写一遍了: === Environment === 1 master node + 4

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145 关键字MapReduce分布式计算

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145 关键字GFS分布式文件系统 ==目标问题 ==

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多云计算相关项目快速理解文档  http://blog.csdn.net/colorant/article/details/8255910==是什么 == 目标Scope（解

作者：刘旭晖 Raymond转载请注明出处Email：colorant at163.comBLOG：http://blog.csdn.net/colorant/ 最近在Hadoop1.0.4稳定版上搭的1+4节点上运行MR Job,遇到一些Latency的问题,记录Share一下在 hadoop 1.0.4的版本中,Jjobtracker默认的最小Heartbe

作者：刘旭晖 Raymond 转载请注明出处Email：colorant at 163.comBLOG：http://blog.csdn.net/colorant/更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145关键字Paxos, 实现,可靠性，性能，Chubby ==