淘宝大数据产品解析之搜索应用平台nimitz介绍

尼米兹（Nimitz）英文原意是航空母舰的意思。在dump中心，是由道凡发起的一个项目，目标是希望nimitz能成为各个搜索小应用提供一个综合平台，可以快速部署各种中小型的搜索引擎服务，可以快速对接淘宝的各个业务库，快速开发海量数据数据的离线处理程序，BUILD索引，方便运维，高可用性。

解析：nimitz显然不是淘宝的搜索引擎，是为外部开发者提供的统一索引创建平台，降低与淘宝对接的开发成本。

在没有nimitz之前：开发成本很大很大。以前，每个应用都各自维护者自己的一套dump程序，开发成本非常之高，主要是dump程序，以及里面的逻辑处理。本来各个应用之间区别就在于各个字段的处理不一样，但是每一个应用，用户都会面临的问题就是数据库连接，取数据，以及相关的异常处理，要是遇到了mysql的分库分布，是要用普通循环串行处理呢，还是并发dump，并发dump是放在同一个数据结构呢，还是放在分别的数据结构，这都是开发者需要解决的问题，但是往往，其实用户不需要关系这些，仅仅需要关注业务逻辑。用户需要被从这里面拯救出来，于是，nimitz出现了。

解析：之前淘宝对外提供的接口，都是开发者自己实现数据库的连接，表关联，同时牵扯到淘宝数据库分库分表的问题，实现还是比较复杂的！

后来，我们发现这么多的小应用里面包含了很多重复的工作。于是我们想做一个综合平台，对源数据进入引擎的各个环节进行统一调度，屏蔽掉对用户来说没有必要的部分（比如数据库到hbase）的同步。

Nimitz主要包含了三大部分，Dump&Bulkload，App，DataPush:

1，Dump&Bulkload：这里面完成了两个主要工作：a，利用streamingDump从数据库拉数据，这里我们不再关心数据库是mysql还是oracle，也不关心mysql单库单表还是分库分表，只要一个简单的配置，我们就能得到一个成千上万行的text裸表，字段间用配置的分隔符分开，这样，就算出现数据库变更，我们也能通过简单的配置，更改数据源。即使最近出现去O，我们也不需要多少开发工作，直接简单配置一下，就将应用依赖的数据，从之前的oracle迁移到了mysql。b，将dump出来的裸表导入到hbase，我们会为每个表建立一个hbase表与之对应，字段也也是以kv形式存在于hbase中的一个qulifier（列族），默认这个qulifier与表名一致，如果用户需要可以将多个数据库表的数据导入到同一个hbase表中（key相同），这样做明显好出就是，只用一次查询就可以完成多个表的join操作。实际上，用户所面对的都是存在于hbase中的一行行的数据，完全不用关心背后数据库是mysql还是oracle。这里面还有一个非常cool的功能，就是用户直接对字段的重命名。什么意思呢，也就是说，数据库发生迁移的过程中，即使字段名发生了变化，我们通过在sql语句中增加as将字段重命名，这样就可以保持hbase中的字段不变化，这样就屏蔽了字段变化对用户业务逻辑的影响。一句话：Dump在hbase中维护中数据库的一个友好镜像！

解析：这里关键点是加入了hbase，基于nosql特性，起到了化繁为简的作用，

首先之前的表join，现在通过hbase的字段动态添加就很容易实现了；

其次之前的分库分表问题通过读取数据库流很简单的屏蔽了这个问题，具体的读取数据流操作很简单，大家能在网上找到大把的开源产品；

数据库表与hbase表字段对应通过配置文件来进行对应。

缺点：这里注意需要说明一下，一是配置文件的维护量牵扯到字段的修改还是比较大的，所以配置文件如果能够动态管理起来还是必要的，读取数据库流数据解决了；

再一个流程序存在单点故障的问题，如何很好地监控并且程序自动修复，数据自动恢复实现也是一个需要关注点。

 2，APP：其实这部分是用户完成的主要工作，是用户的业务逻辑所在。我们提供给用户一个app的模板，用户根据这个模板进行简单的修改，就能完成自己的业务逻辑。这里我们提供了一个选项，是用户的业务逻辑可以依赖主搜的字段，如果用户引擎是基于淘宝宝贝的，那么他完全就可以依赖主搜数据，加上自己的个性化字段，去掉不需要的字段。用户再web前端配置输出路径。我们会在DataPush模块中，完成将数据推送到引擎，并且建立索引，并完成引擎切换。这里面其实也包括两块，一块是全量，一块是增量。如果用户对数据更新不敏感，甚至可以不用完成增量。我们的nimitz会一轮轮的调度每个app的增量，频率跟用户配置的相关。每完成一论增量，nimitz会在zookeeper上面打上这一轮增量的时间戳，这样下一次启动增量的时候，开始时间就从这里开始。后来我们发现，用户其实只关心每个doc的生成，而各个doc之间的关系并不关系，因此，我们计划下一步会将App部分做成一个框架，把从hbase中取数据也封装起来，将一个doc封装成一个HashMap提供给用户，用户只需要编写plugin，完成对这个HashMap中原始数据的业务逻辑处理，放到指定的另一个map，这样用户所面对的，就仅仅只一个doc是怎么生成的，彻底解放用户的开发成本。一句话：App是应用业务逻辑所在！

解析：这里是实现对用户的app，没啥好说的，配置生成doc，并制定不同索引的更新频率

3，DataPush：DataPush将会完成从hadoop上面拉取数据，然后推送到引擎的机器上。如果是全量数据，就调度总控机器上的build脚本，完成索引简历，索引推送，索引切换；如果是增量，就直接将增量推送到引起机器的update目录下，引擎便会每隔一段时间（可配置），扫描这个目录，然后将其build到增量的索引。整个部分由nimitz完成，用户只要告诉nimitz，你的引擎机器在哪，你的增量频率多少，剩下的，都交给nimitz搞定吧！一句话：DataPush负责将xml推送给引擎。

解析：这里是比较有一个比较有意思的区别设计，就是全亮索引、增量索引区别对待，这么设计很明显是基于技术架构考虑

全量索引牵扯到主备索引库切换的情况，因为全量索引时是非常消耗系统性能的，查询操作基本不可用,需要切换到备库，等到全量索引完成再切换回来

增量索引只是增量更新就ok了。这么设计是基于搜索引擎本身设计息息相关的。

nimitz还提供给用户一些很适用的tool，例如：

1. ConfigPush：nimitz会根据用户在web界面的配置，自动生成一套能运行的isearch（其他引擎也可，这需要我们的一些开发工作），比如area名，机器地址，引擎机器，merge机器地址，自动根据我们写好的引擎运维脚本模板，生成一套适用于应用的运维脚本，这里，用户只需要在我们的帮助下完成引擎配置文件(se.conf)的编写。
2. 其他

看看从用户想搭一个引擎，到一个引擎正常运行，用户做了什么。

1. 用户根据代表数据库的一个原始数据的一个hashMap，生成一个最终要数据的hashmap。
2. 用户编写了在我们的帮助下编写了索引配置文件se.conf。

目前nimitz还不能支撑所有的应用， 但是基本上80%的应用都可以通过nimitz完成，而这80%的应用，将仅仅需要不到20%的开发运维成本。

nimitz，为减少搜索应用开发运维成本而生！