小数据：理论和架构 | TW洞见

今日洞见

文章作者及图片来自ThoughtWorks：熊节。

本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。

大数据是当下最热门的IT主题之一。据麦肯锡的分析，大数据能使信息更透明、能让决策者获得更精确翔实的绩效信息、能针对客户群体提供更准确的定制、能提升组织决策能力、能帮助开发下一代产品和服务。新时代里与互联网联结的组织不论大小，都需要这些能力。

然而与此同时，大数据的“大”并非适用于所有组织。Gartner认为，大数据具有“3V”的特征：多样性（Variety），数据来自多种不同来源、具有多种不同形态；速度（Velocity），数据形态和呈现形式的变化快且频繁；量级（Volume），数据量非常巨大。然而对于众多的中小型企业及非营利组织而言，这三个特征有两个未必适用。很多中小型组织只有为数不多的几个IT系统，数据都保存在为数不多的几个关系型数据库中，数据量不超过数百万条记录。只有变化速度快这一特征，对于中小型组织仍然适用。从这个意义上，这些中小型组织需要的是一个“小数据”解决方案：

小数据：聚焦中小型组织和新兴业务，在数据量较小、数据来源较简单的情况下，提供非常灵活、非常简便易用、使用过程中对IT技能要求非常低的数据分析和商业智能，为应对多变且未知的外部环境提供决策支持。

传统上，很多小数据场景的分析和商业智能需求以“报表”的形式呈现在IT项目中：在开发OLTP系统的项目中列出一组报表需求，由交付OLTP系统的团队以直接SQL查询的形式实现报表。这种做法贴合了数据量小、数据来源简单的特征，但损失了灵活性，报表的定制和修改需要技术人员介入，因此又无法满足对速度的要求。为了赢得灵活性，小数据分析也同样需要首先建模OLAP Cube，然后通过不同维度的切片和钻取进行分析。

什么是Cube？按照维度建模方法，数据可以分为“事实”和“维度”两类。事实数据代表“发生了什么事”，维度数据则从各个角度描述这件事。如果以电商为例，事实数据是“销售记录”（卖了一个东西），常见的维度数据可能包括“产品”（卖的是什么）、“门店”（在哪里卖的）、“时间”（什么时候卖的）、“售货员”（谁卖的）、“顾客”（卖给了谁）等等。不难想象，事实数据表将只有一个主键、一个值、以及一大堆外键指向各个维度表；维度表也可能有外键再指向更多的描述性的子维度表（例如“产品”有外键指向“类别”）。于是我们就会得到一个星型表结构（或叫雪花型表结构）。

星型表结构的优势在于，分析操作会变得非常简单：你关心哪些信息，就直接用JOIN子句把这些维度表关联进来；只要在JOIN子句里指定WHERE条件，就可以快速缩减结果集。在星型表结构里，一个事实会被若干个维度修饰，因此可以把整个数据集想象成一个立方体（或超立方体，当维度多于三个时）。例如当只考虑“产品”、“城市”、“时间”这三个维度时，“销售记录”的数据集就可以被建模为一个立方体。

随后就可以在这个立方体上对数据进行各种分析。例如你可以锁定“城市”这一维度，从而得到“某城市各种产品历史销售报表”——“锁定某一维度取值”这一操作也叫“切片”（slice），因为它在这个例子中产生的效果就是从三维的立方体中切出一个二维的数据平面。同样的，我们也可以从“产品”维度切片，从而得到“某产品各市历史销售报表”。当维度具有“分级汇聚”的特性时，我们还可以进行“钻取”（drill）操作，例如当“地区”维度分为“市”和“省”两级时，我们就可以在“地区”维度上进行钻取：首先从产品维度切片得到“某产品各省历史销售报表”，然后选择一个省下钻得到“某产品在某省内各市历史销售报表”。

小数据系统设计原则1：建模一个Cube，就可以快速实现一系列分析操作（及对应的报表）。小数据系统应该支持简便且易于修改的Cube建模。

基于这个设计原则，我们可以大概推知小数据系统的架构：首先，根据指定的Cube描述信息，把业务数据建模成Cube；然后，通过RESTful API对Cube进行切片、钻取和聚合等操作，并取回二维平面表或透视表形式的结果集；最后，根据指定的报表定义信息，把结果集渲染成报表。

从上图不难看出，在这个架构中，必须由用户（不论是开发者或最终用户）提供的信息只有三项：

（1）Cube的描述； （2）数据分析操作对应的URL； （3）呈现分析结果的报表定义。

并且第三项信息（即报表定义）与具体业务是完全解耦的，因此理应可以用分别的开源软件组合形成轻量级的小数据解决方案。在下一篇文章中，我将具体介绍一个基于开源软件的小数据解决方案实现。