久热免费在线视频,黄色片成年人免费的,九九九九九九国产,久草大香蕉视频在线,国产免费v,欧美后门菊门交,逼特逼网,亚洲色图一区二区

?記得點(diǎn)擊?"大數(shù)據(jù)技術(shù)派",?設(shè)為星標(biāo)
后臺(tái)回復(fù)【加群】，申請(qǐng)加入優(yōu)質(zhì)大數(shù)據(jù)學(xué)習(xí)社群

大家好，我是 大數(shù)據(jù)技術(shù)派。最近看到一篇?來自?阿里巴巴淘系業(yè)務(wù)數(shù)據(jù)團(tuán)隊(duì)?的文章，為大家介紹了?2021年大數(shù)據(jù)開發(fā)的發(fā)展趨勢(shì)，看完之后覺得受益匪淺，于是就想著分享給大家。如果看完覺得有所收獲，記得分享給更多的朋友。

?本文作者：鄭棟，來自阿里巴巴淘系業(yè)務(wù)數(shù)據(jù)團(tuán)隊(duì)

數(shù)據(jù)開發(fā)技術(shù)的3個(gè)方向

未來數(shù)據(jù)開發(fā)技術(shù)方向，我認(rèn)為有三個(gè)，首先是流批一體成為主流開發(fā)模式，其次是代碼自動(dòng)化技術(shù)走向成熟，第三是 OLAP Cubes 終將衰落。

一、流批一體成為主流開發(fā)模式

先說說我看到的數(shù)據(jù)開發(fā)的歷史。

1、“遠(yuǎn)古”時(shí)代，通過寫 SQL 腳本抽取 OLTP 數(shù)據(jù)庫(kù)中數(shù)據(jù)進(jìn)行分析和統(tǒng)計(jì)，大量查詢有可能把數(shù)據(jù)庫(kù)拖掛；

2、OLAP 分析成為數(shù)據(jù)庫(kù)的一項(xiàng)重要能力，這個(gè)時(shí)候，可以寫 SQL，也可以寫Python 代碼等來進(jìn)行數(shù)據(jù)分析和統(tǒng)計(jì)，但面對(duì)不斷增長(zhǎng)的數(shù)據(jù)量，數(shù)據(jù)庫(kù)性能遇到挑戰(zhàn)；

3、Hadoop 技術(shù)的引入和不斷成熟，海量數(shù)據(jù)的離線存儲(chǔ)、計(jì)算和調(diào)度問題得到解決；

4、Storm 讓海量數(shù)據(jù)的實(shí)時(shí)計(jì)算成為可能，促進(jìn)了一大批實(shí)時(shí)數(shù)據(jù)產(chǎn)品的出現(xiàn)，也促進(jìn)了 Lambda數(shù)據(jù)架構(gòu)的出現(xiàn)和流行；

5、Kafka、Spark、Flink 等技術(shù)的流行，整個(gè)數(shù)據(jù)鏈路的全流式計(jì)算成為可能，Kappa 架構(gòu)出現(xiàn)和流行。

從單機(jī) OLAP 到 Lambda 到Kappa 的演進(jìn)，數(shù)據(jù)鏈路上的問題、數(shù)據(jù)計(jì)算層面的問題得到了很好解決。那未來一切皆流式，一切皆實(shí)時(shí)是否可行？是否經(jīng)濟(jì)？我們的數(shù)據(jù)架構(gòu)還存在什么問題？列舉幾個(gè)數(shù)據(jù)領(lǐng)域常見的問題：

● 數(shù)據(jù)產(chǎn)品實(shí)時(shí)和離線模塊同一指標(biāo)數(shù)值不同，因?yàn)橹笜?biāo)計(jì)算離線、實(shí)時(shí)是單獨(dú)開發(fā)，單獨(dú)存儲(chǔ)的，口徑有差異；

● 同一口徑的數(shù)據(jù)指標(biāo)，需要離線和實(shí)時(shí)各開發(fā)一份代碼，因?yàn)楸舜说挠?jì)算引擎不同，編程范式不同，即使都用 SQL 編寫，也很難完全復(fù)用；

● 離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)彼此獨(dú)立存在，帶來雙重的存儲(chǔ)和維護(hù)成本，因?yàn)殡x線和實(shí)時(shí)任務(wù)有不同的數(shù)倉(cāng)分層及存儲(chǔ)體系。

