本人理解之一：关于数据仓库体系结构基本功能单元的介绍(ZZ)

Keith这个系列的文章真是不错:D
http://www.bicubes.com/modules/newbb/viewtopic.php?topic_id=112&viewmode=flat&order=ASC&type=&mode=0&start=0

系统构成主要功能单元：
ａ、数据源连接定义模块
　　根据访问不同数据源的方式，频次，抽取顺序，数据存贮方式，定义ODS或DW的数据链接。

ｂ、数据抽取、转换、移动和加载工具（ETML）
　　分为两部分功能：
　　１、不同数据源到ODS的部分，按ODS的结构抽取到ODS，然后进行清洗、转换。
　　２、ODS到DW，或者一些简单不需预处理的数据直接数据仓库星形模型部分。

ｃ、ODS,数据中转区(Staging Area)
　　将数据加载到数据仓库之前的数据准备区。做数据转换、清洗等都可以在此完成。作用主要包括：
　　１、快速采集数据源数据，减少数据采集对应用系统的冲击。
　　２、因为可对多数据源的统一采集，提高采集数据的可靠一致性。
　　３、当数据转换出错或失败时，可从ODS中再次抽取数据进行转换，不必直接面对OLTP系统，减少对OLTP负载，提高效率。

ｄ、元数据(Meta Data)管理
　　元数据记录和描述所有数据仓库定义, 数据分析的模型，设计, 维护，管理和构造过程以及使用等方面的信息。
　　元数据分为以下三类：
　　业务元数据：对业务术语的描述。比如将“Customer”转化为“客户”，便于业务人员理解；
　　技术元数据：数据仓库的结构、Mapping等都是典型的技术元数据；
　　操作元数据：作业调度规则、系统维护规定等等。

ｅ、数据集市(Data Mart)
　　针对特定主题建立的一套含有高度汇总层数据和计算数据的分析系统，可应用MOLAP和ROLAP技术，主要为统计预测分析服务。

ｆ、决策支持(DSS)
　　基于Web的交互式查询、报表和联机分析处理系统，以及EIS, 可以针对数据集市或数据仓库进行各种形式的数据展现，一般直接服务分析用户和决策层领导。

ｇ、 数据挖掘 (Data Mining)
　　运用数据挖掘工具,通过使用神经元、决策树等挖掘算法，用历史数据训练数学模型，分析隐藏在历史数据中，无法通过普通查询得的重要业务信息。

ｈ、数据仓库管理(Data Warehouse Manage)
　　该部分包括了数据仓库和决策支持系统管理的所有方面，包括系统、应用和数据安全性，用户身份验证和基于角色的权限授予、数据库日常维护、备份和恢复、监控和调整、操作和任务调度，数据使用审计和容量规划等等。

本人理解之四：ETL的主要步骤(ZZ)

赞一个！很精辟实在的文章。
http://www.bicubes.com/modules/newbb/viewtopic.php?topic_id=237&forum=9

ETL(Extract Transform Loading, 数据抽取转化装载规则)是负责完成是数据源数据向数据仓库数据的转化的过程。是实施数据仓库中最重要的步骤。可以形象的说，ETL的角色相当于砖石修葺成 房子的过程。在数据仓库系统设计中最难的部分是用户需求分析和模型设计，那么工作量最大的就是ETL规则的设计和实施了，它要占到整个数据仓库设计工作量 的60%-70%，甚至更多。
　　下面是本人对ETL的几个重要步骤理解，和大家分享！

一、ODS区的数据采集：　 　最主要作用为了尽量减少对业务系统的影响。表结构可以不必和DW一致。根据具体业务需求和数据量情况，将数据源的数据放入ODS有各种不同的方法，比如 Oracle的数据库链路，表复制，SQL*LOADER，Teradata的Fastload，Sysbase的BCP等等。

　　需要解决的问题包括：
a、数据的时间差异性问题
　　在抽取旧有数据时，要将不同时期的数据定义统一，较早的数据不够完整或不符合新系统的数据规范，一般可以根据规则，在存入中转区的过程中予以更新或补充。

b、数据的平台多样性问题
　 　在抽取旧有数据时，大部分数据都可采用表复制方式直接导入数据中转区集中，再做处理，但有部分数据可能需要转换成文本文件或使用第三方工具如 Informatica等装载入数据中转区。这部分数据主要是与数据中转区数据库平台不一致的数据库数据，或非存储于数据库内的文本、excel等数据。

