新浪博客

【转载】【TM1 科普】TM1组件介绍: Real-time OLAP Engine

2012-03-15 23:55阅读：

http://blog.sina.cn/dpool/blog/u/1855958547

原文作者：lingo 文章来源： http://www.cognoschina.net/club/thread-2947-1-1.html 整理后转帖
之前谈了TM1的起源，接下来让我们聊聊TM1的几个主要组件，以及它们的特点:
- Real-time OLAP Engine – TM1 Server
- 全面的ETL 工具 – TM1 Turbo Integrator
- 强大的Excel 客户端 – TM1 Perspectives / Client
- 灵活快速的Web界面 – TM1 EV + TM1 Web
TM1的组件介绍: Real-time OLAP Engine
1) Speed, Speed and Speed
都说TM1快，到底有多快？很快！很多人用惯了Hyperi
on或者其他OLAP Server很不习惯TM1，Load完数据，老觉得缺点社么，因为TM1是real-time 实时的，不需要pre-calc，就可以直接看结果。不过这个Real-Time的概念是只计算是Real-time的 (后面会详细解释什么是实时计算)，query 报表还是要花时间的，不过仍旧很快, 通常<1s，少数大的Cube View可能<5s，有一这边的朋友，给一个Retail做了一个特变态的Report有1m+ Rows 仍旧10s多一点。
快有什么好处？一个快的OLAP Server可以把分析应用做的更快，更好用，或者同样速度/性能，更廉价。一个OLAP如果快到TM1这样: Real-time，就不仅仅是”好与坏”,”好与更好”的问题了，而是”能与不能”的区别。你可以用TM1完成以前你不能做，甚至无法想象的工作，特别是在复杂模型的Forecasting, Planning, Budgeting (中文说计划预算，我觉得不够准确，很多时候Planning其实是只公司的战略规划)。空口无凭，可能一些具体的例子可以帮助大家理解：
零模型，简单的手工输入，各部门，分公司手工录入未来1～3年Revenue, Expenses, Profit etc. 然后用OLAP Server进行汇总计算，不存在业务模型。这个简单，Excel都可以做，OLAP的工具更不在话下，大部分都可以实现实时汇总，有的还可以做 Spreading，例如把全年预算push到个个月，可以相等，可以按照一定增长率，或者高级一点按照去年的Actual. Hyperion Planning & Cognos Planning 这些都没问题，Cognos Planning还可以Highlight变化的预测。
初级、中级模型，还是各部门/公司输入，不过不直接输入最后的Financial Results，而是Drivers。简单的例子是，输入预测的销售量，单价 (根据不同产品、市场)，OLAP Server自动计算出销售额，毛利等。复杂一点，销售量又是由市场投入，销售人员，多少客户，每个客户明年的预测决定的；而单价又是由渠道，折扣，返点 决定的。以此类推，可以建立一个以Driver驱动的预测模型，而用户预测输入的则是比较贴近实际的指标。奇特的是这方面的应用仍旧是Excel为主 (即使是在国外)，其他业务模型方面的原因不谈，只谈OLAP Server能力方面，在每次改变Driver后，大多数OLAP需要一个计算过程，before看到最终的预测结果。Hyperion 等现在也可以做类似的Driver-based的Planning模型了，不过计算速度嘛……而这对于TM1来说就太初级了，TM1是实时出结果的。
高级Driver-Based Forecasting、Planning模型，举个最近做的案例: 一个大型工程承包公司的战略计划模型(在中国，像中国建设总公司这样的单位)。

