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

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

---

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

什么是“360°视图”以及应该关注的理由

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

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

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

为何你想要把全部分离的数据放在一块儿？不只仅是为了每一个数据均可以与它的同类数据在一块儿。360°视图的用户案例能够存在于任何一个你能够想象的地方：

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

360°视图数据模型

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

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

传统思惟模型

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

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

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

MongoDB思惟模型

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

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

当你决定如何合并的时候，问一下你本身：你但愿如何使用数据来获取什么有用信息。在这以前，订单是单独存储的。可是每一笔订单都与一个用户相关，所以，在这里，咱们将订单数据嵌入到用户对象中。另外一方面，咱们也许不须要在该顾客对象中存储订购产品的全部细节，所以，咱们将其外链到了产品集合以免重复。

我能够用360°视图作什么？

一旦你使用这个方法重构了你的数据，你能够作什么？让咱们详细看一下用户对象：

以用户的360°视图为例

- 主要交易：经过交易数据，你能够了解最活跃或者最不活跃的客户。
- 情感评分：基于情感评分，你能够进行分析，从而了解情感如何随着用户其它数据改变。
- 订单：订单已经以一种合理的方式嵌入，减小了数据模型的复杂度。
- 位置：除了帐单及配送地址，你能够基于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°视图

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

作好变迁的准备。到达的数据有多种形式，新来源会频繁、不可预计地出现。经过使用一个初始的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的产品经理。