The ScreamScope Model: Microsoft ScreamScope 编程模型

插曲

screamscope 论文读了好几个月了,把之前分享,今天发出来。


总结:

论文主要是提出一种设计理念 rVertex/rStream, 这个设计理念其实还非常先进。尤其是在低延迟和容错性上思考很多

这个设计理念换了一种角度来思考常见的分布式计算框架(常见思路,主要是考虑DAG 和节点), 将计算拆解为计算单元(rVertex)和管道(rStream)2种抽象, 尤其是管道(rStream)将上下游的关系进行解藕, 对failure 问题上还是解的很漂亮。

核心一些观点:

  • 这套系统起源于批处理系统SCOPE, 是对SCOPE 系统一个扩展,并且将原来一些批处理的任务已经迁移到StreamScope 上。已经部署到2万台机器上,每天处理百亿/数十TB 的数据。另外因为它起源于SCOPE, 它应该用sql 解决应用问题上, 会比其他流式框架要更成熟(这个是个人猜测);
  • 用户接口上面, 为用户提供申明式语言(类似sql)和udf,
  • 用户提交一段类sql,将它编译成logic plan(含一些udf和各种算子),然后用优化器,选择一个最优路径,然后,转化为physical plan,部署到每台机器上, 最后用job manager 来跟踪所有的状态。 很多组件都是用scope的组件完成或稍加改造。 (现代系统大致思路都是这个逻辑)
  • 接口抽象上,接口还是适配性非常强; 节点rVertex 提供3个核心接口Load/Execute/GetSnapshot, 这个模型可以适配到绝大部分计算场景。rStream 接口 Write(seq, e)/Register(seq)/GarbageCollect(seq)
  • 在容错性上, 首先通过rStream 来将上下游节点进行解藕, 下游的失败不一定需要影响到上游, 然后提供3种策略来,让用户选择。(读者可以看后面的详细介绍)
  • 在exactly-once 要求上, 依赖3大部分: 1. 容错机制; 2. sequence number(每条消息配置单调递增的) 3. 确定性, 明确每个节点在状态相同时,接受相同输入时(无论是多实例同时计算或者同一个实例重启后计算),必须产生相同结果
  • 性能上, 1. 通过sequence number来减少ack 数据流;2. rStream 的3层设计 (volatile/Reliable/GC)在保障稳定性同时,可以获得一些好的性能。3. 一次读取,可以获取一个小collection

The Dataflow Model: Google Dataflow 编程模型

插曲

《The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing》 2015年,这篇文章就发布了, 每次快速扫描, 理解上总是有些遗漏, 最近,决定将他翻译一下, 仔细阅读一下.
补充一下,2.4及之后的章节自己看了,但是没有翻译, copy一下同事默岭的翻译(版权归默岭所有哦)。

为什么重新设计dataflow 编程模型

  1. 一份代码运行在不同的引擎, 现有很多google的业务方, 使用lambda架构, 实时部分使用millwheel做一些计算,不能保证完全正确, 然后通过离线flumejava作业不停的矫正数据。 (吐槽一句, millwheel 论文里面说自己的强一致多么牛x, 最后在dataflow 论文里面被打脸, 不过,millwheel里面提到的强一致设计是可以保证强一致,但成本非常高)。 业务方只需要实现一次代码,就可以在不同的引擎上切换,按照自己的业务需求。
  2. 会话窗口需求, 需要支持session window
  3. trigger, accumulate和retraction 需求, 一些业务方使用watermark来标记数据已经完成,但经常有数据延迟到达,因此,需要处理迟到的数据。 整个设计需要考虑: 1. 支持增量处理, accumulate和retraction; 2, trigger机制, 一份相同的数据,根据不同的准确性和扩展性要求,选择不同的模式,从而达到不同的结果。
  4. 水位线百分位触发器, 比如, 部分节点处理特别缓慢, 成为job的长尾, 拖慢了整个项目的进度。 另一个需求是, 很多时候,只需要达到一个很高的准确行就好了,而不是100%准备。 这样,只需要通过percentile watermark trigger, 就可以确定是否要提前终止长尾任务或提前计算。
  5. 时间trigger, 在google 推荐系统中, 使用大量google 基础设施建立用户行为画像, 这些用户行为画像会被用来根据兴趣来做推荐。注意的是, 这些系统使用处理时间进行数据驱动, 因为,这些系统需要经常更新,并且查看局部view 数据比等待直到当watermark 来了计算完整view 更重要。也就是说,对于一些时效要求高的系统, 必须具备根据处理时间来进行驱动的。
  6. 数据驱动 & 组合trigger, 在MillWheel的论文中,我们描述了一种用来检测谷歌网站搜索查询趋势的异常探测系统。当我们为模型设计触发器的时候,这种微分异常探测系统启发我们设计了数据驱动触发器。这种微分探测器检测网站检索流,通过统计学估计来计算搜索查询请求量是否存在一个毛刺。如果系统认为一个毛刺即将产生,系统将发出一个启动型号。当他们认为毛刺已经消除,那么他们会发出一个停止信号。尽管我们可以采用别的方式来触发计算,比如说Trill的Punctuations,但是对于异常探测你可能希望一旦系统确认有异常即将发生,系统应该立即输出这个判断。Punctuations的使用事实上把流处理系统转换成了微批次处理系统,引入了额外的延迟。在调查过一些用户场景后,我们认为Punctuations不完全适合我们。因此我们在模型中引入了可定制化数据驱动触发器。同时这个场景也驱使我们支持触发器组合,因为在现实场景中,一个系统可能在处理多种微分计算,需要根据定义的一组逻辑来支持多种多样的输出。图9中的AtCount触发器是数据驱动触发器的例子,而图10-14使用了组合触发器。

