神策數據技術VP付力力親述產品架構演變：變與不變的背后思考

　 阿里云優惠券 先領券再下單

本文作者：付力力，神策數據聯合創始人&技術VP

付力力畢業于北京理工大學軟件工程專業，2008年至2013年期間歷任百度新產品研發部、網頁搜索部、基礎架構部工程師。2013年9月年至2014年8月擔任豌豆莢數據部門資深研發工程師。2014年9月至2015年4月擔任黃金錢包技術合伙人。2018年8月，榮登“2018福布斯中國30歲以下精英榜”。

2015年9月神策數據正式發布了神策分析1.0版本，在隨后的3年里，我們的產品研發團隊一直在不斷地進行版本迭代，到目前為止一共發布了12個大版本。

相比于最初的1.0版本，現在的神策分析無論是在產品體驗還是在底層架構上都已經發生了很大的變化：

從最初只能使用3個單薄的基礎分析功能，到現在支持10個分析模型聯合構建的場景化分析能力;從最初只能支持每天數萬日活的小App，到現在可以輕松應對一天產生數百億的數據量巨型App。

而另一方面，3年內，神策分析里也有很多地方沒有改變：

例如，從第一版的設計里就確定了模型的Event-User，該模型現在依然是整個神策分析里最基礎和重要的概念。

在這篇文章里，我給大家介紹神策分析最近在底層架構上一些比較大的設計改進，同時也會分享我們在這些架構設計中關于“變”與“不變”的思考。

一、從SQL查詢引擎到用戶行為分析引擎

我們之前在很多場合都對神策分析的底層架構做過詳細的介紹，這個架構的主要特點之一是：

神策所有的分析結果都是從明細數據實時查詢得出，而不是基于大多數分析系統所使用的預計算技術，之所以這么設計，因為我們希望系統數據分析能力的上限在于數據本身。

換句話說，我們期望只要是從已經采集的數據里可以分析得到的結論，神策都希望可以幫助我們的客戶很容易的實現。

從結果看來，這種架構設計的好處是非常顯著的：

它大大簡化了整個系統的數據流，我們不需要為不同的分析模型來維護復雜的聚合表，并在數據回溯的時候保持這些數據之間的一致性(大多數類似的數據系統里要么拋棄數據回溯的能力，要么放棄數據一致性)。

受益于這種架構，我們在很短的時間內推出眾多靈活的分析模型，并且這些分析模型之間可以通過分群等方式來進行自由的組合查詢。

同時，配合我們開發的查詢緩存機制，這套架構也可以在報表等相對固定的數據分析需求上得到比較好的使用體驗。

當然，這種設計的另外一個結果是，神策分析很明確地拋棄了對高QPS查詢需求的直接支持(例如不應該嘗試在商品詳情頁里直接從神策分析獲取這個商品本周的銷量)。

不過，整體上我們認為，犧牲一個非必要的特性來換取數倍的分析靈活性以及一個簡單可維護的架構，是一個非常劃算的選擇。

在這套架構里，Impala作為我們使用的數據查詢引擎，可以說是一個非常核心的模塊。

在最初的設計選型上我們選擇Impala，一方面是因為Impala已經是一個相對比較成熟的MPP架構的查詢引擎，而且對SQL有著比較良好的支持。另外一方面則是因為我們的研發團隊在Impala的使用和二次開發上有著比較多的經驗。

其中，是否支持SQL是一個很重要的選型依據。雖然SQL是一種有著幾十年歷史、至今也沒有太多變化的古老工具，但是到目前為止它依然是對表格數據進行操作的最佳選擇，在易用性和靈活性之間做到了比較好的平衡。

更重要的是，我們當初經過簡單的調研發現，只使用SQL就可以很好的實現一個用戶行為分析系統的大部分需求，除此之外，還可以通過UDF/UDAF/UDAnF等增加擴展能力，則幾乎可以滿足所有常見需求。

