实现过程–应用开发流程.ppt

谢 谢！ 利而不害，为而不争 利而不害，为而不争 利而不害，为而不争 利而不害，为而不争 利而不害，为而不争 利而不害，为而不争 利而不害，为而不争 基于DRS实现的应用开发 —案例分析 Leavay Software 传统应用开发流程 需求设计 测试 开发 上线 维护 应用开发流程 按照业务需求，根据经验积累的口径、模型知识等，编写设计文档 模型设计、应用设计文档分散在各个具体工单中 根据设计文档，进行脚本代码开发/修改（多采用文本编辑工具） 调测程序，验证数据质量 填写代码提交单 根据设计文档检查代码的实现情况 检查开发规范 运行程序，并进行数据质量验证 手工配置程序依赖、调度计划等 手工执行个性化脚本，如建表，更新维表等 通过调度工具监控/维护调度情况 在元数据系统配置元数据信息 在数据质量系统配置数据质量规则 存在问题 模型管理问题 需求设计依赖于人的经验和历史文档，模型的复用率低下，模型持续膨胀 设计采用文档编写方式，管理层对模型规范的要求无法作用于实际生产过程 开发管理问题 设计文档无法作用于具体开发，应用的质量无法保障 开发人员的水平高低不一，无法约束代码的规范性，代码的质量无法保障 维护管理问题 任务的调度手工配置，耗时且容易出错 基于任务流调度，只可以查看任务级的依赖关系，难以准确跟踪数据流向 数据质量问题 元数据事后补充，“两张皮”的问题无法解决 数据质量监控无法作用于数据处理过程，质量问题无法及时发现 项目管理问题 各类文档分散，不易追溯、检索 系统存在各种规范，如模型规范、开发规范、测试上线规范等，新人培训周期长，且效果不佳 问题分析 应用开发过程需要解决的问题 管理手段与技术实现脱节，依赖于开发人员的自觉性和事后的抽样检查 需求、设计、开发、上线各环节无法有效衔接，一致性无法保障 后台模型、数据处理过程黑盒化，看不清，管不了 Text in here 元数据、数据质量、数据处理相互独立，无法有效协作 采用由元数据驱动的开发管控框架，集成设计、开发、测试、运行、监控和管理等功能，将元数据、数据质量和数据处理三者融为一体，实现数据全程的可见、可管、可控。 解决 基于DRS的应用开发实现 DRS通过数据对象将元数据、数据质量和数据处理三者进行融合。 任何一个应用，都存在一个清晰可描述的数据流（也即是元数据血缘图），数据流中的每一个节点可以看作一个数据对象 数据对象包含属性和方法 属性 数据实体本身 业务描述/业务元数据 技术参数/技术元数据 方法 数据处理的具体内容 质量检查和控制 技术和管理规范控制 数据对象，实际生产环节（包括数据）的真实反映 数据对象流，实际生产数据流向的真实反映 基于DRS的应用开发实现 数据对象的功能包括：业务数据对象设计、技术数据对象开发和数据对象流调度。 业务数据对象设计 技术数据对象开发 数据对象流 调度 元模型 设计 元数据 填充 元数据 血缘分析图 数据质量 规则设计 数据质量 规则制定 数据质量 监控、告警、处理 数据处理 逻辑框架设计 数据处理 业务逻辑实现 数据处理 调度 数据质量： 质量规则预先设定，落实到系统的具体处理过程； 灵活的数据质量规则设置，具有独立性，不影响已有数据的运行； 中断式告警模式，规则出错可中断数据流，防止错误数据扩散。 元数据： 业务元数据，增强业务人员、技术人员对后台实现的理解； 技术元数据，落实到具体的数据处理过程，实现机读与人读的一致性； 业务、技术元数据统一管理，更好地保障两者的一致性。 数据处理： 用户自定义的、统一的处理框架，可灵活添加技术规范或管理规范； 基于数据处理框架的开发模式，开发只需要按模板填充业务相关的信息，技术细节由DRS统一保障； 更容易定位问题、解决问题、消除问题所造成的影响，实现数据处理重跑最小代价。 实现过程 – 应用开发框架设计 对应用开发涉及到的各层次进行模型定义，明确数据处理流向及各层次节点信息。 DW ST DIM ODS 需求设计 需求设计后，通过平台自动转换成应用流程 实现过程 – 应用开发框架实现 DRS采用自顶向下的开发模式，应用开发流程设计后，自动转换成技术实现模板。 技术实现模板分为两部分：属性填充和方法实现。 方法实现：由管理人员统一管理，主要进行数据处理逻辑实现，以及技术规范和管理规范的定义，支持随需变更。 属性填充：由开发人员填写，主要是元数据、数据质量规则的填写，作为数据处理运行的参数。 属性填充 方法实现 系统初期一次完成，多次复用 实现过程 – 规范落地 – 技术规范预定义 根据表类型操作模型 1、带日期事实表：删除重建； 2、多周期事实表：不删表，不建表，只清当前周期数据； 3、按周期更新事实表：1号建表，建表前检测表是否