Tumweeg，學生時期曾為微軟中國打雜並取得過相關專利，現在某海外業務社交類移動互聯網公司任大數據工程師。熟悉大數據平臺研發、架構，以及數據的處理和分析，熟悉Web架構和高性能/高併發/高可用系統，熱愛技術交流，共同提高。
本文分享的主題是中小型企業基於大數據技術的項目實踐，筆者將從大數據技術棧開始說起，並在後文分享自己在工程實踐中的一些具體經驗。
一、大數據技術初探
首先我們從大數據技術的乾貨介紹開始，這部分內容對於有基礎的童鞋來說，可以快速略過。
準確來說 “大數據” 這個概念並不存在，其就是在曾經我們提到過的 “海量數據” 的基礎上，數據量級再一次增大，導致傳統的處理手段無法進行及時、有效地處理。
為了表徵與傳統數據處理手段的區別，表明技術的先進性，提出來了一個新詞——大數據。
作為 DT 時代的代表技術之一，大數據緊緊地與人工智能，雲計算技術相結合，三者相輔相成，共同促進產業變革，技術進步。無論在學術界還是工業界，這 “三駕馬車” 無疑都是最熱門和前沿的。
作為近幾年火起來的一項技術，大數據技術的主要應用場景是日誌收集與處理、數據分析、機器學習模型的訓練等。基於這些，我們可以實現商業智能（BI）、科學決策等。
所謂的大數據技術棧，無外乎 Hadoop 生態系統，如下圖所示：
那麼，作為一個大數據工程師，是否有必要掌握上述全部內容呢？答案是否定的！
大數據技術主要表現在：
大規模數據存儲
彈性計算
集群資源調度
數據收集
集群一致性保證
1、大規模數據存儲
網盤就是一個典型的大數據存儲應用。毫無疑問，網盤上存儲的數據量是海量的，這需要一個集群去存儲，也就是我們說的雲存儲。
類似地，我們在工業實踐中，也會遇到各種各樣數據，這些數據有些是冷數據，也有的是熱數據。但是，無論是冷的、熱的，只要是有存儲意義的數據我們必然要給他存儲起來，以便後續使用。舉個例子，一個訪問量大的網站，每天產生的日質量是很大的，這些數據我們可以存儲起來，以便後續使用。
Hadoop 的 HDFS 可以認為是實際上的工業標準，其存儲模式是文件分塊存儲、多機備份（冗餘），通過 standby 節點來進行心跳探測，保證可用性。除了 HDFS，我們使用雲產品時，可能也會用亞馬遜的公有云產品，也即是 AWS 的 S3 存儲系統。
由於筆者所在公司的業務是面向海外市場的，雲服務選擇的是 AWS，用的雲存儲是亞馬遜的 S3，免去了自己部署 Hadoop HDFS 的過程。Hadoop 的 HDFS 是自帶讀取 AWS S3 的 API 的。但是，值得說明的是，Hadoop 的 HDFS 並不太適合頻繁更改或者是海量的小文件存儲，畢竟一個文件塊就很大了，有的版本默認是 128M，有的是 64M，海量小文件，一般使用的是 FastDFS 或者淘寶開源的 TFS。
2、彈性計算
所謂彈性計算，也就是之前學術界所說的網格計算，現在很流行的分佈式計算。我們知道，單節點的算力是有限的，包括超級計算機的架構也是上千個 CPU 和 GPU 們組成的。我們在平時使用的時候，自然不會設計出超級計算機這樣複雜的硬件基礎設施，會通過 TCP/IP 協議來傳送數據，在不同的節點上進行並行計算，最後再講結果彙總，這種算法我們叫做 Map/Reduce 算法。這種理念是 Google 提出來的。
Hadoop 有三個組件，用於大規模數據存儲的 HDFS、分佈式計算的 Map/Reduce 引擎和資源調度 Yarn。只不過 Hadoop 的同名計算引擎 MapReduce 在涉及到中間數據緩存時，要寫入 HDFS 上，我們知道 HDFS 本身就是建立在外存上的，而且還要有冗餘備份，整個讀取和寫入速度都比較慢，所以現在真正使用的就是 Spark 計算引擎，MR（MapReduce）引擎都快被廢掉了。
Spark 是一個通用的計算引擎，其除了核心 Core，為應用層封裝了機器學習、圖計算、流式計算框架和 SparkSQL 即席查詢四個模塊，用起來很是方便，我們在實際工程中，用得最多的也就是 Spark 了。Spark 與 Hadoop 的 MR 引擎不同的是，Spark 的中間數據存儲在內存中，所以速度特別快。但Spark 的內存要求比較大，不過內存畢竟也不算太貴。
3、集群資源調度
所謂的資源調度，主要指的就是 CPU 和內存資源的調度，集群中哪臺節點比較閒，就給它多點任務，這樣可使整體的集群負載均衡，這對於分佈式集群來說是十分重要的，直接影響了集群的計算性能。
Hadoop 自帶的模塊是 Yarn，Spark 也自帶一個，叫做 Mesos，不過我們說Spark 是 Hadoop 生態系統中的成員，自然而然 Spark 也可以使用 Hadoop 的 Yarn 資源調度引擎，避免了部署上的麻煩。
4、數據收集
數據分為流式數據和批處理數據。所謂的流式數據是像流水一樣的數據，通常用的計算引擎是 Spark Streaming 和 Storm，我們公司主要用到的是 Spark Streaming。
二者的區別就是，Spark Streaming 不是嚴格意義的實時，是一種準實時，每隔一段時間來對收集到的數據運算一次，這樣達到一種流式計算的效果，而 Storm 是嚴格意義的實時，來一條數據處理一條。
對於我們公司來講，不需要這麼實時的效果，同時 Spark streaming 直接就用 Spark 框架編寫就 ok 了，團隊成員的技術棧比較吻合，避免了再次學習 Storm 的成本，也減少了版本發佈和維護上的苦難。但是具體的選型，還要結合公司的實際情況。
說到流式數據的收集，我們不得不提到 Kafka 這個消息中間件。它是發佈 / 訂閱模式的，可以用來做流式數據收集的消息隊列，起到緩存與緩衝的作用，詳細介紹請看 http://kafka.apache.org/intro.html。
這是一整套流式數據處理的架構，在網上找到這幾篇博文，感覺還可以，推薦給大家：
此外，再介紹一個叫做 Flume 的東西，它的官方介紹是：
Apache Flume is a distributed, reliable, and available system for efficiently collecting, aggregating and moving large amounts of log data from many different sources to a centralized data store.
The use of Apache Flume is not only restricted to log data aggregation. Since data sources are customizable, Flume can be used to transport massive quantities of event data including but not limited to network traffic data, social-media-generated data, email messages and pretty much any data source possible.
Flume 多用作日誌的收集，常用來收集諸如 Nginx 日誌等，配合 Kafka 使用，可以做到數據的流式收集。
具體的架構使用，可參見博文介紹：
https://www.cnblogs.com/cnmenglang/p/6550427.html
5、集群一致性保證
作為一個集群，一致性是應高考慮的一個重要因素。例如，我們在一個集群上兩個不同節點讀取到的數據不一樣，那麼我們是相信誰的？很容易就無法做出下一步的處理。所以，我們在上面的 Hadoop 生態系統的圖示中可以看到一個貫穿始終的叫做 ZooKeeper 的東西，這個東西就是用來保障集群一致性的。
ZooKeeper 主要提供的是 Java API，它通過觀察者模式來實現的，不同節點註冊一個 watcher來監聽事件。它實現了 Paxos 算法，Paxos 算法是一個比較複雜的算法，整個算法的推倒與證明過程一頁 A4 紙都寫不下。
ZooKeeper 實現的 Paxos 算法也是 Fast Paxos，或者說是 Paxos 算法的精簡版本。通過 ZooKeeper 我們可以保證整個集群的一致性，也就為後來基於 ZooKeeper 的應用提供了高可用（HA）的基礎。
二、大數據技術工程實踐
筆者以大數據技術使用的一個典型場景為例展開探討，場景描述：
應用場景是針對一款 app 的日誌分析，該 app 的架構方式是基於 HTTP 的微服務，app 算是典型的社交軟件。包括聊天，更新狀態，群組討論，更新個人信息等都是通過調用 HTTP 接口來實現的，當然，這些內容都是加密過的，包括服務器之間的通訊也都是通過證書來驗證的。
這樣的微服務架構為我們的日誌分析提供了方便，可以認為日誌上的 url 路徑包含了很多的信息，基於不同的 url 我們可以發現用戶的行為，並針對用戶的行為進行數據分析。
1、數據的收集
如果是做離線計算的，可以直接把日誌下載到本機，然後再對本機上的所有日誌進行統一的計算。
Spark 是支持 AWS S3 的，不過這得基於 Hadoop 來實現，還得安裝 Hadoop，在實際使用中坑很多。Spark 讀取 S3 數據可以使用亞馬遜官方的 Java driver 來做，相對來說坑比較少。不過，Spark 直接讀取 HDFS 上的數據相對容易很多，坑也沒有多少；在實際使用的時候，可以嘗試用流式日誌下載的方式，在下載的同時，進行數據的分析，實際還是比較高效的。
2、數據的 ETL
ETL（ Extract-Transform-Load ）用來描述將數據從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。ETL 的方式有很多，有基於現有用具進行 ETL 的，也有自己編寫代碼進行 ETL 的。
筆者所採用的 ETL 方式是基於 Spark 的 ETL，基於 Spark 的 ETL 有諸如靈活快速等特點，這裡有幾篇博文，介紹了 Spark 的 ETL，總的來說，用 Spark 來做 ETL 是比較高大上的。
上面說到，筆者的日誌數據存儲在 AWS 的 S3 上，故而介紹寫 AWS S3 的日誌格式，原文鏈接請查閱 https://goo.gl/8CHKdp
s3 文件的路徑格式：
bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_load-balancer-name_end-time_ip-address_random-string.log
日誌的存儲格式：
timestamp elb client:port backend:port request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes “request” “user_agent” ssl_cipher ssl_protocol
總之，就是包括了用戶的請求 IP、請求設備、時間、請求方法、請求路徑和服務器的相應和處理時間等。這裡有專門針對 AWS 日誌的分析系統的博文供大家學習：
我們的目標是利用 Spark 將這種存儲於亞馬遜 S3 的原始日誌格式進行轉換，存儲在數據倉庫中。對於數據倉庫，比較著名的應該是 HBase 了，HBase 是基於 HDFS 的一個 NoSQL 列式數據庫，存儲容量大。
不過，對於我的業務場景來說，選用 HBase 並不太適合，因為很多數據存儲很長時間並沒有必要，最多隻需要存儲最近一個月的經過 ETL 後的數據就可以了，沒有必要存儲那麼多冷數據，所以我選擇了 MongoDB 進行數據的存儲。
那麼我們就明確了 ETL 的目標，將來自於 AWS S3 的原始數據（raw log）經過 ETL，存儲在 MongoDB 中，MongoDB 中存儲的格式類似於：
{ "time":"2017-2-1-26 UTC xx:xx:xx", "url":"http://foo.com/ab?c=d&e=f", "uri":"ab", "uid":"10000" }
3、MongoSpark
MongoDB 和 Spark 之間是可以用來做高速地數據傳輸的，我們使用 MongoDB 來作為 Spark 的數據持久層，MongoDB 的 Spark driver 名稱就叫做 MongoSpark。
原文部分內容摘要
1) HDFS VS MongoDB
既然我們說 MongoDB 可以用在 HDFS 的地方，那我們來詳細看看兩者之間的差異性。
在說區別之前，其實我們可以先來注意一下兩者的共同點。HDFS 和 MongoDB 都是基於廉價 x86 服務器的橫向擴展架構，都能支持到 TB 到 PB 級的數據量。
數據會在多節點自動備份，來保證數據的高可用和冗餘。兩者都支持非結構化數據的存儲等。
2) HDFS 和 MongoDB 的區別
如在存儲方式上 HDFS 的存儲是以文件為單位，每個文件 64MB 到 128MB 不等。而 MongoDB 則是細顆粒化的、以文檔為單位的存儲。
HDFS 不支持索引的概念，對數據的操作侷限於掃描性質的讀，MongoDB 則支持基於二級索引的快速檢索。
MongoDB 可以支持常見的增刪改查場景，而 HDFS 一般只是一次寫入後就很難進行修改。
從響應時間上來說，HDFS 一般是分鐘級別而 MongoDB 對手請求的響應時間通常以毫秒作為單位。
3) MongoDB-Spark 架構
4) 什麼時候選用 MongoDB
涉及到快速讀取數據
建立索引
對數據的存儲粒度要求較細（文檔形式）
能夠對數據進行修改的場合。
5) 什麼時候選用 HDFS
HDFS 數據存儲節點不要求就有較大的內存，而 MongoDB 要想保證讀寫迅速的前提是要佔據較大的內存空間；
對數據修改的要求不高，例如圖片，音視頻文件，一般寫入後不需要再次修改；
HDFS 被設計部署在低廉的硬件設備上，對硬件的要求不苛刻，能夠保證高可用性，集群的數據吞吐量也很高；
相比之下，MongoDB 對 CPU 和內存的要求要高得多。
6) MongoDB 的地理位置搜索
MongoDB 具有很多高級搜索功能，譬如微信搜索附近的人，我們可以通過 MongoDB 的 GEO 搜索來完成，這是 MongoDB 的又一大好處，有關地理位置搜索，推薦這篇博文：https://goo.gl/FYiZJg。
4、數據的分析
我們首先來回顧一下，日誌中主要包括的內容有：在我們的日誌 url 中記錄了用戶的 id、用戶的行為、用戶的行為屬性、用戶的設備、用戶的 IP、用戶訪問時間、服務器處理時間、服務器響應時間等。
上述數據是來自日誌的原始數據，經過 ETL 後，被存儲到 MongoDB 的 raw 數據庫中，以 K-V 對文檔的形式存儲起來，下面我們將要對存儲到 MongoDB 中，經過整理後的數據進行分析。
4.1 宏觀分析
宏觀分析是最基礎也是最簡單的，例如：
我們可以統計一天 24Hour，那個小時用戶的活躍量最多；
我們可以根據用戶的 IP 來判斷哪個區域的用戶最多；
我們可以根據使用設備，來判斷使用什麼終端的用戶最多；
同樣我們也可以用服務器的響應時間來判斷服務器的運轉情況。
宏觀分析，在用 Spark 進行編程時，首先經過 map 過程轉換成我們想要的形式，例如：我們要統計 24 小時，分時統計用戶活躍量。這樣，我們經過 map 後，就可以形成這樣的一個形式：
// 我們假設 ,rdd 的存儲格式是一個 Document,Document 是 MongoDB driver 的存儲格式，它實現了 Map 接口。 val rdd = MongoSpark.load(...) // 從 MongoDB 中直接加載某個 table，也就是說，rdd 的類型是 RDD[Document]. 這裡用到的是 scala 編程，與 Java 類似 val count = rdd.map(x=>{ (parse2Hour(x.getString("time")),1) }).reduceByKey(_+_) // 得到了分時統計結果，與寫 wordcount 是類似的。 //parse2Hour 是一個函數，實現了將存儲的 UTC 格式的 time 提取出小時，這個其實自己實現一個簡單的文本分割就搞定了。 count.foreach(println) // 打印出統計的結果
4.2 微觀分析
所謂微觀分析，就是粒度更細緻的分析了。
我們在上面只是分析出所有的用戶群體，在哪個時間段更加活躍。現在我們再看另外一個例子：我們想要分析 uid 為 1000 的用戶，在一天 24 小時中，哪個小時活動最頻繁。統計出來的結果，可以直接用做給它推送消息的推送時間點來使用。
其實，這個編程與上面的宏觀統計類似，只不過，我們要將所有的 rdd 進行一個 group 分組，把所有 uid 相同的全都放到一起去。之後，再在這個子 rdd 中分析該用戶在哪個時間段最活躍即可。
示例代碼如下：
val rdd = MongoSpark.load(...) // 從 MongoDB 中直接加載某個 table val user = rdd.groupBy(_.getString("uid")) // 通過用戶的 uid 不同，來劃分為不同的子 rdd val count = user.map(x=>{ // 每個劃分出來的子 rdd 的格式是這樣的： // ("uid",[Document1,Document2,...]) /* 我們可以看出來，劃分出來的結果實際上是一個元組，元組的第一個元素就是我們劃分的依據，元組的第二個元素就是一個 List, 這個 List 把所有屬於這個元組的 Document 都包括進去了。 */ // 後面，我們再對這個 List 進行一個暴力掃描，掃描出其中我們想要的結果就 ok 了 , 這裡根據業務不同，代碼省略，如果不會分佈式並行編程，就給 collect 到本地，編寫相關的業務代碼也 Ok. ... // 最後返回結果: (uid, 某個小時) })
4.3 機器學習
其實在我們實踐當中，最常用到的機器學習算法恐怕就是聚類算法了。
聚類是一種無監督學習，我們最常用到的聚類算法就是 Kmeans 算法，Spark 的 MLlib 庫為我們實現了 Kmeans 算法，我們直接調用就 OK 了。
通過聚類算法，我們可以實現：因為我們在日誌中是包含用戶的行為特徵的，根據這些行為特徵，我們可以通過聚類算法來實現用戶的分群。
這裡簡單介紹下 Kmeans 算法的原理：
Kmeans 算法需要指定參數 k ，用來告訴算法需要分成幾個類別；
然後將事先輸入的 n 個數據對象劃分為 k 個聚類以便使得所獲得的聚類滿足以下條件：
同一聚類中的對象相似度較高；
不同聚類中的對象相似度較小。
聚類相似度是利用各聚類中對象的均值所獲得一個 “中心對象” 來進行計算的。
聚類算法是一種迭代算法，通過反覆迭代，來使得結果趨向於最優。這個迭代次數也是可以指定的，不過也不是越多越好，因為越往後改變就越小，效果不理想，反而浪費時間，這個需要具體去調試。
那麼，我們在進行聚類時，我們可以統計某個用戶（叫他小明吧），下面我舉個例子，假設下面的數據都是針對小明同學行為產生的日誌情況，進行統計分析的結果：
小明的基本用戶信息：
{
“name”:” 小明 “，
“age”:”18”,
“gender”:”male”,
“country”:”china”,
…
}
日誌統計信息：
{
“ 發送聊天記錄 “:250,
“ 陌生人聊天 “:200,
“ 好友聊天 “:25,
“ 群組聊天 “:25,
“ 瀏覽別人發的說說 “：100，
“ 搜索附近的人 “,100,
“ 勾搭過幾個陌生人 “:50,
“ 閱讀推薦文章 “:0,
…
}
當然了，上面的日誌統計結果我只是舉個例子，我們可以選擇其中的某幾個具有代表性的作為特徵向量，根據這些特徵向量來對用戶進行聚類。譬如，我們可以選擇：聊天記錄、陌生人聊天比例、搜索陌生人次數、勾搭過幾個陌生人等來衡量某些人對陌生人交友的喜好程度。
4.4 歸一化
這裡順便說一下歸一化的問題。
在上面的例子中，我們可以看到，如果某個人搜索附近的人頻次特別高，而且只有這個人的水平特別高，可能達到了 100000000 這個量級，而除他之外的所有人可能都是 200 一下的量級。
這樣在進行數據計算時，直接用 100000000 這個數字帶進去算很容易對結果造成干擾，甚至數字還有溢出的可能。
我們想辦法將這些數字映射到 [0,1] 的區間中，用小數來表示，這樣我們叫做歸一化。
比較簡單的歸一化可以是用某個用戶的值除以全體的總數；也可以是用某個用戶的值處理這個群體中最大的那個值；這樣都可以保證結果是在 [0，1] 之間，當然，對於某些特別 “奇葩” 的用戶，我們也可以用 sigmoid 函數來進行映射，sigmoid 函數是一種 S 型曲線函數，它的圖像是：
這個當作瞭解就行了，實際上在一些分工明確的公司裡，會有專門的算法組來進行優化和設計的。詳見百度百科 https://goo.gl/m8NMqC
通過 Kmeans 算法，我們可以對用戶進行聚類，相同類型的人，會被聚類到一起，可以供我們進行統計分析、科學決策和相似用戶推薦等。
4.5 推薦系統
諸如涉及到評分相關內容的都可以用作推薦系統。推薦系統，只要保證能夠維護好這幾個數據表就可以做了：用戶信息表、產品信息表、用戶對產品的評分表。
現在在工業界最常用的推薦系統算法是協同過濾相關算法，Spark 的 MLlib 庫為我們實現了推薦系統的算法。
算法比較常用的一個是基於產品信息的（ItemCF），一個是基於用戶的（UserCF），這裡有一篇博文 https://goo.gl/n1sjnF ，介紹了上面兩種算法。在實際應用場景中，可能並非具有具體評分值，那麼就需要我們根據用戶的具體行為來為其指定具體的分數，譬如一張圖片，衡量用戶對其的喜歡程度：
瀏覽圖片算作 1，評論算作 2（舉個例子，這個有歧義，也可能是差評），點擊大圖觀看算作 3，點贊算作 4，分享算作 5，等。
5、任務調度系統
大數據的任務調度系統主要有 Hadoop 的 Oozie，不過相對而言，筆者更喜歡用領英開源的任務調度系統——Azkaban，Azkaban 的官方簡介是：
azkaban was implemented at LinkedIn to solve the problem of Hadoop job dependencies.We had jobs that needed to run in order, from ETL jobs to data analytics products.
Initially a single server solution, with the increased number of Hadoop users over the years, Azkaban has evolved to be a more robust solution.
可以看到，領英官方就用它來做大數據相關的任務調度使用，這裡推薦一篇博文 https://goo.gl/w6bXdA，詳細介紹了 Azkaban 用作大數據領域任務調度系統的配置和應用方法。
通過 Azkaban 就可以做到解放人力：任務的自動調用和執行，而且可以指定調用順序，定時觸發還有報錯功能，的確是件神器。
三、經驗之談
1、合理架構
在考慮實現大數據平臺時，要對需要實現的產品做一個全方位的衡量，選擇適合自己業務需要的方式針對性地架構，不應直接從網上 copy 一種方案便開始實施。
舉一個例子，某種場合下，我們可以提出多級 ETL 的方式，來實現數據的複用，這些數據之間的關係呈現出金字塔狀，如圖所示：
越在金字塔上部分的數據量越小，經過 ETL 也變得更加細粒度，這部分數據的冗餘部分相對較少，越在下面的數據冗餘越大，越是冷數據。
假設這樣不同層的數據，我們可以對其進行復用，那麼我們就有必要進行多級的 ETL，如果這種複用情況很沒有必要，我們也沒有必要進行多級的 ETL。
具體是否適合我們的應用場景，要依據自身具體的業務情況來進行分析，不能按圖索驥。
2、保證任務調度順序
任務調度系統我們使用 Azkaban 而不使用 Croncat（Linux 自帶的工具），是因為 Azkaban 可以讓我們自行指定任務之間的依賴關係。
這些依賴是一個 DAG，我們在 Azkaban 中配置任務之間順序時，一定要把握好任務之間的關係，當涉及到並行事務時，要考慮到二者之間的執行順序和耦合關係，否則將會造成任務的失敗。
3、保證集群的高負載
一個計算集群都不能浪費掉，因為集群的價格比較昂貴，我們往往都是使用的雲服務。對於不是按量付費的雲服務，我們要保證集群的高負載。也就是讓集群始終處於一種工作狀態，不要將集群空著，這樣比較浪費資源。對於流式數據處理來講，集群自然是保證一直在工作。但對於離線計算來講，可能當我們提交完一個作業之後，很快任務就執行結束，如果確定沒有什麼額外的計算任務，請選擇按量付費，這樣能節約很大一筆開銷。
對於很多雲服務商來講，他們往往提供了 MapReduce 的雲服務，在有條件的情況下，也可以購買這種雲服務，避免配置的繁瑣，也能夠合理地按量付費。
4、充分挖掘節點算力
Spark 的默認設置，每個節點都有內存使用上的限制，我們可以通過修改 conf 目錄中的配置文件，來修改 Spark 使用的內存量。
譬如 spark-env.sh 文件中的參數 SPARK_WORKER_MEMORY 可以設置工作節點的內存使用，這個使用值儘可能設得大一些，可以提高集群性能。
5、考慮批處理調用 HTTP API
由於 Spark 是一種並行編程思想，在某些調用上是並行地取執行。例如我們通過 HTTP 微服務的方式，查詢一個用戶的性別：
每一個並行的執行操作都會去調用一次 HTTP 請求，來查詢某個用戶的性別。實際上，對於查詢這種操作，遠程的服務器是通過掃描數據庫中的內容來完成的，多次反覆掃描和一次批量地掃描效率相比是要差很多的。
以 MongoDB 為例，執行兩次 findOne 和執行一次 findMany 相比，開銷可能要達到 1.8 倍左右，這還不算遠程服務器響應併發時的性能消耗。對於這些操作，可以合併執行，將 HTTP API 改成：
6、降低耦合
通過分析日誌中的 URL 請求來完成大數據分析，避免修改現有的代碼，可以實現大數據平臺與現有平臺之間的分離，實現松耦合。
大數據平臺的數據源來源於日誌文件，避免對現有的業務代碼侵犯，可以對現有數據採用讀取的方式豐富數據來源，但儘量不要取修改業務系統中的數據。這樣把大數據平臺作為一個單獨的系統來實現，可以避免修改現有的業務系統。
四、總結
在本文中，我們談到了中小型企業基於大數據技術的項目實踐。其實，對於中小型企業來講，可能數據量並沒有大型公司想象得那麼多，一般一天產生的日誌條數幾千萬到一億的居多。
對於這種離線計算場景，其實並不一定就非得用分佈式集群去消費數據，如果公司尚有閒置的單節點內存容量達到 16G，雙核心及以上的一臺機器，實際上在做離線計算的時候也夠用了。
本文轉自GitChat技術雜談（GitChat_Club）訂閱號，經平臺授權轉載。
近期熱文
閱讀更多 dbaplus社群 的文章