事實上，在神策分析比較早期的版本里，所有的分析模型都是用標準SQL直接實現的。

隨著我們產品功能的增加，我們為了滿足越來越復雜的分析模型和更高的性能指標，也對Impala做了很多改造。

不過，在這個過程中，SQL自身的描述能力和Impala執行架構的局限性也逐漸暴露出來，例如我們很難像Spark的DAG模型一樣來靈活的控制SQL的查詢計劃，導致一些復雜查詢的性能不佳，以及在一些組合分析的場景下沒有辦法很容易的復用查詢的中間結果。

因此，我們開始基于Impala構建一個全新的查詢引擎。通過對已有的各種分析模型計算過程的理解，我們發現它們幾乎都可以被抽象為如下的計算過程：

1.篩選出特定時間范圍內的特定Event數據，如果查詢還涉及到User/Item，那么還需要再次進行Join操作，最終得到：List;

2.對List按照Event中的用戶ID進行Shuffle，并按時間排序，最終得到每個用戶ID的有序Event序列：(User Id,List);

3.對(User Id,List)中的每個UserId的List應用具體的分析模型規則，例如漏斗、留存等，得出每個用戶ID的中間計算結果，如下：(User Id,IntermediateResult);

4.對(User Id,IntermediateResult)進行最后一次聚合，得到最終的結果。

不難看出，上述計算過程中最核心的難點在于如何快速的得到(User Id,List)，這中間可能涉及重排序和大數據量的Shuffle等操作。對于需要Join User/Item表的查詢，Join本身的性能也可能會成為瓶頸。

我們基于Impala原有的執行框架，在底層存儲和查詢邏輯上做了一系列的優化，最終實現的分析引擎相比于原有的方式在復雜查詢的執行性能上有10x的提升，同時由于開發方式的簡化，也直接加速了我們對各種復雜分析模型的迭代速度。

在后續的文章中，我們會詳細介紹這個面向用戶行為分析的查詢引擎的具體優化細節。

二、模型擴展：從Event-User到Event-Item-User

在神策分析最初的設計階段，我們就確定了以Event-User為核心的邏輯數據模型，可以說，Event-User模型是整個神策分析架構的基礎。

3年以來，神策分析在數百家不同行業的客戶的實踐結果也充分證明了這個模型的適應能力。

所有的數據模型本質上都是對現實世界的抽象，而在抽象之后必然會損失一些對現實世界的還原能力。

所以Event-User模型雖然在電商、金融、在線教育、互聯網娛樂、企業服務等不同的行業上都發揮了很好的價值，但是隨著客戶需求的不斷深入，尤其是在和具體行業業務的深入融合中，我們也逐漸發現了這個模型的一些缺點。

例如在Event-User模型中，出于性能和可解釋性等各方面的考慮，Event是被設計為不可變的。從邏輯上看似乎沒有問題，因為Event代表的是歷史上已經發生過的事件，一般來說不應該需要進行更新。

但是，在實際的應用過程中，并不一定是這么理想的狀態。

例如，在很多客戶進行埋點采集的過程中，他們會發現某些Event在最初的階段并不能很容易的采集到完整的數據。

比如一個電商客戶，在客戶端App里采集“商品加入購物車”事件時，只能采集到商品的ID、名稱等基本信息，而對于后續分析需要的更多維度，例如商品的分類、促銷的活動信息等等，則不一定能很容易的采集到(通常這些信息都是客戶端在業務中沒有使用到的，如果想要采集，則需要對服務端API、客戶端內部的信息傳遞都做比較大的修改)。

又或者是等到真正需要分析的時候，才發現當初的采集是不完備的，這個時候想再把歷史數據補上就是一件非常困難的事情。

還有另外一種比較常見的場景。某個在線教育的App中會有很多和課程相關的事件，例如對課程的瀏覽、購買、學習等，而關于課程的一些基本信息中會有許多是不斷變化的，如課程的分類、定價等等。

