干貨，主流大數(shù)據(jù)技術(shù)總結(jié)

作者：justcodeit

1. 數(shù)據(jù)量不斷增加，企業(yè)需要靈活快速地處理這些數(shù)據(jù)。
2. 處理器主頻和散熱遇到瓶頸，多核處理器成為主流，并行化計(jì)算應(yīng)用不斷增加。
3. 開源軟件的成功使得大數(shù)據(jù)技術(shù)得以興起。

• 批量處理：?jiǎn)挝皇巧习費(fèi)B的數(shù)據(jù)塊而非一條條數(shù)據(jù)，這樣在數(shù)據(jù)讀寫時(shí)能夠整體操作，減少IO尋址的時(shí)間消耗。
• 最終線性一致性：大數(shù)據(jù)技術(shù)很多都放棄線性一致性，這主要是跨行/文檔（關(guān)系型模型叫行，文檔型模型叫文檔）時(shí)非原子操作，在一行/一個(gè)文檔內(nèi)還是會(huì)做到原子的。為了讀寫性能而允許跨行/文檔出現(xiàn)讀寫延遲。
• 增加數(shù)據(jù)冗余：規(guī)范化的數(shù)據(jù)能夠減少數(shù)據(jù)量，但在使用時(shí)需要關(guān)聯(lián)才能獲得完整數(shù)據(jù)，而在大數(shù)據(jù)下進(jìn)行多次關(guān)聯(lián)的操作是十分耗時(shí)的。為此，一些大數(shù)據(jù)應(yīng)用通過(guò)合并寬表減少關(guān)聯(lián)來(lái)提高性能。
• 列式存儲(chǔ)：讀取數(shù)據(jù)時(shí)只讀取業(yè)務(wù)所關(guān)心的列而不需要把整行數(shù)據(jù)都取出再做進(jìn)行截取，而且列式的壓縮率更高，因?yàn)橐涣欣镆话愣际峭惖臄?shù)據(jù)。

• 副本：大數(shù)據(jù)存儲(chǔ)通常都會(huì)有副本設(shè)置，這樣即便其中一份出現(xiàn)丟失，數(shù)據(jù)也能從副本找到。
• 高可用：大數(shù)據(jù)應(yīng)用通常都會(huì)考慮高可用，即某個(gè)節(jié)點(diǎn)掛了，會(huì)有其他的節(jié)點(diǎn)來(lái)繼續(xù)它的工作。

架構(gòu)原理

• NameNode：作為master，管理元數(shù)據(jù)，包括文件名、副本數(shù)、數(shù)據(jù)塊存儲(chǔ)的位置，響應(yīng)client的請(qǐng)求，接收workers的heartbeating和blockreport。
• DataNode：管理數(shù)據(jù)（data block，存儲(chǔ)在磁盤，包括數(shù)據(jù)本身和元數(shù)據(jù)）和處理master、client端的請(qǐng)求。定期向namenode發(fā)送它們所擁有的塊的列表。
• secondary namenode：備用master
• Block：默認(rèn)128MB，但小于一個(gè)block的文件只會(huì)占用相應(yīng)大小的磁盤空間。設(shè)置100+MB是為了盡量減少尋址時(shí)間占整個(gè)數(shù)據(jù)讀取時(shí)間的比例，但如果block過(guò)大，又不適合數(shù)據(jù)的分散存儲(chǔ)或計(jì)算。將數(shù)據(jù)抽象成block，還有其他好處，比如分離元數(shù)據(jù)和數(shù)據(jù)的存儲(chǔ)、存儲(chǔ)管理（block大小固定方便計(jì)算）、容錯(cuò)等。

讀寫流程

寫入：client端調(diào)用filesystem的create方法，后者通過(guò)RPC調(diào)用NN的create方法，在其namespace中創(chuàng)建新的文件。NN會(huì)檢查該文件是否存在、client的權(quán)限等。成功時(shí)返回FSDataOutputStream對(duì)象。client對(duì)該對(duì)象調(diào)用write方法，這個(gè)對(duì)象會(huì)選出合適存儲(chǔ)數(shù)據(jù)副本的一組datanode，并以此請(qǐng)求DN分配新的block。這組DN會(huì)建立一個(gè)管線，例如從client node到最近的DN_1，DN_1傳遞自己接收的數(shù)據(jù)包給DN_2。DFSOutputStream自己還有一個(gè)確認(rèn)隊(duì)列。當(dāng)所有的DN確認(rèn)寫入完成后，client關(guān)閉輸出流，然后告訴NN寫入完成。

