摘要：本文「 StreamX 最佳實(shí)踐-Flink on Kubernetes篇 」作者是霧芯科技大數(shù)據(jù)工程師 >Gerry豪墅，主要內(nèi)容為：

1.為什么選擇 Native Kubernetes
2.當(dāng) Flink on Kubernetes 遇見 StreamX
3.StreamX 在霧芯科技的落地實(shí)踐
4.遇到的問題
5.未來期待

霧芯科技創(chuàng)立于2018年1月句旱。目前主營(yíng)業(yè)務(wù)包括 RELX 悅刻品牌產(chǎn)品的研發(fā)戏溺、設(shè)計(jì)、制造及銷售矮男。憑借覆蓋全產(chǎn)業(yè)鏈的核心技術(shù)與能力，RELX 悅刻致力于為用戶提供兼具高品質(zhì)和安全性的產(chǎn)品。

為什么選擇 Native Kubernetes

Native Kubernetes 具有以下優(yōu)勢(shì)：

更短的 Failover 時(shí)間

可以實(shí)現(xiàn)資源托管脓鹃，不需要手動(dòng)創(chuàng)建 TaskManager 的 Pod，可以自動(dòng)完成銷毀

具有更加便捷的 HA古沥，F(xiàn)link 1.12版本之后在 Native Kubernetes 模式下瘸右，可以依賴于原生 Kubernetes 的 Leader選舉機(jī)制來完成 JobManager 的 HA

Native Kubernetes 和 Standalone Kubernetes 主要區(qū)別在于 Flink 與 Kubernetes 交互的方式不同以及由此產(chǎn)生的一系列優(yōu)勢(shì)。Standalone Kubernetes 需要用戶自定義 JobManager 和 TaskManager 的 Kubernetes 資源描述文件岩齿，提交作業(yè)時(shí)需要用 kubectl 結(jié)合資源描述文件啟動(dòng) Flink 集群太颤。而 Native Kubernetes 模式 Flink Client 里面集成了一個(gè) Kubernetes Client，它可以直接和 Kubernetes API Server 進(jìn)行通訊，完成 JobManager Deployment 以及 ConfigMap 的創(chuàng)建乞封。JobManager Development 創(chuàng)建完成之后，它里面的 Resource Manager 模塊可以直接和 Kubernetes API Server 進(jìn)行通訊肃晚，完成 TaskManager pod 的創(chuàng)建和銷毀工作以及 Taskmanager 的彈性伸縮锚贱。因此生產(chǎn)環(huán)境中推薦使用 Flink on Native Kubernetes 模式部署 Flink 任務(wù)。

Flink on Native Kubernetes 體系架構(gòu)圖

當(dāng) Flink On Kubernetes 遇見 StreamX

Flink on Native Kubernetes 目前支持 Application 模式和 Session 模式著榴，兩者對(duì)比 Application 模式部署規(guī)避了 Session 模式的資源隔離問題往衷、以及客戶端資源消耗問題汰扭，因此生產(chǎn)環(huán)境更推薦采用 Application Mode 部署 Flink 任務(wù)撞芍。下面我們分別看看使用原始腳本的方式和使用 StreamX 開發(fā)部署一個(gè) Flink on Native Kubernetes 作業(yè)的流程。
使用腳本方式部署Kubernetes

在沒有一個(gè)支持 Flink on Kubernetes 任務(wù)開發(fā)部署的平臺(tái)的情況下椰苟，需要使用腳本的方式進(jìn)行任務(wù)的提交和停止，這也是 Flink 提供的默認(rèn)的方式，具體步驟如下:

1. 在 Flink 客戶端節(jié)點(diǎn)準(zhǔn)備 kubectl 和 Docker 命令運(yùn)行環(huán)境你踩，創(chuàng)建部署 Flink 作業(yè)使用的 Kubernetes Namespace 和 Service Account 以及進(jìn)行 RBAC

