一、湖仓平台迁移概况
这个话题相对小众,大家可能觉得数据湖和湖仓以建设为主,为何要做迁移以及迁移过程涉及哪些技术,此处不讲解技术细节,主要阐述做此类小众场景时思路的变化,希望给大家一些启示,今天的分享有三部分。第一是做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需要提交和转换,最大化利用转换资源,集群资源以及减少人工去发现问题去提交任务的成本,所以最终通过这个完整的生产线和这个精细化的一个设计体现的是从存量迁移到最终双端监测持续的收敛的一个过程的加速做为湖仓迁移技术站的转换。