照片拍摄于2014年夏，北京王府井附近 大家好，我是一哥，今天分享一篇数据实时入湖的干货文章。 ; b）实时方式 SET execution.type=streaming; SELECT COUNT(*) FROM IcebergTable; 2，数据入湖速度测试 数据入湖速度测试会根据环境配置 数据入湖分为append和upsert两种方式。 3，数据入湖任务运维 在实际使用过程中，默认配置下是不能够长期稳定的运行的，一个实时数据导入iceberg表的任务，需要通过至少下述四点进行维护，才能使Iceberg表的入湖和查询性能保持稳定。 并增加小文件监控、定时任务压缩小文件、清理过期数据等功能。 2，准实时数仓探索 本文对数据实时入湖从原理和实战做了比较多的阐述，在完成实时数据入湖SQL化的功能以后，入湖后的数据有哪些场景的使用呢？
翻译一下：Azure数据湖服务是2016年11月16日发布的。Azure数据湖是在微软内部的大数据平台Cosmos的技术和经验教训基础上构建的。 Cosmos系统的具体细节，大家可以参阅我早年的文章：大数据那些事(15):Cosmos的技术。这里给一个简单的回顾。Cosmos底层是类似Google File System的文件存储系统。 这位请来没多久，就对大数据这一块产生了兴趣，顺理成章的成为了Cosmos这个部门的大领导。 Raghu这个人我有很矛盾的看法。一方面作为威斯康辛的教授，数据库领域的大牛，其学术贡献不可忽视。 这个新系统要摈弃掉Cosmos老的存储，改用Azure Blob Store。查询语言要摈弃SCOPE，改用更SQL的语言，也就是后来的U-SQL。 Cosmos一度进入了风雨飘摇的状态，很多老人都走了，我也差不多在Raguh入职一年后走了。
2核2G云服务器 每月9.33元起，个人开发者专属3年机 低至2.3折
答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。升级架构升级之后的架构如下，我们引入了 Iceberg。 Iceberg 何以能做近实时入湖我们以 Flink 写入 Iceberg 为例详细阐述为何 Iceberg 只能做近实时的入湖，如下图所示:图片其中，IcebergStreamWriter 主要用来写入记录到对应的 因此 Iceberg 只能做近实时的入湖：Iceberg 提交 Transaction 时是以文件粒度来提交的，这就无法以秒为单位提交 Transaction，否则会造成文件数量膨胀Flink 写入以 数据入湖对于数据入湖用户可能最关心的就是数据一致性问题。数据同步链路我们可以采用 Flink，可以保证 Exactly once 的语义，当作业发生故障，能够做严格的恢复，保证数据的一致性。 本文将介绍一个比较常用的数据入湖的使用场景，MYSQL 分库分表的数据同步到 Iceberg 中的一张表中。本地实操可参考Flink CDC构建实时数据湖[1]。
答案是肯定的，这就是本文要介绍的流批一体、仓湖融合的升级架构解决方案以及高效的数据入湖配套方案。 升级架构 升级之后的架构如下，我们引入了 Iceberg。 Iceberg 何以能做近实时入湖 我们以 Flink 写入 Iceberg 为例详细阐述为何 Iceberg 只能做近实时的入湖，如下图所示: 其中，IcebergStreamWriter 因此 Iceberg 只能做近实时的入湖： Iceberg 提交 Transaction 时是以文件粒度来提交的，这就无法以秒为单位提交 Transaction，否则会造成文件数量膨胀 Flink 写入以 数据入湖 对于数据入湖用户可能最关心的就是数据一致性问题。数据同步链路我们可以采用 Flink，可以保证 Exactly once 的语义，当作业发生故障，能够做严格的恢复，保证数据的一致性。 本文将介绍一个比较常用的数据入湖的使用场景，MYSQL 分库分表的数据同步到 Iceberg 中的一张表中。本地实操可参考 Flink CDC构建实时数据湖 [1]。
IcebergTable;---- *b.实时方式* ----SET execution.type=streaming;SELECT COUNT(*) FROM IcebergTable; 2.2 数据入湖速度测试数据入湖速度测试会根据环境配置 3.3 顺序性数据入湖否可保证全局顺序性插入和更新？ 最后启动Flink任务实时写入数据湖，且从Kafka中指定消费时间要早于批量同步的数据，因为存在主键，数据库提供upsert的能力，对相同主键的数据进行更新覆盖。 四、未来规划高新的技术最终是要落地才能发挥其内在价值的，针对行内纷繁复杂的数据，结合流计算Flink和数据湖技术，在未来的落地规划集中在两个方面，一是数据湖集成到本行的实时计算平台中，解决易用性的问题; 并增加小文件监控、定时任务压缩小文件、清理过期数据等功能。4.2 准实时数仓探索本文对数据实时入湖原理做了比较多的阐述，入湖后的数据有哪些场景的使用呢?下一个目标当然是入湖的数据分析实时化。
高可扩展的 Catalog 元数据服务 随着数据量的快速增长，数据仓库需要能够处理快速增加的分区和文件。 具体来说，当计算引擎产出要提交的各个分区的文件后，会首先提交分区文件更新的信息，例如全量更新或增量更新，然后通过元数据事务操作来更新读者可见的版本。 在 2.0 版本更新中，还支持了 Flink CDC 实时写入，通过将 CDC 更新流转化为 LakeSoul 的 Upsert 操作，能够实现高效的实时入湖。 通过对接 Flink Table API，同样能够通过几行 SQL 完成在线数据库的 CDC 入湖。 5. 实时数据入湖的架构流程： 可以看到 LakeSoul 实时入湖只需要一条流式的链路即可完成入湖，不需要额外的批处理流程，既简化开发工作量，消除数据口径不一致，也简化了部署架构，显著降低了运维成本。
这篇文章就数据湖的入湖管道为大家详细解答关于 COS 数据湖结合 Serverless 架构的入湖方案。 传统数据湖架构分入湖与出湖两部分，在上图链路中以数据存储为轴心，数据获取与数据处理其实是入湖部分，数据分析和数据投递其实算是数据出湖部分。 入湖部分是整个数据湖架构的数据源头入口，由于数据湖的高便捷可扩展等特性，它需要接入各种数据，包括数据库中的表（关系型或者非关系型）、各种格式的文件（csv、json、文档等）、数据流、ETL工具（Kafka 总结来看，整体数据湖链路中定制化程度最高，使用成本及代价最大的其实是数据入湖部分（指数据获取和入湖前的数据处理）。这块内容往往也是实现的数据湖架构比较核心的数据连接。 化封装为数据入湖，数据出湖提供更多能力拓展。
数据入湖 数据入湖有一定的标准，包括明确数据owner，发布数据标准，认证数据源、定义数据密级、评估数据质量和注册元数据。 数据入湖的方式 有物理入湖和虚拟入湖，物理入湖是指将数据复制到数据湖中，包括离线数据集成和实时数据集成两种方式。如果你对报表实时性要求很高，比如支撑实时监控类报表，那就需要入实时区。 对报表实时性要求不高的，比如支撑年月季度等统计报表，可以入离线区。 虚拟入湖指原始数据不在数据湖中进行物理存储，而是通过建立对应虚拟表的集成方式实现入湖，实时性强，一般面向小数据量应用。 贴源or整合 贴源入湖是指入到SDI层，SDI层基本就是copy原系统数据一份，不做多余的处理。而贴源整合是入到DWI层，DWI层会遵从三范式，做多源整合，维度拉通等处理。 DM-Data Mart 数据集市， DM层数据来源于DWR层，面向展现工具和业务查询需求。DM根据展现需求分领域，主题汇总。 数据出湖 数据入了湖，自然要出湖，出湖即数据消费。
字节跳动超大数据量场景下 CDC 入 Hive 数仓遇到的挑战； 2. 数据湖选型过程与思考； 3. 入湖技术方案以及我们做的优化； 4. 业务落地场景和收益； 5. 未来的计划。 本次分享我们将探讨现有入湖入仓技术的典型架构和面临的痛点，包括海量 DB 数据的高效接入、数据一致性的语义保证、表结构的频繁变更等等。 最后，我们会通过一个 demo 来展示如何使用 Flink CDC 完成 MySQL 到 Hudi 的整库数据入湖，并演示表结构变更的自动同步，整个 demo 只使用了几行 SQL，让观众深切体会到数据入湖本应如此 湖仓一体 = 存储流批一体； 3. 技术方案（文件索引，ingestion，compaction 服务）； 4. 应用实践； 5. 未来规划。 日志表数据入湖的挑战和解决方案； 3. CDC 表数据入湖的最佳实践； 4. Iceberg 社区 Flink 模块现状和进展。
B、Spark 入湖任务，读取1小时的 HDFS 分钟级日志 + ETL + 入湖。任务入湖采用 overwrite 模式，一次写入一个小时的完整数据，保证任务的幂等性。 2.2 实时化改造 - 实时湖仓 在项目建设初期，我们选择了小时级入湖，没有急于上线实时入湖，主要基于下面几点考虑： A、基于分区设定，小时入湖可以做到幂等性，批量一次性覆盖写入，方便调试和测试，快速打通上线基于数据湖的日志数仓 针对这些考虑点，结合 Spark batch 入湖积累的经验，我们建设了基于 Flink 的实时入湖链路，如下图所示： 基于 Flink 的分钟级入湖任务，实时消费消息队列 + ETL + 写入数据湖 统一的数据存储 不同于之前的方案将数据采用不同的格式存储且分散在不同的HDFS路径上，在数据入湖后数据统一存储在数据湖中，用户不需要关心底层的数据格式，对用户暴露出来是统一的表。 同时数据湖还提供了异步的优化任务：合并小文件，优化表结构，表级别/列级别的TTL，清理垃圾文件等服务。 接下来我们从入湖，湖上分析和优化服务三个方面介绍我们遇到的问题和改进。
构建ODS实时增量数据层，实时ODS增量层主要作用有两方面：•依赖ODS实时增量数据（保留原始格式，不做清洗转化）每日离线入湖来构建ODS层离线湖仓，ODS层数据后续作为业务数据的备份、满足DWD层全量数据重做需求 针对这一问题，目前我们通过两个层面来进行处理： •推进上游进行数据治理，尽可能控制延迟数据，重复数据的上传•代码层进行优化，设定时间范围开关，控制每日入湖的数据在设定时间范围内，避免延迟较久的极少量数据入湖降低表每日更新性能 ；对于延迟较久的数据汇集后定期入湖，从而降低整体任务性能开销 3.6 数据特性适应问题 从数据入湖的性能测试中来看，Hudi性能跟数据组织的策略有较大的关系，具体体现在以下几个方面： •联合主键多字段的顺序决定了 Hudi中的数据排序，影响了后续数据入湖等性能；主键字段的顺序决定了hudi中数据的组织方式，排序靠近的数据会集中分布在一起，可利用这个排序特性结合更新数据的分布特性，以尽可能减少入湖命中的base文件数据 ，入湖性能应该会有较好的提升； 4.
《系统日报》持续关注分布式系统、AI System，数据库、存储、大数据等相关领域文章。每天以摘要的形式精选不超过三篇系统文章分享给大家。 有过，还算比较幸运，因为都知道云是未来，但不知道这个未来是多久后来。比如 Cloudera 在 08-09 年成立时，从名字就可以看出想开启云时代，但生不逢时，后来还是改变了策略。 刚开始，新入职的员工和融资时，All in Cloud 都会受到挑战，但是到 2018~2019 年左右就开始形成了共识，没人挑战了。 相对云厂商自身产品有什么优势？ 为什么决定做湖仓一体？ 计算自然延伸到存储，开始做数据湖（面向数据科学家、深度学习场景）。为了消除用户组织内部的数据壁垒，自然想能不能打通数据湖和数据仓库（面向 BI ）？ 于是提出湖仓一体（Lakehouse）。 此外，辛湜还分享了通过“引荐”的招人制度，以及创业公司中一些问题。播客是个好媒介，可以利用碎片时间，一边听一边思考。
高效数据入湖通过⾃研批流⼀体数据集成框架 ChunJun，可视化的任务配置，将外部数据高效入湖，让数据具备更高的新鲜度。 ・引入 ChunJun，提供数据同步效率实现秒级快速入湖・全数据同步量 / 增量一体化，链路短组件少开发维护成本低・不影响在线业务的稳定2. 在线数据目录可为数据湖的计算引擎提供 Schema 管理功能；离线数据治理包括，小文件合并、快照清理、孤儿文件清理能治理能力，可以有效降低数据存储提高数据查询效率。 快照管理袋鼠云数据湖平台支持快照历史管理，支持多版本间快照变更对比，支持湖表时间旅行，一键回滚到指定数据版本。数据入湖创建入湖任务，选择一张 Hive 进行转表入湖，一键生成湖表信息。 对比数据同步入湖，可以节省 10x 倍数据的传输时间。数据文件治理创建数据文件治理任务模板，支持小文件合并、快照清理、孤儿文件清理等数据文件治理任务，支持立即支持、预约治理、周期治理多种数据治理方式。
B、Spark 入湖任务，读取1小时的 HDFS 分钟级日志 + ETL + 入湖。任务入湖采用 overwrite 模式，一次写入一个小时的完整数据，保证任务的幂等性。 2.2 实时化改造 – 实时湖仓 在项目建设初期，我们选择了小时级入湖，没有急于上线实时入湖，主要基于下面几点考虑： A、基于分区设定，小时入湖可以做到幂等性，批量一次性覆盖写入，方便调试和测试，快速打通上线基于数据湖的日志数仓 针对这些考虑点，结合 Spark batch 入湖积累的经验，我们建设了基于 Flink 的实时入湖链路，如下图所示： 基于 Flink 的分钟级入湖任务，实时消费消息队列 + ETL + 写入数据湖 同时数据湖还提供了异步的优化任务：合并小文件，优化表结构，表级别/列级别的TTL，清理垃圾文件等服务。 接下来我们从入湖，湖上分析和优化服务三个方面介绍我们遇到的问题和改进。 3.1 入湖 优化commit时的内存占用 在介绍流程前，我们先简单介绍下Iceberg文件的组织结构。
湖仓管理：因为数据入湖之后可能会产生一些小文件，我们提供统一后台服务来自动对这些小文件进行合并。 实时计算：提供了DLink SQL作业和任务管理能力，包括任务运维监控功能。 整库入湖：支持整库数据入湖，提升入湖效率。 算子调优：支持Flink算子自动调优、算子拆分、算子并发。 数据连接：支持丰富的connector。 DLink Hive历史数据快速入Iceberg 核心价值：Hive数据可以在不迁移数据文件的情况下，直接构建Iceberg元数据，转换为Iceberg表，并在此基础上做了性能优化，降低了迁移成本。 同时支持整库多张表和部分表，也支持历史数据和增量数据一体化入湖，这个任务建好之后，可以对存量和增量数据一起入湖。 同时也可以对原有业务库，像MySQL、Oracle业务库，没有入湖的话，注册完之后，也可以支持外部数据源和每个湖之间数据的联邦查询。
网易数帆大数据实时计算技术专家、湖仓一体项目负责人马进表示，通过与业务沟通，企业希望整个数据中台层能够用一套规范的流程，实现数据业务的全场景覆盖。 研发团队先用 TPC-C 跑数据库，再跑一个 Flink CDC 任务，然后把数据库实施流式同步到 Arctic 数据湖中，用 Arctic 数据湖构建一个分钟级别数据新鲜度的流式湖仓，在此基础上再跑 CHbenchmark 中的 TPC-H 部分，这样得到流式湖仓的性能数据。 file 有非常多的关联，所以当团队持续写入流式文件时，导致在 Trino 中做 merge-on-read 性能急剧下降，后面 60-90 分钟、90-120 分钟时直接无法测试。 今日好文推荐 操作系统的“冷板凳”要坐多久？
一、什么是数据湖? 数据湖是保存大量原始格式数据的中心位置。与以文件或文件夹形式存储数据的分层数据仓库相比，数据湖采用扁平化架构和对象存储方式来存储数据。 快速无缝地集成各种数据源和格式：任何和所有数据类型都可以收集并无限期地保留在数据湖中，包括批处理和流数据、视频、图像、二进制文件等。由于数据湖为新数据提供了一个着陆区域，它总是最新的。 Flink SQL 入湖示例 DDL + DML 5. CDC 数据入湖链路 如上所示，我们有一个 AutoDTS 平台，负责业务库数据的实时接入。 小文件合并及数据清理 11. 计算引擎 – Flink Flink 是实时平台的核心计算引擎，目前主要支持数据入湖场景，主要有以下几个方面的特点。 数据准实时入湖： Flink 和 Iceberg 在数据入湖方面集成度最高，Flink 社区主动拥抱数据湖技术。
CDC数据入湖方法 基于CDC数据的入湖，这个架构非常简单。 这是阿里云数据库OLAP团队的CDC入湖链路，因为我们我们做Spark的团队，所以我们采用的Spark Streaming链路入湖。 整个入湖链路也分为两个部分：首先有一个全量同步作业，会通过Spark做一次全量数据拉取，这里如果有从库可以直连从库做一次全量同步，避免对主库的影响，然后写到Hudi。 Hudi的定位是一套完整的数据湖平台，最上层面向用户可以写各种各样的SQL，Hudi作为平台提供的各种能力，下面一层是基于SQL以及编程的API，再下一层是Hudi的内核，包括索引、并发控制、表服务，后面社区要构建的基于 最近几天已经发布了0.9.0重要的优化和改进。首先集成了Spark SQL，极大降低了数据分析人员使用Hudi的门槛。
2.1启用近实时数据摄取和分析 T3出行数据湖支持Kafka 消息、Mysql binlog、GIS、业务日志等多种数据源近实时入湖，全公司60%以上的数据已经存入数据湖，并且这个比例还在不断扩大。 3.1数据入湖 我们将Alluxio与计算集群共置部署。 在数据入湖前，将对应的OSS路径挂载至alluxio文件系统中，然后设置Hudi的"--target-base-path"参数 从oss://... 改为 alluxio://... 。 在同步期间，数据跨多个文件系统流动，从生产OSS到线下数据湖集群HDFS，最后同步到机器学习集群的HDFS。 落地到具体场景上，研发工程师将数据入湖时间缩短了1-2倍。数据分析人员使用Presto+Hudi+Alluxio查询湖上数据的速度提高了10倍以上。
腾讯云数据湖计算（DLC）提供了敏捷高效的数据湖分析与计算服务。该服务采用无服务器架构（Serverless）设计，用户无需关注底层架构或维护计算资源，使用标准 SQL 即可完成对象存储服务（COS）及其他云端数据设施的联合分析计算。借助该服务，用户无需进行传统的数据分层建模，大幅缩减了海量数据分析的准备时间，有效提升了企业数据敏捷度。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
网站备案
对象存储
云直播
实时音视频
