一站式实时数仓开发：当FLINK SQL遇见ULTRON

女主宣言

FLINK是被称为第四代大数据处理引擎的开源利器，近年来在国内各大厂的加持下更是成为了实时计算领域的标准，而ULTRON是360商业化近一年多来在总结自身实时计算场景应用和特点的基础上打造的一款实时作业开发平台，我们一起来看看两者的结合，会擦出怎样的火花吧！

PS：丰富的一线技术、多元化的表现形式，尽在“360云计算”，点关注哦！

1

什么是ULTRON

背景与痛点

       对于开发ULTRON的背景，截止2021年上半年，商业化团队核心KAFKA集群的实时写入OPS峰值已经达到4M/s、写入量5GB/s，而FLINK实时作业数的增长量，从2019年底的180，达到2020年底的350，至今已超过460。随着业务实时计算需求的不断增加，我们也陆续发现一些开发过程中的问题，比如：

Fig-1 实时作业开发问题

• 没有统一的数仓理论和工具支持，业务有各自的数仓分层策略，有的业务甚至并未考虑到数仓分层，这导致了数据彼此割裂，烟囱式开发效应明显。

• 普遍采用API开发方式，开发调试周期较长，线上问题排查困难。

• 缺乏作业管理、权限认证等支撑，我们能看到的只是大量的黑盒作业和各种底层数据连接，对这些作业和数据源之间的引用关系，无法梳理清楚。

• 没有提供统一的开发环境，缺乏CI/CD支持，作业开发完毕后，需要用户自己解决依赖冲突和版本兼容性问题。

ULTRON的定位

为了解决如上问题，我们在去年年初启动了新ULTRON数据平台架构，整体架构如图2所示，自底向上依次划分数据层、计算层、服务层、及用户需求层，每一层涵盖的内容比较多，不具体展开。这里主要结合FLINK讲一下实时作业的计算引擎选型。

Fig-2 ULTRON数据平台架构

FLINK是一个分布式流处理引擎，典型的可对比系统是STORM。FLINK支持各种有界、无界数据源的摄入，经过有状态算子的计算，又以各种数据汇总输出。除此之外，以下优异特性使得FLINK在同类竞品中脱颖而出，比如低延迟高吞吐、支持exactly once、可扩展高可用、灵活的分层API等。FLINK将其开发API分为三个抽象层，最底层是状态算子层，中间是Datastream层，这也是商业化研发团队普遍使用的jar开发方式。再往上是SQL/Table层，这种是将数据源视作表，配合声明式SQL表达，语义更简洁、开发更简单。最后，得益于API的统一和执行算子的抽象，FLINK可以较好支持批流一体化计算的场景。

Fig-3 FLINK流处理示例

Fig-4 FLINKAPI分层

现存的架构中开发者需要同时维护流作业和批作业，同时还要保证两者的结果一致性，维护成本比较高。在未来，流批一体化开发必将成为趋势，我们希望新的数据架构能够更好地适配这一点。目前ULTRON同时支持jar和SQL两种开发方式，由于SQL良好的通用性和简洁的表达性，因此更推荐采用SQL。

FLINK SQL

一个标准的FLINKSQL作业的提交过程图五所示

Fig-5 SQL提交过程

可以看到不论是采用Table API还是利用SQL-CLIENT，整个提交过程的核心步骤其实都是构建JobGraph，然后通过Execution target类型来创建Perjob 或者Session的作业连接器，并通过统一的Jobclient返回抽象来进行作业管理。而JobGraph的生成过程包括SQL解析成AST、Blinkplanner构建关系代数模型Relnode、采用基于RBO或CBO的优化器优化，最终生成可执行的物理计划。可见整个流程还是比较复杂的，那我们能否利用平台的能力来简化复杂度呢？其实这也是ultron重点解决的问题之一。

ULTRON的愿景