计划预算是从单个项目开始的，每一个项目有很多Drivers (总金额，成本，周期…)，通过对以往项目的分析，为不同类型的项目建立了成本曲线(核心业务模型)，然后TM1算出单个项目目每月的Financial Result，再乘以项目的成功率(probability %)，因为这是预测可能回到手的项目。
然后把若干百个项目(project portfolio)的结果汇总到公司，再加上公司一级的Drivers: 主要是公司运营费用的预测，公司调整，TM1算出整个公司的Financial Results。
然后把若干个公司的结果汇总到总公司，然后集团总部，再加上各级的Drivers: 主要是各级运营费用的预测，调整，TM1算出整个集团的Financial Results。
如果想让所有的项目经理输入基本参数，CFO在集团总部立刻看到结果，可不是那么简单的了，这是因为整套模型的运算量太大了。比如通过成本曲线计算每月财 务数据，需要为每一个项目建立两个个6次方的方程进行收入和利润的模拟。如果有1000个项目就是2000个6次方程……..但是实时计算又是非常重要 的，因为除了单纯的汇总外，还可以对预测计划结果进行Sensitivity的分析，例如What-if一个很重要的项目要延长一年，what-if所有 铁路项目的成功率降低50%，what-if 所有商用公寓的项目成本增加30%等….如果是实时的，各级用户可以轻松的根据各种市场因素、内部因素建立若干不同的Scenario（情景）分析，从而 真正达到strategic planning (战略计划) 的目的。
这回市面上绝大部分OLAP服务器(除了TM1)都不行了。记得3年前用Hyperion Essbase做了一个人力资源的分析模型，每次都是星期五下午按钮开始算，等礼拜一回来看结果对不对，再从新调整模型，在等星期五….前前后后折腾了2 个多月….唉，别说让别人用了，就是开发都难呀…
希望一番叙述后，大家对TM1的实时计算特性，还有为什么OLAP快很重要有所了解。OLAPReport年年都做用户调查， 发现OLAP server的performance与BI项目实施成功率成正比，MOLAP比ROLAP快，RAM-based比Disk-based快，快的实施成 功率高，可能是更容易让用户接受。另一方面，所有OLAP用户抱怨最多的不是功能，不是易用性，而是Performance。我觉得这个更有启发，更能再 好在全，不使用，不实用，难使用，也是枉然。
下次说说，为什么TM1 OLAP Engine 可以做的这么快，为什么其他厂商不行？
TM1的组件介绍: Real-time OLAP Engine
2) In-Memory MOLAP 架构
TM1的组件介绍: Real-timeOLAP Engine
2) In-Memory MOLAP架构
为什么TM1可以做到实时计算？因为TM1是 In-Memory 的MOLAP技术。
先说说什么是MOLAP和ROLAP，这是两种最基本的OLAP架构，都是用来实现多维数据的存储、查询和管理。架构的不同，很大程度上造成了最终产品- OLAP Server 不同的技术特性（优点和缺点）。
先看一个最常见最简单的例子，说要分析/预测一个公司的销售情况，要考虑的因素包括：产品、地区、时间，Measure （度量，不知道中文这个准不准确）包括：销售量、销售额、折扣额、实际销售收入等。两种存储方式如下图所示。

2-1.JPG (139.26 KB)
2-1.JPG

ROLAP明显是传统关系型数据库的延伸，引一段英文：This methodology relies onmanipulating the data stored in the relational database to give the appearanceof traditional OLAP's slicing and dicing functionality.翻译过来是通过传统关系型数据库的Table来“伪造”OLAP技术中的切片和切块。而每一次slice、dice就是一条SQL语句查询。
MOLAP则是彻底颠覆了传统关系型数据库的Table的概念，取而代之的是多维度CUBE（立方体，很不习惯这个翻译，TM1中文版的翻译更无法忍受：多维数据集）。数据是存储在CUBE的每一个Cell中的。
记住这本质的区别，因为之后要讨论的优点缺点全部是由于这根本不同的数据结构造成的。
特性对比表如下：

2-2.JPG (473.92 KB)
2-2.JPG

注：除了MOLAP，ROLAP外还有HOLAP等，服务器的位置也可分为Client和Server端，有兴趣的请参考：http://www.olapreport.com/Architectures.htm
说完了传统MOLAP优势，不过这才说完了TM1为什么这么快原因的一半。汗，多么强的Engine呀….这另一半的原因是in-memory技术。In-memory顾名思义就是所有的Cube都是存储在内存里的，只有在关闭服务器的时候才回写到硬盘上。这个本质的技术区别也是TM1与其他MOLAP产品相比有更多特性的根本原因（注：这次重点在性能，解释为什么快，后面慢慢分章节慢慢讲解其他特性）
In-memory 最近几年随着1）64bit Win Server的普及；2）内存价格下跌；3）BI用户对速度的要求增加；逐渐成为了非常流行的OLAP技术，很多厂商陆续推出相应的产品，SAP，Microsoft，MicroStrategy，QlikView，PALO。可这个怎么能和想比呢TM1？TM1已经发展优化这项技术25年了（详细情况请参阅前面帖子：TM1前世今生）。可以说，在In-MemoryMOLAP领域，现在的TM1 9.4已经非常完善了，9.5 今年11月将面试，又增加了不少新功能。明年年中还有一版更新的，和新版的Cognos BI一起出。
那么到底为什么要in-memory呢？是为了Real-Time results…请看另一张对比表：