在Event里記錄的，應當是Event發生的時刻這個課程的狀態，例如一個購買課程的事件，我們可以記錄下來當時課程的分類、價格屬性，作為Event的一部分。而課程的分類、定價后續可能會隨著業務的需要隨時調整，如果業務方希望按照最新的(或者某個特定階段的)課程分類或者定價來分析用戶的歷史行為，則是一個難以完成的需求。

從技術上來看，解決上述問題的方案并不復雜。很多熟悉數據倉庫的朋友可能會發現，這些其實是在傳統數據倉庫里比較典型的維度表的問題，可以使用經典的雪花模型或者星型模型來輕松解決。

但是，我們并不希望引入這么復雜的模型，畢竟神策分析的設計目標并不是一個通用的數據倉庫。雖然靈活性是神策分析最核心的設計目標之一，但也是建立在"用戶行為分析"這個目標的基礎之上的。

我們期望的一個理想方式是：對數據模型增加一點有限的復雜性，但是可以給整個系統帶來十倍甚至百倍的靈活性提升。

為了滿足上述需求，我們在新版的神策分析中對Event-User模型進行了擴展，引入了Item的概念。這里的所謂Item，在嚴格意義上是指一個和用戶行為相關聯的實體，可能是一個商品、一個視頻劇集、一部小說等等。

如果不嚴格約束的話，理論上它也可以存儲其它任意的擴展維度信息。

在具體的技術實現上，我們允許客戶定義多個不同的Item實體，例如電商有商品、配送點等不同的實體。

在使用前，客戶要定義這些實體，并且把這些實體的數據通SDK發送到神策分析系統中，自動建立起一個或者多個Item表。然后，出于不同性能要求和業務需求的考慮，對于Item表的使用我們提供了不同的兩種方式。

第一種方式，客戶在進行Event埋點時，可以選擇要進行關聯導入的Item信息。

例如有一個“商品加入購物車”的事件，這個事件里只采集了“商品ID”，但是同時因為我們事先已經定義好了“商品Item”，那么通過“商品ID”則直接可以先把Event和“商品Item”進行關聯，再把“商品Item”的某一些屬性作為Event的一部分進行直接導入。

使用這種方式，可以在最大程度滿足業務分析的情況下簡化客戶端對數據采集的工作，同時在查詢性能方面也不會有任何下降。

第二種方式，更類似于傳統數據倉庫的維度表。

我們在埋點時不做任何變動，而是在需要進行查詢的時候，把Item表加入進來。

這種方式會有更好的靈活性，因為可以在Event發生之后對數據進行擴展，也可以支持隨時使用最新的Item數據進行分析，但是另外一方面，這么做并不能很好的保留事件發生當時的某些狀態，而且由于需要在查詢的時候進行實時的數據Join，也不可避免的會降低查詢性能。

在把Event-User模型擴展為Event-Item-User模型之后，神策分析對復雜業務場景有了更好的支持，無論是在埋點工作的簡化還是在分析能力的提升上都有非常直接的幫助。

后續我們也將繼續在簡化Item數據的接入和使用上做出更多的改進。

三、用戶分群的進化

從2年前的神策分析1.4版本開始，我們引入了用戶分群功能。從架構層面，我們主要做了兩件事情：一是把分群的概念引入了我們的數據模型中，二是提供靈活、便利的定義分群規則的方式。

對于第一點，我們把分群看作是用戶屬性的一部分，只不過這個屬性是根據用戶已有的行為特征計算出來的，是一個衍生屬性。所以在數據模型上，分群其實是對Event-User模型中User部分的一個擴展。

當然，在物理存儲上，由于分群具有頻繁更新、整體刪除等特點，因此并不會直接和原有的用戶屬性信息存儲在一起，而是采用獨立存儲的方式。

對于第二點，一方面，我們提供了一套描述規則，允許客戶直接從UI上定義比較復雜的分群：在某段時間做過某個Event幾次，或者完成了某個連續的Event序列等。

