淘宝数据魔方技术架构解析

（本文首发于《程序员》8月刊，略有调整。你可通过pengchun#taobao.com联系到作者。） 淘宝网拥有国内最具商业价值的海量数据。截至当前，每天有超过30亿的店铺、商品浏览记录，10亿在线商品数，上千万的成交、收藏和评价数据。如何从这些数据中挖掘出真正的商业价值，进而帮助淘宝、商家进行企业的数据化运营，帮助消费者进行理性的购物决策，是淘宝数据平台与产品部的使命。 为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。尽管从业务层面来讲，数据产品的研发难度并不高；但在“海量”的限定下，数据产品的计算、存储和检索难度陡然上升。本文将以数据魔方为例，向大家介绍淘宝在海量数据产品技术架构方面的探索。

基于二次开发的MSTR缓存准实时刷新程序实现

背景 在mstr报表中，对于那些大数据量的报表，为减少用户等待时间，我们通常都会以启用报表缓存来优化执行。但在大型的数据仓库项目中，由于存在大量的报表，复杂的业务、关联关系、计算口径，常常会有大量的ETL任务，这样就会导致：1:事实表每日被刷新完成的时间不固定；2:一张事实表一天可能被加载多次。这样，报表的缓存也需要被及时的刷新，才能保证用户看到的是最新最准确的数据。MSTR本身自带的定时调度已经无法满足实时更新缓存的需要，而支持事件调度的command manager组件需要额外的费用购买，而且和DW的ETL系统无法打通关系。基于这两点，我自己开发了一个定时调度程序，通过调用MSTR的OPEN API去实现缓存的实时刷新。

mysql数据压缩性能对比（二）

在上一篇文章中，我们用生产环境的真实数据与真实SQL测试了archive和myisampack两种方式下的性能对比情况。我们得到一个对这个测试case有效的结论，那就是在240万数据量的情况下，采用archive引擎将使得某些查询慢得无法忍受! 那么，原因是什么呢? 我们知道，mysql提供archive这种存储引擎是为了降低磁盘开销，但还有一个前提，那就是被归档的数据不需要或者很少被在线查询，偶尔的查询慢一些也是没关系的。鉴于上述原因，archive表是不允许建立自增列之外的索引的。

mysql的数据压缩性能对比（一）

数据魔方需要的数据，一旦写入就很少或者根本不会更新。这种数据非常适合压缩以降低磁盘占用。MySQL本身提供了两种压缩方式——archive引擎以及针对MyISAM引擎的myisampack方式。今天对这两种方式分别进行了测试，对比了二者在磁盘占用以及查询性能方面各自的优劣。至于为什么做这个，你们应该懂的，我后文还会介绍。且看正文：

Microstrategy 8.1.2 Web Universal 开发问题整理

做Microstrategy  Web Universal的二次开发已有半年多的时间了，Web Universal有着非常强大的扩展性和可管理性，Web代码结构，不管与任何系统进行集成都非常方便。 但是随着浏览器种类的增多和浏览器版本的差异，造成Web Universal中很多功能无法正常使用的问题，严重的影响了用户体验。虽然多数报表系统针对的用户群体不是很多，但是由于用户体验造成的影响是非常恶劣的，所以修复这些问题是关键。8.1.2版本的Web Universal由于时间较早，支持的浏览器比较有限，虽然升级能够解决很多问题，但是带来的影响的也是相当巨大的，所以在此版本上的开发也是重中之重。 需要说明的是，二次开发最好能够养成好的习惯，更改的位置加入自己更改的特殊标识，将原内容进行备份以便整理。并且尽量在不变原业务逻辑的基础上进行修改，因为你修改的大多数只是特殊情况和没有涉及到的情况。 1. ie8下文档中的显示相关问题，例如下图中显示的button按钮，在ie8下，最后一个按钮会覆盖前面所有按钮，致使除最后一个按钮外的所有按钮不可用。

BO报表系统嵌入Iframe后的问题探讨

bo报表和mstr报表都是非常优秀的报表系统，每个系统都有自身的优点。很多时候在使用这些报表系统的时候，都是将这些系统集成至我们自己的项目中使用，从而需要对这些报表进行二次开发。常见的就是将报表系统使用iframe的形式嵌入我们的项目中，这样能够很方便的控制报表目录和相关权限。 mstr报表系统中，所有的执行页面没有iframe或者frameset的结构，所以将系统嵌入iframe后，所有的功能都能够正常使用。但是在bo报表系统中，用于操作和显示报表的页面，使用了frameset的结构，因此再将bo系统嵌入iframe中，可能会引起相关问题。不过，bo报表系统的相关方面也是做得不错，在嵌入iframe使用过程中，在ie浏览器下功能都是正常的，但是在firefox下，就会出现一系列的问题，如：结果不能显示、筛选答案不能提交，这种主要功能上的错误。

BIEE使用体验－biee中列、表、报表的更名

之前在BIEE使用中遇到这样的一个问题，对在presentation层中列名、表名，或者对ANSWER中已经存在的报表或者文件夹进行更名(RENAME),会导致一些已经建立好报表报错，提示无法解析某字段，或者导致DASHBOARDS中提示说无法找到某个报表。 这个问题对我们的某些维护性操作会造成一定的影响。比如在为了整理BIEE展现中的表，而进行归类缩进(在presentation层中的表名前加“－”)；或是因为用户需求而变更表名、列名甚至报表名等操作。 通过对BIEE的使用经验的总结,我们发现有几种方法可以解决以上的问题。 (方法一) :在business层直接进行RENAME的话，对应的presentation层中列名会产生对应的改变，与此同时在presentation层中该列的ALIASES中会生成之前用过的列的名字。

BIEE使用体验 – 关于时间格式

  我们数据库有很多关于时间的字段，都是以DATE格式存储的。 这些DATE的数据中有些是到年月日，有些是具体到时分秒的. 当我们将表导入 BIEE物理层的时候,发现含有时分秒 的数据都会默认转变为 timestamp 类型. 为什么biee 要强制转换为 timestamp 类型,我还不得而知,但是在报表开发中的确带来了一些问题.  问题之一:我们在Administrator中创建过一些变量,希望给这些变量赋值为 前一天 或前一周这样的动态的时间.以便应用在报表提示中固定查询之前一段时间的数据. 在变量的定义中使用了select trunc(sysdate)-1 from dual 这样的写法. 结果发现,转换成的sql语句是这样的 trade_day>TIMESTAMP ’2008-02-19 00:00:00′. BIEE将时间格式都变为TIMESTAMP型了.  而我们这个表由于数据量非常大,按照date类型日期进行了分区.现在由于条件日期是TIMESTAMP型,这样一来,查询语句就不能使用现成的分区,查询速度变的很慢很糟糕.