张包峰的博客

我们是全球领先的云数据库技术团队，这里有极具挑战性的岗位期待你的加盟： 阿里云-数据库技术组-分布式数据库研发工程师 岗位描述: 1.负责云数据库分布式计算引擎或者列存索引等核心模块的研发工作 2.负责提升系统的易用性、稳定性，提升资源利用率和性能。 岗位要求: 1.在分布式计算/存储/数据库/OLAP等领域有3-5年的开发和优化经验者优先 2.对开源的Hadoop/Spark/

刚才把之前写的大半年来做的计算这点事看了一遍，还是蛮感慨的。从那时到现在，又半年过去了。当时BH这层runtime正在已混布的方式与另一个集团内的OLAP系统为某项目落地而集成，具体就不谈了。截止目前，这种”狼狈”的组成形式终于比较令人满意地磕磕碰碰着落地了。年后，主要磨了系统的稳定性，在真实数据上做压测，自己对系统摸了底。结果还算满意。

Flink SQL UT Case截止当前flink master分支最新的代码(未完成的1.1版本)，Flink Table项目的UT，batch sql(即直接调用.sql())的sql, logicalPlan, physicalPlan整理。/** Filter **/SELECT * FROM MyTable WHERE falseLogicalProject(_1=[$0], _2=[$

Flink Stream SQLOverviewblog https://flink.apache.org/news/2016/05/24/stream-sql.html提到目前Table API的问题，batch和stream的API各自能支持的query不一样。 However, the original Table API had a few limitations. First of a

SQL Impl in Flink跟了下Flink Table里sql的实现，flink sql的实现比较简单，一句话概述就是：借助Apache Calcite做了sql解析、逻辑树生成的过程，得到Calcite的RelRoot类，生成flink的Table，Table里的执行计划会转化成DataSet的计算，经历物理执行计划优化等步骤。类比Spark SQL，Calcite代替了大部分Spark

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

AspectsInterconnectUDP(User Datagram Protocol) , additional packet verification, the reliability is equivalent to TCP(Transmission Control Protocol), and the performance and scalability exceeds that of

AboutI will try to give the mainline of how does Flink task works.Main classes and methods are mentioned.Format explainationthis is Class this is method()this is constantTask ExecutionTask Compone

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

先把梳理逻辑图放着，有空分析 :)戳大 http://img.blog.csdn.net/20160412144546178Gremlin文档 http://tinkerpop.apache.org/docs/3.1.1-incubating/reference

背景测试了一个case，用GraphX 1.6跑标准的LPA算法，使用的是内置的LabelPropagation算法包。数据集是Google web graph，(忽略可能这个数据集不是很合适)，资源情况是standalone模式，18个worker，每个worker起一个executor，50g内存，32核，数据加载成18个分区。case里执行200轮迭代，代码:import org.apache

这两天搬家，身体很劳累，脑子算是没闲着。在把货物搬上楼的过程中，我琢磨了个自认为很高效的方法，本质和流式处理很像。需求与尝试 一车货物，零零散散打了些包，停在楼下，需要搬到五楼去。劳力有三人。一开始的方案是每个人自己拿几样东西，自管自上楼去，再下楼来拿下一趟。搬了几趟后，有以下一些问题： 1. 搬运过程中，累的不是手臂，而是脚。光爬几次五楼，腿已经先受不了了。 2. 过程中为了方便，楼下车不锁

写一篇随笔，谈谈大半年来做的一些事情。简单地说，从去年三月份到现在，一直在做一个计算框架:BH，一个core。我对自己的要求是，掌握Spark(和Flink)，然后忘了它。所以层面core基本和spark core的层次是一致的，核心是pipeline和DAG。开始做这件事的时候，Flink当时的两层runtime还没统一成pipeline，所以当时与spark core实现思想的主要区分之一就在于

背景graphx实现k-core比较简单，参考淘宝技术部之前的文章，已经给出了一个代码片段，基本上改改就可以定制自己的需求了。codeimport org.apache.spark._import org.apache.spark.graphx._import org.apache.spark.storage.StorageLevelimport org.apache.spark.graphx

背景简单分析一下GraphX是怎么为图数据建模和存储的。入口可以看GraphLoader的函数，def edgeListFile( sc: SparkContext, path: String, canonicalOrientation: Boolean = false, numEdgePartitions: Int = -1, edgeS

背景本文给出了一个简单的计算图中每个点的N度关系点集合的算法，也就是N跳关系。之前通过官方文档学习和理解了一下GraphX的计算接口。N度关系实现思路： 1. 准备好边数据集，即”1 3”, “4, 1” 这样的点关系。使用GraphLoader 的接口load成Graph 2. 初始化每个Vertice的属性为空Map 3. 使用aggregateMessages把VerticeID和

问题zookeeper抛这样的错误： [main-SendThread(localhost:2000)] ERROR org.apache.zookeeper.ClientCnxn - Unable to open socket to localhost/0:0:0:0:0:0:0:1:21814549 [main-SendThread(localhost:2000)] WARN org.ap

背景Apache Zeppelin提供了web版的类似ipython的notebook，用于做数据分析和可视化。背后可以接入不同的数据处理引擎，包括spark, hive, tajo等，原生支持scala, java, shell, markdown等。它的整体展现和使用形式和Databricks Cloud是一样的，就是来自于当时的demo。Mac OS上安装目前github上，zeppelin版

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

小白来山寨一把官网文档。Docker不能直接跑在OS X上，需要先安装下VirtualBox和boot2docker。boot2docker会帮我们启动vm，启动docker，并且本身提供一些管理命令。 boot2docker也很轻量级，完全在内存里启动一个VM，只占24M大小，几秒内就可以启动。安装过程1) 下载VirtualVM-xxx-xxx.dmg，并安装。 2) 使用brew安装boo