基于FLINK的计算能力和FLINK SQL的逻辑表达能力，我们希望将ULTRON打造成一套完整的实时数仓平台，从开发效率、易用性、普适性提供一站式PAAS能力。基于ULTRON提供的分层数据服务，开发者不必过多地关注底层，可以更加专注于业务开发，从而解决“用户”、“服务”、“数据”三者脱节的现状。

Fig-6 分层数据服务

2

实时作业开发流程

简单归纳起来，一个实时SQL作业能跑起来，离不开数据源、计算资源、业务逻辑和作业权限四个方面。

数据源表达了数据从哪里来、到哪里去，数据的存储特性、数据口径等；计算资源我们则关注计算能力(批处理/流处理)、效率、准确性、容灾可恢复性等；业务逻辑则包含逻辑的表述能力、迁移能力(比如一份表达能否同时用于流和批)、逻辑的可验证性；作业权限包含账号权限、数据可访问性、作业变更发布安全性。我们依次看下ULTRON上这四个部分是如何配合WORK起来的。

数据源

FLINK通过动态表统一了无界流和有界流。相比有界流，FLINK的动态查询结果其实是一个随时间不断变化的二维结果集，这使得FLINK更有能力表达“事实变更过程”。

Fig-7 Dynamic Table

目前ULTRON除了支持官方常用的数据源如KAFKA/HIVE/HBASE/ES 外，还额外支持了MYSQLCDC、CLICKHOUSE等第三方数据源，另外商业化这边重度使用的AEROSPIKE 数据源支持已经在开发中，数据湖内部已经支持，不久以后的版本会发布。

数据源本身代表的是具体的资产信息，包括结构化、非结构化，连接方式等，而作业关注的重点则是如何使用这些数据，如果直接采用作业对接数据源，管理成本会是乘方式的扩大。

为了解决这个问题，ULTRON通过使用模型这一概念对数据源进行了封装，大部分场景下模型和资产是一一对应的。模型都是一写多读的，所有SQL作业必须通过引用模型来使用资产数据。这样很大程度上提高了数据源复用能力，也规范了数据的生产方式。

Fig-8 模型及模型持久化

图8-右展示了模型的持久化方案，模型是采用FLINK catalog table的方式存储在HIVE metastore中的，同时ULTRON提供了独立的元数据管理，用于索引和协调数仓、资产、业务之间关系。

在建模过程中，直接写DDL建表成本还是较高的。除了要去查阅语法、还需要我们补充一大堆的连接参数。考虑到这点，ULTRON提供了在线可视化建模，图9对比了DDL建表与可视化建模的对应关系，除了字段、watermark、连接信息外，可视化建模还提供了数仓信息以及数据预览等功能；而权限和认证信息，会影响到优先级、资源重排、数据访问限制等，这部分是因作业而异的，将在运行时根据作业参数注入。这里我们需要牢记在ULTRON中，模型是参与SQL作业的最重要的基础元素，没有之一。

Fig-9 DDL建表VS. 可视化建模

整体上来说，ULTRON目前规划了三种模型，实时模型目前由flink_rtdw存储，离线模型由hive_edw存储，数据湖模型还在规划中，尚未开放。而对于实时作业重度依赖的KAFKA数据源，目前已支持绝大部分常用Format，例如confluent-avro/json/maxwell-json/canal-json/debezium-json/raw等。

计算资源

有了数据源的模型支持，我们再来看下计算资源方面的考量。

      ULTRON目前支持FLINK on K8S 和 FLINKon YARN两种资源调度方式。在资源隔离、数据IO、网络访问等具体场景，两种调度器均有自己的实现方式，YARN对于分布式数据IO，绑定了HDFS，而HDFS是目前为止被实践验证过的大IO场景最稳定可靠的分布式存储之一。而K8S由于支持预pull，所以在作业起调速度方面更具优势。同时在Job manager地址暴露方面，配合Ingress和DNS后缀匹配，K8S可以以静态地址方式暴露，而YARN需要通过YARN PROXY做运行时发现。

