ULTRON — 360基于Flink的实时数仓平台

前言：ULTRON项目从去年开始立项，伴随着Flink社区的成熟不断迭代。在开发过程中，面临着许多困难，一方面是人手紧张，另一方面是需要打通和实现的功能点复杂，从底层K8S/YARN到FLINK核心的封装到数仓产品化，还有周边各支撑组件的打通，工作量确实不小。我们一直也不满意于发布各版本的功能，所以版本号都定义的很低。直到前段时间我们内部发布了1.0版本，我们认为用FLINKSQL进行实时数仓的开发已经可以真正的、完整的在ULTRON完成。回顾当时的设计初衷，简单总结下，以此纪念。

小编发言：“360技术”是360团队的线上技术聚合平台，致力提供有价值的技术干货，点击上方关注哦！

01

背景

长期以来，数仓架构一直以Hive为中心，通过MapReduce或者Spark进行离线ETL处理。ETL任务通常采用T+1或者小时粒度进行调度，也就是数据只能在第二天或者几个小时后产出。随着业务对时效性的要求越来越高，这种传统架构已经无法满足，比如以下几个场景：

1. 实时大盘：需要分钟级甚至秒级实时统计媒体流量、广告主花费、点击率等指标

2. 实时监测：实时分析作弊流量进行异常报警，或者实时反馈用户行为用于实时推荐

数据的实效性对业务的提升至关重要。初期实时计算框架以Storm为主流，但是其只支持At-Least-Once语义，并且不支持SQL，开发部署复杂，使得Storm只能在一些对数据准确性要求不高的场景下应用，在这种架构下，通常Storm实时计算的结果只能作为一个参考，最终数据仍然以离线数仓T+1结果为准，即Storm只能作为离线数仓的补充。

随着Flink的逐步成熟，其低延迟高吞吐的性能、精确一致、有状态计算等重要特性，架构上天生有着Storm无法比拟的优势。并且Flink支持SQL，且支持的生态强大，内置了Kafka/JDBC/ES/HBase等组件的connector。基于FlinkSQL构建实时数仓，与离线Hive数仓相契合，已经成为目前新数仓架构的标配。利用FlinkSQL在实时层面基于最新数据进行秒级流式计算，利用Hive SQL在离线层面进行T+1全量历史数据的数仓计算。值得注意的是，实时Flink与离线Hive数仓不是割裂的，Flink可以打通Hive，既可以在离线通过批处理方式处理Hive数据，也可以在实时流式访问Hive数据。在计算框架层面，实时和离线数仓的统一和融合也即流批一体，是当前数仓架构的新趋势，这将极大提升数据的实效性，简化技术栈，提升开发效率。

经过几年的探索和逐步优化，也得益于Flink社区的逐步成熟，利用FlinkSQL构建实时数仓已经完全可行，国内外各同行公司包括我们商业化也将其在生产上推广应用。然而，新技术的落地远远不是简单的安装配置部署，我们需要在数仓层面进行平台化，在打通各个资产组件的基础上，为用户提供一站式的开发平台，同时做好数据的治理、平台权限的治理，以避免数据和平台的滥用。在开发者角度，开发效率是至关重要的，快速开发且易于维护是平台的核心价值；在数据效能的角度，数据质量是数仓的核心价值，“无治理不数仓”。

02

ULTRON是什么

ULTRON是360商业化大数据架构团队构建的实时数仓开发平台。如前所述，在数据准确性、数据及时性、框架稳定性、开发易用性以及与现有架构的融合这几点上综合衡量，Ultron选择FlinkSQL为核心，构建了一个一站式的数仓开发平台，集项目构建、集群部署、资产管理、数仓建模、作业开发、上线发布、运维监控等功能于一身，提供一站式实时数仓解决方案。

03

ULTRON能做什么

简而言之，ULTRON以实时数仓为核心场景，为开发者提供了从数据集成、数据ETL、OLAP多维分析、数据可视化等全链路的支持。ULTRON以FlinkSQL为基座，主要面向数仓场景设计，侧重海量数据实时统计和报表分析。在ULTRON，数仓开发者可以一站式的轻松构建数仓模型、开发ETL作业、导入OLAP进行多维分析并进行简单的数据探索和可视化图表配置。

在实时数仓开发流程中，各个场景采用技术方案和系统组件也会不一样，Ultron已经支持的场景和流程可以参考下图：

注：部分功能如离线数仓建模与作业调度、Iceberg数据湖集成等还在平台集成中

在ULTRON上，数仓开发者可以完成：

1. 数据集成：包括收集日志到Kafka、Kafka异地数据同步、Kafka数据落地离线HDFS、数据库（MySQL/TiDB）Binlog收集等。

2. 数据资产管理：以资产的方式管理存储资源如Kafka Topic的申请、创建以及相应权限的申请。

