【51CTO精選譯文】編輯注：本文作者是BugSense公司的創始人兼首席技術官Jon Vlachogiannis。BugSense是一家專門報告錯誤、度量質量的服務商，每天跟蹤成千上萬個應用程序。移動應用程序崩潰時，BugSense可以幫助開發人員準確查明問題，并解決問題。這家新興公司的客戶包括VMWare、三星、Skype以及數千家獨立應用軟件開發商。跟蹤2億多種設備需要有一套運行速度快、容錯性強、成本又低廉的基礎設施。

在最近六個月，我們決定使用自己的BigData基礎設施，為用戶們提供評估應用程序性能和穩定性的度量指標，好讓他們知道出現的錯誤給其用戶群和經營收入帶來了怎樣的影響。

我們清楚，自己的解決方案自一開始就應該具有良好的擴展性，因為外面所有的智能手機中超過4%會開始向我們發送大量數據，實際上無異于分布式拒絕服務攻擊（DDoS）。

我們希望能夠做到以下這幾點：

■抽取應用程序邏輯，并以JSON格式向瀏覽器傳送數據

■實時運行復雜算法

■嘗試處理數據，不需要專門的Hadoop集群

■預處理數據，然后存儲數據（減少存儲空間）

■能夠在每一個節點上處理1000多個并發請求

■每個應用程序對超過1.25億行進行“聯結”操作

■不需要把大筆錢投入到服務器上，即可做到這一點

解決方案使用了：

■在Azure平臺上運行的不到20個大實例

■內存中數據庫

■使用C語言編寫的完全成熟的自定義LISP語言，以實現查詢，其速度要比讓虛擬機（附帶廢料收集器）一直在線運行快好多倍。

■用于節點之間聯系的Erlang語言

■經過改動的TCP_TIMEWAIT_LEN，足足少了4萬條連接，節省了處理器、內存和TCP緩沖器等方面的資源。

內存中數據庫萬歲！

我們知道，我們要處理這一切流量，唯一的辦法就是使用內存中數據庫。

為了迅速解答針對龐大數據集的臨時特定問題（比如“一個多星期以來，多少不重復的三星設備用戶遇到了這個特定的錯誤？”），你不僅要應對內存方面的局限性，還要應對在數據處理前后的數據串行化和并行化工作。這就是我們啟動LDB項目的原因。

LDB項目介紹

你是否相信能做到這點：可以將來自不同數據源（甚至上千個不同數據源，如移動設備）的數據傳送到某個系統中，描述你用僅僅幾行代碼想提取什么樣的信息，然后讓所有這些信息觸手可及？而且以實時方式實現，同時不影響系統的正常運行？

LDB與其說是個數據庫，還不如說是款應用服務器。盡管它是內存中數據庫，但是數據實際上存儲在硬驅中，并且復制到其他節點上。

有了LDB，我們并不運行查詢，而是運行算法，因為我們有一種使用C語言編寫的完全成熟的自定義LISP語言，它可以訪問與數據庫同樣的地址空間。這意味著，你能夠以極快的速度搜索數據、增加計數器以及進行get/put操作等。

擁有LISP的優點在于，你可以輕松創建類似SQL的語言，比如Hive，并且實時查詢數據，就像這樣：

LDB工作起來像這樣：

每一個應用程序都有各自的LDB。這意味著它有自己的內存空間。這樣一來，我們就可以把就流量而言更龐大的應用程序輕松轉移到不同的機器上。

當請求來自移動設備時，主LDB節點接受連接（使用erlang線程池），并將該數據轉發到某個特定的數據庫（DB）。這種請求處理機制是用不到20行Erlang代碼實現的。這也是我們選擇Erlang用于節點之間聯系的另一個原因。

當請求被“流式傳送”到LDB后，一個名為“process.lql”的文件負責分析和標記數據，并創建各種計數器。這一切都是實時進行的，對每個請求而言都是如此。

我們之所以能夠這么做，是因為針對每個請求，開啟我們的LISP虛擬機、處理所有這些過程仍比讓虛擬機（附帶廢料收集器）一直在線運行快好多倍。

借助LDB，我們只要用短短的3行代碼，就能創建時間序列和聚合數據。

比如說，下列代碼為不重復用戶創建了7天的時間序列：

替代辦法

我們在測試過程中發現，SQL數據庫之所以不是很適合，正是由于這一點：我們的數據以非結構化數據為主，我們需要許多復雜的“聯結”（和許多索引）。另一方面，就NoSQL數據庫而言，我們無法在系統運行的同時針對數據運行我們的算法，而擁有mappers/reducers使得整個事情處理起來既復雜又緩慢。我們需要一種沒有大鎖或數據庫鎖的高并發系統，可以用僅僅幾KB就能跟蹤數百萬個不重復事件，而且、擴展起來很容易。

一個很好的替代辦法就是使用Stream數據庫（比如Storm）。我們的主要問題在于，單個節點有許多變化因素，而且存在性能問題。借助LDB，我們有了這個優點：能夠以極快的速度處理數據（數據駐留在同一個內存空間），把它們作為聚合計數器或符號來存儲（因而能夠將數GB數據塞入到數KB空間），然后讓特定領域語言（DSL）來實時處理我們想要進行的任何關聯操作。沒有串行化/并行化，沒有網絡調用，也沒有廢料收集器。這就好比是將匯編代碼映射到你的數據上。

除此之外，借助LDB，我們有了可以擴展并處理入站數據的接收器、一切僅用幾行代碼就可以定義的流式組件以及存儲引擎（Storage Engine）和復制引擎（Replication engine）。

優化內核

較之于每秒處理大量請求的其他服務，我們進行分析時的獨特地方在于，移動設備與服務器之間的對話極少（3個TCP握手數據包、1個有效載荷數據包和3個TCP終結數據包）。

不過，TCP在設計時并沒有考慮到這種情況（也就是說設備之間的對話很少），而是實現了一種名為TIME_WAIT的狀態（在2.6 Linux內核中持續時間約1分鐘）：上一個FIN（完成）數據包被發送后，該特定連接tuple的TCP狀態仍保持一段時間的開啟狀態，目的是為了接收可能延誤的任何雜散數據包（也就是說，在連接關閉之前）。不過就我們的情況而言，這用處不大（我們希望酷似UDP行為，但又有TCP保障），因為有效載荷只是1個數據包（瀏覽請求多達4個或5個數據包），于是我們決定改動內核源代碼，把這個參數的常量減小到20秒。結果就是足足少了4萬條連接，數量驚人，因而節省了處理器、內存和TCP緩沖器等方面的資源。

我們所打的補丁在這個文件中：

linux-kernel-source/include/net/tcp.h
#define TCP_TIMEWAIT_LEN (60*HZ)

換成

#define TCP_TIMEWAIT_LEN (20*HZ)

使用這種架構，我們就能為我們的所有付費客戶提供實時分析和了解移動應用程序的功能，不到20個大實例在Azure平臺上運行，包括退守服務器和備用服務器。

原文：BigData Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data