我们使用Kettle在实际项目应用中，会遇到一些kettle不方便处理的问题，比如想要定时调度执行某个任务时，kettle自带的定时功能肯定是不能满足要求了，它需要界面一直处在打开状态，会占用大量的资源，并且界面有崩溃的风险。当然也有替代方案，就是使用操作系统的计划任务，不管是windows还是linux系统都提供了这样稳定的调度系统。如果你是专业人员和运维，当然是没有问题，写一个bat或shell调用kettle，再配一个计划任务，windows还好，linux还需要了解一下crontab的语法。一般的业务用户是很难具备这样的能力的。

　　Kettle在消费一些消息队列的场景时，低版本是一次性消费，即开始执行消费后，当没有消息时就停止了。在kettle8新改进了消费者为监听模式，可以一直监听队列，有消息就开始消费，但也必须保持kettle界面打开，问题跟上调度差不多，大家不可能一直开着kettle，这个方案也不适合真实场景。
　　另外当kettle与业务系统相结合使用时，我们很希望kettle能发布出一个服务，外部系统通过这个服务来调用kettle，执行转换或任务，还能监控kettle的运行过程，并记录执行的日志，如果执行失败了，可以查看日志，再重新执行。这些功能kettle本身是不具备，当然可以使用pentaho server结合自己写程序是可以实现的，这也正是OMI研发的初衷。OMI加了上面的一些功能，运行环境还是kettle的内核。下面我们分几个章节分别介绍一下OMI是怎么处理这场景的。

　　OMI在项目中的定位
　　OMI在项目中主要是与内外部系统进行数据交互，并对数据进行，跑批、清洗、归档等加工处理。在交互中适配多种协议，SOAP、REST、JDBC、FILE、MQ等等。支持多种大数据交互，hive、mongonDB、redis等等。