数据资源的整体规划上海通用汽车报表整体解决方案.docx

数据资源的整体规划上海通用汽车报表整体解决方案.docx

《数据资源的整体规划上海通用汽车报表整体解决方案.docx》由会员分享，可在线阅读，更多相关《数据资源的整体规划上海通用汽车报表整体解决方案.docx（6页珍藏版）》请在冰豆网上搜索。

数据资源的整体规划上海通用汽车报表整体解决方案

数据资源的整体规划-上海通用汽车报表整体解决方案

在绝大多数的软件系统中，报表的制作都是一项复杂但又必不可少的应用，在某种程度上甚至决定了软件能否推广，因而其重要程度不言而喻。

近几年，越来越多的企业实施了ERP系统。

随着ERP系统的完善，企业逐渐将重点转移到满足各种层次的业务报表需求的建设上来，因此企业级报表中心的建立就成了CIO们关心的一个话题。

本文以上海通用汽车有限公司的思考和实践为例，讨论了一个整体规划、局部实施的企业级报表中心解决方案，供业界参考。

在1999年4月第一辆别克车下线时，上海通用汽车有限公司（以下简称“SGM”）就建立了以美国通用汽车（GM）的核心公共系统和SAP部分模块为主的、比较完善的ERP系统。

这几年，随着SGM业务的进一步发展，SGMIT部门逐步改造了部分原有业务系统，并建立了越来越多的企业业务应用系统。

所有这些业务系统中都有一定的报表功能，能满足基本的生产管理和控制的需求。

建设过程中，一个在许多企业中普遍发生的问题也同样困扰着SGM：

尽管各业务系统中已经有许多报表，但业务部门（尤其是市场部、财务部、质量部等）在日常业务操作和管理中，仍然需要更多的报表，而且对分析型报表的需求逐渐多起来。

因此业务部门就不断地对IT支持人员提出开发新报表的要求。

为了将IT支持人员从烦琐的、零星的报表程序开发工作中解脱出来，SGMIT决定实施一个独立于各业务系统（OLTP系统）、面向整个公司或部门的报表中心项目来满足各业务部门的不断增长的报表需求。

初期建设时，对SGM报表中心项目提出了如下期望：

●该报表中心将提供各业务部门所有日常运营和管理所需的报表；

●尽可能将产生报表的功能从OLTP系统中脱离出来，以提高OLTP系统的性能；

●最大程度地减少SGMIT人员对各业务部门的报表需求的支持工作量；

●使业务用户经过简单培训后能自己定制各种报表。

在这种背景下，SGMIT部专门成立了一个报表中心项目组，该项目组的前期任务是提出SGM报表中心解决方案，该方案有以下具体要求：

●是一个可实施的（workable）的方案；

●给出关键技术难点及建议解决方法；

●对SGM未来的企业级数据仓库发展方向给出建议。

该项目组在专业咨询公司的帮助下，对SGM目前的报表需求进行了详细分析，对一些可能的技术难点进行了试验，并最终给出了下列的解决方案。

现阶段的报表需求分析

从整个企业的业务运行、管理、决策的角度看，所需要的报表可以大致分为下列几类：

1.按运行频率来分，有实时性报表和日/周/月批次报表。

实时性报表这里实时性的含义是：

能反映在报表生成这一刻之前的有关车辆、物料、费用、客户、经销商、库存、生产等信息变化的报表。

尽管从理论上讲可以采用报表中心的方式来产生这类报表，但一般我们不建议这样做。

不断地从业务系统中抽取数据，会严重影响在线运行的业务系统的性能。

日/周/月批次报表该类报表通常在业务操作（Operation）一层中所占数量较多，OLTP系统中的许多夜间工作的主要目的就是产生这类报表。

2.按报表格式来分，有固定格式报表和非固定格式报表。

固定格式报表在报表中心开发初期，这类报表大量存在。

业务人员能提出明确的需求，并给出所希望的报表格式。

这类报表适合在报表中心中开发。

非固定格式报表有时也称该类报表为AdHoc查询。

这类报表在OLTP系统中往往是一类需求或报表呈现样式不太确定的报表，而且对计算资源的需求往往较多，因此非常适合在报表中心中开发。

3.按业务层次来分，有操作类报表和管理类报表。

操作类报表目前所涉及到的大多为此类报表，主要是业务人员在日常业务操作中所需要的报表。

操作类报表中有细节数据，也有汇总数据。

管理类报表管理类报表大多为各层主管或部门经理，甚至公司领导需要看到的报表，是中度汇总或高度汇总过的数据。

4.按展现方式来分，有交互分析报表和固定发布报表。