2-4.JPG (479.42 KB)
2-4.JPG
其实in-memory的技术是OLAP的鼻祖，最早的OLAP：IBM APL就是主流内存的，我觉得从分析师的角度，这是很自然的，只是后来的发展受到RAM容量和成本的限制，不得不转向Disk-base。现在好了这两点限制都有了质的飞跃，再回到RAM-base 也算是自然回归。下面是两篇扩展阅读，English好的可以试试：
OLAPReport: Commentary: What in-memory BI ‘revolution’?
2009年
http://www.olapreport.com/Comment_InMemBI.htm
澳大利亚Monash 大学Curt A.博士的论文Memory-CentricData Management， 2006年
附件，写得挺好的。不但有OLAP的部分，还有OLTP。举了Amazon怎么实现对二手书数据库100万次每分钟的查询，还有内存数据存储在金融交易市场的应用。
好了现在基本清楚了为什么TM1这么的快，主要是MOLAP + in-memory，尤其是in-memory。后面要陆续介绍的TM1 Server的特性，有很多都是因为in-memory这样独特的技术才有的。
TM1的组件介绍:Real-time OLAP Engine
3) 什么是Multi-cube?
接下来的几段想详细说说一些TM1 Engine区别与其他MOLAP的特点，像前面说过的，这其中很大程度上是得益于其In-Memory的结构特点。另外，在介绍的特性的同时，尽量结合一些实际的例子，来帮助大家理解特性真正的应用价值，想我之前说的，应用的强大才是真正的强大。今天先说说什么是Multi-Cube。
OLAP应用的一个技术概念就是Multi-Dimension多维，因为分析本身就是多维的，所以建立一个有多个分析维度构成的多维数据集：Cube（终于明白TM1中文版的翻译是怎么来得了）就成为了最基本的数据单元
（也可以说是为了特定的目的建立的Data Mart）。而一般来讲一个数据单元涵盖了特定的分析主题，例如销售，利润，人力资源等等。这基本上就是ROLAP中Fact表的概念，一个Fact表就是一个分析的主题。
例如“收入”这个分析主题，可以由：产品，地区，销售代表，时间，Version等维度构成。换句话说，我们可以按不同地区、不同产品、不同销售代表、不同时间做收入的分析。同样的我们也可以按照地区、产品、销售代表、时间做“收入”的预测和计划。现在让我们把这个例子复杂化：把“现有客户数量”和“潜在客户数量”数量也作为销售收入的一个预测因素(driver)。而且这两个指标也是按照，产品、地区分类的。听上去如果我们要做这样的分析，就必须把“客户/潜在客户”作为一个新的维度加到“收入”Cube里。其实这样做的结果实际扩大了“收入”这个分析主题(Cube)的范围，不仅仅销售的分析了，而且有了一些客户的分析。但又达不到真正“客户”详细分析的程度
(例如:按年龄、收入、职业、性别)。
这其实就是Single Cube OLAP架构的一个主要问题，因为各个分析主题是分离的，所以档需要将模型进一步复杂化的时候，往往重复存储相同的数据(例如重复存储客户的信息在“收入”和“客户”Cube里)，重复建立类似的数据结构(客户维度)，在同一个分析主题里(Cube)，也造成了很多的冗余空间。为了包含更多的内容，维度越来越多，Cube 变得更Sparse，为了维持Performance就要优化(可能是为什么会有HOLAP的原因)。所以这是为什么，ROLAP很难建立复杂分析、预算模型的原因，太慢了。而在以单个Cube为基础的MOLAP Engine (例如：Hyperion) 也同样收到很大的限制。
来看看TM1 的Multi-cube的结构，如下图：