要解決這些問題，需要實(shí)時(shí)和離線計(jì)算的融合，稱作流批一體架構(gòu)。這里說的融合不是用實(shí)時(shí)計(jì)算替代所有離線計(jì)算，離線和實(shí)時(shí)計(jì)算有各自適用的場(chǎng)景，而是對(duì)于數(shù)據(jù)的下游應(yīng)用來說，不用去關(guān)注數(shù)據(jù)來自實(shí)時(shí)還是離線，對(duì)于數(shù)據(jù)開發(fā)工程師來說，不用去關(guān)注開發(fā)的是實(shí)時(shí)還是離線代碼，實(shí)時(shí)、離線只是調(diào)度層面的概念。融合過程根據(jù)現(xiàn)狀的不同可以分兩個(gè)階段，第一是存儲(chǔ)統(tǒng)一，第二是代碼統(tǒng)一。

實(shí)時(shí)、離線的存儲(chǔ)統(tǒng)一

這個(gè)階段，實(shí)時(shí)和離線任務(wù)還是單獨(dú)開發(fā)和執(zhí)行的，但不再區(qū)分存儲(chǔ)介質(zhì)，比如常見的離線結(jié)果存 MySQL，實(shí)時(shí)結(jié)果存 HBase 方案，改成統(tǒng)一存儲(chǔ)到海量數(shù)據(jù)高頻讀寫皆優(yōu)的存儲(chǔ)計(jì)算引擎，如 Apache Kudu & Impala，Alibaba Hologres 等。存儲(chǔ)統(tǒng)一可以解決下游應(yīng)用需要通過不同邏輯對(duì)接實(shí)時(shí)、離線數(shù)據(jù)的問題，例如統(tǒng)一后，同一張表取當(dāng)天的數(shù)據(jù)就是截止目前為止的實(shí)時(shí)數(shù)據(jù)，取昨天的數(shù)據(jù)，就是 T-1 的離線數(shù)據(jù)。另外，也為后續(xù)第二階段的代碼統(tǒng)一做了鋪墊，因?yàn)橐呀?jīng)做到實(shí)時(shí)、離線統(tǒng)一存儲(chǔ)，代碼統(tǒng)一過程對(duì)下游是無感知的。

實(shí)時(shí)、離線的代碼統(tǒng)一

實(shí)時(shí)和離線代碼被統(tǒng)一為一份，通過調(diào)度設(shè)置來區(qū)分是實(shí)時(shí)還是離線批處理。這個(gè)階段存在兩個(gè)挑戰(zhàn)。

● 第一個(gè)挑戰(zhàn)是對(duì)計(jì)算引擎的，需要實(shí)時(shí)計(jì)算引擎兼具批任務(wù)執(zhí)行能力，且做到流批 API 的統(tǒng)一，這塊能力在 Flink Roadmap 里，Blink當(dāng)前已經(jīng)支持的不錯(cuò)。

● 第二個(gè)挑戰(zhàn)是對(duì)數(shù)倉(cāng)架構(gòu)的，實(shí)時(shí)和離線數(shù)倉(cāng)需要統(tǒng)一，存在兩個(gè)問題:（1）新流批一體任務(wù)如何和所替代的老的離線任務(wù)保持統(tǒng)一的上游依賴？這個(gè)問題在存儲(chǔ)、計(jì)算分離的計(jì)算平臺(tái)架構(gòu)下比較容易解決，打通元數(shù)據(jù)，不同計(jì)算引擎訪問統(tǒng)一存儲(chǔ)；（2）流批一體任務(wù)依賴的上游任務(wù)可能未做流批一體，比如為了更精準(zhǔn)的反作弊，需要獨(dú)立開發(fā)離線任務(wù)通過長(zhǎng)周期歷史數(shù)據(jù)做計(jì)算，即如何解決流批一體任務(wù)依賴雙重上游數(shù)據(jù)輸入的問題？這個(gè)問題可以通過對(duì)該上游任務(wù)的結(jié)果表在 Schema 層面做統(tǒng)一來解決，如構(gòu)建鏡像表，根據(jù)調(diào)度模式的不同來映射依賴上游哪份數(shù)據(jù)。

二、代碼自動(dòng)化技術(shù)走向成熟

代碼自動(dòng)化，有兩個(gè)方向，一是代碼的自動(dòng)生成，二是代碼的自動(dòng)優(yōu)化。