Google Millwheel

插曲

google millwheel 《MillWheel: Fault-Tolerant Stream Processing at Internet Scale》, 论文应该2012年就推出来了, 以前总是快速扫一遍, 每次阅读都有一些不同的收获, 这次终于仔细拜读一下, 顺便将它翻译了一遍。

设计目标

  • 提供一种编程模型,可以满足复杂的计算逻辑而无需使用者是分布式计算专家
    • framework能处理任何一条边或一个节点发生故障
    • 可以保证数据处理仅被处理一次, 采用冥等的方式
    • 用一种合适的粒度进行checkpoint, 从而可以避免外部sender 缓冲数据的buffer在多个checkpoint 之间长时间等待
  • 能够同时高效满足scalability和容错性
  • 按照论文描述, 可以支持多语言

个人总结:

这篇论文,大篇幅介绍的如何做容错和扩展性, 扩展性很多时候是依赖容错性来做系统伸缩。 整体而言,扩展性和容错性应该非常不错, 但成本比较高,因为对持久化层需求很大, 而且比较偏好mini-batch设计,非常倾向去做window的aggregate, 另外对这个系统时延,感觉会在秒级以上。微软scope streaming 感觉和这个系统有很大的相似性, 不过scope 比较强调确定性(determinacy)。
整个设计里面一些亮点:

  • 整个dag中,组件(compuation)之间是完全解耦, 因此,可以自由对一个computation做迁移,扩容,合并。不过,这些都依赖底层的exactly-once 框架。
  • 系统数据传输都是通过rpc, 而非消息中间件, 并且组件(computation)之间可以自由订阅, 这一点超越了samza和scope。
  • 数据结构是(key, bytes[], timestamp), 这个数据结构在后来的dataflow中发生了变化
    • key 非常重要, 目前是对key 做group by, 相同的key保证在一个进程中串行执行, 并且每个用户自己写key-extractor 函数。 并且后续的所有操作/context,都是基于对应的key, 比如checkpoint,状态更新, 发送/更新 timer/low wwatermark。
    • bytes[], 用户自己选择序列化和反序列化
    • timestamp 完全由用户来确定,
  • exactly-once
    • 当timer 来到时, 会做checkpoint, 这个checkpoint, 会在一个原子操作中, 把这次checkpoint的输入数据id 和输出数据 和状态更新, timer 全部更新到bigtable 中的一行, 如果有外部状态更新,用户需要自己保证冥等
    • 后台存储更新需要一个sequencer, 拥有了sequencer token后,才能做数据库更新操作, 保证一个key,永远只有一个single-writer。
    • 接收数据后,需要ack给发送方, 这样发送方可以做 input record id的清理工作。
    • 系统会对输入消息进行去重
  • low watermark
    • 通过一个外部全局系统injector来做lower watermark, 会订阅injector 来获取lower watermark。
    • 每个worker 从injector处获取输入源的low watermark,然后根据自己的工作状态,计算出自己的low watermark, 然后汇报给injector

台湾环岛自由行攻略

很早之前, 朋友就推荐过台湾, 称台湾绝对值得游玩一趟的, 于是,很早就把台湾通行证给办了。 而且, 台湾说的是国语, 英文不好的朋友,大可不必担心语言沟通问题。 另外, 台湾并没有网上说的,很歧视或排斥大陆游客, 我玩的时候,发现普遍讲话非常有礼貌,开口打扰了,闭口谢谢。另外,运气特别好的是,丈母娘她们报名的跟团游, 导游特别好, 没有强制购物,也没有强制玩景点时快速结束, 全程耐心等待游客, 而且经常扛箱子。 (可能因为第一导游是刚入行, 第二,行程是淡季,非十一或春节等)