3-1.JPG (314.8 KB)
3-1.JPG
Multi-Cube就是为了更复杂的分析或者业务模型，建立一个有多个数据单元或分析主题，而构成的一个更大的数据集市（DataMart），或更复杂的分析主题。比如这个P&L预算的例子。注：仅仅是随手画的，为了说明概念而已，请大家只是意会，不要细究其中的细节，实际项目中的模型可能回更细致。
基本的概念就是，可以自由的按照分析主题设计模型，维度的设计可以非常Specificto主题。之后，各个主题之间相互Feed所需要得信息，作为另一个主题的输入。这样的结果是，1）整个模型结构效率得到了最大的优化，没有重复存储，也不用为了整合两个主题，而牺牲结构或性能；2）设计出来的模型更加贴近分析用户的需要，因为是针对主题的。
为什么TM1能做到这个能，前面说了，主要是In-Memory real-time calc。所以一点变化，牵动全身，所有预测全部更新，这就是What-if的前提。当然，这样的模型也需要更高的建模技巧。如果模型大了，结构设计不好，反而回更慢，这就是TM1 Consultant 通常的工作了。
说到这里似乎要告一段落，不过想借此机会谈谈TM1的后台管理。因为TM1的设计者真可谓深刻的领会这个Multi-Cube的优势，所以许多TM1 Server后台管理的功能也是通过Multi-Cube的特性实现的。个人觉得这个对与建模的设计是非常有启发的。举几个例子：
Cell Security, 前面提到过，TM1是市场上为数不多的可以实现Cell 级别Security 的OLAP Engine。这是通过Cell Security Cube 来实现的。如果你需要对Cell进行控制，系统建立一个CellSecurity Cube，这个Cube拥有和原始Cube一模一样的维度，外加用户组。CellSecurity cube的值就是“READ” or“WRITE”。
之后，每一次的用户“读/写”请求回先通过这个Cube。

3-2.JPG (144.79 KB)
3-2.JPG
沿着这个Cell_Security cube的思路，很容易可以做到对Cell级数据的实时锁定。这个非常在预算的应用里非常实用。其实后来的Cognos TM1 Workflow，就是通过一系统的cube和相应的管理逻辑实现的。

3-3.JPG (150.86 KB)
3-3.JPG
不仅是Cell Security，
TM1这个的后台Security都是由Cube 进行管理的。
另外TM1 还用Cube管理dimension 的attributes, alias；
用户的Status；Content等等。你甚至可以激活TM1自带的一个Performance Log Cube，实时记录24小时内每一秒钟Query的performance by cell, by users, by time，以及内存使用的情况，缓存的设置…..可以说一切的一切都是用Cube管理的。时间长了，真让人不由自主的在怀疑是不是这就是数据未来的存储模式？
下期预告：
TM1的组件介绍:Real-time OLAP Engine
5) Capability& Scalability
最后附上2002年DHL财务预算项目的multi-cube 结构图，就算是一个项目实例吧，不过这个嘛，买2文钱吧......嘿嘿

