张包峰的博客

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

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

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

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

Apache Crunch是FlumeJava的实现，为不太方便直接开发和使用的MapReduce程序，开发一套MR流水线，具备数据表示模型，提供基础原语和高级原语，根据底层执行引擎对MR Job的执行进行优化。从分布式计算角度看，Crunch提供的许多计算原语，可以在Spark、Hive、Pig等地方找到很多相似之处，而本身的数据读写，序列化处理，分组、排序、聚合的实现，类似MapReduce各阶段的拆分都可以在Hadoop里找到影子。本文介绍Crunch在数据表示模型、操作原语、序列化处理方面的设计和

背景前段时间在为内部自研的计算框架设计算子层，参考对比了一些开源的计算框架的算子层，本文做一个粗粒度的梳理。下面这张图是我对计算框架抽象层次的一个拆分，具体可以参考上周日杭州Spark meetup上我做的Spark SQL分享 slides。

Spark Runtime里的主要层次分析，梳理Runtime组件和执行流程，DAGSchedulerJob=多个stage，Stage=多个同种task, Task分为ShuffleMapTask和ResultTask，Dependency分为ShuffleDependency和NarrowDependency面向stage的切分，切分依据为宽依赖维护waiting jobs和active job