用机器学习流程去建模我们的平台架构

Spark 提供了一个新的体系,spark.ml。 相对于spark.mllib,这是一个更高层的对机器学习流程的一个抽象。然而,你会神奇的发现这套抽象,竟然也适合服务平台的设计与建模。更让我印象深刻的是,一个合适的抽象,简直就像真理一样。譬如RDD这种就是一个和神一般的抽象,它使得Spark成为了一个非常通用的平台,囊括了流式计算,离线计算,机器学习,图计算等多个领域。

spark.ml 在一开始就提出了五个概念。这五个概念也完全可以对一个通用的service platform进行建模和抽象。我们来看看。

五个主要概念

服务的本质是数据的流转。

  • Transformer。 我们的每一个服务节点,都是一个数据转换器。譬如你开发的一个Spark Streaming程序,一个Storm程序,一个Tomcat Web服务,都是一个Transformer。
  • Estimator 。支撑Tranformer运行的框架平台。他是解决一类问题的支撑平台。通常我们会有很多不同类型的Estimator,比如MR,比如Spark,比如Storm,比如Tomcat。他们分别解决各自领域的类的问题。比如Storm适合运行你开发的实时类的Transformer,MR则适合运行你开发的批量数据处理的Transformer,Tomat则适合支撑Web类的Transformer。
  • Parameter 。 每个Transformer都有自己的参数,每个Estimator有自己的参数。Parameter就是所有参数的集合。
  • Pipeline。 Pipeline 其实是由互通的Transformer构建起来的一段网状结构。每一个Transformer 以自己作为Root节点,都会向下延伸出一个树状节点。
  • DataFrame。数据框。各个Transformer之间交换数据的规范。Transformer 将一种DataFrame transform 成另一种DataFrame。

通用的建模

最终你会发现,我们的整个服务体系就是一个由Transformer,Pipeline构建起来的网状结构。如果我们跳出公司的视野,你会发现整个公司的网状服务体系只是全世界网络体系的一小部分。整个互联网是一张大网。这就说明,整个互联网其实也是可以通过上面五个概念进行涵盖。

我们部署服务到底是一件什么样的事情

你可能觉得这个问题会比较可笑。然而,如果之前我们提出的概念是正确或者合理的,让我们离真理更近了一步的话,那么它应该能够清晰的解释,我们部署或者下线一个服务,或者一个服务故障,到底是什么?

先说部署上线新服务,其实就是新建了一个Transformer,无论这个Transformer是一个Web服务,直接面向用户,或者是一个类似中转的器的角色,譬如将Kafka里的数据消费然后填充到搜索系统里,他都导致了一个(或者多个)新的PipeLine的产生。Transformer的作用是将数据连接了起来,并且将数据转化成一个我们需要的形态,如此而已。

下线或者服务故障则是类似的。

这个理论对我们来说有什么意义

答案是指导我们如何去思考问题。

我们不希望每次遇到一个新的业务问题,都需要根据自己的聪明才智,通过经验,得到一个解决方案。任何事情都是有迹可循的。正如吴文俊提出的机器证明,可以通过流程化的方式让计算机来证明几何问题。当面临一个新的业务问题的时候,我们应该有标准的流程可以走。

以构建一个搜索服务为例子。搜索本身是一个Transformer,他需要把数据transform成索引,当用户进行查询的时候,搜索会对索引的数据再次进行transform,返回给客户。也就是进行了两次大的transform。

下面是进行平台设计时我觉得比较合适的一个想法:

当设计一个平台的时候,我们只要关注Estimator就好,我们必须已经有大量的以及随时具备上线新的Estimator的能力。 之后面对实际的各种业务需求,应该由基于这些Estimator的Transformer去应对,构建Transformer主要考虑两点:

  • 需要将哪些原来没有Pipeline的的Tranformer连接起来
  • 如何对数据进行Transform

对于一个新的业务需求,如何进行考虑呢?

  1. 和哪些已有的Transformer 建立 Pipeline?
  2. DataFrame是否需要经过新的Transformer 转换,这个Pipeline才能正常工作?
  3. 如果有新的Transformer,如何选择合适的Estimator?

罗列已有的Transformer

