开发效率提升15倍！批流融合实时平台在好未来的应用实践
摘要：本文由好未來資深數(shù)據(jù)平臺工程師毛祥溢分享，主要介紹批流融合在教育行業(yè)的實踐。內(nèi)容包括兩部分，第一部分是好未來在做實時平臺中的幾點思考，第二部分主要分享教育行業(yè)中特有數(shù)據(jù)分析場景。大綱如下：
背景介紹
好未來 T-Streaming 實時平臺
K12 教育典型分析場景
展望與規(guī)劃
1.背景介紹
好未來介紹
好未來是一家 2003 年成立教育科技公司，旗下有品牌學而思，現(xiàn)在大家聽說的學而思培優(yōu)、學而思網(wǎng)校都是該品牌的衍生，2010 年公司在美國納斯達克上市，2013 年更名為好未來。2016 年，公司的業(yè)務(wù)范圍已經(jīng)覆蓋負一歲到 24 歲的用戶。目前公司主營業(yè)務(wù)單元有智慧教育、教育領(lǐng)域的開放平臺、K12 教育以及海外留學等業(yè)務(wù)。
好未來數(shù)據(jù)中臺全景圖
上圖為好未來數(shù)據(jù)中臺的全景圖，主要分為三層：
● 第一層是數(shù)據(jù)賦能層
● 第二層是全域數(shù)據(jù)層
● 第三層是數(shù)據(jù)開發(fā)層
首先，數(shù)據(jù)賦能層。主要是商業(yè)智能、智慧決策的應(yīng)用，包括一些數(shù)據(jù)工具、數(shù)據(jù)能力以及專題分析體系，數(shù)據(jù)工具主要包括埋點數(shù)據(jù)分析工具、AB 測試工具、大屏工具；數(shù)據(jù)能力分析主要包括未來畫像服務(wù)、未來增長服務(wù)、未來用戶服務(wù)以及新校區(qū)的選址服務(wù)；專題分析體系主要包企業(yè)經(jīng)營類專題分析等等。
其次，數(shù)據(jù)全域?qū)印Ｎ覀兤谕麑⑷瘓F所有的事業(yè)部的數(shù)據(jù)進行深入的拉通和融合，打通不同業(yè)務(wù)線、產(chǎn)品線的用戶池，從而盤活全集團的數(shù)據(jù)。具體的手段是 IDMapping，將設(shè)備 id、自然人、家庭三個層級的 id 映射關(guān)系挖掘出來，將不同產(chǎn)品上的用戶數(shù)據(jù)關(guān)聯(lián)起來。這樣就能夠形成一個打的用戶池，方便我們更好的賦能用戶。
最后，數(shù)據(jù)開發(fā)層。數(shù)據(jù)開發(fā)通過一些列的平臺承載了全集團所有的數(shù)據(jù)開發(fā)工程，主要包括數(shù)據(jù)集成、數(shù)據(jù)開發(fā)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)服務(wù)、數(shù)據(jù)治理等服務(wù)。我們今天要分享的實時平臺就是在數(shù)據(jù)開發(fā)中。
2.好未來 T-Streaming 實時平臺
實時平臺構(gòu)建前的訴求
實時平臺在構(gòu)建之初，我們梳理了四個重要的訴求。
● 第一個訴求是期望有一套統(tǒng)一的集群，通過提供多租戶，資源隔離的方式提高資源利用率，解決多個事業(yè)部多套集群的問題。
● 第二個訴求是期望通過平臺的方式降低實時數(shù)據(jù)開發(fā)的門檻，從而能夠覆蓋更多的開發(fā)者。
● 第三個訴求是期望能夠提供通用場景的解決解方案，提高項目的復(fù)用性，避免每個事業(yè)部都開發(fā)相同場景的分析工具。
● 第四個訴求是對作業(yè)進行全方位的生命周期管理，包括元數(shù)據(jù)和血緣，一旦有一個作業(yè)出現(xiàn)異常，我們可以快速分析和定位影響范圍。
實時平臺功能概述
現(xiàn)在我們平臺已經(jīng)是一個一站式的實時數(shù)據(jù)分析平臺，包括了數(shù)據(jù)集成、數(shù)據(jù)開發(fā)、作業(yè)保障、資源管理、數(shù)據(jù)安全等功能。
● 在數(shù)據(jù)集成方面，我們支持數(shù)據(jù)庫、埋點數(shù)據(jù)、服務(wù)端日志數(shù)據(jù)的集成，為了能夠提高數(shù)據(jù)集成的效率，我們提供了很多的通用模板作業(yè)，用戶只需要配置即可快速實現(xiàn)數(shù)據(jù)的集成。
● 在數(shù)據(jù)開發(fā)方面，我們支持兩種方式的作業(yè)開發(fā)，一種是 Flink SQL 作業(yè)開發(fā)、一種是 Flink Jar 包托管，在 Flink SQL 開發(fā)上我們內(nèi)置了很多 UDF 函數(shù)，比如可以通過 UDF 函數(shù)實現(xiàn)維表 join，也支持用戶自定義 UDF，并且實現(xiàn)了 UDF 的熱加載。除此之外，我們也會記錄用戶在作業(yè)開發(fā)過程中的元數(shù)據(jù)信息，方便血緣系統(tǒng)的建設(shè)。
● 在作業(yè)保障方面，我們支持作業(yè)狀態(tài)監(jiān)控、異常告警、作業(yè)失敗之后的自動拉起，作業(yè)自動拉起我們會自動選擇可用的 checkpoint 版本進行拉起，同時也支持作業(yè)在多集群之間的切換。
● 在資源管理方面，我們支持平臺多租戶，每個租戶使用 namespace 進行隔離、實現(xiàn)了不同事業(yè)部、不同用戶、不同版本的 Flink 客戶端隔離、實現(xiàn)了計算資源的隔離。
● 在數(shù)據(jù)安全方面，我們支持角色權(quán)限管理、表級別權(quán)限管理、操作審計日志查詢等功能。
以上就是我們平臺的功能，在賦能業(yè)務(wù)的同時，我們也還在快速迭代中，期望平臺簡單好用，穩(wěn)定可信賴。
實時平臺的批流融合
接下來說一下平臺建設(shè)中的一些實踐，第一個是批流融合。
我們先理清楚批流融合是什么？
批流融合可以分為兩個概念，一個是 Flink 提出的批流融合，具體的理解就是一個 Flink SQL 既可以作用于流數(shù)據(jù)、也可以作用于批數(shù)據(jù)，通過保證計算引擎一致從而減少結(jié)果數(shù)據(jù)的差異，這是一個技術(shù)層面上的批流融合。另個一概念是我們內(nèi)部提出來的，那就是架構(gòu)層面的批流融合。具體的操作手法就是通過 Flink 作業(yè)保證數(shù)據(jù)倉庫 ODS 層的實時化，然后提供小時級別、分鐘級別的調(diào)度，從而提高數(shù)據(jù)分析的實時化。
為什么我們會提出架構(gòu)上的批流融合，主要我們看到行業(yè)發(fā)展的兩個趨勢。
● 第一個趨勢是數(shù)據(jù)集成的實時化和組件化，比如 Flink 集成 Hive、Flink CDC 的持續(xù)完善和增強，這樣我們做數(shù)據(jù)集成的時候就會變得非常簡單。
● 第二個趨勢是實時 OLAP 引擎越來越成熟，比如 Kudu+impala、阿里云的 Hologres、湖倉一體的方案。
這兩個趨勢讓用戶開發(fā)實時數(shù)據(jù)會變得越來越簡單，用戶只需要關(guān)注 SQL 本身就可以。
如上圖所示，我們有三個類型的實時數(shù)倉，一個是基于 Hive 的、一個是基于實時 OLAP 引擎的、一個是基于 Kafka 的。其中，藍色線條就是我們 ODS 層實時化的具體實現(xiàn)。我們提供了一個統(tǒng)一的工具，可以將實時的將數(shù)據(jù)寫入到 Hive、實時 OLAP 引擎、當然還有 Kafka。這個工具使用起來比較簡單，如果是 MySQL 數(shù)據(jù)的同步，用戶只需要輸入數(shù)據(jù)庫名稱和表名就可以了。
通過 ODS 層實時化的工具，我們就可以在 Hive、實時 OLAP 引擎、Kafka 中構(gòu)建實時數(shù)倉。
● 如果是 Hive 實時數(shù)倉，我們會使用 Flink 將實時的增量數(shù)據(jù)寫入到 ODS 層，然后提供一個定時 merge 的腳本，用來 merge 增量數(shù)據(jù)和歷史數(shù)據(jù)，從而保證 ODS 層的數(shù)據(jù)是最新最全的。配合 airflow 小時級別的調(diào)度能力，用戶就可以得到一個小時級別的數(shù)倉了。
● 如果是類似于 Kudu / Hologres 這樣的實時 OLAP 引擎，我們會先把離線數(shù)據(jù)從 Hive 中導(dǎo)入到實時 OLAP 引擎中，然后使用 Flink 將實時的增量數(shù)據(jù)寫入到 ODS 層，寫入的方式推薦使用 upsert 這樣的特性，這樣用戶就能夠得到一個純實時的數(shù)倉了。配合 airflow 分鐘級別的調(diào)度能力，用戶就可以得到一個分鐘級別的數(shù)倉了。
● 基于 Kafka 構(gòu)建實時數(shù)倉，就是非常經(jīng)典的架構(gòu)了，開發(fā)成本也比較高一些，除了必須要秒級更新的分析場景，我們不太建議用戶使用。當然在 2021 年的時候，我們也會去做 Flink 批流一體解決方案，讓用戶有更多選擇方式的同時，讓整個實時數(shù)倉變得更加簡單。
以上就是我們對批流融合的思考和實踐，通過這種架構(gòu)層面的批流融合，原來需要開發(fā)一個月的實時需求，現(xiàn)在 2 天就差不多能完成。大大降低了開發(fā)實時數(shù)據(jù)的門檻，提高了數(shù)據(jù)分析的效率。
實時平臺 ODS 層實時化
說一下 ODS 層實時化我們具體是怎么做的。
要想把 ODS 層數(shù)據(jù)實時化，我們需要解決兩個問題，第一個是離線數(shù)據(jù)的初始化問題，第二個是增量數(shù)據(jù)如何寫入的問題。離線數(shù)據(jù)導(dǎo)入比較好做，如果數(shù)據(jù)源是 MySQL，我們可以使用 DataX 或者 Spark 作業(yè)的方式將 MySQL 的全量數(shù)據(jù)導(dǎo)入到 Hive 中，而實時增量數(shù)據(jù)的寫入我們需要有兩個步驟，第一個步驟是將 MySQL 的 binlog 采集到 Kafka，第二個步驟是將 Kafka 的數(shù)據(jù)使用Flink作業(yè)導(dǎo)入到 Hive。這樣算下來，要解決 ODS 層實時化的問題，我們就需要一個離線初始化的作業(yè)，一個增量數(shù)據(jù)采集的作業(yè)，一個增量數(shù)據(jù)寫入的作業(yè)，也就是需要 3 個作業(yè)。
在我們的平臺上，我們對 ODS 層的 3 個作業(yè)進行了封裝和統(tǒng)一調(diào)度，用戶只需要輸入一個數(shù)據(jù)庫名稱和表的名稱就能完成 ODS 層實時化的工作。
以上就是我們批流融合中 ODS 層實時化的實現(xiàn)過程。
實時平臺 Flink SQL 開發(fā)流程
image.png
我們另外一個實踐，就是對 Flink SQL 的作業(yè)封裝。先看一下，在我們平臺上進行 Flink SQL 開發(fā)的整體流程。
從左往右看，數(shù)據(jù)源中的數(shù)據(jù)會通過 Maxwell、canal 這樣的工具采集到 Kafka，采集到 Kafka 的原始數(shù)據(jù)格式并不是統(tǒng)一的，所以我們需要將 Kafka 中的數(shù)據(jù)進行統(tǒng)一格式化處理，我們默認支持埋點數(shù)據(jù)格式、canal 數(shù)據(jù)格式、maxwell 數(shù)據(jù)的解析，也支持用戶自己上傳 Jar 包進行數(shù)據(jù)解析，解析得到的標準化數(shù)據(jù)就會再次發(fā)送到 Kafka。
然后我們會使用 Flink SQL 作業(yè)來消費 Kafka 的數(shù)據(jù)，進行 SQL 腳本的開發(fā)。這里的 SQL 腳本開發(fā)和原生的 Flink SQL 的腳本開發(fā)有一點不一樣，原生的 SQL 腳本開發(fā)用戶需要編寫 Source 信息、Sink 信息，在我們平臺上用戶只需要寫具體的 SQL 邏輯就可以了。
那用戶寫完 SQL 之后，會將 SQL 作業(yè)信息提交到我們封裝好的 Flink SQL 執(zhí)行作業(yè)上，最后通過我們封裝的 SQL 引擎將作業(yè)提交的 Flink 集群上去運行。后面將介紹我們是怎么封裝的。
以上就是在我們平臺上進行 Flink SQL 開發(fā)的流程，出了 Flink 作業(yè)本身的開發(fā)和提交，平臺也會保留與作業(yè)有關(guān)的各種輸入、輸出的 schema 信息。比如業(yè)務(wù)數(shù)據(jù)庫表的 schema 信息，經(jīng)過同意加工之后的 schema 信息，數(shù)據(jù)輸出的表的 schema 信息，通過這些記錄，后期我們排查問題的時候就能夠快速梳理出作業(yè)的來龍去脈和影響范圍。
實時平臺 Flink SQL 開發(fā)過程
在我們平臺上開發(fā) Flink SQL 作業(yè)，只需要三個步驟：
● 第一個步驟確認 Kafka 的 Topic 是否已經(jīng)注冊過了，如果沒有注冊就需要用戶手動注冊下，完成注冊后，我們會把 Topic 的數(shù)據(jù)解析出來，將字段信息保存起來。
● 第二步使用戶編寫 SQL，剛才說過，用戶只需要寫具體的 SQL 邏輯，不需要寫 Source 和 Sink 信息。
● 第三步是用戶指定將數(shù)據(jù)輸出到哪里，現(xiàn)在平臺可以支持同時指定多個 Sink 存儲設(shè)備，比如將計算好的數(shù)據(jù)同時寫入到 Hive、Holo 等存儲。
通過以上三個步驟的配置，用戶就可以提交作業(yè)了。
接下來說一下，我們是怎么做的，我把整個執(zhí)行過程分為 2 個階段 10 個步驟。
第一個階段就是作業(yè)準備階段，第二個階段就是 SQL 執(zhí)行階段。
■ 作業(yè)準備階段
● 第一步，用戶在頁面數(shù)據(jù) SQL 和指定 Sink 信息。
● 第二步，SQL 解析及校驗過程，當用戶提交 SQL 時，我們會對 SQL 進行解析，看看 SQL 中用到的 Source 表和 UDF 是否在平臺中注冊過。
● 第三步，推測建表，我們會先運用下用戶的 SQL，然后得到 SQL 的返回結(jié)果，根據(jù)結(jié)果數(shù)據(jù)生成一些建表語句，最后通過程序自動到目標 Sink 存儲上去建表。
● 第四步，拼裝 Flink SQL 的腳本文件，得到一個有 Source、SQL、Sink 三要素的腳本文件。
● 第五步，作業(yè)提交，這里會把 Flink SQL 文件提交到我們自己執(zhí)行引擎中。
■ SQL 執(zhí)行階段
● 第一步是會初始化 StreamTableAPI，然后使用 connect 方法注冊 Kafka Source，Kafka 的 Source 信息需要指定數(shù)據(jù)解析的規(guī)則和字段的 schema 信息，我們會根據(jù)元數(shù)據(jù)自動生成。
● 第二步是使用 StreamTableAPI 注冊 SQL 中使用到的維表和 UDF 函數(shù)，UDF 函數(shù)包括用戶自己上傳的 UDF 函數(shù)。
● 第三步是使用 StreamTable API 執(zhí)行 SQL 語句，如果有視圖也可以執(zhí)行視圖。
● 第四步是一個比較關(guān)鍵的步驟，我們會把 StreamTabAPI 轉(zhuǎn)成 DataStream API。
● 第五步就是在 DataStream 的基礎(chǔ)上 addSink 信息了。
以上是兩個階段的執(zhí)行過程，通過第二個階段，用戶的 SQL 作業(yè)就會真正的運行起來。
實時平臺原生作業(yè)與模板任務(wù)
上面分享了我們的 Flink SQL 作業(yè)如何開發(fā)和運行，接下來說一下我們平臺對 JAR 包類型作業(yè)的支持。
在我們平臺上，我們支持用戶自己上傳 JAR 包作業(yè)，然后在我們平臺上進行管理。與此同時，為了提高代碼通常場景的復(fù)用性，我們開發(fā)了很多模板作業(yè)，比如支持 Maxwell 采集的 binlog 直接寫入到 Hive、Kudu、Holo 等存儲設(shè)備，支持阿里云 SLS 日志寫入到各種 OLAP 引擎。
實時平臺混合云部署方案
講一下混合云部署方案和平臺技術(shù)架構(gòu)。
我們平臺現(xiàn)在支持將作業(yè)提交到阿里云機房、自建機房中，并且作業(yè)可以在兩個機房中來回切換。為了要有這個功能呢?
今年年初，隨著疫情的爆發(fā)，互聯(lián)網(wǎng)在線教育涌入了大量的流量，為了應(yīng)對暴增的流量，春節(jié)期間我們采購了上千臺機器進行緊急的部署和上線，后來疫情穩(wěn)定住了之后，這些機器的利用率就比較低了，為了解決這個問題，我們平臺就支持了混合云部署方案，高峰期的時候作業(yè)可以遷移到阿里云上運行，平常就在自己的集群上運行，既節(jié)約了資源又保證了彈性擴容。
實時平臺技術(shù)架構(gòu)
接下來說一下平臺的技術(shù)架構(gòu)。
我們是一個前后端分離的項目，前端使用 vue+elmentui、服務(wù)端使用 springboot，不同的機房里面我們會部署一個后端服務(wù)的實例。任務(wù)提交到不同的機房主要通過轉(zhuǎn)發(fā)層的 nginx+lua 來實現(xiàn)的。平臺上任務(wù)的提交、暫停、下線操作，都是通過驅(qū)動層來完成的，驅(qū)動層主要是一些 shell 腳本。最后就是客戶端了，在客戶端上我們做了 Namespace/用戶/Flink 版本的隔離。
3.K12 教育典型分析場景
續(xù)報業(yè)務(wù)介紹
我們聊一個具體的案例，案例是 K12 教育行業(yè)中典型的分析場景，用戶續(xù)報業(yè)務(wù)。
先說下什么是續(xù)報，續(xù)報就是重復(fù)購買，用戶購買了一年的課程，我們期望用戶購買二年的課程。為了用戶購買課程，我們會有一個集中的時間段用來做續(xù)報，每次持續(xù)一周左右，一年四次。
因為續(xù)報周期比較集中，時間比較短暫，每次做續(xù)報業(yè)務(wù)老師對實時續(xù)報數(shù)據(jù)的需求就特別迫切。
為此我們做了一個通用的續(xù)報解決方案，來支持各事業(yè)部的續(xù)報動作。要做實時續(xù)報，有幾個挑戰(zhàn)。
● 第一個挑戰(zhàn)是計算一個用戶的訂單是否是續(xù)報，需要依賴這個用戶歷史上所有的訂單，也就是需要歷史數(shù)據(jù)參與計算。
● 第二個挑戰(zhàn)就是一個訂單的變化會影響其它訂單的變化，是一個連鎖效應(yīng)。比如用戶有 5 個訂單，編號為 345 的訂單都是續(xù)報狀態(tài)，如果用戶取消了編號為 3 的訂單，訂單 4 和訂單5的續(xù)報狀態(tài)就需要重新計算。
● 第三個挑戰(zhàn)是維度變化很頻繁，比如用戶上午的分校狀態(tài)是北京，下午的分校狀態(tài)可能就是上海，上午的輔導(dǎo)老師是張三，下午的輔導(dǎo)老師就是李四，頻繁變化的維度給實時匯總數(shù)據(jù)帶來了挑戰(zhàn)。
依賴歷史數(shù)據(jù)、訂單改變的連鎖效應(yīng)、頻繁變化的維度，這些挑戰(zhàn)如果單個看都不算什么，如果放在一起就會變得比較有意思了。
實時續(xù)報解決方案
先說下整體架構(gòu)，我們采用的批流融合方式來做的，分成兩條線，一條線是分鐘級實時續(xù)報數(shù)據(jù)計算，一條是秒級實時續(xù)報數(shù)據(jù)計算。計算好的數(shù)據(jù)放在 MYSQL 中，用來做大屏和 BI 看板。
先看下藍色的這條線，我們會把 Hive 中的離線數(shù)據(jù)導(dǎo)入到 Kudu 中，離線數(shù)據(jù)都是計算好的訂單寬表。然后會使用 Flink 作業(yè)把新增的訂單做成寬表寫入到 Kudu 中，這樣 Kudu 里面就會有最新最全的數(shù)據(jù)。配合 4 分鐘的調(diào)度，我們就提供了分鐘級的實時續(xù)報數(shù)據(jù)。
在看第一條橙色的線條，這條線上有兩個 Flink 作業(yè)，一個是 ETL Job，一個是 Update Job。
ETL job 會負責靜態(tài)維度的拼接與續(xù)報狀態(tài)的計算，靜態(tài)維度拼接我們是直接訪問 MySQL，然后緩存在 JVM 中。續(xù)報狀態(tài)的計算需要依賴歷史數(shù)據(jù)，ETL Job 會將所有的訂單數(shù)據(jù)加載到 JVM 中，具體的實現(xiàn)方法是我們自定義了一個 partitioncustom 方法，對所有的歷史數(shù)據(jù)進行了分片，下游的每個 Task 緩存一個分片的數(shù)據(jù)。通過將數(shù)據(jù)加載到內(nèi)存中，我們大大的加快了 Flink 實時計算的速度。
ETL Job 的計算的數(shù)據(jù)，會有兩個輸出，一個是輸出到 Kudu，用來保證 Kudu 中的數(shù)據(jù)最新最全，兩個一個數(shù)據(jù)是 Kafka，Kafka 中有一個 Topic 記錄的是是當前訂單的變化導(dǎo)致了哪些訂單或者維度變化的信息。
接在 Kafka 后面的程序就是 Update Job，專門用來處理受影響的訂單或者維度，直接去修改 MySQL 中相關(guān)的統(tǒng)計數(shù)據(jù)。
這樣我們就通過 2 個 Flink 作業(yè)實現(xiàn)的實時續(xù)報的計算。
最下面的一條線是實時維度的數(shù)據(jù)變更的處理，維度變更的數(shù)據(jù)會發(fā)送到 Kafka中，然后使用 Flink 進行處理，看看維度的變化影響了哪些數(shù)據(jù)的統(tǒng)計，最后將受影響的訂單發(fā)送到受影響的 Topic 中，由 Update Job 來重新計算。
以上就是我們實時續(xù)報的整體解決方案，如果有教育行業(yè)的朋友聽到這個分享，或許可以參考下。
實時續(xù)報穩(wěn)定性保障
我們看看這個通用的解決方案上線之后有哪些保障。
● 第一個保障是異地雙活，我們在阿里云和自建機房都部署了一套續(xù)報程序，如果其中一套有異常，我們切換前端接口就可以了。如果兩個機房的程序都掛了，我們重零開始啟動程序，也只需要 10 分鐘。
● 第二個保障是作業(yè)容錯，我們有兩個 Flink 作業(yè)，這兩個作業(yè)隨停隨啟，不影響數(shù)據(jù)的準確性。另外一點就是我們緩存了所有訂單數(shù)據(jù)在 JVM 中，如果數(shù)據(jù)量暴漲，我們只需要改變 ETL 程序的并行度就可以，不用擔心 JVM 內(nèi)存溢出。
● 第三個保障是作業(yè)監(jiān)控，我們支持作業(yè)的異常告警和失敗后的自動拉起，也支持消費數(shù)據(jù)延遲告警。
通過以上保障措施，實時續(xù)報程序經(jīng)過了幾次續(xù)報周期，都比較平穩(wěn)，讓人很省心。
4.展望與規(guī)劃
上述內(nèi)容詳細介紹了好未來當前業(yè)務(wù)及技術(shù)方案，總結(jié)而言我們通過多租戶實現(xiàn)各事業(yè)部資源隔離、通過批流融合的架構(gòu)方案解決分析實時化、通過 ODS 層實時化解決數(shù)據(jù)源到 OLAP 的數(shù)據(jù)集成問題、通過 Flink SQL 封裝降低實時數(shù)據(jù)開發(fā)門檻、通過模板任務(wù)提供通用場景解決方案、通過混合云部署方案解決資源的彈性擴容、通過實時續(xù)報解決方案覆蓋相同場景的數(shù)據(jù)分析。
最后，來看一下我們展望和規(guī)劃。接下來我們要繼續(xù)深化批流融合，強化混合云部署，提高數(shù)據(jù)分析的時效性和穩(wěn)定性。支持算法平臺的實時化，數(shù)據(jù)應(yīng)用的實時化，提高數(shù)據(jù)決策的時效性。
原文鏈接：https://developer.aliyun.com/article/781032?
版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。總結(jié)
以上是生活随笔為你收集整理的开发效率提升15倍！批流融合实时平台在好未来的应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 详解 Flink 容器化环境下的 OOM
- 下一篇： 数据创新的四个陷阱