背景

在漫長(zhǎng)的數(shù)倉(cāng)建設(shè)過(guò)程中，實(shí)時(shí)數(shù)倉(cāng)與離線數(shù)倉(cāng)分別由不同的團(tuán)隊(duì)進(jìn)行獨(dú)立建設(shè)，有大而廣的離線數(shù)倉(cāng)體系，也有需要追求業(yè)務(wù)時(shí)效，需要建設(shè)實(shí)時(shí)數(shù)倉(cāng)。然而，業(yè)務(wù)數(shù)據(jù)需求和數(shù)據(jù)產(chǎn)品需求中，往往需要把實(shí)時(shí)數(shù)據(jù)與離線數(shù)據(jù)結(jié)合在一起進(jìn)行比對(duì)和分析，但是這兩個(gè)天然不一樣的數(shù)據(jù)存儲(chǔ)和計(jì)算結(jié)構(gòu)，需要同時(shí)開(kāi)發(fā)兩套數(shù)據(jù)模型。在數(shù)據(jù)處理過(guò)程中，實(shí)時(shí)數(shù)倉(cāng)需要使用Blink/Flink 處理，離線需要寫ODPS SQL處理，還有在線計(jì)算模型，需要開(kāi)發(fā)java代碼處理。

如上圖所示，實(shí)時(shí)數(shù)據(jù)與離線數(shù)據(jù)在存儲(chǔ)層、計(jì)算層、服務(wù)層，都是割裂分離、獨(dú)立建設(shè)的。實(shí)時(shí)數(shù)據(jù)，有著增量式計(jì)算的特性，需要快速的流轉(zhuǎn)與計(jì)算，它主要以DataHub、Flink、Hbase等異構(gòu)系統(tǒng)做為支撐，串聯(lián)形成一個(gè)完整實(shí)時(shí)計(jì)算全鏈路。而離線數(shù)據(jù)，是定時(shí)、批量計(jì)算的特性，由存儲(chǔ)計(jì)算統(tǒng)一的ODPS系統(tǒng)做為支撐。它們除了計(jì)算鏈路的差異，還有著數(shù)據(jù)處理的邏輯差異：

1. 流批處理不能復(fù)用，ODPS和Blink/Flink的SQL標(biāo)準(zhǔn)不一致，他們的底層調(diào)度和數(shù)據(jù)處理邏輯也有根本的差別，一個(gè)是以MR作為核心的批處理方式，一個(gè)是以Flink/Blink為核心的流處理。
2. 有些流批處理場(chǎng)景需要調(diào)用HSF接口，調(diào)用HSF接口，在Java Spring環(huán)境里，是信手拈來(lái)的事情，但到了ODPS/Flink環(huán)境里，就變得額外的一個(gè)大挑戰(zhàn)，甚至不可實(shí)現(xiàn)，因?yàn)樵贠DPS/Flink是無(wú)法加載或者極難使用Spring容器的，這就會(huì)讓開(kāi)發(fā)在面對(duì)復(fù)雜流處理場(chǎng)景，更傾向使用自己熟悉的Java環(huán)境，但同時(shí)也意味失去ODPS/Flink那種貼近業(yè)務(wù)表達(dá)的SQL表達(dá)。
3. 計(jì)算處理除了流批處理，還更廣泛存在在線交互計(jì)算，這個(gè)和流處理異步處理還不太一樣，是需要同步計(jì)算并返回結(jié)果，這通常是在Java環(huán)境開(kāi)發(fā)HSF接口，但如果你要對(duì)外同時(shí)提供三種能力：流計(jì)算、批計(jì)算和在線計(jì)算的時(shí)候，就面臨需要三端開(kāi)發(fā)，流計(jì)算和批計(jì)算尚且還有SQL，雖然不太一致，但至少大同小異，但在線交互計(jì)算就是需要純Java開(kāi)發(fā)了，將SQL翻譯成Java代碼可是個(gè)不小的挑戰(zhàn)。

Unify SQL VS 流批一體

