数据仓库

July 20, 2011
This article was contributed by Josh Berkus
Data Warehousing
翻译：马少兵、曾怀东、朱翊然、林业

尽管服务器存储、处理能力得到有效的提高，以及服务器价格的降低，让人们能够负担起大量的服务器，但是商业软件应用和监控工具快速的增加，还是使得人们被大量的数据所困扰。在数据仓库领域中的许多系统管理员、应用开发者，以及初级数据库管理员发现，他们正在处理“海量数据”-不管你准备与否-都会有好多不熟悉的术语，概念或工具。已知该领域大约有40多年的历史，广为人知。这篇文章ss对那些想去了解该领域的人来说是一个起点。

什么是数据仓库呢？

数据仓库不等同于“海量数据”；恰恰相反，而是其子集。海量数据也包含：通过大量的连接提供每秒百万次服务请求的系统，例如Amazon的Dynamo database。数据仓库一般指的是：在相当长的时间内堆积数据，仅仅需要处理大量数据请求中的少部分的系统。

数据仓库真正的答案之一：三种不同的问题--组织归档，数据挖掘或分析。有时它回答了三个结合。

1. Archiving
   

   “我想在相当长的时间内存储大量数据，可能对其从不进行任何查询服务”。

   由于HIPAA法案、奥克利斯法案、第8公司法以及其他相关法律，归档成为非常流行（或者、至少、必须）的一种数据。它也被叫做“WORN” (写数据后，从不去读) 数据。公司积累了大量他们不想要的数据，但是却不能扔掉，从理论上来说，数据需要在合理的时间内要去访问。存储的大小范围从GB到TB。

   这种归档系统其中一个非常好的例子是：我帮Comptel and Sun Microsystems建造的关于欧洲手机呼叫完成数据。每个城市呼叫完成数据大小为75TB，可以预料，每周每一个数据库应至少应答一条信息请求。这就允许我们使用非常便宜的PostgreSQL数据库、Solaris和压缩文件系统的组合。

   如果你想建立一个文档服务器，你仅仅的需求是：花费最少的存储成本和确保文档服务器和当前数据同步。一般地，这意味着需要对数据进行压缩、以及一个能够稳定工作非常廉价的硬盘驱动器的数据库或者是磁带库。查询的速度和其他特性不是关心的事情。有趣的是，这是数据库的一种类型，但是却没有很好的开源解决方案。

2. Data mining
   

   “我一天堆积了1GB的数据，知道其中有有用的信息，但是不知道那些是。”

   数据挖掘是数据仓库中一种非常普遍的类型；大多数的公司或网站产生很多副作用的数据，然而大多数的公司或者网站不清楚如何利用这些数据，仅仅知道他们有时候会用到这些数据。更可悲的是，我们对这些大量数据的结构和意义却完全不了解；这些数据可能是完整的文档，未知的字段，以及不明确的分类。数据大小一般是从TB到PB。这常常被称为“半结构化”数据。

   Web流量数据分析可能是数据挖掘中的一个最经典的例子。作为结构化和消息文本的混合形式的数据，一般来自web服务器的日志和cookies。 公司收集这些信息，因为他们想在不使用数据库的情况下，通过这些数据逐渐地建立一个查询的集合和报告，来获取趋势数据。

   在数据挖掘解决方案中，最想得到的数据是在高效和快速的情况下，获得CPU的性能和I/O高性能的检索、分类和计算效率。或者，基于多处理器或者多服务器上的并行计算，是最好的结果。对于第二个关注点，数据挖掘数据库常常不得不以每分钟1GB的高速率接受数据。

3. Analytics
   

   “我有大量高度结构化的数据，我希望用这些数据生成可视化的结果来帮助商业决策。”

   商业活动通常也会产生他们自己很了解的数据：销售数据，客户账户和调查数据。他们希望利用这些数据生成可以策略性地使用的表格，图表和其他好看的图像。这种数据系统有不少形式，包括分析，business intelligence (BI)，决策支持(DSS)以及在线分析处理(OLAP)。

   我曾经使用来自Point Of Sale (POS) 系统的连锁销售数据部署过这类系统中的两个。POS数据几乎完全由数值，库存ID以及分类树组成，所以它能够创建按类别，时间和地理分类的图表。没有什么必要对这样的数据进行挖掘，因为它已经非常容易理解，而且分类计划的变化很频繁。

   大量分析系统功能都集中在分析中间件工具上。用于分析的数据解决方案都是关于大量数据聚合的。像“cubes”（稍后解释）这种支持，对高级分析很有用，这是因为数据被压缩并索引。数据通常通过夜间的批处理导入系统，所以读取方面的快速响应时间没那么重要。

