化整为零:湖仓数据平台一站式迁移

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 本文介绍了湖仓平台迁移的概况、痛点及解决方案。首先概述了数据湖和数据仓库迁移的现状与背景,强调其重要性及挑战。接着分析了迁移过程中的主要痛点,如数据量大、业务变更频繁等。最后提出了一种化整为零的新范式,通过精细化设计和自动化工具提升迁移效率,并展示了一站式湖仓迁移中心的关键阶段和产品大图,旨在加速迁移过程并减少人工成本。

一、湖仓平台迁移概况

这个话题相对小众,大家可能觉得数据湖和湖仓以建设为主,为何要做迁移以及迁移过程涉及哪些技术,此处不讲解技术细节,主要阐述做此类小众场景时思路的变化,希望给大家一些启示,今天的分享三部分。第一是做lakehouse数据湖或数据仓库迁移的现状,第二如何通过新设计实现湖仓迁移效率最大化,第三展示新设计及落地时可供参考的部分。


1.数据湖仓迁移的背景与现状

数据技术很重要,研究大模型的人很多,但做好大模型也离不开数据。做各种AI智能化之前,要把数据汇总到数据湖做分析。数据是生产力,应用更先进的生产力完成数据的分析和查询也很重要。有时可能面临传统技术栈,有holo,data本地的数据存储,看到新的先进技术,如singoks,kos,资源占比低或查询效率高,想尝试时会面临重点问题,即如何把现有数据调度和作业迁移到目标基础站,迁移可能有额外成本,因成本可能放弃。所以对现代技术栈来说,做数据迁移是为提高数据生产力。不管架构成本降低、技术栈升级还是跨云数据管控,都需把数据从一个平台迁移到另一个平台。技术栈迁移并非低频操作,未来可能高频,一两年可能就需改变技术栈。直观做数据迁移,首先可能关注数据湖或数据仓库的组件、底层元数据、数据存储和物理I/O,以及上层的SQL作业和数据服务,还有数据开发的IDE工作层和权限管控。原始出发点是做平台从A到B的迁移,要知道哪些地方可被自动化工具覆盖。过去几年迁移更多使用点状能力覆盖组件迁移过程,出发点是有多种数据分层、数据引擎、相关权限和workflow调动组件,需找到点对点的迁移工具,看其是否能满足,若遇到问题如何解决。在点状覆盖过程中,这是后面设计要解决的问题。


2.迁移过程的痛点分析

现状是做了一些相关覆盖,空间层面技术栈迁移已较成熟,但作为复杂工程,整个流程并非有工具就能解决。因为数据量很大,从一个上百TB的数据湖迁移可能需几个月时间,在此过程中业务不稳定,可能发生变更,包括原数据变更、WORKflow变更和新应用上线。所以通常会形成一套方案,即标准流程,包括盘点、环境准备、存量同步、增量同步和最后的验证和割接。流程结合了点状工具和标准化流程,但做此事过程中还会遇到大量困难。比如业务运行一段时间后数据发生变更或新业务上线,最终平台和原端有很大差异,存量数据完成后,如何快速定位目标平台和原平台的差异,降低它们的一致性。在此过程中,效率、成败和人工成本是痛点。过往产品分析也遇到问题,资源成本和人工成本消耗较大,主要体现在从最初的数据调度和存量数据迁移到最后的跑通过程中,人工成本体现明显。比如使用很多工具,在每个流程中调用,每个调用环节都需重新整理输入、输出,很多时候需对上一个节点生产的东西进一步加工才能交给下一个工具转换或同步,以保证目标平台运作正确。工具在数据传输和调用过程中对资源消耗大,做复杂平台迁移可能用到五到十种工具,这些工具对资源的利用差异明显,有些是I/O密集型,有些是计算密集型,所以工具对资源的利用率很低,导致传统面向过程的操作产生成本浪费。

 

二、化整为零湖仓迁移设计

1.湖仓迁移新范式

