数据仓库建设项目实施方案建议书.doc

株洲南车时代电气股份有限公司 数据仓库建设规划项目 方案建议书 XX 软件系统股份有限公司 2015 年 03 月 目 录 第 1 章 南车电气数据仓库建设项目介绍 3 1 1 南车电气数据仓库建设项目的背景 3 1 2 南车电气环境现状及需求分析 4 1 2 1 项目目标 4 第 2 章 南车电气数据仓库建设解决方案详述 6 2 1 南车电气数据仓库建设整体方案说明 6 2 1 1 方案概述 6 2 1 2 系统逻辑架构 7 2 1 3 系统硬件架构建议方案 8 2 1 4 未来建设目标 9 2 2 南车时代电气数据仓库平台建设 13 2 2 1 数据仓库建设原则 13 2 2 2 数据仓库规范体系设计 14 2 2 3 BW 数据仓库结构定义 17 2 2 4 数据仓库管理标准及命名规范 20 2 3 南车时代电气 BW 数据仓库优化方案 31 2 4 数据展现层迁移方案 32 2 5 主数据共享平台方案 33 第 3 章 南车电气数据仓库建设项目实施方案 35 3 1 南车电气数据仓库系统实施计划 35 3 1 1 工作时间表 预计 35 3 2 培训计划 39 3 2 1 培训类型 40 3 2 2 培训课程 40 3 3 容灾备份方案 42 3 3 1 备份策略的定义 43 3 3 2 备份窗口的选择 43 3 3 3 灾难恢复的策略 43 第 4 章 项目实施和管理提升方法 46 4 1 项目实施和管理提升方法 46 4 2 XX 在南车电气项目中提供的管理提升和服务内容 46 4 3 XX 管理提升与 BI 实施相结合的指导原则 47 4 4 XX 管理提升与 BI 实施相结合的方法和步骤 48 4 4 1 现状调研和企业问题诊断 48 4 4 2 未来业务流程和管理提升初步讨论 48 4 4 3 建立 BI 原型系统 49 4 4 4 结合 BI 进行未来业务流程和管理提升详细讨论和蓝图确认 49 4 4 5 管理提升交付成果实例 49 第 5 章 项目管理和质量保证 51 5 1 工作计划管理 51 5 2 沟通管理 51 5 3 争议协调升级程序 52 5 4 项目质量控制 52 5 5 文档管理 54 5 6 建议南车电气提供的保障措施 55 5 7 验收标准及方案 56 5 7 1 系统符合性 56 5 7 2 系统质量 56 5 7 3 交付文档 57 第 1 章 南车电气数据仓库建设项目介绍 1 1 南车电气数据仓库建设项目的背景 南车时代电气始终坚持核心技术向相关产业延伸的发展战略 不断巩固在轨道交通领 域的行业地位 着力提升在电气传动和控制系统领域的专业地位 正树立起公司在电气传 动和控制系统领域国际化专业供应商的新形象 为挖掘信息化系统价值 提升内部管理手段 公司于 2010 2011 年启动并初步建立 了南车时代电气综合分析系统 该系统采用了 SAP BW 和 EP 的技术平台 实现了部分经 营指标及报表需求 且于 2014 年从 V7 0 升级到 V7 4 版本 为优化各类应用系统间的借 口 提高系统的安全性和可维护性 公司于 2014 年启动了 ESB 技术平台的预研工作 确 立了以普元公司的 Primeton ESB 为技术平台建设公司的数据总线 部分系统间接口已经 实现与 ESB 的集成 1 2 南车电气环境现状及需求分析 公司为实现基于企业绩效管理的信息化系列重大需求 准备通过本项目做好数据仓库 技术平台的规划及优化提升工作 确保数据仓库平台满足全面启动建设企业绩效管理系统 的要求 本项目的工作任务包括数据仓库的建设规划 数据仓库的技术规范及性能优化 数据仓库与 BO EP 的集成应用 数据仓库与 ESB 集成实现重要主数据的信息共享等四个 方面 公司为实现企业绩效管理信息化的重大需求 籍由本项目做好数据仓库平台建设的规 划 搭建起商务智能体系的整体技术架构并实现部分实例应用 满足全面启动企业绩效管 理信息化的技术要求 同时 提出规范和优化提升既有的 SAP BW 数据仓库系统 使之成 为企业商务智能平台中运行良好的关键一环 为了解决本公司现有重要数据分布管理 交叉共享 无法保障数据及时性和准确性的 弊端 公司拟将 SAP BW 建设成为未来的数据集成与共享中心 能够满足建设公司 ESB 平 台的数据服务要求 实现重要主数据的归集与共享 提升数据交互性能和系统安全性 实现 BW 系统的规划与优化 搭建并应用 BW EP BO 的技术平台 建立重要主数据 的集中存储机制 与 ESB 集成实现与试点目标系统主数据的同步 前瞻性 既体现在 BW 软硬件平台规划和建设思路上要考虑未来五年的发展需求 也 体现在 BW 的 ETL 部署 处理连 聚集 模型等数据仓库要素的设计规范上 1 2 1 项目目标 本期项目定位为规划奠基阶段 需要全面系统的构建南车电气未来企业核心数据仓库 的基础架构 该基础架构要具有完整性 能满足本期项目的需求 同时也要具有灵活性和 可拓展性 能够满足未来企业发展而不断变化的需求 综上所述我们对于本次项目目标概括如下 1 以 BW 作为数据仓库建设进行未来的整体规划 使之覆盖 5 年内 含 2015 企业 级中心数据仓库的技术框架 业务对象设计等需求 且至少满足未来 2 3 年内南车 电气核心数据仓库的具体使用情况 满足其建设标准及管理标准 提高可读性 可 扩展性 可维护性 规划内容包括数据整合 ETL 层 数据服务层 数据展现 应 用 层的软硬件技术平台和服务内容 制定数据仓库的设计规范 2 优化 SAP BW 的软硬件环境 规范 BW 数据仓库的技术架构 对象设计和管理方式 重新梳理及构建原 BW 系统中设计不合理的部分 比如 CUBE Query 等 提升 BW 的操作性能 优化 Query 等待时间 使之具备满足当前作为企业级中心数据仓 库服务的条件 涉及的相关 CUBE 主要有总帐行项目 应收 应付 成本 采购 库存 销售 考核指标等 3 部署 SAP BO 集成 EP 作为新的数据展现 应用 层 将当前 BW 中的部分报表展 现重构 以 BO 在原 BW CUBE 的基础上重新开发 形成 SAP BW BO EP 的商务 智能技术平台结构 完成重要历史报表的迁移工作 4 构建主数据共享平台 扩展数据仓库实现重要主数据归集和储存的业务应用 目前 有物料 客户 供应商 人员 岗位 组织机构 制造 BOM 订单 BOM 七类核心 业务系统中的主数据需要汇集到 BW 数据仓库 通过 ETL 手段完成 SAP 和非 SAP 系统的主数据抽取并且在 BW 中建模 最终实现将数据仓库作为 ESB 中核心业务系 统重要主数据的存储与共享中心 提供相关主数据的接口以供 ESB 系统调用 以此 实现重要主数据的跨平台同步 第 2 章 南车电气数据仓库建设解决方案详述 2 1 南车电气数据仓库建设整体方案说明 2 1 1 方案概述 本期项目的专业定位是集团企业级核心数据仓库的建设 数据仓库架构的优化及规范 体系的建立 XX 软件系统有限公司以 ROI 投资回报 为目标 以科技为手段 为南车电气 未来的公司绩效管控和决策支持服务构建强壮的基础 XX 公司通过结合中国本地的人力资 源和地利之先 综合国内外的先进管理思想和应用实践 愿为南车电气的事业锦上添花 针对上一章节中我们所理解归纳的南车电气本期项目的需求 本期项目是南车电气信 息系统建设的核心部分 整合后的数据仓库将作为将来南车电气整个 IT 环境中的数据基础 平台 建设完成后将为未来的南车电气企业绩效管理信息化系统做准备 数据仓库系统的 建设有其顺序性 且需要大量时间 数据仓库系统建设过程中 将发现原有的营运系统在 作业流程 数据质量 数据标准化的问题 基于此发现 将有助于对营运系统的缺陷进行 修复 BI 系统的建设是循序渐进不断完善的 是跟业务一起发展的 基于上述想法 数据仓 库项目的实施 当一期建设完成后 二期 三期将建设更为详细的企业各系统数据模型 增加新的源数据系统 扩展和完善数据主题域 新建更多主题数据集市 涵盖整个南车电 气的业务范围 以 SAP BW 数据仓库平台为基础 构建未来企业级中心数据仓库 通过 SAP BO 平 台重新进行报表前端展现层的开发 最后通过 EP 平台发布 形成 SAP BW BO EP 的商 务智能技术平台结构 2 1 2 系统逻辑架构 系统逻辑架构示意图 源系统说明 本次项目的主要数据来源为 SAP 系统和非 SAP 系统 数据处理层 数据抽取层的目的是实现将数据源的数据经过抽取 转换后加载到数据管理层中 同 时在这个过程中 需要进行任务的调度控制 任务出错处理以及数据质量的检查 南车电 气的项目数据主要通过 BW 中的 ETL 技术手段来实现抽取和汇总 1 SAP 数据源通过 BW 标准的数据抽取方式 2 非 SAP 系统建立数据库连接数据源 oracle 同时考虑增量抽取机制 数据管理层 数据管理层以业务需求为驱动 根据业务不同的主题 建立多个主题模型 建模以维 度建模方法论为指导 结合实际需求 考虑模型的灵活性 扩展性以及性能 为前端展现 提供一致 高效的数据 报表平台层 报表平台采用业界最为优秀的 SAP BO 产品 可实现固定格式报表 动态报表 移动展现 等多种报表 报表展现层 前端展现 SAP EP 门户集成 BO 报表来实现 2 1 3 系统硬件架构建议方案 本次项目至少需要有两套环境 开发环境和生产环境 从逻辑上 两套环境必须分开 权限上必须进行区分 每套环境配置相同数量的服务器 安装相同的操作系统和应用软件 保证环境的一致性 开发的资源配置可低于生产环境 由于未来 BW 将作为南车核心数据仓库使用 众多核心的业务系统中的数据都需要抽 取到 BW 数据库中 我们调研了一部分业务系统的数据总量及增量如下表所示 系统名称 当前数据量 月增量数据 SAP ERP 2 1T 40 50G SAP CRM 115 77G 3 4G PLM 710G 25 30G 供应商门户 电气加国变 52 3G 约 0 8G 供应商门户 风电 19 5G 约 0 1G 供应商门户 电动 39 6G 约 40M 费用管理系统 35G 1G 1 5G 投资管理系统 46G 预算系统 5 88G 0 1G 上述系统只是部分核心业务系统 其当前的数据总量为 3 个多 T 未来 5 年的数据增量 保守估计为 6 10 个 T 而 BW 系统的数据基本上为源系统数据量的 1 5 2 倍 也就是说 在数据仓库服务器的存储设备上至少要准备 20T 以上才能满足未来 5 年内的业务需求 目前南车 BW 生产环境的数据库服务器存储空间较小 才不到 2 个 T 而且已经使用 了 80 左右 所以我们建议在服务器存储空间上需要有较大的配置增加 服务器种类 VCPU 虚拟 CPU 内存 硬盘空间 性能问题简述 BW 开发服务器 应用 数据库 4 20G C 50G D 1500G 操作响应慢 EP 开发服务器 4 20G C 80G D 300G 操作响应慢 BW 生产服务器 12 30G C 100G D 300G 数据查询等待时间长 BW 生产数据库服务器 12 30G C 100G D 1800G D 400G 数据查询等待时间长 EP 生产服务器 12 30G C 100G D 1800G D 400G 数据查询等待时间长 由上表中我们可以看到几乎每一台服务器都有不同程度的性能问题 但光看配置感觉 在 CPU 和内存上并没有太大问题 所以我们的做法是在项目启动之后 将会派遣资深的 SAP BASIS 顾问对于相关系统的内存使用率 CPU 使用情况 服务器资源分配是否合理 等等情况进行评估 找准产生性能问题的原因之后 我们再进行相关的 BW 软硬件配置调 整 2 1 4 未来建设目标 第一阶段目标 1 数据获取 将所有源系统数据通过 ETL 工具和 BW 数据抽取汇总到数据仓库 搭建 智慧采集平台以录入的方式对业务系统中无法抽取的指标数据进行统一上报 使其 汇总到数据仓库的接口表中存放 重大任务 重点工作的进度 数据调整也将通过 智慧采集平台来调整并保存到数据仓库之中 2 指标管理 进行指标管理系统的初步建设 该系统主要功能为设置指标阀值 指标 权重 指标字典 梳理指标归口关系 是一个管理维护整个指标体系的强大系统 由于涉及的功能较为复杂 我们会逐步完善充实该系统 本期的目标是该系统的初 步建设 主要开发指标阀值 指标权重维护功能 3 指标展现 我们在 XX 智慧决策平台上实现多个事业部和产业板块的绩效数据汇总 和 BSC 指标展现 同时还包括财务 运营 人事等方面的主题分析 主要内容为 各类日常使用报表 管理驾驶舱以及绩效考核重大任务 阶段性成果 这一阶段的工作重点是 XX 智慧采集平台 XX 智慧决策平台的建立以及 这两个平台同南车时代电气原有的企业级数据仓库 报表平台相整合 同时做好数据仓库 的数据梳理工作 当第一阶段顺利完成之后 将会形成一套完整的绩效管理系统和面向事 业部及集团的 BI 系统 届时所有相关绩效考核的数据都可以顺利的进入数据仓库中 并进 行正确的合并汇总 同时 对集团和事业部 BI 用户实现严格的权限划分 使不同管辖权限 的用户看到不同的数据 为今后系统建设及扩展打下坚实基础 第二阶段目标 1 深化主题 对一期已经开发的主题分析 绩效指标进行更深入分析和展现 指标的 监控及考核从一期的二级对象深入到三级对象中 各个 BCS 战略层面的进一步深 化 2 提升指标管理 完善指标管理系统的功能 在第二阶段中指标字典 指标归口关系 设定等功能将陆续开发 最终使得整个指标管理平台可以完全满足整个系统指标管 理维护的需要 使得未来的开发维护成本大大降低 3 完善 BI 平台建设 将一期已经得到的成果结合平衡计分卡的理念 将企业四个维度 财务成果 内部管理 市场与客户 学习与发展 的关键指标进行多角度探索分 析 同时从一期的指标展现提升为数据分析 多维分析 预测分析等商务智能的王 牌分析全面展开 为高层决策层与知识型管理者提供科学的决策依据 阶段性成果 在这一阶段中 主要是对一期已经建设完成的较为全面的绩效管理系统 的全面深化 包括预测分析 多维分析 各个主题分析的深入和系统功能的完善 在第一 阶段 我们看到的是绩效指标的展现 监控 现在我们将可以根据更全面的数据定义各个 单位个性化的指标 领导可以从指标的分析 预测 深入了解到每一个环节的问题 了解 问题的原因 从好更好的帮助管理层了解如何让企业运作的更好 考虑到未来可能有的系 统扩展和 SAP ERP 故障 XX 智慧采集平台依旧在整个架构中扮演重要的角色 但是手工 上报数据和自动上报数据将通过数据标签严格区分 以便事业部和集团清楚数据来源 第三阶段 随着数据仓库中越来越丰富的数据 南车电气已经完全具备了大数据分析 的能力 此时可以引入先进的数据分析软件 如 SAS 等为集团 BI 系统进行更多的挖掘和 分析 届时将实现一些高级别数据分析的需求和结果 例如 我们可以从风机运行时各部件传感器传回的大量秒级数据之中分析得到为什么 这个型号的风机故障率会高 故障主要集中在哪几个点 当出现怎么样的数据参数波动时 风机的哪个部件有可能将会出问题 从而做到设备的故障预测 减少设备的非计划性停机 维护 增加客户的经济效益 提升客户的满意度 同时 随着技术的发展和实时数据及性能的需求 可以把原先的数据仓库替换成 HANA 产品 HANA 强大的数据处理能力和系统实时性数据的展现可以通过关键指标体系 展示企业实时的运营状态 将采集到的数据形象化 直观化 具体化 时效化 让管理层 随时可以观察到企业的运转状态 即使得到分析预测结果来辅助自己的决策 为战略层和 管理层提供 一站式 的决策支持 在这个阶段中 我们要更强化 BI 系统数据仓库架构 通过从业务系统抽取更多的明细数据以使集团 BI 系统可以分析到凭证级粒度 在这个基础 之上我们可以为各个产业板块开发定制化的 DataMart 这一阶段工作重点将会是如何做 好 HANA 平台的替换以及如何运用数据分析软件做到 BI 系统的全面预测 深入的数据分 析及多元化的报表展现 最终成果 南车时代电气 BI 系统通过整合各个事业部 分子公司 产业板块业务数据 将集团各层级管理人员关心的业务指标以驾驶舱 分析报表等形式通过 XX 智慧决策平台 的个性化展现 BI 战略管理层通过这个平台可以一目了然地看清企业全貌和业务全貌 让 企业管理者从各个方面多个个维度来了解自己的企业 为集团层面 事业部层面和分子公 司管理层提供高效数据分析和决策支持 与此同时 通过大数据 数据分析等应用 逐步 形成针对各产业板块的个性化的数据挖掘 数据预测 以提高对市场的洞察力 提升客户 满意度 促进技术创新 最终达成提升企业市场竞争力 为企业创造更多的经济效益和社 会效益 2 2 南车时代电气数据仓库平台建设 2 2 1 数据仓库建设原则 数据仓库系统的建设不是一蹴而就的 是一个渐进和长期的过程 所以 XX 公司在南 车电气数据仓库建设项目方案规划过程中 始终贯穿了下列原则 先进性 采用业界领先的管理思想和技术手段构建数据仓库 保证信息化体系结构 和数据仓库解决方案在业界处于领先地位 开放性 数据仓库系统模型采用国际统一标准进行建模 集成 SAP ECC 各模块数 据 这些数据可供管理人员共同使用 支持多种数据源和第三方的分析与报告工具 支持数据的抽取和数据的分析 如能够提供对各种数据业务含义进行解释和方便的查 询 为开发人员提供高效的外部接口 灵活性 数据仓库系统的模型需要能够依业务变化而调整 南车电气数据仓库系统 从不同的角度对整个南车电气的生产情况和销售情况进行多维度 多角度 多指标的 不同层次的分析 这样就确保了随着业务的发展 可以很方便的在此基础上扩充更多 的应用 主题 用户能够灵活地根据实际需要定制不同层次的分析 持续性 数据仓库系统提供了一个完善的数据平台 保存了大量的历史数据 具备 极佳的扩展性 可以为今后可能出现的管理 决策支持系统提供数据支持 容灾性 数据仓库系统的 3 个重要元件 包括 ODS EDW DM 的系统平台架设 于不同的数据库实例 此种设计确保系统因单个系统发生灾害时 减少系统恢复的时 间 降低相应的损失 2 2 2 数据仓库规范体系设计 2 2 2 1 数据仓库目标分析 数据的存储和管理是企业级数据仓库的核心内容之一 企业级数据仓库存储详细数据 及必要的汇总数据 支持整个企业的业务分析和决策 现有业务系统的数据被抽取 清理 并有效地集成到数据仓库中 并按照主题进行重新组织 数据仓库设计时应全面考虑 实 施时可以先按照需求的轻重缓急选择部分业务主题 然后逐步扩展到涵盖全部业务 数据仓库管理的数据包含了集成之后的多年历史数据 数据量是巨大的 数据应被合 理的规划 组织 存储 分片和索引 保证数据的管理和使用的高效性 按照企业建立数 据 唯一事实 的要求 数据仓库应为各级业务人员提供一致的信息视图 因而 整个企 业应共享统一的数据存储模型 与这样的要求相匹配 企业数据仓库采用满足第三范式的 规范化建模 规范化建模是一个剔除冗余并应用业务规则的过程 它的目的是为了更好的理解和表 达存在于数据元素之间的依赖性和参与性 规范化的关系型数据通常能够给出精确和无歧 异的回答 规范化建模的目的是建立企业级数据仓库的逻辑数据模型 逻辑数据模型是把业务需 求 特别是对数据的需求 用规范化的 ER 模型和文字进行描述 它反映的是业务逻辑 因此它是数据库中立 技术无关的 同时 它应能涵盖业务需求的各方面 回答有关业务 的所有合理问题 逻辑数据模型标识出业务管理领域中涉及的主题 实体 属性 及它们 之间的关系 主题集中反映某方面业务内容 通常是同类或关联关系较为紧密的实体的集 合 实体是任何可以区分的人 地点 事情 事件或概念 信息围绕它来保存 属性是实 体的特性或数据字段 对数据仓库需求进行分解 按业务主题进行组织 将业务主题相关的数据组织成主题 域 并对各指标进行分析 数据仓库目标分析后形成数据仓库目标说明书 其中详细说明包含的业务主题 业务 主题域等内容 数据模型是数据仓库系统的关键部分 开发数据模型除了要描述企业现有的业务数据 架构 还要满足企业未来业务扩展的需要 通过整体数据架构的搭建可以实现以下三个目 标 数据整合 建立业务数据构架 找出业务项目的相互关系 描绘企业的各个业务项 目在现实中是如何被组合在一起的 创建出企业业务的整体性视图 基于业务数据 架构创建企业数据模型 能够较好地保证数据模型的稳定性和有效性 理解业务 不同部门用户对数据有着不同的理解 作为企业级的决策支持系统必须 通过一定的手段把这些不一致的理解定义出来 支持性元数据的使用就是解决这一 问题的主要手段 数据分析 业务上经常遇到同一指标在不同报表里得到的值不一致 有些不一致是 为人所知的 有些不一致却没有人清楚 通过对数据的分析和了解 使不一致变得 明显而可操作 是数据模型建立的主要目标之一 通过元数据的使用 记录数据的 加工规则及使用环境 可以让使用者清楚地知道差异的原因 从而正确使用这些数 据 控制好建模范围和周期将直接关系到项目的进展 最好的方法是利用已有的各类业务 需求 报表需求及查询需求 借助建模人员本身的业务经验及与各部门业务人员的沟通 将获得的需求片断有机地组织成一个完整的目标区域 在区域范围内开展建模工作 2 2 2 2 数据仓库逻辑模型 数据仓库逻辑模型设计要进行的工作主要有 分析主题域 确定当前要装载的主题 确定粒度层次划分 确定数据分割策略 关系模式定义 记录系统定义 逻辑模型设计的成果是 对每个当前要装载的主题的逻辑实现进行定义 并将相关内 容记录在数据仓库的元数据中 包括 1 适当的粒度划分 2 合理的数据分割策略 3 适当的表划分 4 定义合适的数据来源等 2 2 2 3 数据仓库物理模型 数据仓库物理模型所做的工作是确定数据的存储结构 确定索引策略 确定数据存放 位置 确定存储分配 确定数据仓库实现的物理模型 要求设计人员必须做到以下几方面 要全面了解所选用的数据库管理系统 特别是存储结构和存取方法 了解数据环境 数据的使用频度 使用方式 数据规模以及响应时间要求等 这些 是对时间和空间效率进行平衡和优化的重要依据 了解外部存储设备的特性 如分块原则 块大小的规定 设备的 I O 特性等 2 2 3 BW 数据仓库结构定义 2 2 3 1 数据抽取层 数据抽取层是面向业务主题划分的一组数据模型 用于从每个源系统中抽取必需的数 据 该层数据对接 BW 底层与其他业务系统数据 同时仅对该层数据进行基本的清理 以 保留业务系统原始数据 BW 系统使用信息包完成对业务源系统的抽取工作 主要抽取 SAP ECC PLM 报价 系统 预算系统等核心系统以及外部文本的数据 根据的具体情况 可以将各业务系统数 据源信息包分为以下几类 系统历史交易数据初始化信息包 系统增量交易数据抽取信息包 系统全量交易数据抽取信息包 为了将数据从各源系统顺利抽取至 BW 系统 需要进行以下工作 配置 BW 与各源系统的接口连接 复制各业务源系统的数据源 创建各数据源的初始化 全量 增量信息包 SAP ECC 系统 LO 数据源的初始化 删除 填充设置表 执行信息包 装载数据至 PSA 创建信息包到数据抽取层 DSO 转换及 DTP 将数据从 PSA 加载至数据抽取层 DSO 2 2 3 2 数据逻辑层 数据合并层是面向客户业务操作将抽取层数据进行初步的清洗和整理 将数据抽取层 中数据按照业务规则集成 整合的过程 在此模型上执行粒度较细的查询分析 该层模型 的集成 整合工作主要分为以下两大类 不同业务系统间模型合并 数据抽取层中来自不同业务系统的模型数据 按照业务规则创建模型转换 进行数据 合并 该过程要注意来自异构业务系统的数据格式 关联关系 根据实际需要新增数据映 射关系表 以保证数据合并 同一业务系统内模型合并 数据抽取层中来自同一业务系统的模型数据 按照业务内容及逻辑规则创建模型转换 进行数据合并 以上合并过程 最终都通过数据传输流程 DTP 进行数据加载 将数据抽取层转换 加载至数据逻辑层 DTP 默认加载方式为增量加载 2 2 3 3 数据分析层 数据分析层是面向高层战略分析将数据合并层的业务数据统一汇总到数据分析层 提 供综合决策数据支撑 该层模型的设计原则是以最终分析为准 根据分析规则创建转换 将数据指标按照多维度组织 同时衍生出计算后分析指标 通过数据传输流程 DTP 将 数据加载至数据分析层 2 2 3 4 ETL 过程 BW 系统集成了对各种源系统进行数据抽取 数据转换及加载到数据仓库的各种功能 并提供简单的图形化操作界面 可以通过简单的拖动实现数据源的建立 数据的抽取 可 以定义数据转换的规则及加载方式 时间等 上图即为 BW 数据仓库 ETL 的流程 使用信息包 InfoPackage 将数据从源系统抽 取至 BW 底层 PSA 通过一系列的转换 Transformation 和数据传输流程 DTP 将 PSA 中数据逐层加载至数据抽取层 数据合并层及分析层相应的模型中 2 2 3 5 数据存储 BW 数据仓库中 数据存储采用的分层设计方法 即上文所划分的数据抽取层 数据 合并层 数据分析层 在这样的设计中 数据是真正物理存储于各层模型中 数据在流经 各层时 从性能与准确性方面考虑 使用全量或增量 2 2 3 6 分析层 数据分析层提供给商务用户一个专业的数据视图 提供多样展示数据必需的功能 选 择分析工具集来满足数据展示的需求信息 这个工具的具体信息在软件和硬件层里详细的 描述 属性 描述 主要功能 此层给出了支持商务用户信息需求的功能 内在关系 数据存储层 数据处理 安全与保密 系统管理 软件和硬件 元数据 连接 2 2 3 7 主数据 按照需求应用的需要 主数据首先进入到抽取层 DSO 中 抽取层 合并层使用 DSO 存放数据 分析层一般使用 DSO 存放数据 但亦有使用特性存放主数据 如与时间相关 的主数据 2 2 3 8 交易数据 交易数据的 DSO 中 必须记录每笔业务数据的业务产生的时间戳或者日期 且需要 明细到凭证级 Cube 中仅存放汇总后的业务数据且此类数据是已经经过逻辑处理的 2 2 4 数据仓库管理标准及命名规范 2 2 4 1 命名规则设计原则 层次 常用名 作用 4 Outbound Data Layer ODL 数据集市接口层 通过 Open Hub BAPI RFC 等方式向系统外的应用 程序提供数据的接口层 3 Reporting Data Layer RDL 报表层 报表层 主要由立方体 多信息提供者 虚拟信息提供 者构成 以业务需求和性能为首要考虑因素进行最终输出模型维 度设计 2 Consolidation Data Layer CDL 逻辑合并层 逻辑处理层 实现报表逻辑 储存逻辑处理完的数据 1 Inbound Data Layer IDL 原始数据层 全量保存来自数据源的数据 是以后若干年所有报表需 求的数据基础 保证一期上线以后 后面若干年对数据 的需求不会导致 ERP 停机抽取 此层数据未经过转换和数据粒度处理 全部采用覆盖模 式的 ODS 构成 部分业务模块可以采用写优化 ODS 0 Persistent Staging Area PSA 缓存层 数据缓存层 与数据源对应 占用 BW 数据库磁盘空间 最大比例 每三到六个月定期清理一次 2 2 4 2 BW 系统开发对象通用编码 2 2 4 2 1 代表源系统 按以下规范编码 全称适用于信息区域的命名 缩写适用于其 他开发对象的命名 SAP 系统按 0 9 数字顺序编码 全称 缩写 含义 SD1 1 SD1 SAP ERP SD2 2 SD2 SAP CRM 以下顺序编码 以下顺序编码 非 SAP 系统按 A Z 字母顺序编码 2 2 4 2 2 根据南车管理现状 代表经营中心 按以下规范编码 全称为经营中心全称或者惯用称呼的每个字的拼音首字母 缩写为以下字母编码 全称适用于 信息区域的命名 缩写适用于其他开发对象的命名 全称 缩写 含义 NCJT 注 下划线 南车集团 适用于集团层面或多经营中心 无法 具体到某个经营中心的命名 FYGLXT A 费用管理系统 YSXT B 预算系统 C D E 以下顺序编码 2 2 4 2 3 代表模型层次 按以下规范编码 全称适用于信息区域的命名 缩写适用于其 他开发对象的命名 全称 缩写 含义 IDL I 原始数据层 CDL C 逻辑合并层 RDL R 报表层 ODL O 数据集市接口层 IBJ B 特征信息区域 2 2 4 2 4 代表数据主题 按以下规范编码 无缩写及全称的区分 除了以下常用缩写 其他的内容可以根据缩写决定 并及时更新到该规范中 命名 主类 命名 子类 主题含义 FI 财务 含财务通用 或无法归集到子类的 AP 应付 AR 应收 CO 管理会计 GL 总账 PA 盈利分析 SD 销售及分销 含销售通用 或无法归集到子类的 SO 订单 PO 采购单 DN 发货单 SP 装运单 BL 发票 MM 库存 PP 生产 2 2 4 3 南车 BW 系统开发对象命名规范 2 2 4 3 1 Info Area 1 最多 30 个字符 2 以 Z SINOCHEM 开头 3 第一层 注 此层已建立 无需重建 Z SINOCHEM LAYERED DESIGN LSA 模型设计 4 第二层 根据模型架构层次创建 注 此层已建立 无需重建 Z SINOCHEM LAYER IDL 原始数据层 Z SINOCHEM LAYER CDL 逻辑合并层 Z SINOCHEM LAYER RDL 报表层 Z SINOCHEM LAYER ODL 数据集市接口层 Z SINOCHEM LAYER IBJ 特征信息区域 5 第三层及往下层 分 IDL CDL 及 RDL 这两种情况 适用不同的命名规范 注 从此层开始 按照编码规范和项目需求 进行创建 如为 IDL 层 i 第三层首先按模型层次及源系统创建 命名规范是 Z SINOCHEM LAYER 参见 3 2 4 2 3 参见 3 2 4 2 1 示例 Z SINOCHEM LAYER IDL SD1 集团 SD1 原始数据层 Z SINOCHEM LAYER IDL FILE 各类文本 ii 除文本之外的第四层 根据需要按照数据主题域区分 即 Z SINOCHEM LAYER 见 3 2 4 2 4 示例 Z SINOCHEM LAYER IDL SD1 SD Z SINOCHEM LAYER IDL KTDB PP iii 文本向下第四及第五层 根据需要 首先按照经营中心 然后按照主题域区分 第四层 编码规范如下 Z SINOCHEM LAYER 见 3 2 4 2 2 示例 Z SINOCHEM LAYER IDL FILE SYZX Z SINOCHEM LAYER IDL FILE ZHJT 第五层 编码规范如下 Z SINOCHEM LAYER 见 3 2 4 2 4 见 3 2 4 2 2 示例 Z SINOCHEM LAYER IDL FILE SYZX YZ Z SINOCHEM LAYER IDL FILE ZHJT YS CDL 和 RDL 层 i 首先按经营中心创建 命名规范是 Z SINOCHEM LAYER 参见 3 2 4 2 3 见 3 2 4 2 2 示例 Z SINOCHEM LAYER CDL ZHJT Z SINOCHEM LAYER CDL SYZX Z SINOCHEM LAYER CDL ZHGJ ii CDL 和 RDL 层 继续下分时 按主题域创建 命名规范是 Z SINOCHEM LAYER 参见 3 2 4 2 3 见 3 2 4 2 2 见 3 2 4 2 4 示例 Z SINOCHEM LAYER CDL XTGS FI Z SINOCHEM LAYER CDL HFZX SD 2 2 4 3 2 ODS 1 最多 8 个字符 2 以 Z 开头 注 如果以 Z 开头的编码已全部被占用 才可 Y 此条适用于所有以 Z 开头的命名 规则 下面不再特殊注明 示例 ZI1SOS01 SD1 的 IDL 层订单 ODS Y I1SOS01 某某中心的整合订单 ODS 3 ODS 必须根据它的作用分配到指定的层次 如 IDL CDL RDL 4 命名原则 ZS 见 3 2 4 2 3 见 3 2 4 2 4 2 位数字编码 分如下两种情况 分别适用不同的编码规则 i 如模型属于 IDL 层 则代表源系统编号 即 见 2 1 示例 ZI1SOS01 SD1 的 IDL 层订单 ODS ZI2SOS01 SD2 的 IDL 层订单 ODS ii 如模型属于 CDL 或则 RDL 层 则代表经营中心 即 见 2 2 示例 ZC SOS01 ZCASOS01 2 2 4 3 3 Cube 1 最多 8 个字符 2 以 Z 开头 3 Cube 必须分配到 RDL 层次 4 命名原则 ZRC 见 3 2 4 2 3 见 3 2 4 2 4 2 位数字编码 示例 ZRLGLC01 财务公司收入分析 Cube ZR GLC01 集团的收入分析 Cube 2 2 4 3 4 MultiProvider 1 最多 8 个字符 2 以 ZR 开头 3 必须分配到 RDL 层次 5 命名原则 ZRM 见 3 2 4 2 3 见 3 2 4 2 4 2 位数字编码 示例 ZRLGLM01 财务公司收入分析 Cube ZR GLM01 集团的收入分析 Cube 2 2 4 3 5 Aggregates 1 命名原则 AGGR 所属 Info Cube 的技术名称 2 位数字编码 示例 示例 ZRLGLC01 AGGR01 ZR GLC01 AGGR01 2 描述原则 把累计的特征列出 用 隔开 示例 Material Plant Month Plant Material Component Month 2 2 4 3 6 InfoObject Catalogs 1 最多 30 个字符 2 以 Z 开头 3 Cube 必须分配到 RDL 层次 4 命名原则 Z 所属 Info Area 的技术名称 CH 特征 KF Key Figure 2 2 4 3 7 Info Object 命名规则 Z 变量 字段长度 说明 Function Area 2 见 3 2 4 2 4 Name 5 自定义名称 部分参照 R3 字段名 示例 ZFI BANK 银行 2 2 4 3 8 Hierarchy 为系统标准的来自 BI Content 中的信息对象建立 Hierarchy 时 按以下命名规则 命名规则 Z H 变量 字段长度 说明 InfoObject 7 NN 2 当前编号 标号从 01 开始 Date 6 有效起始日期 YYMMDD 注意 如果长度不够 可以将缩写 示例 为 0Company 建立 Hierarchy 时 命名为 ZCompany H01 031121 也可缩写为 ZCC H01 031121 为自定义的信息对象建立 Hierarchy 时 按以下命名规则 命名规则 Z H 变量 字段长度 说明 InfoObject 7 见 3 2 4 3 7 NN 2 当前编号 标号从 01 开始 Date 6 有效起始日期 YYMMDD 注意 如果长度不够 可以将缩写 示例 ZFI BANK H01 031121 2 2 4 3 9 Query 项目组内部命名规则 命名规则 Q Variable Length Comment MultiProvider 8 Multiprovider 的全名 NNN 3 三位数字 从 001 开始 其他用户或者其他用途创建命名规则 例如 培训 测试用途 命名规则 Q 变量 字段长度 说明 Function Area 2 见模块 命名规则 Business Area 4 同 R3 系统 NNN 3 当前编号 标号从 001 开始 示例 ZT FI XXXX Q0001 2 2 4 3 10 Struture 命名规则 S 变量 字段长度 说明 MultiProvider 见 Cube 命名规则 NNN 3 当前编号 标号从 001 开始 示例 ZR SDC01 S001 2 2 4 3 11 Bex Variable 1 最多 8 个字符 2 命名原则 Z P 单值 I 范围 H 层次 N 层次节点 T 文本变量 F 公式变量 NNN 3 位数字编码 2 2 4 3 12 Calculated Key Figure 1 最多 30 个字符 2 命名原则 CK Variable Length Comment Info Cube 8 Cube 全名 CK 2 固定 NNN 3 三位数字 从 001 开始 2 2 4 3 13 Restricted Key Figure 1 最多 30 个字符 2 命名原则 RK Variable Length Comment Info Cube 8 Cube 全名 RK 2 固定 NNN 3 三位数字 从 001 开始 2 2 4 3 14 Data Source InfoSource 由标准 BI Content 激活生成的 DS 或者 IS 使用系统自动生成的名字 勿需改名字 由于客户定制需要 由 BW 顾问新建的非系统标准 BI Content 的 DS 或者 IS 请按照以 下方式命名 命名规则 Z 变量 字段长度 说明 Function Area 2 见 3 2 4 2 4 M T 1 M 代表主数据 T 代表业务数据 NN 2 当前编号 标号从 01 开始 2 2 4 3 15 Info Package 命名规则 变量 字段长度 说明 DataSource 见 Datasource 命名规则 Update 1 F Full Update D Delta Update I Delta Initial 示例 0FI GL 4 D 2 2 4 3 16 Process chain 1 命名原则 ZPC 示例 ZPC IM TRAN WK ZPC MAT ATTR DL 2 2 4 4 BW 系统权限命名规则 角色 2 2 4 4 1 singlerole 命名规则 变量 字段长度 说明 Site 3 见 3 2 4 2 1 业务代码 OBJECT 4 9 权限对象名称或模型名称 NR 4 可选 对于模型的角色可以为空 权限对象下的具体付值 示例 为南车建立公司代码上的权限对象 可以命名为 ZS CMP XXXX 2 2 4 4 2 commonrole 命名规则 变量 字段长度 说明 Site 3 见 3 2 4 2 1 业务代码 OBJECT 4 9 权限对象名称或模型名称 NR 4 可选 对于模型的角色可以为空 权限对象下的具体付值 2 3 南车时代电气 BW 数据仓库优化方案 目前南车电气的 BW 系统设计较不规范 很多可用标准方式进行 CUBE 开发的模块也 用了 ABAP 程序来进行实现 从中我们找出了很多可以优化的点 通过我们对于南车电梯 BW 系统现状的调研之后 我们给南车提供如下 BW 优化建议方案 1 现系统模型命名没有明确的规范 考虑确定明确的命名规范以便于后续的系统管理 及 后续开发项目对原有模型能有比较清楚的了解 涉及范围包括 信息范围 自定义数据 源 信息源 信息对象 模型 处理链 OPEN HUB APD QUERY 程序 函数等 等 2 现系统区域划分较乱 考虑划分出比较规范明确的区域 比如分主数据区域 业务数据 区域 业务数据区域还可分为数据抽取层 转换层 合并层 展现层等等 3 考虑系统资源的合理安排及日常数据加载的监控 考虑处理链调度时间的安排 监控 各环节数据加载顺序及方式的调整等等 4 现 BW 数据源大多为 3 5 数据源 信息源 传输规则 更新规则 考虑转换为 7 0 数据 源及转换 方便以后的运维管理及系统新功能的应用 5 CUBE 层面未做聚集 压缩 分区等处理以及 CUBE 维度的设置比如 行项目维 高 基数 维等方面的考量 6 系统里存在冗余模型及报表可考虑清理优化系统空间 系统可规则清理机制 比如定期 清理 PSA 数据 ChangLog 数据等等 7 主要的库存相关模型考虑优化 现大多数通过 SE38 程序实现 考虑是否可用标准模型 替换重构 例如涉及的程序有 ZTBW001 ZTBW003 ZTBW004 ZTBW005 ZTBW006 ZTBW007 ZTBW00 8 ZTBW010 ZTBW031 ZTBW032 ZTBW033 等 另外 以上程序里大部分 功能是通过调用现有模型的 query 通过一定逻辑处理再存入到另一模型 此部分功能 完全可以用 BW 的 APD 的标准功能替代实现 更方便后续的维护及管理 8 经落实系统中还存在抽取 HR 系统人员信息的程序 ZTBW016 此程序将人员信息数据 从 HR 系统抽取到 BW 系统中的二维表中 再按人员级别发邮件给相关用户 现程序可 能存在些问题 为方便以后的管理及操作 此程序可以用 BW 连接数据库作为数据源 的标准方式替换 2 4 数据展现层迁移方案 当完成 BW 优化升级的工作之后 我们即将着手部署 SAP BO 集成 EP 门户作为新的 数据展现 应用 层 首先我们会对该 54 张报表的业务逻辑进行梳理 了解业务之后将 进行面向未来的数据展现层报表结构设计 使得迁移到 BO 设计环境的报表符合未来的报 表设计规范 实现现阶段报表查询转线的基本应用 本期项目需做迁移的报表共 54 张 在优化好 BW 环境并且重构部分 CUBE 的基础之上 我们将当前 BW 中的相关 Query 的展现重构 以 BO 为设计平台 在原 BW CUBE 上重新开发 同时将开发好的新报表集 成到 EP 门户中 最终形成 SAP BW BO EP 的商务智能技术平台结构 完成重要历史报 表的迁移工作 2 5 主数据共享平台方案 主数据 源系统 目标系统 物料 ERP PLM SPM 制造 BOM ERP PLM SPM 客户 ERP ECM 供应商 ERP ECM 人员 HCM SPM 岗位 HCM SPM 组织机构 HCM SPM 订单 BOM ERP 只抽取 从上表中我们可以发现本期项目中需要进行系统主数据共享的一共分为 8 个主数据指 标 一个 SAP 系统和 4 套非 SAP 系统 首先 BW 的抽取方式可分为两种 1 对 SAP ERP 系统采用 BW 标准的抽取方式即可 2 对非 SAP 系统如 PLM 我们将会建立数据库连接数据源 oracle 并且考虑增量抽 取机制 当相关主数据全部进入数据逻辑层的时候 我们将在 BW 中进行建模 建立存储主数 据的模型 及对外准备的接口数据表 二维表 以供 ESB 系统来 BW 数据仓库中进行主 数据的提取 具体分层结构及 ETL 数据存储等的操作方式可参见 3 2 3 章节 这里不再做 重复的赘述 第 3 章 南车电气数据仓库建设项目实施方案 3 1 南车电气数据仓库系统实施计划 3 1 1 工作时间表 预计 比较宽泛的项目计划如下图所示 明细的项目计划将在项目合同签订后 每个阶段的需 求分析期间制定 包括明细的项目任务 工作 交付物 资源 时间等都将体现在明细计 划中 最终的项目计划将在需求收集完成后 项目主要成员充分理解项目需求 包括客户的 工作流程 标准 和执行规范等基础上制定 初步实施计划 实施内容 根据对招标文件的解读和客户要求的实施周期的通盘考虑 建议此次南车电气项目一 期实施内容如下所示 调研用户部门部分需求 同时借鉴以往经验 由架构师规划设计整个数据仓库 对BW 数据仓库的软硬件进行调优 以满足后续开发任务 调整BW中相关Query的展示界面 把报表迁移到BO平台上 抽取相关源系统主数据到BW数据仓库中 进行主数据模型开发并设计接口一共ESB系 统调用 XX 公司将根据项目需要在各阶段安排合适的资源 包括项目领导小组和质量管理委员 会定期听取项目汇报 检查项目工作 确认项目按计划 按质量要求顺利开展 以下是针对项目主要角色和责任的描述 XX 角色 描述 项目领导小组 成员 定期听取项目小组汇报 了解项目的进展状况 确保必要的项目资源投入 管理项目的边界 审批由于变更引起的项目成本和时间的变 动 监控项目风险和制定风险管理方法 项目总监 根据项目方法论推动项目的实施并监督项目的执行工作 构 建项目过程质量保证体系和质量保证措施实施监控 对项目经理的工作给予支持 帮助项目经理协调项目重要资 源并 参与项目时间 成本 范围的控制 并对项目进行考核 项目经理 项目现场管理 主要的职责包括 项目需求 沟通 风险管理 项目时间 质量 成本管理 项目团队管理 技术经理 建立和维护系统架构 包括技术架构 硬件架构 软件架构 和网络架构 以及提供相关的技术支持 角色 描述 推荐项目相关技术和工具 并支持项目实施中实施技术支持 关注如硬件 软件 网络之类的基础架构 并且还要关注这 些技术是否符合系统架构和技术标准 指导各技术小组完成设计 包括 ETL 设计 展示设计 集成 设计等 SAP BW 顾问 分析业务需求 设计快速原型ETL工程师将负责根据ETL 设计 说明书 实现整个ETL 过程 ETL工程师精通于ETL 技术 深刻 理解数据抽取 转换和加载所涉及的技术和问题 ETL工程师 还负责对所开发的ETL 模块进行单元测试 以保证所开发的模 块能够满足ETL设计说明书的要求 SAP BO 顾问 根据需求和设计开发仪表盘 报表和分析模块 对每个报表和分析模块的单元测试负责 以确保这些模块符 合详细设计说明书 培训师 负责相关软件操作培训和相关产品培训 南车电气 角色 描述 参与程度 项目领导小组 定期听取项目小组汇报 了解项目的进展 状况 确保足够的项目资源投入 管理项目的边界 审批由于变更引起的项 目成本和时间的变动 监控项目风险和制定风险管理方法 低 项 目 推动项目的实施并监督项目的执行工作 对项目经理的工作给予支持 低 角色 描述 参与程度 总 监 帮助项目经理协调资源 向项目领导小组汇报并接受项目领导小组 的指示 考核项目经理 并与项目经理共同考核项 目组成员 参与项目验收审核 项目经理 项目经理从客户的角度对整个项目的成功负责 项目经理与实施方的项目经理密切合作 确保 项目按时 在预算的基础上逐步实现项目的成 功 项目经理的职责还包括协调客户方的内部资源 根据项目的需要 推动相关资源支持项目 以 确保项目的成功实施 高 业务用户 业务专 家 在项目建成后 本项目涉及的业务人员是从项 目成果中获得收益最大的使用人员 业务人员深度理解本项目提供需求的业务含义 对提出的报表和分析等需求的细节有准确的理 解和认识 业务人员在和项目组成员合作之前 不了解 BI 的技术知识是可以接受的 但是我们建议业务 人员在项目中开发一个功能模块以帮助理解 BI 软件 从而可以在需求制定过程中更有效的工 作 项目结束时 业务用户需要负责完成对项 目的用户接受测试 最终证明本项目是可交付 的 中等 角色 描述 参与程度 IT 团队 参与项目的 IT 团队 包括基础设施负责人 DBA 专家等 需要参加解决方案培训 需求分 析 系统设计和开发等阶段 确保根据数据集 市模型的需要 从数据源系统中抽取所需要的 数据 该团队还负责在项目结束后 完成一些用户特 定的需求 参与的 IT 成员的技术背景主要如下 丰富的 RDBMS 工作背景 至少 5年的 DBA 或数据仓库经验 丰富的 BI 工作经历 至少2 3 年的 BI 报表 设计开发经验 丰富的 ETL