五种类型的数据库

目前市场上，解决数据仓库的这三个基本问题的主要有五种不同类型色数据库系统。这些系统经历了几十年的软件开发。当然，现实生活中的许多大型数据库系统实际上是由以下五种类型混合而成，但我将根据其主要类别列出例子。

1. 标准关系型数据库

   如果你只有几十或者上百G的数据，标准主流的关系型数据库仍旧是一个的选择。不管你的选择是 PostgreSQL, MySQL, Oracle, 还是 SQL Server，它们都很成熟，灵活而且有大量第三方和厂商的工具可供使用。或许更重要的是，技术人员已经对它们非常熟悉了。

   我为一个小型的连锁零售商的库存管理系统部署了一个分析型数据仓库。最初我们考虑把它设计成一个专有的大型数据库，但是后来我们发现这个数据仓库的最大容量为350G.鉴于此，我们决定采用主流开源的 PostgreSQL，这样一来节省了资金和时间。

   标准的关系数据库在数据归档，数据挖掘以及数据分析这些方面都不突出。但是，它们可以胜任所有这些任务。所以如果你的数据仓库问题规模比较小或者不是对响应时间要求严格，它们可以作为一个选择。

2. MPP 数据库

   MPP数据库是最早为数据仓库设计的数据库，它诞生于20年前。MPP代表“massively parallel processing”，也就是一种单一的查询在多台机器或多个主板上的多处理器执行的关系数据库。数据库管理员喜欢这种类型的数据库，因为他可以把这种数据库当作一个有一定限制的又大又快的关系型数据库服务器。MPP数据库包括 Teradata, Netezza, Greenplum, 以及DB2的数据仓库版。

   当我在Greenplum工作的时候，我建立了多个“分析点击量”的数据库，在这些数据库中我们为营销公司处理大量的网络日志数据。我们在日志中没有办法知道我们将会看到什么，甚至网站的页面结构。我们不得不做许多CPU密集型处理：解析文本的聚集，运行自定义数据库函数，并建立实体化的视图，16节点的Greenplum数据库是相当快的。

   MPP数据库适用于数据挖掘和分析。其中一些—尤其是Greenplum—也混合了列表中的其他数据库类型。然而，迄今为止，所有产品级的MPP数据库是专有的，任何真正的大数据库通常都非常昂贵。

3. 基于列的数据库

   在1999年发明，列存储数据库致力于改变用于关系型数据库或者“基于行”的数据库的基础存储模型。在基于行的数据库中，数据存储在属性的连续行中，列通过表的元数据相关。列存储数据库把这个模型转了90度，把列的属性存储在一起，而只通过元数据关联行。这允许了不少的优化，包括各种形式的压缩和非常快的聚合。

   当前的列存储包括 Vertica, Paraccel, Infobright, LucidDB和 MonetDB. 其中Vertica或许是领先的列存储数据库，后面三个是开源的。此外，一些其他类型的数据库，包括 Aster Data和Greenplum，已经将列存储作为一个选项加入其中。

   我们的客户端之一是为一些TB级别的医院绩效数据创建顶层的射线图表。由于所有的这些数据是数字，评级或者保健类别，Vertica被证明是一个很好的解决方案，它用比标准的关系数据库少得多的时间里返回顶层摘要。

   列存储仅适合于分析，因为所有的数据必须可以很好的被理解，高度的结构化而被存储于压缩的列中。列存储对于数据有很好的效率，可以减少数字和类别列表的数据。它们主要的缺点是更新或者导入数据缓慢，单行更新基本不可能。

4. MapReduce

   数据仓库的下一个创新是google在不到十年前推广的MapReduce框架。MapReduce是一个算法，当伴随着集群工具，它允许你把单一的请求分为若干小的部分，然后执行于数量巨大的服务器阵列中。当与某种形式的集群或者散列分区存储结合的时候，MapReduce允许用户在数十到数百个节点上执行大量的，长时间运行的请求。Hadoop是占有绝对主导地位的MapReduce框架。当前的基于MapReduce的数据库包括 Hadoop with Hbase, Hadapt, Aster Data, 以及CouchDB。

   在一个项目中，客户需要运行30TB JSON和二进制混合的数据的请求。因为二进制数据的搜索程序是处理器密集型的，它们把这些数据放到HBase并且用Hadoop运行许多的处理程序，把查询结果存储于PostgreSQL中，方便以后的浏览。

   在许多方面，MapReduce是开源的，能够替代MPP数据库，而且主要适用于数据挖掘。它可以扩展到较大数量的节点。然而由于它的通用性质，MarReduce在查询方面比MPP低效多了，也更难写了。多亏了诸如 Hive 和 Pig 这样的工具修正了这样的缺点，它们让用户用类似SQL的语法写MapReduce查询。此外，MapReduce数据库比前面的三种要年轻许多，使得它们可靠性和文档化相对差点。