做复杂系统工程时,如何解决多元素长周期的工程化实践,所谓化整为零,即解决经济化提升工程化生产能力。整个数据仓库迁移过程中,数据量上百TB或上万作业实例迁移,以往点状覆盖是基于对业务和工程化的理解形成整套流程,现在从另一个思路看问题。若要做从A一个复杂系统搬迁到云上或云下,换一个技术栈,首先要定义问题,而非去做,这是思路上的大差异,如何更好地定义迁移过程涉及的元素操作,才能在无穷大空间找到收敛方式解决问题。新的思路是定义一套语言描述迁移过程涉及的东西,包括事件元素和数据量配置等相关信息,通过统一的数据语言为优化治理和重新解决问题提供基础。第二是结合现有工具,把点状能力通过运行时(如java里的GC或高级语言里的调度工具通过智能化或规则化的东西自动化,把点状能力变成线状或自动化流程。最后把逻辑上的表达和物理上的表达分层,使最终设计适配不同更新的技术解决复杂系统迁移的点状问题。要解决的问题包括工具调用、人工成分和粗力度阶段化的资源浪费。


以一个场景描述数据仓库或带数据湖性的多组件数据迁移,左边是从hive基于docing schadue以及基于底层数据湖和原数据迁移到阿里云产品上的映射关系,如datecompute,date+f。改变以往思路,看到hive不应只想到如何把数据迁移到maxcompute,还应考虑SQL和底层数据的转换,以及复杂系统中原数据涉及的元素。定义迁移过程中有存量数据的迁移、增量数据的迁移及对应的调度迁移,通过一种语言把形式化进化结构化,直观看到整个迁移过程不只是底层的数据sme到sos如何迁移、SQL如何转换,还能看到不同节点之间的关联,不同节点可精细化呈现转换过程,转换过程之间的依赖也可充分表达,最后把整个过程形成让事件和数据能在其中流转的体系,不再关注某一阶段该做什么,而是首先关注问题以及它们持续收敛需要规划的蓝图,即领域关站语言。


2.湖仓迁移管控精细化演进

具体来说,精细化体现在三个地方。把阶段化的一批一批作业转换变成自动化生产线,有三点精细化。第一点是操作精细化,不再只说做数据迁移,明确是存量数据的迁移还是数仓的迁移,ODS,DWD等不同层面的迁移在不同阶段和定义中占比位置和前后关系不同,这样能在不同阶段给利用不同资源,同时在数据迁移过程中从对业务的认知上体现拆解出来的内容。在整个上层TOP中,蓝图不会改变,但在不同阶段,比如这次把170TB的数据全部迁移,可根据业务变化让精细化管控提供帮助,比如ods前者是哪些表的数据同步,这些数据能直接驱动下游作业,有重要业务可先迁移,而不是等所有数据库完成后再迁移,在此过程中内部数据的流转也实现了精确化,从节点的精细化、数据流转的精细化做了整体升级,在不同阶段能快速看到业务收敛效果,而不是等待其他无关的数据同步完成后再做数据和服务。


在做整体升级过程中,在两个象限做了较大调整。左下角是传统做数据仓库或数据湖常用的阶段和步骤,比如做同样的数据同步和增长速度,每个框框可能代表每个SOP环节中间经过的工具调用,但现在考虑节约和成本,做了两个较大调整。第一是从横轴上做操作精细化,把所有节点里的能力拆解出来,变成从湖、SQL文件分、甚至是workflow不同工具之间的转换形式,从节点到整个全局拆解成大概50多个定义。第二是从管控上做动态化调整和体现,主要体现在节点线的组织和数据之间的流转。新的设计理念是事件驱动,一个多方面的技术群体,通过探查制定接下来的全局化流转过程,最终应是右上角象限里的情况,即基于统一的状态驱动A到B技术栈的调整。


数据仓库本身有工程化技术,迁移的工具化生产结合新的精细化设计,提升了数据迁移的生产力,数据迁移更多是用新的数据机制解决问题。除视角持续精细化外,最终希望从业务视角体现整个品牌是否趋近于收敛,化整为零后最终希望以化零再为整的视角看到变化,通过定义问题抽象解决问题后,希望给平台运维同学或管理层提供一个整体视图,看到做数据基础上的迁移时A和B之间的差异,以及在迁移过程中原则是否发生很多变化,这些变化在一致性持续收敛过程中是否有完整认识,还需要多长时间才能进行整个平台的计划划分。最终虽底层做了大量精细化,但在最上面也希望提供一个从数据湖仓库角度的所有全颜色、双端、持续的监测以及差异性等的完整展示,展示基于今天展示的数据实行的作用、所有状态,最终汇总出来是一个百分比数字,一个北极星的指标,比如平台数量达到90%或100%,可快速告诉相关人员业务可割接,不需要将整块数仓的数据全部迁移,这是过往一些大项目的痛点,最后的割接迁移过程可能持续一周或两周,希望对业务变更影响最少,能快速切到一个新的平台上,或按照业务通过实时的双端建设完成整体迁移。


最后展望一下,大家可能关心大模型,把工程变成精细化是对工程化的分级自动化设定。从最早期员工做方案做设计,调用简单工具或人工作迁移,到过去几年的工具箱方式(L2),以人为本,知道何时用工具完成迁移,现在把经验规则精细化、动态化形成生产线,精细化是为最后的智能化阶段做准备。目前尝试把option作为精细化的节点,变成可执行非常精细化的输入输出,把输入结构化的信息给到现在的一个模型,以agent方式搭模型,只要知道目标,就能知道如何收敛,该调用的东西,通过模型通过AI自动运行相关的同步转换能力,最终实现双端上的持续收敛,即智能迁移,思路可匹配各种场景的迁移,结合大环境和精细化设计的场景。

 

三、一站式湖仓迁移中心

1.基于精细化的产品大图

我们希望把迁移过程中的所有事件元素在一个平台中体现,而不是人肉在各个阶段调用不同的工具。其底层是工具箱里的一些原始能力,这些原始能力可插拔、可替换,更多关注第二产品的逻辑表达、中间生产线之间的流转,具体事件驱动调用哪些引擎、哪个工具由生产线以及未来结合大数据的能力做一个自动化标准,随着新生产力的体现,不同节点可能有新的数据处理能力,或snatshop,innerge探查进行快速替换,而不影响整个表达以及最终的实践过程。


2.迁移过程中的关键阶段

以两个节点进行同样数据作业的同步迁移的paiplan。从产品视角看,最痛的两个阶段是大批量的数据和数据迁移以及双跑阶段如何把动态的端的变化导到目标端。第一个阶段是把同样的所有的数据和作业,未来数据包括甚至一些条件体系的数据全部迁移过去,以前在产品上是一个节点,进入到数据迁移页面点数据迁移做完后,再去作业的转换完成转换,跑到另一个地方进行平台启动,得到最终结果,现在基于上述设计,在平台上直观形成完整的生产线,其节点和作业驱动可以在系统中自动化,需要在元数据启动以后进行数据的转换,SQL的转换,workflow的提交,它会自动将上游的数据节点和下游需要的节点提前准备好,下游就可以根据现在的物理资源进行调用,直观展示不再是点状的能力,而是串形整体的大图,关注其作业流转是否正常,关注终端检测后的差异性是否满足我们割接需求。


第二个痛点是关于如何结合血缘形成双跑阶段语言,它跟存量的迁移有很大的区别,通常情况下,数据和作业在目标平台已经完备,但达不到一致,一直有新的变更,表多了一列,或者上新了业务,都会导致很大的差异,但是血缘并不完整,可能在A平台存在一个引擎和数据数据湖的flink引擎之间的血缘是分散的,而在整体迁移平台,我们有完整的数据,可以基于整个画像和血缘在生产线里精细管控时告诉客户某个数据已经发生变更,需要做新一轮的转换,这是精细化在产品上的体现,形成的一站式迁移平台在我们双跑阶段,可以动态地检测到跨引擎血缘变化以及结合我们的生产线的精细化的能力,不再是批量的1次而是重复覆盖和提交workflow,可以精确知道某一表和节点nod里面对应的skipt需要提交和转换,最大化利用转换资源,集群资源以及减少人工去发现问题去提交任务的成本,所以最终通过这个完整的生产线和这个精细化的一个设计体现的是从存量迁移到最终双端监测持续的收敛的一个过程的加速做为湖仓迁移技术站的转换。

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
打赏
0
6
6
0
263
分享
相关文章
数据无界、湖仓无界,Apache Doris 湖仓一体典型场景实战指南(下篇)
Apache Doris 提出“数据无界”和“湖仓无界”理念,提供高效的数据管理方案。本文聚焦三个典型应用场景:湖仓分析加速、多源联邦分析、湖仓数据处理,深入介绍 Apache Doris 的最佳实践,帮助企业快速响应业务需求,提升数据处理和分析效率
数据无界、湖仓无界,Apache Doris 湖仓一体典型场景实战指南(下篇)
数据无界、湖仓无界, Apache Doris 湖仓一体解决方案全面解读(上篇)
湖仓一体架构融合了数据湖的低成本、高扩展性,以及数据仓库的高性能、强数据治理能力,高效应对大数据时代的挑战。为助力企业实现湖仓一体的建设,Apache Doris 提出了数据无界和湖仓无界核心理念,并结合自身特性,助力企业加速从 0 到 1 构建湖仓体系,降低转型过程中的风险和成本。本文将对湖仓一体演进及 Apache Doris 湖仓一体方案进行介绍。
数据无界、湖仓无界, Apache Doris 湖仓一体解决方案全面解读(上篇)
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
快手 OLAP 系统为内外多个场景提供数据服务,每天承载近 10 亿的查询请求。原有湖仓分离架构,由离线数据湖和实时数仓组成,面临存储冗余、资源抢占、治理复杂、查询调优难等问题。通过引入 Apache Doris 湖仓一体能力,替换了 Clickhouse ,升级为湖仓一体架构,并结合 Doris 的物化视图改写能力和自动物化服务,实现高性能的数据查询以及灵活的数据治理。
快手:从 Clickhouse 到 Apache Doris,实现湖仓分离向湖仓一体架构升级
美的楼宇科技基于阿里云 EMR Serverless Spark 构建 LakeHouse 湖仓数据平台
美的楼宇科技基于阿里云 EMR Serverless Spark 建设 IoT 数据平台,实现了数据与 AI 技术的有效融合,解决了美的楼宇科技设备数据量庞大且持续增长、数据半结构化、数据价值缺乏深度挖掘的痛点问题。并结合 EMR Serverless StarRocks 搭建了 Lakehouse 平台,最终实现不同场景下整体性能提升50%以上,同时综合成本下降30%。
云栖实录 | 开源大数据全面升级:Native 核心引擎、Serverless 化、湖仓架构引领云上大数据发展
在2024云栖大会开源大数据专场上,阿里云宣布推出实时计算Flink产品的新一代向量化流计算引擎Flash,该引擎100%兼容Apache Flink标准,性能提升5-10倍,助力企业降本增效。此外,EMR Serverless Spark产品启动商业化,提供全托管Serverless服务,性能提升300%,并支持弹性伸缩与按量付费。七猫免费小说也分享了其在云上数据仓库治理的成功实践。其次 Flink Forward Asia 2024 将于11月在上海举行,欢迎报名参加。
324 6
云栖实录 | 开源大数据全面升级:Native 核心引擎、Serverless 化、湖仓架构引领云上大数据发展
云计算与大数据平台的数据库迁移与同步
本文详细介绍了云计算与大数据平台的数据库迁移与同步的核心概念、算法原理、具体操作步骤、数学模型公式、代码实例及未来发展趋势与挑战。涵盖全量与增量迁移、一致性与异步复制等内容,旨在帮助读者全面了解并应对相关技术挑战。
84 3
DataWorks产品使用合集之需要将mysql 表(有longtext类型字段) 迁移到odps,但odps好像没有对应的类型支持,该怎么办
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
实时数仓 Hologres产品使用合集之湖仓加速版查询maxcompute外部表,有什么优化途径吗
实时数仓Hologres的基本概念和特点:1.一站式实时数仓引擎:Hologres集成了数据仓库、在线分析处理(OLAP)和在线服务(Serving)能力于一体,适合实时数据分析和决策支持场景。2.兼容PostgreSQL协议:Hologres支持标准SQL(兼容PostgreSQL协议和语法),使得迁移和集成变得简单。3.海量数据处理能力:能够处理PB级数据的多维分析和即席查询,支持高并发低延迟查询。4.实时性:支持数据的实时写入、实时更新和实时分析,满足对数据新鲜度要求高的业务场景。5.与大数据生态集成:与MaxCompute、Flink、DataWorks等阿里云产品深度融合,提供离在线
参与开源大数据Workshop·杭州站,共探企业湖仓演进实践
Apache Flink 诚邀您参加 7 月 27 日在杭州举办的阿里云开源大数据 Workshop,了解流式湖仓、湖仓一体架构的最近演进方向,共探企业云上湖仓实践案例。
199 12
参与开源大数据Workshop·杭州站,共探企业湖仓演进实践

相关产品

  • 云原生大数据计算服务 MaxCompute
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等