3. Flink集群与作业管理：包括Flink集群自助申请、部署、扩容、运维监控；Flink作业的上下线、重启、版本追踪、运维监控等。

4. 数仓开发：包括数仓建模、UDF管理、作业的开发配置、测试、发布等

5. OLAP多维分析：ETL后数据入OLAP后通过Superset或者API进行数据的多维度交互式探索分析，支持的OLAP引擎包括Druid/Presto/ClickHouse/TiDB等

6. 数据质量：包括利用数据地图快速找到数据；利用血缘分析快速追踪数据的流向和作业依赖；利用模型规范约束模型分层、主题域、命名规范等数仓治理手段

同时，ULTRON以项目方式管理，提供了申请加入项目、创建项目、以及项目内的权限管理、成员管理等基础功能。

04

ULTRON不能做什么

1. ULTRON是开发者平台，基于底层基础设施构建平台，面向开发者提供数仓的整个开发流程的支持；ULTRON试图尽量简化和打通数仓开发过程中涉及到底层基础设施的账号、权限等流程，但ULTRON不是运维平台，不负责实时数仓底层基础设施的安装、部署、运维、优化等功能，这些功能由专门的平台来支撑。

2. ULTRON是面向数仓的，侧重在数仓开发和数据治理，提供数仓场景下的数据ETL处理和分析能力；对于数据应用层面比如机器学习、算法分析、复杂事件处理、数据可视化等，ULTRON仅能提供数据处理能力的支持，不能提供上层场景的应用能力。

05

ULTRON的核心优势

1. 一站式

ULTRON提供的是数仓开发的一站式体验，从数据集成到集群部署，从数仓建模到作业开发、测试、上线，再到OLAP多维分析和简单的数据验证和可视化，以及整个过程中的资源扩容、报警监控等，ULTRON希望尽量集成到一个平台完成，而不是各个环节割裂，让开发者问东问西，或者开发者自己来操心一些监控报警配置等操作。

数据开发是一个复杂的过程，涉及到的底层基础设施的各种交互，比如Kafka/HBase/数据库/离线Hive以及Flink集群的账号、权限等。站在平台维护角度，希望底层基础设施的使用是规范而可治理的；站在开发者的角度，希望开发流程是简单的、顺畅的。ULTRON将数仓开发流程化，将开发过程中所涉及到的各个底层基础设施的交互编织入开发流程中，让开发者更关注在数据开发的业务逻辑上，少操心和折腾底层的细节，在流程中为开发者自动提供平台支撑，为底层平台提供有效账号和权限治理。

举例来说，在ULTRON，申请部署一个Flink集群是非常Easy的，1分钟即可为当前项目申请一个可用的集群。而这个申请过程中，与底层K8S/YARN的账号权限的创建、配额资源的申请、集群部署涉及到的各种复杂配置、集群的监控数据收集、可用性报警等，ULTRON平台会自动完成。1分钟后集群可用，这些保障手段也同时打包提供给用户。后续集群版本升级也非常简单，只需要选择相应新版本的Docker镜像后重新配置部署即可。

好的平台，应该要解藕用户需求和底层逻辑。上，面向用户需求提供简单易用的流程，下，对底层基础设施封装，减少暴露细节。中间的平台层要自动化（自动完成开发流程中涉及的账号、权限、监控等）、可迭代（保障前后兼容可升级迭代或替换）。

1. 面向数仓

从广义角度，要完成报表，任意的ETL手段都能够最终实现，比如我们原来的很多项目就是各种烟囱式开发，只要能最终产出报表就可以。数据是用来发挥数据效能的，数仓只有规范有效治理才能可持续、易维护，否则数据就是一锅粥，大家各自取一瓢。

以FlinkSQL作业开发为例，常见的逻辑是消费Kafka Topic1经过JobA ETL处理后写回另一个Kafka Topic2。如果没有平台支撑，用户当然可以直接用Flink原生的DDL语句来基于Topic1创建Flink Table，如下所示：

CREATE TABLE KafkaTable (
  `user_id` BIGINT,
  `item_id` BIGINT,
  `behavior` STRING,
  `ts` TIMESTAMP(3) METADATA FROM 'timestamp'
) WITH (
  'connector' = 'kafka',
  'topic' = 'user_behavior',
  'properties.bootstrap.servers' = 'localhost:9092',
  'properties.group.id' = 'testGroup',
  'scan.startup.mode' = 'earliest-offset',
  'format' = 'csv'
)

以上DDL语句中涉及到的表字段、数据格式、集群连接信息、认证信息以及一些负责的表参数等等。站在数仓的角度，有很多问题值得思考：

1）如何保证表字段是正确设置且前后Schema兼容的？

2）如何保证这些参数都是正确配置的？

3）如何保证集群连接信息如地址、认证账号密码等是不被滥用或者冲突使用的？

4）如何保证这个元数据信息是可复用的，可被其他项目直接使用且口径一致？

……