代碼的自動(dòng)生成

數(shù)倉(cāng)模型設(shè)計(jì)的實(shí)施工作流包含業(yè)務(wù)和需求調(diào)研，架構(gòu)設(shè)計(jì)，規(guī)范定義，數(shù)據(jù)建模四個(gè)過程。

● 架構(gòu)設(shè)計(jì)指以維度建模為理論基礎(chǔ)，基于業(yè)務(wù)和需求調(diào)研的結(jié)果，進(jìn)行整體數(shù)倉(cāng)設(shè)計(jì)，包含確定數(shù)據(jù)域，定義每個(gè)數(shù)據(jù)域下面的業(yè)務(wù)過程及相關(guān)維度兩件事情；

● 規(guī)范定義指定義指標(biāo)體系，包括原子指標(biāo)，業(yè)務(wù)限定如修飾詞、時(shí)間周期，以及派生指標(biāo)，由原子指標(biāo)和業(yè)務(wù)限定組合而成；

● 數(shù)據(jù)建模主要包括維度及屬性的規(guī)范定義，維表、明細(xì)事實(shí)表和匯總事實(shí)表的模型設(shè)計(jì)。

現(xiàn)在已經(jīng)有數(shù)據(jù)研發(fā)平臺(tái)可以做到可視化數(shù)據(jù)模型設(shè)計(jì)：配置化定義維度、業(yè)務(wù)過程和事實(shí)表元數(shù)據(jù)，自動(dòng)生成維表和事實(shí)表；可視化關(guān)聯(lián)字段的原子指標(biāo)和業(yè)務(wù)限定，配置化定義派生指標(biāo)口徑，自動(dòng)生成匯總表。整個(gè)模型設(shè)計(jì)過程代碼是自動(dòng)生成的，當(dāng)然，一些復(fù)雜指標(biāo)計(jì)算邏輯是通過代碼片段的形式作為配置項(xiàng)提交。

代碼的自動(dòng)生成除了提升開發(fā)效率外，還帶來額外的好處，因?yàn)橛?jì)算代碼是動(dòng)態(tài)生成的，匯總表是否生成真正的物理表，對(duì)用戶是透明的，平臺(tái)可以根據(jù)成本、性能、效率等的考慮，來動(dòng)態(tài)決定是構(gòu)建物理表（也就是OLAP Cube），還是只是一個(gè)視圖，背后是直接下發(fā)查詢到事實(shí)明細(xì)表。

大家有興趣可以了解下阿里的 Dataphin 產(chǎn)品。

代碼的自動(dòng)優(yōu)化

實(shí)時(shí)/離線計(jì)算引擎的不斷發(fā)展演進(jìn)，越來越多人肉在做的優(yōu)化最佳實(shí)踐會(huì)被集成到引擎里，做到在線識(shí)別、自動(dòng)優(yōu)化。

比如 Join 長(zhǎng)尾（傾斜）問題，有一個(gè)優(yōu)化方式是把熱點(diǎn)數(shù)據(jù)提取出來，然后拆分任務(wù)，用大小表的 mapjoin 機(jī)制來提速；比如 count distinct 傾斜問題，可以基于熱點(diǎn)字段做數(shù)據(jù)的二次分發(fā)，將查詢拆成兩層，內(nèi)層子查詢基于二次分發(fā)的數(shù)據(jù)做聚合，外層查詢?cè)侔礋狳c(diǎn)字段聚合。后者已經(jīng)被 Flink partialAgg 機(jī)制所支持，開發(fā)人員使用普通SQL 開發(fā)任務(wù)即可。相信這些有規(guī)可循的優(yōu)化“套路“會(huì)越來越多地被集成到計(jì)算引擎中。

三、OLAP Cubes 終將衰落

OLAP Cube 又稱 Data Cube，工程實(shí)踐上是對(duì)（明細(xì)）數(shù)據(jù)表基于合適的維度組合（基于業(yè)務(wù)確定的維度組合或基于重要維度的笛卡爾積組合）做預(yù)先聚合計(jì)算，典型的計(jì)算機(jī)領(lǐng)域以空間換時(shí)間案例。