由此比较， 其实K8S更适合计算密集型及云原生应用，YARN更适合Batch及IO密集型应用。而FLINK的流式处理天生就是计算密集型和云原生的，对于Long Running的FLINK作业，我们也希望使用静态可配的Job Manager地址进行作业管理，因此更倾向于将FLINK部署在K8S上。

      有了对多种调度器的支持，FLINK集群的部署流程可以抽象为6个阶段，分别是本地资源初始化、账号权限初始化、配额初始化、启动集群、运行时监控、生命周期管理。图10是ULTRON上配置一个FLINK集群的步骤，通过选择一个可用计算资源，如shbt-k8s(部署在shbt IDC的K8S类型资源集群)，可获得推荐的集群名称。目前支持FLINK 1.11+版本，选择镜像时尽量选最新版本；资源空间和权限、配额有关，平台会帮我们自动处理好，开发者无需关心。如果希望集群异常时获取告警，需要开启监控功能。对于部署参数，需要调整JM/TM内存和CPU，以及TM的SLOT，如果需要运行较大状态的作业，建议选用rocks db状态后端并使能增量checkpoint。如上简易配置后，ULTRON可以一键启动集群并且30秒内可用。

Fig-10 FLINK集群参数配置

待集群启动后，我们便可以向该集群提交作业了，我们可以创建多个集群，并根据业务需要，安排哪些作业集中在哪个集群上运行。图11-左是作业部署架构，借助FLINK REST API以及ULTRON提供的parser/deployer服务，我们可以很容易将目标作业部署到K8S或者YARN上，图11-右是SQL作业提交工作流，总体上先使用parser服务将SQL切分成多条独立可执行的Statement后，先进行语法校验和逻辑优化，如果没有错误则会使用deployer服务创建会话事务，按SQL顺序一次提交。

Fig-11 作业部署架构 &SQL提交流程

业务逻辑

开发SQL作业，避免不了需要开发自定义的UDF来表达特殊的业务逻辑。FLINK分别通过core/hive module支持了Builtin/Hive 内置UDF，又支持通过Hive catalog支持原生Hive自定义UDF，当然也可以直接开发FLINK的nativeUDF。对比两种自定义的方式，Hive UDF不但可以用于FLINKSQL，还可以复用到现有离线作业，考虑到目前商业化仍然以lambda架构为主，我们选用Hive UDF作为自定义使用方式。在项目资产->自定义函数中，可以根据提示生成项目专属UDF开发包，完成开发并上传后，在数据仓库->UDF管理中注册，之后就可以在SQL中使用了。这里需要注意的是，所有的UDF都可以开放共享，其他业务只要申请了，就可以在其他作业中复用。

Fig-12 UDF注册示例图

ULTRON目前提供了在线IDE来支持SQL开发(下图13)，主要分为三大区域，最左侧是资源展示区，包含作业列表区(选中后其他区域联动)，项目模型区(为当前作业申请指定模型权限)，已授权模型区(查看字段及直接在SQL中使用)以及函数列表区，其中申请模型权限如图14，我们不但可以覆盖watermark定义，还可以重定义相关properties，下一个release中还会添加重定义META列Virtual属性的功能。中间是核心工作区，SQL编辑支持多条DML，支持MultiInsert(相较于社区版1.13+才支持，ULTRTON在1.11版本中已开始支持)。我们可以同时编辑或调试多个SQL作业，查看每个作业的血缘依赖，下方是调试及发布输出展示区。最右侧是作业参数定义区，比如设置并行度、check point等。

Fig-13 在线开发IDE

Fig-14 申请/变更作业的模型权限

很多同学在开发实时作业总会遇到一个问题，就是作业开发好了，版本也发布出去了，但数据对不对，只能等线上作业运行一段时间后观察输出表的结果才能比对，一旦数据有问题，就要撤回重发，严重影响生产效率。ULTRON基于FLINK SQL的开发模式，提供了在线测试功能，我们可以直接观察debug输出，确认无误后再提交发布。此外，在增强的交互体验中，相同作业的测试可以和线上任务并行操作，我们提供了数据录制和下载功能，方便线下对数。

Fig-15 在线测试

作业权限主要包括开发过程权限和数据读写权限。

