创建一个360°视图 第一部分：概述&数据分析

摘要：第一部分包括一个视图示例以及在构建视图时需要考虑的要点概述，第二部分将介绍一个示例数据模型的实现，第三部分将深入探讨如何将数据迁移到的机制。让我们假设你已经有创建一个视图的想法了。

本文源地址：http://www.mongoing.com/archives/884

本系列的三篇博客将会提供一个关于在MongoDB上构建360°视图的介绍。第一部分包括一个360°视图示例以及在构建360°视图时需要考虑的要点概述，第二部分将介绍一个示例数据模型的实现，第三部分将深入探讨如何将数据迁移到MongoDB的机制。

那么，什么是360°视图呢？或许你也听过术语——数据总线、360°视图或者多渠道显示。所有的这些术语都描述了一个从多个分离的数据源收集数据并且将其整合到一起以提供一个360°视图的系统——这就是所谓的“360°视图”。什么对象的360°视图呢？答案是：任何潜在的、你希望的对象。通常，人们指的是一个“单用户视图”。但是，或许你还想创建一个关于业务线、产品、雇员、资产或者其它数不清可能对象的360°视图。接下来，我们将在这里主要讨论一个用户的360°视图，但是相同的原则也适用于其它任何一个对象的360°视图。

为什么你会需要一个数据的360°视图？大部分公司对它们的数据都会有一个复杂的处理过程：经常包括来自于多个数据源多种结构数据的读取、转化，然后载入到一个操作型数据库，然后再提供给需要这些数据的应用程序。通常，其中的分析、商业智能以及报表服务都有可能需要从一个多带带的数据仓库中读取数据。当然，所有的这些层次都需要与安全协议、信息管理标准以及其它相兼容。

不可避免地，信息最终会被搁浅在“数据孤岛”中。系统构建的目的都是为了满足当前的需求，或者某一个特定的应用需要一个特定的数据结构。 突然有一天，你发现同一个用户的数据被存到了许多不同的互不联通的地方。

为什么你想要把所有分离的数据放在一起？不仅仅是为了每个数据都可以与它的同类数据在一起。360°视图的用户案例可以存在于任何一个你可以想象的地方：

任意选择一个行业，你可以发现无数商业理由需要将分离的数据进行整合。360°视图就是使用用一种最合适的方法处理数据并且用一种你从未用过的方式观察它。

好的，上面已经有足够多的商业说法了。让我们假设你已经有创建一个360°视图的想法了。你如何着手开始呢？

让我们以一个网络平台的零售商为例。分离的数据世界或许是这样的：

传统思维模型

在这里，你可以看到许多不同类型的数据。蓝色的框代表你的客户及他们相关的信息。而绿色的框则代表外部数据：包括你通过支付第三方而得到的信息——情感分析、人口统计信息等。紫色代表你的产品信息。当然，这些对象都通过用户与产品交互的方式联系了起来——包括留下评论及打分、下订单以及浏览网页等。

现在，这么多数据孤岛以各种各样不同的方式在逻辑上联系在了一起。但是，通过观察这些联系，你可以发现两个大类别——与客户相关的信息以及与产品相关的信息。 注意这两类数据不是互斥的。。

这是非常直观的一个分组。因此，当你将其转化到一个新模型以支持MongoDB中的360°视图时，你可以使用下面这种方式重构数据模型：

在这里，你真正创建的是两个360°视图：一个是客户的，一个是产品的。在以前的模型中，如果你想查看关于一个用户的所有信息，你不得不从大概10个地方收集­—假设可能的话。而现在，你已经将它们放置在了同一个地方，因此你可以快速、简单地查看所有与一个给定用户相关的信息。你可以在产品上做相同的操作，因此你可以马上了解一个给定产品的运行情况。除了可以在同一个地方查看一个顾客或产品的所有信息，你也可以很容易地在整个类中统一工作。例如，查询所有的顾客，找到在给定的邮编下购买了一个特定产品的用户。

