大數(shù)據(jù)中臺(tái)架構(gòu)棧

近來數(shù)據(jù)中臺(tái)概念大火，大家對(duì)它的定義也五花八門，不一而足。但無論怎么定義，一個(gè)完善的數(shù)據(jù)技術(shù)架構(gòu)必不可少。了解這些架構(gòu)里每個(gè)部分的位置，功能和含義，不僅能讓我們更好了解數(shù)據(jù)產(chǎn)品的范圍和邊界，知道技術(shù)能幫我們實(shí)現(xiàn)什么，能怎么實(shí)現(xiàn)得更好，另一方面，很多技術(shù)的設(shè)計(jì)理念對(duì)我們認(rèn)知世界，了解復(fù)雜系統(tǒng)也會(huì)有所裨益。因此這篇文章旨在梳理市面上常見的開源技術(shù)方案，背后原理及應(yīng)用場景，幫助產(chǎn)品經(jīng)理對(duì)大數(shù)據(jù)技術(shù)體系有個(gè)大致全面的了解。一般來說，我們將數(shù)據(jù)整個(gè)鏈條區(qū)分為四個(gè)環(huán)節(jié)，從數(shù)據(jù)采集傳輸，到數(shù)據(jù)存儲(chǔ)，再到數(shù)據(jù)計(jì)算&查詢，到后續(xù)的數(shù)據(jù)可視化及分析?？蚣軋D如下：'￥觸"上hHjdoopI^jaA.數(shù)據(jù)采集傳輸這個(gè)一般對(duì)應(yīng)于公司的日志平臺(tái)，任務(wù)是將數(shù)據(jù)采集后緩存在某個(gè)地方，供后續(xù)的計(jì)算流程進(jìn)行消費(fèi)使用。針對(duì)不同的數(shù)據(jù)來源有各自的采集方式，從APP/服務(wù)器日志，到業(yè)務(wù)表，還有各種API接口及數(shù)據(jù)文件等等。其中因?yàn)槿罩緮?shù)據(jù)有數(shù)據(jù)量多，數(shù)據(jù)結(jié)構(gòu)多樣，產(chǎn)生環(huán)境復(fù)雜等特點(diǎn)，屬于「重點(diǎn)關(guān)照」的對(duì)象。目前市面針對(duì)日志采集的有Flume，Logstash，F(xiàn)ilebeat，F(xiàn)luentd，rsyslog幾種常見的框架，我們挑應(yīng)用較廣泛的前兩者介紹下：Flume和LogstashFlume是一款由Cloudera開發(fā)的實(shí)時(shí)采集日志引擎，主打高并發(fā)，高速度，分布式海量日志采集。它是一種提供高可用、高可靠、分布式海量日志采集、聚合和傳輸?shù)南到y(tǒng)。Flume支持在日志系統(tǒng)中定制各類數(shù)據(jù)進(jìn)行發(fā)送，用于采集數(shù)據(jù)；同時(shí)，它支持對(duì)數(shù)據(jù)進(jìn)行簡單處理，并寫到各種數(shù)據(jù)接收方。目前有兩個(gè)版本，OG和NG，特點(diǎn)主要是：側(cè)重?cái)?shù)據(jù)傳輸，有內(nèi)部機(jī)制確保不會(huì)丟數(shù)據(jù)，用于重要日志場景由java開發(fā)，沒有豐富的插件，主要靠二次開發(fā)配置繁瑣，對(duì)外暴露監(jiān)控端口有數(shù)據(jù)

