實(shí)時(shí)計(jì)算Flink版總體介紹4實(shí)時(shí)數(shù)倉(cāng)助力互聯(lián)網(wǎng)實(shí)時(shí)決策和精準(zhǔn)營(yíng)銷62Hologres數(shù)據(jù)導(dǎo)入/導(dǎo)出實(shí)踐實(shí)時(shí)計(jì)算Flink版總體介紹大數(shù)據(jù)的高速發(fā)展已經(jīng)超過10年，大數(shù)據(jù)也正在從計(jì)算規(guī)模化向更加實(shí)時(shí)化的趨勢(shì)演比如阿里巴巴舉辦的購(gòu)物狂環(huán)節(jié)雙11，可以通過實(shí)時(shí)大屏展示整個(gè)雙11實(shí)時(shí)的交易額、成交額，并可實(shí)現(xiàn)毫秒級(jí)的更新；全球華人都會(huì)觀看的中央電視臺(tái)春節(jié)聯(lián)歡晚會(huì)，可以通過春晚大屏，實(shí)時(shí)統(tǒng)計(jì)全國(guó)的收視率與觀眾畫像；現(xiàn)在多個(gè)城市都有的城市大腦項(xiàng)目，通過IoT的攝像頭信息，實(shí)時(shí)捕獲各個(gè)城市中的交通、車輛、人流等信息去做交通的監(jiān)察和治理；還有金融行業(yè)，在銀行、證券交易所等機(jī)構(gòu)的核心業(yè)務(wù)場(chǎng)景下，也都在通過大數(shù)據(jù)實(shí)時(shí)計(jì)算能力實(shí)時(shí)監(jiān)控交易行為，進(jìn)行反作弊反洗錢等行為的探測(cè)；除此之外，在整個(gè)淘寶電商交易的場(chǎng)景下，實(shí)時(shí)根據(jù)用戶的行為進(jìn)行個(gè)性化推薦，基于用戶在前一分鐘或者30秒內(nèi)瀏覽商品情況，在后續(xù)的瀏覽中系統(tǒng)就會(huì)根據(jù)算法測(cè)算用戶畫像，然后實(shí)時(shí)向用戶推薦可能會(huì)喜歡的相關(guān)商品等?？梢哉f這么多日常生活中涉及的場(chǎng)景，背后都是由實(shí)時(shí)計(jì)算在推動(dòng)生產(chǎn)力的提升，日夜不息。實(shí)時(shí)計(jì)算需要后臺(tái)有一套極其強(qiáng)大的大數(shù)據(jù)計(jì)算能力，ApacheFlink作為一款開源大數(shù)據(jù)實(shí)時(shí)計(jì)算技術(shù)應(yīng)運(yùn)而生。它從設(shè)計(jì)之初就由流計(jì)算開啟，因?yàn)閭鹘y(tǒng)的Hadoop、Spark等計(jì)算引擎，本質(zhì)上是批計(jì)算引擎，通過對(duì)有限的數(shù)據(jù)集進(jìn)行數(shù)據(jù)處理，其處理延時(shí)性是不能保證的。而ApacheFlink作為流式計(jì)算引擎，它可以實(shí)時(shí)訂閱實(shí)時(shí)產(chǎn)生的現(xiàn)實(shí)數(shù)據(jù)，并實(shí)時(shí)對(duì)數(shù)據(jù)進(jìn)行分析處理并產(chǎn)生結(jié)果，讓數(shù)據(jù)在第一時(shí)間發(fā)揮價(jià)值。目前ApacheFlink也從流計(jì)算的引擎逐漸擁有流批一體的計(jì)算能力，可以通過日志流，點(diǎn)擊流，IoT數(shù)據(jù)流等進(jìn)行流式的分析處理，同時(shí)也可以對(duì)數(shù)據(jù)庫(kù)和文件系統(tǒng)中的文件等有限數(shù)據(jù)集進(jìn)行批式的數(shù)據(jù)處理，快速分析結(jié)果。ApacheFlink現(xiàn)在是開源社區(qū)中非常流行的一個(gè)開源大數(shù)據(jù)技術(shù)，并且連續(xù)三年成為Apache開源項(xiàng)目中全球活躍度最高的項(xiàng)目之一。它具備強(qiáng)一致性的計(jì)算能力、大規(guī)模的擴(kuò)展性，整體性能非常卓越，同時(shí)支持SQL、Java、Python等多語(yǔ)言，擁有豐富的API接口方便各種場(chǎng)景業(yè)務(wù)使用。目前國(guó)內(nèi)外互聯(lián)網(wǎng)企業(yè)中Flink已經(jīng)成為主流的實(shí)時(shí)大數(shù)據(jù)計(jì)算技術(shù)，是實(shí)時(shí)計(jì)算領(lǐng)域的事實(shí)技術(shù)標(biāo)準(zhǔn)。阿里云實(shí)時(shí)計(jì)算Flink版產(chǎn)品，在阿里巴巴集團(tuán)內(nèi)部歷經(jīng)多年錘煉和驗(yàn)證，積累了豐富的技術(shù)和產(chǎn)品，現(xiàn)已經(jīng)提供到云上，為各行各業(yè)中小企業(yè)提供云計(jì)算服務(wù)。早在2016年，ApacheFlink剛剛捐獻(xiàn)給Apache之后的第三年，阿里已經(jīng)開始大規(guī)模上線使用實(shí)時(shí)計(jì)算產(chǎn)品了。這個(gè)產(chǎn)品最早上線于阿里最核心的搜索推薦以及廣告業(yè)務(wù)場(chǎng)景，在這個(gè)場(chǎng)景下我們需要大量的數(shù)據(jù)實(shí)時(shí)化的處理，比如實(shí)時(shí)推薦、實(shí)時(shí)排序、實(shí)時(shí)廣告等，對(duì)整個(gè)電商的核心業(yè)務(wù)有非常大的提升。2017年，基于Flink的實(shí)時(shí)計(jì)算平臺(tái)產(chǎn)品，開始服務(wù)于整個(gè)阿里巴巴集團(tuán)，同年雙11服務(wù)全集團(tuán)的數(shù)據(jù)實(shí)時(shí)化，包括最核心的雙11的大屏。在2018年產(chǎn)品正式上云，不僅服務(wù)集團(tuán)內(nèi)，同時(shí)開始服務(wù)云上中小企業(yè)，這也是第一次將實(shí)時(shí)計(jì)算Flink的產(chǎn)品以公共云的形式對(duì)外提供服務(wù)。2019年初，阿里巴巴收購(gòu)了Flink的創(chuàng)始公司-Ververica，阿里的Flink技術(shù)團(tuán)隊(duì)-實(shí)時(shí)計(jì)算技術(shù)團(tuán)隊(duì)和德國(guó)總部的Flink創(chuàng)始團(tuán)隊(duì)順利會(huì)師，成為了全球Flink技術(shù)最強(qiáng)的團(tuán)隊(duì)，也共同推進(jìn)了整個(gè)ApacheFlink開源社區(qū)的發(fā)展和貢獻(xiàn)。目前中國(guó)ApacheFlink社區(qū)有超過20w的開發(fā)者參與到社區(qū)中，F(xiàn)link成為Apache基金會(huì)大數(shù)據(jù)領(lǐng)域最活躍的項(xiàng)目之一。去年，在全球主流的云計(jì)算公司和大數(shù)據(jù)公司，都大量采用Flink的技術(shù)推出了自己的Flink產(chǎn)品。比如借Hadoop起家的Cloudera也推出全面集成了Flink的CDP/CDH，國(guó)內(nèi)的大數(shù)據(jù)公司也陸續(xù)推出了基于Flink的實(shí)時(shí)計(jì)算產(chǎn)品。二、實(shí)時(shí)計(jì)算Flink版產(chǎn)品架構(gòu)阿里云的實(shí)時(shí)計(jì)算產(chǎn)品架構(gòu)和開源版本相比較，有很大的提高和增值?，F(xiàn)在很多開發(fā)者在自建機(jī)房或者云上虛擬機(jī)作業(yè)時(shí)都會(huì)使用開源的ApacheFlink去搭建自己的實(shí)時(shí)計(jì)算平臺(tái)。那么阿里云官方推出的實(shí)時(shí)計(jì)算Flink產(chǎn)品，它的特色是什么呢？根據(jù)整個(gè)產(chǎn)品的架構(gòu)圖，最底層是基于阿里云的完善的云原生的基礎(chǔ)設(shè)施，通過容器化來構(gòu)建一套實(shí)時(shí)計(jì)算Flink的產(chǎn)品，所有的Flink的計(jì)算任務(wù)都運(yùn)行在Kubernetes的生態(tài)之上，以容器化的方式進(jìn)行多租戶的隔離，保障安全。同時(shí)它又是全托管的服務(wù)形態(tài)，在云上提供高SLA保證的全托管服務(wù)，免除用戶運(yùn)維的煩惱。并搭配service架構(gòu)，用戶可以更靈活的判斷各類資源的占比，完全配合自己的業(yè)務(wù)量來選擇，無需為機(jī)器的規(guī)劃而煩惱。實(shí)時(shí)計(jì)算Flink版產(chǎn)品是一套天然的云原生基礎(chǔ)架構(gòu)。在核心計(jì)算引擎上，相對(duì)于開源的ApacheFlink阿里云進(jìn)行了多處核心功能的優(yōu)化，這些優(yōu)化也通過了阿里內(nèi)部業(yè)務(wù)的錘煉。目前實(shí)時(shí)計(jì)算Flink產(chǎn)品，支持了阿里集團(tuán)將近100個(gè)事業(yè)部的實(shí)時(shí)數(shù)據(jù)服務(wù)。通過大量業(yè)務(wù)實(shí)踐，產(chǎn)品在支持存儲(chǔ)，調(diào)度、網(wǎng)絡(luò)傳輸?shù)确矫?，都調(diào)試到最佳效果。插件方面，產(chǎn)品內(nèi)置幾十種增強(qiáng)型的Connector，可以對(duì)接所有主流的開源數(shù)據(jù)存儲(chǔ)包括云上像MySQL、HBase、HDFS、阿里云SLS等，天然集成、開箱即用。開發(fā)平臺(tái)方面，提供企業(yè)級(jí)的一站式的開發(fā)平臺(tái)，自帶開發(fā)和運(yùn)維能力，免除自建煩惱，提高企業(yè)用戶整體使用感受。實(shí)時(shí)計(jì)算Flink版支持SQL、Java、Python等多語(yǔ)言開發(fā)環(huán)境，提供開發(fā)任務(wù)的全生命周期管理，可支持基于OIDC和RBAC的企業(yè)級(jí)安全機(jī)制，并且擁有基于Prometheus協(xié)議的全鏈路監(jiān)控報(bào)警，同時(shí)提供自有AutoPilot的智能調(diào)優(yōu)系統(tǒng)，智能地幫助用戶去對(duì)Flink任務(wù)進(jìn)行參數(shù)的調(diào)優(yōu)，包括資源的調(diào)優(yōu)和并發(fā)度的調(diào)優(yōu)。產(chǎn)品完全可以去自適應(yīng)業(yè)務(wù)的流量，不需要人工做任何的調(diào)試（智能調(diào)優(yōu)是實(shí)時(shí)計(jì)算Flink版產(chǎn)品的核心優(yōu)勢(shì)）。實(shí)時(shí)計(jì)算Flink版的產(chǎn)品相對(duì)于開源產(chǎn)品，具有數(shù)10項(xiàng)的性能優(yōu)勢(shì)，通過開發(fā)、運(yùn)維、成本、安全等角度進(jìn)行對(duì)比。開發(fā)方面具備豐富的數(shù)據(jù)連接能力和一站式的多語(yǔ)言的開發(fā)環(huán)境，內(nèi)置多種函數(shù)庫(kù)，方便用戶進(jìn)行代碼調(diào)試，還可以進(jìn)行多租戶的開發(fā)，任務(wù)的調(diào)試，測(cè)試的模擬等等。運(yùn)維方面支持全鏈路的監(jiān)控報(bào)警，用戶在使用過程中出現(xiàn)的數(shù)據(jù)延遲、數(shù)據(jù)異常、服務(wù)中斷等都可以進(jìn)行自動(dòng)報(bào)警。智能運(yùn)維方面支持自動(dòng)化的智能診斷和調(diào)優(yōu)，能夠根據(jù)業(yè)務(wù)流量自動(dòng)幫用戶進(jìn)行性能調(diào)優(yōu)、作業(yè)調(diào)優(yōu)、參數(shù)調(diào)優(yōu)和資源調(diào)優(yōu)等，針對(duì)問題可以進(jìn)行診斷優(yōu)化。資源層面在開源的基礎(chǔ)上，做到了更細(xì)粒度和更精細(xì)化的資源的調(diào)配，使得每個(gè)作業(yè)每個(gè)算子都可以在CPU和內(nèi)存粒度上進(jìn)行配置，大幅優(yōu)化資源的利用率，幫助用戶節(jié)省成本，提升服務(wù)的穩(wěn)定性，降低OM的概率。搭配原廠的運(yùn)維兜底服務(wù)，SLA99.9%的保證，以及全鏈路的容錯(cuò)能力，系統(tǒng)穩(wěn)定性的保證，充分解決用戶后顧之憂。成本層面，通過云上成本優(yōu)化，在性能提升的同時(shí)降低用戶整體的TCO，這也是核心性能的優(yōu)勢(shì)?；贜exMark的流計(jì)算的標(biāo)準(zhǔn)測(cè)試中，實(shí)時(shí)計(jì)算Flink版的產(chǎn)品性能約為開源的3倍，依托阿里集團(tuán)強(qiáng)大的研發(fā)團(tuán)隊(duì)在內(nèi)部核心業(yè)務(wù)場(chǎng)景下積累的實(shí)踐優(yōu)化，使得產(chǎn)品在降低用戶的基礎(chǔ)成本上，突出核心優(yōu)勢(shì)。實(shí)時(shí)計(jì)算Flink版還具備云原生的彈性擴(kuò)容能力，可幫助用戶合理地節(jié)省資源，提高資源利用率。產(chǎn)品付費(fèi)類型支持包年包月付費(fèi)，也支持按量付費(fèi)，更好地適配不同需求。安全層面通過容器化的任務(wù)隔離，提高用戶使用感受，并且支持租戶隔離、安全隔離、VPC隔離等等多種需求。同時(shí)與阿里的賬號(hào)體系直接打通，用戶可以基于阿里云的賬號(hào)無縫進(jìn)行產(chǎn)品之間的安全管控，也支持基于角色、OIDC這種開放的身份認(rèn)證協(xié)議，大大提高業(yè)務(wù)的安全性。整體來說，企業(yè)版相對(duì)于開源版具有更優(yōu)勢(shì)的功能性和穩(wěn)定性，除了運(yùn)維方面的優(yōu)勢(shì)，開箱即用也讓用戶更加方便。四、產(chǎn)品解決方案Flink作為實(shí)時(shí)計(jì)算的一個(gè)流式計(jì)算引擎，可以處理多種實(shí)時(shí)數(shù)據(jù)，包括ECS在線服務(wù)日志，IoT場(chǎng)景下傳感器數(shù)據(jù)等各類實(shí)時(shí)數(shù)據(jù)。同時(shí)可以訂閱云上數(shù)據(jù)庫(kù)RDS、PolarDB等這種關(guān)系型數(shù)據(jù)庫(kù)中binlog的更新。再通過DataHub數(shù)據(jù)總線產(chǎn)品、SLS日志服務(wù)、開源的Kafka消息隊(duì)列產(chǎn)品等將實(shí)時(shí)數(shù)據(jù)進(jìn)行訂閱，收錄進(jìn)實(shí)時(shí)計(jì)算產(chǎn)品中，進(jìn)行實(shí)時(shí)的數(shù)據(jù)分析和處理。最終將分析結(jié)果寫入不同的數(shù)據(jù)服務(wù)中，比如MaxCompute、MaxCompute-Hologres交互式分析、PAI機(jī)器學(xué)習(xí)、Elasticsearch等產(chǎn)品中，根據(jù)業(yè)務(wù)需求選擇最佳數(shù)據(jù)服務(wù)產(chǎn)品，提高數(shù)據(jù)利用率。Flink主要的應(yīng)用場(chǎng)景就是將各種不同的實(shí)時(shí)數(shù)據(jù)源中的數(shù)據(jù)進(jìn)行實(shí)時(shí)的訂閱、處理、分析，并把得到的結(jié)果寫入到其他的在線存儲(chǔ)之中，讓用戶直接生產(chǎn)使用。整個(gè)系統(tǒng)具有速度快，數(shù)據(jù)準(zhǔn)，云原生架構(gòu)以及智能化等特點(diǎn)，是一款非常具有競(jìng)爭(zhēng)力的企業(yè)級(jí)的產(chǎn)品。產(chǎn)品運(yùn)行在阿里云的容器服務(wù)ECS等IaaS系統(tǒng)上，跟阿里云的各項(xiàng)系統(tǒng)天然打通，方便客戶適用更多場(chǎng)景。五、產(chǎn)品應(yīng)用場(chǎng)景基于實(shí)時(shí)計(jì)算Flink版產(chǎn)品總結(jié)出4大應(yīng)用場(chǎng)景，方便用戶根據(jù)需求輕松構(gòu)建自己的業(yè)務(wù)實(shí)時(shí)計(jì)算解決方案。1.實(shí)時(shí)數(shù)倉(cāng)實(shí)時(shí)數(shù)倉(cāng)主要應(yīng)用在網(wǎng)站pv/uv統(tǒng)計(jì)、商品銷量統(tǒng)計(jì)、交易數(shù)據(jù)統(tǒng)計(jì)等各類交易型數(shù)據(jù)場(chǎng)景中。通過訂閱業(yè)務(wù)實(shí)時(shí)數(shù)據(jù)源，將信息實(shí)時(shí)秒級(jí)分析，最終呈現(xiàn)在大屏幕中給決策者使用，方便判斷企業(yè)經(jīng)營(yíng)狀況和活動(dòng)促銷的情況。根據(jù)實(shí)時(shí)的商業(yè)運(yùn)營(yíng)數(shù)據(jù)作出決策，做到真正數(shù)據(jù)智能。因場(chǎng)景的特殊性，實(shí)時(shí)數(shù)據(jù)尤為重要，在瞬息萬(wàn)變的業(yè)務(wù)互動(dòng)中需要對(duì)上一分鐘甚至上一秒鐘發(fā)生的數(shù)據(jù)進(jìn)行分析決策，實(shí)時(shí)計(jì)算是這種場(chǎng)景下最好的選擇。2.實(shí)時(shí)推薦實(shí)時(shí)推薦主要是根據(jù)用戶喜好進(jìn)行個(gè)性化推薦或者基于AI技術(shù)進(jìn)行推薦，是一個(gè)主流的產(chǎn)品形態(tài)。常見于短視頻場(chǎng)景，電商購(gòu)物場(chǎng)景，內(nèi)容資訊場(chǎng)景等，通過之前的用戶點(diǎn)擊情況實(shí)時(shí)判斷用戶喜好，從而進(jìn)行針對(duì)性推薦，增加用戶粘性。這種是實(shí)時(shí)性非常強(qiáng)的場(chǎng)景，可以通過Flink技術(shù)結(jié)合AI技術(shù)進(jìn)行實(shí)時(shí)推薦場(chǎng)景的運(yùn)作。3.ETL場(chǎng)景實(shí)時(shí)的ETL場(chǎng)景常見于數(shù)據(jù)同步作業(yè)中，在數(shù)據(jù)同步的過程中還要做數(shù)據(jù)計(jì)算處理。比如數(shù)據(jù)庫(kù)中不同表的同步、轉(zhuǎn)化、不同數(shù)據(jù)庫(kù)的同步，或者是進(jìn)行數(shù)據(jù)聚合預(yù)處理等操作。最終將結(jié)果寫入數(shù)倉(cāng)/數(shù)據(jù)湖進(jìn)行歸檔沉淀，為后續(xù)深度分析進(jìn)行前期準(zhǔn)備工作，方便用戶進(jìn)行后續(xù)的日志類分析等操作。在整個(gè)的數(shù)據(jù)同步和處理鏈路上，基于Flink做這種實(shí)時(shí)化數(shù)據(jù)的同步和預(yù)處理是非常高效的。4.實(shí)時(shí)監(jiān)控實(shí)時(shí)監(jiān)控常見于金融類或者是交易類業(yè)務(wù)場(chǎng)景下，針對(duì)行業(yè)的獨(dú)特性，需要有商業(yè)化的反作弊監(jiān)管，根據(jù)實(shí)時(shí)短時(shí)間之內(nèi)的行為，判定用戶是否為作弊用戶，做到及時(shí)止損。該場(chǎng)景對(duì)時(shí)效性要求極高，通過對(duì)異常數(shù)據(jù)檢測(cè)，可以實(shí)時(shí)發(fā)現(xiàn)異常情況而做出一個(gè)止損的行為。收集指標(biāo)或者日志等統(tǒng)計(jì)各個(gè)系統(tǒng)的指標(biāo)，對(duì)指標(biāo)進(jìn)行實(shí)時(shí)的觀察和監(jiān)控等等需求場(chǎng)景，都是可以通過實(shí)時(shí)計(jì)算Flink產(chǎn)品解決的。產(chǎn)品官網(wǎng)：/product/bigdata/scHologres總體架構(gòu)一、典型業(yè)務(wù)場(chǎng)景列舉提到實(shí)時(shí)數(shù)倉(cāng)，我們可以看一下數(shù)據(jù)業(yè)務(wù)典型的應(yīng)用場(chǎng)景。如上圖所示，第一類場(chǎng)景是實(shí)時(shí)大屏。如今一般來說，不管是做toC還是toB的業(yè)務(wù)，或者說給上司看，都喜歡做一個(gè)業(yè)務(wù)大盤，來展現(xiàn)整個(gè)業(yè)務(wù)的運(yùn)行情況。第二類場(chǎng)景是BI報(bào)表，這類業(yè)務(wù)是從傳統(tǒng)的離線BI報(bào)表產(chǎn)生的，只不過隨著實(shí)時(shí)數(shù)據(jù)、實(shí)時(shí)業(yè)務(wù)的需求越來越旺盛，所以實(shí)時(shí)BI報(bào)表的需求也越來越多。第三類場(chǎng)景是用戶畫像，不管是做金融還是做推薦，都是做千人千面，希望能夠通過歷史數(shù)據(jù)、用戶行為數(shù)據(jù)得到用戶的興趣，來給用戶提供更好的服務(wù)。第四類場(chǎng)景是預(yù)警監(jiān)控，或者說是流量監(jiān)控。不管是做APP的還是做服務(wù)器端的監(jiān)控，最終都是把數(shù)據(jù)收集上來，以這樣大盤的形式進(jìn)行展現(xiàn)。最終可以在這些預(yù)警指標(biāo)進(jìn)行報(bào)警，來保證監(jiān)控業(yè)務(wù)的穩(wěn)定性。數(shù)據(jù)業(yè)務(wù)無論是離線還是實(shí)時(shí)，大致可以分為以上這么四類。二、傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)處理流程接下來我們看一下傳統(tǒng)離線數(shù)倉(cāng)是怎么樣的一個(gè)處理流程。上方是一個(gè)典型的傳統(tǒng)離線數(shù)倉(cāng)的數(shù)據(jù)處理鏈路。首先，從業(yè)務(wù)系統(tǒng)CRM、ERP或者其他數(shù)據(jù)源把這些業(yè)務(wù)數(shù)據(jù)收集上來，然后經(jīng)過離線數(shù)倉(cāng)的ETL，然后對(duì)數(shù)據(jù)的話進(jìn)行數(shù)據(jù)清洗、數(shù)據(jù)加工。在這個(gè)過程中涉及數(shù)據(jù)建模、數(shù)據(jù)分層，最終會(huì)把加工后的數(shù)據(jù)，或者是最終要產(chǎn)生BI報(bào)表的數(shù)據(jù)，通過BI工具或者寫到數(shù)據(jù)庫(kù)里面，推到一個(gè)在線系統(tǒng)里面去，最后提供給用戶進(jìn)行訪問，這些用戶可能包括產(chǎn)品的用戶、運(yùn)營(yíng)同學(xué)或老板。用戶希望能夠從這樣的數(shù)據(jù)里面看到，比如整個(gè)產(chǎn)品的售賣情況，或者業(yè)績(jī)的增長(zhǎng)趨勢(shì)，系統(tǒng)的一些指標(biāo)等，這就是一個(gè)比較典型的離線數(shù)倉(cāng)的處理流程。批量數(shù)據(jù)分析流程有以下幾個(gè)特點(diǎn)：O多種數(shù)據(jù)源接入l定時(shí)數(shù)據(jù)開發(fā)與應(yīng)用O數(shù)據(jù)提取/數(shù)據(jù)轉(zhuǎn)換/數(shù)據(jù)加載ODS數(shù)據(jù)處理O數(shù)據(jù)集市應(yīng)用l核心痛點(diǎn)OETL計(jì)算/存儲(chǔ)/時(shí)間成本過高O數(shù)據(jù)處理鏈路過長(zhǎng)O無法支持實(shí)時(shí)/近實(shí)時(shí)數(shù)據(jù)分析為了解決傳統(tǒng)數(shù)倉(cāng)的問題，出現(xiàn)了一些新的解決思路。首先在2011年之后興起了Lambda架構(gòu)，如上圖所示。Lambda的大致思路還是以傳統(tǒng)的離線數(shù)倉(cāng)為主，然后引入了實(shí)時(shí)數(shù)據(jù)的處理鏈路。T+1數(shù)據(jù)還是走傳統(tǒng)離線數(shù)倉(cāng)鏈路，然后再加上一個(gè)實(shí)時(shí)的數(shù)據(jù)鏈路，再把這些實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)匯總到一起，然后再通過一個(gè)Merge層提供數(shù)據(jù)服務(wù)，對(duì)外提供的服務(wù)可能是點(diǎn)查詢，也可能是做復(fù)雜分析，還有可能是做聯(lián)邦查詢。然后在這上面去加數(shù)據(jù)應(yīng)用，比如上文提到的BI報(bào)表，實(shí)時(shí)大屏，用戶畫像等。從架構(gòu)的名稱Lambda就能夠看出來，其實(shí)它是在傳統(tǒng)離線數(shù)倉(cāng)基礎(chǔ)上加了實(shí)時(shí)，解決傳統(tǒng)離線數(shù)倉(cāng)的問題。但其實(shí)整個(gè)Lambda架構(gòu)也有一些問題，主要存在的問題是架構(gòu)復(fù)雜、數(shù)據(jù)同步難、資源消耗大、數(shù)據(jù)孤島、人才培養(yǎng)難、開發(fā)成本高、不敏捷。比如，Lambda架構(gòu)并沒有從源頭上解決傳統(tǒng)離線數(shù)倉(cāng)的問題，而是在傳統(tǒng)離線數(shù)倉(cāng)上加了一條鏈路，這會(huì)讓整個(gè)系統(tǒng)變得更加復(fù)雜。在架構(gòu)復(fù)雜的基礎(chǔ)上，數(shù)據(jù)可能會(huì)存兩份或者存多份，實(shí)時(shí)鏈路和離線鏈路數(shù)據(jù)不統(tǒng)一。除此之外，整個(gè)架構(gòu)維護(hù)起來也是非常復(fù)雜的，并且開發(fā)成本比較高。比如說離線鏈路用Spark或者Hive，實(shí)時(shí)用Flink，但其實(shí)這些SQL是不太一樣的。還有元數(shù)據(jù)如何管理，數(shù)據(jù)如何治理，再加上提供服務(wù)的時(shí)候，Merge層可以用HBase、Redis這樣的系統(tǒng)去做，這些API其實(shí)都是非常復(fù)雜的。對(duì)一個(gè)小企業(yè)，做這種數(shù)據(jù)開發(fā)或者說做這種數(shù)據(jù)平臺(tái)，資源是有限的，學(xué)習(xí)成本非常高的。經(jīng)常發(fā)生的情況是，小公司剛把一批同學(xué)培養(yǎng)起來能夠熟悉這些系統(tǒng)，然后就被其他公司挖走了，因此人才成本也非常高。阿里巴巴的整個(gè)數(shù)據(jù)業(yè)務(wù)也是沿著這條路走過來的，我們思考有沒有什么方法來簡(jiǎn)化這個(gè)架構(gòu)，下面來看一下。首先一個(gè)簡(jiǎn)單的思路，就是能不能把離線數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)進(jìn)行統(tǒng)一。我們首先做的事情是實(shí)時(shí)/離線一體化，把實(shí)時(shí)ETL和離線ETL進(jìn)行統(tǒng)一，整個(gè)數(shù)據(jù)模型進(jìn)行統(tǒng)一。在實(shí)時(shí)/離線一體化的基礎(chǔ)上，分析部分是偏離線的，服務(wù)部分是偏在線的，我們思考能否把這兩部分也做一個(gè)統(tǒng)一，讓一份數(shù)據(jù)既服務(wù)于離線又服務(wù)于在線。我們把這樣的架構(gòu)叫做分析服務(wù)一體化，分析相當(dāng)于離線分析，服務(wù)是提供在線服務(wù)。如果真能做到一體化的話，相當(dāng)于是由傳統(tǒng)的OLAP變成了分析服務(wù)一體化架構(gòu)。思路有了，接下來我們看一下怎么去做這個(gè)事情。四、阿里業(yè)務(wù)場(chǎng)景原架構(gòu)阿里巴巴原來的業(yè)務(wù)也是由傳統(tǒng)Lambda架構(gòu)走過來的，下面介紹阿里巴巴一個(gè)業(yè)務(wù)場(chǎng)景：搜索推薦場(chǎng)景。如上圖所示，最早的時(shí)候這個(gè)架構(gòu)就是為了解決實(shí)時(shí)推薦。大家都清楚阿里巴巴最主要的是電商業(yè)務(wù)，電商業(yè)務(wù)以淘寶為核心，打開淘寶會(huì)給用戶推薦很多內(nèi)容，其實(shí)這些推薦的內(nèi)容都是一些行為事件，包括在滾屏看到的那些內(nèi)容都是一條條事件。這些事件會(huì)實(shí)時(shí)寫到后臺(tái)服務(wù)里面，然后經(jīng)過Flink做實(shí)時(shí)ETL，做實(shí)時(shí)的模型訓(xùn)練，或者做數(shù)據(jù)采樣，會(huì)把這些數(shù)據(jù)寫到HBase或Cassandra里面。通過在HBase里面做實(shí)時(shí)的模型訓(xùn)練，再把這些模型推到搜索引擎或者在線服務(wù)里面，這樣的話就能夠完成實(shí)時(shí)推薦的鏈路閉環(huán)，能夠提供點(diǎn)查詢的數(shù)據(jù)服務(wù)。那么我們想對(duì)已經(jīng)存在的數(shù)據(jù)樣本或者數(shù)據(jù)特征進(jìn)行分析怎么辦？我們引入列式查詢的產(chǎn)品，比如ClickHouse或者Druid做分析，然后去接一些報(bào)表。如果還需要做數(shù)據(jù)的離線歸檔怎么辦？可以通過MaxCompute或者Hive去做離線歸檔。有了實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)，那么就要去做離線/實(shí)時(shí)的聯(lián)邦分析，又引入Drill和Presto。我們都清楚，像Drill和Presto這樣的系統(tǒng)的話，它整個(gè)的性能或者QPS承載的并發(fā)非常差的，如果想提高并發(fā)怎么辦？我們引入了Redis和MySQL去做這樣的一個(gè)Cache，然后通過非常短周期的調(diào)度，從Drill和Presto去做查詢，再把結(jié)果寫到Redis或MySQL里面去，然后整個(gè)數(shù)據(jù)去對(duì)接API服務(wù)或者對(duì)接報(bào)表等。上方就是阿里巴巴搜索推薦場(chǎng)景原來的業(yè)務(wù)架構(gòu)，是一個(gè)典型的Lambda架構(gòu)。絕大部分公司從業(yè)務(wù)出發(fā)的話，也是這么一個(gè)架構(gòu)。五、下一代實(shí)時(shí)數(shù)倉(cāng)如何選型按照上文的思路，如果我們想去簡(jiǎn)化這樣的架構(gòu)，把實(shí)時(shí)/離線一體化，再把分析服務(wù)一體化，我們需要一個(gè)新的實(shí)時(shí)數(shù)倉(cāng)，應(yīng)該怎么去做，考慮哪些問題？首先，必須支持實(shí)時(shí)寫入，傳統(tǒng)離線T+1肯定是不可以的。除此之外，能夠支持非常實(shí)時(shí)的計(jì)算。第二是能夠把實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)存放在一起，做到實(shí)時(shí)/離線數(shù)據(jù)一體化，減少數(shù)據(jù)的移動(dòng)。第三是希望平臺(tái)跟上層的業(yè)務(wù)能夠解耦，意味著平臺(tái)必須具備一定的通用性，而不是一個(gè)定制的產(chǎn)品。第四是對(duì)于上層業(yè)務(wù)使用的API，我們希望能夠擁抱開源生態(tài)，并且希望整個(gè)系統(tǒng)或者產(chǎn)品是一種云原生的架構(gòu)，便于云上用戶使用。為了解決上述問題，我們從已有的一些開源產(chǎn)品里面找找靈感，看看它們現(xiàn)在是怎么去做的，每個(gè)產(chǎn)品解決哪些問題。如上所示，首先一大類是數(shù)據(jù)庫(kù)產(chǎn)品，如MySQL、PostgreSQL等，它們比較典型的是支持事務(wù)，事務(wù)最重要的是支持ACID，做到讀寫一致性，保證數(shù)據(jù)的一致性。但是它們有個(gè)缺點(diǎn)，就是Scalability往往很難做到PB級(jí)別，同時(shí)不能做非常復(fù)雜的Query分析。第二類是現(xiàn)在面向于分析加速或者OLAP這樣的系統(tǒng)，比較典型有Presto，ClickHouse，Hive等，這類的特點(diǎn)是大規(guī)模數(shù)據(jù)掃描、過濾、匯總，語(yǔ)義層，分布式，列式存儲(chǔ)，面向分析師。第三類是Serving場(chǎng)景，提供高并發(fā)，支持簡(jiǎn)單快速的查詢，比如Cassandra、HBase、Redis等，能夠提供非常高的性能。目前有一種趨勢(shì)是很多產(chǎn)品在做HTAP，就是把Transaction和Analytics融合，相當(dāng)于在一個(gè)產(chǎn)品里滿足這兩部分能力，目前有很多產(chǎn)品在一定程度上都能做到，其中有一些隔離性或者數(shù)據(jù)一致性的問題，但是基本是可解的。這類場(chǎng)景的話往往是Transaction，以TP為主業(yè)務(wù)基礎(chǔ)，然后在TP數(shù)據(jù)的基礎(chǔ)上做一定的分析。針對(duì)這種場(chǎng)景，我們對(duì)讀寫一致性沒有很高的要求，只要做到最終一致性就好了，更多的是要求能夠支持非常高并發(fā)的查詢和分析。把這兩類場(chǎng)景結(jié)合到一起的話，我們叫做HybridServing/Analytics目前在市場(chǎng)上并沒有這樣一類產(chǎn)品，我們希望做出這樣的產(chǎn)品來解決分析服務(wù)一體化。有了架構(gòu)理念，下面我們看一下如何實(shí)現(xiàn)。六、新一代技術(shù)理念HSAP：分析、服務(wù)一體化我們首先想到是做統(tǒng)一存儲(chǔ)，把離線數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)放到一起做規(guī)劃處理，然后對(duì)統(tǒng)一存儲(chǔ)的數(shù)據(jù)提供統(tǒng)一的數(shù)據(jù)服務(wù)，上層的數(shù)據(jù)應(yīng)用如數(shù)據(jù)報(bào)告、數(shù)據(jù)看板、在線應(yīng)用等，都直接通過在線的數(shù)據(jù)服務(wù)，提供統(tǒng)一查詢出口，就可以解決上文的問題。有了這樣的思路后，我們研發(fā)了一個(gè)產(chǎn)品——Hologres。簡(jiǎn)單介紹一下Hologres這個(gè)產(chǎn)品的名字是怎么來的，它是由兩個(gè)單詞拼成的，一個(gè)是Postgres代表的PostgreSQL生態(tài)，Hologra我們知道，黑洞連光都能夠吸進(jìn)去，但是我們?cè)诘厍蛏喜]有被黑洞吸進(jìn)去，是因?yàn)槲覀冸x這個(gè)黑洞足夠遠(yuǎn)，這是否就意味著有這一個(gè)臨界點(diǎn)，這個(gè)臨界點(diǎn)之內(nèi)的都會(huì)被黑洞吸進(jìn)去，臨界點(diǎn)之外的能夠逃出黑洞引力。由這個(gè)臨界點(diǎn)組成的一個(gè)面，被證明是個(gè)球面，我們把它叫做世界面。有科學(xué)家證明黑洞里面的所有信息在世界面上都有投影，意味世界面上包含黑洞的全部信息，也就我們經(jīng)常提到的3D全息投影技術(shù)，全息的英文單詞就是Holographic。Hologres想做的事情是通過產(chǎn)品對(duì)數(shù)據(jù)黑洞做全息展示，全部信息在Hologre能夠提供服務(wù)的能力，并且數(shù)據(jù)存在Hologres的數(shù)據(jù)黑洞里面。上圖為使用Hologres前后的架構(gòu)對(duì)比圖，使用了Hologres之后整個(gè)架構(gòu)就變得非常簡(jiǎn)單了。首先，F(xiàn)link實(shí)時(shí)寫入到Hologres里面，也可以通過Hologres做維表關(guān)聯(lián)。同時(shí)，通過實(shí)時(shí)數(shù)據(jù)可以歸檔到MaxCompute里面。這樣的架構(gòu)對(duì)于數(shù)據(jù)服務(wù)來說非常簡(jiǎn)單，離線分析走M(jìn)axCompute，數(shù)據(jù)的點(diǎn)查詢、離線加速、聯(lián)邦分析或交互式分析等可以走整個(gè)阿里巴巴的業(yè)務(wù)架構(gòu)由左邊演變成右邊，帶來的收益是業(yè)務(wù)敏捷響應(yīng)，數(shù)據(jù)自助分析，避免數(shù)據(jù)割裂，賦能數(shù)據(jù)服務(wù)，簡(jiǎn)化運(yùn)維管理。下面我們來簡(jiǎn)單看一下Hologres到底是個(gè)什么樣的產(chǎn)品。Hologres基于HSAP理念，云原生分布式分析引擎，支持對(duì)PB級(jí)數(shù)據(jù)進(jìn)行高并發(fā)、低延時(shí)的分析，支持實(shí)時(shí)數(shù)倉(cāng)，大數(shù)據(jù)交互式分析等場(chǎng)景。Hologres的特點(diǎn)是提供分析服務(wù)一體化，如點(diǎn)查詢景，類HBase、Redis場(chǎng)景。OLAP場(chǎng)景能夠提供PB級(jí)別復(fù)雜查詢，毫秒級(jí)交互式分析。Hologres以實(shí)時(shí)為中心設(shè)計(jì)理念，查詢快，實(shí)時(shí)數(shù)據(jù)寫入快，并且能夠支持實(shí)時(shí)數(shù)據(jù)、離線數(shù)據(jù)的快速導(dǎo)入。整個(gè)架構(gòu)是存儲(chǔ)計(jì)算分離的架構(gòu)，在云上面跟MaxCompute無縫打通，并且從Hologres這個(gè)名字就能看出來，Hologres兼容PG語(yǔ)法如上圖所示，Hologres是典型的存儲(chǔ)計(jì)算分離架構(gòu)，整個(gè)數(shù)據(jù)是在一個(gè)共享存儲(chǔ)里面，這個(gè)共享存儲(chǔ)可以是阿里云內(nèi)部的存儲(chǔ)產(chǎn)品盤古，也可以是數(shù)據(jù)湖的產(chǎn)品，比如OSS、計(jì)算節(jié)點(diǎn)都是在容器里面，提供一個(gè)Worker，還有一個(gè)角色是Frontend，相當(dāng)于是能夠接收用戶的SQL。接收完SQL以后進(jìn)行SQL解析生成AST，然后通過優(yōu)化器把AST轉(zhuǎn)化成分布式的執(zhí)行計(jì)劃，通過Coordinator發(fā)給這些Worker去做，每個(gè)Worker里面有自己的調(diào)度系統(tǒng)，有數(shù)據(jù)的分片管理，同時(shí)還有Cache，然后能夠分步式執(zhí)行。整個(gè)計(jì)算節(jié)點(diǎn)是MPP架構(gòu)，然后是存儲(chǔ)計(jì)算分離的。八、存儲(chǔ)計(jì)算分離下面我們看一下存儲(chǔ)計(jì)算分離能帶來的好處。一般來說，現(xiàn)在的大數(shù)據(jù)產(chǎn)品或者數(shù)據(jù)庫(kù)產(chǎn)品，存儲(chǔ)計(jì)算就幾種關(guān)系。第一類是傳統(tǒng)Oracle的RAC，它們是SharedDisk/Storage的架構(gòu)，相當(dāng)于有單獨(dú)的計(jì)算節(jié)點(diǎn)，每個(gè)計(jì)算節(jié)點(diǎn)有自己的本地盤，有自己的內(nèi)存，然后還有一個(gè)存儲(chǔ)集群。存儲(chǔ)集群相當(dāng)于是一個(gè)管理的磁盤陣列，這些盤對(duì)這些節(jié)點(diǎn)都是開放的，這些節(jié)點(diǎn)能夠直接訪問存儲(chǔ)的數(shù)據(jù)。第二類架構(gòu)是SharedNothing，開源系統(tǒng)用得比較多的像Clickhouse或者Druid，特點(diǎn)是存儲(chǔ)節(jié)點(diǎn)不共享。存儲(chǔ)節(jié)點(diǎn)和計(jì)算節(jié)點(diǎn)綁定，相當(dāng)于每個(gè)計(jì)算節(jié)點(diǎn)有自己的一塊存儲(chǔ)。如果其他的計(jì)算節(jié)點(diǎn)想讀另外節(jié)點(diǎn)的存儲(chǔ)，必須通過網(wǎng)絡(luò)請(qǐng)求到計(jì)算節(jié)點(diǎn)，然后通過計(jì)算節(jié)點(diǎn)再把這個(gè)數(shù)據(jù)給另外的節(jié)點(diǎn)。這個(gè)架構(gòu)帶來的問題是很容易產(chǎn)生數(shù)據(jù)熱點(diǎn)，比如Node2，假如它數(shù)據(jù)特別多，這個(gè)數(shù)據(jù)也沒辦法存到其他節(jié)點(diǎn)上，這樣的架構(gòu)往往會(huì)使整個(gè)Scalability受限。第三類是云原生這種完全存儲(chǔ)計(jì)算分離的架構(gòu)，計(jì)算節(jié)點(diǎn)部署在容器里面或者是單獨(dú)的服務(wù)器ECS，存儲(chǔ)是以共享的存儲(chǔ)服務(wù)或者DFS的方式進(jìn)行訪問。整個(gè)架構(gòu)非常清晰，對(duì)于計(jì)算節(jié)點(diǎn)來說，看到的就是一個(gè)非常大的分布式文件系統(tǒng)，計(jì)算節(jié)點(diǎn)只需要關(guān)心到底要訪問哪個(gè)文件，而不需要知道這個(gè)文件到底在哪存的，容錯(cuò)怎么去做。Hologres就是采用這樣的計(jì)算存儲(chǔ)分離架構(gòu)，架構(gòu)帶來的好處是可以按需購(gòu)買，在云上面需要多少計(jì)算就買多少計(jì)算資源，需要多少存儲(chǔ)就買多少存儲(chǔ)資源。九、流批統(tǒng)一的存儲(chǔ)有了分析服務(wù)一體化的架構(gòu)，就能把流計(jì)算和批計(jì)算的結(jié)果進(jìn)行統(tǒng)一。以前流計(jì)算產(chǎn)生的結(jié)果寫到流計(jì)算存儲(chǔ)，離線計(jì)算的結(jié)果寫到離線計(jì)算存儲(chǔ)，引入Hologres以后，相當(dāng)于不管是離線計(jì)算還是流計(jì)算，都寫到Hologres里面來，數(shù)據(jù)的一致性能夠得以保證。Hologres支持點(diǎn)查詢、分析型查詢，主要是因?yàn)镠ologres的存儲(chǔ)引擎支持兩種文件格式，一種是行存，一種列存。顧名思義，行存就是同一行數(shù)據(jù)的多個(gè)列是連續(xù)存放在一起的。如圖所示，列存就是相同列存放在一起，帶來的好處就是在分析的時(shí)候能夠提高Cache命中率，并且可以用向量計(jì)算做一些加速查詢。整個(gè)Hologres存儲(chǔ)引擎的架構(gòu)是類似于LSM-tree架構(gòu)，數(shù)據(jù)先寫MemTable，寫滿以后Flush成文件，小文件太多的話合并成大文件然后做管理。Hologres的宗旨是做分析服務(wù)一體化的實(shí)時(shí)數(shù)倉(cāng)，簡(jiǎn)單總結(jié)有以下三方面的特點(diǎn)：l云原生：存儲(chǔ)計(jì)算分離架構(gòu)O計(jì)算存儲(chǔ)資源彈性擴(kuò)展，按需使用；O低成本、高可用、高可靠；l統(tǒng)一存儲(chǔ)：流批統(tǒng)一的存儲(chǔ)O行列共存，列存對(duì)分析友好，行存對(duì)點(diǎn)查快速；O高效數(shù)據(jù)分片、分段、壓縮、索引；LSM-like寫友好數(shù)據(jù)結(jié)構(gòu)，高吞吐數(shù)據(jù)寫入，支持更新，寫入即可見。O向量化、全異步等執(zhí)行引擎優(yōu)化；O輕量級(jí)用戶態(tài)線程調(diào)度，同時(shí)支持多種查詢負(fù)載（高并發(fā)、復(fù)雜統(tǒng)計(jì)）；O公平調(diào)度算法（CFS高并發(fā)充分利用計(jì)算資源。十一、交互式分析典型應(yīng)用場(chǎng)景由于Hologres架構(gòu)非常簡(jiǎn)單，因此典型的應(yīng)用場(chǎng)景也就非常簡(jiǎn)單，大致可以分為以下三類。第一類是替代傳統(tǒng)的離線數(shù)據(jù)做加速查詢，可以把傳統(tǒng)的離線數(shù)據(jù)導(dǎo)到Hologres里面來，這樣的話就能夠變得很快。第二類是做實(shí)時(shí)數(shù)倉(cāng)，跟Flink進(jìn)行配合，把實(shí)時(shí)的ETL實(shí)時(shí)數(shù)據(jù)加工寫到Hologres里面，然后在Hologres做實(shí)時(shí)的數(shù)據(jù)分析。第三類是把實(shí)時(shí)離線一體化，能夠把實(shí)時(shí)/離線數(shù)據(jù)都寫到Hologres，甚至可以通Hologres做聯(lián)邦查詢，直接對(duì)其他系統(tǒng)的數(shù)據(jù)進(jìn)行查詢。下面舉幾個(gè)業(yè)務(wù)場(chǎng)景的例子。業(yè)務(wù)場(chǎng)景-阿里客戶體驗(yàn)系統(tǒng)(CCO)實(shí)時(shí)數(shù)倉(cāng)改造2020雙十一活動(dòng)期間，實(shí)時(shí)計(jì)算Flink版+Hologres為阿里客戶體驗(yàn)系統(tǒng)(CCO)構(gòu)建了集實(shí)時(shí)化、自動(dòng)化、系統(tǒng)化于一體的用戶體驗(yàn)實(shí)時(shí)數(shù)倉(cāng)。以前的阿里客戶體驗(yàn)系統(tǒng)(CCO)也是典型的Lambda架構(gòu)，存儲(chǔ)層有MySQL，HBase架構(gòu)升級(jí)主要有以下幾個(gè)業(yè)務(wù)難點(diǎn)：l數(shù)據(jù)復(fù)雜度高，加購(gòu)、下單、支付、售后全渠道，90%實(shí)時(shí)數(shù)據(jù)；l數(shù)據(jù)量大，日志（千萬(wàn)/秒)，交易（百萬(wàn)/秒)l場(chǎng)景豐富，實(shí)時(shí)監(jiān)控大屏，實(shí)時(shí)交互式分析數(shù)據(jù)產(chǎn)品，ToC線上應(yīng)用。升級(jí)后的架構(gòu)如下所示。技術(shù)架構(gòu):帶來收益:l整體硬件資源成本下降30+%；l高吞吐實(shí)時(shí)寫入：支持了行存千萬(wàn)/秒，列存幾十萬(wàn)/秒寫入要求；l簡(jiǎn)化實(shí)時(shí)鏈路：面向公共層的開發(fā)和復(fù)用；l統(tǒng)一服務(wù)：同時(shí)支撐了多維分析和高QPS服務(wù)化查詢場(chǎng)景；l支撐200+實(shí)時(shí)數(shù)據(jù)大屏搭建，為近300+小二提供穩(wěn)定的數(shù)據(jù)查詢服務(wù)。業(yè)務(wù)場(chǎng)景-菜鳥：智能物流菜鳥智能物流分析引擎是基于搜索架構(gòu)建設(shè)的物流查詢平臺(tái)，日均處理包裹事件幾十億，承載了菜鳥物流數(shù)據(jù)的大部分處理任務(wù)。需求訴求：lHBase的架構(gòu)下維表數(shù)據(jù)導(dǎo)入耗時(shí)長(zhǎng)、資源浪費(fèi)嚴(yán)重、成本高；lHBase不能同時(shí)滿足PointQuery和OLAP分析，數(shù)據(jù)導(dǎo)入導(dǎo)出引發(fā)數(shù)據(jù)孤島、數(shù)據(jù)同步負(fù)擔(dān)、冗余存儲(chǔ)、運(yùn)維成本和數(shù)據(jù)不一致等問題。升級(jí)架構(gòu)后的客戶收益：l整體硬件資源成本下降60%+；l更快的全鏈路處理速度（2億記錄端到端3分鐘）；l一個(gè)系統(tǒng)，滿KV和OLAP兩個(gè)場(chǎng)景，沒有數(shù)據(jù)冗余；l解決大維表實(shí)時(shí)SQL查詢需求；l強(qiáng)Schema，有效避免潛在錯(cuò)誤，節(jié)省時(shí)間。開發(fā)者提供基本報(bào)表統(tǒng)計(jì)及自定義用戶行為分析服務(wù)，支持精細(xì)化運(yùn)營(yíng)。業(yè)務(wù)痛點(diǎn)：l業(yè)務(wù)數(shù)據(jù)量大，年新增行為數(shù)據(jù)10PB級(jí)，個(gè)性化、自定義地交互式用戶行為分析強(qiáng)需求；l基于MaxCompute提供異步離線的adhoc分析和優(yōu)化、以及自研引擎開發(fā)嘗試均無法滿足業(yè)務(wù)需求；l導(dǎo)出到MySQL/Hbase方案的二次開發(fā)和數(shù)據(jù)導(dǎo)出鏈路長(zhǎng)、成本高、操作不靈活?？蛻羰找妫簂PB級(jí)數(shù)據(jù)毫秒級(jí)查詢響應(yīng)；同時(shí)也可以實(shí)現(xiàn)冷熱數(shù)據(jù)混合查詢，有利于成本性能平衡；l計(jì)算資源彈性伸縮，可兼顧擴(kuò)展性、穩(wěn)定性、性能、成本。實(shí)時(shí)推薦（特征查詢、實(shí)時(shí)指標(biāo)計(jì)算、向量檢索召回提高廣告留存率，實(shí)時(shí)計(jì)客戶收益：l支持2000萬(wàn)日活用戶快速向量檢索，千萬(wàn)級(jí)u2u,i2i均可以20ms返回；l通過SQL描述業(yè)務(wù)邏輯，無需手工編碼(selecta,b,proxima_distance(c)asdistancl加工邏輯簡(jiǎn)化，無需額外集群（Redis）。構(gòu)解析一、實(shí)時(shí)推薦系統(tǒng)原理在介紹實(shí)時(shí)推薦系統(tǒng)之前，先看一下靜態(tài)推薦系統(tǒng)是什么樣子的。上方是一個(gè)非常經(jīng)典的靜態(tài)推薦系統(tǒng)的架構(gòu)圖。前端會(huì)有很多用戶端的應(yīng)用，這些用戶會(huì)產(chǎn)生大量用戶的行為日志，然后放到一個(gè)消息隊(duì)列里面，進(jìn)入ETL。接著通過離線系統(tǒng)去做一些特征生成和模型訓(xùn)練，最后把模型和特征推到線上系統(tǒng)中，通過在線的服務(wù)就可以去調(diào)用在線推理服務(wù)去獲得推薦結(jié)果。這就是一個(gè)非常經(jīng)典的靜態(tài)推薦系統(tǒng)運(yùn)作流程，下面我們舉一個(gè)具體的例子來看靜態(tài)推薦系統(tǒng)到底是怎么樣工作的。如上圖所示，比如在線用戶的行為日志可能是一些用戶的瀏覽和廣告點(diǎn)擊的日志，推薦系統(tǒng)的目的是為了幫用戶推薦廣告，那么在日志里面可以看到以下用戶行為：用戶1和用戶2都看了PageID200和一些其他的頁(yè)面，然后用戶1看了PageID200并且點(diǎn)了廣告2002，那么在用戶日志里面通過ETL可以把這樣的一系列行為給歸納出來，然后送到模型訓(xùn)練里面去訓(xùn)練模型。在訓(xùn)練模型的過程當(dāng)中我們會(huì)用到一些特征，在這個(gè)情況下我們可以發(fā)現(xiàn)用戶1和用戶2都是中國(guó)的男性用戶，這可能是用戶維度的一個(gè)特征。在這種情況下，我們從日志里面看到的結(jié)果是用戶在看了PageID100后點(diǎn)了廣告2002，并且兩個(gè)用戶都是中國(guó)的男性用戶。因此，我們的模型就有可能學(xué)到當(dāng)中國(guó)的男性用戶來看PageID100的時(shí)候，應(yīng)該要給他展示廣告2002，這個(gè)行為會(huì)被訓(xùn)練到模型里面去。這個(gè)時(shí)候我們會(huì)把一些用戶的離線特征都推到特征庫(kù)，然后把這個(gè)模型也推到線上去。假設(shè)這里有一個(gè)用戶ID4，他正好是中國(guó)的男性用戶，這個(gè)特征就會(huì)被推進(jìn)特征庫(kù)，那模型也被推到線上。如果用戶4來訪問的時(shí)候看PageID100，推理服務(wù)會(huì)先去看用戶ID4的特征，然后根據(jù)他是一個(gè)中國(guó)的男性用戶，通過訓(xùn)練的模型，系統(tǒng)就會(huì)給他推廣告2002，這是一個(gè)靜態(tài)推薦系統(tǒng)基本的工作原理。在這種情況下，如果發(fā)生一些變化的時(shí)候，我們來看一下靜態(tài)推薦系統(tǒng)是不是能夠繼續(xù)很好地工作？假使說今天訓(xùn)練了用戶1和用戶2的特征模型，到第二天發(fā)現(xiàn)用戶4產(chǎn)生了行為，根據(jù)模型里面的內(nèi)容，模型會(huì)認(rèn)為用戶4是中國(guó)的男性用戶和用戶1、用戶2行為一致，所以需要給他推的應(yīng)該是中國(guó)男性用戶的行為。但這個(gè)時(shí)候我們發(fā)現(xiàn)用戶4的行為其實(shí)跟用戶3更像，而不是跟用戶1和用戶2更像。在這種情況下，由于模型和特征都是靜態(tài)的，所以為了讓用戶4能夠跟用戶3得到的行為更像，需要去重新訓(xùn)練模型，這會(huì)導(dǎo)致預(yù)測(cè)的效果被延遲，因?yàn)樾枰匦掠?xùn)練用戶4，才能夠推薦出跟用戶3更像的一些行為。所以在這種實(shí)際操作情況下，可以看到靜態(tài)推薦模型存在一些問題：l靜態(tài)生成模型和特征；l以分類模型為例，根據(jù)用戶的相似性進(jìn)行用戶分類，假設(shè)同類用戶有相似的興趣和行O例如中國(guó)的男性用戶有類似行為。O一旦用戶被劃分為某個(gè)類別，則他將一直處于這個(gè)類別中，直到被新的模型訓(xùn)練重新分類。這種情況下，比較難去做到很好的推薦，原因是：l用戶的行為非常多元化，無法劃分到某個(gè)固定類別。O上午為父母采購(gòu)保健品，中午為出差訂酒店，晚上給家人買衣服…O靜態(tài)系統(tǒng)無法準(zhǔn)確將用戶放到當(dāng)時(shí)當(dāng)刻正確的類別中。l某一類別用戶的行為相似，但是行為本身可能會(huì)發(fā)生變化。O假設(shè)用戶“隨大流“，但是“大流”可能發(fā)生變化；O歷史數(shù)據(jù)看出來的“大流”可能無法準(zhǔn)確反映線上的真實(shí)情況。為了解決上述問題，可以加入動(dòng)態(tài)特征。那么動(dòng)態(tài)特征是什么樣的？舉個(gè)例子說明。如上圖所示，我們以大流發(fā)生變化的動(dòng)態(tài)特征舉例。之前的模型推薦是如果中國(guó)的男性用戶訪問PageID100，就給他推薦廣告2002，這是一個(gè)固定不變的行為。在此基礎(chǔ)上做一些變化，當(dāng)進(jìn)行采樣實(shí)時(shí)特征的時(shí)候，這個(gè)實(shí)時(shí)特征是最近一段時(shí)間內(nèi)，即當(dāng)中國(guó)的男性用戶訪問PageID100的時(shí)候，他們點(diǎn)擊最多的10個(gè)廣告。這個(gè)特征沒有辦法在離線的時(shí)候計(jì)算出來，因?yàn)樗且粋€(gè)線上實(shí)時(shí)發(fā)生的用戶行為。那么在產(chǎn)生用戶行為之后可以做一件什么事情呢？可以在中國(guó)的男性用戶訪問PageID100的時(shí)候，不單純給他推廣告2002，而是推最近這段時(shí)間中國(guó)男性用戶訪問PageID100時(shí)候點(diǎn)擊最多的那些廣告。這樣的情況下，如果中國(guó)男性用戶訪問PageID100的時(shí)候，最近訪問最多的廣告是2001和2002。當(dāng)用戶ID來了，我們看到他是一個(gè)中國(guó)男性用戶，就有可能給他推薦廣告上述就是大流發(fā)生變化的一個(gè)例子。同樣的道理，因?yàn)橄到y(tǒng)可以對(duì)用戶的實(shí)時(shí)特征進(jìn)行采樣，所以能更好地判斷用戶當(dāng)時(shí)當(dāng)刻的意圖。比方說，可以去看用戶最近一分鐘看了哪些頁(yè)面，瀏覽哪些商品，這樣的話可以實(shí)時(shí)判斷用戶當(dāng)時(shí)當(dāng)刻的想法，從而給他推薦一個(gè)更適合他當(dāng)下意圖的廣告。這樣的推薦系統(tǒng)是不是就完全沒有問題呢？再看一個(gè)例子。比方說剛才上文提到用戶1和用戶2都是中國(guó)男性用戶，之前假設(shè)他們的行為是類似的，在之前的歷史數(shù)據(jù)里面也印證了這一點(diǎn)。但是當(dāng)在線上真正看用戶行為的時(shí)候，可能會(huì)發(fā)生什么樣的情況？可能發(fā)生用戶1和用戶2的行為產(chǎn)生分化，分化的原因可能有很多種，但不知道是什么原因。此時(shí)給用戶1和用戶2所推薦的東西可能就完全不一樣了，那是什么原因?qū)е路只?？舉個(gè)例子來說，如果用戶1來自上海，用戶2來自北京。某天北京有非常大的降溫，這個(gè)時(shí)候北京用戶2可能就開始搜索秋褲，但是上海當(dāng)天還是很熱，上海的用戶1在搜索服裝的時(shí)候，可能還是搜索一些夏裝。這個(gè)時(shí)候，中國(guó)的男性用戶里面，上海用戶1和北京用戶2的搜索行為就產(chǎn)生了一些變化。此時(shí)就需要給他們推薦不一樣的廣告，但是靜態(tài)的模型沒有辦法很好地做到這一點(diǎn)。因?yàn)檫@個(gè)模型其實(shí)是一個(gè)靜態(tài)訓(xùn)練的模型，所以如果是一個(gè)分類模型的話，當(dāng)中能夠產(chǎn)生的類別其實(shí)是一個(gè)固定的類別，為了產(chǎn)生一個(gè)新的分類，就需要對(duì)模型重新進(jìn)行訓(xùn)練。由于模型訓(xùn)練是離線進(jìn)行的，所以可能這個(gè)訓(xùn)練的模型需要在第二天才能被更新，這樣就會(huì)對(duì)推薦效果產(chǎn)生影響。l通過增加動(dòng)態(tài)featureO實(shí)時(shí)跟蹤一類用戶的行為，貼合“大流”；O實(shí)時(shí)追蹤用戶的行為表現(xiàn)，了解用戶當(dāng)時(shí)當(dāng)刻的意圖，并將用戶劃分到更合適的類別l但是當(dāng)模型的分類方式本身發(fā)生變化時(shí)，可能無法找到最合適的類別，需要重新訓(xùn)練模型增加分類。例：新產(chǎn)品上線頻繁，業(yè)務(wù)高速成長(zhǎng)，用戶行為的分布變化比較快。當(dāng)遇到以上問題，需要把考慮的事情加入動(dòng)態(tài)的模型更新，動(dòng)態(tài)模型更新是怎么來做？其實(shí)是一樣的道理。如上圖所示，除了把用戶的實(shí)時(shí)行為日志做ETL到離線的地方進(jìn)行FeatureGeneration以外，可能還要把用戶行為日志在線導(dǎo)出來，然后去做特征生成、樣本拼接，然后做進(jìn)線的模型訓(xùn)練。這里的模型訓(xùn)練通常都是流式的訓(xùn)練，在一個(gè)基礎(chǔ)模型之上做增量的訓(xùn)練，來使模型更好地貼合當(dāng)時(shí)當(dāng)刻用戶行為的一些變化。在這種情況下，通過這種實(shí)時(shí)樣本的訓(xùn)練，可以讓這個(gè)模型產(chǎn)生新的分類，它會(huì)知道上海和北京用戶的行為可能是不一樣的。因此，當(dāng)用戶訪問PageID100的時(shí)候，對(duì)于上海的用戶它可能會(huì)推薦廣告2002，北京的用戶可能推薦的就是廣告2011了。在這樣的情況分化下，假設(shè)用戶4再過來的時(shí)候，系統(tǒng)會(huì)看他到底是上海的用戶還是北京的用戶，如果他是上海的用戶的話，還是會(huì)給他推薦廣告2002。加入實(shí)時(shí)模型訓(xùn)練的推薦系統(tǒng)特點(diǎn)：l在動(dòng)態(tài)特征的基礎(chǔ)上，實(shí)時(shí)訓(xùn)練模型，使模型盡可能貼近此時(shí)此刻用戶行為的分布；l緩解模型的退化。二、實(shí)時(shí)推薦系統(tǒng)架構(gòu)上面的例子是了解實(shí)時(shí)推薦系統(tǒng)的原理，它為什么會(huì)比一般的離線推薦系統(tǒng)做得更好。那么，如何通過Flink加上Hologres和一些其他系統(tǒng)/項(xiàng)目來搭建出這樣一套可用的實(shí)時(shí)推薦系統(tǒng)？首先來看一下上文提到的經(jīng)典離線推薦系統(tǒng)的架構(gòu)，如下所示。這個(gè)架構(gòu)其實(shí)之前講的架構(gòu)一樣，只是增加了部分細(xì)節(jié)。首先，通過消息隊(duì)列用來采集實(shí)時(shí)的用戶行為，這個(gè)消息隊(duì)列里面的實(shí)時(shí)用戶行為會(huì)被導(dǎo)入到一個(gè)離線存儲(chǔ)來存儲(chǔ)歷史用戶行為，然后每天會(huì)做靜態(tài)特征的計(jì)算，最后放到特征存儲(chǔ)里面給線上的推理服務(wù)用。與此同時(shí)，系統(tǒng)也會(huì)做離線的樣本拼接，拼接出來的樣本會(huì)存到樣本存儲(chǔ)里面給離線的模型訓(xùn)練使用，離線的模型訓(xùn)練每天會(huì)產(chǎn)生新的模型去驗(yàn)證，然后給到推理服務(wù)使用，這個(gè)模型是一個(gè)T+1的更新。以上就是一個(gè)經(jīng)典離線推薦系統(tǒng)的架構(gòu)。如果要把它推進(jìn)到實(shí)時(shí)推薦系統(tǒng)里面，主要要做以下三件事情：l特征計(jì)算O靜態(tài)T+1特征計(jì)算到實(shí)時(shí)特征計(jì)算。l樣本生成O離線T+1樣本生成到實(shí)時(shí)樣本生成。l模型訓(xùn)練O離線訓(xùn)練T+1更新到增量訓(xùn)練實(shí)時(shí)更新。阿里巴巴搜推廣已經(jīng)上線了這樣的實(shí)時(shí)推薦系統(tǒng)，它的整個(gè)流程其實(shí)跟離線的推薦系統(tǒng)是類似的，主要區(qū)別是整個(gè)過程都實(shí)時(shí)化了。如上所示，這套系統(tǒng)主要有三方面的特性：l時(shí)效性：大促期間，全流程實(shí)時(shí)更新。l靈活性：根據(jù)需求，隨時(shí)調(diào)整特征和模型。l可靠性：系統(tǒng)穩(wěn)定、高可用，上線效果保證。用戶可以做到非常有時(shí)效性地更新模型、特征，在大促的期間，可以隨時(shí)調(diào)整特征和模型，表現(xiàn)出來的效果也很好。實(shí)時(shí)推薦系統(tǒng)的架構(gòu)應(yīng)該長(zhǎng)成什么樣子？如上圖所示，相比于剛才經(jīng)典的離線推薦系統(tǒng)，實(shí)時(shí)推薦架構(gòu)發(fā)生了一些變化。首先，消息隊(duì)列生成的數(shù)據(jù)，除了進(jìn)到離線存儲(chǔ)保存歷史行為以外，系統(tǒng)還會(huì)把這個(gè)消息隊(duì)列里面的消息讀出來兩份，其中一份拿去做實(shí)時(shí)的特征計(jì)算，也是會(huì)放到特征存儲(chǔ)里面，另外一份是會(huì)放到實(shí)時(shí)樣本拼接里面，跟線上的推理服務(wù)使用的用戶特征進(jìn)行一個(gè)雙流Join，這樣能夠得到一個(gè)實(shí)時(shí)的樣本。在這種情況下，存儲(chǔ)到實(shí)時(shí)系統(tǒng)的樣本可以同時(shí)被拿來做離線的模型訓(xùn)練，也可以拿來做實(shí)時(shí)的模型訓(xùn)練。不管是離線的還是實(shí)時(shí)的模型訓(xùn)練，它們生成的模型都會(huì)被放到模型存儲(chǔ)里面，并經(jīng)過模型驗(yàn)證最后上線。離線模型訓(xùn)練是天級(jí)別的，但實(shí)時(shí)模型訓(xùn)練可能是分鐘級(jí)、小時(shí)級(jí)甚至是秒級(jí)的。這個(gè)時(shí)候離線的模型訓(xùn)練會(huì)天級(jí)別產(chǎn)生一個(gè)BaseModel給到實(shí)時(shí)的模型訓(xùn)練，然后再去做增量的模型更新。整個(gè)的架構(gòu)里面有一點(diǎn)需要提到的是，推理服務(wù)在使用這個(gè)特征存儲(chǔ)里面拿過來的特征做推理的同時(shí)，它還需要把本次做推理所用的特征也加上RequestID送到消息隊(duì)列里面。這樣的話實(shí)時(shí)樣本拼接的時(shí)候，當(dāng)產(chǎn)生一個(gè)正樣本，比方說用戶展示了某一個(gè)廣告，然后點(diǎn)擊了之后它是一個(gè)正樣本，這時(shí)候才能夠知道當(dāng)時(shí)用了哪些特征給用戶推薦的廣告，所以這個(gè)特征信息是需要推理服務(wù)保留下來，送到實(shí)時(shí)樣本里面做樣本拼接，才能生成一個(gè)很好的樣本。這個(gè)架構(gòu)里面可以看到，相比于經(jīng)典的離線推薦系統(tǒng)，在綠色框的部分都是實(shí)時(shí)的部分，有一些部分是新加的，有一些部分是把原來離線的部分變成了實(shí)時(shí)的部分。比如實(shí)時(shí)特征計(jì)算是新加的，實(shí)時(shí)樣本拼接是把原來的離線樣本拼接的部分變成了實(shí)時(shí)，實(shí)時(shí)模型訓(xùn)練是新加的，模型驗(yàn)證也是同樣的道理，是把原來的離線模型驗(yàn)證，變成了實(shí)時(shí)的模型驗(yàn)證。如果要實(shí)現(xiàn)剛才的實(shí)時(shí)推薦系統(tǒng)架構(gòu)，會(huì)用到一些什么樣的系統(tǒng)？如上圖所示，消息隊(duì)列用的是Kafka，離線的存儲(chǔ)假設(shè)用的是HDFS。不管是實(shí)時(shí)特征計(jì)算還是離線特征計(jì)算，現(xiàn)在都可以用Flink來進(jìn)行計(jì)算，利用Flink流批一體的能力，能夠保證實(shí)時(shí)和離線的特征計(jì)算所產(chǎn)生的結(jié)果是一致的。Hologres在這里的作用是特征存儲(chǔ)，Hologres特征存儲(chǔ)的好處是可以提供非常高效的點(diǎn)查，另一個(gè)就是在做實(shí)時(shí)特征計(jì)算的時(shí)候，經(jīng)常會(huì)產(chǎn)生一些不準(zhǔn)確的特征，需要在后期對(duì)這些特征進(jìn)行一些修正?？梢酝ㄟ^Flink加Hologres的機(jī)制進(jìn)行很好的特征的修正。同樣的道理，在推理服務(wù)這一側(cè)，通過保留用來做推理的特征，放到后面的樣本拼接里面,這里的消息隊(duì)列也會(huì)使用Kafka。樣本拼接這個(gè)事情會(huì)用Flink來做，F(xiàn)link一個(gè)非常經(jīng)典的應(yīng)用場(chǎng)景做雙流Join。把樣本給拼接出來后，在把特征給加上，接著把算好的樣本同樣也放進(jìn)Hologres里面做樣本的存儲(chǔ)。在樣本存儲(chǔ)的情況下，Hologres里面的樣本既可以拿來做實(shí)時(shí)的模型訓(xùn)練，通過讀取Hologres的Binlog來做實(shí)時(shí)的模型訓(xùn)練，也可以通過Hologres批量的Scan去做離線的模型訓(xùn)練。不管是在線還是離線的模型訓(xùn)練，都可以用Flink或者是FlinkML，也就是Alink來做。如果是傳統(tǒng)機(jī)器學(xué)習(xí)的話，也可以用TensorFlow來做深度學(xué)習(xí)的模型訓(xùn)練，這樣的模型還是可能會(huì)存到HDFS，然后通過Flink和TensorFlow做模型的驗(yàn)證，最后做線上的推理服線上推理服務(wù)很多用戶會(huì)有自己的推理引擎，如果有可以用，如果想用Flink和TensorFlow的話也可以直接使用。首先我們來看實(shí)時(shí)特征計(jì)算和推理的過程，如上圖所示。剛才提到我們會(huì)把實(shí)時(shí)的用戶行為采集下來，送到Flink里面去做實(shí)時(shí)特征計(jì)算，然后存進(jìn)Hologres里面給線上推理服務(wù)使用。這里的實(shí)時(shí)特征可能包含：l用戶最近5分鐘的瀏覽記錄O商品、文章、視頻O停留時(shí)長(zhǎng)O收藏、加購(gòu)、咨詢，評(píng)論l最近10分鐘每個(gè)品類中點(diǎn)擊率最高的50個(gè)商品l最近30分鐘瀏覽量最高的文章、視頻、商品l最近30分鐘搜索量最高的100個(gè)詞對(duì)于搜推廣業(yè)務(wù)，都可以用這樣的實(shí)時(shí)特征來更好的獲得推薦效果。再往下我們會(huì)看實(shí)時(shí)樣本拼接的部分，如下圖所示。實(shí)時(shí)用戶行為會(huì)被采集下來，進(jìn)到Flink里面去做樣本的拼接。這里的樣本拼接包含了兩個(gè)部分，第一個(gè)部分是首先要知道這個(gè)樣本是正樣本還是負(fù)樣本，這是通過分析實(shí)時(shí)用戶行為的日志來的，我們會(huì)有展示流、點(diǎn)擊流，如果展示流Join點(diǎn)擊流，然后發(fā)現(xiàn)展示的一個(gè)Item被用戶點(diǎn)擊了，那么這就是正樣本。如果我們展示了某個(gè)Item用戶沒有點(diǎn)擊，那么就是一個(gè)負(fù)樣本，這就是我們判斷正負(fù)樣本的過程。僅僅有正負(fù)樣本的判斷顯然不夠，因?yàn)樵谧鲇?xùn)練的時(shí)候還需要這個(gè)特征，這些特征是從推理服務(wù)過來的，當(dāng)展示某一個(gè)Item的時(shí)候，推理服務(wù)就使用了某一些特征來判斷用戶是否會(huì)對(duì)這個(gè)東西感興趣。這些特征會(huì)放到Kafka里面留存下來，進(jìn)到Flink里面。做樣本拼接的過程當(dāng)中，會(huì)通過RequestIDJoin上當(dāng)時(shí)去做推薦的所用到這些特征，然后生成一個(gè)完整的樣本放到Hologres里面。這里會(huì)利用Flink多流Join能力進(jìn)行樣本拼接，與此同時(shí)也會(huì)做多流同步、正負(fù)樣本、樣本修正。在樣本生成了以后，下一個(gè)步驟就是實(shí)時(shí)的模型訓(xùn)練或者深度學(xué)習(xí)。如上圖所示，在這種情況下，剛才說到樣本是存在Hologres里面的，Hologres里面的樣本可以用作兩個(gè)用途，既可以用做在線的模型訓(xùn)練，也可以用做離線的模型訓(xùn)練。在線的模型訓(xùn)練和離線的模型訓(xùn)練可以分別利用Hologres的Binlog和批量Scan的功能去做。從性能上來講，其實(shí)跟一般的消息隊(duì)列或者文件系統(tǒng)去掃描相差并不大。這里如果是深度模型的話，可以用TensorFlow來做訓(xùn)練。如果是傳統(tǒng)機(jī)器學(xué)習(xí)模型的話，我們可以用Alink或者說FlinkML來做訓(xùn)練，然后進(jìn)到HDFS存儲(chǔ)，把模型給存儲(chǔ)起來，接著再通過Flink或者TensorFlow來做模型的驗(yàn)證。上述過程是實(shí)際搭建實(shí)時(shí)模型和深度模型訓(xùn)練可以用到的一些技術(shù)。這里簡(jiǎn)單的介紹一下Alink，Alink是基于Flink的一個(gè)機(jī)器學(xué)習(xí)算法庫(kù)，目前已經(jīng)開源，正在向ApacheFlink社區(qū)進(jìn)行貢獻(xiàn)中。如上圖所示，Alink(FlinkML)相比于SparkML來講有兩個(gè)特色：ML僅提供批式算法，Alink提供批流一體算法；lAlink在批式算法上和SparkML相當(dāng)。介紹完訓(xùn)練部分，再來看離線特征回填。這個(gè)過程其實(shí)是說在上線實(shí)時(shí)特征以后，需要上線新的特征，應(yīng)該怎么做？如上圖所示，一般會(huì)分成兩步。第一步會(huì)在實(shí)時(shí)的系統(tǒng)里面先把新的特征給加上，那么從某一個(gè)時(shí)刻開始，Hologres里面存儲(chǔ)生成的特征都是有新的特征了。對(duì)于那些歷史數(shù)據(jù)怎么辦？這個(gè)時(shí)候就需要重新做一個(gè)特征回填，用HDFS里面存的歷史行為數(shù)據(jù)跑一個(gè)批量的任務(wù)，然后把歷史上的一些特征給補(bǔ)上。所以離線特征回填在這個(gè)架構(gòu)圖里面也是由Flink的離線特征計(jì)算來完成的，從HDFS里面把歷史行為數(shù)據(jù)讀出來，然后去算一些離線的特征，把過去的歷史消息里面的特征給補(bǔ)上。剛才的架構(gòu)里面所用到的關(guān)鍵技術(shù)比較多，接下來主要講兩個(gè)點(diǎn)。第一個(gè)點(diǎn)是可撤回訂正的特征和樣本，如上圖所示。圖中有下部陰影的區(qū)域里面，通過Flink和Hologres配合，會(huì)進(jìn)行一些樣本和特征的撤回和訂正。為什么需要特征和樣本的訂正？l實(shí)時(shí)日志存在亂序O例如某個(gè)用戶點(diǎn)擊事件由于系統(tǒng)延遲晚到產(chǎn)生FalseNegative樣本l一般通過離線作業(yè)重新計(jì)算離線樣本O重新跑整個(gè)離線樣本計(jì)算O僅更新需要更正的特征和樣本實(shí)時(shí)日志有可能會(huì)存在一些亂序，有些流可能到得早一些，有些流可能到得晚一些。在這種情況下，在做多流Join的時(shí)候就有可能會(huì)由于系統(tǒng)的延遲、晚到而產(chǎn)生一些False舉個(gè)例子，比如在做展示和點(diǎn)擊流Join的時(shí)候，可能一開始認(rèn)為用戶并沒有點(diǎn)擊某一個(gè)廣告，后來發(fā)現(xiàn)用戶點(diǎn)擊了，但是這條事件到的時(shí)間晚了。在這種情況中，一開始會(huì)告訴下游用戶沒有點(diǎn)擊，這是一個(gè)FalseNegative，后面發(fā)現(xiàn)用戶其實(shí)點(diǎn)擊了，因此需要對(duì)FalseNegative做修正。當(dāng)發(fā)生這種情況，需要對(duì)之前的樣本做撤回或者更新，去告訴它之前的樣本不是負(fù)樣本，而是正樣本?；谏鲜鲞@種情況，我們需要整套鏈路上面有一個(gè)撤回的能力，需要逐級(jí)告訴下游之前的錯(cuò)誤，需要把它給修正，通過ApacheFlink+Hologres配合可以完成這樣一個(gè)機(jī)制。為什么要做這樣一件事情？以前產(chǎn)生這種FalseNegative樣本的時(shí)候，一般都是通過離線作業(yè)重新計(jì)算離線樣本進(jìn)行更正。這種方式的代價(jià)是可能需要重新跑整個(gè)離線的樣本計(jì)算，但最終目的其實(shí)僅僅是修正所有樣本里其中很小的一部分樣本，因此這個(gè)代價(jià)是比較高昂的。通過ApacheFlink+Hologres實(shí)現(xiàn)的機(jī)制，可以做到對(duì)FalseNegative樣本進(jìn)狀的更新，而不是重新跑整個(gè)樣本，這種情況下，更正特征和樣本的代價(jià)就會(huì)小很多。在這個(gè)架構(gòu)里另一個(gè)關(guān)鍵技術(shù)是基于事件的流批混合工作流，它是什么意思？看這個(gè)圖，除了剛才所示那些系統(tǒng)之外，這也是一個(gè)非常復(fù)雜的工作流。因?yàn)椴煌南到y(tǒng)之間，它可能存在依賴關(guān)系和調(diào)度關(guān)系，有的時(shí)候是數(shù)據(jù)依賴，有的時(shí)候是控制依賴。例如，我們可能會(huì)周期性或者定期去跑一些離線的靜態(tài)特征計(jì)算，有可能是做特征回填，也有可能是更正實(shí)時(shí)特征產(chǎn)生的問題，但可能是默認(rèn)周期性地跑，也有可能是手動(dòng)觸發(fā)地跑。還有的時(shí)候是當(dāng)離線模型訓(xùn)練生成之后，需要去觸發(fā)在線模型驗(yàn)證的動(dòng)作，也有可能是在線的模型訓(xùn)練生成以后要去觸發(fā)在線模型訓(xùn)練的動(dòng)作。還有可能是樣本拼接到了某一個(gè)點(diǎn)，比如上午10點(diǎn)樣本拼接完成之后，想要告訴模型訓(xùn)練說，上午10點(diǎn)之前的樣本都拼接好了，希望想跑一個(gè)批量離線訓(xùn)練的任務(wù)，把昨天早上10點(diǎn)到今天早上10點(diǎn)的數(shù)據(jù)做離線的模型訓(xùn)練。這里它是由一個(gè)流任務(wù)觸發(fā)一個(gè)批任務(wù)的過程。在剛才提到的批量模型訓(xùn)練生成之后，需要放到線上做模型驗(yàn)證的過程當(dāng)中，它其實(shí)是一個(gè)批任務(wù)觸發(fā)流任務(wù)的過程，也會(huì)線上模型訓(xùn)練產(chǎn)生的模型，需要去線上模型訓(xùn)練進(jìn)行驗(yàn)證，這是流任務(wù)觸發(fā)流任務(wù)的過程。所以在這個(gè)過程當(dāng)中，會(huì)涉及到很多不同任務(wù)之間的交互，這里叫做一個(gè)比較復(fù)雜的工作流，它既有批的任務(wù)又有流的任務(wù)，所以它是一個(gè)流批混合的工作流。如何做到流批混合的工作流實(shí)現(xiàn)？使用的是FlinkAIFlow，它是一個(gè)大數(shù)據(jù)加AI頂層工作流抽象。如上圖所示，一個(gè)工作流通?？梢苑譃閃orkflow定義和Workflow執(zhí)行這兩個(gè)步驟。Workflow定義會(huì)定義Node和Relation，即定義節(jié)點(diǎn)和節(jié)點(diǎn)之間的關(guān)系。在FlinkAIFlow里面，我們把一個(gè)節(jié)點(diǎn)定義成一個(gè)LogicalProcessingUnit，然后把這個(gè)節(jié)點(diǎn)之間的關(guān)系定義成Eventdrivenconditions。在這樣的抽象下面，在Workflow執(zhí)行層面做了一個(gè)基于事件的調(diào)度。抽象嚴(yán)格來，在一個(gè)系統(tǒng)里面會(huì)有很多的事件，把這些事件組合到一起，可能會(huì)滿足某一些條件，當(dāng)滿足一個(gè)條件的時(shí)候，會(huì)產(chǎn)生一些動(dòng)作。例如，一個(gè)工作流中可能有一個(gè)任務(wù)A，它可能會(huì)監(jiān)聽這個(gè)系統(tǒng)里面各種各樣的事件。當(dāng)事件1發(fā)生，然后發(fā)生了事件2，接著發(fā)生了事件3，當(dāng)事件按照這么一個(gè)序列發(fā)生之后，需要做啟動(dòng)任務(wù)A的動(dòng)作，事件123按序發(fā)生是條件。通過這樣的抽象，可以很好地把以前傳統(tǒng)工作流和帶有流作業(yè)的工作流整合起來。因?yàn)橐郧皞鹘y(tǒng)的工作流里都是基于作業(yè)狀態(tài)發(fā)生變化進(jìn)行調(diào)度，一般是作業(yè)跑完了，然后去看怎么跑下一個(gè)作業(yè)。這個(gè)方式的問題是如果作業(yè)是一個(gè)流作業(yè)，那么這個(gè)作業(yè)永遠(yuǎn)跑不完，這個(gè)工作流無法正常工作。在基于事件的調(diào)度里面，很好地解決了這個(gè)問題。將不再依賴作業(yè)的狀態(tài)發(fā)生變化來進(jìn)行工作流調(diào)度，而是基于事件來做。這樣的話即使是一個(gè)流作業(yè)，它也可以產(chǎn)生一些事件，然后告訴調(diào)度器做一些其他的事情。為了完成整個(gè)調(diào)度語(yǔ)義，還需要一些支持服務(wù)，協(xié)助完成整個(gè)調(diào)度語(yǔ)義的支持服務(wù)包括：下面來分別看一下這些支持服務(wù)的內(nèi)容。元數(shù)據(jù)服務(wù)是管理數(shù)據(jù)集，在工作流里面希望用戶不用非常繁瑣地找到自己的數(shù)據(jù)集，可以幫用戶管理數(shù)據(jù)集，用戶要用的時(shí)候給一個(gè)名字就可以。元數(shù)據(jù)服務(wù)也會(huì)管理項(xiàng)目（Project這里的Project是指FlinkAIFlow里面的Project，一個(gè)Project里面可以含有多個(gè)工作流，管理Project最主要的目的是為了保證工作流能夠被復(fù)現(xiàn)。在元數(shù)據(jù)服務(wù)里面，還會(huì)管理工作流和作業(yè)，每個(gè)工作流里面可能會(huì)涉及到很多的作業(yè)。除此之外，也會(huì)管理模型血緣，可以知道模型的版本是由哪一個(gè)工作流當(dāng)中的哪一個(gè)作業(yè)生成的，最后也支持用戶定義一些自定義實(shí)體。第二個(gè)服務(wù)是通知服務(wù)，它是一個(gè)帶主鍵的事件和事件監(jiān)聽。舉個(gè)例子，如上圖所示。一個(gè)客戶端希望監(jiān)聽一個(gè)事件，這個(gè)事件的Key是模型。如果Key被更新的時(shí)候，監(jiān)聽的用戶就會(huì)收到一個(gè)callback，會(huì)告訴他有一個(gè)事件被更新了，那個(gè)事件的主鍵是模型，Value是模型的URI，版本號(hào)是1。這里能夠起到的一個(gè)作用就是如果驗(yàn)證一個(gè)作業(yè)，它可以去監(jiān)聽NotificationService。當(dāng)有一個(gè)新模型生成的時(shí)候，需要被通知然后對(duì)這個(gè)模型進(jìn)行驗(yàn)證，所以通過NotificationService就可以做這樣的事情。模型中心做的是模型多版本的管理，參數(shù)的記錄，包括模型指標(biāo)的追蹤和模型生命周期的管理，還有一些模型可視化的工作。舉個(gè)例子闡述FlinkAIFlow是如何把實(shí)時(shí)推薦系統(tǒng)里面復(fù)雜的工作流，用一個(gè)完整的工作流描述出來。如上所示，假如有一個(gè)DAG，它里面包含了模型的訓(xùn)練，模型的驗(yàn)證以及在線推理這三個(gè)作業(yè)。首先，通過Scheduler模型訓(xùn)練的作業(yè)，在提交上去之后，Scheduler會(huì)到MetadataService里面去更新作業(yè)的狀態(tài)，變成一個(gè)待提交的狀態(tài)。假設(shè)環(huán)境是K8SCluster，那么它會(huì)提交到Kubernetes上去跑這樣一個(gè)訓(xùn)練作業(yè)。訓(xùn)練作業(yè)跑起來之后，可以通過作業(yè)狀態(tài)監(jiān)聽器去更新作業(yè)的狀態(tài)。假使這個(gè)作業(yè)是一個(gè)流式的訓(xùn)練作業(yè)，跑了一段時(shí)間以后會(huì)生成一個(gè)模型，這個(gè)模型會(huì)注冊(cè)到模型中心。注冊(cè)完了以后，模型中心會(huì)發(fā)出一個(gè)事件，表示有一個(gè)新的模型版本被注冊(cè)了，這個(gè)事件會(huì)到Scheduler,Scheduler會(huì)監(jiān)聽這些事件。之后Scheduler就會(huì)去看，當(dāng)收到這個(gè)事件的時(shí)候，有沒有一些條件被滿足了，然后需要做一些什么樣的動(dòng)作。有一個(gè)模型生成的時(shí)候，Scheduler需要去對(duì)這個(gè)模型進(jìn)行驗(yàn)證，這個(gè)條件被滿足以后，需要去拉起一個(gè)作業(yè)，這個(gè)作業(yè)就是一個(gè)模型驗(yàn)證的作業(yè)。模型驗(yàn)證作業(yè)被拉起之后，它會(huì)到模型中心找到最新被生成的一個(gè)模型版本，然后對(duì)它去進(jìn)行模型的驗(yàn)證。假設(shè)模型驗(yàn)證通過了，這個(gè)模型驗(yàn)證是個(gè)批作業(yè)，它會(huì)告訴ModelCenter模型被Validated了，這個(gè)時(shí)候模型中心就會(huì)發(fā)送一條ModelValidatedVersionEvent給Scheduler，模型被更新了以后，Scheduler會(huì)去看ModelValidated，觸發(fā)拉起線上的推理服務(wù)。推理服務(wù)拉起之后，它會(huì)到模型中心里面把剛被Validated過的模型拉過來做推理。假設(shè)推理服務(wù)也是一個(gè)流的作業(yè)，也是一直跑在那里。過了一段時(shí)間之后，線上的流的訓(xùn)練作業(yè)又生成了一個(gè)新的模型，剛才那條路又會(huì)再走一遍，它會(huì)有一個(gè)模型生成的一個(gè)NewModelVersionValidated，它又會(huì)被Scheduler聽到，Scheduler又拉起一個(gè)Validated作業(yè)，Job2又會(huì)被拉起，拉起之后Validated作業(yè)又會(huì)去驗(yàn)證模型，有可能這個(gè)模型驗(yàn)證又通過了，又會(huì)發(fā)送一條模型NewModelVersionValidated給模型中心，模型中心會(huì)把這個(gè)Event又給到Scheduler。這個(gè)時(shí)候，Scheduler會(huì)看到推理作業(yè)其實(shí)已經(jīng)起在那里了，可能就什么都不做。推理作業(yè)同時(shí)也在監(jiān)聽著ModelVersionValidated事件，當(dāng)它收到這個(gè)事件的時(shí)候，會(huì)去做的一件事情就是到模型中心里面重新加載最新的被Validated過的事件。通過這個(gè)例子，解釋了為什么需要流批混合的調(diào)度器和工作流，來實(shí)現(xiàn)端到端的實(shí)時(shí)推薦系統(tǒng)架構(gòu)里所有作業(yè)、工作流的串聯(lián)。目前，F(xiàn)linkAIFlow也作為開源Flink生態(tài)項(xiàng)目放在Github上面，感興趣的同學(xué)可以通過下方鏈接進(jìn)行觀看。實(shí)時(shí)數(shù)倉(cāng)助力互聯(lián)網(wǎng)實(shí)時(shí)決策和精準(zhǔn)營(yíng)銷近年來，實(shí)時(shí)數(shù)倉(cāng)是互聯(lián)網(wǎng)的熱門話題，主要應(yīng)用場(chǎng)景主要是在實(shí)時(shí)決策和營(yíng)銷等領(lǐng)域，這些領(lǐng)域?qū)?shù)據(jù)分析的精細(xì)度、實(shí)時(shí)性都有很高的要求，是走在技術(shù)前沿的領(lǐng)域。一、業(yè)務(wù)在線化、運(yùn)營(yíng)精細(xì)化推動(dòng)數(shù)倉(cāng)實(shí)時(shí)化、交互化先看一下過去幾年數(shù)據(jù)分析發(fā)展的趨勢(shì)，如上圖所示?？梢钥吹?，數(shù)據(jù)分析基本的趨勢(shì)是從批處理向交互式分析、流計(jì)算的方向演進(jìn)。在10年前，大數(shù)據(jù)更多的是處理規(guī)模的問題，通過并行計(jì)算的技術(shù)處理海量的數(shù)據(jù)，那個(gè)時(shí)候我們更多的是在做數(shù)據(jù)的清洗，數(shù)據(jù)模型的設(shè)計(jì)，對(duì)分析的需求并不太多。如今，我們的大數(shù)據(jù)團(tuán)隊(duì)基本上都變成了數(shù)據(jù)分析的團(tuán)隊(duì)，對(duì)數(shù)據(jù)模型的沉淀，對(duì)交互式分析的支持能力，對(duì)查詢響應(yīng)延遲的支持效率，對(duì)QPS的要求都會(huì)越來越多。數(shù)據(jù)分析也并不只是數(shù)據(jù)存下來再分析，也有很多計(jì)算前置，先有邏輯后有計(jì)算的場(chǎng)景。比如在雙11的時(shí)候，在多少秒有多少成交量，這樣一個(gè)典型的場(chǎng)景就不是先有交易數(shù)據(jù)后有計(jì)算量的問題，一定是隨著交易而發(fā)生實(shí)時(shí)計(jì)算的過程。因此，交互式分析和流計(jì)算幾乎是一個(gè)并行前進(jìn)的過程，這兩種新的場(chǎng)景對(duì)背后技術(shù)有很多不一樣的要求。批處理更多的是講究并行度，在交互式分析領(lǐng)域里，我們開始有很多的預(yù)計(jì)算、內(nèi)存計(jì)算、索引等技術(shù)，這也是推動(dòng)了整個(gè)大數(shù)據(jù)技術(shù)的演進(jìn)?？偨Y(jié)來看，數(shù)據(jù)分析支撐著越來越多的在線業(yè)務(wù)，在線業(yè)務(wù)包括我們?nèi)魏螘r(shí)候打開手機(jī)，手機(jī)屏幕里邊推薦的產(chǎn)品、展示的廣告，這些都是需要在幾毫秒之內(nèi)返回結(jié)果，靠數(shù)據(jù)智能推薦出來，如果不推薦的話點(diǎn)擊率、轉(zhuǎn)化率一定非常低。因此，我們的數(shù)據(jù)業(yè)務(wù)在支撐越來越多的在線業(yè)務(wù)，在線業(yè)務(wù)對(duì)查詢延遲、QPS、精細(xì)度都有非常高的要求，這也推動(dòng)著數(shù)倉(cāng)向?qū)崟r(shí)化、交互化方向演進(jìn)。二、阿里巴巴典型實(shí)時(shí)數(shù)倉(cāng)場(chǎng)景在阿里巴巴有很多數(shù)倉(cāng)的使用場(chǎng)景，例如雙11的實(shí)時(shí)GMV大屏。GMV只是一個(gè)結(jié)論性的數(shù)字，實(shí)際上對(duì)數(shù)據(jù)分析師而言，這個(gè)工作只是剛剛開始。我們要向下分析，是什么產(chǎn)品，在什么渠道，針對(duì)什么樣的人群，以什么樣的促銷手段，達(dá)成這樣的轉(zhuǎn)化效果，有哪些轉(zhuǎn)化效果沒有達(dá)成，等等。這些分析其實(shí)非常的細(xì)致，是精細(xì)化分析的效果。分析之后，就會(huì)對(duì)所有的商品、人群做一些標(biāo)簽化處理，通過標(biāo)簽化我們下一步可以去指導(dǎo)在線的應(yīng)用去做推薦、分析、圈選等等，所以有很多數(shù)據(jù)中臺(tái)的業(yè)務(wù)也會(huì)產(chǎn)生。還有一類業(yè)務(wù)是偏監(jiān)控類業(yè)務(wù)，訂單突然抖動(dòng)、增長(zhǎng)，網(wǎng)絡(luò)質(zhì)量的抖動(dòng)，視頻直播的一些監(jiān)控等，這些也是實(shí)時(shí)數(shù)倉(cāng)典型的應(yīng)用場(chǎng)景。三、大數(shù)據(jù)實(shí)時(shí)數(shù)倉(cāng)體系的“紛繁蕪雜”過去我們建設(shè)實(shí)時(shí)數(shù)倉(cāng)的時(shí)候參考過很多公司，阿里巴巴也是走過很復(fù)雜的一條路線。這是我們?cè)缙诘南到y(tǒng)架構(gòu)圖。但當(dāng)真正去做這樣一個(gè)系統(tǒng)的時(shí)候，發(fā)現(xiàn)這個(gè)系統(tǒng)的開發(fā)效率、運(yùn)維效率非常令人抓狂。這套系統(tǒng)從左上角演化開始，消息從消息中間件收集，之后是一個(gè)離線加工的過程，那個(gè)時(shí)候我們還沒有很多實(shí)時(shí)的技術(shù)，首先要先解決規(guī)模的問題。通過離線的加工，我們會(huì)把加工的結(jié)果集變成小的結(jié)果集，存到MySQL和Redis，這是一個(gè)典型的加工服務(wù)二元化的體系。通過把數(shù)據(jù)變成小數(shù)據(jù)之后，才能對(duì)外提供上層的應(yīng)用，包括報(bào)表應(yīng)用、推薦應(yīng)用等。之后數(shù)據(jù)分析需要實(shí)時(shí)化，光靠這種“T+1”的離線加工不能夠滿足需求，數(shù)據(jù)越實(shí)時(shí)越有上下文，價(jià)值越大。這個(gè)時(shí)候就有很多計(jì)算前置的技術(shù)被采用，例如Flink。通過Flink直接消費(fèi)Kafka里的事件，通過事件驅(qū)動(dòng)的方式做計(jì)算，由于Flink是分布式的，因此可擴(kuò)展性非常好，它可以通過計(jì)算前置，通過事件驅(qū)動(dòng)的方式，可以把端到端的延遲做到極致。然后我們會(huì)把結(jié)果集也存到一個(gè)介質(zhì)里面，通過Flink加工的結(jié)果集是一個(gè)非常精簡(jiǎn)的結(jié)構(gòu)，一般是以kv6結(jié)構(gòu)為主，放在HBase、Cassandra這樣的系統(tǒng)，這樣的系統(tǒng)對(duì)上提供的大屏報(bào)表是最快的。比如說雙11的大屏，絕對(duì)不能等成交幾千萬(wàn)、幾億條記錄之后再去做統(tǒng)計(jì)，否則查詢性能一定無法滿足。因此，我們一開始都會(huì)加工成如以每秒每個(gè)渠道為粒度的原始數(shù)據(jù)集，原始數(shù)據(jù)集在做大屏分析的時(shí)候，就可以從一個(gè)很大的數(shù)據(jù)集變成一個(gè)很小的數(shù)據(jù)集，性能達(dá)到極致。現(xiàn)在我們看到有處理規(guī)模，有處理速度，這兩者看起來表面上都滿足一定需求，但其實(shí)成本也是不小的。如果想要計(jì)算足夠地快，需要把計(jì)算前置，這樣的話數(shù)據(jù)模型的靈活度就會(huì)減少，因?yàn)槲覀円呀?jīng)通過Flink把所有的數(shù)據(jù)匯聚成一個(gè)結(jié)果集了。例如，如果有些業(yè)務(wù)邏輯一開始沒有定義好，比如剛開始分析的是某三個(gè)維度的聚合，如果后續(xù)想分析第四個(gè)維度的聚合，由于提前沒有計(jì)算好，因此無法進(jìn)行分析，所以這里犧牲了靈活性。此時(shí)就有一些相比HBase更靈活，又比Hive實(shí)時(shí)性更好的技術(shù)會(huì)被采用，例如ClickHouse、Druid。數(shù)據(jù)可以實(shí)時(shí)寫入，寫入之后也提供一定的交互式分析、自助式分析的能我們會(huì)發(fā)現(xiàn)，數(shù)據(jù)處理將同一份數(shù)據(jù)分散在三個(gè)不同的介質(zhì)，包括離線處理的介質(zhì)，近實(shí)時(shí)處理的介質(zhì)和全實(shí)時(shí)處理介質(zhì)。三個(gè)介質(zhì)往往需要三個(gè)團(tuán)隊(duì)來維護(hù)，三個(gè)團(tuán)隊(duì)隨著時(shí)間發(fā)生人員的變動(dòng)，數(shù)據(jù)加工邏輯一定會(huì)有多多少少的調(diào)整，造成的結(jié)果就是，我們會(huì)發(fā)現(xiàn)同一個(gè)指標(biāo)通過三個(gè)不同渠道產(chǎn)生的計(jì)算結(jié)果不一致，這個(gè)事情幾乎每個(gè)公司都會(huì)發(fā)生。這還只是表面的問題，對(duì)于分析師來說更痛苦，他需要使用不同的數(shù)據(jù)，訪問不同的系統(tǒng)，學(xué)習(xí)不同的接口，甚至是有不同的訪問控制機(jī)制，這對(duì)分析師來說就非常不方便。因此，很多公司都要搭一套所謂的數(shù)據(jù)中臺(tái)，通過中臺(tái)來屏蔽底下物理引擎上的不同，這種情況下Presto、Drill這種聯(lián)邦計(jì)算技術(shù)就會(huì)被采用。聯(lián)邦計(jì)算技術(shù)有著二十多年的發(fā)展歷史，從最早期的數(shù)據(jù)信息系統(tǒng)集成到數(shù)據(jù)虛擬化，技術(shù)一直在發(fā)展。這個(gè)技術(shù)是一套數(shù)據(jù)不移動(dòng)、計(jì)算移動(dòng)的技術(shù)，聽起來很美好，但是當(dāng)真正在生產(chǎn)上使用的時(shí)候會(huì)發(fā)現(xiàn)，這套系統(tǒng)的查詢體驗(yàn)是不可預(yù)期的，我們不知道通過系統(tǒng)查詢下去數(shù)據(jù)是快還是慢，因?yàn)樗巡樵兿聣旱讲煌囊?，如果下壓到Hive，就沒那么快，要是下壓到ClickHouse可能就比較快。所以這對(duì)一個(gè)分析師來說，他不知道這個(gè)系統(tǒng)的預(yù)期是什么，