不多说，直接上干货！
Kettle工具在设计初，就考虑到了一些设计原则。这些原则里借鉴了以前使用过的其他一些ETL工具积累下的经验和教训。
易于开发：作为数据仓库和ETL开发者，你只想把时间用在创建BI解决方案上。任何用于软件安装、配置的时间都是一种浪费。例如，为了创建数据库连接，很多和Kettle类似的Java工具都要求用户手工输人数据库驱动类名和JDBC URL连接串。尽管用户通过互联网都能搜索到这些信息，但这明显把用户的注意力转移到了技术方面而非业务方 而。Kettle尽量避免这类问题的发生。
避免自定义开发：一般来说，ETL工具要使简单的事情更简单，使复杂的事情成为可能。ETLT具提供了标准化的构建组件来实现ETL开发人员不断重复的需求。当然可以通过手工写Java代码或Java脚本来实现一些功能。但增加的每一行代码都给项目增加了复杂度和维护成本。所以尽量避免手工开发，尽量使用已提供组件的各种组合来完成任务。
所有功能都通过用户界面完成：对于这一黄金准则也有很少的几个例外（如kettle, properties和shared.xmr文件就是两个例外，不能通过界面，要手丁修改配置文件），如果不直接把所有功能通过界面的方式提供给用户，实际上就是在浪费开发人员的时间， 也是在浪费用户的时间。专家级的ETL元数据还要去学习隐藏在界面以外的一些特性。在Kettle里，ETL元数据可以通过XML格式表现，或通过资源库，或通过使用Java API。 无论ETL元数据是以哪种形式提供，都可以百分之百通过图形用户界面来编辑。
没有命名限制：ETL转换里有各种各样的名称，如数据库连接、转换、步骤、数据字段、作业等都要有一个名称。如果还要在命名时考虑到一些限制（如长度、选择的字符），就会给工作带来一定麻烦。ETL具需要足够的智能化来处理ETL开发人员设置 的各种名称。最终ETL解决方案应该吋以尽可能地描述，这样可以部分减少文档的需求，减少项目维护成本。
透明：如果有ETL工具需要你了解转换中某一部分工作是如何完成的，那么这个ETL工具就是不透明的。当然，如果想己实现ETL工具里某一个同样的功能，你就要确切地 知道这一部分功能是如何完成的。不过允许用户看到ETL过程中各部分的运行状态也是很重要的，这样可以加快开发速度、降低维护成本。ETL工作流程中的不同部分不能互相影响，它们应该只是以指定的顺序传递数据。这种 数据隔离的原则也在很大程度上影响了透明性，那些使用非数据隔离的ETLT具的用户 会感受到透明的益处。
灵活的数据通道：对ETL开发者来说，创造性极端重要，创造性不但让你享受到工作的乐趣，而且能让你以最快的方式开发出ETL方案。Kettle从设计初始就在数据的发送、 接收方式上尽可能灵活。Kettle可以在文本文件、关系数据库等不同目标之间复制和分发数据，从不同数据源合并数据也是内核引擎的一部分，也同样很简单。
只映射需要映射的字段：在一些ETL工具里经常可以看到数百行的输人和输出映射，对于维护人员来说这是一个舰梦。在ETL开发过程中，字段要经常变动，这样的大量映射也会增加维护成本。
Kettle的一个重要核心原则就是在ETL流程中所有未指定的字段都自动被传递到下一个组件。这个原则极大减少了维护成本。也就是说输人中的字段会ft动出现在输出中，除非中间过程特别设置了终止某个字段的传递。