2. 編寫 Dockerfile 文件诅岩，將 Flink 基礎(chǔ)鏡像和用戶的作業(yè) Jar 打包到一起

FROM flink:1.13.6-scala_2.11
RUN mkdir -p $FLINK_HOME/usrlib
COPY my-flink-job.jar $FLINK_HOME/usrlib/my-flink-job.jar

3. 打鏡像推送 Docker 倉(cāng)庫(kù)

docker build -t relx_flink_1.13.6-scala_2.11:latest .
docker tag relx_flink_1.13.6-scala_2.11:latest relx_docker_url/streamx/relx_flink_1.13.6-scala_2.11:latest
docker push relx_docker_url/streamx/relx_flink_1.13.6-scala_2.11:latest

4. 使用 Flink 客戶端腳本啟動(dòng) Flink 任務(wù)

    --target kubernetes-application \
    -Dkubernetes.namespace=flink-cluster \
    -Dkubernetes.jobmanager.service-account=default \
    -Dkubernetes.cluster-id=my-first-application-cluster \
    -Dkubernetes.container.image=relx_docker_url/streamx/relx_flink_1.13.6-scala_2.11:latest \
    -Dkubernetes.rest-service.exposed.type=NodePort \
    local:///opt/flink/usrlib/my-flink-job.jar

5. 使用 Kubectl 命令獲取到 Flink 作業(yè)的 WebUI 訪問地址和 JobId

kubectl -n flink-cluster get svc 

6. 使用Flink命令停止作業(yè)

./bin/flink cancel --target kubernetes-application -Dkubernetes.cluster-id=my-first-application-cluster -Dkubernetes.namespace=flink-cluster <jobId>

以上就是使用 Flink 提供的最原始的腳本方式把一個(gè) Flink 任務(wù)部署到 Kubernetes 上的過程，只做到了最基本的任務(wù)提交带膜，如果要達(dá)到生產(chǎn)使用級(jí)別吩谦，還有一系列的問題需要解決，如：方式過于原始無法適配大批量任務(wù)膝藕、無法記錄任務(wù)checkpoint 和實(shí)時(shí)狀態(tài)跟蹤式廷、任務(wù)運(yùn)維和監(jiān)控困難、無告警機(jī)制芭挽、 無法集中化管理等等滑废。

使用 StreamX 部署 Flink on Kubernetes

對(duì)于企業(yè)級(jí)生產(chǎn)環(huán)境使用 Flink on Kubernetes 會(huì)有著更高的要求, 一般會(huì)選擇自建平臺(tái)或者購(gòu)買相關(guān)商業(yè)產(chǎn)品, 不論哪種方案在產(chǎn)品能力上滿足: 大批量任務(wù)開發(fā)部署、狀態(tài)跟蹤袜爪、運(yùn)維監(jiān)控蠕趁、失敗告警、任務(wù)統(tǒng)一管理辛馆、高可用性 等這些是普遍的訴求俺陋。
針對(duì)以上問題我們調(diào)研了開源領(lǐng)域支持開發(fā)部署 Flink on Kubernetes 任務(wù)的開源項(xiàng)目，調(diào)研的過程中也不乏遇到了其他優(yōu)秀的開源項(xiàng)目昙篙，在綜合對(duì)比了多個(gè)開源項(xiàng)目后得出結(jié)論: StreamX 不論是完成度還是使用體驗(yàn)腊状、穩(wěn)定性等整體表現(xiàn)都非常出色，因此最終選擇了 StreamX 作為我們的一站式實(shí)時(shí)計(jì)算平臺(tái)瓢对。下面我們看看 StreamX 是如何支持 Flink on Kubernetes :

基礎(chǔ)環(huán)境配置

