SPARQL和大数据（以及NoSQL）

如何达到一个双方的共识基础?

很显然SPARQL和其他RDF相关的技术在重叠的大数据和NoSQL的世界中会大有用武之地，但是对专注于该领域的人来说这好像还不够明显，例如本周的Strata会议基本上对RDF或SPARQL无所顾及。我看的越深入，我就觉得这个灵活的、标准化的数据模型和查询语言已经可以在上述人群努力去处理的各类问题中已经表现得相当不错。

我们语义网人士不能批评人家。如果你做了一个更好的捕鼠器，这个世界不会开辟一一条直通你家门口的路，因为他们得先知道你的捕鼠器以及它干什么干得好。这就需要营销，就是用人家的语言来描述。于是我就开始看一些关于大数据和NoSQL的材料来更好地亲近他们正在努力做的以及怎样去做的。

首先是 Edd Dumbill等人精彩的电子书Planning for Big Data。一开始他就指出“那些无法满足你数据库架构的严格要求的”数据是大数据方案的候选者。在后面的“提取和清洗（Ingesting and Cleaning）”有两段引文（在从多个不同数据源采集数据的讨论之后）:

一旦数据被采集，它就必须被提取On。传统的BI的说法是抽取、转换刚和装载（Extract, Transform, and Load，ETL）：即把合适的信息放在对应的数据库脚本的表格中，并对特定的域进行操作处理使得他们容易处理。

大数据的一个显著特征是，这些数据往往是非结构化的。也就是说在我们开始分析他们之前， 我们是不清楚其内在信息结构的。我们当然可以进行某些转换——例如把IP地址变成城市的名称，或者使用单向的来隐藏特定的字段——但是我们还是要紧紧抓住原始数据并且在我们分析的时候来定义其结构。

对于一个具有很长时间XML背景的人来说，我知道关于"structured" vs. "unstructured"数据的说法是一个 data 具有非常相对性意义的概念——对一个人来说的结构化数据可能对另一个人来说是非结构化的，尤其前者是个XML领域的二后者是关系数据库领域的——这就是术语"semi-structured" 做为一个协调性形容词的出现缘由。我将打造一个新的术语，以期和Google hits没什么相关 "minimally structured"——如果我们手上有一个虽小但是足够用结构来作为起点并开始工作的话，那么你的数据就是最小化结构的。并且RDFS做为"边分析定义结构边分析"是非常棒的，这可以一步步来，并且OWL可以进一步往深走。

有一些最小化的结构可以被演绎并且使其显性化： 例如（参考： 翻译——三元组存储会取代关系型数据…的例子，省了没翻）you have data about people's genders and and about who is the parent of who, you can infer father and mother relationships (and grandfather, and aunt, and...) and even classes by defining a Grandfather class as the set of instances that have a gender of male and have children who have children. 对我而言这就是新信息的生成， 但是一个关系数据库领域的人并不这样看——他会说这只不过是把隐性的知识显性化了而已。关系数据库领域的人们花了很多精力（a lot of effort）来避免显性化第存储那些可以通过演绎得来的信息。然而关系数据库是一个相当封闭的世界，所以在一个给定的数据集合中来演绎出新玩意的机会并不是常常可以出现。来自多个数据源的RDF的累积可以非常动态，并且易于生成一个比它组成部分更广阔的空间（源于其演绎推理），进而为在不同数据组合中发现模式w差U那个早更多的机遇。另一段引文:

即使没有大量的数据类型不匹配，关系数据库的一大弱点是其脚本（schema）的静态特征。在一个快速扩张的环境下，计算的结果将会随着对信号不断侦测和抽取的过程而进化。Semi-structured 数据库符合这样的灵活性要求：它们提供了足够的结构来组织数据，但在数据存储之前不要求一个具体的规范。

这对于三元组来说也是一样的，后者提供了两个世界最好的东西：不要数据脚本，你可以不断地累积数据，并且使用一个标准的查询语言来检索；如果你愿意，你还可以逐渐地增加脚本元数据（schema metadata）——通常基于查询结果 (often based on query results)来协助更进一步的查询。

NoSQL数据库通常被称为“非脚本化（schemaless）” ，因为他们不许要具备和关系数据库相关联的正规脚本。后者——通常在软件正式编写以前就要定义好——其缺失意味着非脚本化数据库将会较好地适应目前的软件开发实践如敏捷开发。从一个简单的可以工作小项目开始，不断快速迭代来响应用户输入的方式并不能与项目一开始就把所有的数据脚本设计定义的方式好很好协调。我们也无法预测数据将被怎样使用，以及随着项目的开展会有什么样的数据进一步要添加。

这里又一次对基于RDF的技术来说是十分容易处理的情况。在"开发之前就拼装大脚本"和"尽管扔掉那些减弱灵活性的脚本"的选择之外，你还可以在项目进行中需要的时候，和中间层一点加入的脚本元数据进行一道工作。

从我听到的各类型的NoSQL数据库产品，面向图的Neo4J好像是最接近三元组存储（triplestores），该产品也是对图进行存储graphs。 下面这个关于另一类NoSQL数据库种类的描述真正引起了我的注意，尽管：

Cassandra和HBase都被称为是面向列的数据库, 更为恰当的名称其实应当是“稀疏行存储（sparse row store）。在这些数据库中，和关系型“表”相对等的是一个行的集合，使用一个键值来标识。每行含有一个无限制数目的列；这些列实际上是一些必要的键值用来查询该行中的各种值。列可以在任何时间加入，并且对某一给定的行来说没有使用到的列将不占据任何存储空间。不存在NULL。

这个就是 "和关系型“表”相对等"?这听起来更像是等同于被某一主题所归类的一组三元组。属性（谓语）实际上就是那些必须的供你查询的和这些主题相关的值的键值；你可以在任何时候为某个主题添加“属性名称/值”，由于它们并不依赖于某种固定的脚本，并且未被使用的属性将不占据任何存储（也就没有NULL）。

我乐意见到的，而且已经听说了一些实质性的尝试, 是这些NoSQL数据库系统的SPARQL端（ endpoints）。D2RQ和R2RML 的完成的工作可以使得面向图和列的NoSQL databases都会变得简单起来——如果我对上述引文理解正确的话。在Google上归于SPARQL和 Hadoop（或者和Neo4J, HBase, Cassandra）的检索显示已经有人在讨论并且已经开始了一些编码的工作。在面向图和列的NoSQL数据库之外，另一类是面向文献的数据库， 那么AllegroGraph的利用SPARQL来访问MongoDB（interface to MongoDB）就是这个方向上一个出色的标记。我们可以怎样做来鼓励继续这个互动呢？