這種預(yù)計(jì)算模式，通過為下游應(yīng)用提供穩(wěn)定的查詢性能，長(zhǎng)久來促進(jìn)了數(shù)據(jù)倉(cāng)庫(kù)的發(fā)展，我們通常說的集市層“百花齊放”，快速響應(yīng)業(yè)務(wù)訴求，指的就是 OLAP Cubes 的建設(shè)。數(shù)據(jù)倉(cāng)庫(kù)建模理論，如 Kimball 的維度建模理論，本質(zhì)上就是解決如何基于業(yè)務(wù)的分析訴求，科學(xué)的定義數(shù)據(jù)倉(cāng)庫(kù)中數(shù)據(jù)的組織方式，讓數(shù)據(jù)開發(fā)工程師更好更容易的構(gòu)建 OLAP Cubes。

技術(shù)的限制讓這種模式存在并流行，這種模式反過來又在塑造數(shù)據(jù)團(tuán)隊(duì)的組織形式和職能，成為一種行業(yè)標(biāo)準(zhǔn)。做個(gè)假設(shè)，如果我們當(dāng)前擁有極為充足的計(jì)算能力，很便宜的內(nèi)存資源，還有能高效利用它們提供足夠優(yōu)秀查詢性能的數(shù)據(jù)庫(kù)，我們是否還需要花費(fèi)大量人力基于明細(xì)數(shù)據(jù)去開發(fā)一個(gè)個(gè)應(yīng)用層匯總表來解決多樣的數(shù)據(jù)查詢?cè)V求？

計(jì)算技術(shù)的成熟

● 第一個(gè)因素是摩爾定律，帶來了計(jì)算和存儲(chǔ)成本的不斷降低，公有云的高速發(fā)展，按需購(gòu)買，按量付費(fèi)的模式，進(jìn)一步降低了數(shù)據(jù)的存儲(chǔ)和計(jì)算成本。

● 第二個(gè)因素是類MPP計(jì)算架構(gòu)，列存儲(chǔ)模式數(shù)據(jù)查詢引擎的技術(shù)突破和成熟，同等資源下，能提供成倍甚至幾十倍的查詢性能提升。

從技術(shù)上來看，停止建設(shè) OLAP Cubes，所有請(qǐng)求直連明細(xì)數(shù)據(jù)是可能的。但從業(yè)務(wù)上來看，所有的數(shù)據(jù)查詢請(qǐng)求直連明細(xì)數(shù)據(jù)，存在兩個(gè)潛在問題：1）查詢請(qǐng)求過于復(fù)雜，不易理解，且容易出錯(cuò)；2）數(shù)倉(cāng)匯總層會(huì)變得很薄，業(yè)務(wù)人員要從明細(xì)層取數(shù)，效率變低。

數(shù)據(jù)應(yīng)用的契機(jī)

數(shù)據(jù)應(yīng)用端的兩個(gè)發(fā)展趨勢(shì)一定程度上可以解決上述潛在問題。

● 第一個(gè)趨勢(shì)是BI工具的演化，從提供優(yōu)秀的報(bào)表制作及數(shù)據(jù)可視化能力，到兼具高級(jí)分析的”計(jì)算“能力。用戶不再需要費(fèi)腦力去思考如何寫復(fù)雜的取數(shù) SQL，而是通過 BI 工具的拖拽可視化，以及簡(jiǎn)單易用的計(jì)算字段配置來進(jìn)行數(shù)據(jù)的分析和探索，如 YoY/MoM/DoD 對(duì)比、年/月/日匯總和趨勢(shì)分析、字段級(jí)聯(lián)組織和下鉆分析等，都是通過系統(tǒng)配置自動(dòng)支持，不用寫 SQL。