基礎(chǔ)環(huán)境配置包括 Kubernetes 和 Docker 倉(cāng)庫(kù)信息以及 Flink 客戶端的信息配置寿酌。對(duì)于 Kubernetes 基礎(chǔ)環(huán)境最為簡(jiǎn)單的方式是直接拷貝 Kubernetes 節(jié)點(diǎn)的 .kube/config 到 StreamX 節(jié)點(diǎn)用戶目錄，之后使用 kubectl 命令創(chuàng)建 Flink 專用的 Kubernetes Namespace 以及進(jìn)行 RBAC 配置硕蛹。

# 創(chuàng)建Flink作業(yè)使用的k8s namespace
kubectl create ns flink-cluster
# 對(duì)default用戶進(jìn)行RBAC資源綁定
kubectl create clusterrolebinding flink-role-binding-default --clusterrole=edit --serviceaccount=flink-cluster:default

Docker 賬戶信息直接在 StreamX Setting 界面配置即可：

StreamX 可適配多版本 Flink 作業(yè)開發(fā)醇疼，F(xiàn)link 客戶端直接在 StreamX Setting 界面配置即可：

作業(yè)開發(fā)

StreamX 做好基礎(chǔ)環(huán)境配置之后只需要三步即可開發(fā)部署一個(gè) Flink 作業(yè):

StreamX 開發(fā)部署 Flink on K8S 流程

StreamX 既支持 Upload Jar 也支持直接編寫 Flink SQL 作業(yè), Flink SQL 作業(yè)只需要輸入SQL 和 依賴項(xiàng)即可, 該方式大大提升了開發(fā)體驗(yàn), 并且規(guī)避了依賴沖突等問題硕并，對(duì)此部分本文不重點(diǎn)介紹。

這里需要選擇部署模式為 kubernetes application, 并且需要在作業(yè)開發(fā)頁(yè)面進(jìn)行以下參數(shù)的配置：紅框中參數(shù)為 Flink on Kubernetes 基礎(chǔ)參數(shù)秧荆。

下面參數(shù)為 Flink 作業(yè)和資源相關(guān)的參數(shù)倔毙，Resolve Order 的選擇與代碼加載模式有關(guān)，對(duì)于 DataStream API 開發(fā)的 Upload Jar上傳的作業(yè)選擇使用 Child-first乙濒，F(xiàn)link SQL 作業(yè)選擇使用 Parent-first 加載陕赃。

最后就是下面這兩個(gè)重量級(jí)參數(shù)了，對(duì)于 Native Kubernetes 而言颁股，k8s-pod-template 一般只需要進(jìn)行 pod-template 配置即可么库，Dynamic Option 是 pod-template 參數(shù)的補(bǔ)充，對(duì)于一些個(gè)性化配置可以在 Dynamic Option 中配置甘有。更多 Dynamic Option 直接參考 Flink 官網(wǎng)即可诉儒。

作業(yè)上線

作業(yè)開發(fā)完成之后是作業(yè)上線環(huán)節(jié)，在這一環(huán)節(jié)中 StreamX 做了大量的工作亏掀，具體如下:

• 準(zhǔn)備環(huán)境

• 作業(yè)中的依賴下載

• 構(gòu)建作業(yè)(打JAR包)

• 構(gòu)建鏡像

• 推送鏡像到遠(yuǎn)程倉(cāng)庫(kù)

對(duì)于用戶來說: 只需要點(diǎn)擊任務(wù)列表中的云狀的上線按鈕即可忱反。

作業(yè)提交

最后只需要點(diǎn)擊 Operation 里 start Application 按鈕便可啟動(dòng)一個(gè) Flink on Kubernetes 作業(yè)，作業(yè)啟動(dòng)成功之后點(diǎn)擊作業(yè)名便可跳轉(zhuǎn)到 Jobmanager WebUI 頁(yè)面间影、整個(gè)過程非常簡(jiǎn)單絲滑注竿。

整個(gè)過程僅需上述三步，即可完成在 StreamX 上開發(fā)和部署一個(gè)Flink on Kubernetes 作業(yè)宇智。而 StreamX 對(duì)于 Flink on Kubernetes 的支持遠(yuǎn)遠(yuǎn)不止提交個(gè)任務(wù)這么簡(jiǎn)單蔓搞。

