数据仓库开发的灵活与规范之间

innovate511

众所周知，管理软件的实施都较为复杂，不过开发则不然，大多数都有产品化软件。数据仓库系统是唯一没有完全产品化的管理软件(如ERP的SAP、CRM的Siebel等)，而数据仓库的ETL工具、BI前端展现工具、OLAP工具、挖掘工具等，都是开发平台，并非管理软件。

就做DWBI多年的感受而言，最主要的原因，就是数据仓库开发，开发随着需求的不同，同一个行业的差异也会很大。并且开发途径太过于灵活，规范太零散，所以其整体开发也无法产品化。

那么有没有折中的方案呢？我想未来应该是有的，但需要我们创新、归纳。大家知道工具厂商会出来所谓的开发规范，不过都是针对具体的某个组件功能，那么某个ETL或者展现实现的方法可以使用功能A，但也可以使用B，或者C+D组件的组合来实现。于是呼，开发出来的用来实现定制化需求还行，但无法复制、甚至无法长远地管理，这也是很多项目重新再来的原因之一。

所以现在有两条路需要走，需要创新、规范。一是基于ETL本身的规范，和工具无关的规范，如增量抽取及之后的加载汇总、日志管理、监控管理、还有最近有人转帖的“过程模型”，其实几年前老外在项目中就有详细的“过程模型”系统，用来管理ETL的过程，以及过程变化。不过最近才听说学术界那叫“过程模型”，难道学术界在人家用了好些年才出来总结术语？

还有就是基于结合前面提到的规范，以及ETL工具的开发规范，这个和具体工具和开发语言有关系。但如果象厂商那样根据不同组件来规范，那也没法玩，所以最现实的办法，还是创新新的规范，基于ETL模块化的新规范，比如模块1是实现增量抽取，二是实现增量加载、汇总，三是实现变化维，四是实现某变化规则的汇总，依次类推。这样的规范在开发中才能体现真正的规范性，团队开发不会一会使用组件A，一会使用B+C组件实现同一个功能。

如果开发规范很细到模块化，是不是就不灵活了呢？我想不会，因为如果当规范模板不能满足ETL需求的时候，自然会有新的模板来归纳这种需求应该怎么处理更好。如果随着技术的发展或管理方法的发展，模板可以更优化，那么模板也是可以有变化的，这就不会限制我们的创新思想，但却对大规模开发的规范有了扎实的基础。

至于规范管理，那么前面提到的“过程模型”就尤其重要，因为只有少数较为固定的变化需求可以用参数、变量来实现，大多数灵活、复杂的ETL规则需要通过过程模型来管理，而无须去经常修改代码。“过程模型”的出现目的，就是当初ETL规则由于客户的需求变化过于频繁或者太多东西在第一次开发可以用“硬编码”来快速实现，但现代编码中，很忌讳硬编码，特别是大量硬编码，一定时间后就无法管理了。于是通过一些有规则、有层次的模型，来管理这些ETL规则定义，就出现了，而且不断丰富，成为DW中的一个重要架构支撑点。

所以DW的开发趋势，那就是灵活体现在技术实现、模型代替代码实现，而技术实现的最佳方案、最佳规则管理模型的规范，是制约一个项目不能太灵活，以至于无法管理和维护，以达到平衡，和长期的开发维护、BI知识积累！！！

hero--008

开发规范很细到模块化，是不是就不灵活了呢？我想不会，因为如果当规范模板不能满足ETL需求的时候，自然会有新的模板来归纳这种需求应该怎么处理更好。如果随着技术的发展或管理方法的发展，模板可以更优化，那么模板也是可以有变化的，这就不会限制我们的创新思想，但却对大规模开发的规范有了扎实的基础。
细化到基元