交互分析报表这类报表的特点是一般没有固定的格式，或有一定格式但需要综合计算、汇总，而且业务分析人员往往需要从不同的角度进行分析，甚至还要在一定的假设条件下进行分析。

固定发布报表将报表以批处理的方式产生，然后存放到报表管理系统中，用户在需要的时候直接将报表展现。

除了以上分类外，还有统计分析和数据挖掘报表，这类报表是数据分析应用的较高层次的报表。

如在质量管理方面，统计分析和数据挖掘的报表展现是最主要的需求。

在售后服务方面，统计分析的需求也会很强烈。

通过以上的分析，我们可以看出，除了实时性报表适合且必须在OLTP系统中开发外，其他类型的报表都应该在报表中心中开发。

将非实时性报表从OLTP系统中脱离出来，通过建立报表中心系统来单独开发的一个最直接的好处是：

大大提高了OLTP系统的运行性能和响应速度。

开放式企业级报表中心解决方案

本解决方案架构中，数据源部分是SGM目前所有的数据源类型。

除此之外，我们将整体架构分成四部分：

ETL（提取、转换、导入）部分，数据重组织（DataRe-Construction）部分，数据呈现（Presentation）部分，元数据管理（MetaData）部分。

1．ETL部分

该部分表示了从目前SGM业务系统数据库中抽取数据的过程。

在目前建设数据仓库应用的诸多案例中，对ETL这部分通常采用两种模式开发：

开发人员自己编写程序这是早些年被大多数公司所采用的一种方式，开发人员自己编写程序从业务系统中抓取数据。

优点是表面看起来前期投资较少，但经过几年的实践，逐渐暴露出下列缺点：

（1）开发周期长。

由于数据抽取、转换、转载等环节都由开发人员一行行编写程序来完成，因此开发效率不高，导致即使是中小规模的项目，整个开发周期也很长，无法及时满足业务部门的需求。

（2）维护工作量大。

由于整个ETL部分都是代码组成，支持人员阅读困难，当系统有故障时，导致查错、排错的工作量很大。

这实际上与当初建设数据仓库应用时希望将IT日常支持人员从烦琐的、大量的报表支持工作中解脱出来的初衷相违背。

（3）可扩展型差。

数据仓库应用开发是一个不断完善的过程，只有开始，没有结束。

当业务用户提出新需求时，往往要对ETL部分做一定的改动，此时就表现出整个系统的可扩展性较差。

采用商业化的ETL工具这几年越来越多的公司在数据仓库应用开发中采用了商业化的ETL工具。

ETL工具被认为是数据仓库应用开发中最重要的工具之一，其主要原因是：

（1）能够明显改正由于开发人员自己编写ETL程序所导致的诸多缺点。

（2）能够带来由于开发效率高、项目周期缩短而使得项目风险降低的利益。

（3）自动调度功能的实现。

由于ETL工具都有很强的工作流调度功能，因此很容易实现数据抽取、转换、装载等各种程序在多种触发条件（如系统时间、操作系统事件、数据库事件等）下的运行。

若由手工编写程序来实现对几十到几百个工作流的调度，则复杂程度很高，难度很大。

（4）能充分利用硬件平台的资源（如SMP、MPP、Cluster等），提高数据抽取、转换、转载的效率。

要特别提醒注意的是，在选择商业化的ETL工具时要检查对主流ERP软件的支持程度。

若公司实施了SAP、Siebel、PeopleSoft等应用，则一定要考虑ETL工具是否有专门的针对这些应用的联接程序（Adapter）。

因为这些应用的数据库设计非常复杂，且一般都在应用层（ApplicationLayer）对数据库进行了一定程度的封装，因此需要专门的Adapter来正确读取数据。

2．数据再组织部分（DataRe-Construction）

我们在该部分采用了下列技术来实现报表中心的数据组织：

分段存储区（StagingArea）在本方案中，我们设计分段存储区仅仅为一个数据缓存区，主要是利用前面介绍的StagingArea的隔离和缓存的作用。

其数据模型比较简单，是E-R表示的关系型数据库模型，基本继承了数据源中的实体关系。

也有用简单的文件系统来表示的数据模型，具体的数据模型待后续项目实施过程中详细定义。

操作数据存储（ODS）由于ODS的特点是面向主题的、集成的、变化的，数据是当前的或接近当前的，因此在设计时往往按主题来设计数据模型，而且要体现出对某一个主题，数据模型是集成的。

同时，它不像通常意义上数据仓库中的数据是稳定的，在ODS中数据是动态变化的，即可以对其数据进行增、删、改等操作。

在本解决方案中，采用操作数据存储（ODS）完全是为了满足业务系统IS－AUTO（SAP在汽车行业的完整解决方案）中所涉及到的一些反映销售、生产、物料、运输等动态变化的报表开发而设计的。