SourceSinkHOFSChannel徵信等ourS^neLogstash是Elastic.co旗下的一個(gè)開源數(shù)據(jù)收集引擎，可動(dòng)態(tài)的統(tǒng)一不同的數(shù)據(jù)源的數(shù)據(jù)至目的地，搭配ElasticSearch進(jìn)行分析，Kibana進(jìn)行頁面展示，是著名的ELK技術(shù)棧中的「L」部分。特點(diǎn)主要是:內(nèi)部沒有一個(gè)persistqueue，異常情況可能會(huì)丟失部分?jǐn)?shù)據(jù)由ruby編寫，需要ruby環(huán)境，插件很多配置簡單，偏重?cái)?shù)據(jù)前期處理，分析方便從兩者的設(shè)計(jì)思想來看，F(xiàn)lume最初并不是為了采集日志而設(shè)計(jì)，而是定位在把數(shù)據(jù)傳入HDFS中，這和Logstash有根本的區(qū)別。所以它理所應(yīng)當(dāng)側(cè)重于數(shù)據(jù)的傳輸和安全，且需要更多的二次開發(fā)和配置工作。而Logstash明顯側(cè)重先對(duì)日志數(shù)據(jù)進(jìn)行預(yù)處理，為后續(xù)的解析做鋪墊。它搭配ELK技術(shù)棧使用起來比較簡單，更像是為你準(zhǔn)備好的便當(dāng)，開盒即食。日志采集如何工作我們以Flume為例子講些日志采集Agent是怎么工作的。Flume由三個(gè)部分組成：Source，Channel和Sink，對(duì)應(yīng)于采集，緩存和保存三個(gè)環(huán)節(jié)。

其中，Source組件用來采集各種類型的數(shù)據(jù)源，如directory、http、kafka等。Channel組件用來緩存數(shù)據(jù)，有memorychannel，JDBCchannel和kafkachannel三種。最后再通過Sink組件進(jìn)行保存，分別支持HDFS，HBase，Hive和Kafka四種存儲(chǔ)方式。下面結(jié)合一個(gè)大數(shù)據(jù)實(shí)時(shí)處理系統(tǒng)闡述下Flume在實(shí)際應(yīng)用中所扮演的重要角色。該實(shí)時(shí)處理系統(tǒng)整體架構(gòu)如下：通過將Agent部署在Web服務(wù)器，一旦發(fā)生新增的日志數(shù)據(jù)，就會(huì)被Flume程序監(jiān)聽到，并且最終會(huì)傳輸?shù)終afka的Topic中，再進(jìn)行后續(xù)的一系列操作。勵(lì)fedis勵(lì)fedis數(shù)據(jù)傳輸KafkaKafka最初是由領(lǐng)英開發(fā)，并隨后于20n年初開源，并于2012年10月23日由ApacheIncubato孵化出站。該項(xiàng)目的目標(biāo)是為處理實(shí)時(shí)數(shù)據(jù)提供一個(gè)統(tǒng)一、高吞吐、低延遲的平臺(tái)。其持久化層本質(zhì)上是一個(gè)“按照分布式事務(wù)日志架構(gòu)的大規(guī)模發(fā)布/訂閱消息隊(duì)列”，這使它作為企業(yè)級(jí)基礎(chǔ)設(shè)施來處理流式數(shù)據(jù)非常有價(jià)值。

KafkaProducerKafka

StreamsISIkafkaKafkaConnectSourceKafkaProducerKafka

