IT分销/经销数据库
我理解的过程模型应是这样的
我所理解的过程模型，应该是一种数据模型，它辅助ETL完成很复杂的逻辑部分，而作为元数据的一部分而存在，从而使ETL程序开发简单化。
最近和一些同事聊天的时候，我就说，如果从OLTP系统开发想转到开发BI（当然也包括ETL），必须得有BI的思维。其中多角度的分析思维是一方面，另一方面就是多从“模型”着想，少从“编程”着想。因为OLTP是一个业务实现对应一套程序，对元数据管理要求不高，而BI由于太过于集成多变，所以适应多变、易管理是重点。
于是我问一个同事，如果客户需要用两个时间相减来判断是否合理，其中前一个时间需要和区间判断，取区间的后者，而在下午某个时间后，就算隔天的时间。如8:00-9:30是其中一个时间段，当前一个时间在这个区间，则取9:30，和后一个时间相减，如小于3小时则合理，否则不合理。同事说其实用程序也容易实现，现在开发工具那么丰富。那我再问，如果隔天的这个逻辑，需要判断是否工作日呢，程序如何处理？同事说，这当然程序无法判断了，系统咋知道中国哪些时间是假期，这还不算公司自己的特别日子。那好，请建一个模型，用模型实现这个逻辑，这个模型至少应包括这几个时间段，然后就是增加一个字段来辅助判断是否隔天，然后加一个表，粒度高到日期，且日期是有节假日标志的。这样只要事实表与这个模型关联就能轻松实现ETL，不管是使用工具还是SQL，就都容易实现了。更重要的是，用户要修改规则，我们让专门的维护人员维护ETL对应的过程模型即可，不需要动任何代码，以后别人要看逻辑，只看模型即可，同时方便SQL到工具开发的移植，好处太多了。
最近和一些同事聊天的时候，我就说，如果从OLTP系统开发想转到开发BI（当然也包括ETL），必须得有BI的思维。其中多角度的分析思维是一方面，另一方面就是多从“模型”着想，少从“编程”着想。因为OLTP是一个业务实现对应一套程序，对元数据管理要求不高，而BI由于太过于集成多变，所以适应多变、易管理是重点。
于是我问一个同事，如果客户需要用两个时间相减来判断是否合理，其中前一个时间需要和区间判断，取区间的后者，而在下午某个时间后，就算隔天的时间。如8:00-9:30是其中一个时间段，当前一个时间在这个区间，则取9:30，和后一个时间相减，如小于3小时则合理，否则不合理。同事说其实用程序也容易实现，现在开发工具那么丰富。那我再问，如果隔天的这个逻辑，需要判断是否工作日呢，程序如何处理？同事说，这当然程序无法判断了，系统咋知道中国哪些时间是假期，这还不算公司自己的特别日子。那好，请建一个模型，用模型实现这个逻辑，这个模型至少应包括这几个时间段，然后就是增加一个字段来辅助判断是否隔天，然后加一个表，粒度高到日期，且日期是有节假日标志的。这样只要事实表与这个模型关联就能轻松实现ETL，不管是使用工具还是SQL，就都容易实现了。更重要的是，用户要修改规则，我们让专门的维护人员维护ETL对应的过程模型即可，不需要动任何代码，以后别人要看逻辑，只看模型即可，同时方便SQL到工具开发的移植，好处太多了。
2同行回答
更加可操作的方法论应该是:
1. 绘制出每个主题的ETL流程控制模型,使用图形化文档解释每个主题的ETL到底需要哪些控制、不同工作流之间的调度关系、schedual、日志管理、如何发邮件/短信通知
2. 数据模型管理每个ETL各层级的思想，比如Informatica的workflow、session/tasks、mapping，例每个workflow想使用几条线并发运行，是否有控制task,是否有时间task等等。session的话，每个session是否partition、是否全量等等，每个mapping是控制的重点，因为开发的开发量大部分都在这里，每个mapping可将每个SQ的过滤条件全放模型里控制，每个mapping用到了哪些组件？还可以将update策略、Join组件关联策略、lookup策略等等信息集成到管理模型里。
这种ETL过程管理数据模型最大的好处就是大批量开发的时候可及时发现问题、可分析、可调用（比如SQ过滤条件全从过程模型里调用），经验丰富的人，一看分析数据，就可以大致判断出某ETLmapping是否范了较大的错误，当然细节问题是发现不了的，需要去看具体开发逻辑。
3. 复杂ETL过程模型，比如固定规律的数据刷新，需要先对某些数据清理掉，然后再汇总插入，就需要ETL过程模型辅助（如果刷新使用update else insert可能会非常慢）、复杂条件的生成，如1楼提到的时间判断模型，如果对多个复杂模型汇总的话，可以升级成为局部通用的ETL过程数据模型，ETL过程的精华将在模型里，你只需要关联模型即可，而非想尽办法写程序，最后弄得10个开发人员10个逻辑方式。
大规模开发的重点一直在于方便控制、方便查看思路、方便维护，即便是国际大团队，也能真正做到。我计划写一个完整的高可实现方案在我日益壮大的团队中实践，从自我开始跟随ETL过程模型开发，成熟的时候我想是可以推广的，不同的工具，只要修修改改一下即可使用，这套模型思路绝不能太依赖具体的工具而定。
过程模型同时也是ETL设计思想的实例化过程，绝不会为开发增加负担。
至于业务逻辑是否让业务人员定，可以将过程模型中具体的过滤数据、逻辑数据给出接口给相应的维护人员维护，其他属于技术数据，应技术团队管理。就目前元数据管理工具中的元数据来看，可能无法满足细节管理的需求，如果能满足需求，那么第二部分的工作可以省略掉，工具的数据可能更专业。收起
1. 绘制出每个主题的ETL流程控制模型,使用图形化文档解释每个主题的ETL到底需要哪些控制、不同工作流之间的调度关系、schedual、日志管理、如何发邮件/短信通知
2. 数据模型管理每个ETL各层级的思想，比如Informatica的workflow、session/tasks、mapping，例每个workflow想使用几条线并发运行，是否有控制task,是否有时间task等等。session的话，每个session是否partition、是否全量等等，每个mapping是控制的重点，因为开发的开发量大部分都在这里，每个mapping可将每个SQ的过滤条件全放模型里控制，每个mapping用到了哪些组件？还可以将update策略、Join组件关联策略、lookup策略等等信息集成到管理模型里。
这种ETL过程管理数据模型最大的好处就是大批量开发的时候可及时发现问题、可分析、可调用（比如SQ过滤条件全从过程模型里调用），经验丰富的人，一看分析数据，就可以大致判断出某ETLmapping是否范了较大的错误，当然细节问题是发现不了的，需要去看具体开发逻辑。
3. 复杂ETL过程模型，比如固定规律的数据刷新，需要先对某些数据清理掉，然后再汇总插入，就需要ETL过程模型辅助（如果刷新使用update else insert可能会非常慢）、复杂条件的生成，如1楼提到的时间判断模型，如果对多个复杂模型汇总的话，可以升级成为局部通用的ETL过程数据模型，ETL过程的精华将在模型里，你只需要关联模型即可，而非想尽办法写程序，最后弄得10个开发人员10个逻辑方式。
大规模开发的重点一直在于方便控制、方便查看思路、方便维护，即便是国际大团队，也能真正做到。我计划写一个完整的高可实现方案在我日益壮大的团队中实践，从自我开始跟随ETL过程模型开发，成熟的时候我想是可以推广的，不同的工具，只要修修改改一下即可使用，这套模型思路绝不能太依赖具体的工具而定。
过程模型同时也是ETL设计思想的实例化过程，绝不会为开发增加负担。
至于业务逻辑是否让业务人员定，可以将过程模型中具体的过滤数据、逻辑数据给出接口给相应的维护人员维护，其他属于技术数据，应技术团队管理。就目前元数据管理工具中的元数据来看，可能无法满足细节管理的需求，如果能满足需求，那么第二部分的工作可以省略掉，工具的数据可能更专业。收起
浏览484