开源BI向我们走来

DW (MYSQL, PostgreSQL)
| ETL (SP or Kettle)
BIRT JASPER JPivot based on Mondrian (olap server) Dashboard
|______|____________|___________________________________|
SOLUTION ENGINE (SOLUTION ENGINE)
|
JBOSS AS & PORTAL
|
Web browser

采用该方案整体TCO要低很多，想想对应工具厂商的license，不好的地方也显而易见，决策者得有点胆子，实施者得有点能力。个人觉得可以面向零售业（便利店总店、超市等等）等业务模式固定的行业，将相关的业务分析和报表封装成固定的内容，搞成产品的形式进行推广比较有搞头，南美有个小公司就是靠以色列的一个小BI工具在零售业卖BI“产品”挣了大钱，以上公司均不署名，信之则有，:-)。

下次聊聊PENTAHO的solution engine，有点意思的，也许是dashboard模块，等我看完再说，呵呵。

Jeasonzhao
20060304

MYSQL和PostgreSQL我用的很少，理论上应该支持不了大量的数据，即使是零售业，沉淀的数据也是可怖的，这样的数据库能不能支撑啊。

开源固然是好事，但是我想构架最终结果还是体现应用上，如果效率不行，什么也不管用。客户花上大量的时间在等待报表生成上，100％项目是要闹翻天。所以我对开源的BI保持一种欣赏的态度，开源BI还是有待成熟。

另外，楼上提到针对性优化数据库，而且两个数据库都是开源的，存储的IO瓶颈可如何是好？如果支持商业大型数据库，我想路会宽阔些，至少抛除IO的顾虑。

Dumpedjoe
20060306

硬件处理器：基于双核64位AMD Opteron服务器群
内存： 8GB
操作系统：SUSE LINUX Enterprise Server 8
数据库系统：MySQL Database Server
业务生产开发语言： PHP
数据存储方式：日立公司的存储区域网路产品 HitachiSAN
负载均衡工具：Netscaler
设计的数据库容量：7.3Terabytes，超过1亿条记录，超过100张的数据库表。

http://tech.ccidnet.com/art/309/20031218/76491.html

从字面意思理解总会有偏颇，还是找一个切入点哪怕是稍微了解一下也好。

BI&DW
20060307

Open source BI&DW tools:
ETL:
• Kettle ETL tool
• MySQL Stored Procedures
Database:
• MySQL 5
BI Server / Dashboard:
• Pentaho BI Server
• It integrates all the different products into a single architecture
Application Server / Portal:
• JBoss AS
• JBoss Portal
OLAP
• Server: Mondrian.
• Viewer: JPivot (Web Based)
Reporting:
• Operational Reports: Jasper Reports & BIRT
• Embeddable reports and charts: JFree

再谈谈ODS

丁西宁
20060305

摘一段Kimball的文章：

The four systems are:
" Production (source) transaction processing systems
" Data warehouse staging area systems
" Data warehouse presentation systems, including client/server and Web-based query tools and report writers
" Optional high-end analytic tools supporting data mining, forecasting, scoring, or allocating.

The first system for which the data warehouse is responsible is the data staging area, where production data from many sources is brought in, cleaned, conformed, combined, and ultimately delivered to the data warehouse presentation systems. Much has been written about the crucial extract-transform-load (ETL) steps in the staging area, but stepping away from this detail, the main requirement for the staging area is that it is off limits to all final data warehouse clients. The staging area is exactly like the kitchen in a restaurant. The kitchen is a busy, even dangerous, place filled with sharp knives and hot liquids. The cooks are busy, focused on the task of preparing the food. It just isn’t appropriate to allow diners into a professional kitchen or allow the cooks to be distracted with the very separate issues of the fine dining experience. In data warehouse terms, by barring all data warehouse clients from the data staging area, we avoid:
" Guaranteeing up-time service levels for querying or reporting
" Enforcing client-level security
" Building performance-enhancing indexes and aggregations for query performance
" Handling logical and physical conflicts between the querying and data cleaning steps
" Guaranteeing consistency across separate, asynchronous data sources.
The two dominant data structures in the data staging area are the flat file and the entity/relationship schema, which are directly extracted or derived from the production systems. Almost all processing in the staging area is either sorting or simple sequential processing.

上面是Kimball关于数据仓库架构的分析，他把数据仓库定义为四个层次：

" 数据源(oltp)
" 数据缓冲层(staging area)
" 数据展现层(presentation area)
" 应用数据挖掘工具的数据分析层

