建立一個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的產品經理。