c 、数据的不稳定性问题
　　对于重要信息的完整历史变更记录，在抽取时可以根据各时期的历史信息，在抽取需要信息等基本属性的旧有数据时，要与相应时段的信息关联得到真实的历史属性。

d 、数据的依赖性问题
　　旧有业务系统的数据关联一般已有约束保证，代码表和参照表等数据也比较准确，但仍有少量数据不完整，对这部分数据，需根据地税的需求采取清洗策略，保证数据仓库各事实表和维表之间的关联完整有效。
　　数据仓库各事实表和维表的初始装载顺序有先后关系，要有一个集中的数据装载任务顺序方案，确保初始数据装载的准确。这可以通过操作系统或第三方工具的任务调度机制来保证。

二、数据转换、清洗：
　 　将ODS中的数据，按照数据仓库中数据存储结构进行合理的转换，转换步骤一般还要包含数据清洗的过程。数据清洗主要是针对源数据库中出现二义性、重复、 不完整、违反业务或逻辑规则等问题的数据数据进行统一的处理，一般包括如：NULL值处理，日期格式转换，数据类型转换等等。在清洗之前需要进行数据质量 分析，以找出存在问题的数据，否则数据清洗将无从谈起。数据装载是通过装载工具或自行编写的SQL程序将抽取、转换后的结果数据加载到目标数据库中。

　　数据质量问题具体表现在以下几个方面：
a、正确性（Accuracy）：数据是否正确的表示了现实或可证实的来源?
b、完整性（Integrity）：数据之间的参照完整性是否存在或一致?
c、一致性（Consistency）：数据是否被一致的定义或理解?
d、完备性（Completeness）：所有需要的数据都存在吗?
e、有效性（Validity）：数据是否在企业定义的可接受的范围之内?
f、时效性（Timeliness）：数据在需要的时侯是有效的吗?
g、可获取性（Accessibility）：数据是否易于获取、易于理解和易于使用?

　　以下综合说明数据仓库中数据质量要求，包括格式、完整性要求。
a、业务描述统一，对数据模型的不同版本融合、映射为唯一版本。包括：
　　1、在业务逻辑没有变化的前提下，旧的业务数据映射在新模型上。
　　2、 遗留系统的人事信息、考核相关信息与业务系统、行政其他模块要一致。
b、信息描述规范、完整。
　　1、不存在格式违规
　数据类型不存在潜在错误。
　　2 、参照完整性未被破坏
　数据不会找不到参照。
　　3 、不存在交叉系统匹配违规，数据被很好集成
　相同的数据存在于多个系统中，数据之间要匹配。
　　4 、数据在内部一致
　同样的纪录字段在同一个表中重复出现，不能有差别。

　　以下是对主要数据质量问题的清洗策略：

主要问题	表现形式	产生原因	清洗策略
数据完整性问题	大量的空值字段的出现	原OLTP系统中对很多字段没有做非空限制	1. 交由OLTP系统重新录入, 补齐 2. 在数据仓库对应的维表中建立一个新的字段, 将这些空值字段的值统一的赋值
	超出字典表范围	填写这些值的时候是直接让用户填写而非下拉框选择	1. 交由OLTP系统重新录入, 补齐 2. 在数据仓库对应的维表中建立一个新的字段, 将这些空值字段的值统一的赋值
数据一致性问题	一个特定的字段在不同的表中内容不同	录入, 同步的问题	1. 选取最可靠的表中的字段为确定值
	应该成为主键的值不唯一	原OLTP系统中未建立有效的主键关系	1. 消除错误, 重复的主键

三、数据加载：
　　将转换和清洗完的数据按照数据仓库的结构进行数据加载。需要考虑初始数据装载、数据刷新、加载顺序等等问题。
　　a、针对数据现状，初始导入有这样一些问题需要考虑：
1、如何解决时间差异性？
2、如何解决平台差异性？
3、如何适应数据的不稳定性？
4、如何解决数据依赖性？

　　b、数据刷新的策略要根据业务需求和应用系统的承受能力和数据情况决定。主要有这样一些问题需要考虑：1、如何解决时间差异性？
2、如何适应数据的不稳定性？
3、如何解决平台差异性？
4、如何解决数据依赖性？
5、如何减少对业务系统的影响？

　　c、不同的刷新任务类型，对业务系统的影响不同，刷新任务有以下种归类特性：
1、刷新频率：
实时刷新、每数小时、每日、每周、每月、不定期手动刷新。