● 第二個(gè)趨勢(shì)是交互式/對(duì)話式查詢?cè)跀?shù)據(jù)產(chǎn)品上的應(yīng)用越來越多。這類數(shù)據(jù)產(chǎn)品模式的目標(biāo)是提供更大的靈活性給用戶，數(shù)據(jù)產(chǎn)品不僅僅只是看數(shù)，而是用戶參與其中，定義自己的看數(shù)視角。以用戶行為轉(zhuǎn)化漏斗分析舉例，常規(guī)數(shù)據(jù)產(chǎn)品會(huì)首先根據(jù)業(yè)務(wù)訴求定義轉(zhuǎn)化過程重要節(jié)點(diǎn)，數(shù)據(jù)開發(fā)進(jìn)行需求開發(fā)，然后通過數(shù)據(jù)的可視化展現(xiàn)服務(wù)用戶。而交互式分析模式首先是對(duì)轉(zhuǎn)化分析方式進(jìn)行抽象：轉(zhuǎn)化漏斗分析是對(duì)漏斗窗口期內(nèi)，所有滿足限制條件的用戶行為，按既定步驟順序的轉(zhuǎn)化計(jì)算，以漏斗圖的可視化形式展現(xiàn)。產(chǎn)品模塊定義如下：1）漏斗名稱設(shè)置組件，2）漏斗窗口周期設(shè)置組件，3）漏斗步驟設(shè)置模塊，其中每項(xiàng)步驟包含用戶行為選擇和限制條件配置，4）漏斗圖展現(xiàn)組件。至于對(duì)哪些行為做分析，是否需要對(duì)該行為再做條件篩選，關(guān)聯(lián)多長(zhǎng)時(shí)間的數(shù)據(jù)做時(shí)間序列追蹤等，交由用戶選擇，即席查詢。

概括來說，就是使用可視化分析工具替代取數(shù) SQL 開發(fā)，產(chǎn)品化構(gòu)建交互式分析場(chǎng)景替代集市主題表建設(shè)。

數(shù)據(jù)開發(fā)從業(yè)者的3個(gè)核心能力

前面講了數(shù)據(jù)開發(fā)技術(shù)的三個(gè)方向：1）流批一體成為主流開發(fā)模式，2）代碼自動(dòng)化技術(shù)走向成熟，3）OLAP Cubes 終將衰落。對(duì)于數(shù)據(jù)開發(fā)從業(yè)者而言，在技術(shù)的發(fā)展中，如何持續(xù)保持個(gè)人競(jìng)爭(zhēng)力，我認(rèn)為最重要的是如下三項(xiàng)能力。

1、能深入理解你所服務(wù)的業(yè)務(wù)

只有深入理解業(yè)務(wù)，才能真正知道當(dāng)前業(yè)務(wù)處在什么階段，碰到了什么問題，重點(diǎn)目標(biāo)是什么。對(duì)應(yīng)到企業(yè)的數(shù)據(jù)建設(shè)，一定要先解決“為什么”的問題，當(dāng)前數(shù)倉(cāng)服務(wù)的業(yè)務(wù)現(xiàn)狀是什么，為了解決業(yè)務(wù)什么問題，期望達(dá)到什么目標(biāo)，這些是無法靠技術(shù)自動(dòng)化解決的。然后才是模型設(shè)計(jì)、實(shí)施落地。

2、有把數(shù)據(jù)做深的能力

數(shù)據(jù)會(huì)被用來搭建一個(gè)個(gè)分析報(bào)表，服務(wù)一個(gè)個(gè)數(shù)據(jù)產(chǎn)品，好像數(shù)據(jù)產(chǎn)生后，就和數(shù)據(jù)開發(fā)從業(yè)者無關(guān)了，以至于從業(yè)者很多自嘲是“人肉SQL機(jī)器”，是“數(shù)據(jù)搬運(yùn)工”，也經(jīng)常被合作方稱做“ETL工程師”。把數(shù)據(jù)做深的能力是指生產(chǎn)數(shù)據(jù)之外，能持續(xù)去思考從這些數(shù)據(jù)里能獲取什么，不管是通過數(shù)理統(tǒng)計(jì)還是機(jī)器學(xué)習(xí)，探索能否挖掘出推動(dòng)業(yè)務(wù)增長(zhǎng)的洞察，以及行動(dòng)指引，是做“數(shù)據(jù)掘金者”。

3、具備數(shù)據(jù)鏈路的全局觀

數(shù)據(jù)鏈路的全局觀不僅僅是清楚整個(gè)數(shù)據(jù)架構(gòu)是什么樣子，熟悉數(shù)據(jù)是如何流轉(zhuǎn)的，更是能做數(shù)據(jù)鏈路的全局優(yōu)化。如整個(gè)數(shù)據(jù)鏈路的穩(wěn)定性保障，數(shù)據(jù)資產(chǎn)的組織和管理機(jī)制設(shè)計(jì)，數(shù)據(jù)的全鏈路價(jià)值評(píng)估、成本治理，數(shù)據(jù)的質(zhì)量管理及測(cè)試、監(jiān)控機(jī)制的建設(shè)等。

2021年大數(shù)據(jù)開發(fā)發(fā)展趨勢(shì)