面對(duì)三種計(jì)算模式，較低的研發(fā)效率、不可控的數(shù)據(jù)質(zhì)量，以及臃腫數(shù)據(jù)接口服務(wù)的困境，三端（流計(jì)算、批計(jì)算、在線計(jì)算）一體計(jì)算的想法自然油然而生，在20年做價(jià)格力業(yè)務(wù)時(shí)候，我就一直思考有什么解法，其實(shí)，這個(gè)也是大數(shù)據(jù)架構(gòu)經(jīng)常面臨的問(wèn)題，業(yè)界達(dá)成共識(shí)，可以歸納兩種方案：

?  流批一體計(jì)算

同一個(gè)引擎承載流、批兩種計(jì)算模式，在流計(jì)算模式下進(jìn)行實(shí)時(shí)數(shù)據(jù)計(jì)算，在批計(jì)算模式下進(jìn)行離線數(shù)據(jù)計(jì)算。

流批一體計(jì)算的典型架構(gòu)是：Flink + Kappa架構(gòu)。Flink可以實(shí)現(xiàn)基于SQL的流批一體的計(jì)算表達(dá)，復(fù)雜計(jì)算通過(guò)Java應(yīng)用承接，價(jià)格力計(jì)算架構(gòu)就是典型這種架構(gòu)，但是這種架構(gòu)存在以下問(wèn)題：

• 沒(méi)有解決在線交互計(jì)算

Flink解決了流計(jì)算、批計(jì)算一體的能力，這兩種都是異步處理，只是時(shí)效不同而已，但沒(méi)有解決在線計(jì)算的能力，如果要提供在線計(jì)算能力，不得不在以下兩個(gè)方案選擇：

1. 通過(guò)Java應(yīng)用提供同步計(jì)算接口，這樣就存在兩套邏輯：一個(gè)是Flink實(shí)現(xiàn)的流批處理，另一個(gè)是Java實(shí)現(xiàn)的在線處理。
2. 提供兩個(gè)接口，一個(gè)接口是發(fā)起計(jì)算請(qǐng)求，將計(jì)算請(qǐng)求交到Flink處理后，再提供一個(gè)輪訓(xùn)查詢接口，查詢計(jì)算好后的數(shù)據(jù)，這個(gè)方案至少在計(jì)算上做到一套代碼，但這種同步轉(zhuǎn)異步處理的方案勢(shì)必會(huì)影響產(chǎn)品的設(shè)計(jì)。

• Flink的批處理吞吐量

Flink實(shí)現(xiàn)批處理，其實(shí)是有點(diǎn)一廂情愿，為啥這么說(shuō)，因?yàn)槠渫掏乱?guī)模，跟MR批計(jì)算（ODPS）完全不是一個(gè)量級(jí)，如果Flink真能實(shí)現(xiàn)和ODPS完全對(duì)等的吞吐規(guī)模和資源成本，那完全不需要ODPS什么事了，但現(xiàn)實(shí)是，對(duì)于一些只有批量處理場(chǎng)景的（比如特征預(yù)處理、統(tǒng)計(jì)計(jì)算），ODPS仍然是第一優(yōu)先選擇，只有當(dāng)面臨流批同時(shí)存在的場(chǎng)景時(shí)候，并且對(duì)批處理規(guī)模要求不大時(shí)候，F(xiàn)link的確提供非常不錯(cuò)的一體化解決方案。

?  Unify SQL

同一SQL代碼通過(guò)自動(dòng)化轉(zhuǎn)義，翻譯到流計(jì)算引擎和批計(jì)算引擎上進(jìn)行流、批計(jì)算，也包括翻譯到HSF接口代碼，提供在線交互計(jì)算能力。

Flink的流批一體架構(gòu)非常優(yōu)秀，能解決90%的流批一體問(wèn)題，但不幸的是，我們有些業(yè)務(wù)場(chǎng)景（典型的價(jià)格計(jì)算場(chǎng)景），遠(yuǎn)不是Flink寫寫SQL可以解決的：

