• Feeds

  • 从硅谷之谜看工程师价值

    上文为什么我认为架构师需要坚持写代码发出后,看到一个朋友在网上分享了他最近的变化,经过深思熟虑,这位朋友已经离职放弃了原来舒适但是不太需要技术驱动的位置,去重新寻找让自己更有激情、能更好体现技术价值的环境及平台。

    最近阅读的《硅谷之谜》中,吴军也将工程师分成五个等级

    第五等工程师 独立完成任务
    第四等工程师 领导产品
    第三等工程师 行业最优
    第二等工程师 改变世界
    第一等工程师 开创行业

    这跟上文提到的架构师的分类方法比较类似。第五等工程师是指能够独立完成功能模块的人,第四等需要具有产品的意识以及能够带领及组织公司资源完成某项产品的开发。第五等和第四等其实都任务导向型。而更高的几种类型则需要善用技术及平台的力量。

    第三等工程师可以做出行业最好的产品,吴军讲到这类人与第二类的差异是这一类人需要“悟性”,当然也需要后天因素,比如处于一个上升平台的舞台上。

    即使一个人再聪明,基础再好,也需要在工程上花足够的时间才能达到这个水平,一个年轻人工作四五年就开始做行政管理工作,基本就和这个水平无缘了。

    第二等及第一等则是能充分利用技术力量改变世界的人,吴军更多的是从产品及结果导向来看归类这两类人,比如 iPhone 总设计师、爱迪生等人。

    硅谷的介绍虽然过度开采,但在工程师眼里却一直充满着永久的好奇与热情。每年都有大量技术从业人员去硅谷游学研修,了解地球另外一边的一群人,是通过怎么样的组织方式,利用技术创新来改变世界。

    因此可以通过吴军在《硅谷之谜》中的角度,来了解硅谷的工程师是如何样通过技术来体现自己的价值。

    在另外一些内容介绍硅谷公司对于工程师代码的要求,也多次提到代码能力的重要性。一些具有较好业界名气、或者具备丰富经验的人员,进入一些知名互联网公司之前也需要测试基本的代码能力,而如果不能通过的话则无法通过面试。

    在硅谷的公司里,从录取开始就显示出对权威和经验的一种淡漠。在 Google,不管面试者名气多大,水平多高,过不了一关关的面试也是白搭。对于那些技术负责人职位的申请者,不论申请者年龄多大,过去的经验多么丰富,一定要考技术问题,甚至包括写程序。因此,一个有名气有经验的申请者,未必比那些大学刚毕业的人更容易被录用。我曾经遇到这样一个例子,一个在美国顶级计算机系工作的教授,先推荐了他的两个学生来 Google 应聘,结果都录用了。后来他自己来应聘,Google 要他做他的学生做过的类似的考题,他反而没有考过,虽然我们很为他感到可惜,但是也没有办法。这位教授很不服气,对我讲,我的学生远不如我你们却要了,我发表过那么多论文,拿到过那么多基金你们却不要,说明你们的眼光有问题。我承认他讲的很有道理,但是,不能为一个人坏了规矩。类似的情况在 Facebook 也发生过,某公司的一位工程总监手底下的好几个人都被 Facebook 录用了,等到他自己去,因为编程荒疏,反而被拒绝了。

    另外一些正向的例子也提到一些行业泰斗坚持工作在技术一线。

    在硅谷你总是能看到一些世界科技行业的泰斗或巨头还在写程序。Google 的狄恩(Jeff Dean)和戈玛瓦特(Sanjay Ghemawat)是世界上最早发明云计算技术的工程师,也都是美国工程院院士,至今仍在自己写代码,而且每次有什么新的想法,都是自己先实现自己的狗食(Dogfood)。Google 的汤普森是 Unix 的发明人,图灵奖的获得者,每天大部分时间仍然花在写程序上。太阳工作站的发明人,该公司的创始人贝托谢姆,后来成为了天使投资人,又投资成立了上市公司 Arista,今天仍然在写程序。这些人可算是功成名就,要是放在中国,早就当官去了,至少也进入了到“君子动口不动手”的状态,但是他们在硅谷依然自己动手。虽然他们自己写的代码未必比别人好多少,但是这在硅谷营造了自己动手的工程师文化。

    在硅谷之谜中,多次提到硅谷影响最大的红杉资本。12 月 5 日,在中国企业领袖年会上,红杉资本全球执行合伙人沈南鹏就创新创业的下一站——科技创新主题发表了类似观点。

    “全球性”公司必须有一个重要的特征,产品上一定是科技的创新,而不仅仅是模式的创新。我们相信在今天新一代的创业者,很多有国际化的视野,也有国际化的工作经验包括科技研发的经验,他们一定会引领中国下一个风口,这样的创业创新一定会产生一批有全球竞争力的优秀企业。

    为什么我认为架构师需要坚持写代码?

    最近在高可用架构群、EGO会员群等多个场合,大家都在讨论架构师的能力的问题,架构师应该具备哪些能力?在面试时如何合适的评估一个架构师的能力?

    架构师的两种类型

    第一种是可以将业务实现的人,他可能需要整合公司不同部门的资源、解决不同技术模块整合、解决不同版本之间的兼容性、解决各个模块的技术选型等,解决任务的分解及分配,解决进度上出现的问题。当上面所有这些问题都完成后,架构师顺利帮助公司完成了项目目标。

    第二种是在第一种的基础上,利用技术的力量,改进了一个领域的效率或提升了生产力。比如一个在现有技术基础上提升20%效率的视频解码模块、或者类似美剧硅谷中的,研发出一套压缩比很大且保持高质量信息的压缩算法。目前的大部分互联网创新在某种程度也是利用技术变革的力量,比如电子商务及在线教育等行业。

    如果从输出结果的角度来看,架构师有两种类型,具备技术杠杆能力的和不具备杠杆能力的架构师。并不否认第一种架构师在战略执行层面的作用,他们是各个软件开发团队的中坚力量。但从影响力的角度,其归根结底是在一个画好的表格里面填东西,他从事领域的最终的格局是由市场、运营或者产品主导。而一种是真正具备杠杆能力的工程师或者架构师,他可以利用技术的力量,在填写一个格子的同时,利用技术的力量,将格子的功效放大,影响十倍或者百倍以上的结果。比如在音乐播放软件中,推荐算法的应用彻底改变了用户播放音乐的习惯与体验。

    很多人所说的架构师的设计能力,大多也可以归纳到第一种情况。很多所谓的架构设计,就是拿着多年一成不变的分层模式往业务上套,把业务按照功能规划成软件模块填写到架构图,并且把上下游的调用串起来。这种设计的大多时候是起给客户或者领导展示的作用。程序员代码的整体构思,大多可以通过白板上或者白纸以及程序员直接的沟通很敏捷的完成,大多不需要一个专职画图纸的架构师来指导。

    第一种架构师是可以不写代码的,因为他大部分所做的事情是跟人打交道、分配任务以及解决开发过程中各种进度问题。因此很多技术负责人面试时候看重协调能力等非真正的技术能力。而那些服务甲方项目型的公司,更是特别看重人际关系、沟通能力、展示能力等跟客户打交道的能力。另外一些软件版本历史包袱重的企业,则看重架构师的打补丁能力。由于功能型及偏执型型的团队偏多,因此在很大程度上造成了架构师的能力标准的偏离,在一些讨论的场合,过份看重项目执行中的个别技巧型能力,比如项目管理、人际关系等能力常常还占据了主流的声音。

    但这类架构师只能勉强称为“技术架构师”,因为大部分时候,他做的事情是填格子,而无法做到利用技术的力量,把一个格子放大到10个格子及更多。在另外一方面,这些不写代码进而慢慢丧失代码能力的“架构师”,也不太可能利用技术的力量去做发挥技术杠杆的事情。当然技术架构师也可以驱动工程师去完成一个技术型的大项目,大型的项目也需要合理的组织,但并不意味不写代码的人就比写代码的人做得更好。而那些对技术体系有深入了解及一线体验的架构师,比那些只跟人员管理打交道的人,更有机会利用技术的力量促进变革。

    因此如果希望一个架构师有令人满意的技术驱动能力,他应该具备代码能力,对技术有直接的了解及体验,进而能够精通如何利用技术来改变未来生产力。

    如何面试及评估架构师的能力

    Tim 的面试方法是,候选人需要第一步通过电脑上完成一个小型的代码实现,在代码基本符合要求的情况下,才会获得所有面试官可以接受的一个能力起点。如果不做这一点,面试时候,面试官需要费尽心思去问对方项目上更多细节问题,才可能了解一个候选人真正的开发能力。而通过考试,则可以在验证候选人具备一定开发能力的基础上,愉快的聊一些其他轻松的话题。

    在EGO会员讨论时候,一部分创业公司技术负责人担心一些资深的候选人不能接受这种方式,国内这种现象确实也不少见。但换个角度来想,创业公司大多还在起跑阶段,需要的肯定是从事大量一线开发的人。如果面试通不过机考编程,或者是不愿意做题,这种候选人也未必能完全适合创业公司需要。而那些不愿意做一线事情的架构师即使进来,他大部分时候在分派任务或者强化流程,可能让公司的技术层级及开发环节变多、管理成本变高进而导致整体研发效率下降。

    面试时候大家也认可的一些验证架构师能力的方法,比如把当前技术开发中遇到的一些典型性技术场景让对方来提出实现方案,以便评估对方是否具备应对类似场景的能力。在入职之后,可以让新的架构师独立承担及完成一些任务,以便考察对方是否具备独立的架构实现能力。

    Pinterest的Feed架构与算法

    Pinterest首页的Feed消息流,最早是按照用户的关注对象的Pin(类似微博)聚合后按时间进行排序(自然序,类似朋友圈),后来版本的feed系统放弃了自然序,而是根据一定规则及算法来设计,内部称之为Smart feed,其算法及架构根据其公开资料整理如下,值得业界做信息流产品的技术架构师参考。

    Pinterest每个用户的首页feed都是个性化内容。Pinterest系统大约1/3流量都指向feed页面,因此它是整个系统最关键的页面之一。当工程师开发新版Smart Feed时,如何达到99.99%可用性也是衡量项目是否成功的指标之一。

    Pinterest smart feed的主要算法及规则如下

    • 不同来发表来源的Pin按照不同的频次聚合。
    • 将Pin按照算法及权重有选择的去除(或延迟加载),质量较低的发表来源不必每次显示全部,系统可以有选择的决定哪些立即出现,哪些延迟显示。Pin的质量都是从当前接收用户的角度来衡量。
    • Pin排序的逻辑是最好的优先,而不是最新的优先。一些发表来源的Pin可能最新的优先,但另外一些发表来源的可能新的Pin优先级低。

    Pinterest Feed如图所示主要由以下几部分构成,最左边是数据来源,最右边是用户看到的Pinterest瀑布流。中间的三个服务介绍如下。
    pinterest-1

    Feed worker

    Feed worker职责:接收新的pin并根据接收的用户的不同赋予pin权重并保存。同一个Pin,不同的接收用户有不同的权重打分。
    新的pin主要有三个来源:关注用户,相关内容,关注关系的感兴趣内容。Worker会给每个来源的pin打分之后插入到一个pool里面,每个Pool是针对单个用户的优先队列(Priority Queue,即优先级高的内容先出)。
    由于Feed Worker按照接收用户的维度存储,因此所有的pin进入worker时候已经按照关注关系进行分发(即行内通常说的Feed推模式)。

    Feed content generator

    Feed content generator负责返回用户上次访问后新的pin。Content Generator可以返回前n条或者全部新的pin,用户获取过(即浏览过)的pin会从pool中删除。Content Generator可以将多个发表源的pin按照一定规则重新排列,但是不能改变原来的Priority Queue返回的优先顺序。即队列中高优先级的会被优先取出。

    Smart feed service

    物化视图用于保存用户上次feed列表的快照。此服务不需要对feed的重新排序,它将上次返回给用户的pin按照当时的顺序完整保存,由于它属于用户已阅读过的历史列表,读写较少,因此它可以提供更好的可用性。另外由于可以限制历史列表的长度,存储空间可控,因此可以更低成本来增加从库来提高访问的可用性。

    Feed依赖content generator来提供新的Pin,如果content generator不可用,服务可以优雅的降级,用户仍然可以获取历史的列表,返回物化存储的结果。

    Pinterest通过以上3个不同的服务,实现了对feed返回内容灵活的控制,每个服务都有自己明确的职责,达到了每个用户都具备个性化返回内容的目标。

    Feed存储

    Pinterest的feed存储需要解决以下几个需求:

    • 写入新发表的feed,由于Pinterest采用的是推模式,这个场景需要面临需要高的写入QPS,但用户能容忍一定的写入延迟。
    • 获取首页的物化feed列表,相对与写入的QPS要小很多,但是用户对请求的延迟容忍度低。
    • 删除feed。

    可以采用简单的设计方法,比如将所有的feed写入到一个存储,可以简单实现访问、更新及删除功能。在Pinterest当前的访问规模有上百T的数据以及每秒百万访问操作。经过综合评估,选择使用HBase来实现了上述需求,Pinterest业务场景需要提供非常高的读写及更新操作,HBase同时提供较高的读写及更新访问性能。

    用户发表一个新的Pin时,将Pin分发给他所有的粉丝,他的粉丝可能被shard到所有的HBase region上,因此一个分发操作可能要访问到多个region,并锁定每个region的WAL日志,然后进行更新再解锁。每次的write/delete/update操作锁定WAL非常低效,而且很快成为系统的瓶颈。更好的方法是将HBase的操作批量进行,并且可以加大HBase的吞吐能力,但另外一方面增加了访问的时延latency,如果是面向用户请求的操作,访问时延增大是不能接受的。

    为了满足不同的需求,Pinterest设计使用了双HBase集群的方法,将数据在不同的阶段写入到不同的HBase集群的方法,请参考图示。
    pinterest-3
    Zen是一个在HBase基础上提供图(Graph)存储的服务。
    SmartFeed Worker将用户发表的内容分发后通过Zen保存在HBase中,异步处理任务通过PinLater服务来调用。
    SmartFeed ContentGenerator负责返回最新的Pin,并进行评分及排序。
    当用户刷新请求自己首页的feed时,SmartFeed服务从Content Generator和物化存储的HBase归并数据返回给用户,如果生成服务请求超时,则系统仍然可以返回物化存储的数据给用户。在后台,SmartFeed将物化存储的数据从左边的存储删除。
    在实际的场景中,物化存储HBase的数据远远要比发表池的数据要少,这样请求的速度会非常快。

    Feed的高可用

    使用上述设计后,系统的可用性相当于物化存储HBase的可用性。HBase集群目前存在GC卡顿的风险,还有单点故障region迁移等问题,因此使用单一的HBase集群,可用性很难保证99.99%以上。

    为了解决这个问题,在另外一个EC2可用区启用一个备用集群,任何写入到主集群的数据将会在数百毫秒内同步到另外一个集群上。当主集群不可用时,可以从备用集群返回用户请求的数据。通过上述设计,整个系统的可用性达到99.99%以上(不包括写)。

    pinterest-2

    参考资料

    http://pingineering.tumblr.com/post/105293275179/building-a-scalable-and-available-home-feed
    https://engineering.pinterest.com/blog/building-scalable-and-available-home-feed