搜索要获取数据,那么就是要新建一个Pipeline,也就是要和已经存在的一个Transformer(数据源)建立连接。所以现有的数据源(假设是Kafka)是我们已知的,并且要建立Pipeline的Transformer。

DataFrame是否需要经过新的Transformer 转换,这个Pipeline才能正常工作

经过调研我们发现,数据源的信息并不能直接被搜索给接受,所以一个新的Transformer IndexDataCollector就诞生了。通过IndexDataCollector我们可以把Kafka和搜索给关联起来。

如何选择合适的Estimator?

Estimator的概念的提出,就是希望我们的应用应该是不关心服务环境的,应该是往Estimator提交,就能让Transformer运行并且产生作用。所以我们优先推荐采用可以跑在Yarn/Mesos这种将服务器屏蔽的资源调度平台上的Estimator。

这里,IndexDataCollector 需要的Estimator 应该是Storm或者Spark Streaming。

采用这种类型Estimator的好处是,我们仅仅按规则(Estimator的接口规范)开发一个应用,提交给集群就能方便的将Kafka和搜索这两个原来不存在的Pipeline的Transformer连接起来,从而满足新的需求。

结束语

个人认为大部分业务需求都可以按如上的步骤去考虑。万物互通,一个好的抽象应该具有普适的价值。虽然原先这套理论是针对机器学习流程抽象出来的,但是你会发现它也适用于其他的问题。事实上,你会发现机器学习中处理的环节和要素和我们在做平台架构或者处理新的业务需求的过程是如此的相似。

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏挖掘大数据

Hadoop的正确打开方式

关于 Hadoop 所谓的消亡,以及它跌落神坛的报道数不胜数。有很多人放马后炮说,Hadoop 从一开始就没有意义。还有人说“Hadoop 对于小型,临时的工作...

24090
来自专栏钱塘大数据

【推荐阅读】系统性解读大数据处理框架

微信后台回复:“框架”,获取高清图片 前言 说起大数据处理,一切都起源于Google公司的经典论文:《MapReduce:Simplied Data Proce...

36880
来自专栏ATYUN订阅号

Cloudera宣布更新一系列机器学习产品,为数据团队提速

软件公司Cloudera今天在Strata Data伦敦会议上宣布了一系列机器学习产品更新:Cloudera Data Science Workbench 1....

13330
来自专栏恰童鞋骚年

Hadoop学习笔记系列文章导航

  这是一个信息爆炸的时代。经过数十年的积累,很多企业都聚集了大量的数据。这些数据也是企业的核心财富之一,怎样从累积的数据里寻找价值,变废为宝炼数成金成为当务之...

9220
来自专栏腾讯大数据的专栏

飞起来的大象-Hadoop从离线到在线

时代在变迁,市场在变化,周边的软硬件环境也突飞猛进般的发展,同时企业的业务需求也不断升级,从规模到成本都有较高的要求,这刺激Hadoop生态圈的变革。据AMR研...

29480
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(182)-作业成本要素与核算模型

作业成本核算模型是实施作业成本法(Activity-Based Costing)的基础,是对作业成本法核算体系的描述,因此作业成本核算模型在作业成本法的实施过程...

30570
来自专栏风火数据

教你如何成为Spark大数据高手

Spark目前被越来越多的企业使用,和Hadoop一样,Spark也是以作业的形式向集群提交任务,那么如何成为Spark大数据高手?下面就来个深度教程。

13810
来自专栏钱塘大数据

Spark与Hadoop两大技术趋势解析

导读: 开源数据集如今深受开发者喜爱,比如谷歌的Images dataset数据集,YouTube-8M数据集等。通过对数据集里的数据进行分析,可以发现许多隐...

38640
来自专栏人工智能头条

3位Committer,12场国内外技术实践,2016中国Spark技术峰会议题详解

23550
来自专栏about云

Hadoop是从Lucene中独立出来的子项目--Hadoop产生背景

问题导读 我们在学习一项新知识,可能不太关注它的产生背景,但是任何故事如果脱离了它的时代,就不会在有意义。如果想了解Hadoop,我们需要知道 1.它是如何产生...

31680

扫码关注云+社区

领取腾讯云代金券