由于IS-AUTO中包含有六大模块，因此设计按每个模块为一个主题来组织ODS中的数据。

SGMMDDataMart这是一个以SGM市场部的需求为目标的数据集市。

从Sales和Distribution这个主题来看，一些反映动态变化过程的报表，可以在ODS中解决。

但由于目前市场部的报表需求比较多，且较多报表是反映历史的状况，因此我们决定设计一个专为市场部服务的数据集市来解决这类报表的开发问题。

多维分析（OLAP）在目前的报表需求中，尽管比较多的报表是关于详细数据的、操作层面的报表，但也有一些报表是属于管理层面的、多维分析的报表，比较典型的是CO模块的所有报表和DOL中的部分报表。

通过与市场部的主要业务用户的交流，我们发现他们对多维分析报表的需求还有很多，因此在数据集市的基础之上，我们又引入了多维分析的设计，以便更好地满足用户对交互分析型报表的需求。

3.数据呈现（Presentation）

针对目前这两个项目的固定报表，我们可以采用下列方式来展现报表：

Excel方式这是受多数用户欢迎的一种报表展现方式。

该方式既可以在Web上展现Excel表格的报表，也可以允许用户将报表下载到本地机器以Excel表格的方式保存。

BO用BO作前端展现工具，除了可以自动产生报表并自动发布外，还允许用户自己定义语义层，自己生成一定格式的报表，并且还能对数据做多维分析。

这会大大减轻IT支持人员不断为用户开发报表的工作量。

4.元数据（MataDataManagement）

按照定义，元数据（Metadata）是关于数据的数据。

我们将其按用途的不同分为两类：

技术元数据（TechnicalMetadata）和业务元数据（BusinessMetadata）。

技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。

业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。

业务元数据主要包括以下信息：

使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息。

在报表中心的开发中，我们将元数据管理当作重中之重来考虑，采用专门的工具来对元数据进行统一管理。

未来企业级数据仓库规划

在报表中心解决方案的基础之上，结合我们对数据仓库的理解和几年的实践经验，给出的一个框架性的构想，旨在说明从报表中心解决方案的实施开始，如何向企业级数据仓库过渡并最终全面建成一个企业级数据仓库。

在由数据集市向企业级数据仓库扩展的过程中，若能很好地实施下面几个方面所涉及到的内容，则SGM就一定能建设一个完善的企业级数据仓库应用系统。

1．Baseline部分由虚化变成实在

这里实现的就是BillInmon所定义的“面向主题的、集成的、稳定的、随时间变化的”的数据存储系统。

Baseline主要保存所有的细节数据（但并不是所有的Transaction数据），每一条细节数据都是稳定的，不再随时间变化。

它是所有数据集市的数据源。

这里的数据只能增加，不能修改和删除。

这部分的建设时间往往要在对整个企业的业务流程和管理需求非常清楚的前提下才能开始。

2．更多的数据集市

今后要针对企业的每个业务部门建立相应的数据集市。

在实施了所有业务部门的数据集市后，Baseline的建设就变成纯IT部门的项目。

“纯IT部门的项目”的意思是：

当实施了所有部门的数据集市后，我们对业务部门的需求就能全面了解，此时再做一次数据“集中”，就是纯IT人员的事情了。

3．元数据管理

对企业元数据（MetaData）管理的好坏，是评价一个企业级数据仓库建设成功与否的最关键的指标。

所谓元数据管理的成功，就是任何一个元数据，在整个企业中只能有一个标准或定义。

在数据仓库的建设各个环节都有元数据管理问题。

如在ETL过程中，有关于数据源的元数据定义，关于数据转换的元数据定义，关于目标数据的元数据定义；在数据建模和组织过程中，有关于表定义的元数据，字段定义的元数据，表与表之间关系的元数据，维表定义的元数据，事实表定义的元数据等;在展现过程中，有关于语义层定义方面的元数据等。

对元数据的管理，是从开发第一个数据集市开始的。

当要开发第二个数据集市时，就要首先检查已经定义过的元数据并加以引用。

若已经定义过的元数据无法满足要求，则要修改元数据，然后再引用。

这样当一个个数据集市建立后，整个企业完整的元数据库也就建立起来了。

对元数据的统一管理，有专门的工具帮助开发人员和维护人员来较好地完成对元数据的管理。

结束语

数据仓库系统的建设只有开始，没有结束。

未来上海通用汽车的IT系统建设的重点将转移到基于数据仓库的应用开发上来，本文的结果仅仅是我们在这方面的初步实践。

随着开发工作的逐步展开，更高形式的商务智能系统将逐步得到应用。

（本文作者系上海通用汽车有限公司信息部工程师）