StreamsISIkafkaKafkaConnectSource2.數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫存儲(chǔ)方面，有單機(jī)/分布式、關(guān)系型/非關(guān)系型、列式存儲(chǔ)/行式存儲(chǔ)三個(gè)維度的劃分，各種維度交叉下都有對(duì)應(yīng)產(chǎn)品來解決某個(gè)場景下的需求。在數(shù)據(jù)量較小的情況下，一般采取單機(jī)數(shù)據(jù)庫，如應(yīng)用非常廣泛，技術(shù)成熟的MySQL。數(shù)據(jù)量大到一定程度后，就必須采取分布式系統(tǒng)了。目前業(yè)界最知名的就是Apache基金會(huì)名下的Hadoop系統(tǒng)，它基本可以作為大數(shù)據(jù)時(shí)代存儲(chǔ)計(jì)算的經(jīng)典模型。HDFSHDFS作為Hadoop里的分布式文件系統(tǒng)，為HBase和Hive們提供了高可靠性的底層存儲(chǔ)支持，對(duì)應(yīng)于GoogleGFS的開源實(shí)現(xiàn)。一般也會(huì)用于一些批次分析的場景。HBaseHBase是Hadoop數(shù)據(jù)庫，作為基于列的非關(guān)系型數(shù)據(jù)庫運(yùn)行在HDFS上。它具備HDFS缺乏的隨機(jī)讀寫能力，因此比較適合實(shí)時(shí)分析。HBase以GoogleBigTable為藍(lán)本，以Key-Value形式存儲(chǔ)，能快速在主機(jī)內(nèi)數(shù)十億行數(shù)據(jù)中定位所需的數(shù)據(jù)并訪問它。Hive和PigHive和Pig都是集成在Hadoop頂層的查詢語言，提供靜態(tài)數(shù)據(jù)的動(dòng)態(tài)查詢，支持類SQL語言，底層經(jīng)過編譯轉(zhuǎn)為MapReduce程序，省去了自己編寫MR程序的繁瑣。區(qū)別是HiveSQL是類SQL的查詢語言，要求數(shù)據(jù)存儲(chǔ)于表中，而Pig是面向數(shù)據(jù)流的一個(gè)程序語言，常用于開發(fā)簡潔的腳本來轉(zhuǎn)換數(shù)據(jù)流從而嵌入到較大的應(yīng)用程序中。MapReduceMR開創(chuàng)了分布時(shí)代計(jì)算的先河，使得大批量數(shù)據(jù)處理成為可能。簡單來講，就是將比較龐大的計(jì)算任務(wù)先分組，再匯總，提高計(jì)算效率。舉例來講，如果你新家需要裝修，要在不同地方購置很多東西。你一個(gè)人（單機(jī)）去買估計(jì)得花十天?，F(xiàn)在叫了一堆小伙伴（分布式），每個(gè)人負(fù)責(zé)去一個(gè)地方買東西（Map），最后再拿到家里分類匯總（Reduce），一天就搞定了。INPUTSPLITMAPCOMBINEPARTITIONREDUCE其他輔助工具上圖中的其他工具是為了保證整個(gè)大數(shù)據(jù)計(jì)算存儲(chǔ)系統(tǒng)更加健壯和開放，如Zookeeper提供了穩(wěn)定服務(wù)和failover機(jī)制，Sqoop則為Hadoop提供了方便的RDBMS(關(guān)系型數(shù)據(jù)庫)數(shù)據(jù)導(dǎo)入功能，使得傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)向HBase中遷移變的非常方便。值得一提的是，Hadoop生態(tài)其實(shí)是建立在Google2003年發(fā)表的三大論文的基礎(chǔ)之上?？赡苁钱?dāng)時(shí)Google有意改善業(yè)內(nèi)落后的現(xiàn)狀，讓大家稍微跟得上他的腳步才發(fā)布的論文…這么多年過去了，不知道Google內(nèi)部對(duì)數(shù)據(jù)的理解和使用又到了什么樣的高度。數(shù)據(jù)計(jì)算&查詢3.1批計(jì)算和流計(jì)算大數(shù)據(jù)處理場景可分為批處理和流處理兩個(gè)，分別對(duì)應(yīng)離線分析和實(shí)時(shí)分析。常見框架分類有：僅批處理框架：HadoopMapReduce僅流處理框架：Storm，Samza混合框架：Spark，F(xiàn)link篇幅所限，除了上文已經(jīng)提到的Hadoop生態(tài)外，我們再簡單科普下Spark：Spark和FlinkApacheSpark是一種包含流處理能力的下一代批處理框架。批處理模式下，Spark與MapReduce不同，它將數(shù)據(jù)處理工作全部在內(nèi)存中進(jìn)行，計(jì)算性能大幅改善。流處理模式下，Spark主要通過SparkStreaming實(shí)現(xiàn)了一種叫做微批(Micro-batch)的概念。該技術(shù)可以將數(shù)據(jù)流視作一系列非常小的“批”，借此即可通過批處理引擎的原生語義進(jìn)行處理。這種方式的實(shí)際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。綜上所述，Spark是多樣化工作負(fù)載處理任務(wù)的最佳選擇。Spark批處理能力以更高內(nèi)存占用為代價(jià)提供了無與倫比的速度優(yōu)勢。對(duì)于重視吞吐率而非延遲的工作負(fù)載，則比較適合使用SparkStreaming作為流處理解決方案。而Flink作為更新一代的處理框架，擁有更快的計(jì)算能力，更低的延遲，已經(jīng)慢慢嶄露頭角。不過一個(gè)框架的應(yīng)用，特別是開源框架，需要足夠長的時(shí)間進(jìn)行運(yùn)行，測試和優(yōu)化。大數(shù)據(jù)技術(shù)在開源社區(qū)的推動(dòng)下，迭代日新月異。在不久的將來，相信Flink會(huì)像Spark取代Storm一樣，逐漸成為大數(shù)據(jù)處理技術(shù)的主流。數(shù)據(jù)查詢經(jīng)過處理后的數(shù)據(jù)，還需要有高效的查詢引擎才能被用戶接觸和使用。目前OLAP的查詢技術(shù)框架大致可分為三類：基于HBase做預(yù)聚合：如Opentsdb,Kylin等，均需指定預(yù)聚合的指標(biāo)，在數(shù)據(jù)接入的時(shí)候進(jìn)行聚合運(yùn)算，適合相對(duì)固定，維度較多的業(yè)務(wù)報(bào)表類需求基于Parquet做列式存儲(chǔ)：如Presto,Drill,Impala等，基本是完全基于內(nèi)存的并行計(jì)算，Parquet系能降低存儲(chǔ)空間，提高IO效率，以離線處理為主，很難提高數(shù)據(jù)寫的實(shí)時(shí)性，超大表的Join支持可能不夠好基于Lucene做外部索引：如ElasticSearch，Solr等，能夠滿足的的查詢場景遠(yuǎn)多于傳統(tǒng)的數(shù)據(jù)庫存儲(chǔ)，但對(duì)于日志、行為類時(shí)序數(shù)據(jù)，所有的搜索請(qǐng)求都也必須搜索所有的分片，另外，對(duì)于聚合分析場景的支持也是軟肋我們以常見的Presto,Druid，Kylin三個(gè)模型來講講各自的特點(diǎn)：Presto：由Facebook開源，是一個(gè)分布式數(shù)據(jù)查詢框架，原生集成了Hive、Hbase和關(guān)系型數(shù)據(jù)庫。它背后所使用的執(zhí)行模式與Hive有根本的不同，并沒有使用MapReduce。因其所有的處理都在內(nèi)存中完成（與上文的Spark類似），大部分場景下要比Hive快一個(gè)數(shù)量級(jí)Druid：由MetaMarket開源，是一個(gè)分布式、面向列式存儲(chǔ)的準(zhǔn)實(shí)時(shí)分析數(shù)據(jù)存儲(chǔ)系統(tǒng)，延遲性最細(xì)顆粒度可到5分鐘。它能夠在高并發(fā)環(huán)境下，保證海量數(shù)據(jù)查詢分析性能，同時(shí)又提供海量實(shí)時(shí)數(shù)據(jù)的查詢、分析與可視化功能Kylin：Cube預(yù)計(jì)算技術(shù)是其核心，基本思路是預(yù)先對(duì)數(shù)據(jù)作多維索引，查詢時(shí)只掃描索引而不訪問原始數(shù)據(jù)從而提速。劣勢在于每次增減維度必須對(duì)Cube進(jìn)行歷史數(shù)據(jù)重算追溯，非常消耗時(shí)間。據(jù)說Kylingence在前幾天的新品發(fā)布會(huì)上已經(jīng)解決了這個(gè)問題，拭目以待下圖引自快手在OLAP技術(shù)選型時(shí)的評(píng)價(jià)，以供大家參考：OLAP技術(shù)實(shí)現(xiàn)方案對(duì)比Hiwe/即出KyliriE$Druid好好中好差好中好差中好好離井發(fā)差好好好鼠he?靈活性好差汗好辭超財(cái)制5Q期1好好中很多時(shí)候，在計(jì)算和查詢這塊沒有明顯的邊界區(qū)分。這里為了方便闡述分成了兩個(gè)部分。事實(shí)上，對(duì)于技術(shù)能力比較強(qiáng)的團(tuán)隊(duì)，可以針對(duì)這些開源系統(tǒng)進(jìn)行魔改，比如采用Kylin的預(yù)計(jì)算能力+Druid的查詢引擎，來提高查詢的速度等等。4.數(shù)據(jù)可視化及分析在數(shù)據(jù)可視化這塊，一般會(huì)采取三個(gè)途徑來進(jìn)行數(shù)據(jù)展示。最基礎(chǔ)的利用開源的圖表庫，如國外的HighCharts、D3，百度的ECharts，還有阿里Antv的G2、G6、F2等。往上一層是各個(gè)知名公司開源的可視化框架，如Airbnb的Superset，Redash，Metabase等等。這些框架一般能夠滿足從數(shù)據(jù)源接入，

