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

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

本系列的三篇博客將會提供一個關(guān)于在MongoDB上構(gòu)建360°視圖的介紹。第一部分包括一個360°視圖示例以及在構(gòu)建360°視圖時需要考慮的要點概述，第二部分將介紹一個示例數(shù)據(jù)模型的實現(xiàn)，第三部分將深入探討如何將數(shù)據(jù)遷移到MongoDB的機(jī)制。

那么，什么是360°視圖呢？或許你也聽過術(shù)語——數(shù)據(jù)總線、360°視圖或者多渠道顯示。所有的這些術(shù)語都描述了一個從多個分離的數(shù)據(jù)源收集數(shù)據(jù)并且將其整合到一起以提供一個360°視圖的系統(tǒng)——這就是所謂的“360°視圖”。什么對象的360°視圖呢？答案是：任何潛在的、你希望的對象。通常，人們指的是一個“單用戶視圖”。但是，或許你還想創(chuàng)建一個關(guān)于業(yè)務(wù)線、產(chǎn)品、雇員、資產(chǎn)或者其它數(shù)不清可能對象的360°視圖。接下來，我們將在這里主要討論一個用戶的360°視圖，但是相同的原則也適用于其它任何一個對象的360°視圖。

為什么你會需要一個數(shù)據(jù)的360°視圖？大部分公司對它們的數(shù)據(jù)都會有一個復(fù)雜的處理過程：經(jīng)常包括來自于多個數(shù)據(jù)源多種結(jié)構(gòu)數(shù)據(jù)的讀取、轉(zhuǎn)化，然后載入到一個操作型數(shù)據(jù)庫，然后再提供給需要這些數(shù)據(jù)的應(yīng)用程序。通常，其中的分析、商業(yè)智能以及報表服務(wù)都有可能需要從一個多帶帶的數(shù)據(jù)倉庫中讀取數(shù)據(jù)。當(dāng)然，所有的這些層次都需要與安全協(xié)議、信息管理標(biāo)準(zhǔn)以及其它相兼容。

不可避免地，信息最終會被擱淺在“數(shù)據(jù)孤島”中。系統(tǒng)構(gòu)建的目的都是為了滿足當(dāng)前的需求，或者某一個特定的應(yīng)用需要一個特定的數(shù)據(jù)結(jié)構(gòu)。 突然有一天，你發(fā)現(xiàn)同一個用戶的數(shù)據(jù)被存到了許多不同的互不聯(lián)通的地方。

為什么你想要把所有分離的數(shù)據(jù)放在一起？不僅僅是為了每個數(shù)據(jù)都可以與它的同類數(shù)據(jù)在一起。360°視圖的用戶案例可以存在于任何一個你可以想象的地方：

任意選擇一個行業(yè)，你可以發(fā)現(xiàn)無數(shù)商業(yè)理由需要將分離的數(shù)據(jù)進(jìn)行整合。360°視圖就是使用用一種最合適的方法處理數(shù)據(jù)并且用一種你從未用過的方式觀察它。

好的，上面已經(jīng)有足夠多的商業(yè)說法了。讓我們假設(shè)你已經(jīng)有創(chuàng)建一個360°視圖的想法了。你如何著手開始呢？

讓我們以一個網(wǎng)絡(luò)平臺的零售商為例。分離的數(shù)據(jù)世界或許是這樣的：

傳統(tǒng)思維模型

在這里，你可以看到許多不同類型的數(shù)據(jù)。藍(lán)色的框代表你的客戶及他們相關(guān)的信息。而綠色的框則代表外部數(shù)據(jù)：包括你通過支付第三方而得到的信息——情感分析、人口統(tǒng)計信息等。紫色代表你的產(chǎn)品信息。當(dāng)然，這些對象都通過用戶與產(chǎn)品交互的方式聯(lián)系了起來——包括留下評論及打分、下訂單以及瀏覽網(wǎng)頁等。

現(xiàn)在，這么多數(shù)據(jù)孤島以各種各樣不同的方式在邏輯上聯(lián)系在了一起。但是，通過觀察這些聯(lián)系，你可以發(fā)現(xiàn)兩個大類別——與客戶相關(guān)的信息以及與產(chǎn)品相關(guān)的信息。 注意這兩類數(shù)據(jù)不是互斥的。。

這是非常直觀的一個分組。因此，當(dāng)你將其轉(zhuǎn)化到一個新模型以支持MongoDB中的360°視圖時，你可以使用下面這種方式重構(gòu)數(shù)據(jù)模型：

在這里，你真正創(chuàng)建的是兩個360°視圖：一個是客戶的，一個是產(chǎn)品的。在以前的模型中，如果你想查看關(guān)于一個用戶的所有信息，你不得不從大概10個地方收集-—假設(shè)可能的話。而現(xiàn)在，你已經(jīng)將它們放置在了同一個地方，因此你可以快速、簡單地查看所有與一個給定用戶相關(guān)的信息。你可以在產(chǎn)品上做相同的操作，因此你可以馬上了解一個給定產(chǎn)品的運行情況。除了可以在同一個地方查看一個顧客或產(chǎn)品的所有信息，你也可以很容易地在整個類中統(tǒng)一工作。例如，查詢所有的顧客，找到在給定的郵編下購買了一個特定產(chǎn)品的用戶。

