什么是实践中,真正的大数据科学系统?

产生推荐

  实际上,有非常多的方法可以由数据驱动产生推荐。例如在所谓的“协同过滤”里,所有用户的行为都可以被收集起来作为推荐的基础,然后分析发现哪些商品有相似的用户行为模式。这种方法的优美之处在于计算机根本不用知道这些商品是什么。而它的缺点则是商品必须要有足够多的用户行为信息数据才能保证这个方法起作用。另外一类产生推荐的方法是只看商品的属性。例如,推荐具有相同品牌的或者相同颜色的商品。当然,对这些方法还有非常多的扩展或者组合。

  更简单一些的方法就是只通过计数来做推荐。但这种方法在实践里会有非常多的复杂的变形。例如,对个性化推荐,我们曾使用过“学习排序”的方法,即对商品集做个性化的排序。上图里所显示的就是这个方法需要最小化的损失函数。不过,这里画出这个图的主要目的还是来展示数据科学可能会引入的复杂度。

  将数据科学方法引入工业界

  为了把类似上图的非常复杂的数学算法引入到生产系统中,我们需要做什么?数据科学和软件工程之间的界面应该是什么样?什么样的组织架构和队伍结构才最适合使用这些数据科学的方法。这些都是非常相关和合理的问题。因为这些问题的答案将会决定对于一个数据科学家或者是整个数据科学团队的投资是否能最终得到回报。

  理解数据科学(系统)与生产系统的关系

  让我首先从了解数据科学系统与后端生产系统的关系开始,看看如果将两者进行集成。

  典型的数据科学工作流程(管道):第一步总是从发现问题和收集一些数据(来自于数据库或者生产系统的日志)开始。取决于机构的数据准备好的程度,这一步有可能就是很困难的。首先,你有可能需要搞清楚谁能让你接触到所需的数据,并搞清楚谁能给你权限去使用这个数据。

  上述的这个分析管道通常都是短期一次性的工作。一般是由数据科学家手工完成所有的步骤。数据科学家可能会用到如Python这样的编程语言,并包括很多的数据分析和可视化的库。取决于数据数量,有时候数据科学家也使用类似Spark和Hadoop这样的计算框架。但一般他们在一开始都只会使用整个数据集的一小部分来做分析。

  为什么开始只用一小部分数据

  开始只用一小部分数据的主要原因是:整个分析管道过程并不是一锤子买卖,而是非常多次反复迭代的过程。数据科学项目从本质上讲是探索性的,甚至在某种程度上是开放式的命题。虽然项目目标很清楚,但什么数据可用,或可用的数据是否适合分析,这些在项目一开始都不是很清楚。毕竟,选择机器学习作为方法就已经意味着不能仅仅只是通过写代码来解决问题。而是要诉诸于数据驱动的方法。

  这些特点都意味着上述的分析管道是迭代的,并需要有多次改进,尝试不同的特征、不同的预处理模式、不同的学习方法,甚至是重回起点并寻找和实验更多的数据来源。

  区分生产系统和数据科学系统

  生产系统和一个数据科学系统的最主要区别就是生产系统是一个实时地、在持续运行的系统。数据一定要被处理而模型必须是经常更新的。产生的事件也通常会被用来计算关键业务性能指标,比如点击率等。而模型则通常会每隔几个小时就被用新数据再进行训练,然后再导入生产系统中去服务于新来的数据。

  这些生产系统一般都是用如Java这样的编程语言写的,可以支持高性能和高可靠性。

  如果你把生产系统和数据科学系统并排放置,那么就会得到一个类似上图的情况。在右上角,是数据科学的部分。其典型特征是使用类似Python的语音或者是Spark的系统,但一般是一次性的手工触发的计算任务,并经过迭代来优化整个系统。它的产出就是一个模型,本质上就是一堆学习到的数字。这个模型随后被导入进生成系统。而生产系统则是一个典型的企业应用系统,用诸如Java语言写成的,并持续运行。

  当然,上面的这个图有一些简化了。现实中,模型都是需要被重新训练的,所以一些版本的数据处理管道会和生成系统集成在一起,以便不时地更新生产系统里的模型。

  请注意那个在生成系统里运行的A/B测试。它对应于数据科学一侧的评估部分。但这两部分经常并不完全具有可比性。例如不把离线的推荐结果展示给客户,就很难去模拟一个推荐的效果,但有这样做可能会带来性能的提升。

  最后,必须要意识到,这个系统并不是在安装部署完成后就“万事大吉了”。就如数据科学侧的人需要迭代多次来优化数据分析管道,整个实时系统也必须随着数据分布漂移来做迭代演进。由此新的数据分析任务就成为可能。对我而言,能正确做好这个“外部迭代”是对生产系统的最大的挑战,同时也是最重要的一步。

  数据科学家和程序员:合作的模式

  到目前为止,我们主要关注的是生产环境里的系统是什么样。当然对于如何保证生产系统稳定和高效则有很多种方法。有时候,直接部署Python写的模型就足够了,但生产系统和探索分析部分的分离是肯定存在的。

  你将会面对的艰巨挑战之一就是如何协调数据科学家与程序员的合作。“数据科学家”依然是一个新的角色,但他们所做的工作与典型的程序员有着明显差异。由此导致的误解和沟通障碍就不可避免了。

  数据科学家的工作通常是探索性的。数据科学项目一般始于一个模糊的目标、哪些数据可用的一些想法、以及可能的算法。但非常常见的情况是,数据科学家必须尝试多种想法,并从数据里获取洞察。数据科学家会写很多的代码,但是大部分都是用于测试想法,并不会被用于最终的解决方案。

  与数据科学家相反,程序员通常非常关注于编程。他们的目标是开发一个系统,实现所要求的功能。程序员有时会做一些探索性的工作,比如构建原型、验证概念或是测试性能基准。但他们的工作的主要目标还是写代码。

  他们间的不同还明显地体现在代码的变化上。程序员通常会坚持一个非常明确定义的代码开发流程。一般包括创建自己工作流的分支,在开发完成后做评测检查,然后把自己的分支合并进主分支。大家可以并行开发,但必须在协商后才能把他们的分支合并进主分支。然后这个过程再重复进行。这整个过程都是确保主分支会以一个有序的方式演进。

  数据科学家也会写很多的代码。但正如我之前所说的,这些代码通常是为了验证想法。所以数据科学家可能是会写出一个版本1,但它并没有实现需求。然后又针对一个新的想法写了版本2,随后是2.1和2.2,直到发现还是不能实现需求而停止。再对更新的想法去写版本3和3.1。也许在这个时候,数据科学家意识到,如果采用2.1版里的某些方法并结合3.1版里的某些方法,就能获得一个更好的解决方案。这就带来了版本3.3和3.4,并可能由此形成了最终解决方案。

  一个有意思的事情是,数据科学家实际上可能希望保留所有这些没成功的版本。因为之后的某个时间,也许它们又会被拿来测试新的想法。也许有些部分可以被放入一个“工具箱”里,逐步形成数据科学家自己的私人机器学习库。程序员更希望去删除“无用的代码”,而数据科学家则喜欢保留代码以防万一。

  上述的两大不同意味着,在现实中,直接让程序员和数据科学家共同工作可能会出问题。标准的软件工程流程对数据科学家的探索性工作模式并不合适,因为他们的目标是不同的。引入代码评测检查和有序的分支管理、评测、合并分支的工作流对数据科学家而言并不合适,还会减慢他们的工作。同样的,把探索性的模式引入生产系统开发也不会成功。

  为此,如何才能构建一个合作模式来保证两边都能高产出的工作?可能第一直觉就是让他们相互分离地工作。例如,完全分开代码库,并让数据科学家独立工作,产出需求文档,再由程序员团队实现。这种方法也行得通,但流程通常会非常得慢,且容易出错。因为重新开发实现一遍就可能会引入错误,尤其是在程序员并不熟悉数据分析算法的情况下。同时能否进行外部迭代来改进系统的表现也依赖于程序员是否有足够的能力来实现数据科学家的需求。

  例如,数据科学家和程序员的代码库依然是分离的,但部分生产系统会提供清晰定义的接口来方便数据科学家把他们的方法嵌入进系统。与这些生产系统的接口进行沟通的代码必须严格地依据软件开发实践流程,但这是数据科学家的工作。用这种方式,数据科学团队可以在自己的代码快速地迭代,同时也就是完成了对生产系统的迭代。

  这种架构模式的一个具体实现是采用“微服务”方法。即让生产系统去调用数据科学家团队开发的微服务来获取推荐。用这个方式,整个数据科学家使用的离线分析管道还可以被调整用来做A/B测试,甚至是加入生产系统而不用程序员团队重新开发实现。这种模式会要求数据科学家具有更多的软件工程技能,但我们看到越来越多的数据科学家已经具有这样的技能集。

  持续适应并改进

  至此,我概述了一个能把数据科学引入生产系统的架构的典型模式。需要理解的一个关键概念就是这样的系统需要持续地适应并改进。能够快速迭代,实验新的方法,使用A/B测试验证结果,这一切都非常重要。

  依据我的经验,保持数据科学家团队和程序员团队的分离是不可能达成这些目标的。与此同时,很重要的是我们也要承认他们两个团队的工作方式确实是不同的,因为他们的目标不一样。通过允许各自团队能工作在更适合他们的目标的方式,并定义一些清晰的接口,是有可能集成两个团队,并保证新的方法可以被快速地试错的。这会要求数据科学家团队具有更多的软件工程技能,或是至少能有软件工程师来桥接起两个世界。

