為什麼會有這一篇文章？
在筆者過去幾年的資料分析系統的開發中，接觸了大量的訂單次元的不同狀态流轉情況下的資料分析，在最近的實戰中，發現可以跳出業務系統，在高階的抽象層面，落地一套東西，這一套設計和業務無關，說白了，任何業務的單據的不同狀态流轉的多元分析，都可以用這一套思路落地，如果對你有用，最好，如果無用，就當抛磚引玉了
什麼是資料分析的模型？
資料分析的模型，在我看來是資料分析的最高階的抽象，可能不是java中的object，可能不是db中的表，但是在無形之中指導者我們的系統設計
筆者在做系統設計的時候，覺得事件+有限狀态機，能夠解決大部分的業務單據不同狀态流轉的問題，遂在原先系統設計的基礎上做了抽象，如果你也遇到類似的問題，可以參考，基于這個可以做很多事情
已有的模型有哪些，這裡做幾個簡單的介紹
漏鬥模型
例如一個典型的購物路徑，使用者可能經曆下面幾個環節
商品詳情頁浏覽，添加商品進入購物車，購物車點選結算，進入訂單确認頁面進行确定，跳到付款頁面進行付款
這些過程中，是比較典型的一個漏鬥的模型，在向下走的過程中，使用者肯定越來越少
事件模型
使用的比較多的一個模型，什麼事件？已經發生的一件事情
比較典型的，例如登陸事件，浏覽事件
基于這個事件資料，可以做多個次元的分析，最簡單的是統一一天的使用者數以及頁面浏覽數
路徑分析模型
順着剛才的事件模型向下走，使用者在浏覽特定網站的時候，會從一個頁面跳轉到另外一個頁面，如此反複
在做精細化網站分析的時候，需要了解使用者的路徑，友善網站本身做優化以及更新
基于上面的描述，我們一步一步的走向優先狀态機模型的鍊路分析
什麼是事件驅動？
所謂事件，表示已經發生的一件事，然後這件事件驅動後面的流程，在系統架構中，eda更多的是異步化，通過消息來包裝事件，之後做事情，例如“訂單付款事件”，這個事件發生之後，廣播出來，物流的系統要根據付款事件去發貨，廣告的系統要根據付款來結算廣告費用等等(純yy，如果業務不對，請指正哈哈)；
誰在什麼時間在那裡做了什麼事情
具體落地到各個系統中的時候，可能有取舍或者個性化，例如where，有個設計可能是業務的類型，有的可能是地域資訊；
比較典型的一個事件的案例？
這裡copy一下神策分析網站上的事件的抽象定義
誰在什麼時間在哪裡用那種方式做了什麼事情
who：即參與這個事件的使用者是誰
when：即這個事件發生的實際時間
where：即事件發生的地點，更多是區域資訊的記錄
how：即使用者從事這個事件的方式。這個概念就比較廣了，包括使用者使用的裝置、使用的浏覽器、使用的app版本、作業系統版本、進入的管道、跳轉過來時的referer等
what：描述使用者所做的這個事件的具體内容，這個可能根據不同的業務有不用的形式，可以通過幾個核心的屬性來描述清楚一件事
什麼是狀态機？
有限狀态機（finite-state machine）是一個非常有用的模型，可以模拟世界上大部分事物
特征一：狀态總數（state）是有限的
特征二：任一時刻，隻處在一種狀态之中
特征三：某種條件下，會從一種狀态轉變（transition）到另一種狀态
多元度的分析
處于特定事件狀态的單據的數量，例如狀态為“完成發貨事件”，則處于發貨事件的訂單數量是多少
處于特定事件狀态的單據，超過特定時間的數量，例如狀态為“付款事件”，則會有一種場景，就是逾時未付款的數量
狀态之間流轉，例如a狀态到b狀态，平均用時多久，這樣時效類的就能獲得到了，例如“建立訂單”到“支付訂單”的資料，我們能夠得到平均付款時間等
舉例說明整個過程
我們的資料是這樣的形式
計算邏輯可以采用storm的的流式計算來搞定
計算的結果存儲在線上的db中，對外提供查詢服務
什麼是lamdba架構？
一套方法論，說白了就是一套概念，但是在系統架構設計的時候，有非常大的借鑒意義
這套架構的必選條件
對于硬體的問題以及人為失誤的高容錯性
支援使用者多元度的查詢以及更新，且保證性能
線性擴充性，也就是當出現瓶頸的時候，能夠通過增加機器來實作
在系統維護以及添加新功能上良好的擴充性
通過最高層階看lamdba架構
batch 層，做兩件事情
管理整體的資料集合，不可變行級别的資料進行追加，類似離線的資料倉庫
對于查詢的需求做一些預加工
server 層
對于batch views和real timeview的查詢的服務提供者
speed 層
針對流動的實時資料，做多元度的加工處理
單獨從一個訂單次元看，似乎沒啥意義
但是如果從事件存儲次元做抽象，計算過程統一
這樣，任何單據的狀态事件變更，都可以在這套計算體系落地了
例如采購單、交易訂單、物流單、支付訂單等等