自助制作報(bào)表和報(bào)表整理展示的功能，接入起來更加方便。再往上一層就是商用的可視化軟件，如國外的Tableau,Qlik,國內(nèi)的FineReport，永洪BI等等。這種軟件需要付費(fèi)，但都具備更豐富的可視化功能并提供一些技術(shù)支持，對(duì)于那些沒有精力折騰可視化的公司會(huì)是個(gè)不錯(cuò)的選擇。圖表庫理解整個(gè)圖表開源生態(tài)，我們得先了解下SVG和Canvas這兩個(gè)瀏覽器提供的原生能力。SVG全稱叫可縮放矢量圖，跟HTML一樣，有自己的命名空間，使用XML標(biāo)簽來繪圖。而Canvas是HTML5中的新標(biāo)簽，用于客戶端的圖形繪制，有一個(gè)基于Java的繪圖API。D3.js全稱是Data-DrivenDocuments，支持SVG和Canvas。相對(duì)于其他產(chǎn)品，它更偏底層，并沒有對(duì)圖表進(jìn)行歸類。開發(fā)者可以通過D3豐富的類庫來方便的操作DOM，繪制任何想繪制的圖形，以增加開發(fā)復(fù)雜度的代價(jià)，覆蓋更加全面的可視化場景。VisualIndexBoxPlotsBulletChartsNon-contFguousCartogramBubbleChartDendrogramCalendarViewForce-DirectedGraphCirclePackingSunburstPopulationPyramidstackedBarsStreamgraphTneennapVoronoiDiagramBoxPlotsBulletChartsNon-contFguousCartogramBubbleChartDendrogramCalendarViewForce-DirectedGraphCirclePackingSunburstPopulationPyramidstackedBarsStreamgraphTneennapVoronoiDiagram而國外的HighCharts是基于SVG開發(fā)的圖表庫，ECharts和G2則均基于Canvas。ECharts有完整的圖表封裝，開箱即用，而G2則是一套基于可視化編碼的圖形語法，以數(shù)據(jù)驅(qū)動(dòng)，具有高度的易用性和擴(kuò)展性。阿里后續(xù)基于G2又往上封裝了一套基于React的圖表庫Bizcharts，主打電商業(yè)務(wù)圖表可視化，沉淀電商業(yè)務(wù)線的可視化規(guī)范。在React項(xiàng)目中實(shí)現(xiàn)常見圖表和自定義圖表。

ECharts和G2的對(duì)比可借用ECharts作者的一句話，ECharts和G2的對(duì)比可借用ECharts作者的一句話，G2是面粉，ECharts是面條，皆微小但美好。BiffLItmolLr*可視化框架這里主要介紹下業(yè)內(nèi)比較出名的Superset和Metabase。前者的方案更加完善，支持集合不同數(shù)據(jù)源形成對(duì)應(yīng)的指標(biāo)，再通過豐富的圖表類型進(jìn)行可視化。在時(shí)間序列分析上比較出色，支持移動(dòng)平均及周期偏移等分析方法。同時(shí)與Druid深度集成，可以快速解析大規(guī)模數(shù)據(jù)