对于staging area的定义，认为在staging area只负责数据的准备（ETL），应该避免任何直接的访问。想起曾经在ttnn上讨论的关于ODS的话题，ODS的作用是什么？在ODS上我们要实现什么功能？一种是认为ODS上只负责ETL，代表是innovate511；一种认为除了ETL，还可以进行数据的查询（查询是指从客户的数据展现需求中剥离出来的，属于查询类的那部分需求），很多人这样认为。不管是否少数服从多数，也不管Kimball说的话就一定适应我们的现状，我想我们讨论的目的是为了对数据仓库架构有更深入的理解。

上述考虑应该是从功能上进行的分类，力求每一个部分完成各自的功能，因为功能不同会导致数据结构不同，设计方法不同。

Kimball认为：

" 数据抽取（清洗）和数据查询这两种不同的功能，不应该放在数据缓冲层同时进行。
" 数据缓冲层不应该进行为了查询优化而进行的索引、汇总这样的操作。
" 数据缓冲层中的数据结构只应该包括和OLTP一样的实体和非关系型的文件。

这样在设计上才不至于混乱不清。

那么如何在物理上实现数据缓冲层呢？综上的分析，数据应该有三种用途：

" 用来进行清洗、转换，用来多个不同数据源之间的数据进行整合；
" 用来进行日常的查询（既明确的业务查询）；
" 用来进行分析；

用来进行分析的数据肯定是放在DM中，这个不会有疑义的，那么其他两种呢？是都放在ODS中，还是把第二种也和第三种放在一起？不如再分一层，姑且叫做ODS2，这一层数据是为了第二种查询准备的。Innovate511不也说过分层或者分模块是比较好的方式吗？我们在一个项目里面就是这么设计的。

Innovate
呵呵，其实也不用太扣概念，从现实项目中你自己都可以发现，用来缓冲的数据肯定不能担负查询的责任，原因以前已经讲过了，就不多说了。至于查询，可以放到和DM并列的一层去，数据源来自DW层的conform table，这些数据是完整的、ETL处理好的优质数据，可以不用关联就可以查询到很多他们想要的主题，甚至超出他们的想象，只要分析能分析的主题，他们就能把相关主题感兴趣的信息查询出来，用于客户拜访、挽留、收账、准客户跟踪等多种事情。试想从ODS出来，没有经过ETL、conform的信息，能给客户多少信息呢？所以建议查询的数据源和DM一致，让客户能分析出什么，就能查询出什么。

BI&DW
20060307
我理解的就是，如果是使用ETL tool来实现ETL处理，那么Staging Area就存在于Load Data into DW之前，如果借助Relational Database来实现ETL处理，那么Staging Area就存在于Load Data into DW之后。

Innovate
20060307
不错，工具确实可以帮助我们处理一些清洗、整理的工作。就staging area而言，并没有定论，不是说一个项目就那么一个staging area就行了。比如为了增加灵活性，DM层里面有大量来自DW的conform tables，这些tables也算是一个staging area。

Jerome
20060317

看了大家关于ods的讨论很感兴趣，也乱说两句，见笑了。

正如关于数据仓库的架构有两种方式一样，对于ods（operational data store）也存在着两种观点。

从Inmon的corporate information factory架构来说，ods是介于集成转换层（integrated and transformation）和数据仓库（data warehouse）之间的。集成转换层实现数据的etl过程，不对用户提供接口。 ods的的定义是：面向主题的，集成的，可变的，反映当前数据值的，详细的。 前两个特征和数据仓库是一样的，但是ods是可以更新的，保存原子数据，一般保存几天到几个月的数据，这三点和数据仓库有很大的不同。 ods的输入是集成转换层，输出是数据仓库、交易访问和dss处理，是对用户可以直接访问的。 由于ods要同时处理大批量装载、更新、交易访问和dss处理，它是实现其实是非常困难的。

从kimball的multidimensional architecture架构来说，kimball认为ods应该放在data staging area 和data warehouse之间的第三个物理存储区，或者作为data warehouse的一个特殊部分。 这里需要指出，ods和data staging area是两回事，data staging area是不对用户提供访问服务的，而ods需要是对用户提供访问服务的。

kimball指出ods有两种用途，一种是对操作数据出报告，是定制好的查询，直接写好sql。另一种是提供近乎实时的数据时使用。

总的来说，ods和数据处理的过程不在一起，不管是集成转换层还是data staging area，而应该是一个独立的数据仓库架构中的部件。它的实现是非常困难的，而且不是必须的，没有特殊的需要一般是不必实现的，而且现实中大家也基本都没有做这¬部分。 个人感觉，kimball是不推荐实现ods的。可能是因为ods是inmon先下好的定义。：）

个人比较赞同innovate511的观点，如果把ods三个字母换成data staging area三个单词的话，大家实际做的东西都差不多，只是名称有点乱。

ods我们可以在有特殊需求的时候再来实现。

刘庆
20060317

哈哈，jerome说得好，这段关于操作型存储的介绍也是简洁明了。

从一个实际情况来看看。