• 开发过程权限管理：

1. SQL作业进入编辑模式后，平台自动对该作业加锁，其他用户无权进行并发编辑。

2. SQL作业进入测试模式后，平台自动对该测试加锁，其他用户无权进入性并发测试。

3. 作业开发Ready后必须经过项目主管审批方可上线。

• 数据读写权限管理：

目前按分层授权，规定了模型要先有项目权限再进行作业授权，而UDF仅设置项目权限，创建或申请一次即可所有作业使用。对于底层资产权限对接，既支持独立的租户认证如KAFKA consumer/producer、TIDB等，也支持公用资源的统一账户代理。对于实时ODS落地，目前支持以FLINK账号落地数据到HDFS，由后续离线作业读取进行ETL。

最后用一张整体俯瞰图总结下SQL开发过程：

Fig-16 SQL开发过程

3

ULTRON平台治理

数仓建设

平台治理离不开数仓建设，而说到数仓，数据分层又是必不可少的话题。分层，不仅能够规范数据之间的产入产出关系，还能有效消除重复的数据开发，将数据打上使用标识，为后续数仓的指标系统建设打下基础。在ULTRON数仓中模型是核心，所以我们将模型按照业界主流的one data标准进行了划分。数据从ODS层分路生成lambda的实时、离线链路，经过dw处理后又于dwa层汇聚，整个过程会复用dim层的维表，而对于实时链路来讲，由于其数据低延迟的要求，往往dw的处理层数较短，一般不超过4层。

如果我们将模型分层视为数仓的纵向分层，那么主题域划分可以认为是数仓的横向分层。这块内容其实更接近业务，主题域之间会有一定的数据隔离性。目前将主题域分为两个层次，一级主题域按公司主营业务划分，二级主题域按核心板块划分，业务过程在一级主题域内共享，每个主题域可设置接口人实现业务自治。

Fig-17 数仓分层与主题域划分

通过模型分层和主题域划分，我们希望能更加规范化数仓作业的拓扑关系和血缘关系，无论是从业务内部还是平台侧，都能为进一步的数据治理提供参考依据。

模型和UDF在开发完成后会发生迭代，而多个SQL作业会同时引用同一模型和UDF，这在ULTRON上又是如何协调和同步的呢？如图18-左所示，假设某一时刻模型A同时被作业1和作业2使用，其中作业2使用的是最新的V6版本模型Schema，而作业1使用的是某历史V2版本。此时在作业1的开发界面“已授权模型“列表中，我们会收到提示，被告知模型A已有更新，最新的Schema与作业1当前使用相比，减少了一个字段，另增加了两个字段。如果我们认为有必要升级到最新，则可以一键同步操作。对于UDF而言，其会随着UDF jar的更新而更新。如图18-右所示，假设某一时间来自不同项目SQL作业同时使用某自定义UDF，我们在更新UDF jar时只要保证使用同名覆盖更新方式即可在这些作业重启后自动使用最新版本的该UDF实现。

Fig-18 模型/UDF演进与同步

SQL作业运行起来后，我们需要在众多的作业和模型之间梳理引用关系，所谓数据血缘。比如找数场景、基于流水线视图的冷热数据/核心作业分析、流水线优化、运行时数据异常告警、故障节点排查等。如果我们将模型和作业视为不同类型的节点，将作业配置视为节点之间的边，而将数据流动方向视为边的方向，我们就可以绘制出这样一幅模型/作业流水线拓扑（如图19），需要注意的是模型节点是一写多读的，且流水线的输入/输出节点一定是模型；作业可以读多写多，且只能出现在流水线的途中节点。

Fig-19 数据血缘示例

我们在前述业务逻辑开发部分提到的为作业申请模型权限操作后，将新的拓扑分支更新到现有血缘图中。目前ULTRON上支持三个地方查看数据血缘，分别是当前项目数据质量、模型详情、当前作业血缘。

一站式高效开发

为了支持实时数仓快速、高效的开发，ULTRON集成了很多支撑型服务来简化开发过程中的环境依赖，如图20。

