《刻意练习》读后感



《刻意练习》

鲁肃推荐的一本书, 非常有意思,值得推荐。

成功都是靠大量不断提升的训练, 而刻意练习就是有针对性的训练。
在2000年, 英国科学家 对伦敦的出租车司机进行观察,出租车司机需要每天记住地图和所有标志性的建筑,用核磁共振观察16位出租车司机和普通50位男性相比,储存记忆的海马体要明显大很多。另外,对79名刚参加出租车考试的司机进行观察,在刚开始考试时, 大家的海马体在一个水平线上, 几年后, 79名中的41名仍然是出租车司机,另外38名中途放弃了, 结果这41名出租车司机的海马体要明显大于非出租车的38名非司机。

《乔布斯传》读后感



乔布斯传,很早以前就看到人手一册, 但看到外界对乔布斯的点评就如同媒体点评马老师一样, 众彩纷纭, 最近因为机缘巧合, 被人要求阅读一下乔布斯传, 就把乔布斯传,拿过来读了一番, 读完之后,有很多不同的感悟,挑2个和大家探讨一下。
第一个印象就是 唯有偏执才能成功,做什么事情都有自己的想法和见地, 甚至对很多事情到了偏执的程度, 年少的乔布斯就放荡不羁,想到了什么就会坚信不疑, 对精神世界的探索, 对素食主义的偏好, 对极简主义的信奉,所幸这些偏执大部分都是善意的, 但在中国, 有句古语叫, 兼听则明, 偏听则暗, 个人观点, 天才往往是超凡脱俗, 天才往往总是坚持自己内心深处的追求, 总是引领世界, 将世界引向自己的方向, 如果非天才级的人物, 最终还是会走向“三个臭皮匠抵得上一个诸葛亮”,依赖群体智慧, 群体的智慧往往是最稳定,大部分时候都是正确的。
营销大师,这个世界上, 有2种事情是最难的, 第一就是从别人的口袋里把钱掏过来, 第二个,就是把自己的思想灌输到别人的大脑中。 乔布斯是一位世界级的营销大师。 乔布斯,最开始也不是总是灌输自己的idea到别人的脑中, 但从印度之行回来后, 就开始开挂的人生, 总是在不停的说服其他人按照自己想法,当还是一家小公司时,在做每次展览的时候,就深谙如何抓住眼球 而且他总是和很多营销大师进行交流, 因此他的营销技巧在不断的完善, 另外,他对营销的追求, 远远是高于其他人一个量级, 因此,当苹果的广告出来时,总是给人耳目一新。 营销已经不仅仅对苹果的产品产生深远影响, 同样带来了一个 “乔布斯磁场”, 当乔布斯出现时,大家最后总是在不知不觉中和乔布斯的观点一致。

最后,一千个读者就会有一千个哈姆雷特, 相信大家每次阅读乔布斯,都会有不同的感悟 。

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 结合的编程语言