數(shù)據(jù)倉庫概念的提出都要追溯到上世紀(jì)了烘豌，我們認(rèn)為在大數(shù)據(jù)元年之前的數(shù)倉可以稱為傳統(tǒng)數(shù)倉，而后隨著海量數(shù)據(jù)不斷增長，以及Hadoop生態(tài)不斷發(fā)展挣惰，主要基于Hive/HDFS的離線數(shù)倉架構(gòu)可以興起并延續(xù)至今，近幾年隨著Storm/Spark（Streaming）/Flink等實(shí)時(shí)處理框架的更新迭代乃至相互取代，各廠都在著力構(gòu)建自己的實(shí)時(shí)數(shù)倉憎茂，特別是近兩年珍语，隨著Flink聲名鵲起，實(shí)時(shí)數(shù)倉更是名聲在外并且還在不斷快速發(fā)展竖幔。
目前大多企業(yè)的數(shù)據(jù)體系都是圍繞數(shù)倉的數(shù)據(jù)平臺架構(gòu)板乙，特別是在著力建設(shè)實(shí)時(shí)數(shù)倉，或者在建設(shè)離線數(shù)倉與實(shí)時(shí)數(shù)倉相統(tǒng)一的數(shù)倉體系拳氢。本文我們精選了實(shí)時(shí)數(shù)倉建設(shè)的典型代表募逞，包括美團(tuán)點(diǎn)評、網(wǎng)易馋评、知乎放接、OPPO等幾家的實(shí)時(shí)數(shù)倉架構(gòu)，他們的數(shù)倉實(shí)踐肯定對我們有所借鑒或啟迪栗恩。筆者這里特別推薦參考他們的分層設(shè)計(jì)透乾，存儲(chǔ)與計(jì)算引擎的選型。
本文舉的四個(gè)代表案例：
美團(tuán)點(diǎn)評基于 Flink 的實(shí)時(shí)數(shù)倉平臺實(shí)踐
網(wǎng)易基于Flink的嚴(yán)選實(shí)時(shí)數(shù)倉實(shí)踐
知乎實(shí)時(shí)數(shù)倉實(shí)踐及架構(gòu)演進(jìn)
OPPO 實(shí)時(shí)數(shù)倉揭秘及離線到實(shí)時(shí)的平滑遷移
從中提煉出最精彩的內(nèi)容磕秤。感謝以上文章作者的技術(shù)分享乳乌，所有內(nèi)容版權(quán)歸其個(gè)人及相關(guān)社區(qū)所有，文末給出了原文鏈接市咆。
美團(tuán)點(diǎn)評基于Flink的實(shí)時(shí)數(shù)倉平臺實(shí)踐
實(shí)時(shí)計(jì)算平臺架構(gòu)
下圖所示的是美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算平臺的架構(gòu)汉操。
最底層是收集層，這一層負(fù)責(zé)收集用戶的實(shí)時(shí)數(shù)據(jù)蒙兰，包括 Binlog磷瘤、后端服務(wù)日志以及 IoT 數(shù)據(jù)，經(jīng)過日志收集團(tuán)隊(duì)和 DB 收集團(tuán)隊(duì)的處理搜变，數(shù)據(jù)將會(huì)被收集到 Kafka 中采缚。這些數(shù)據(jù)不只是參與實(shí)時(shí)計(jì)算，也會(huì)參與離線計(jì)算挠他。
收集層之上是存儲(chǔ)層扳抽，這一層除了使用 Kafka 做消息通道之外，還會(huì)基于 HDFS 做狀態(tài)數(shù)據(jù)存儲(chǔ)以及基于 HBase 做維度數(shù)據(jù)的存儲(chǔ)殖侵。
存儲(chǔ)層之上是引擎層贸呢，包括 Storm 和 Flink。實(shí)時(shí)計(jì)算平臺會(huì)在引擎層為用戶提供一些框架的封裝以及公共包和組件的支持拢军。
在引擎層之上就是平臺層了楞陷，平臺層從數(shù)據(jù)、任務(wù)和資源三個(gè)視角去管理茉唉。
架構(gòu)的最上層是應(yīng)用層固蛾，包括了實(shí)時(shí)數(shù)倉结执、機(jī)器學(xué)習(xí)、數(shù)據(jù)同步以及事件驅(qū)動(dòng)應(yīng)用等艾凯。
從功能角度來看昌犹，美團(tuán)點(diǎn)評的實(shí)時(shí)計(jì)算平臺主要包括作業(yè)和資源管理兩個(gè)方面的功能。其中览芳，作業(yè)部分包括作業(yè)配置斜姥、作業(yè)發(fā)布以及作業(yè)狀態(tài)三個(gè)方面的功能。
在作業(yè)配置方面沧竟，則包括作業(yè)設(shè)置铸敏、運(yùn)行時(shí)設(shè)置以及拓?fù)浣Y(jié)構(gòu)設(shè)置；
在作業(yè)發(fā)布方面悟泵，則包括版本管理杈笔、編譯/發(fā)布/回滾等；
作業(yè)狀態(tài)則包括運(yùn)行時(shí)狀態(tài)糕非、自定義指標(biāo)和報(bào)警以及命令/運(yùn)行時(shí)日志等蒙具。
在資源管理方面，則為用戶提供了多租戶資源隔離以及資源交付和部署的能力朽肥。傳統(tǒng)數(shù)倉模型為了更有效地組織和管理數(shù)據(jù)禁筏，數(shù)倉建設(shè)往往會(huì)進(jìn)行數(shù)據(jù)分層，一般自下而上分為四層：ODS（操作數(shù)據(jù)層）衡招、DWD（數(shù)據(jù)明細(xì)層）篱昔、DWS（匯總層）和應(yīng)用層。即時(shí)查詢主要通過 Presto始腾、Hive 和 Spark 實(shí)現(xiàn)州刽。
實(shí)時(shí)數(shù)倉模型
實(shí)時(shí)數(shù)倉的分層方式一般也遵守傳統(tǒng)數(shù)據(jù)倉庫模型，也分為了 ODS 操作數(shù)據(jù)集浪箭、DWD 明細(xì)層和 DWS 匯總層以及應(yīng)用層穗椅。但實(shí)時(shí)數(shù)倉模型的處理的方式卻和傳統(tǒng)數(shù)倉有所差別，如明細(xì)層和匯總層的數(shù)據(jù)一般會(huì)放在 Kafka 上奶栖，維度數(shù)據(jù)一般考慮到性能問題則會(huì)放在 HBase 或者 Tair 等 KV 存儲(chǔ)上匹表，即席查詢則可以使用 Flink 完成。
準(zhǔn)實(shí)時(shí)數(shù)倉模型
在以上兩種數(shù)倉模型之外驼抹，我們發(fā)現(xiàn)業(yè)務(wù)方在實(shí)踐過程中還有一種準(zhǔn)實(shí)時(shí)數(shù)倉模型桑孩，其特點(diǎn)是不完全基于流去做拜鹤，而是將明細(xì)層數(shù)據(jù)導(dǎo)入到 OLAP 存儲(chǔ)中框冀，基于 OLAP 的計(jì)算能力去做匯總并進(jìn)行進(jìn)一步的加工。
實(shí)時(shí)數(shù)倉和傳統(tǒng)數(shù)倉的對比主要可以從四個(gè)方面考慮：
第一個(gè)是分層方式敏簿，離線數(shù)倉為了考慮到效率問題明也，一般會(huì)采取空間換時(shí)間的方式宣虾，層級劃分會(huì)比較多；則實(shí)時(shí)數(shù)倉考慮到實(shí)時(shí)性問題温数，一般分層會(huì)比較少绣硝，另外也減少了中間流程出錯(cuò)的可能性。
第二個(gè)是事實(shí)數(shù)據(jù)存儲(chǔ)方面撑刺，離線數(shù)倉會(huì)基于 HDFS鹉胖，實(shí)時(shí)數(shù)倉則會(huì)基于消息隊(duì)列（如 Kafka）。
第三個(gè)是維度數(shù)據(jù)存儲(chǔ)够傍，實(shí)時(shí)數(shù)倉會(huì)將數(shù)據(jù)放在 KV 存儲(chǔ)上面甫菠。
第四個(gè)是數(shù)據(jù)加工過程，離線數(shù)倉一般以 Hive冕屯、Spark 等批處理為主寂诱，而實(shí)時(shí)數(shù)倉則是基于實(shí)時(shí)計(jì)算引擎如 Storm、Flink 等安聘，以流處理為主痰洒。
網(wǎng)易基于Flink的嚴(yán)選實(shí)時(shí)數(shù)倉實(shí)踐
整體架構(gòu)
實(shí)時(shí)數(shù)倉整體框架依據(jù)數(shù)據(jù)的流向分為不同的層次，接入層會(huì)依據(jù)各種數(shù)據(jù)接入工具收集各個(gè)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)浴韭，如買點(diǎn)的業(yè)務(wù)數(shù)據(jù)或者業(yè)務(wù)后臺的并購放到消息隊(duì)列里面丘喻。消息隊(duì)列的數(shù)據(jù)既是離線數(shù)倉的原始數(shù)據(jù)，也是實(shí)時(shí)計(jì)算的原始數(shù)據(jù)念颈，這樣可以保證實(shí)時(shí)和離線的原始數(shù)據(jù)是統(tǒng)一的仓犬。有了源數(shù)據(jù)，在計(jì)算層經(jīng)過FLink+實(shí)時(shí)計(jì)算引擎做一些加工處理舍肠，然后落地到存儲(chǔ)層中不同存儲(chǔ)介質(zhì)當(dāng)中搀继。不同的存儲(chǔ)介質(zhì)是依據(jù)不同的應(yīng)用場景來選擇〈溆铮框架中還有FLink和Kafka的交互叽躯，在數(shù)據(jù)上進(jìn)行一個(gè)分層設(shè)計(jì)，計(jì)算引擎從Kafka中撈取數(shù)據(jù)做一些加工然后放回Kafka肌括。在存儲(chǔ)層加工好的數(shù)據(jù)會(huì)通過服務(wù)層的兩個(gè)服務(wù)：統(tǒng)一查詢点骑、指標(biāo)管理，統(tǒng)一查詢是通過業(yè)務(wù)方調(diào)取數(shù)據(jù)接口的一個(gè)服務(wù)谍夭，指標(biāo)管理是對數(shù)據(jù)指標(biāo)的定義和管理工作黑滴。通過服務(wù)層應(yīng)用到不同的數(shù)據(jù)應(yīng)用，數(shù)據(jù)應(yīng)用可能是我們的正式產(chǎn)品或者直接的業(yè)務(wù)系統(tǒng)紧索。后面會(huì)從數(shù)據(jù)的分層設(shè)計(jì)和具體的實(shí)現(xiàn)兩個(gè)方面介紹袁辈。
整體設(shè)計(jì)
上面是對數(shù)據(jù)的整體設(shè)計(jì)珠漂，主要參考了離線數(shù)倉的設(shè)計(jì)方案荞彼，也參考了業(yè)界同行的一些做法寞缝。將數(shù)據(jù)分為四個(gè)層次：
首先是ODS層，即操作數(shù)據(jù)層，通過數(shù)據(jù)采集工具收集各個(gè)業(yè)務(wù)源數(shù)據(jù)券犁；DWD層稚新，明細(xì)數(shù)據(jù)層是按主題域來劃分冲茸，通過維度建模方式來組織各個(gè)業(yè)務(wù)過程的明細(xì)數(shù)據(jù)逗栽。中間會(huì)有一個(gè)DIM層兵志，維度數(shù)據(jù)層主要做一些查詢和關(guān)聯(lián)的操作。最上層是DM層惭适，通過DWD層數(shù)據(jù)做一些指標(biāo)加工，主要面向一些分析和應(yīng)用匯總的指標(biāo)或者是做多維分析的明細(xì)數(shù)據(jù)戒突。
技術(shù)實(shí)現(xiàn)
然后介紹下技術(shù)實(shí)現(xiàn)方面的考量，主要分為計(jì)算和存儲(chǔ)描睦。對于計(jì)算方面膊存，有很多實(shí)時(shí)計(jì)算引擎，有Flink忱叭、Storm隔崎、Spark Streaming，F(xiàn)link相對于Storm的優(yōu)勢就是支持SQL韵丑，相對于Spark Streaming又有一個(gè)相對好的性能表現(xiàn)仍稀。同時(shí)Flink在支持好的應(yīng)用和性能方面還有比較好的語義支持和比較好的容錯(cuò)機(jī)制，因此構(gòu)建實(shí)時(shí)數(shù)倉Flink是一個(gè)比較好的實(shí)時(shí)計(jì)算引擎選擇埂息。技術(shù)實(shí)現(xiàn)中
Flink的具體作用：
Flink作為實(shí)時(shí)的計(jì)算引擎技潘，不同的數(shù)據(jù)層（ods->dwd->dm）之間，不同的存儲(chǔ)引擎（kafka->db）都是通過Flink job串聯(lián)的千康，相關(guān)的etl和關(guān)聯(lián)享幽、聚合等操作也是在Flink中完成。
對于存儲(chǔ)層會(huì)依據(jù)不同的數(shù)據(jù)層的特點(diǎn)選擇不同的存儲(chǔ)介質(zhì)拾弃，ODS層和DWD層都是存儲(chǔ)的一些實(shí)時(shí)數(shù)據(jù)值桩，選擇的是Kafka進(jìn)行存儲(chǔ)，在DWD層會(huì)關(guān)聯(lián)一些歷史明細(xì)數(shù)據(jù)豪椿，會(huì)將其放到Redis里面奔坟。在DIM層主要做一些高并發(fā)維度的查詢關(guān)聯(lián)携栋，一般將其存放在HBase里面，對于DIM層比價(jià)復(fù)雜咳秉，需要綜合考慮對于數(shù)據(jù)落地的要求以及具體的查詢引擎來選擇不同的存儲(chǔ)方式婉支。對于常見的指標(biāo)匯總模型直接放在MySQL里面，維度比較多的澜建、寫入更新比較大的模型會(huì)放在HBase里面向挖，還有明細(xì)數(shù)據(jù)需要做一些多維分析或者關(guān)聯(lián)會(huì)將其存儲(chǔ)在Greenplum里面，還有一種是維度比較多炕舵、需要做排序何之、查詢要求比較高的，如活動(dòng)期間用戶的銷售列表等大列表直接存儲(chǔ)在Redis里面咽筋。
知乎實(shí)時(shí)數(shù)倉架構(gòu)實(shí)踐與演進(jìn)
本文主要講述知乎的實(shí)時(shí)數(shù)倉實(shí)踐以及架構(gòu)的演進(jìn)溶推，這包括以下幾個(gè)方面：
實(shí)時(shí)數(shù)倉 1.0 版本，主題：ETL 邏輯實(shí)時(shí)化奸攻，技術(shù)方案：Spark Streaming悼潭。
實(shí)時(shí)數(shù)倉 2.0 版本，主題：數(shù)據(jù)分層舞箍，指標(biāo)計(jì)算實(shí)時(shí)化舰褪，技術(shù)方案：Flink Streaming。
實(shí)時(shí)數(shù)倉未來展望：Streaming SQL 平臺化疏橄，元信息管理系統(tǒng)化占拍，結(jié)果驗(yàn)收自動(dòng)化。
上圖：實(shí)時(shí)數(shù)倉 1.0
第一部分是數(shù)據(jù)采集捎迫，由三端 SDK 采集數(shù)據(jù)并通過 Log Collector Server 發(fā)送到 Kafka晃酒。第二部分是數(shù)據(jù) ETL，選擇了 Spark Streaming 作為實(shí)時(shí)數(shù)據(jù)的處理框架窄绒，主要完成對原始數(shù)據(jù)的清洗和加工并分實(shí)時(shí)和離線導(dǎo)入 Druid贝次。第三部分是數(shù)據(jù)可視化，由 Druid 負(fù)責(zé)計(jì)算指標(biāo)并通過 Web Server 配合前端完成數(shù)據(jù)可視化彰导。
1.0 版本的實(shí)時(shí)數(shù)倉有以下幾個(gè)不足：
所有的流量數(shù)據(jù)存放在同一個(gè) Kafka Topic 中蛔翅，如果下游每個(gè)業(yè)務(wù)線都要消費(fèi)，這會(huì)導(dǎo)致全量數(shù)據(jù)被消費(fèi)多次位谋，Kafka 出流量太高無法滿足該需求山析。
所有的指標(biāo)計(jì)算全部由 Druid 承擔(dān)，Druid 同時(shí)兼顧實(shí)時(shí)數(shù)據(jù)源和離線數(shù)據(jù)源的查詢掏父，隨著數(shù)據(jù)量的暴漲 Druid 穩(wěn)定性急劇下降笋轨，這導(dǎo)致各個(gè)業(yè)務(wù)的核心報(bào)表不能穩(wěn)定產(chǎn)出。
由于每個(gè)業(yè)務(wù)使用同一個(gè)流量數(shù)據(jù)源配置報(bào)表，導(dǎo)致查詢效率低下爵政，同時(shí)無法對業(yè)務(wù)做數(shù)據(jù)隔離和成本計(jì)算仅讽。
隨著數(shù)據(jù)量的暴漲，Druid 中的流量數(shù)據(jù)源經(jīng)常查詢超時(shí)同時(shí)各業(yè)務(wù)消費(fèi)實(shí)時(shí)數(shù)據(jù)的需求也開始增多钾挟，如果繼續(xù)沿用實(shí)時(shí)數(shù)倉 1.0 架構(gòu)洁灵，需要付出大量的額外成本。于是等龙，在實(shí)時(shí)數(shù)倉 1.0 的基礎(chǔ)上处渣，我們建立起了實(shí)時(shí)數(shù)倉 2.0伶贰，梳理出了新的架構(gòu)設(shè)計(jì)并開始著手建立實(shí)時(shí)數(shù)倉體系蛛砰，新的架構(gòu)如下圖所示。
上圖：實(shí)時(shí)數(shù)倉 2.0
相比實(shí)時(shí)數(shù)倉 1.0 以 Spark Streaming 作為主要實(shí)現(xiàn)技術(shù)黍衙，在實(shí)時(shí)數(shù)倉 2.0 中泥畅，我們將 Flink 作為指標(biāo)匯總層的主要計(jì)算框架。Flink 相比 Spark Streaming 有更明顯的優(yōu)勢琅翻，主要體現(xiàn)在：低延遲位仁、Exactly-once 語義支持、Streaming SQL 支持方椎、狀態(tài)管理聂抢、豐富的時(shí)間類型和窗口計(jì)算、CEP 支持等棠众。從實(shí)時(shí)數(shù)倉 1.0 到 2.0琳疏，不管是數(shù)據(jù)架構(gòu)還是技術(shù)方案，我們在深度和廣度上都有了更多的積累闸拿。隨著公司業(yè)務(wù)的快速發(fā)展以及新技術(shù)的誕生空盼，實(shí)時(shí)數(shù)倉也會(huì)不斷的迭代優(yōu)化。短期可預(yù)見的我們會(huì)從以下方面進(jìn)一步提升實(shí)時(shí)數(shù)倉的服務(wù)能力：
Streaming SQL 平臺化新荤。目前 Streaming SQL 任務(wù)是以代碼開發(fā) maven 打包的方式提交任務(wù)揽趾，開發(fā)成本高，后期隨著 Streaming SQL 平臺的上線苛骨，實(shí)時(shí)數(shù)倉的開發(fā)方式也會(huì)由 Jar 包轉(zhuǎn)變?yōu)?SQL 文件篱瞎。
實(shí)時(shí)數(shù)據(jù)元信息管理系統(tǒng)化。對數(shù)倉元信息的管理可以大幅度降低使用數(shù)據(jù)的成本痒芝，離線數(shù)倉的元信息管理已經(jīng)基本完善奔缠，實(shí)時(shí)數(shù)倉的元信息管理才剛剛開始。
實(shí)時(shí)數(shù)倉結(jié)果驗(yàn)收自動(dòng)化吼野。對實(shí)時(shí)結(jié)果的驗(yàn)收只能借助與離線數(shù)據(jù)指標(biāo)對比的方式校哎，以 Hive 和 Kafka 數(shù)據(jù)源為例，分別執(zhí)行 Hive SQL 和 Flink SQL，統(tǒng)計(jì)結(jié)果并對比是否一致實(shí)現(xiàn)實(shí)時(shí)結(jié)果驗(yàn)收的自動(dòng)化闷哆。
OPPO 實(shí)時(shí)數(shù)倉揭秘：從頂層設(shè)計(jì)實(shí)現(xiàn)離線與實(shí)時(shí)的平滑遷移
以數(shù)倉為中心的數(shù)據(jù)架構(gòu)
在過去幾年的時(shí)間里面腰奋，OPPO 內(nèi)部的這套以數(shù)倉為核心的數(shù)據(jù)架構(gòu)已經(jīng)逐漸開始成熟了。
離線到實(shí)時(shí)數(shù)倉的平滑遷移
OPPO 希望所設(shè)計(jì)出來的實(shí)時(shí)數(shù)倉能夠?qū)崿F(xiàn)從離線到實(shí)時(shí)的平滑遷移抱怔，之前大家如何使用和開發(fā)離線數(shù)倉劣坊，如今到了實(shí)時(shí)數(shù)倉也希望大家如何開發(fā)和使用。通常而言屈留，當(dāng)設(shè)計(jì)一款產(chǎn)品或者平臺的時(shí)候局冰，可以劃分為兩層，即底層實(shí)現(xiàn)和上層抽象灌危。對于底層實(shí)現(xiàn)而言康二，可能會(huì)有不同的技術(shù)，從 Hive 到 Flink勇蝙，從 HDFS 到 Kafka沫勿。而在上層抽象而言，則希望對于用戶而言是透明的味混。
實(shí)時(shí)數(shù)倉的層級劃分
如下圖所示的是 OPPO 實(shí)時(shí)數(shù)倉的分層結(jié)構(gòu)产雹，從接入層過來之后，所有的數(shù)據(jù)都是會(huì)用 Kafka 來支撐的翁锡，數(shù)據(jù)接入進(jìn)來放到 Kafka 里面實(shí)現(xiàn) ODS 層蔓挖，然后使用 Flink SQL 實(shí)現(xiàn)數(shù)據(jù)的清洗，然后就變到了 DWD 層馆衔，中間使用 Flink SQL 實(shí)現(xiàn)一些聚合操作瘟判，就到了 ADS 層，最后根據(jù)不同的業(yè)務(wù)使用場景再導(dǎo)入到ES等系統(tǒng)中去哈踱。當(dāng)然荒适，其中的一些維度層位于 MySQL 或者 Hive 中。
SQL一統(tǒng)天下的數(shù)據(jù)架構(gòu)
對于數(shù)倉領(lǐng)域的近期發(fā)展而言开镣，其中很有意思的一點(diǎn)是：無論是離線還是實(shí)時(shí)的數(shù)據(jù)架構(gòu)刀诬，都慢慢演進(jìn)成了 SQL 一統(tǒng)天下的架構(gòu)。無論是離線還是實(shí)時(shí)是數(shù)據(jù)倉庫邪财，無論是接入陕壹，查詢、開發(fā)還是業(yè)務(wù)系統(tǒng)都是在上面寫 SQL 的方式树埠。
寫在最后的話
總結(jié)下糠馆，實(shí)時(shí)數(shù)倉主要有兩個(gè)要點(diǎn)。首先是分層設(shè)計(jì)上怎憋，一般也是參考離線數(shù)倉的設(shè)計(jì)又碌，通常會(huì)分為ODS操作數(shù)據(jù)層九昧、DWD明細(xì)層、DWS匯總層以及ADS應(yīng)用層毕匀，可能還會(huì)分出一層DIM維度數(shù)據(jù)層铸鹰。另外分層設(shè)計(jì)上也有不同的思路，比如可以將DWS和ADS歸為DM數(shù)據(jù)集市層皂岔，網(wǎng)易嚴(yán)選就是這樣設(shè)計(jì)的蹋笼。
技術(shù)選型上，離線數(shù)倉一般依托HDFS或Hive構(gòu)建躁垛，選擇MR或Spark計(jì)算引擎剖毯；實(shí)時(shí)數(shù)倉存儲(chǔ)層更多是選擇Kafka等消息引擎，通常明細(xì)層和匯總層都放在Kafka教馆，計(jì)算層則多是選擇Flink/Spark Streaming/Storm逊谋，這方面Flink更有優(yōu)勢，社區(qū)也更傾向于選擇Flink活玲。大概總結(jié)這么多涣狗，筆者才疏學(xué)淺谍婉，有不同看法的同學(xué)歡迎留言討論舒憾。
作者：大數(shù)據(jù)技術(shù)架構(gòu)
鏈接：http://www.reibang.com/p/5194736aee50
來源：簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)穗熬，非商業(yè)轉(zhuǎn)載請注明出處镀迂。
關(guān)注我的公眾號，后臺回復(fù)【JAVAPDF】獲取200頁面試題唤蔗！
5萬人關(guān)注的大數(shù)據(jù)成神之路探遵，不來了解一下嗎？
5萬人關(guān)注的大數(shù)據(jù)成神之路妓柜，真的不來了解一下嗎箱季？
5萬人關(guān)注的大數(shù)據(jù)成神之路，確定真的不來了解一下嗎棍掐？
歡迎您關(guān)注《大數(shù)據(jù)成神之路》
[圖片上傳失敗...(image-437cab-1593172867584)]
