關于用戶行為幾類大數據計算_數據分析師

用戶行為類數據是最常見的大數據形式，比如電信的通話記錄、網站的訪問日志、應用商店的app下載記錄、銀行的賬戶信息、機頂盒的觀看記錄、股票的交易記錄、保險業的保單信息，連鎖超市會員的購物信息、交通違法信息、醫療就診記錄。

用戶行為類數據的特點在于用戶數量龐大，但每個用戶的行為數量較小，針對用戶行為的計算較為復雜，用戶之間的關聯計算相對較少。

用戶數量龐大。通話記錄中的電話號碼、訪問日志中的用戶編號、賬戶信息中的銀行賬戶、交易記錄中股票賬戶、保單信息中的被保險人，這些都是用戶行為類數據中的用戶。用戶的數量通常都很龐大，多的可達億級或更多，少的也有百萬級。

每個用戶的行為數量較小。相對于龐大的用戶數量，每個用戶的行為通常較少。對單個電話號碼來說，平均每月的通話記錄只有數百條，每年也不超過一萬條。即使是網站的活躍用戶，他們每天最多也只能產生上百條行為記錄，每年不超過十萬條。

用戶行為的計算較為復雜。計算用戶的兩次登錄間隔天數、反復購買的商品、累積在線時間，這些都是針對用戶行為的計算，通常具有一定的復雜性。

用戶之間的關聯計算較少。用戶的行為相對獨立，一般不需要知道其他用戶即可實現計算。相應的，用戶之間的關聯計算則較少，比如：某人通話記錄中接聽電話的一方的通話時長；社交網站上某個用戶的朋友購買了哪些商品，這些計算存在但不多。

根據用戶行為類大數據的特點不難看出，其最直觀最容易寫出的算法可以這樣設計：每次將某一用戶的所有數據一次性加載到內存中來計算，而不要反復訪問硬盤讀取某個用戶的部分數據，也不要將大量用戶的數據同時加載到內存中。

將某一用戶的所有數據加載到內存中來計算。這樣做是因為用戶之間的關聯計算少，而單個用戶行為的計算較為復雜，計算同一個用戶的數據可以讓程序員減少不相干數據的干擾。比如計算某用戶反復購買的商品。首先，將某用戶的數據按商品分組匯總出每件商品的購買次數；再按次數逆序排序；過濾掉只購買了一次的商品，剩下的就是反復購買的商品及購買次數。再比如計算某用戶的累積在線時長。該用戶會訪問多次，每次都會形成一對登錄和退出，因此先要過濾出所有的登錄和退出記錄；再針對每一次訪問，用退出時刻減去登錄時刻，這就是單次時長；將多個單次時長相加，就是累積時長。

另外，因為每個用戶的行為數量相對較少，完全可以全部加載進內存進行自由靈活的計算。

不要反復訪問硬盤讀取用戶的部分數據。由于用戶的行為計算比較復雜，同一個用戶的各條數據之間是存在關聯關系的，讀取一個用戶的部分記錄去計算會導致算法難寫，而且性能很低。

不要將大量用戶的數據同時加載到內存中。由于用戶數量龐大，顯然不可能將全部用戶的數據一次性加載到內存中來，必須要分批讀取。分批的標準上面已經分析出來了：按用戶分批。至于用戶之間計算結果的合并，可以留到最后一步再做，由于用戶之間關聯計算少，這個合并非常簡單。比如計算所有用戶反復購買的商品或累計在線時長，只要計算出每個用戶反復購買的商品或累計的在線時長，再將所有用戶的計算結果簡單合并就可以。另外還可以看出，由于是用戶之間的關聯少，因此此類算法很適合使用并行計算，即每個節點機分配一定數量的用戶，這樣既不會增加難度又能大幅提高性能。