索引

簡(jiǎn)介

特點(diǎn)

• 適合：
• 數(shù)據(jù)量大，單表至少超千萬(wàn)。對(duì)稀疏數(shù)據(jù)尤其適用，因?yàn)槲臋n型數(shù)據(jù)庫(kù)的 null 就相當(dāng)于整個(gè)字段沒有，是不需要占用空間的。
• 高并發(fā)寫入，正如上面 LSM 樹所說(shuō)。
• 讀取近期小范圍數(shù)據(jù)，效率較高，大范圍需要計(jì)算引擎支持。
• 數(shù)據(jù)多版本
• 不適合：
• 小數(shù)據(jù)
• 復(fù)雜數(shù)據(jù)分析，比如關(guān)聯(lián)、聚合等，僅支持過(guò)濾
• 不支持全局跨行事務(wù)，僅支持單行事務(wù)

場(chǎng)景

• 對(duì)象存儲(chǔ)：新聞、網(wǎng)頁(yè)、圖片
• 時(shí)序數(shù)據(jù)：HBase之上有OpenTSDB模塊，可以滿足時(shí)序類場(chǎng)景的需求
• 推薦畫像：特別是用戶的畫像，是一個(gè)比較大的稀疏矩陣，螞蟻的風(fēng)控就是構(gòu)建在HBase之上
• 消息/訂單等歷史數(shù)據(jù)：在電信領(lǐng)域、銀行領(lǐng)域，不少的訂單查詢底層的存儲(chǔ)，另外不少通信、消息同步的應(yīng)用構(gòu)建在HBase之上
• Feeds流：典型的應(yīng)用就是xx朋友圈類似的應(yīng)用

架構(gòu)原理

• Client：發(fā)送DML、DDL請(qǐng)求，即數(shù)據(jù)的增刪改查和表定義等操作。
• ZooKeeper（類似微服務(wù)中的注冊(cè)中心）
• 實(shí)現(xiàn)Master的高可用：當(dāng)active master宕機(jī)，會(huì)通過(guò)選舉機(jī)制選取出新master。
• 管理系統(tǒng)元數(shù)據(jù)：比如正常工作的RegionServer列表。
• 輔助RS的宕處理：發(fā)現(xiàn)宕機(jī)，通知master處理。
• 分布式鎖：方式多個(gè)client對(duì)同一張表進(jìn)行表結(jié)構(gòu)修改而產(chǎn)生沖突。
• Master
• 處理 client 的 DDL 請(qǐng)求
• RegionServer 數(shù)據(jù)的負(fù)載均衡、宕機(jī)恢復(fù)等
• 清理過(guò)期日志
• RegionServer：處理 client 和 Master 的請(qǐng)求，由 WAL、BlockCache 以及多個(gè) Region 構(gòu)成。
• Store：一個(gè)Store存儲(chǔ)一個(gè)列簇，即一組列。
• MemStore和HFile：寫緩存，閾值為128M，達(dá)到閾值會(huì)flush成HFile文件。后臺(tái)有程序?qū)@些HFile進(jìn)行合并。
• HLog（WAL）：提高數(shù)據(jù)可靠性。寫入數(shù)據(jù)時(shí)先按順序?qū)懭際Log，然后異步刷新落盤。這樣即便 MemoStore 的數(shù)據(jù)丟失，也能通過(guò)HLog恢復(fù)。而HBase數(shù)據(jù)的主從復(fù)制也是通過(guò)HLog回放實(shí)現(xiàn)的。
• BlockCache
• Region：數(shù)據(jù)表的一個(gè)分片，當(dāng)數(shù)據(jù)表大小達(dá)到一定閾值后會(huì)“水平切分”成多個(gè)Region，通常同一張表的Region會(huì)分不到不同的機(jī)器上。

讀寫過(guò)程