原文发布于微信公众号 - BestSDK(bestsdk)

原文发表时间:2017-06-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

如何做好大数据产品设计架构和技术策略?

作者经过研发多个大数据产品,将自己形成关于大数据知识体系的干货分享出来,希望给大家能够快速建立起大数据产品的体系思路,让大家系统性学习和了解有关大数据的设计架构...

3308
来自专栏大数据挖掘DT机器学习

【解析】网站分析:关联推荐、交叉营销与向上营销

很多网站都具备了内容推荐的功能,不仅是像B2C电子商务类的卓越的图书推荐,也包括兴趣类网站像豆瓣的豆瓣猜等。这类功能无疑在帮助用户发现需求,促进商品购...

3744
来自专栏ATYUN订阅号

Tailor Brands推出了AI平台,可生成和安排社交媒体内容

Tailor Brands是一家利用AI帮助公司自动化营销和品牌元素的公司,该公司宣布推出一种新的基于AI的社交媒体管理工具,可自动创建,安排和优化内容,以便在...

891
来自专栏java一日一条

传统的程序员将会被淘汰

要成为当今软件开发中受人尊敬的专业人士,你需要掌握各种技能,而且达到高水平的专业级别。最起码,你需要能够把你的英语解决方案翻译成软件实现。不仅技术上要正确,在业...