1. 整個(gè)電商是個(gè)非常復(fù)雜的業(yè)務(wù)體系，就以我所處在的營(yíng)銷域里，就要面對(duì)招商模型、投放模型、活動(dòng)模型、權(quán)益等等，這些都遠(yuǎn)不是一個(gè)單一系統(tǒng)可以承接的，也不是一個(gè)單一團(tuán)隊(duì)可以承接的，阿里針對(duì)這樣復(fù)雜的業(yè)務(wù)，設(shè)計(jì)了HSF這樣微服務(wù)電商架構(gòu)，但是Flink和電商這樣的Java技術(shù)棧明顯是割裂的，怎么結(jié)合兩種體系架構(gòu)，一方面發(fā)揮電商的微服務(wù)架構(gòu)的紅利，一方面又能利用到Flink的SQL流批處理能力，考慮到Flink本身的局限性，與其讓Flink支持HSF，不如讓Java環(huán)境支持Flink SQL，換句話說(shuō)，設(shè)計(jì)一個(gè)SQL引擎，它能通過(guò)sql的流處理方式，處理Java對(duì)象，將流引擎嵌入到Java里，隨調(diào)隨用。
2. Flink的批引擎，在面對(duì)T級(jí)離線數(shù)據(jù)批量處理，是非常耗資源，幾乎不可用，正如上面所講的，F(xiàn)link批處理的吞吐量遠(yuǎn)不及ODPS的MR批處理，那么，我們?yōu)楹尾蛔屵@樣計(jì)算仍然交接給ODPS處理，但是，ODPS和Flink的SQL標(biāo)準(zhǔn)不一致，需要兩端開(kāi)發(fā)，現(xiàn)在問(wèn)題變成：怎么統(tǒng)一ODPS和Flink的開(kāi)發(fā)，說(shuō)的再通俗點(diǎn)，我們可不可以在ODPS和Flink上面架設(shè)一層統(tǒng)一Unify SQL，這個(gè)SQL引擎可以翻譯成ODPS或者Flink能理解的處理（ODPS翻譯成MR程序，F(xiàn)link翻譯成Stream Operator）方式，抹平ODPS和Flink的SQL語(yǔ)義差別。
3. 如果僅僅是抹平ODPS和Flink的SQL差異，帶來(lái)的收益其實(shí)并不大，但是其統(tǒng)一SQL表達(dá)計(jì)算的設(shè)計(jì)，是可以進(jìn)一步擴(kuò)寬其應(yīng)用范圍，比如在線交互計(jì)算，或者說(shuō)，我們可以進(jìn)一步打造統(tǒng)一計(jì)算引擎，包括編排不同模式的計(jì)算能力，比如：有些場(chǎng)景對(duì)時(shí)效要求比較高，我們可以調(diào)度Flink計(jì)算，對(duì)時(shí)效沒(méi)有要求，但數(shù)據(jù)量巨大，可以只調(diào)度離線計(jì)算，有些需要提供HSF接口，就調(diào)度應(yīng)用啟動(dòng)spring接口。

Unify SQL Engine

淘系價(jià)格計(jì)算引擎，以Flink + Kappa為核心的數(shù)據(jù)架構(gòu)，關(guān)于這種數(shù)據(jù)架構(gòu)演進(jìn)，可以參考我其他文章，三種計(jì)算模式的疊加是價(jià)格服務(wù)計(jì)算引擎的常態(tài)模式，他們都在各自核心計(jì)算發(fā)揮自己最大的優(yōu)勢(shì)：

1. ODPS：離線批量計(jì)算引擎，核心優(yōu)勢(shì)，非常高的計(jì)算吞吐量，但時(shí)效差，有面向MR和SQL編程模式，業(yè)務(wù)和BI友好，主要用在數(shù)據(jù)預(yù)處理、離線特征加工、常見(jiàn)維表ETL等。
2. Flink：流式處理引擎，核心優(yōu)勢(shì)，低延遲計(jì)算，時(shí)效好，極高的容錯(cuò)和高可靠性，但吞吐量相比ODPS一般，有面向Stream API和SQL API的編程模式，業(yè)務(wù)和BI友好，主要用在實(shí)時(shí)數(shù)據(jù)加工（優(yōu)惠、訂單等）、消息預(yù)處理等
3. Java計(jì)算：核心優(yōu)勢(shì)，豐富的電商Java HSF接口，復(fù)雜的領(lǐng)域模型，面向?qū)ο笤O(shè)計(jì)，開(kāi)發(fā)友好，但是業(yè)務(wù)和BI不友好，容錯(cuò)和可靠性依賴開(kāi)發(fā)設(shè)計(jì)，延遲和吞吐量也高度依賴開(kāi)發(fā)設(shè)計(jì)。