作業(yè)管理

在作業(yè)提交之后胰丁，StreamX 能實(shí)時(shí)獲取到任務(wù)的最新 checkpoint 地址随橘、任務(wù)的運(yùn)行狀態(tài)、集群實(shí)時(shí)的資源消耗信息锦庸，針對(duì)運(yùn)行的任務(wù)可以非常方便的一鍵啟停, 在停止作業(yè)時(shí)支持記錄 savepoint 的位置, 以及再次啟動(dòng)時(shí)從 savepoint 恢復(fù)狀態(tài)等功能机蔗，從而保證了生產(chǎn)環(huán)境的數(shù)據(jù)一致性，真正具備 Flink on Kubernetes 的 一站式開發(fā)甘萧、部署萝嘁、運(yùn)維監(jiān)控的能力。

接下來我們來看看這一塊的能力 StreamX 是如何進(jìn)行支持的:

• 實(shí)時(shí)記錄checkpoint
  在作業(yè)提交之后扬卷，有時(shí)候需要更改作業(yè)邏輯但是要保證數(shù)據(jù)的一致性牙言，那么就需要平臺(tái)具有實(shí)時(shí)記錄每一次 checkpoint 位置的能力, 以及停止時(shí)記錄最后的 savepoint 位置的能力，StreamX 在 Flink on Kubernetes 上很好的實(shí)現(xiàn)了該功能怪得。默認(rèn)會(huì)每隔5秒獲取一次 checkpoint 信息記錄到對(duì)應(yīng)的表中咱枉，并且會(huì)按照 Flink 中保留 checkpoint 數(shù)量的策略卑硫，只保留 state.checkpoints.num-retained 個(gè)，超過的部分則刪除蚕断。在任務(wù)停止時(shí)有勾選 savepoint 的選項(xiàng)欢伏，如勾選了savepoint 選項(xiàng)，在任務(wù)停止時(shí)會(huì)做 savepoint 操作亿乳，同樣會(huì)記錄 savepoint 具體位置到表中硝拧。

默認(rèn) savepoint 的根路徑只需要在 Flink Home flink-conf.yaml 文件中配置即可自動(dòng)識(shí)別，除了默認(rèn)地址葛假，在停止時(shí)也可以自定義指定 savepoint 的根路徑障陶。

任務(wù)停止時(shí) savepoint選項(xiàng)

任務(wù)啟動(dòng)時(shí)從savepoint恢復(fù)

• 實(shí)時(shí)跟蹤運(yùn)行狀態(tài)
  對(duì)于生產(chǎn)環(huán)境的挑戰(zhàn)，很重要的一點(diǎn)就是監(jiān)控是否到位聊训，F(xiàn)link on Kubernetes 更是如此内狸。這點(diǎn)很重要, 也是最基本需要具備的能力，StreamX 可實(shí)時(shí)監(jiān)控 Flink on Kubernetes 作業(yè)的運(yùn)行狀態(tài)并在平臺(tái)上展示給用戶贪惹，在頁(yè)面上可以很方便的根據(jù)各種運(yùn)行狀態(tài)來檢索任務(wù)底扳。

  
  
  作業(yè)運(yùn)行狀態(tài)

• 完善的告警機(jī)制
  除此之外 StreamX 還具備完善的報(bào)警功能: 支持郵件、釘釘遏暴、微信和短信 等侄刽。這也是當(dāng)初公司調(diào)研之后選擇 StreamX 作為 Flink on Kubernetes 一站式平臺(tái)的重要原因。

  
  
  監(jiān)控告警配置
  
  

  通過以上我們看到 StreamX 在支持 Flink on Kubernetes 開發(fā)部署過程中具備的能力, 包括：作業(yè)的開發(fā)能力朋凉、部署能力州丹、監(jiān)控能力、運(yùn)維能力杂彭、異常處理能力等墓毒，StreamX 提供的是一套相對(duì)完整的解決方案。 且已經(jīng)具備了一些 CICD/DevOps 的能力亲怠，整體的完成度還在持續(xù)提升所计。是在整個(gè)開源領(lǐng)域中對(duì)于 Flink on Kubernetes 一站式開發(fā)部署運(yùn)維工作全鏈路都支持的產(chǎn)品，StreamX 是值得被稱贊的团秽。