2、刷新方式：
数据库表复制、文本文件ftp再装载、物化视图、数据库trigger。

3、数据加工方式：
简单插入更新、增加计算项字段、多表关联更新、汇总、多表关联汇总计算。

　　并可针对各种异常情况做处理：回滚，重新装载，断点重新装载等等，还可在任务完成后（或失败后）将日志以Email方式发给数据仓库管理人员。

四、汇总层、CUBE加载：
　　ODS加载进入数据仓库的数据只是底层详细层数据，还需按定义的汇总规则进行汇总，生成数据集市用的汇总表或CUBE。ETL流程是指完成每个维表数据及事实表数据导入的顺序, 其包括两个部分, 初始导入数据时的ETL流程, 及增量导入时的ETL流程。

初始导入数据时的ETL流程
第一步: 自动生成维的数据装载
　 　自动生成维一般来说就是日期，年度月份，年度等时间类维度（年度月份，年度其实都是日期维的一个层次，但某些事实表中没有日期信息，只有月份信息，所以 需额外建立此二维度），几乎数据仓库中每个数据模型都需使用时间类维度，在加载其它维度和事实之前，需要先将时间维度生成出来。

第二步: 手工维护维度装载
　　实际数据仓库开发中，很可能会有些维度的数据在业务系统中无发得到，典型的是一些外部信息指表的类型代码，是由数据仓库开发人员设计的。所以需要手工方式建立这些信息，然后导入数据仓库。

第三步: 缓慢变化维表数据装载
　　这些维度可以从业务系统中找到来源，但变化比较缓慢。对于初始装载时，需要考虑对缓慢变化维的处理方式要和增量刷新方式一致。
　　在装载事实表数据之前，需要先装载这些维表。需要注意的是，有些维本身就是事实表，其所依赖的维必须先装载完成。

第四步: 事实表数据装载
　　然后是初始装载所有的事实表数据。事实表之间也有依赖关系，某些事实表需在其他事实表装载之前装载。（如果ETL程序已保障了数据的完整性，也可以在将关联约束禁用的情况下不考虑先后顺序，但一般不建议）。

第五步：聚合表初始生成
　　许多数据仓库的前端应用，并非直接使用主题星型模型中的事实表数据，而是聚合表中汇总，运算好的数据。（Oracle OLAP Service所建立的ROLAP 和数据集市实际上也是使用一系列的经过大量预先计算得到的聚合表）

增量导入
第一步: 缓慢变化维表数据装载
　　每天将所有变化过的维度信息刷新到数据仓库中，维表数据的刷新必须现于事实表。

第二步: 事实表数据装载阶段
　　每天新增事实数据的导入，如同初始化导入一样，需要考虑任务之间的先后顺序。

第三步: 数据汇总和聚合
　　根据设定的聚合规则和时间段对数据进行聚合。

第四步: 作业调度和异常情况处理


五、任务调度策略
驱动策略
前导Job驱动：只有满足另外一个JOB成功后，自己才运行。文件驱动：当下传的文件到达，并经过检验准确后JOB才运行。时间驱动：当到达某个时点时，Job便开始运行。事件驱动：如人工参与，导致JOB执行。
通知设计：重要信息（成功/失败）的通知
1、成功退出
　　分段提交方式，当分段提交的当次任务都正确完成，即Job运行状态临时表中登记的作业状态全部为完成时，退出ETL调度。
　　自动提交方式，当当期所有的任务都正确完成，即Job运行状态表中登记的作业状态全部为完成时，退出ETL调度。
2、失败退出
　　关键作业异常，关键作业运行异常时，影响剩下的作业不能运行时，则退出ETL调度。
　　超过ETL时限，当超过预先设定的ETL?时限时，退出ETL调度。
　　数据库异常，当不能正常操作数据库时，退出ETL调度。
　　操作系统异常，当发生操作系统异常，导致程序不能正常运行，如文件系统异常导致读写文件错时，需要退出ETL调度。

3、手工退出，需要人为干预ETL调度的时候，能以手工操作的方式退出ETL调度。

Data Quality Learning Plan

• What 's for
  
• Software Architect
• Data flow concept and Design
• DQ Integration Solution
• Solution Process

Data Integrator -Transform Overview

Operation Code:

Operation codes that describe the status of each row in each data set described by the inputs to and outputs from objects in data flows.

