公司动态

秒速飞艇投注:工程师要不要写ETL?——

2018-07-09 admin

  秒速飞艇彩票在很多互联网公司的算法相关部门(例如搜索、推荐、广告)里,都有“做算法的”和“做工程的”两个工种。这个看似天经地义的分工方式是否就是最优的方式?这似乎还是存在一些争议的。

  这篇文章阐述了一种当前较为普遍合作模式下的问题,译者觉得说得很在点上。更宝贵的是,作者同时也提出了一种可能会更好的合作模式,能够解决这些问题。

  需要提前说明的一点,文中的“数据科学家”可理解为我们常说的偏算法的工程师,而文中的“工程师”或者“数据工程师”可理解为我们常说的偏工程或者偏架构的工程师。

  “你的团队和数据科学家们[1]之间的关系是怎样的”?毫无疑问,这是我作为面试官,面试数据平台工程师[2]时最常被问到的一个问题。这在面试过程中是一个很正常的问题,属于求职者评估新机会的必要流程。而我也经常很乐于回答这个问题。但是我希望我不需要回答,因为这个问题的背后,折射出的是怀疑和恐惧。

  为什么呢?如果你阅读一下硅谷科技公司里数据科学与算法开发部门的招聘启事,你或许会相信数据科学家和工程师之间的关系是高度协作、有机并且富有创造性的。

  但是,行业里的真实情况却并非如此。大多数场景下,这两者的关系其实是介于“不存在”[3]和“高度功能失调”之间的。

  数据科学家:这些家伙就是那些“工程比统计学家好&统计比工程师好”的人。也就是所谓的“思考者”。

  数据工程师:这些人构建数据通道,秒速飞艇投注:工程师要不要写ETL?——教你构建高效的算法数据科学部门将数据“喂”到数据科学家“嘴里”,然后从数据科学家手里拿到idea并且实现它们。也就是所谓的“执行者”(Doer)。

  架构工程师:这些人维护Hadoop集群以及其他大数据平台架构。也就是所谓的“水管工”[4]。

  数据科学家们经常不爽的是,工程师们实现算法的速度太慢,以及他们之间的工作流程,路线图以及动机总是同步不到位。当他们想法的版本1进入ABTest的时候,版本2和版本3早就已经排好队了。他们的失望和不爽是非常可以理解的。

  数据工程师们经常不爽的是,数据科学家们给出的代码总是效率低下,代码丑陋,几乎从不考虑可维护性和工程化问题,而且会提出一些不现实的功能需求,结果是破坏了工程实现方案,但也没有得到什么好处。这种问题继续下去还有很多,但是相信你已经懂了问题在哪里。

  而架构工程师们对他们都不爽,因为他们总是将集群上塞满任务,将硬盘里塞满数据。而且他们常常与数据科学家和工程师们都离得比较远,这意味着他们从来不知道集群是在什么场景下被如何使用的,也不知道集群被用来解决什么业务或技术问题。这让他们在很难摆脱当前不爽的境地。所以,他们的应对方法就是对集群做更严格的限制,这样做的结果,就是其他人都开始对他们感到不爽。

  我们都知道这样做是不对的,那我们为什么不解决这样的问题呢?为什么每个数据科学和算法开发部门似乎都会滑落到这样“功能失调”的模型中?

  数据处理的工具和技术在过去五年间发生了巨大的进步。除非你要处理几个P级别的数据,或者每天需要消费千亿级的事件,那么大多数技术现在都可以轻松扩容到你所需要的规模。

  除非你有试探这些技术的极限的需求,你或许并不需要一只高度专业的专业工程师团队来在其基础上构建解决方案。如果你雇佣了这些人,他们会感到无聊。如果他们感到无聊,他们就会离你而去,去到他们的专业技能更能发挥作用的地方,例如Google,Facebook等等。如果他们不感到无聊,那么他们的技能很可能非常平庸。平庸的工程师最擅长的事情,就是构建巨大无比、过于复杂、难以使用的垃圾,然后称之为“解决方案”。而垃圾往往需要更多的维护工作。

  因为这听起来更酷!你可以整天坐在那里,思考做事情更好的方式,然后把你的思考结果甩给那些急于将它们工程化的工程师们。大街上每个人都会喜欢这个职位的!数据科学家们,尤其是那些刚刚工作、对行业了解不多的,对这样的职位尤其喜欢。

  这些都是我们引导的结果,而一些大公司更要为此负责,尤其是那些在大数据疯狂之前就已经有了数据智能部门的公司。