那么如何整合這3個(gè)不同計(jì)算架構(gòu)，F(xiàn)link提出一個(gè)引擎承接所有計(jì)算模式，也就是Flink的流批一體引擎，但這帶來(lái)的問(wèn)題就是，不同計(jì)算模式，底層的引擎本身就很難完全周全到，與其去統(tǒng)一計(jì)算引擎，為何不統(tǒng)一表達(dá)和調(diào)度，而把真正的計(jì)算下放到各自計(jì)算引擎，這就是Unify Engine的核心思想。

?  SQL引擎技術(shù)

在實(shí)現(xiàn)三端一體化時(shí)候，有個(gè)核心技術(shù)難點(diǎn)，就是SQL引擎，很多數(shù)據(jù)產(chǎn)品都自帶自己的SQL引擎，F(xiàn)link內(nèi)部有SQL引擎，ODPS內(nèi)部有C++實(shí)現(xiàn)的SQL引擎，Hive也有，Mysql內(nèi)部也有SQL解析引擎，這些SQL引擎都高度集成到各自的存儲(chǔ)和計(jì)算里，如果你說(shuō)要找個(gè)獨(dú)立的可用在Java環(huán)境的SQL引擎，市面上有是有，不過(guò)要么是非常復(fù)雜的calcite sql引擎，要么是非常簡(jiǎn)單的select * 簡(jiǎn)易sql引擎，能做的事情非常少，開(kāi)箱即用的幾乎沒(méi)有。但Unify SQL引擎又是實(shí)現(xiàn)三端一體化的核心組件，沒(méi)有它，其他什么事情都無(wú)從談起。從無(wú)設(shè)計(jì)一個(gè)SQL引擎成本是非常高的，其中不說(shuō)復(fù)雜的語(yǔ)法解析，生成AST語(yǔ)法樹，就單單SQL邏輯計(jì)劃優(yōu)化，就是非常復(fù)雜，幸運(yùn)的是，業(yè)界是存在一個(gè)可以二次開(kāi)發(fā)的SQL引擎，就是calcite SQL引擎，其實(shí)，很多SQL引擎都是基于calcite二次開(kāi)發(fā)的，比如Flink、Spark內(nèi)部的SQL解析引擎就是基于calcite二次開(kāi)發(fā)的，我們?cè)O(shè)計(jì)的SQL引擎也是基于calcite的。Calcite 使用了基于關(guān)系代數(shù)的查詢引擎，聚焦在關(guān)系代數(shù)的語(yǔ)法分析和查詢邏輯的規(guī)劃，通過(guò)calcite提供的SQL API（解析、驗(yàn)證等）將它們轉(zhuǎn)換成關(guān)系代數(shù)的抽象語(yǔ)法樹，并根據(jù)一定的規(guī)則或成本估計(jì)對(duì)AST關(guān)系進(jìn)行優(yōu)化，最后進(jìn)一步生成ODPS/Flink/Java環(huán)境可以理解的執(zhí)行代碼。calcite的主要功能：