• NORMAL:Creates a new row in the target. All rows in a data set are flagged as NORMAL when they are extracted by a source table or file.
• INSERT:Rows can be flagged as INSERT by the Table_Comparison transform to indicate that a change occurred in a data set as compared with an earlier image of the same data set. The Map_Operation transform can also produce rows flagged as INSERT. Only History_Preserving and Key_Generation transforms can accept data sets with rows flagged as INSERT as input.
• DELETE:Rows can be flagged as DELETE in the Map_Operation and Table Comparison transforms. Only the History_Preserving transform with the Preserve delete row(s) as update row(s) option selected, can accept data sets with rows flagged as DELETE.
• UPDATE: Overwrites an existing row in the target table. Rows can be flagged as UPDATE by the Table_Comparison transform to indicate that a change occurred in a data set as compared with an earlier image of the same data set. The Map_Operation transform can also produce rows flagged as UPDATE. Only History_Preserving and Key_Generation transforms can accept data sets with rows flagged as UPDATE as input.

总结：Operators 与transform的关系分2种，产生与接受。Operators主要用于，根据2个data source的不同，来执行操作。主要用于CDC。CDC分成2种，一种是perserving：可以由 History_Preserving 来处理，还有就是MAP_CDC。或者自由处理，MAP_Operation.

Descriptions of transforms:

处理分支/合并结构的:

• Case: Simplifies branch logic in data flows by consolidating case or decision making logic in one transform. Paths are defined in an expression table.
• Data_Transfer:Allows a data flow to split its processing into two sub data flows and push down resource-consuming operations to the database server.
• Merge: Unifies rows from two or more sources into a single target.

生成新的一列：

• Date_Generation: Generates a column filled with date values based on the start and
  end dates and increment that you provide.
• Effective_Date: Generates an additional “effective to” column based on the primary
  key’s “effective date.” ???
• Key_Generation:Generates new keys for source data, starting from a value based on existing keys in the table you specify.
• Row_Generation: Generates a column filled with int values starting at zero and incrementing by one to the end value you。

对当前Schema进行转换的：

• Hierarchy_Flattening: Flattens hierarchical data into relational tables so that it can
  participate in a star schema. Hierarchy flattening can be both vertical and horizontal. ???
• Pivot (Columns to Rows): Rotates the values in specified columns to rows.
• Reverse Pivot (Rows to Columns) :Rotates the values in specified rows to columns.

对目标data操作：

• History_Preserving: Converts rows flagged as UPDATE to UPDATE plus INSERT, so
  that the original values are preserved in the target. You specify in which column to look for updated data. If it receives a DELETE row, this transform can generate an UPDATE row to close the record in the target table.(CDC update的另外一种方式)
• Map_CDC_Operation: While commonly used to support relational or mainframe changed data capture, this transform supports any data stream if its input requirements are met. Sorts input data, maps output data, and resolves before- and after-images for UPDATE rows.
• Map_Operation: Allows conversions between operation codes (map UPDATE to
  INSERT) on data sets to produce the desired output.

对Source data 进行筛选/甄别

• Query:Retrieves a data set that satisfies conditions that you specify. A query transform is similar to a SQL SELECT statement.
• Table_Comparison:Compares two data sets and produces the difference between
  them as a data set with rows flagged as INSERT, UPDATE or DELETE.

Others:

• SQL: Performs the indicated SQL query operation when it cannot be performed by other built-in transforms.
• Validation: Ensures that the data at any stage in the data flow meets your criteria. You can filter out or replace data that fails your criteria.
• XML_Pipeline: Processes large XML inputs in small batches.

Data Integrator Get Started Note (1)

DI Architect Overview

Overview of Standard Data Integrator

• Data Integrator Designer : to create applications containing work flows
  
• Data Integrator repository: a set of tables that hold user-created and predefined system objects, source and target metadata, and transformation rules, 2 types: local repository & central repository.
• Data Integrator Job Server :starts the data movement engine that integrates data from multiple heterogeneous sources, performs complex data transformations, and manages extractions and transactions from ERP systems and other sources. 2 modes batch or real-time mode.
  
• Data Integrator engine :processes to perform data extraction, transformation, and movement.
• Data Integrator Access Server: real-time, request-reply message broker that collects
  message requests, routes them to a real-time service, and delivers a message reply within a user-specified time frame.
