建立一個360°檢視 第一部分:概述&資料分析

NO IMAGE
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

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

相關文章

資料庫 最新文章