1. client 根據(jù)待寫入數(shù)據(jù)的主鍵（rowkey）尋找合適的 RegionServer 地址，如果沒有符合的，就向 zookeeper 查詢存儲(chǔ)HBase元數(shù)據(jù)表的 RegionServer 地址。
2. client 從第一步找到的 RegionServer 查詢HBase元數(shù)據(jù)表，找出合適的寫入地址。
3. 將數(shù)據(jù)寫入對(duì)應(yīng)的 RegionServer 的 Region。

簡(jiǎn)介

利用 Logstash 同步 Mysql 數(shù)據(jù)時(shí)并非使用 binlog，而且不支持同步刪除操作。

特點(diǎn)

• 適合：
• 全文檢索，like "%word%"
• 一定寫入延遲的高效查詢
• 多維度數(shù)據(jù)分析
• 不合適：
• 關(guān)聯(lián)
• 數(shù)據(jù)頻繁更新
• 不支持全局跨行事務(wù)，僅支持單行事務(wù)

場(chǎng)景

• 數(shù)據(jù)分析場(chǎng)景
• 時(shí)序數(shù)據(jù)監(jiān)控
• 搜索服務(wù)

框架原理

• Master：主要負(fù)責(zé)集群中索引的創(chuàng)建、刪除以及數(shù)據(jù)的Rebalance等操作。
• Data：存儲(chǔ)和檢索數(shù)據(jù)
• Coordinator：請(qǐng)求轉(zhuǎn)發(fā)和合并檢索結(jié)果
• Ingest：轉(zhuǎn)換輸入的數(shù)據(jù)

增刪改查原理

細(xì)節(jié)補(bǔ)充

倒排索引

為什么全文檢索中 ES 比 Mysql 快？

select field1, field2
from tbl1
where field2 = a
  and field3 in (1,2,3,4)
這里如果 field2 和 field3 都建立了索引，理論上速度跟 es 差不多。es最多把 field2 和 field3 concat 起來(lái)，做到查詢時(shí)只走一次索引來(lái)提高查詢效率。

內(nèi)存消耗大

目前觸漫 ES 情況

• 適合：大批量數(shù)據(jù)的靈活計(jì)算，包括關(guān)聯(lián)、機(jī)器學(xué)習(xí)、圖計(jì)算、實(shí)時(shí)計(jì)算等。
• 不適合：小量數(shù)據(jù)的交互式計(jì)算。

Spark

架構(gòu)原理

作業(yè)例子

object SparkSQLExample {def main(args: Array[String]): Unit = {    // 創(chuàng)建 SparkSession，里面包含 sparkcontext    val spark = SparkSession      .builder()      .appName("Spark SQL basic example")      .getOrCreate()import spark.implicits._    // 讀取數(shù)據(jù)    val df1 = spark.read.load("path1...")    val df2 = spark.read.load("path2...")    // 注冊(cè)表    df1.createOrReplaceTempView("tb1")    df2.createOrReplaceTempView("tb2")    // sql    val joinedDF = sql("""        |select tb1.id, tb2.field        |from tb1 inner join tb2        |on tb1.id = tb2.id      """.stripMargin)    // driver 終端顯示結(jié)果    joinedDF.show()    // 退出 spark    spark.stop()  }}

• 文檔型數(shù)據(jù)庫(kù)：大部分都不支持關(guān)聯(lián)，因?yàn)樾实?。關(guān)聯(lián)基本都要全文檔掃描。因?yàn)槲臋n是 schemaless 的，并不確定某個(gè)文檔是否有關(guān)聯(lián)所需字段。而且個(gè)文檔的讀取都是整個(gè)對(duì)象的讀取，并不會(huì)只讀某個(gè)字段來(lái)減少內(nèi)存開銷。另外，這兩個(gè)組件在內(nèi)存中本身就有各自的數(shù)據(jù)結(jié)構(gòu)來(lái)服務(wù)讀寫，所以額外的內(nèi)存用于這類大開銷計(jì)算也是不現(xiàn)實(shí)的。因此，HBase 本身只支持簡(jiǎn)單的過(guò)濾，不支持關(guān)聯(lián)。ES 即便支持過(guò)濾、聚合，但依然不支持關(guān)聯(lián)。
• 傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)：可以完成較大數(shù)據(jù)關(guān)聯(lián)，然而效率低，這主要是受到其大量的磁盤 IO、自身服務(wù)（讀寫、事務(wù)等、數(shù)據(jù)同步）的干擾。在真正大數(shù)據(jù)情況下，這關(guān)聯(lián)還涉及數(shù)據(jù)在不同機(jī)器的移動(dòng)，數(shù)據(jù)庫(kù)需要維持其數(shù)據(jù)結(jié)構(gòu)，如 BTree，數(shù)據(jù)的移動(dòng)效率較低。
• 計(jì)算引擎：
• 基于內(nèi)存：計(jì)算引擎留有大量?jī)?nèi)存空間專門用于計(jì)算，盡量減少磁盤 IO。
• 計(jì)算并行化
• 算法優(yōu)化