总攻略

去台湾玩,选择哪些地点,怎么玩。 这里说一些我个人的小技巧,

  • 第一种办法,上途牛/携程/去哪儿, 挑一个时间和自己差不多跟团游, 看他玩了哪些地方, 然后,记下来。
  • 另外一个好办法,强烈推荐手机安装“梦想旅行”, 每到一个城市,它会告诉这个城市有哪些非常不错的景点, 你挑选几个,然后,他会给你安排一下行程。
台北有几个地方,值得推荐一下
  • 垦丁, 漂亮的地方特别多, 也有很多小孩玩的地方,比如 海洋生物馆, 尤其是夜宿海底隧道, 至少要提前半年预定, 绝对赞。
  • 花莲, 和垦丁类似
  • 日月潭, 类似千岛湖
  • 清境农场
  • 中台禅寺, 信佛的人,一定要去
  • 台北, 台北故宫博物馆,101, 夜市, 中正纪念堂。

台北如果玩的时间非常长的话,超过2周, 可以推荐环岛游, 如果不足2周,建议半岛游, 如果半岛游的话, 就没有必要到在一个地方往返。
最早安排的行程是 台北(1天)–> 清境(1天) –> 日月潭(1天) –> 高雄(1天) –> 垦丁(3天) –> 台北(2天), 但最后觉得需要在台北买不少东西, 台北需要放到最后, 最后行程安排是 台北(1天) –> 垦丁(3天) –> 高雄(1天) –> 日月潭(1天) –> 清境(1天) –> 台北(2天)。 这个时候才发现机票没有订好, 没有必要在订 杭州到 台北的往返, 完全可以 去程杭州 –> 高雄,返程台北–> 杭州, 这样就可以节省半天 从台北到高雄的时间,也节省了一张高铁票。

小谈跳槽

小谈 跳槽

最近看一个帖子《阿里70w vs IBM 40W》, 帖子里面充斥着阿里和IBM 各种出差补助的争吵, 实在无语, 忍不住,利用周末的时间,总结自己的想法, 抛砖引玉一下, 欢迎各位朋友一起探讨。
跳槽其实是一个非常大的话题,可以从梦想,从性格,从经历,从专业等各个维度长篇大论一番,另外每个人都有自己的经历,从而都有自己的解读, 没有哪一种是完全正确的,也没有哪一种是完全错误的,而我只能说,将我的理解表达出来,如果你有更多的想法,不妨也探讨一下。

zookeeper 扩容

背景

因为阿里经常进行机房断网演练, 如果一套zk 只能部署在一个机房时, 当发生断网时, 这套zk是无法为其他机房提供zk 服务, 因此需要将单机房zk 升级到多机房zk, 但因为zookeeper是强同步方式, 所有的请求会在内部进行同步, 如果机器之间延迟比较大时, zookeeper 问题会非常多, 因此,这套解决方案前提条件是同城多机房, 并且时延比较小。

这套解决方案也适合, zookeeper 升级扩容和zookeeper 机器替换

在多机房方案中, 常常是3机房, 这个时候,推荐221 的分布模式, 客户端多的机房多部署一台zookeeper

scala 概述

概述

scala 就是 将函数式编程和面向对象编程进行融合, 并加入静态类型语言的一种编程语言
是一种运行在jvm上的,可以无缝和java 结合的编程语言

投诉godaddy

原博客下面文章, 因为godaddy 删除了个人空间,导致5年的博文,毁于一旦,真是吐血三升, 很多美好的回忆,已付之东流。

强烈谴责godaddy, 没有任何责任感, 而且多次投诉godaddy无果。

如果有条件,还是建议在阿里云上购买虚拟机,自建网站

深度分析Twitter Heron

2015年6月1号, Twitter 对外宣讲了他们的Heron系统, 从ppt和论文中,看起来完爆storm。昨天,抽空把论文,仔细读了一遍, 把个人笔记和心得分享一下:

最后总结:

Heron更适合超大规模的机器, 超过1000台机器以上的集群。 在稳定性上有更优异的表现, 在性能上,表现一般甚至稍弱一些,在资源使用上,可以和其他编程框架共享集群资源,但topology级别会更浪费一些资源。

而从应用的角度,应用更偏向于大应用,小应用的话,会多一点点资源浪费, 对于大应用,debug-ability的重要性逐渐提升。 另外对于task的设计, task会走向更重更复杂, 而JStorm的task是向更小更轻量去走。

未来JStorm可以把自动降级策略引入, 通过实现阿里妈妈的ASM, debug-ability应该远超过storm, 不会逊色于Heron, 甚至更强。