StreamX 在霧芯科技的落地實(shí)踐

StreamX 在霧芯科技落地較晚主胧，目前主要用于實(shí)時(shí)數(shù)據(jù)集成作業(yè)和實(shí)時(shí)指標(biāo)計(jì)算作業(yè)的開發(fā)部署，有 Jar 任務(wù)也有 Flink SQL 任務(wù)习勤，全部使用 Native Kubernetes 部署踪栋；數(shù)據(jù)源有CDC、Kafka 等图毕，Sink 端有 Maxcompute夷都、kafka、Hive 等予颤，以下是公司開發(fā)環(huán)境StreamX 平臺(tái)截圖：

RELX StreamX 實(shí)時(shí)計(jì)算作業(yè)

遇到的問題

任何新技術(shù)都有探索與踩坑的過程囤官，失敗的經(jīng)驗(yàn)是寶貴的厢破，這里介紹下 StreamX 在霧芯科技落地過程中踩的一些坑和經(jīng)驗(yàn)，這塊的內(nèi)容不僅僅關(guān)于 StreamX 的部分, 相信會(huì)帶給所有使用 Flink on Kubernetes 的小伙伴一些參考治拿。

常見問題總結(jié)如下

• kubernetes pod 拉取鏡像失敗
  這個(gè)問題主要在于 Kubernetes pod-template 缺少 docker的 imagePullSecrets

• scala 版本不一致
  由于 StreamX 部署需要 Scala 環(huán)境摩泪，而且 Flink SQL 運(yùn)行需要用到 StreamX 提供的 Flink SQL Client，因此一定要保證 Flink 作業(yè)的 Scala 版本和 StreamX 的 Scala 版本保持一致劫谅。

• 注意類沖突
  進(jìn)行 Flink SQL 作業(yè)開發(fā)的時(shí)候需要注意 Flink 鏡像和 Flink connector 及 UDF 中有沒有類沖突见坑，最好的避免類沖突的辦法是將 Flink 鏡像和常用的 Flink connector 及用戶 UDF 打成一個(gè)可用的基礎(chǔ)鏡像，之后其他 Flink SQL 作業(yè)直接復(fù)用即可捏检。

• 沒有 Hadoop 環(huán)境怎么存儲(chǔ) checkpoint?
  HDFS 阿里云 OSS/AWS S3 都可以進(jìn)行 checkpoint 和 savepoint 存儲(chǔ)荞驴，F(xiàn)link 基礎(chǔ)鏡像已經(jīng)有了對(duì)于 OSS 和 S3 的支持，如果沒有 HDFS 可以使用阿里云 OSS 或者 S3存儲(chǔ)狀態(tài)和 checkpoint 和 savepoint 數(shù)據(jù)贯城，只需要在 Flink 動(dòng)態(tài)參數(shù)中簡(jiǎn)單配置一下即可熊楼。

-Dstate.backend=rocksdb
-Dcontainerized.master.env.ENABLE_BUILT_IN_PLUGINS=flink-oss-fs-hadoop-1.13.6.jar
-Dcontainerized.taskmanager.env.ENABLE_BUILT_IN_PLUGINS=flink-oss-fs-hadoop-1.13.6.jar
-Dfs.oss.endpoint=xxyy.aliyuncs.com
-Dfs.oss.accessKeyId=xxxxxxxxxx
-Dfs.oss.accessKeySecret=xxxxxxxxxx
-Dstate.checkpoints.dir=oss://realtime-xxx/streamx/dev/checkpoints/
-Dstate.savepoints.dir=oss://realtime-xxx/streamx/dev/savepoints/