更重要的是，我們把所有已有分析模型的用戶列表功能都看作為是分群規則定義的一部分，這種方式使得客戶可以很容易的把各個分析模型的結果進行組合，產生1+1>2的效果。

整體上來看，神策分析1.4在引入分群的概念之后，架構上幾乎沒有做任何大的改動，就可以讓所有的分群和普通的用戶屬性一樣在任何的分析模型里直接使用。

這個也是完全得益于前文提到的實時分析架構，以及具有良好擴展能力的Event-User模型。

隨著客戶對神策分析的使用場景越來越復雜，我們的客戶對分群功能也提出了更多的需求。

一個比較顯著的問題是：現在的神策的每個分群只能保存一個最新的結果，而不能查看歷史的狀態。

比如在一個電商產品里，我們可以很容易的建立一個"日購買金額>=300"的用戶分群，但是這個分群每天都會自動刷新，并且會丟掉前一天的狀態。

如果我們想分析這個用戶分群在時間軸上的變化趨勢，或者考慮一個更復雜的場景，想分析“日購買金額>=300”的這個用戶群體在當天購買的商品品類的分布情況，用現在的分群功能都是沒辦法直接實現的。

為了實現上述功能，我們在即將發布的1.13版本也對用戶分群功能做了一次大的改進。

首先在數據模型上，我們擴展了分群的模型定義，加入了時間維度。即每個分群不只是代表這個分群的群體在某一時刻的狀態，而是可以保存每天、每周等不同時間點下的狀態。

其次，我們也進一步增強了分群的描述能力，除了增強了在UI上進行定義的功能之外，還允許用戶直接上傳分群好的結果(例如某個線下活動的用戶列表)，或者是從一個SQL結果導出成一個分群，避免讓分群的能力受限于已有的規則定義。

另外，在分群的計算執行層面，我們也不再使用獨立的MapReduce程序來進行，而是復用了上面提到的基于Impala的用戶行為分析引擎。

因為分群的過程，其實也是一個很典型的用戶行為分析的計算邏輯，這樣就很自然的把整個神策系統內對于用戶行為的分析都統一到了一個計算模塊上來完成。

四、更精確的用戶標識體系

如何準確地標識用戶一直是用戶行為數據系統中的一大難題。在過去的3年里，我們在客戶端SDK、服務端架構、數據接入的解決方案支持上做了持續的優化，解決了很多普遍的問題。

傳統的網站或者App分析工具，通常以Cookie或設備號作為用戶(其實是設備)的標識，同時這些分析工具大部分也并不支持跨端的分析，所以關于用戶標識導致的各類問題并不突出。

但是在今天的用戶行為分析場景中，準確的跨端標識用戶變成了一個非常迫切的需求。尤其是在微信生態的情況下，一個自然人用戶在App、小程序、H5、公眾號之間反復跳轉，完成一系列行為是非常常見的場景，如果不能做到準確的標識用戶，很多數據分析的需求將會無法準確完成。

在神策分析1.13版本之前，為了解決跨端標識用戶的問題，我們提供了有限度的多設備用戶關聯體系。

這里的“有限”主要體現在一個注冊用戶在未登錄狀態下只能跟一個設備進行綁定。很顯然，在很多場景下這種關聯并不能很好的滿足需求。

最典型的場景是，如果一個老用戶更換了新的設備，那么他在這個新設備上未登錄狀態下的操作將會被識別為一個全新的用戶，從而對某些分析結果的準確性產生影響。

因此，我們在最近的1.13版本提供了一個注冊用戶跟任意多個設備進行關聯的機制。在這個新的機制下，一個注冊用戶可以使用多個設備進行登錄，并且他在這些設備上注冊/登錄前后的行為都會被準確的識別到同一個用戶身上，從而能在神策分析里更準確的還原一個用戶的行為序列。

