完整解决方案:基于Flink的高可靠实时ETL系统

　　完整解决方案:基于Flink的高可靠实时ETL系统

　　GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是由长期关注互联网技术和架构的高可用架构技术社区和msup发起的面向架构师、技术领袖和高端技术从业者的年度技术架构会议。这是中国最大的技术。其中一次会议。

　　在今年的第六届GIAC大会上，腾讯数据平台部实时计算负责人石晓刚以大数据架构为主题，发表了“基于Flink的高可靠实时ETL系统”的主题演讲。以下为嘉宾致辞实录：

　　石晓刚毕业于北京大学，获得博*敏*感*词*。并且是 Apache Flink 项目的 Committer。在SIGMOD、TODS、IPDPS等国际顶级会议和期刊发表多篇论文，并担任KDD、DASFAA等国际顶级会议的程序委员会成员。

　　实时计算平台 Oceanus

　　近年来，实时计算在腾讯的应用越来越广泛。为了提高用户流计算任务持续集成和持续发布的效率，腾讯大数据团队从2017年开始围绕Flink打造Oceanus，一个集开发、测试、部署、运营于一体的一站式可视化实时计算平台，维护。

　　Oceanus提供Canvas、SQL、Jar三种不同的应用开发方式，满足不同用户的开发需求。通过这三种方式，不同应用场景的用户无需了解底层框架的技术细节，即可快速开发实时计算任务，降低用户开发门槛。

　　完成作业开发后，用户可以通过 Oceanus 对作业进行测试、配置和部署。Oceanus 为用户程序提供了一系列工具来辅助作业测试。用户既可以使用Oceanus提供的一键生成功能生成测试数据，也可以将自己的测试数据上传到Oceanus，通过比较预期结果和实际结果来验证应用逻辑的正确性。Oceanus 依靠腾讯内部资源调度系统 Gaia 进行资源管理和作业部署。用户可以通过Oceanus配置作业所需的CPU和内存资源，指定作业需要部署的集群。用户完成配置后，Oceanus 会向 Gaia 申请相应的资源，并将作业提交给 Gaia 运行。

　　Oceanus 对 Flink 作业的多个运行指标执行采集，包括 Task Manger 的内存、I/O 和 GC。通过这些丰富的运行指标，用户可以很好地了解应用的运行情况，并在出现异常时帮助用户及时定位问题。运维人员可以通过这些采集获取的指标设置告警策略，实现精细化操作。

　　在Oceanus之上，腾讯大数据还为ETL、监控告警、在线学习等常见实时计算任务提供场景化支持。例如，Oceanus-ML 提供端到端的在线机器学习，涵盖数据访问、数据处理、特征工程、算法训练、模型评估和模型部署的整个机器学习过程。借助Oceanus-ML，用户可以轻松使用完整的数据处理功能和丰富的在线学习算法构建自己的在线学习任务，轻松完成模型训练和评估，一键部署模型。

　　针对ETL场景，Oceanus还提供Oceanus-ETL产品，帮助用户将应用和产品中的采集数据实时导入数据仓库。目前，腾讯大数据团队为腾讯内部多个业务提供数据接入服务，包括微信、QQ音乐、腾讯游戏等。每天处理的消息量超过40万亿条，每秒访问峰值超过40亿条。

　　实时数据访问平台 Oceanus-ETL

　　腾讯大数据早在2012年就开始数据接入，并基于Storm打造了第一代腾讯数据银行（TDBank），成为腾讯大数据平台的前线，提供文件、消息和数据库等多种接入方式，统一数据访问门户，并提供高效、实时的分布式数据分发。

　　2017年，腾讯大数据基于Flink在易用性、可靠性和性能方面的优势，重构了TDBank通过Flink的数据访问。与 Storm 相比，Flink 提供了更多的状态支持。一方面，Flink 将程序的状态保存在本地内存或 RocksDB 中，用户无需通过网络远程访问状态数据，可以获得更好的工作性能。另一方面，Flink 通过 Chandy-Lamport 算法提供了一种高效、轻量级的检查点机制，可以保证 Exactly Once 和 At-Least Once 的数据处理语义在发生故障时仍然可以实现。

