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