當然，這個在新的關聯機制也并不是提供無限的靈活性?？紤]這樣一個場景：一個設備先后被多個注冊用戶登錄使用，那這個設備上產生的匿名行為(即非登錄狀態下產生的行為)只會被關聯到第一個在這個設備上登錄的注冊用戶。

雖然在技術上我們也可以很容易的實現用戶和設備之間的多重綁定，但是考慮到實際的應用場景并不常見，而且提供這種機制之后一定會給客戶帶來的更多理解上的復雜性，我們還是決定把新的關聯機制限定在一個注冊用戶多個設備的場景下。

全新的用戶標識體系雖然可以更準確地標識用戶，但是同時也會引入一個新的問題：允許一個注冊用戶和多個設備進行關聯，會導致歷史數據的分析結果是不斷變化的。我們可以看一個具體的例子，假設一個用戶X進行了一系列操作：

7月1日之前在設備A上注冊、登錄并使用App

7月2日開始在設備B上使用App

7月5日在設備B上使用之前的帳號進行登錄，并繼續使用

我們可以看到，在7月5日之前，神策分析并不知道使用設備B跟設備A背后都是用戶X在操作，也就是說在這之前計算用戶數都會是2，同時在計算留存、漏斗等數據時也都會當作兩個不同的用戶。

而一旦到7月5日用戶X登錄了，神策分析可以知道之前的行為其實都是同一個人X產生的，那么這個時候再看7月5日之前的用戶數也會變成了1。

這種數據的變化在某些場景下可能會變得更加難以理解，我們假設一個比較極端的情況，如果上面的用戶X是在一年之后才在設備B上進行登錄，那么這一年內設備B所產生的行為是否都應該視作用戶X產生的?現實情況下可能是，也可能不是，只憑借這些信息很難做出準確的判斷。

本質上，新的用戶標識體系是實現了對歷史數據的修正，同時由于神策分析又是一個完全基于明細數據進行實時查詢的分析系統，因此數據分析的結果跟著發生變化也是很自然的事情。

正如我們在上文的Event-User模型擴展中提到的，雖然Event代表的是已經發生的事件，但是依然會有一些信息在Event發生的當時是無法得到的。

比如在上面的例子中，7月2日當天我們并不知道在設備B上使用的也是用戶X，只能在3天之后再對這個數據進行修正。我們在一定程度上破壞了Event的不變性，但是也帶來了更高的數據準確性。

不過，除了技術上的難點，歷史數據的變化還會給數據的可解釋性造成比較大的影響：很多人都會對昨天甚至更早的數據報表會發生變化產生困惑。

因此，如何在提高數據準確性的同時降低客戶對數據的理解難度，會是我們后面的重點方向。

關于神策數據

神策數據(https://www.sensorsdata.cn)，是一家專業的大數據分析服務公司，致力于幫助客戶實現數據驅動。公司推出深度用戶行為分析平臺神策分析(Sensors Analytics)，支持私有化部署、基礎數據采集與建模，并作為PaaS平臺支持二次開發;同時推出基于行為數據的客戶全生命周期分析平臺神策客景(Sensors Journey)，創造性將用戶行為數據融入客戶全生命周期的管理與分析，實現客群健康度分析，流失預警等重要價值，并應用到企業服務、工具軟件等多個領域。

此外，還提供大數據相關咨詢和完整解決方案。神策數據積累了中國銀聯、中國電信、百度視頻、百聯、萬達、小米、中郵消費金融、廣發證券、中原銀行、百信銀行、聚美優品、中商惠民、紛享銷客、Keep、36氪、中青旅、太平洋保險、平安壽險、鏈家、四川航空等500余家付費企業用戶的服務和客戶成功經驗，為客戶全面提供指標梳理、數據模型搭建等專業的咨詢、實施、和技術支持服務。希望更深入了解神策數據或有數據驅動相關問題，請撥打4006509827電話咨詢，會有專業的工作人員為您解答。

申請創業報道，分享創業好點子。點擊此處，共同探討創業新機遇！