　　随着腾讯业务规模的不断扩大，对数据接入也提出了更高的要求。

　　为了满足上述需求，我们今年引入了 Iceberg，通过 Iceberg 提供的 ACID 事务机制和增量更新能力，提供更可靠、更强大的数据访问服务。

　　基于 Flink 实现端到端的 Exactly Once 传输

　　Flink 使用 checkpoint 机制来备份和恢复任务状态。在任务失败的情况下，可以从上次备份的状态恢复任务，而无需从头开始重新执行。通过 checkpoint 机制，Flink 可以保证在发生故障的情况下仍然可以实现 Exactly Once 的数据传输。

　　但在整个数据接入环节，除了Flink之外，还包括上游中间件、下游数仓等多个组件。仅仅依靠 Flink 的 checkpoint 机制只能保证 ExactlyOnce 在 Flink 作业内的数据传输，而不能保证端到端的 ExactlyOnce 在整个数据访问链路中的传输语义。如果我们将 Flink 接收到的数据直接写入下游存储系统，那么当 Flink 发生故障并从故障中恢复时，自上一个 checkpoint 以来写入下游存储系统的数据会出现重复，导致后续数据分析出错。

　　为了保证端到端的 Exactly Once 数据传输，TDBank 使用 Flink 的 checkpoint 机制实现了两阶段提交协议，对数据访问的各个环节产生的指标进行聚合和协调，以保证数据的端到端. 传输可靠性。

　　为了保证数据链接的 Exactly Once，我们首先将 Flink 接收到的数据写入一个临时目录，并保存写入的文件列表。当检查点执行时，我们会将这些文件的列表保存到检查点并记录下来。并且当检查点完成时，Flink 会通知所有节点。此时，这些节点会将checkpoint中保存的文件移动到官方目录。

　　在这个实现中，Flink 使用现有的 checkpoint 机制来实现两阶段提交机制。所有节点在执行 checkpoint 时都会执行 pre-commit 操作，并将所有数据先写入可靠的分布式存储。当 JobManager 上的检查点完成时，事务被视为已提交。所有节点在收到检查点成功消息后都会完成最后的事务提交操作。

　　如果任何节点在执行最后一个文件移动时发生故障，Flink 作业将从最后一个完成的检查点恢复，并从最后一个完成的检查点获取文件的完整列表。Flink 作业会检查此文件列表中的文件，并将所有尚未移动的文件移动到最终目录。

　　为了保证整个访问过程中数据不会丢失和重复，我们会采集并核对整个数据链路中各组件收发的数据数量。由于通用指标体系无法保证指标的及时性和正确性，我们也基于 Flink 实现了高可靠一致的指标聚合。

　　与数据链路类似，我们也使用 Flink 的 checkpoint 机制来保证指标数据的一致性。我们通过 Flink 对 采集 接收到的指标进行细粒度的聚合，并在执行检查点时将这些聚合的指标保存到外部存储中。在保存聚合指标时，除了一般的标签外，我们还会在写入这些指标时带上检查点编号。当检查点完成时，每个节点也会将完成的检查点编号记录到外部存储中。当我们需要查询指标时，只需将完成的检查点编号与聚合指标连接起来，即可获得一致的指标结果。

　　通过 Flink 的 checkpoint 机制，我们可以保证数据链路和指标链路中数据传输和指标聚合的一致性，保证整个数据访问链路中端到端的 Exactly Once 数据传输。

　　基于 Iceberg 的 ACID 实时数据访问