• BroadcastJoin：當(dāng)一個(gè)大表和一個(gè)小表進(jìn)行Join操作時(shí)，為了避免數(shù)據(jù)的Shuffle，可以將小表的全部數(shù)據(jù)分發(fā)到每個(gè)節(jié)點(diǎn)上。算法復(fù)雜度：O(n).
• ShuffledHashJoinExec：先對(duì)兩個(gè)表進(jìn)行hash shuffle，然后把小表變成map完全存儲(chǔ)到內(nèi)存，最后進(jìn)行join。算法復(fù)雜度：O(n)。不適合兩個(gè)表都很大的情況，因?yàn)槠渲幸粋€(gè)表的hash部分要全部放到內(nèi)存。
• SortMergeJoinExec：先hash shuffle將兩表數(shù)據(jù)數(shù)據(jù)相同key的分到同一個(gè)分區(qū)，然后sort，最后join。由于排序的特性，每次處理完一條記錄后只需要從上一次結(jié)束的位置開始繼續(xù)查找。算法復(fù)雜度：O(nlogn)，主要來(lái)源于排序。適合大表join大表。之所以適合大表，是因?yàn)?join 階段，可以只讀取一部分?jǐn)?shù)據(jù)到內(nèi)存，但其中一塊遍歷完了，再把下一塊加載到內(nèi)存，這樣關(guān)聯(lián)的量就能突破內(nèi)存限制了。

數(shù)據(jù)流動(dòng)

這是一張簡(jiǎn)單的數(shù)據(jù)流程圖。描述了一個(gè) WorkCount 的數(shù)據(jù)流向。其主要代碼如下：

val textFile = sc.textFile("hdfs://...")val counts = textFile.map(word => (word, 1))                  .reduceByKey(_ + _) counts.saveAsTextFile("hdfs://...")

Flink

• 實(shí)時(shí)分析/BI指標(biāo)：比如某天搞活動(dòng)或新版本上線，需要盡快根據(jù)用戶情況來(lái)調(diào)整策略或發(fā)現(xiàn)異常。
• 實(shí)時(shí)監(jiān)控：通過(guò)實(shí)時(shí)統(tǒng)計(jì)日志數(shù)據(jù)來(lái)盡快發(fā)現(xiàn)線上問(wèn)題。
• 實(shí)時(shí)特征/樣本：模型預(yù)測(cè)和訓(xùn)練

架構(gòu)原理

細(xì)節(jié)補(bǔ)充

• 保證數(shù)據(jù)剛好被處理一次，即便在計(jì)算過(guò)程中出現(xiàn)網(wǎng)絡(luò)異常或者宕機(jī)。
• event-time處理，即按照數(shù)據(jù)中的時(shí)間作為計(jì)算引擎的時(shí)間，這樣即便數(shù)據(jù)上報(bào)出現(xiàn)一定的延遲，數(shù)據(jù)仍然可以被劃分到對(duì)應(yīng)的時(shí)間窗口。而且還能對(duì)一定時(shí)間內(nèi)的數(shù)據(jù)順序進(jìn)行修正。
• 在版本升級(jí)，修改程序并行度時(shí)不需要重啟。
• 反壓機(jī)制，即便數(shù)據(jù)量極大，F(xiàn)link 也可以通過(guò)自身的機(jī)制減緩甚至拒絕接收數(shù)據(jù)，以免程序被壓垮。

• 拉模型
• 系統(tǒng)更加成熟，尤其是離線計(jì)算
• 生態(tài)更加完善

