0%

插曲

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
Read more »

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

总攻略

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

  • 第一种办法,上途牛/携程/去哪儿, 挑一个时间和自己差不多跟团游, 看他玩了哪些地方, 然后,记下来。
  • 另外一个好办法,强烈推荐手机安装“梦想旅行”, 每到一个城市,它会告诉这个城市有哪些非常不错的景点, 你挑选几个,然后,他会给你安排一下行程。

台北有几个地方,值得推荐一下

  • 垦丁, 漂亮的地方特别多, 也有很多小孩玩的地方,比如 海洋生物馆, 尤其是夜宿海底隧道, 至少要提前半年预定, 绝对赞。
  • 花莲, 和垦丁类似
  • 日月潭, 类似千岛湖
  • 清境农场
  • 中台禅寺, 信佛的人,一定要去
  • 台北, 台北故宫博物馆,101, 夜市, 中正纪念堂。

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

Read more »

小谈 跳槽

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

Read more »

背景

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

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

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

Read more »

概述

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

Read more »

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

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

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

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

最后总结:

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

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

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

Read more »