摘要：第一部分包括一個視圖示例以及在構建視圖時需要考慮的要點概述，第二部分將介紹一個示例數據模型的實現，第三部分將深入探討如何將數據遷移到的機制。讓我們假設你已經有創建一個視圖的想法了。

本文源地址：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的產品經理。