这些问题不解决，直接交给用户为了完成结果而粗糙的、重复的进行ETL开发，难免走向烟囱式开发的老路。

ULTRON面向数仓设计，将各个存储资源资产化管理、再将资产进行数仓化建模，建立起一套元数据治理的体系，以上所提到的Schema兼容、模型复用性、权限认证、参数正确配置等问题均可以在元数据层面有效解决。面向模型管理和治理数据，即简化了用户使用、避免了错用滥用，也有效的做好了数据治理和平台治理。

1. 简单易用

这体现在两个方面：

一方面，我们统一和规范了数仓的开发流程，并为此进行了很多自动化操作。从构建项目、部署集群、作业开发、测试、发布部署到后续的运维监控和配额管理，平台屏蔽了底层的很多复杂的细节的同时，又自动自助的提供给用户所需要的各种支撑能力。

另一方面，我们尽量提供给用户一个完整的好用的开发IDE，在这个IDE中完成大部分开发工作。

ULTRON的目标是想开发者所想，让开发者减少不必要的沟通和重复的配置工作，更专注在业务逻辑开发。

1. 通用平台与资源云化管理

Ultron设计时就作为一个通用平台，即不是为某个基础设施定制的。数仓开发所涉及的资源，我们抽象为计算资源池和存储资源池。计算资源池如K8S/YARN，存储资源池如Kafka集群/HBase集群/ES集群/数据库实例等。我们可以在后台管理中对接任意资源，即可纳入平台提供服务。比如数据在某Kafka集群中，需要对该数据进行ETL处理。在后台管理中注册该Kafka集群即可完成资产对接，然后基于该集群下的Topic构建模型，纳入元数据管理，就可以在SQL作业中申请使用该集群的数据了。

资源对接需要注意的有两点：

1）权限：计算资源与存储资源的对接考虑到了权限隔离。资源只能挂靠给某部门组织，只有该部门的项目才可以访问，对非该部门的项目不可见。这样就避免了基础设施跨部门滥用和成本核算不清的问题，用户无需担心。

2）跨地域：我们很多基础设施资源是分散在全国各地IDC的，在大数据场景下，跨IDC之间的处理应该要尽量避免。比如我们不允许Flink Job跨IDC访问另一个IDC的Kafka，这将增大跨城网络带宽成本，也造成光纤中断带来的可用性风险。ULTRON参考AWS Region/Zone的地域划分思想，在对接资产时确定其所在的Region/Zone。还是以Kafka为例，与Flink集群所在的K8S或YARN集群同Region下的Kafka集群可访问，跨Region不可访问，需要通过MirrorMaker进行异地复制。

06

ULTRON功能演示

我们以一个简单的Demo演示下在ULTRON上进行数仓开发的基本操作。

 注：点击播放

关于Ultron的介绍和更多平台功能，去年FFA上做过分享，由于功能迭代发生了很多变化和新功能升级，后续将再整理出一篇介绍。

07

实时数仓开发系列

为了知识沉淀和共享，我们准备了《实时数仓开发系列》，介绍基于FlinkSQL如何进行实时数仓建设，本篇为前言。我们站在数仓角度，探索利用FlinkSQL进行实时数仓ETL和OLAP的基本思路和开发流程，并给出了一些Demo便于用户理解和实践。

整个系列按照数仓开发流程为主线，大纲如下：

1. ODS原始数据接入：介绍如何将Kafka中已有的原始日志入仓并进行建模。

2. DIM维表数据接入：介绍两种实时维表的接入方式，用于实时数仓建设中维度打宽。一是直接基于外部存储访问方式如HBase/MySQL/TiDB/Redis等，二是基于数据库CDC数据（binlog）方式。

3. DWD数据抽取：介绍如何利用FlinkSQL对ODS数据进行抽取转换加工的基本方法。

4. DWD宽表打宽：介绍利用FlinkSQL在实时基于维表进行实时打宽（实时Join）的基本原理和方法。

5. DWS数据聚合：介绍利用FlinkSQL进行实时聚合统计分析的基本方法。

6. 实时OLAP：介绍将实时数据摄入OLAP进行实时多维分析的基本方法，目前支持的OLAP引擎包括Druid/ClickHouse/TiDB。

7. 与离线Hive结合：介绍利用FlinkSQL如何与离线Hive数仓结合的基本方法，实现流式数据实时入Hive仓库，流式任务访问离线Hive数仓数据等操作。

8. 与Iceberg结合：介绍FlinkSQL如何与Iceberg数据湖相结合，实现流式数据实时入湖，湖上仅实时数据分析的基本方法。

9. FlinkSQL开发技巧篇：介绍在FlinkSQL开发过程中，针对常见场景如数据倾斜、状态清理、并行度调优等的技巧和优化思路。

10. 性能优化篇：介绍Flink任务部署后进行运维监控和性能优化的思路和实践经验，以保障作业稳定高效可靠。