1. SQL解析：Calcite的SQL解析是通過(guò)JavaCC實(shí)現(xiàn)，使用JavaCC變成SQL語(yǔ)法描述文件，將SQL解析成未經(jīng)校驗(yàn)（unvalided AST）的AST語(yǔ)法樹。
2. SQL校驗(yàn)：無(wú)狀態(tài)校驗(yàn)，即驗(yàn)證SQL語(yǔ)句是否符合規(guī)范；有狀態(tài)校驗(yàn)，通過(guò)和元數(shù)據(jù)驗(yàn)證SQL的schema，字段，UDF是否存在，以及類型是否匹配等。這一步生成的是未經(jīng)優(yōu)化的RelNode（邏輯計(jì)劃樹）
3. SQL查詢優(yōu)化：對(duì)上面步驟的輸出（RelNode），進(jìn)行優(yōu)化，這一過(guò)程會(huì)循環(huán)使用優(yōu)化器（RBO規(guī)則優(yōu)化器和CBO成本優(yōu)化器），在保持語(yǔ)義等價(jià)的基礎(chǔ)上，生成執(zhí)行成本最低的SQL邏輯樹（Lo）

至于calcite的比較詳細(xì)的原理，可以詳解：Apache Calcite 處理流程詳解（地址：https://xie.infoq.cn/article/1df5a39bb071817e8b4cb4b29），這里不詳解了。有了calcite，解決了SQL->邏輯樹，但是真正執(zhí)行SQL計(jì)算的，還需要進(jìn)一步將邏輯數(shù)轉(zhuǎn)換成物理執(zhí)行樹（Physical Exec DAG），在這個(gè)DAG，是包含可執(zhí)行的Java代碼（JavaCode）片段，最后下發(fā)到不同執(zhí)行環(huán)境，會(huì)被進(jìn)一步串聯(lián)可被環(huán)境執(zhí)行的鏈路，比如在ODPS環(huán)境，會(huì)生成MR代碼，在Flink環(huán)境，會(huì)被轉(zhuǎn)換成Stream Operator，在Java環(huán)境，會(huì)被轉(zhuǎn)換成Collector Chain，在Spring環(huán)境，會(huì)被轉(zhuǎn)換成Bean組件。

PS：如果你們看過(guò)Flink源碼，對(duì)上面流程會(huì)非常眼熟，是的，Unify SQL Engine不是從頭設(shè)計(jì)的，是基于Flink 1.12源碼魔改的，其中Parse和下面要說(shuō)的Codegen技術(shù)都是直接參考了Flink設(shè)計(jì)，當(dāng)然說(shuō)是魔改的，就是還有大量代碼需要基于上面做二次開(kāi)發(fā)，比如從執(zhí)行DAG到各個(gè)環(huán)境真正可執(zhí)行的MR/Bean/Stream。

?  Codegen技術(shù)

在SQL解析后，經(jīng)過(guò)邏輯優(yōu)化器和物理優(yōu)化器，產(chǎn)生的PhyscialRel物理計(jì)劃樹，包含大量的復(fù)雜數(shù)據(jù)邏輯處理，比如SQL常見(jiàn)的CASE WHEN語(yǔ)句，常見(jiàn)的做法是給所有符號(hào)運(yùn)算定義個(gè)父類（比如ExecNode），實(shí)際運(yùn)行時(shí)，委派給真實(shí)的子類運(yùn)行，這涉及到大量虛擬函數(shù)表的搜尋，最終這種分支指令一定程度阻止指令的管道化和并行執(zhí)行，導(dǎo)致這種搜尋成本比函數(shù)本身執(zhí)行成本還高。

Codegen技術(shù)就是專門針對(duì)這樣的場(chǎng)景孕育而生，行業(yè)做的比較出色的Codegen技術(shù)，有LLVM和Janino，LLVM主要針對(duì)編譯器，而Java的代碼codegen通常使用Janino，Janino做為一種小巧快速的Java編譯器，不僅能像Javac將一組java文件編譯成Class文件，也可以將Java表達(dá)式、語(yǔ)句塊、類定義塊或者Java文件進(jìn)行編譯，直接加載成ByteCode，并在同一個(gè)JVM里進(jìn)行運(yùn)行。

Unify SQL Engine也使用Janino用來(lái)做CodeGen技術(shù)，并有效地提升代碼的執(zhí)行效率。關(guān)于Janino更多內(nèi)容，可以參考這篇文章：Java CodeGen編譯器Janino（地址：https://zhuanlan.zhihu.com/p/407857568）。這里有采用Codegen和不采用Codegen的技術(shù)性能對(duì)比：