5. Enterprise search

   数据仓库中的“新人”是企业搜索。它仅仅包括了两个开源的产品，它们两个都是Apache Lucene项目的后代：Solr和Elastic Search(ES)。企业搜索包括以文件形式在大量的半结构化数据上做多服务器分区索引。二者也都支持“facets”，它是实体化的搜索索引，允许用户通过类别，值，范围和复杂的搜索表达式快速的计算和搜索文档。企业搜索也往往给人“近似”的答案，它可以是一个功能或缺陷，这取决于你的设计目标。

   企业搜索在一些令人惊讶的地方是有用的。我们有一个客户端，使用它可以让它们的客户端在非常庞大的法律文件中产生细致入微的汇总统计。把它们放入Solr允许客户端跳过他们需要运行的数据程序而把它放入其他种类的数据库中，同时仍然给它们快速的搜索结果。特别是，Solr索引的预处理计数允许返回文档计数的速度远远超过关系数据库。

   企业搜索服务是数据挖掘和分析的一个子集，这使得它具有广泛的用途。它的最大价值发挥在待搜索的数据已经是HTML，XML或者JSON格式的时候，这样不用在索引之前转换或者变换格式。然而，它是最年轻的数据库类型，这两种产品仍旧有许多可靠性问题以及令人惊讶的局限性。此外，数据库请求仍然和“搜索”模型紧密的结合，这让它很难被用在不同的使用情况下。

其它工具

作为所有数据仓库工程的一部分，你同样将需要一些其它的工具，这些工具可以从源中获取数据从而完成你的报告或者接口。鉴于我无法更详细的叙述他们，下边仅罗列出一些你需要知道的工具

加载（Extract Transform Load/ETL）和数据集成工具：这些工具从初始源中获取最终成为数据库格式的数据。代表性的开源加载工具有 Talend 和 KETTLE，而且有许多类似 Informatica 的专属工具。在现代化的基础设施中，像 ActiveMQ 和RabbitMQ 的开源工具队列平台，许多应用程序所应用的ETL工具正在被自定义代码所取代。

数据挖掘和数据分析工具：像Weka，SAS，以及R language中各式各样的项目所提供的从大量的无序数据中获取意义的高级工具。它们帮助你通过统计学分析和机器学习算法找到你的数据中所存在的模式。在这个领域内，Weka以及R这些开源工具居于行业之首，专有工具主要是用于一些遗留的应用。

报表工具：鉴于你需要展示你的数据，你会需要像 BIRT, JasperReports 这样的报表工具，或者像Business Objects 和 MicroStrategy 这样的专有平台。这些工具可以提供你的数据以简单的可视化效果，通常是很有交互性的图表和图形格式的。近来，这两大代表性的开源工具在易用性方面与专用工具展开了竞争，但是这恐怕要花费他们一些时间去突出他们的特性。

在线分析处理（OLAP）：一个欺诈性的名字总是有很多的事情去做，使用“cubes”提供一个基于导航的用户界面去探索你的数据。OLAP工具，像Mondrian，Cognos，以及 Microsoft Analysis Services创建了一个数据的多维空间图，它可以让用户通过在其内不断移动来查看数据的不同部分。这是开源工具十分落后的一块领域；相比于Oracle和SQL Server，开源数据库的OLAP支持就比较弱，Mondrian是仅有的开源OLAP中间件。

我同样需要提及Pentaho，一种集成了所有开源ETL，数据挖掘，报表工具的开源平台。

总的来说，对于所有级别的数据仓库栈都有开源工具，但是这些工具与其竞争对手相比，经常不太完备并且缺乏特性。但是，如今，在分析与数据挖掘领域拥有最先进技术的是开源界，很有可能在将来的3到5年，它们将会达到一个平衡。

结论

现在你应该对数据仓库领域有了比较深的了解，特别是从数据库角度。我们无法深究这些话题的细节或者工程和项目，至少你知道从哪里开始搜索，并且对于每个数据仓库领域都有许多的工具。同样，你可以在最近的波特兰的 Open Source Bridge conference上以视频格式来看这些材料。