3-4.JPG (386.54 KB)
售价: 社区金钱 2 C币 [记录]
3-4.JPG
TM1的组件介绍: Real-time OLAP Engine
5) Capability & Scalability
除了前面介绍过的in-memory real-timecalculation 和 Multi-Cube外，再说说其他TM1 OLAP Engine独特的Capability。
►文本存储能力。在构成TM1Cube的dimension中，有3种不同的Element类型，C, N, S。 C是Consolidation element，也就是parent level，N是最底层的element，也就是child level。这两种element都是数字类型的。前面说过了，TM1是in-memory real time calculation，所以，数都是存储在最底层的，也就是N level，而所有的Clevel都是实时计算出来的。这个都是一般的OLAP服务器必备的能力，而S类的element 则是TM1所特有的了，S=String，也就是可以存储文本了，这个从很古老的TM1 ver.7就有了，当时很强，因为很少有OLAP Server/多维数据库，可以存储文本的。后来2008年的9.4就更牛了，去除了255个字符的限制，写整篇文章都可以。有人问了，这个在实际应用中有什么用呀？
举几个例子：
首先，可以用来存储Comments (注释，评论)，比如Variance Analysis，财务经理课业要求各部门解释为什么实际费用高于预算费用，而且这些解释会被记录在案。再比如在做Forecast (预测)和Budget(预算)的时候，财务经理或部门经理可能会作出一定的假设，通货膨胀3%，人员数量不增加，但是工资上调5%等等，这些假设对于完整、精确的理解预测和预算结果非常重要。可能现在很多其他OLAP server也有了这样的功能，但可能只是具体数字、事件驱动的，而不是和原始数据一同存储的。TM1比较牛的是文本和原始数据可以存储在同一个Cube里。而更可怕的是TM1可以对Cube中的每一个Cell进行注释，方法是建立一个一模一样的注释cube，again 这是multi-cube的好处。
其次，文本可以用来构建下拉菜单，比如说进行固定资产的资本预算。可以用文本类型的element存储“资产类别”。而通过TM1的实时计算特性，可以把这个“资产类别”的下拉菜单与“资产类别”的dimension动态的连接起来，实现自动更新。而在即将推出的TM1 9.5中，在WebCube View 界面里，就可以实现in-cell dropdown list. 在实际应用中，可能允许用户先选择资产类别，系统根据选择的资产类别，自动选择可能的折旧算法/公式，然后再利用TM1强大的实时计算建模能力，根据资产的价值，和折旧公式，算出未来的cash flow.
再次，文本可以用来做对特定的指标进行状态显示和预警。简单的，比如在项目进程管理中，根据实际完成的价值，和项目的总价值，自动分析出项目的进展阶段，然后显示出项目的状态。复杂的，可以针对特定的KPI指标设计预警范围，然后显示相应的预警信息。如果需要，甚至可以做到针对不同的用户，提供不同的信息，引外用户，在TM1中无非就是 another dimension。
另外，文本还可用于对绩效管理的workflow(工作流程)进行管理，比如预算过程。其实TM1自带的Workflow模块就用到了很多文本信息，而且都是存在Cube里的。
►Write-back (回写) 能力。这个对于一个planning/budgeting的产品来说，这基本上是必须的。但是与其他planning/budgeting产品不同的是TM1内置了很多高级输入方式，在TM1里叫Spreading，这个主要帮助用户更加快速的输入预算信息。方法是允许用户在层级结构(hierarchy)的顶端进行输入。比如预测未来一年的办公费用，用户可以估算出整个公司的预算是100万，TM1会自动的，由上至下的将这100万按比例的分配个个各部门（根据前一年的实际花费）。整个过程也是实时的，或几秒钟如果数据量非常大的话。Again这又是充分利用了in-memory real time 的特性，只有计算是实时的情况下，这样的Spreading才可能实现。
相比较而言，其他产品由于不是实时计算(一般是Batch计算)，就要求预算数据必须是由下至上的逐级录入，费时费力。完成全部输入后，才能够进行Batch计算，计算完成后才能进行报表。Hyperion就是这样的典型，不过Hyperion Essbase 9好像有所改进，不过似乎能够实时计算的功能受到很大程度的限制，比如，如果选择实时计算(aggregation模式)，模型就不能包含复杂业务逻辑，只能做最简单的汇总等等。
下面是TM1支持的Spreading功能，用户手册中专门有一个章节介绍这个(很不习惯中文版的翻译，反而还是英文版的看着比较容易理解)：

2-1.JPG (190.16 KB)
2-1.JPG
►对ODBO和MDX的支持。虽然微软在BI产品上，除了MS SQL ServerAnalytic Services外的其他尝试都以失败告终，ODBO和MDX的认可程度还是比较高的。我的理解是MS的产品大多数还是面向开发者的，而传统的BI/PM产品的思路越来越多是面向业务用户或是分析师的了。ODBO和MDX则是基本上打开了对于微软支持的大门。现在主流的OLAP工具基本上都支持。
ODBO支持，基本上是说只要是支持ODBO作为数据源的BI前端展现工具都可以使用TM1作为后端OLAP服务器。举个极端的例子，比如Excel中的Pivotal Table就可以用TM1作为数据源，当然TM1自己的Excel客户端要比PivotalTable好得多。不过对于非常非常熟悉Pivotal Table的人来说，可能是一个了解TM1的好机会。另外在Visio2007据说也加入了对ODBO多维数据库的支持，可以自动生成类似于“成因树”的KPI图表。另外一个比较实用的功能是，由于ODBO的支持，可以用微软的MDX调试工具对TM1中的MDX进行调试。如下图：