　　Apache Iceberg 是一种通用的表格格式（数据组织格式），可以适配 Presto、Spark 等引擎，提供高性能的读写和元数据管理功能。Iceberg的定位是在计算引擎下的存储之上。它是一种被冰山称为“表格格式”的数据存储格式。准确地说，它是介于计算引擎和数据存储格式之间的一种数据组织格式——数据和元数据以特定的方式进行组织，因此称其为数据组织格式更为合理。

　　Iceberg 通过锁定机制实现 ACID 功能。它从元存储中获取锁，并在每次更新元数据时更新它。同时，Iceberg 保证了线性一致性（Serializable 隔离），保证了表修改操作是原子的，读操作永远不会读取部分或未提交的数据。Iceberg 提供了乐观锁机制来减少锁的影响，并使用冲突回退和重试机制来解决并发写入引起的冲突。

　　Iceberg 基于 ACID 能力，提供类似于 MVCC 的读写分离能力。首先，每次写操作都会产生一个新的快照（snapshot），总是向后线性递增，保证线性一致性。读取操作只读取现有的快照，对正在生成的快照读取操作是不可见的。每个快照都有当时表的所有数据和元数据，从而为用户提供了对表数据进行时间旅行的能力。使用 Iceberg 的时间旅行能力，用户可以读取当时的数据，同时也为用户提供回滚快照和重放数据的能力。

　　与 Hudi 和 Delta Lake 相比，Iceberg 提供了更完整的表格格式能力、类型定义和操作的抽象，以及与上层数据处理引擎和底层数据存储格式的解耦。此外，Iceberg 在设计之初并没有绑定特定的存储引擎，同时避免了与上层引擎的相互调用，从而可以方便地扩展 Iceberg 以支持不同的引擎。

　　在数据访问上，可以通过 Iceberg 保证 ACID 事务和强一致性，实现“一个且唯一”的写入；读写分离使交互式查询引擎（如 Hive 和 Presto）能够在第一时间读取到正确的数据；行级更新和删除支持通过计算引擎进行数据修正；增量消费使落地数据进一步返回到流引擎，只处理和回传变化的部分；冰山高效的查询能力，还可以省去 MySQL 或 ClickHouse 等环节的导入，直接被报表和 BI 系统消费。

　　为了能够使用 Iceberg，腾讯大数据实现了支持 Iceberg 的 Flink 连接器，让 Flink 可以将数据写入 Iceberg。Flink 的 Iceberg Sink 由两部分组成，一个叫 Writer，一个叫 Committer。Writer负责将接收到的数据写入外部存储，形成一系列DataFile。目前，腾讯为了简化适配，最大限度地利用现有逻辑，使用Avro作为数据的中间格式。后续社区将引入 Flink 内置类型转换器，使用 Iceberg 内置数据类型作为输入。当 Writer 执行 checkpoint 时，Writer 会关闭自己的文件，并将构造好的 DataFile 发送给下游的 Committer。

　　提交者在 Flink 作业中是全局唯一的。Committer 收到所有上游 writer 发送的 DataFiles 后，会将这些 DataFiles 写入一个 ManifestFile，并将 ManifestFile 保存到 checkpoint。当 checkpoint 完成后，Committer 会通过 merge append 将 ManifestFile 提交给 Iceberg。Iceberg会通过一系列操作完成commit操作，最终使新增的数据对下游数仓可见。

　　腾讯对 Iceberg 做了很多改进和优化。除了支持 Flink 的读写操作，腾讯还完成了行级的删除和更新操作，大大节省了数据修改和删除的成本。同时，腾讯还对 Spark 3.0 中的 Data Source V2 进行了适配，利用 Spark 3.0 中的 SQL 和 DataFrame 无缝连接 Iceberg。

　　在未来的工作中，腾讯将继续提升 Iceberg 的核心能力，包括：

　　直观:iS-RPM知识点4 | 灵活配置采集策略，精准捕捉桌面数据！

　　朋友们，好久不见。在上一篇文章中，我与大家分享了如何安装和配置RPM采集器。安装客户端后，我们现在可以开始任务挖矿之旅了。.