可以看出當(dāng)表達(dá)式越復(fù)雜時(shí)，使用Janino的效果就會(huì)體現(xiàn)越明顯。

?  有狀態(tài)計(jì)算

通常計(jì)算分為無(wú)狀態(tài)計(jì)算和有狀態(tài)計(jì)算，無(wú)狀態(tài)計(jì)算一般是過(guò)濾、project映射，其每次計(jì)算依賴當(dāng)前數(shù)據(jù)上下文，相互獨(dú)立的，不依賴前后數(shù)據(jù)，因此，不需要有額外的存儲(chǔ)保存中間計(jì)算結(jié)果或者緩存數(shù)據(jù)，但還有一類是有狀態(tài)計(jì)算，除了當(dāng)前數(shù)據(jù)上下文，還需要依賴之前計(jì)算的中間態(tài)數(shù)據(jù)，典型的比如：

1. sum求和：需要有存儲(chǔ)保存當(dāng)前求和的結(jié)果，當(dāng)有新的數(shù)據(jù)過(guò)來(lái)，結(jié)合當(dāng)前中間結(jié)果基礎(chǔ)上累加
2. 去重：去掉之前重復(fù)出現(xiàn)的數(shù)據(jù)，需要保存之前已經(jīng)處理過(guò)哪些數(shù)據(jù)，然后有新的數(shù)據(jù)需要計(jì)算，要和保存的數(shù)據(jù)比較是否重復(fù)
3. 排序：需要有存儲(chǔ)保存之前排好的數(shù)據(jù)，當(dāng)有新的數(shù)據(jù)過(guò)來(lái)，會(huì)變更之前的排序結(jié)果，并diff后，將重新排序后有變動(dòng)的數(shù)據(jù)重新發(fā)到下游

可見(jiàn)，當(dāng)需要進(jìn)行有狀態(tài)計(jì)算，需要有后背存儲(chǔ)來(lái)承載中間狀態(tài)結(jié)果，Unify SQL Engine是支持3種后背存儲(chǔ)：內(nèi)存、Redis和Hbase：

1. 內(nèi)存State是只保存到內(nèi)存，一旦重新啟動(dòng)，就丟失歷史數(shù)據(jù)，內(nèi)存State通常用在單機(jī)有狀態(tài)計(jì)算，并且容忍數(shù)據(jù)丟失。一般用在ODPS的MR程序里，因?yàn)橐淮蜯R調(diào)用狀態(tài)計(jì)算，只需要當(dāng)前執(zhí)行上下文的累計(jì)結(jié)果，不需要放在全局緩存，不同批次之間的累計(jì)是通過(guò)MR API之間傳輸，內(nèi)存State完全夠用。
2. Redis：對(duì)于需要跨多機(jī)狀態(tài)計(jì)算，就會(huì)用到Redis作為后背存儲(chǔ)，Unify SQL Engine在Java環(huán)境里默認(rèn)是使用這個(gè)作為后背存儲(chǔ)。Redis后備存儲(chǔ)一般用在Java計(jì)算環(huán)境，數(shù)據(jù)會(huì)流經(jīng)過(guò)不同生產(chǎn)機(jī)器，計(jì)算的中間結(jié)果需要全局可見(jiàn)。
3. Hbase：如果狀態(tài)數(shù)據(jù)超過(guò)100G，可以選擇Hbase做為后背存儲(chǔ)，性能雖然比不上Redis，但狀態(tài)可以保存很長(zhǎng)時(shí)間，對(duì)于長(zhǎng)周期的狀態(tài)計(jì)算非常有用。

?  JOIN語(yǔ)義