將同一用戶的所有數據加載到內存中來計算，這就需要事先將數據按用戶分成多個組。比如按零售店會員分組，每個組就是某個會員對應的多條采購記錄；或按用戶編號分，每個組是某個用戶對應的網頁訪問記錄。分組的實質是排序，即將數據按用戶排序，使同一個用戶的數據挨在一起?？梢韵胂蟮?，對億級的用戶、每用戶萬級的數據排序將是個非常緩慢的過程。事先排序可以加速分組的過程。

將數據事先按用戶排序，不同的計算目標都使用同樣排序好的數據。將排序的時間花在前面而且只花一次，這就可以避免計算時的大排序，參數不同的同一個計算目標也可以重復計算而不必重復排序，不同的計算目標還可以省去相同的排序過程。

但是，不幸的是，一般的計算工具難以實現上述算法，無法有效利用事先排序的數據。比如SQL（含Hive）和MapRreduce。

SQL的困難。SQL的集合是無序的，事先按索引重新插入排好序的數據往往不能被優化器正確優化，具有很大的偶然性，無法保證查詢時可以按排好的次序查詢出需要的數據。

Hive具有SQL的語法風格，同時也支持并行計算，但它卻并不適合用戶行為類大數據計算。這是因為用戶行為的計算較為復雜，需要窗口函數甚至存儲過程來解決，而Hive只支持基本的SQL語法，不支持窗口函數和存儲過程。

用戶行為的計算之所以較為復雜，是因為需要對同一個用戶的多條數據之間進行計算，這種計算大多和順序相關。SQL對有序計算的支持有限，只有窗口函數可以實現部分簡單的有序計算，但對于復雜的業務邏輯仍然顯得非常繁瑣，而且經常因為大排序造成低下的性能。使用程序性的存儲過程編寫復雜代碼可以實現復雜的有序計算，但很難復用SQL的集合運算能力，所有處理都有從基礎運算自己編寫，而且其性能通常比SQL更低。

MapReduce的困難。MapReduce支持大數據并行計算，同時它是用程序性的JAVA語言來編寫的，這一點和存儲過程有相似性。但是，MapReduce所使用的 JAVA語言缺乏針對結構數據計算的類庫，所有的底層功能都要自己實現：分組、排序、查詢、關聯等等，對于有序計算這較復雜的算法所要書寫的代碼更多、編寫難度更大、維護更加困難。同樣的，MapReduce也無法利用已經排序好的數據，在shuffle階段還需要得做大排序。

SQL和MapReduce無法利用事先排序好的數據，難以高性能地將同一用戶的所有數據加載到內存中來計算，用戶類大數據計算因此會遇到性能、擴展性和開發難度的挑戰。

如何利用事先排序好的數據，以此簡化代碼書寫難度并提高計算性能？

集算器是支持多節點并行計算的程序設計語言，并提供豐富的有序計算。如果數據事先排好序，集算器支持通過游標來按組讀取數據，每次讀取一組數據進內存，避免反復的外存訪問，整個數據只要遍歷一次即可，從而使性能大大提高。針對組內計算復雜，集算器具有完備的批量化數據計算類庫，可以輕松實現各類復雜的有序計算。。

集算器支持靈活自由的多節點并行計算，可以進一步優化性能。方法之一將用戶按某種方式分段，以此實現分布存儲后的高效并行處理。比如將會員零售數據按照會員編號的前兩位分成100段存儲于HDFS，每段存儲十萬會員的一億條數據?；蛘邔⒕W站日志按照用戶ID的首字母和年份分段，每段存儲幾百萬用戶的數據?；蛘邔⑼ㄔ捰涗洶凑諈^號和用戶數量合并為30段，每段存儲一個州或幾個州的用戶。經過分段處理后，每段數據都是排好序的，可被節點機的一個線程獨立處理，這樣的并行計算性能更高。

針對上面的難點，下面用”每個用戶在每種產品上的累積在線時間”為例來說明集算器的一般解決辦法。

大分組的困難：事先排序數據，以供多種計算目標使用。在節點機運算時可以直接按用戶分組取數，有效利用已經有序的數據以提高性能。