• 改了代碼重新發(fā)布后并未生效
  該問題與 Kubernetes pod 鏡像拉取策略有關(guān)，建議將 Pod 鏡像拉取策略設(shè)置為 Always：
  -Dkubernetes.container.image.pull-policy=Always
• 任務(wù)每次重啟都會(huì)導(dǎo)致多出一個(gè) Job 實(shí)例
  在配置了基于 kubernetes 的HA的前提條件下能犯，當(dāng)需要停止 Flink 任務(wù)時(shí)鲫骗，需要通過 StreamX 的 cancel 來進(jìn)行，不要直接通過 kubernetes 集群刪除 Flink 任務(wù)的 Deployment踩晶。因?yàn)?Flink 的關(guān)閉有其自有的關(guān)閉流程执泰，在刪除 pod 同時(shí) Configmap 中的相應(yīng)配置文件也會(huì)被一并刪除，而直接刪除 pod 會(huì)導(dǎo)致 Configmap 的殘留渡蜻。當(dāng)相同名稱的任務(wù)重啟時(shí)术吝，會(huì)出現(xiàn)兩個(gè)相同 Job 現(xiàn)象，因?yàn)樵趩?dòng)時(shí)茸苇，任務(wù)會(huì)加載之前殘留的配置文件排苍，嘗試將已經(jīng)關(guān)閉的任務(wù)恢復(fù)。
• kubernetes pod 域名訪問怎么實(shí)現(xiàn)
  域名配置只需要按照 Kubernetes 資源在 pod-template 中配置即学密，可針對(duì)以上問題給大家分享一個(gè)本人總結(jié)的一個(gè) pod-template.yaml 模板：

apiVersion: v1
kind: Pod
metadata:
  name: pod-template
spec:
  serviceAccount: default
  containers:
  - name: flink-main-container
    image: 
  imagePullSecrets:
  - name: regsecret
  hostAliases:
    - ip: "192.168.0.1"
      hostnames:
      - "node1"
    - ip: "192.168.0.2"
      hostnames:
      - "node2"
    - ip: "192.168.0.3"
      hostnames:
      - "node3"

最佳實(shí)踐

悅刻的大數(shù)據(jù)組件很多基于阿里云淘衙，比如 Maxcompute、阿里云 Redis则果，同時(shí)我們這邊 Flink SQL 作業(yè)需要用到一些 UDF幔翰。最開始我們是采用使用 Flink Base image + maven dependency + upload udf jar 的方式漩氨，但是實(shí)踐過程中遇到了一些比如版本沖突西壮、類沖突的問題，同時(shí)如果是大批量作業(yè)的話這種方式開發(fā)效率比較低叫惊，最后我們采取將公司級(jí)別的常用的 Flink connector 和 udf 和 Flink base image 打包成公司級(jí)別的基礎(chǔ)鏡像款青，新 Flink SQL 作業(yè)使用該基礎(chǔ)鏡像之后直接寫 Flink SQL 即可，大大提高了開發(fā)效率霍狰。

下面分享一個(gè)制作基礎(chǔ)鏡像的簡(jiǎn)單步驟：

1. 準(zhǔn)備需要的 JAR
將常用 Flink Connector Jar 和用戶 Udf Jar 放置在同一文件夾 lib 下抡草，以下都是Flink 1.13.6 常用的一些 connector 包

bigdata-udxf-1.0.0-shaded.jar
flink-connector-jdbc_2.11-1.13.6.jar
flink-sql-connector-kafka_2.11-1.13.6.jar
flink-sql-connector-mysql-cdc-2.0.2.jar
hudi-flink-bundle_2.11-0.10.0.jar
ververica-connector-odps-1.13-vvr-4.0.7.jar
ververica-connector-redis-1.13-vvr-4.0.7.jar

2. 準(zhǔn)備 Dockerfile