1352
来自专栏靠谱PM

产品需求从哪些维度划分优先级

上一篇文章中说到由一个需求挖掘出更多的需求点,需求那么多不可能一下全都做的(开发资源有限),那么这个时候我们就要对需求进行优先级的排序,得出结论哪些需求优先做,...

2962
来自专栏CDA数据分析师

案例 | 客服中心优化案例数据分析

介绍:笔者写这篇文章主要是针对那些在案例解决方面缺乏自信的初学者,这将成为在面试中被拒的一个重要原因。如果你还在读这篇文章的话,笔者相信,你肯定已经做好了和我一...

2505
来自专栏WeTest质量开放平台团队的专栏

为测试赋能,腾讯WeTest探索手游AI自动化测试之路

做好自动化测试从来不件容易的事情,更何况是手游的自动化测试,相比传统的APP,手游画面纯OPENGL绘制无可识别控件,且界面动画多、随机性大。举个例子,拿新手引...

1175
来自专栏BestSDK

交互新趋势,如何设计语音交互?

一直以来,我们使用的是以视觉界面交互为主的3C产品。iPhone,Google Glass,Apple Watch,以及增强现实的Magic Leap, Mic...

4119
来自专栏互联网杂技

经验分享 | 如何更好地推动产品及交互需求顺利落地?

我很喜欢这样的一句话:“在做设计的时候,最大的阻力不是用户相关问题,而是内部的认知、利益点、看待事情方式的不一致。”;尤其是在推动产品及交互需求落地的过程中,感...

32611
来自专栏大数据挖掘DT机器学习

非常好的协同过滤知识讲解

“探索推荐引擎内部的秘密”系列将带领读者从浅入深的学习探索推荐引擎的机制,实现方法,其中还涉及一些基本的优化方法,例如聚类和分类的应用。同时在理论讲解的基础上...

3628

扫码关注云+社区

领取腾讯云代金券