用戶行為類數(shù)據(jù)的特點在于用戶數(shù)量龐大，但每個用戶的行為數(shù)量較小，針對用戶行為的計算較為復(fù)雜，用戶之間的關(guān)聯(lián)計算相對較少。
用戶數(shù)量龐大。通話記錄中的電話號碼、訪問日志中的用戶編號、賬戶信息中的銀行賬戶、交易記錄中股票賬戶、保單信息中的被保險人，這些都是用戶行為類數(shù)據(jù)中的用戶。用戶的數(shù)量通常都很龐大，多的可達億級或更多，少的也有百萬級。
每個用戶的行為數(shù)量較小。相對于龐大的用戶數(shù)量，每個用戶的行為通常較少。對單個電話號碼來說，平均每月的通話記錄只有數(shù)百條，每年也不超過一萬條。即使是網(wǎng)站的活躍用戶，他們每天最多也只能產(chǎn)生上百條行為記錄，每年不超過十萬條。
用戶行為的計算較為復(fù)雜。計算用戶的兩次登錄間隔天數(shù)、反復(fù)購買的商品、累積在線時間，這些都是針對用戶行為的計算，通常具有一定的復(fù)雜性。
用戶之間的關(guān)聯(lián)計算較少。用戶的行為相對獨立，一般不需要知道其他用戶即可實現(xiàn)計算。相應(yīng)的，用戶之間的關(guān)聯(lián)計算則較少，比如：某人通話記錄中接聽電話的一方的通話時長；社交網(wǎng)站上某個用戶的朋友購買了哪些商品，這些計算存在但不多。
根據(jù)用戶行為類大數(shù)據(jù)的特點不難看出，其最直觀最容易寫出的算法可以這樣設(shè)計：每次將某一用戶的所有數(shù)據(jù)一次性加載到內(nèi)存中來計算，而不要反復(fù)訪問硬盤讀取某個用戶的部分數(shù)據(jù)，也不要將大量用戶的數(shù)據(jù)同時加載到內(nèi)存中。
將某一用戶的所有數(shù)據(jù)加載到內(nèi)存中來計算。這樣做是因為用戶之間的關(guān)聯(lián)計算少，而單個用戶行為的計算較為復(fù)雜，計算同一個用戶的數(shù)據(jù)可以讓程序員減少不相干數(shù)據(jù)的干擾。比如計算某用戶反復(fù)購買的商品。首先，將某用戶的數(shù)據(jù)按商品分組匯總出每件商品的購買次數(shù)；再按次數(shù)逆序排序；過濾掉只購買了一次的商品，剩下的就是反復(fù)購買的商品及購買次數(shù)。再比如計算某用戶的累積在線時長。該用戶會訪問多次，每次都會形成一對登錄和退出，因此先要過濾出所有的登錄和退出記錄；再針對每一次訪問，用退出時刻減去登錄時刻，這就是單次時長；將多個單次時長相加，就是累積時長。
另外，因為每個用戶的行為數(shù)量相對較少，完全可以全部加載進內(nèi)存進行自由靈活的計算。
不要反復(fù)訪問硬盤讀取用戶的部分數(shù)據(jù)。由于用戶的行為計算比較復(fù)雜，同一個用戶的各條數(shù)據(jù)之間是存在關(guān)聯(lián)關(guān)系的，讀取一個用戶的部分記錄去計算會導致算法難寫，而且性能很低。
不要將大量用戶的數(shù)據(jù)同時加載到內(nèi)存中。由于用戶數(shù)量龐大，顯然不可能將全部用戶的數(shù)據(jù)一次性加載到內(nèi)存中來，必須要分批讀取。分批的標準上面已經(jīng)分析出來了：按用戶分批。至于用戶之間計算結(jié)果的合并，可以留到最后一步再做，由于用戶之間關(guān)聯(lián)計算少，這個合并非常簡單。比如計算所有用戶反復(fù)購買的商品或累計在線時長，只要計算出每個用戶反復(fù)購買的商品或累計的在線時長，再將所有用戶的計算結(jié)果簡單合并就可以。另外還可以看出，由于是用戶之間的關(guān)聯(lián)少，因此此類算法很適合使用并行計算，即每個節(jié)點機分配一定數(shù)量的用戶，這樣既不會增加難度又能大幅提高性能。
將同一用戶的所有數(shù)據(jù)加載到內(nèi)存中來計算，這就需要事先將數(shù)據(jù)按用戶分成多個組。比如按零售店會員分組，每個組就是某個會員對應(yīng)的多條采購記錄；或按用戶編號分，每個組是某個用戶對應(yīng)的網(wǎng)頁訪問記錄。分組的實質(zhì)是排序，即將數(shù)據(jù)按用戶排序，使同一個用戶的數(shù)據(jù)挨在一起。可以想象到，對億級的用戶、每用戶萬級的數(shù)據(jù)排序?qū)⑹莻€非常緩慢的過程。事先排序可以加速分組的過程。
將數(shù)據(jù)事先按用戶排序，不同的計算目標都使用同樣排序好的數(shù)據(jù)。將排序的時間花在前面而且只花一次，這就可以避免計算時的大排序，參數(shù)不同的同一個計算目標也可以重復(fù)計算而不必重復(fù)排序，不同的計算目標還可以省去相同的排序過程。
但是，不幸的是，一般的計算工具難以實現(xiàn)上述算法，無法有效利用事先排序的數(shù)據(jù)。比如SQL（含Hive）和MapRreduce。
SQL的困難。SQL的集合是無序的，事先按索引重新插入排好序的數(shù)據(jù)往往不能被優(yōu)化器正確優(yōu)化，具有很大的偶然性，無法保證查詢時可以按排好的次序查詢出需要的數(shù)據(jù)。
Hive具有SQL的語法風格，同時也支持并行計算，但它卻并不適合用戶行為類大數(shù)據(jù)計算。這是因為用戶行為的計算較為復(fù)雜，需要窗口函數(shù)甚至存儲過程來解決，而Hive只支持基本的SQL語法，不支持窗口函數(shù)和存儲過程。
用戶行為的計算之所以較為復(fù)雜，是因為需要對同一個用戶的多條數(shù)據(jù)之間進行計算，這種計算大多和順序相關(guān)。SQL對有序計算的支持有限，只有窗口函數(shù)可以實現(xiàn)部分簡單的有序計算，但對于復(fù)雜的業(yè)務(wù)邏輯仍然顯得非常繁瑣，而且經(jīng)常因為大排序造成低下的性能。使用程序性的存儲過程編寫復(fù)雜代碼可以實現(xiàn)復(fù)雜的有序計算，但很難復(fù)用SQL的集合運算能力，所有處理都有從基礎(chǔ)運算自己編寫，而且其性能通常比SQL更低。
MapReduce的困難。MapReduce支持大數(shù)據(jù)并行計算，同時它是用程序性的JAVA語言來編寫的，這一點和存儲過程有相似性。但是，MapReduce所使用的 JAVA語言缺乏針對結(jié)構(gòu)數(shù)據(jù)計算的類庫，所有的底層功能都要自己實現(xiàn)：分組、排序、查詢、關(guān)聯(lián)等等，對于有序計算這較復(fù)雜的算法所要書寫的代碼更多、編寫難度更大、維護更加困難。同樣的，MapReduce也無法利用已經(jīng)排序好的數(shù)據(jù)，在shuffle階段還需要得做大排序。
SQL和MapReduce無法利用事先排序好的數(shù)據(jù)，難以高性能地將同一用戶的所有數(shù)據(jù)加載到內(nèi)存中來計算，用戶類大數(shù)據(jù)計算因此會遇到性能、擴展性和開發(fā)難度的挑戰(zhàn)。
如何利用事先排序好的數(shù)據(jù)，以此簡化代碼書寫難度并提高計算性能？
集算器是支持多節(jié)點并行計算的程序設(shè)計語言，并提供豐富的有序計算。如果數(shù)據(jù)事先排好序，集算器支持通過游標來按組讀取數(shù)據(jù)，每次讀取一組數(shù)據(jù)進內(nèi)存，避免反復(fù)的外存訪問，整個數(shù)據(jù)只要遍歷一次即可，從而使性能大大提高。針對組內(nèi)計算復(fù)雜，集算器具有完備的批量化數(shù)據(jù)計算類庫，可以輕松實現(xiàn)各類復(fù)雜的有序計算。。
集算器支持靈活自由的多節(jié)點并行計算，可以進一步優(yōu)化性能。方法之一將用戶按某種方式分段，以此實現(xiàn)分布存儲后的高效并行處理。比如將會員零售數(shù)據(jù)按照會員編號的前兩位分成100段存儲于HDFS，每段存儲十萬會員的一億條數(shù)據(jù)?；蛘邔⒕W(wǎng)站日志按照用戶ID的首字母和年份分段，每段存儲幾百萬用戶的數(shù)據(jù)。或者將通話記錄按照區(qū)號和用戶數(shù)量合并為30段，每段存儲一個州或幾個州的用戶。經(jīng)過分段處理后，每段數(shù)據(jù)都是排好序的，可被節(jié)點機的一個線程獨立處理，這樣的并行計算性能更高。
針對上面的難點，下面用”每個用戶在每種產(chǎn)品上的累積在線時間”為例來說明集算器的一般解決辦法。
大分組的困難：事先排序數(shù)據(jù)，以供多種計算目標使用。在節(jié)點機運算時可以直接按用戶分組取數(shù)，有效利用已經(jīng)有序的數(shù)據(jù)以提高性能。
組內(nèi)計算復(fù)雜：esProc具有完備的批量化數(shù)據(jù)計算類庫，可以輕松實現(xiàn)各類復(fù)雜的有序計算。
完整的代碼如下：
