开发工具在主流市场逐步取代手工编码,最大的原因就是方便了ETL管理,包括代码管理和元数据管理,使客户更好地使项目能延续下去,企业在长远的投资中
实现回报最大化。不过工具仅仅能管理代码和元数据,但代码和元数据是死的,他们不能适应客户的各种需求变化,而且太多方法可以提供开发者去实现,没法规
范,这也是厂家希望的,厂家希望自己的产品什么功能都能提供,至于怎么用,他只是从纯技术角度建议。
于是要适应用户无休止地需求变化,那么维护者就需要不断修改代码。虽然大多数开发已经开始注意“硬编码”,但参数、变量只能解决极少数需求变化问题,而
更多的目的是方便代码管理。于是适应用户的变化的根本办法,应是建立一个规则管理体系,然后逐步管理起来,ETL调用这个“管理体系”,达到最大限度的
扩展性。
从常见的ETL规则来看,可分为三大类,一是条件,过滤条件、主题分类条件等;二是维度,维定义的变化、维层级的变化,企业业务变化常造成此变化;三是
指标的变化,用户经常会对自己定义的指标不满意,而修改定义、指标的公式。
我想标准的价值就在于2点,一是开发的更加规范,二是维护成本降低,客户可以自由地发挥自己的分析想象空间,维护人员也不用再因为变化而烦恼,而且规则
的变化记录也可以记录下来。(现代DW模型只能达到记录业务数据的变化记录,而不是ETL规则的变化),又在新的层面达到DW项目管理新的高度。
个人觉得DW发展到当前现在,已经普遍重视元数据管理,数据开始跟踪历史变化,而产生变化维模型和ETL设计,不过仍然没能解决用户需求变化问题,或者
用户需求不确定的问题。
于是我在想,应该有一种方法,能管理经常变化的元数据,是用风险最小、最快捷地处理经常变化的元数据,避免修改代码。所以我在前面谈到常见的变化或需求
不确定有:条件、维、指标。于是我们可以在处理条件、维、指标的ETL过程时候,将其规则不放入代码,而是关联关联模型,来得出同样的逻辑。对于不确
定、变化的需求,这个时候技术并不再是附属,而是实际处理项目问题的根本方法。
就拿指标来举例,指标是用户自定义的统计口径,就算KPI,同一行业的不同企业的具体定义或计算公式都可能不同。指标的计算常见的有三种情况,一是度量
字段的算术算法得出,如单价*货品数量*折率=实际销售额;二是同一个度量,不同条件统计得出,如财务的科目A+科目B=X费;三是自定义属性统计度量
得出,如 高速同比增长期销售额,首先计算出哪些天/周的同比算是高速同比增长,然后反过来对该段时间的记录,加入一个标志位,然后=单价*货品数量*
折率*N(如果是该阶段,就为1,否则为0)。
那么当客户要变化他们的需求时(可能因为分析需要,也可能基础业务有变化,还可能是当时需求没确定好),我们可以考虑如何不修改代码,或尽少可能修改代
码,来实现客户的变化需求。
同理,对于条件变化、维属性/层级关系的变化,也可以从类似角度考虑。
总之,目前DW需求升级和维护阶段的高成本,都是因为元数据变化的管理跟不上造成。我原来也参加过特大型的项目,常见的情况,就是新到一个需求,哪怕增
加一个大的指标定义,也得动用很大功夫修改全部相关表的ETL、再来集成测试、回归测试,还有较大风险(影响原有ETL的风险)。个人觉得前期如果有好
的方案或者标准的话,事情应该变得更简单,也不需要那么多人力维护和升级。
为什么我也说是价值所在,因为可以提高整个项目的性价比,DW的开发和管理并非没有性价比提升的空间了。
元数据管理的时代到来,该朝元数据变化管理的时代前进了。