用机器学习流程去建模我们的平台架构
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
对于一个新的业务需求，如何进行考虑呢？
- 和哪些已有的Transformer 建立 Pipeline?
- DataFrame是否需要经过新的Transformer 转换，这个Pipeline才能正常工作？
- 如果有新的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连接起来，从而满足新的需求。
结束语
个人认为大部分业务需求都可以按如上的步骤去考虑。万物互通，一个好的抽象应该具有普适的价值。虽然原先这套理论是针对机器学习流程抽象出来的，但是你会发现它也适用于其他的问题。事实上，你会发现机器学习中处理的环节和要素和我们在做平台架构或者处理新的业务需求的过程是如此的相似。