五个主要概念
- 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,无论这个Transformer是一个Web服务，直接面向用户，或者是一个类似中转的器的角色，譬如将Kafka里的数据消费然后填充到搜索系统里，他都导致了一个(或者多个)新的PipeLine的产生。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连接起来，从而满足新的需求。