• 推模型
• 實(shí)時(shí)計(jì)算更優(yōu)秀
• 阿里推動(dòng)，正在迅速發(fā)展
• 生態(tài)對(duì)國(guó)內(nèi)更為友好

小紅書實(shí)時(shí)技術(shù)

而后續(xù)的實(shí)時(shí)框架是這樣的

日志服務(wù)的埋點(diǎn)數(shù)據(jù)先進(jìn)入 Kafka 這一消息隊(duì)列里面。不太清楚為什么要加上 Kafka 這一中間件，或許當(dāng)時(shí)并沒有開源的 日志服務(wù)到Flink 的 connecter 吧。但總之，引入 Flink 之后就可以實(shí)時(shí)累計(jì)埋點(diǎn)中的數(shù)據(jù)，進(jìn)而產(chǎn)生實(shí)時(shí)的畫像、BI指標(biāo)和訓(xùn)練數(shù)據(jù)了。下面介紹一下這個(gè)實(shí)時(shí)歸因

如上圖所以，用戶app屏幕展示了4個(gè)筆記，然后就會(huì)有4條曝光埋點(diǎn)，而如果點(diǎn)擊筆記、點(diǎn)贊筆記以及從筆記中退出都會(huì)有相應(yīng)的埋點(diǎn)。通過(guò)這些埋點(diǎn)就可以得出右面兩份簡(jiǎn)單的訓(xùn)練或分析數(shù)據(jù)。這些數(shù)據(jù)跟原來(lái)已經(jīng)積累的筆記/用戶畫像進(jìn)行關(guān)聯(lián)就能得出一份維度更多的數(shù)據(jù)，用于實(shí)時(shí)的分析或模型預(yù)測(cè)。實(shí)時(shí)模型訓(xùn)練這一塊至少小紅書在19年8月都還沒有實(shí)現(xiàn)。下圖是小紅書推薦預(yù)測(cè)模型的演進(jìn)

那么如何進(jìn)行實(shí)時(shí)訓(xùn)練深度學(xué)習(xí)模型呢？以下是我的一些想法。借助一個(gè)阿里的開源框架flink-ai-extended。

• Martin Kleppmann: “Designing Data-Intensive Applications”, O’Reilly Media, March 2017
• Tom White: “Hadoop: The Definitive Guide”, 4th edition. O’Reilly Media, March 2015
• 胡爭(zhēng), 范欣欣: “HBase原理與實(shí)踐”, 機(jī)械工業(yè)出版社, 2019年9月
• 朱鋒, 張韶全, 黃明: “Spark SQL 內(nèi)核剖析”, 電子工業(yè)出版社, 2018年8月
• Fabian Hueske and Vasiliki Kalavri: “Stream Processing with Apache Flink”, O’Reilly Media, April 2019

• 再談 HBase 八大應(yīng)用場(chǎng)景：https://cloud.tencent.com/developer/article/1369824
• Elasticsearch讀寫原理：https://blog.csdn.net/laoyang360/article/details/103545432
• ES文章集：https://me.csdn.net/wojiushiwo987
• MySQL和Lucene索引對(duì)比分析：https://www.cnblogs.com/luxiaoxun/p/5452502.html
• 深入淺出理解 Spark：環(huán)境部署與工作原理：https://mp.weixin.qq.com/s/IdrX4Hh1HQaJZx-VnB7XsQ

• ES官方文檔：https://www.elastic.co/guide/index.html
• Spark官方文檔：http://spark.apache.org/docs/latest/
• Flink官方文檔：https://flink.apache.org/

• 基于Flink的高性能機(jī)器學(xué)習(xí)算法庫(kù)?https://www.bilibili.com/video/av57447841?p=4
• “Redefining Computation”?https://www.bilibili.com/video/av42325467?p=3
• Flink 實(shí)時(shí)數(shù)倉(cāng)的應(yīng)用?https://www.bilibili.com/video/av66782142
• Flink runtime 核心機(jī)制剖析?https://www.bilibili.com/video/av42427050?p=4
• 小紅書大數(shù)據(jù)在推薦中的應(yīng)用?https://mp.weixin.qq.com/s/o7JM7DDkUNuGZEGKBtAmIw
• TensorFlow 與 Apache Flink 的結(jié)合?https://www.bilibili.com/video/av60808586/