• Data Integrator Administrator : provides browser-based administration of Data Integrator. Resources including:
  • Scheduling, monitoring, and executing batch jobs
  • Configuring, starting, and stopping real-time services
  • Configuring Job Server, Access Server, and repository usage
  • Configuring and managing adapters
  • Managing users
  • Publishing batch jobs and real-time services via Web services
• Data Integrator Metadata Reports applications : provide four applications for exploring your metadata:
  
  • Impact and lineage analysis
  • Operational dashboards
  • Auto documentation
  • Data validation
    
• Data Integrator Metadata Integrator :seamlessly share metadata with Business Objects Intelligence products.

• Data Integrator Web Server
  
• Data Integrator Service
• Data Integrator SNMP Agent: Simple network management protocol (SNMP) support.
• Data Integrator Adapter SDK
• Reading, writing, and request-reply from Data Integrator to other systems
• Request-reply from other systems to Data Integrator
  

Data Integrator distributed architecture



Data Integrator System Configuration

Data Integrator Bin/config investigation

昨天不小心非法了DI，然后就起不来了。：（折腾一上午终于搞定，排障过程如下：
1.Investigate Log files and notice log\Errorlog.txt提示说找不到DICodePages.txt.
2.为了确认报错的确是由client启动未遂造成的，将其备份，清空 reproduce，成功。
3.比较bin\下面的file,发现所有的*.txt均不见了。
List 如下：

• DICodepages.txt
• DILanguages.txt
• DITerritories.txt
• DSConfig.txt (Configuration information! Important!)
• Job Server Configuration
• SNMP Configuration
• Repository Configuration.
  
• errormsg.txt
• jsConfig.txt
• MLMessages.txt
• tracemsg.txt

之后，Client, Server 都可以work了，真是奇怪。这些文件，貌似除了config是可以修改的，其他都应该是只读的呀。

启动了Client开始编辑以后，发现这些file已经被改名为数字文件(1.txt,2.txt,3.txt etc....)，难道一定要用这种方式进行读写么？

然后，就发现，其实，是我在文件名称的时候，不小心把他们都改了，一定是因为他们在root目录下进行的，So,之后就演变成为绝对路径和相对路径的问题了。哈哈。真是诡异呀。

后记：最终的原因是我的脚本有一个循环修改file名字的步骤。但是它又没有找到制定的文件夹，所以，就在bin文件夹下面的(*.txt)进行了循环修改，导致了上述错误。fix了DI job以后，一切正常。不过，由此发现一件事情，就是DI 难道不支持多语言版本么？Error info居然就这样在Bin文件夹下面裸奔......实在有点无语。

Data Integrator Log Investigation

Root of Log

• $InstallFolder\Log

Folder Structure
ROOT

• \BulkLoader
• \Mataexchange
• \$PCache: Data Cache from Server, also configure the place on Server Manager.
  
• \$JobServer1
• \$JobServer2...
• WebServices.log
• inslog.txt(for install information)
• errorlog.txt
• monitor.txt
• Service_eventlog.txt
• AL_RWJobLauncherLog.txt (Job server launcher)
• Tracelog.txt (trace info?)
• Server_configlog.txt (Server configuration update log via Server Manager)
• Statistics log — A list of each step in the job, the number of rows processed by that step, and the time required to complete the operation.
  
  

More Details for logs.

• errorlog.txt: A list of any errors produced by the RDBMS, Data Integrator, or the computer operating system during the job execution. e.g. Error Number <80101>...Error message
• service_eventlog.txt: tracks server starts events. e.g.[Wed Jul 30 16:03:05 2008 ] Job Server on DataIntegratorJobServer1 Port 3500 is started.[Wed Jul 30 16:03:05 2008 ] SNMP Agent on Broker Port 4001 is started.[Sat Aug 09 12:27:58 2008 ] Quit Job Service...
• Monitor.txt : A list of the job steps in the order they started. +di_job_al_mach_info/di_df_al_mach_info_1/Query, READY, 0, 0.000, 7.559-di_job_al_mach_info/di_df_al_mach_info_1/$di_machFileName, READY, 0, 0.000, N di_job_al_mach_info|DATAFLOW di_df_al_mach_info
• AL_RWJobLauncherLog.txt: (Job server launcher) :09_03_2008 23:00:00 CRWJobLauncherApp::InitInstance called.09_03_2008 23:00:00 BODI-1250134: Launching Job (no wait, no status). INET ADDR , GUID .