2-2.JPG (165.16 KB)
2-2.JPG
接下来就是对MDX的支持。这个主要有两个作用。
一个是Dynamic Subset (动态列表)，主要用途有：a) TOP X or BOTTOM X，
比如最赚钱的10个客户，毛利最高的10个产品；b)排序，比如客户列表按照单月销售额；c)过滤，比如所有营业额大于2m的门市部；….还有很多其他更加复杂的应用。总而言之，从前比较复杂的分析和查询，可以通过简单的MDX建成在一个Dimension里的Dynamic Subset，用的时候就直接用了。当TM1在ver 8.4中第一次介绍这个功能的时候，原来很多的报表、分析模型大大被简化了，几天几个星期的工作，变成了几分钟了。
另一个是Dynamic View, 主要是用在以微软开发平台的开发工具上的，比如.net 或者是ExcelVBA。可以对cube进行查询，返回整个view。
特别适用于“巨大”查询，比如几百万条记录的报表。不过后来TM1买了EV后，EV要更容易用。
►对unicode的支持。从9.4版后TM1服务器是完全支持unicode的了，也就是说理论上可以完美的支持双字节的亚洲文字，乃至世界上任何一种文字。不过任何数据库被转换成unicode后就没法再转换回原来的模式了。也就是说一旦升级到9.4后，就只能跟着IBM往前走了。不过幸好跟的是IBM…对于新用户问题不大。
由于可以为dimension中的Element 建立 Alias（别名），所以可以实现多语言的名称，特别适用于跨国公司。
►强大的Log。一直以为TM1 Server的日志功能算是非常强大的，而且还在进一步提高中。首先TM1最开始是为了满足财务/金融分析的需要进行设计的，而且最早就是为了计划预算(具备回写能力)功能设计的，所以任何对Cube中的数据的操作，都会被记录，when, who made what change，称之为Transaction Log。这个有什么用呢？
首先，是从audit trial的角度，保证了数据的准确性，可追溯性，特别适用与公司重要的财务、销售信息。特别适用与交互性极强的预算流程。
其次，对于灾难恢复有重大意义。记得前不久，系统管理员搞丢了一部分关键数据，但是有不能简单的从备份里恢复，因为其他部分的数据有了新的正确的更新。但借助Transactionlog, 管理员可以选择所有错误的操作，然后Back out。（TM1自带一个不错的log查询工具，可以做很多筛选）
再次，由于实时记录transaction log，所以TM1几乎不会因为系统故障丢失任何信息。缺省设置，在启动TM1服务的时候，系统会根据transaction log自动回复server crash 之前未来得及存入硬盘的数据。
最新的TM1 server，不但对业务数据有Transaction Log，
对metadata也有log了。就是说可以记录cube, dimension, element 等变化。
►分布式服务器架构，同步服务
TM1还支持分布式的应用模式，并且提供Replication的功能。举例来说，对于大型的分布式的企业，可能在本地设置分析数据模型，会提供更好的性能、支持。而且也可以把海量的数据分割成局部的数据。
Replication可以对数据进行增量同步，还可以同步数据结构，比如：新的cube，新的dimension，新的hierarchy等等。
►跨平台的支持
TM1几乎可以运行在任何操作系统上，从Windows2K/XP，Windows Vista个人电脑，到Windows Server，再到Linux, Unix(HP, SUN, AIX)。TM1很早就支持UNIX了，毫无疑问，对于一个一开始就定位于In-Memory的OLAP服务器，对于UNIX的支持至关重要。
最新的进展是，IBM正在将TM1放在它的mainframe，z系列上，这就意味着TM1的服务器将拥有TB级Meomory，最顶级的并发处理能力和计算能力。这个将是TM1的又一big step forward。在我看来有可能是量变到质变的转变。
最近IBM又收购了SPSS，在“smart planet”的战略上又迈出了一大步，而TM1，作为市场上最强有力的OLAP引擎，毫无疑问将会在IBM未来的“Smart Plant” 中扮演重要的角色。
我想到此TM1的主要模块，OLAP服务器的介绍就告一段落了。后面会尽量抽一些时间，继续其他模块的介绍，比如：
-
全面的ETL 工具
– TM1 TurboIntegrator
-
强大的Excel 客户端
– TM1Perspectives / Client
-
灵活快速的Web界面
– TM1 EV + TM1Web

我的更多文章

下载客户端阅读体验更佳

APP专享