特別需要注意的是：你不需要將所有的相關(guān)信息都放置在同一個用戶對象中。當(dāng)你查看某用戶的360°視圖時，你是否真的需要過去十年內(nèi)他在你網(wǎng)站上的所有行為，或者所有他曾今推特過的所有有關(guān)你公司或產(chǎn)品的信息？也許沒必要。這并不意味著你丟棄所有的細(xì)節(jié)——無論如何，你應(yīng)該將它們進(jìn)行多帶帶的存儲，但是在用戶對象中，將其在一個可用的層次進(jìn)行總結(jié)也許非常有用。例如，過去30天內(nèi)的交易重點或者一個整合的情感分?jǐn)?shù)。

當(dāng)你決定如何合并的時候，問一下你自己：你希望如何使用數(shù)據(jù)來獲取什么有用信息。在這之前，訂單是多帶帶存儲的。但是每一筆訂單都與一個用戶相關(guān)，因此，在這里，我們將訂單數(shù)據(jù)嵌入到用戶對象中。另一方面，我們也許不需要在該顧客對象中存儲訂購產(chǎn)品的所有細(xì)節(jié)，因此，我們將其外鏈到了產(chǎn)品集合以避免重復(fù)。

一旦你使用這個方法重構(gòu)了你的數(shù)據(jù)，你可以做什么？讓我們詳細(xì)看一下用戶對象：

- 主要交易：通過交易數(shù)據(jù)，你可以了解最活躍或者最不活躍的客戶。
- 情感評分：基于情感評分，你可以進(jìn)行分析，從而了解情感如何隨著用戶其它數(shù)據(jù)改變。
- 訂單：訂單已經(jīng)以一種合理的方式嵌入，減少了數(shù)據(jù)模型的復(fù)雜度。
- 位置：除了賬單及配送地址，你可以基于IP或者移動位置做地理分析。
- 評論：你可以通過使用評論進(jìn)行本地的全文檢索以發(fā)現(xiàn)用戶產(chǎn)生的共同描述。
- 行為：在這里，你可以過濾和展示最重要的數(shù)據(jù)：例如，最近用戶做了某件事，因此客戶服務(wù)代表應(yīng)該準(zhǔn)備在與用戶進(jìn)行交談的過程中討論那件事。

在這里，我們還有許多關(guān)于新數(shù)據(jù)模型的問題。但是，我們應(yīng)該如何在MongoDB中提出相關(guān)的問題呢？讓我們來看一些例子，了解MongoDB的查詢。當(dāng)然，下面這些都是一些偽代碼案例，構(gòu)建屬于你自己查詢的方式需要依賴于你的數(shù)據(jù)模型。

這名顧客購買了什么類型的產(chǎn)品？

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

目前他們到某服務(wù)點的距離有多遠(yuǎn)？

find( “l(fā)ocation” : { $near : [40.8768, -73.787] } )

哪些是對我們服務(wù)最不滿意的前10名顧客？

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

我們的客服代表應(yīng)該在下次談話中提及什么？

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

保持專注，快速迭代。不要超出你的能力，試圖在一步內(nèi)就合并你所有數(shù)據(jù)。使用一些數(shù)據(jù)源作為概念驗證進(jìn)行一次重要嘗試?？紤]這些數(shù)據(jù)以及你有可能提出的問題來推導(dǎo)數(shù)據(jù)模型。然后規(guī)范它，并且在你的原型上不斷迭代。

做好變遷的準(zhǔn)備。到達(dá)的數(shù)據(jù)有多種形式，新來源會頻繁、不可預(yù)計地出現(xiàn)。通過使用一個初始的360°視圖，你有可能會啟動能夠創(chuàng)建更多數(shù)據(jù)的分析，或者將會發(fā)現(xiàn)你確實應(yīng)該收集的、其他額外類型的數(shù)據(jù)。幸運的是，MongoDB的動態(tài)模式使改進(jìn)數(shù)據(jù)模型變得非常容易，而不必要在每次事情發(fā)生改變的時候都要重新設(shè)計。你的模式應(yīng)該能夠反映訪問模式，如果你改變了使用數(shù)據(jù)的方式，你就應(yīng)該準(zhǔn)備好要么修改它的組織方式，要么使用多種方式存儲數(shù)據(jù)。

提出問題。從提出問題開始。你如何定義你的數(shù)據(jù)模型結(jié)構(gòu)依賴于你想獲得什么。例如，如果你提出下面一系列的查詢，你或許應(yīng)該關(guān)注用戶的360°視圖：

客戶做了什么不尋常的事？

什么是客戶的同伴正在做而客戶沒有做的（但是應(yīng)該做的）？

客戶購買了什么產(chǎn)品，他將會在下周購買一些新產(chǎn)品的可能性是多少？

這周客戶將會做什么？

客戶告訴我們關(guān)于他自己、關(guān)于我們以及關(guān)于我們的產(chǎn)品什么信息？

我應(yīng)該關(guān)注哪些客戶，我應(yīng)該向他們展示什么，為什么？

在我們“創(chuàng)建一個360°視圖”博客系列的第一部分，我們討論了如何修改你的數(shù)據(jù)模型以適應(yīng)MongoDB中的360°視圖、你將得到的益處以及你應(yīng)該如何開始創(chuàng)建一個360°視圖。在下周的第二部分，我們將了解模式的一般形式，并且列舉一些真實的JSON。

同時，你可以下載白皮書以了解更多關(guān)于MetLife如何使用MongoDB構(gòu)建一個360°用戶視圖的案例。

現(xiàn)在開始了解MetLife

本文譯自Eric Holzhaue的英文博客：https://www.mongodb.com/blog/post/creating-single-view-part-1-overview...。 Eric Holzhauer是MongoDB的產(chǎn)品經(jīng)理。