张包峰的博客

上面这件事一般IBasicBolt可以罩住，更多的方法可以使用IRichBolt。一个topology里面的acker数量是可以设置的，然后tuple比较多的话可以多设置几个acker，提高效率。每个tuple有一个64位的id，acker利用这个id来追踪tuple，且会知道这个tuple他的祖宗们，也就是只要继续跟踪新的tuple就可以了，因为祖宗的id会被传递下去。storm用一致性哈希来把spout-tuple-id对应给acker，因为tuple知道自己的祖宗，所以他可以算出通知哪个acker

DAG vs. MPPNative DesignMPP每个Segment高度对称(symmetric)，狭义MPP storage各个Segment自己管理，自己备份，涉及某数据相关的query必定会落到某个Segment上，有concurrency和straggler的问题存在。MPP天然有很优秀的Compiler和Optimizer，包括local runtime环境是数据库，解析、优化、cod

本文描述了在OS X上安装使用Marathon的过程。Marathon简介Marathon是Mesosphere公司为Mesos生态圈打造的一个轻量级、扩展性很强的调度long-running service的调度框架。支持RESTful api来创建和管理app，自动为app做容错迁移，凡是能用shell起的任务，理论上都可以通过Marathon在mesos上简单地启动和管理起来。下图为Mesos

Infobright作为开源的MySQL数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算等内容，本文是摘抄了infobright论文里最重要的设计点，KnowledgeGird是infobright设计上的核心。brighthouse是一个面向列的数据仓库，在列存储和压缩数据方面，数据压缩比达到10：1。其核心Knowledge Grid（知识网格）层，即一个能自动调节、所存出具特别小的元数据层，替代了索引的功能，提供了数据过滤、统计信息表达、实际数据位置信息等内容，让brightho

Vertica与传统数据库系统和其他列式数据仓库系统相比的话，在性能上有比较明显的优势，在设计上有一些异同，比较适合ad-hoc查询，OLAP类型的作业。总的来说，Vertica通过列存储减少了io开销，再加上高效的压缩手段，极大节省了磁盘空间，基于此Vertica采用多备份来保证高可用性，并且多备份又能够增强查询性能。在使用和运维角度了，Vertica自带工具帮助用户做物理表的存储，能提供标准SQL接口，也兼容现有的BI、ETL工具方便作业往Vertica上迁移，而且Vertica部署对硬件没有特殊要求，

背景异构数据的适配及数据可扩展性，资源可扩展性，廉价机器，SQL查询。架构概述Worker pool，query server，clientinterfaces，metadata serverWorker线程是long-running的，worker pool包括master节点和worker节点，以及一个master watcher。Query server把query解析，优化之后传给master执行，优化包括一些基本的规则优化和基于成本的优化。

核心抽象和基本原语PCollection<T>是一个不可变的bag，可以是有序的(Sequence)，也可以是无序的(Collection)。PCollection可以来自于内存里的Java PCollection对象，也可以读取自文件。 PTable<K, V>，可以看成PCollection<Pair<K, V>>，不可变无序multi-map。 第一个原语是parallelDo()，把PCollection<T>变成新的PCollection<S>，处理方式定义在DoFn<T, S>里。e

背景是设计一个实时数据接入的模块，负责接收客户端的实时数据写入（如日志流，点击流），数据支持直接下沉到HBase上（后续提供HBase上的查询），或先持久化到Kafka里，方便后续进行一些计算和处理，再下沉到文件系统或做别的输出。在设计中，对于客户端和服务端有这么些目标。客户端需要支持多语言（Java，C++），做得尽量轻量级，只要连上服务端的ip:port，以RPC的形式调用简单的write就可以把数据写出去。客户端不承担任何逻辑的处理，服务端的负载均衡对客户端是透明的。服务端想要做的是一个去中心

Slave模块三种Executor的设计，主要考虑的是各个Executor挂掉之后，怎样保证数据处理的不重复和不遗漏。我们依赖Zookeeper的可靠性，记录、更新、判断Bundle的状态，做到Input、Cache、Output各司其职，最到最小粒度的容错。Executor本身的失败和重启则由Mesos保障，Mesos作为资源管理系统，由Master监控Slave上各个Executor的执行状况，通过回调，可以在合适的Slave上再次启动挂掉的Executor进程，保证业务Task的顺利进行。

BK是一个可靠的日志流记录系统，用于将系统产生的日志(也可以是其他数据)记录在BK集群上，由BK这个第三方Storage保证数据存储的可靠和一致性。典型场景是系统写write-ahead log，即先把log写到BK上，再对log做处理，比如将log写到内存的数据结构中。BookKeeper同时适用于任何单点写入并要求保证高性能和数据不丢失（Strong Durabilty Guarantees）的场景。BK诞生于Hadoop2.0的namenode HA。在Hadoop中，出于故障恢复的考虑，Namen

最近在设计和开发一个分布式系统的流式处理模块，整个系统用于跨集群、跨机房搬运不同数据源内的数据到另一份或多份数据源上，包括HDFS、MySQl、MongoDB、FTP等。功能比较像Hadoop的Sqoop，但是能扩展支持更多的数据源，且本身是个集群部署，不像Sqoop需要依赖Hadoop的MR。我们整个cluster的资源管理借助Mesos来完成，由自己定制的Mesos Scheduler向Mesos Master申请可用的资源，具体把数据搬运的任务分发到Mesos Slave的Executor上，而我主

本文译自Storm Github Wiki: Structure of the codebase，有助于深入了解Storm的设计和源码学习。本人也是参照这个进行学习的，觉得在理解Storm设计的过程中起到了重要作用，所以也帖一份放在自己博客里。以下的模块分析里没有包括Storm 0.9.0增加的Netty模块，对应的代码包在Storm Github下的storm-netty文件夹内，内容比较简单，关于这块的release note可以参考Storm 0.9.0 Released Netty Transpor

Flume是Cloudera公司的一款高性能、高可能的分布式日志收集系统。现在已经是Apache Top项目。Github地址。同Flume相似的日志收集系统还有Facebook Scribe，Apache Chuwka，Apache Kafka(也是LinkedIn的)。Flume是后起之秀，本文尝试简要分析Flume数据流通过程中提供的组件、可靠性保证来介绍Flume的主要设计，不涉及Flume具体的安装使用，也不涉及代码层面的剖析。写博文来记录这个工具主要是觉得与最近开发的一个流式的数据搬运的工具在设

AboutI will try to give the mainline of how does Flink buildint the logical plan 2 physical plan 2 task. Main classes and methods are mentioned.Format explainationthis is Class this is method()thi