　　但是，在执行数据采集之前，我们需要定义相应的采集策略，以更准确的捕捉用户的业务操作行为。

　　本文主要介绍创建任务挖掘项目后如何配置其数据采集策略。以下内容主要分为以下五个配置内容：采集的目标应用、采集的目标应用数据内容、数据隐私保护、客户端启动方式、数据传输。

　　注意：创建项目时将初始化默认策略。如果管理员不修改策略内容，用户入队后默认使用初始化策略。

　　01策略一：采集的目标应用

　　查看和管理需要捕获的指定应用程序列表是记录业务流程的必要步骤。一旦管理员设置了列表内容，客户端在获取策略后只会记录那些应用程序或网页的数据。应用列表分为以下3种配置模式：

　　注意：初始默认配置是采集所有应用程序。

　　02策略2：采集的数据内容

　　通过数据内容配置选项，可以自定义需要采集的业务规则和事件内容。包括但不限于：时间戳、截图、应用名称、网页URL、控件名称、坐标等基本信息。

　　采集用户行为数据（时间戳、事件类型、事件详情等）获取有效信息。

　　1、采集使用应用程序/网页时用户窗口的屏幕截图（例如：每次点击或滚动都会截取屏幕截图）。

　　2、屏幕截图将同时采集触发事件的窗口和区域。

　　注意：初始化的默认配置是采集基本数据，不选择截图。

　　03策略三：数据隐私保护

　　一方面，iS-RPM 的采集 政策支持相关用户的匿名化，保护用户隐私。另一方面，由于 RPM 的隐私政策，默认情况下会启用“显示用户同意对话框”选项。如果策略启用“隐私同意”配置，最终用户需要加入指定的项目团队，并且在开始用户录制过程之前，会首先弹出用户同意对话框接受或拒绝录制条款和条件，以及用户需要选择同意策略。捕获桌面应用程序/网页数据。

　　捕获数据后，系统会将数据发送到 RPM 服务器进行分析和管理。我们会将数据保存在高度安全的存储中。

　　启用后，最终用户需要加入指定的项目团队。当 RPM 客户端第一次运行记录时，会显示一个隐私确认对话框。用户必须接受隐私条款才能捕获数据，否则客户端将被注销。

　　通过处理采集的目标用户的假名化（例如：“张三”被匿名化为“用户1”）

　　04策略四：客户端启动模式

　　通过设置采集器的操作模式，可以灵活控制采集器何时开始记录员工的桌面操作，减少不必要的存储空间占用。

　　每次用户启动计算机时，RPM 客户端都会自动启动 采集data。

　　当需要记录时，用户将手动启动客户端并单击“开始”按钮手动开始捕获数据。

　　注意：初始化的默认配置是开机自动启动。

　　05策略五：数据传输

　　1.最大本地存储空间阈值（GB）：用户可以在本地存储的最大数据量。

　　2.最大本地磁盘占用率（%）：用户可以占用的最大空闲数据量/用户本地磁盘的总容量。

　　注意：当达到“本地存储”部分中的任何目标时，Data采集 任务将立即停止。

　　1.上传文件速度（KB/s）：用户上传文件时占用的网络带宽。

　　2.同时上传任务数：客户端运行时可以同时上传的文件数。

　　3.自动上传间隔（分钟）：配置客户端自动生成采集并上传文件的时间间隔。

　　注意：自动上传间隔时长：系统达到上传时间间隔后，会自动触发上传任务数据，实时更新数据。（用户也可以在达到时间间隔前手动停止采集，达到自动上传间隔后系统会自动上传数据）

　　一个。本地存储最大空间阈值：10GB

　　湾。最大本地磁盘使用率：90%

　　C。上传文件速度：256KB/s

　　d。同时上传任务数：5

　　e. 自动上传间隔：10分钟

　　-结尾-

　　过程挖掘

　　更多新闻

　　点击阅读文字