Infobright 数据仓库

目录 分布式系统, 开源

最近有部分工作涉及到了 Infobright 数据仓库,就浏览了一些相关的资料,感觉很受启发。下面写一些感想,如有谬误,还请指正。

简单的来讲,Infobright 主要有下面的一些优点:

1. TB 级的数据存储和高效查询。大数据量存储主要依赖自己提供的高速数据加载工具(百G/小时)和高数据压缩比(>10:1),高效查询主要依赖特殊设计的存储结构对查询的优化,但这里优化的效果还取决于数据库结构和查询语句的设计。

2. 高数据压缩比,号称一般能够达到 10:1 以上的数据压缩率。高数据压缩比主要依赖列式存储和 patent-pending 的灵活压缩算法。

3. 与主要 BI 分析工具的兼容性。兼容性这点主要依赖与 MySQL 的集成,作为 MySQL 的存储引擎自然地能够保证与 BI 分析工具的兼容。

除了上面的优点外,它也有一些限制:

1. 不支持数据更新。这使对数据的修改变得很困难,这样就限制了它作为实时数据服务的数据仓库来使用。用户要么忍受数据的非实时或非精确,这样对最(较)新数据的分析准确性就降低了许多;要么将它作为历史库来使用,带来的问题是实时库用什么?很多用户选择数据仓库系统,不是因为存储空间不够,而是数据加载性能和查询性能无法满足要求。

2. 不支持高并发。虽然单库 10 多个并发对一般的应用来说也足够了,但较低的机器利用率对投资者来说总是一件不爽的事情,特别是在并发小请求较多的情况下。

3. 没有提供主从备份和横向扩展的功能。如果没有主从备份,想做备份的话,也可以主从同时加载数据,但只能校验最终的数据一致性,这会使得从机在数据加载时停服务的时间较长;横向扩展方面,倒不是 Infobright 的错,它本身就不是分布式的存储系统,但如果把它搞成一个分布式的系统,应该是一件比较好玩的事情。

在架构方面,Infobright 给我展示了不少新想法,算是受益颇多吧。首先是按列存储,然后把列数据切成小块(Data Pack),进行压缩和统计(DPN, Data Pack Node),然后再对多块数据之间进行知识关联(Knowledge Node),最后对整个表形成知识网格(Knowledge Grid)。虽然说 Infobright 没有提供索引结构,但它 Knowledge Grid 中的 Numerical Histogram、Character Map 和 Pack-to-Pack 结构,怎么看都和 bitmap 索引脱不了关系。只是它的组织形式不像传统数据库中的索引罢了。

其实我们在设计类似的分布式表格系统时,也可以实现类似于 Knowledge Grid 的结构。这个结构未必跟 Infobright 的一样,但是如果在压缩的基础上,基于系统查询模式(分布式系统的查询模式一般相对简单,复杂的也做不来),存储一些辅助的块统计信息以及块之间的关联信息,对于减少查询的资源消耗,提高查询效率会非常有帮助,这也正好是针对分布式表格系统很难建立索引这一缺点的弥补。

参考链接:

这篇文章对 Infobright 及其安装方法进行了基本介绍,最后的一个查询速度对比有些夸张(105:1),我觉得这可能跟查询条件正好能匹配上 Knowledge Grid 中的信息所致;这个博客很有趣,从 2010 年 3 月 8 日到 5 月 8 日之间的文章全是 Infobright 相关的,写的还是挺详细的;Brighthouse: An Analytic DataWarehouse for Ad-hoc Queries 是一篇相关的 08 年 VLDB paper;此外官网上的白皮书不能直接下载,但在搜索引擎中能搜到一些。

长按识别二维码关注《边际效应》
长按识别二维码关注《边际效应》

1 条评论

  • Facebook的实时Hadoop系统 | 自由 开源 分享
    2011-08-27

    [...] Infobright 数据仓库 (0) – 最近有部分工作涉及到了 Infobright 数据仓库,就浏览了一些相关的资料,感觉很受启发。下面写… [...]

发表评论

电子邮件地址不会被公开。 必填项已用*标注