Fig-20 ULTRON集成的各种支撑服务

在开发过程组织上，采用以项目为粒度的管理方式，对内由项目角色各司其职，对外使用项目账号运行作业，如图21所示。每个项目的管理员只有一个，项目创建者自动成为该项目管理员。同一个用户可以在不同项目中担任不同的角色。每份数据都有项目归属，原则上“谁生产谁负责”。项目之间的数据交换体现在数仓模型分享与资产读写ACL授权，每个项目在创建伊始必须挂载到组织，因此项目内的资产核算自然也归属到该组织。

Fig-21 项目上下文内角色权限

ULTRON能够轻松管理各种异构的计算、存储资源，得益于其资源的云化管理方式。考虑到如下业务场景

• 业务方自有计算/存储资源的独立接入需求

• 作业的跨IDC操作数据问题

• 资源的独占、共享与核算问题

在参考了AWS的资源划分方式后，我们将计算、存储资源按Region（区域）、Zone（地区|IDC）划分，如图22所示。Region内部各Zone之间被认为是网络连通的，而Region之间被认为是网络隔离的。ULTRON本身并不绑定资源，而是抽象出资源池的概念来支持资源快速对接、即时生效。而资源在接入时也需要指定挂载组织，以便于资源隔离和资源清算。业务方的数仓在创建时需要绑定主Region，不允许跨Region使用计算/存储资源。

云化管理后为我们带来更灵活的资源分配方式，现在可以弹性接入全国各地的存储、计算资源，满足数仓项目开发的地域差异性。

Fig-22 资源云化管理示意图

统一监控告警

目前针对FLINK集群和作业支持了统一的metric监控，如图23，通过资产->FLINK集群列表及详情可以跳转到Grafana视图，对于自定义监控需求，目前只支持了探活监控，计划在后续版本中，参考FLINK官方的metric体系和接口开发额外的支持。

      告警策略方面目前采用的是告警组的管理模式(图24)，由组管理员维护成员和监控目标的告警状态；项目内成员可以主动订阅感兴趣的监控项，一旦触发告警阈值，优先使用推推（360内部办公软件）告警，若在阈值有效期内告警未处理则会启用电话告警。

Fig-23FLINK集群& 作业统一监控

Fig-24告警组管理

计算资源监控方面目前支持了K8S上的CPU监控和MEMORY监控，以及FLINK集群可用数量的监控，每个项目在创建初期会获得一定数量的配额，之后如需扩容，可在运维监控->配额管理中一键申请(图25)，审批经平台管理员和K8S接口人审批后自动生效。

Fig-25 配额扩容

4

后续工作

功能完善

数据湖探索

我们知道，在作业中计算和存储共同构成了数据的载体，如果要统一流批，就要解决计算的统一和存储的统一。传统的LAMBDA架构明显的问题是两套数据两套计算，由于数据的不可变性，需要开发者自行做数据合并；而为了解决这个问题，几年前出现的KAPPA架构简化处理流水线，使用类KAFKA的消息队列来统一计算和存储，但由于消息队列的有限数据范围，导致KAPPA不能较好的解决历史回放问题，从而无法在实践中大范围推广。

Fig-26 KAPPA ON DATALAKE

近年来随着数据湖概念的兴起，似乎使这一技术方向的落地成为了可能，数据湖存储具有可更新、支持事务、Time Travel、统一流批存储等特性，而回过头来对比LAMBDA和KAPPA，其中一个缺陷是不支持更新，还有一个致命缺陷是不支持历史回放，这样数据湖确实可以看做一个折中的方案。目前业界三大数据湖方案中对FLINK比较友好的iceberg和hudi，我们还在调研和比较中，预计在不久之后的版本中，也会将其集成到ULTRON中来。

360云计算

由360云平台团队打造的技术分享公众号，内容涉及数据库、大数据、微服务、容器、AIOps、IoT等众多技术领域，通过夯实的技术积累和丰富的一线实战经验，为你带来最有料的技术分享！