創(chuàng)建 Dockerfile 文件饰及，并將 Dockerfile 文件跟上面文件夾放置在同一文件夾下

FROM flink:1.13.6-scala_2.11
COPY lib $FLINK_HOME/lib/

3. 基礎(chǔ)鏡像制作并推送私有倉(cāng)庫(kù)

docker login --username=xxx
docker build -t udf_flink_1.13.6-scala_2.11:latest .
docker tag udf_flink_1.13.6-scala_2.11:latest k8s-harbor.xxx.com/streamx/udf_flink_1.13.6-scala_2.11:latest
docker push k8s-harbor.xxx.com/streamx/udf_flink_1.13.6-scala_2.11:latest

未來期待

• StreamX 對(duì)于 Flink 作業(yè) Metric 監(jiān)控的支持
  StreamX 如果可以對(duì)接 Flink Metric 數(shù)據(jù)而且可以在 StreamX 平臺(tái)上展示每時(shí)每刻 Flink 的實(shí)時(shí)消費(fèi)數(shù)據(jù)情況就太棒了
• StreamX 對(duì)于Flink 作業(yè)日志持久化的支持
  對(duì)于部署到 YARN 的 Flink 來說，如果 Flink 程序掛了康震，我們可以去 YARN 上看歷史日志燎含，但是對(duì)于 Kubernetes 來說，如果程序掛了腿短，那么 Kubernetes 的 pod 就消失了屏箍，就沒法查日志了。所以用戶需要借助 Kubernetes 上的工具進(jìn)行日志持久化橘忱，如果 StreamX 支持 Kubernetes 日志持久化接口就更好了赴魁。
• 鏡像過大的問題改進(jìn)
  StreamX 目前對(duì)于 Flink on Kubernetes 作業(yè)的鏡像支持是將基礎(chǔ)鏡像和用戶代碼打成一個(gè) Fat 鏡像推送到 Docker 倉(cāng)庫(kù)，這種方式存在的問題就是鏡像過大的時(shí)候耗時(shí)比較久钝诚，希望未來基礎(chǔ)鏡像可以復(fù)用不需要每次都與業(yè)務(wù)代碼打到一起颖御，這樣可以極大地提升開發(fā)效率和節(jié)約成本。

編者按

社區(qū)正在著手解決該問題凝颇，新的方案將采用 pod template 的方式潘拱，去除目前打>鏡像這個(gè)冗余的流程，將大大簡(jiǎn)化流程拧略，提升開發(fā)效率泽铛。

什么是 StreamX

StreamX 的初衷是讓流處理更簡(jiǎn)單，定位是流處理開發(fā)腳手架和一站式實(shí)時(shí)計(jì)算平臺(tái)辑鲤。目前盔腔，StreamX 為 Spark 和 Flink 提供了一套快速開發(fā)的 API，定義了最佳的編程方式月褥，提供了一系列開箱即用的連接器，標(biāo)準(zhǔn)化了配置舀透、開發(fā)佛猛、測(cè)試遂跟、部署、監(jiān)控和運(yùn)維的整個(gè)過程假消。此外亿傅，StreamX 很好地解決了流處理任務(wù)開發(fā)谅阿、部署和運(yùn)維方面的問題盯串，集成了項(xiàng)目編譯、發(fā)布、啟動(dòng)和狀態(tài)監(jiān)控等工作。通過 StreamX否副，流處理任務(wù)可以輕松的部署在 YARN 或 Kubernetes 上负甸，這大大降低了 Flink 和 Spark 應(yīng)用的開發(fā)部署管理門檻队腐。

我們正在積極運(yùn)營(yíng) StreamX 社區(qū)，并期待著不斷增加社區(qū)活動(dòng)，歡迎廣大開發(fā)者參與我們应民，攜手共建涉馅，目前我們已經(jīng)有一大批用戶在生產(chǎn)環(huán)境使用 StreamX，歡迎更多用戶前來使用。

StreamX用戶墻