特别需要注意的是：你不需要将所有的相关信息都放置在同一个用户对象中。当你查看某用户的360°视图时，你是否真的需要过去十年内他在你网站上的所有行为，或者所有他曾今推特过的所有有关你公司或产品的信息？也许没必要。这并不意味着你丢弃所有的细节——无论如何，你应该将它们进行多带带的存储，但是在用户对象中，将其在一个可用的层次进行总结也许非常有用。例如，过去30天内的交易重点或者一个整合的情感分数。

当你决定如何合并的时候，问一下你自己：你希望如何使用数据来获取什么有用信息。在这之前，订单是多带带存储的。但是每一笔订单都与一个用户相关，因此，在这里，我们将订单数据嵌入到用户对象中。另一方面，我们也许不需要在该顾客对象中存储订购产品的所有细节，因此，我们将其外链到了产品集合以避免重复。

一旦你使用这个方法重构了你的数据，你可以做什么？让我们详细看一下用户对象：

- 主要交易：通过交易数据，你可以了解最活跃或者最不活跃的客户。
- 情感评分：基于情感评分，你可以进行分析，从而了解情感如何随着用户其它数据改变。
- 订单：订单已经以一种合理的方式嵌入，减少了数据模型的复杂度。
- 位置：除了账单及配送地址，你可以基于IP或者移动位置做地理分析。
- 评论：你可以通过使用评论进行本地的全文检索以发现用户产生的共同描述。
- 行为：在这里，你可以过滤和展示最重要的数据：例如，最近用户做了某件事，因此客户服务代表应该准备在与用户进行交谈的过程中讨论那件事。

在这里，我们还有许多关于新数据模型的问题。但是，我们应该如何在MongoDB中提出相关的问题呢？让我们来看一些例子，了解MongoDB的查询。当然，下面这些都是一些伪代码案例，构建属于你自己查询的方式需要依赖于你的数据模型。

这名顾客购买了什么类型的产品？

distinct( “orders.category”, { “id” : 12345678 } )

目前他们到某服务点的距离有多远？

find( “location” : { $near : [40.8768, -73.787] } )

哪些是对我们服务最不满意的前10名顾客？

find().sort( { “sentiment”: 1} ).limit( 10)

我们的客服代表应该在下次谈话中提及什么？

find( { “action.topic” : “talkingpoint”} ).sort( “createdOn” : -1 )

保持专注，快速迭代。不要超出你的能力，试图在一步内就合并你所有数据。使用一些数据源作为概念验证进行一次重要尝试。考虑这些数据以及你有可能提出的问题来推导数据模型。然后规范它，并且在你的原型上不断迭代。

做好变迁的准备。到达的数据有多种形式，新来源会频繁、不可预计地出现。通过使用一个初始的360°视图，你有可能会启动能够创建更多数据的分析，或者将会发现你确实应该收集的、其他额外类型的数据。幸运的是，MongoDB的动态模式使改进数据模型变得非常容易，而不必要在每次事情发生改变的时候都要重新设计。你的模式应该能够反映访问模式，如果你改变了使用数据的方式，你就应该准备好要么修改它的组织方式，要么使用多种方式存储数据。

提出问题。从提出问题开始。你如何定义你的数据模型结构依赖于你想获得什么。例如，如果你提出下面一系列的查询，你或许应该关注用户的360°视图：

客户做了什么不寻常的事？

什么是客户的同伴正在做而客户没有做的（但是应该做的）？

客户购买了什么产品，他将会在下周购买一些新产品的可能性是多少？

这周客户将会做什么？

客户告诉我们关于他自己、关于我们以及关于我们的产品什么信息？

我应该关注哪些客户，我应该向他们展示什么，为什么？

在我们“创建一个360°视图”博客系列的第一部分，我们讨论了如何修改你的数据模型以适应MongoDB中的360°视图、你将得到的益处以及你应该如何开始创建一个360°视图。在下周的第二部分，我们将了解模式的一般形式，并且列举一些真实的JSON。

同时，你可以下载白皮书以了解更多关于MetLife如何使用MongoDB构建一个360°用户视图的案例。

现在开始了解MetLife

本文译自Eric Holzhaue的英文博客：https://www.mongodb.com/blog/post/creating-single-view-part-1-overview...。 Eric Holzhauer是MongoDB的产品经理。