Flink是可以支持雙流Join，但是Flink的雙流Join的語(yǔ)義完全照搬了SQL的JOIN語(yǔ)義，就是一邊的數(shù)據(jù)會(huì)和另一邊的所有數(shù)據(jù)JOIN，這個(gè)對(duì)于離線分析沒(méi)有任何問(wèn)題，但是對(duì)于實(shí)時(shí)計(jì)算是會(huì)存在重復(fù)計(jì)算，在有些場(chǎng)景還有損業(yè)務(wù)邏輯，比如：當(dāng)訂單流去雙流JOIN優(yōu)惠表的時(shí)候，就會(huì)出現(xiàn)這個(gè)問(wèn)題，優(yōu)惠表的數(shù)據(jù)是會(huì)不停變化的，但是我們希望以快照數(shù)據(jù)做為JOIN的依據(jù)，而不是把優(yōu)惠變更的數(shù)據(jù)都復(fù)現(xiàn)一遍，Unify SQL Engine是做到后者語(yǔ)義的，也就是SNAPSHOT JOIN，也是業(yè)務(wù)場(chǎng)景常見(jiàn)的語(yǔ)義：

一些想法

?  統(tǒng)一調(diào)度

Unify SQL Engine現(xiàn)在已經(jīng)可以做到將SQL翻譯成不同執(zhí)行環(huán)境可運(yùn)行的任務(wù)，通過(guò)Unify SQL統(tǒng)一表達(dá)了不同環(huán)境的邏輯計(jì)算，但是離最終我們期望的還很遠(yuǎn)，其中一點(diǎn)就是要做到統(tǒng)一調(diào)度和分配，現(xiàn)在不同環(huán)境的協(xié)調(diào)是需要開(kāi)發(fā)者自己去分配和調(diào)度，比如哪些計(jì)算需要下發(fā)到ODPS MR計(jì)算，哪些是在Java環(huán)境運(yùn)行，未來(lái)我們希望這些分配也是可以做到統(tǒng)一調(diào)度和運(yùn)行，包括全量和增量計(jì)算的自動(dòng)協(xié)同，離線和在線數(shù)據(jù)協(xié)同等

?  資源成本

通過(guò)Unify SQL Engine，開(kāi)發(fā)者可以自己選擇底層的計(jì)算引擎，對(duì)于數(shù)據(jù)量較大但對(duì)時(shí)效要求不高的場(chǎng)景，可以選擇在ODPS計(jì)算，對(duì)于時(shí)效有要求同時(shí)數(shù)據(jù)規(guī)?？山邮軆?nèi)，可以選擇在Flink調(diào)度，對(duì)于計(jì)算邏輯復(fù)雜，需要大量依賴HSF接口，可以選擇在Java環(huán)境啟動(dòng)，選擇自己最容易接受的資源和成本，承接其計(jì)算語(yǔ)義。

同時(shí)，也是希望通過(guò)Unify SQL Engine最大化的利用計(jì)算資源，比如Java應(yīng)用，很多情況下是空閑狀態(tài)的，CPU利用率是比較低下的，比如一些流計(jì)算可以下發(fā)到這些空閑的應(yīng)用，并占用非常小的CPU（比如5%以內(nèi)），整體的資源利用率就提升了，還比如，F(xiàn)link計(jì)算資源是比較難申請(qǐng)，那么可以選擇在Java環(huán)境里計(jì)算（Java相比Flink環(huán)境缺乏一些特性，比如Exactly once語(yǔ)義）等等。

團(tuán)隊(duì)介紹

我們是大淘寶技術(shù)營(yíng)銷工具團(tuán)隊(duì)，承擔(dān)天貓各種大促活動(dòng)，開(kāi)發(fā)面向消費(fèi)者端/商家端營(yíng)銷產(chǎn)品，負(fù)責(zé)雙11核心玩法、價(jià)格管控、權(quán)益發(fā)放的核心業(yè)務(wù)團(tuán)隊(duì)。這里覆蓋全域營(yíng)銷產(chǎn)品，擁有億級(jí)用戶規(guī)模、千萬(wàn)商家規(guī)模，這里充滿技術(shù)挑戰(zhàn)，有復(fù)雜的業(yè)務(wù)場(chǎng)景、T級(jí)大規(guī)模的數(shù)據(jù)處理，千萬(wàn)級(jí)的QPS、秒級(jí)億數(shù)據(jù)實(shí)時(shí)處理等。