以前，我们大多的项目设计的操作型存储层中，是将数据源的表结构照搬过来，但在这一层面处理数据的维度转换和清洗工作。维度转化是因为曾经使用了大量的代理键（¬后来发现不必要，但已经很难改正矣），清洗工作是保证在这个层面数据都已经转换成数据仓库认可的数据质量，也就是说，对主键、外键、字段非法等问题，都在这一层¬清理掉，要不拒绝，要不转换成特定的代码，如"未知"。
原来设想的操作型存储层的目的确实是为了满足即席查询那种诸如名单、详单之类的统计，不过很长一段时间里面。它的作用是混乱的，一方面因为数据仓库层有时候不能¬满足统计需求，一方面因为大家对整体数据仓库的结构有些不明了。

于是很多可以从数据仓库层出的数据都直接从操作型存储中统计。如此，确实造成很多不必要的重复工作，例如一个统计各地市收入的需求，明明数据仓库层就有这个数据¬，统计好了放在那里，可有人还是愿意从明细的帐单表中汇总一遍。

后来决定将层次要分清楚，能够不从操作型存储出的数据就不出，尽量根据需求在数据仓库层汇总好。这样，基本上能够满足大部分的统计需求。当然对于某些特定的应用¬，诸如挖掘，还是得从操作型存储取数，构成自己的挖掘集市。然而即便如此，发现对操作型存储的访问其实大大减少了，例如详单，总觉得将它转换放在表里面没什么作¬用，反而是浪费转换装载的时间。正好我们采用的是接口文件，于是干脆也不转换，直接保存详单文件，如果需要统计的话，直接用文件建立一个外部表。如此，操作型存¬储几乎就演变成了数据装载区。

这种应该算作是球派的做法，数据装载区和操作型存储的区分模糊。

在我理解的郁闷派的操作型存储，不一样。在郁先生提出的理论中，操作型存储层要对企业业务模型进行重构，采用第三范式（而球派还是建议采用维度建模）的方式构建¬此层模型。因此，他的操作型存储也就是一个非常大的、理想的模型，这也符合此派自上而下的理念。很多大公司，诸如十八摸、恩西阿都愿意这样干，因为他们自认为有¬能力自上而下去构建整个数据仓库，因此这些公司都有自己的概念模型，提出诸如参与方、产品、资源等实体。然而在国内很多实际项目当中，这些概念模型变成一种幌子¬，根本就无能力去自上而下去设计模型，还是落得个将数据源的表对应到操作型存储的局面，悲哀啊。

Jerome
20060318

kimball在他的工具箱一书中讲解了实时分区（real-time partitions）的设计。
实时分区的引入是因为用户有近乎实时的需求。 在md架构中，这个实时分区是与数据仓库在物理上分开的存储区域， 是能够支持特殊更新和查询的独立的表。 这个实时分区内保留数据仓库最近一次更新后到当前时刻的所有行为。 这个实时分区的表结构与数据仓库中的表结构在粒度和内容上要尽可能的相同， 因为会把这个表的内容和数据仓库的内容联合查询使用。 针对维度建模中三种不同类型的事实表，实时分区有不同的实现方式。

1）transaction facts
对于操作型事实表，实时分区中只保留上次更新后的事务操作信息， 在下次更新时清空。由于只保留一天（通常数据仓库更新周期为一天）的数据， 出于查询性能的要求可以将这部分内容装载在内存中。

2)periodic snapshot facts
对于周期快照型事实表，按周期粒度来保留实时分区中的数据，也可加载在内存中。

3)accumulating snapshot facts

对于累积快照型事实表，按数据仓库的刷新周期来保留数据。 但是与操作型事实表不同的是，累积快照表中的记录可能在实时分区和数据仓库中都存在， 这时需要按主键进行更新。可加载到内存中。

总的来说，实时分区保留数据仓库最近更新后的行为，可以驻留在内存中，同时满足更新和查询两方面的性能要求。 这个实时分区和通常的数据仓库联合在一起就是实时的数据仓库。

kimball的实时分区设计，几乎从所有的要点上满足inmon对ods的定义：面向主题的、集成的、可变的、反映当前数据值的、详细的。 至于它在概念上是否就叫ods，我觉得，kimball比较回避这个问题， 只是说如果需要建立ods的话，支持实时的交互操作是一种情况（另一种情况是提供操作数据的固定查询）。 另外，inmon在96年出版的building the operational data store中就给ods下了定义。 不过在inmon的cif架构中，数据仓库是不用更新的，只是向里添加快照，而kimball的md架构中数据仓库是可以更新的。

其实从我们来说，只要知道实际是什么样的东西就行了。实时数据仓库也是很难实现的，难点在staging area。 要保证近乎实时的话，staging area就没有时间进行复杂的处理。 如果数据源情况较复杂的话，时间上很难保证。