祝桥建设网站,潍坊青州网站建设,加盟营销型网站建设,对网站的界面设计分析本文根据作者在2017年ArchSummit的分享记录整理而成。 互联网格局复杂多变#xff0c;大规模的企业合并重组不时发生。原来完全独立甚至相互竞争的两家公司#xff0c;有着独立的技术体系、平台和团队#xff0c;如何整合#xff0c;技术和管理上的难度都很大。2015年10月大规模的企业合并重组不时发生。原来完全独立甚至相互竞争的两家公司有着独立的技术体系、平台和团队如何整合技术和管理上的难度都很大。2015年10月美团与大众点评合并为今天的“美团”成为全球规模最大的生活服务平台。主要分布在北京和上海两地的两支技术团队和两套技术平台为业界提供了一个很好的整合案例。 本文将重点讲述数据平台融合项目的实践思路和经验并深入地讨论Hadoop多机房架构的一种实现方案以及大面积SQL任务重构的一种平滑化方法。最后介绍这种复杂的平台系统如何保证平稳平滑地融合。 两家公司融合之后从业务层面上公司希望能做到“112”所以决定将美团和大众点评两个App的入口同时保留分别做出各自的特色但业务要跨团队划分形成真正的合力。比如丽人、亲子、结婚和休闲娱乐等综合业务以及广告、评价UGC等都集中到上海团队而餐饮、酒店旅游等业务集中到北京团队。为了支撑这种整合后台服务和底层平台也必须相应融合。 点评App和美团App的数据原来会分别打到上海和北京两地的机房业务整合之后数据的生产地和数据分析的使用地可能是不一样的。同时随着公司的融合我们跨团队、跨业务线的分析会越来越多并且还需要一些常态化的集团级报表包括流量的分析表、交易的数据表而这些在原来都是独立的。 举个例子原点评侧的分析师想要分析最近一年访问过美团和大众点评两个App的重合用户数他需要经过这样一系列的过程如下图所示首先他要想办法找到数据这样就需要学习原美团侧数据平台元数据的服务是怎么用的然后在元数据服务上去找到数据才能开始做分析。而做分析其实是一个人工去做SQL分解的过程他需要把原点评侧的去重购买用户数拉下来然后发到原美团侧的数据平台这个环节需要经历一系列的操作包括申请账号、下载数据、上传数据可能还会踩到各种上传数据限制的坑等等。最终如果在这些都走完之后想做一个定期报表那他可能每天都要去人工处理一回。如果他的分析条件变了怎么办可能还要再重新走一遍这个流程。 所以他们特别痛苦最终的结果是分析师说“算了我们不做明细分析了我们做个抽样分析吧”最后他做了一个在Excel里就能做的去重数据量的分析。我们作为平台开发的同学来说看到这个事情是非常羞愧的。那怎么办呢 在经过一些磨合后我们得出一个结论就是必须进行数据口整合。 确立目标 我们定了一个整体的目标希望最终是能做到一个集群、一套数据平台的工具、一套开发规范。但是这个目标有点大怎么把它变的可控起来呢首先至少看来是一个集群也就是说从用户访问的角度上来讲他通过一个Client或一套用户视图就能访问。工具方面至少明确已有的两套哪些是新的员工进来之后还需要学哪些是未来会抛弃掉的。最终让大家认同我们有了一套数据平台规范虽然这套规范短期内还没有办法做到完美。我们做的这些权衡其实是为了从整体上能将问题收敛。 但即使我们把这个目标缩小了想要达到也是很难的。难点在哪呢 难点 架构复杂基础设施限制 如上图所示整个数据平台基本上分为数据接入、数据开发、数据分析、数据输出等等几个阶段。我这里只列了其中涉及到跨机房、跨地域的部分还有很多数据平台产品的融合在这里就不赘述了。在两个公司融合之前原点评侧和美团侧都已经在同地域进行多机房的部署了也都很”默契”地抽象出了离线的机房是相对独立的。在线的业务机房不管是通过消息队列还是原点评自己当时做的Blackhole一个类似DataX的产品都会有一系列数据收集的过程、对应任务的调度系统和对应的开发工具也会有一些不在数据开发体系内的、裸的开源客户端的跳板机。虽然架构大体一致但是融合项目会牵扯整套系统同时我们有物理上的限制就是当时跨机房带宽只有10Gb。 可靠性要求 由于团购网站竞争激烈两家公司对于用数据去优化线上的一些运营策略以控制运营成本以及用数据指导销售团队的管理与支撑等场景都有极强的数据驱动意识管理层对于数据质量的要求是特别高的。我们每天从零点开始进行按天的数据生产工作日9点老板们就坐在一起去开会要看到昨天刚刚发生过什么、昨天的运营数据怎么样、昨天的销售数据怎么样、昨天的流量数据怎么样工作日10点分析师们开始写临时查询写SQL去查数据包括使用Presto、Hive一直到22点同时数据科学家开始去调模型。如果我们集群不能work几千人每天的工作就只能坐在电脑面前看着Excel…… 当时的分析是这样如果考虑回滚的情况下我们运维的时间窗口在平日只有一个小时而且要对全公司所有用数据的同学进行通告这一个小时就是他们下班之后晚上6点至7点的时候开始做一个小时如果一个小时搞不定回滚还有一个小时。周末的话好一点可以做4小时之内然后做全面的通告相当于整个周末大家都没法加班了他们是非常不开心的。 体量 虽然没有到BAT几万台节点的规模但是也不算小了融合时原点评的节点数是500个数据量是11个P原美团的节点数是3000个现在整体已经上6000了。这里有一个比较关键的数据就是每天生成的数据量由于我们的集群上面以数仓的场景为主会有很多重新计算比如说我要看去年每月的去重这些都是经过一些时间变化之后会进行重算的。它对于分析数据的迭代速度要求很高我每天可能都会有新的需求如果原来的数据表里面要加一个字段这个字段是一个新的统计指标这个时候我就要看历史上所有的数据就得把这些数据重新跑一遍。这里的生成数据量其中有50%是对历史的替换50%是今天新增的。这对于后面我们拷数据、挪数据是比较大的挑战。 平台化与复杂度 两家公司其实都已经慢慢变成一个平台也就是说数据平台团队是平台化的没法对数据的结果分析负责数据平台团队其实对外暴露了数据表和计算任务这两种概念。平台化以后这些数据表的owner和这些数据任务的owner都是业务线的同学们我们对他们的掌控力其实是非常差的。 我们想要改一个表的内容、一个数据任务的逻辑都是不被允许的都必须是由业务侧的同学们来做。两侧的平台融合难免存在功能性的差异数据开发平台的日活跃就有100和240如果查询就是每天作分析的日活跃的话原点评和美团加起来有1000多。所以在平台融合过程中能让这么多用户觉得毫无违和感是非常有挑战的。综上我们做了一个项目拆解。 数据互访打通 数据互访打通其实是最早开始的早在公司宣布融合以后我们两侧平台团队坐在一起讨论先做什么当时做了一个投入产出比的权衡首要任务是用相对少的开发先保障两边分析师至少有能在我们平台上进行分析的能力。接着是让用户可以去配置一些定时任务通过配置一些数据拷贝任务把两地数据关联起来。 在这方面我们总共做了三件事。 原始层数据收集 在原美团侧把原点评侧线上业务机房一些DB数据以及Server的log数据同步过来。这个时候流式数据是双跑的已经可以提供两边数据合在一起的分析能力了。 集群数据互拷 集群数据互拷也就是DistCp。这里稍微有一点挑战的是两边的调度系统分别开了接口去做互相回调。如果我们有一份数据我想它ready之后就立即拷到另外一边比如原点评侧有个表我要等它ready了之后拷到原美团侧这个时候我需要在原美团侧这边配一个任务去依赖原点评侧某一个任务的完成就需要做调度系统的打通。本文主要讨论大数据框架的部分所以上面的调度系统还有开发平台的部分都是我们工具链团队去做的就不多说了下文重点描述DistCp。 其实Hadoop原生支持DistCp就是我起一个MapReduce在A集群然后并行地去从B集群拖数据到A集群就这么简单。只要你网络是通的账号能认比如说你在A集群跑的任务账号能被B集群认并且有对应的读权限执行端有计算资源用开源版本的DistCp就可以搞定。 这方面我们做了一些权衡 首先是因为涉及到带宽把控的问题所以同步任务是由平台团队来统一管理业务侧的同学们提需求。 然后我们两侧集群分别建立一个用于同步的账号原则是在读的那一端提交任务。什么叫“读的一端”比如说我想把一个原点评侧的数据同步到原美团侧原美团侧就是要读的那端我在原美团侧起这个任务去读原点评侧的数据然后写到原美团侧。这里的主要考虑是读端更多是需求端所以他要在他的资源池里去跑。另外对集群的影响读小于写我们希望对于被读集群的影响能尽量减少。 当然这都是一些临时的项目投入较小但收益是磨合了两地团队。 Kerberos跨域认证架构 接着介绍一下认证部分是怎么打通的。原美团侧和点评侧恰好都用了Kerberos去做认证服务这个Kerberos在这我不去详细展开只是简单介绍一下。首先是KDC会拥有所有的Client和ServerClient就是HDFS ClientServer就是Name NodeKDC会有Client和Server的密钥然后Client和Server端都会保有自己的密钥这两个甚至都是明文的。所有的密钥都不在传输过程中参与只拿这个密钥来进行加密。基于你能把我用你知道的密钥加密的信息解出来这一假设去做认证。这也是Kerberos架构设计上比较安全的一点。 Kerberos不细讲了下面详细讲一下Kerberos跨域认证架构。 一般公司都不会需要这个只有像我们这种两地原来是两套集群的公司合并了才需要这种东西。我们当时做了一些调研原来的认证过程是Client和KDC去发一个请求拿到对应Server的ticket然后去访问Server就结束了。但是如上图所示在这里它需要走3次原来是请求2次。大前提是两边的Kerberos服务KDC其中的TGS部分下面存储的内容部分分别要有一个配置叫krbtgt它有A realm依赖 B realm这样的一个配置。两边的KDC基于这个配置是要一致的包括其中的密码甚至是包括其中的加密方式。那这个时候我们认为这两个KDC之间实际上是相互信任的。 流程是Client发现要请求的Server是在另外一个域然后需要先去跟Client所属的KDC发请求拿一个跨域的ticket就是上图中1右边那个回来的部分他拿到了这个krbtgt CREALM REALM。然后Client拿着跨域的ticket去请求对应它要访问Service那一个域的KDC再去拿对应那个域的Service的ticket之后再去访问这个Service。这个流程上看文档相对简单实则坑很多下面就讲一下这个。 上图是Kerberos跨域认证的一些要求。 首先第一个比较大的要求就是密钥的编码一致这有一个大坑就是你必须让两个KDC拿到的信息是一样的它们基于这个信息去互信去互相访问。然后krb5.conf里面有一些比较诡异的domain_realm策略这个在你网络环境不一致的时候会有一定的影响包括DNS也会影响这个。在你的网络环境比较不可知的时候你需要做做测试尝试去怎么配然后在Hadoop端有两个配置需要做分别在Server端和Client端配置即可。其中比较恶心的是说在测试的过程当中需要去看Hadoop的详细日志需要开一下它的Debug然后去看一下它真正请求的那个域是什么样的。因为我们翻代码发现Hadoop底层有对logClient去请求realm的隐改就是说我认为我应该是这个realm啊它为什么传出来的是另外一个realm这个是比较坑的一点。 我们做完这个项目之后分析师就可以愉快地配置一些调度任务去同步数据然后在对应的集群上去关联他们的数据进行分析了。做完这个项目之后我们两边的团队也相互磨合相互形成了一定的认可。因为这个小项目涉及到了数据平台的每一个领域包括工具链、实时计算、离线的团队都做了一些磨合。 集群融合 粗看起来打通了数据平台我们的大目标似乎已经完成了一个集群、一套数据平台的工具、一套开发规范。把数据拷过来然后重新改它的任务就可以形成在统一的一套工具和规范里面用一个集群然后慢慢把原来团队维护的服务都下掉就好了。事实上不是这样的这里面有大量的坑。如果接下来我们什么都不做的话会发生什么情况呢 数据RD会需要在迁移的目标平台重建数据比如说我们都定了以后把原美团侧平台砍掉那么好以后都在原点评侧的平台包括平台的上传工具、平台的集群去使用、去开发。这个时候至少原美团侧的同学会说“原点评那边平台的那些概念、流程可能都跟我不一样啊我还需要有学习的时间这都还好”。但他们怎么迁移数据呢只能从源头开始迁移因为对端什么都没有所以要先做数据的拷贝把上游所有的表都拷贝过去。然后一层一层地去改一整套任务都要完全重新构建一遍。 那我们有多少任务呢 我们当时有7000个以上后来超过8000个任务然后我们平均深度有10层。也就是说上游先迁过来然后下游才能迁。整个流程会变成数据表的拷贝然后上线任务进行双跑。因为必须得有数据的校验我才能放心地切过来花的时间大概是拷贝数据1~4天然后改代码加测试再加双跑可能要3~5天。这里我们有一个流水线的问题如上图所示蓝色的部分只有一层依赖的当然我把这个左边的ODS都迁完了之后1层依赖的Task 1、Task 2、Task 3、Task 8中Task 1、2、3就可以迁了但是Task 8 还是不能迁的因为Task 8依赖的Task 7还没过来。我再走一层Task 4的负责人要等上游相关任务都迁完了之后才能干活那整个这个迁移就纯线性化我们大概估了一下并行度不会超过50。如果是两地两份数据这个项目的周期会变成特别长会有长期的两份数据、两份任务。这个时候第一是我们真存的下吗第二是如果我要迁移出来那个方向的业务有需求的变更我怎么改我要两边都再改一遍所以这个是非常不可控的。 那这个时候怎么办 集群融合的问题本质 反思一下这个问题的本质首先我们是不能双跑的因为一旦双跑我们必须有常态化的两份数据然后衍生一系列的校验、存储量、切换策略等问题。所以我们必须得有一套数据一套任务执行机制。后续任务的改变不管是替换工具链上的东西替换计算引擎比如说让两边Hive、Spark和UDF去做一致化的时候其实本质上是说对单个任务的修改对每个任务灰度的修改就好了。 所以我们推断出必须自底向上地去进行融合先合集群然后后续再推动上游平台和引擎的融合。 集群融合的解决思路 整体我们融合的思路是这样的集群融合先行两边的Hadoop的服务架构和代码先进行统一其次拷贝原点评侧集群的Block同步到原美团侧机房的两个副本。这里有一个大的前提第一个是原点评侧的集群节点数相对来讲确实小再一个就是原点评侧的机房确实放不下了它当时只能扩容到10月再往后扩就装不下机器了。 所以我们将原点评侧的集群合并到原美团侧机房然后进行拷贝和切换。我们让整个这个集群变成在原美团侧机房一样的样子然后进行融合。我们会把上面的客户端和元数据统一使得访问任何一个集群的时候都可以用一套客户端来做。一旦我们做到这个样子之后基于统一的数据、集群的元数据和访问入口之后我们上面的工具链就可以慢慢地去做一个一个机制一个一个模块的融合了。 简单总结下来就是四步统一、拷贝、切换、融合下面我们来展开说一下这四步。 统一 第一优先级要解决的是上图中标红的部分两边的Hadoop版本是不一样的我们需要将原上海侧的版本变成我们的2.7.1带着跨机房架构的版本。同时因为我们后面要持续地去折腾Hadoop集群所以必须先把原上海侧的HDFS架构改全改成高可用的。 这里有一个小经验就是我们自研的patch对改的bug或者是加的feature一定要有一个机制能够管理起来我们内部是用Git去管理的然后我们自研的部分会有特殊的标签能一下拉出来。我们当时其实互相review了上百个patch因为当时两个团队都有对集群包括Hive等等这些开源软件的修改。这是统一的阶段相对容易就是一个梳理和上线的过程。接下来是拷贝的阶段。 拷贝 上图是最终的效果图同步在运行的打通任务还是用DistCp然后先把原点评侧的HDFS跨机房部署。但是这个时候原点评侧的YARN还是在上海机房。在这个过程当中因为HDFS跨机房部署了所以原新上线的DataNode可以承载更多在原点评侧集群的冷数据。这个过程是慢慢进行拷贝的大概持续了4个月中间长期都是10Gbps的小管子。 切换 这个相当于把原点评侧的NameNode这个时候还没有彻底下线切换到原美团侧机房然后把对应的YARN重新启动起来。这里有一个小trick就是原美团侧机房的承载能力大概是1000多台节点是原点评侧的两倍所以我们才能做这个事最近我们刚刚把上海机房的节点迁完。 那整个集群的拷贝和切换是怎么做的呢其实就是用我们自研的一套Hadoop多机房架构。可能做Hadoop集群维护管理的同学们对这个有深刻的体会就是不时地就要从一个机房搬到另一个机房。设计目标是说我们一个Hadoop集群可以跨机房去部署然后在块的力度上能控制数据副本的放置策略甚至是进行主动迁移。 设计是怎么做的呢整个Hadoop原生的架构其实没有机房这个概念只支持Rack也就是机架所有服务器都被认为是在同一个机房的。这个时候不可避免地就会有很多跨机房的流量就如果你真的什么都不干就把Hadoop跨机房去部署的话那么不好意思你中间有好多的调用和带宽都会往这儿走最大的瓶颈是中间机房网络带宽的资源受限。 我们梳理了一下跨机房部署的时候大概都有哪些场景会真正引发跨机房流量基本上就这3~4个。首先是写数据的时候大家知道会3副本3个DataNode去建pipeline这个时候由于是机器和机器之间建连接然后发数据的如果我要分机房部署的话肯定会跨机房。那我要怎么应对呢我们在NameNode专门增加zone的概念相当于在Rack上面又加了一层概念简单改了一些代码。然后修改了一下NameNode逻辑。当它去建立pipeline的时候在那个调用里面hack了一下。建pipeline的时候我只允许你选当前这个Client所属的zone这样写数据时就不会跨机房了。 这些Application在调度的时候有可能会在两个机房上比如说mapper在A机房reducer在B机房那么中间的带宽会非常大。我们怎么做的呢在YARN的队列里面也增加zone的概念我们用的是Fair Scheduler。在队列配置里面对于每一个叶子队列都增加了一个zone的概念。一个叶子队列其实就是对应了这个叶子队列下面的所有任务它在分配资源的时候就只能拿到这个zone的节点。读取数据的时候有可能是跨机房的那这个时候没有办法我们只有在读取块选择的时候本地优先。我们有一些跨机房提交job的情况提交job的时候会把一些job里面的数据进行上传这个时候加了一些任务的临时文件上传的是任务所在的目标机房。这里做一些简单的改动最重要的是提供了一个功能就是我们在拷贝数据的时候其实用balancer所用的那一套接口我们在此基础之上做了一层Hack一层封装。形成了一个工具我们叫ZoneTransfer又由它来按照我们一系列的策略配置去驱动DataNode之间的跨机房的block粒度的拷贝。 上图是我们跨机房架构的架构图下面的Slave里面有DN(DataNode)和NM(NodeManager)上面跑的同颜色的是一个App。我们在RM(ResourceManager)里面的叶子队列里配置了zone的概念然后在调度的时候如大家所见一个App只会在一个机房。然后下面黑色的线条都是写数据流程DN之间建立的pipeline也会在一个机房只有通过root去做的DN之间做数据transfer的时候才会跨机房进行这里我们基本上都卡住了这个跨机房的带宽它会使用多少都是在我们掌控之内的。 在上线和应用这个多机房架构的时候我们有一些应用经验。 首先在迁移的过程当中我们需要评估一点就是带宽到底用多少或者说到底多长时间之内能完成这个整体数据的拷贝。这里需要面对的一个现实就是我们有很多数据是会被持续更新的。比如我昨天看到这个块还在呢今天可能由于更新被删那昨天已经同步过来的数据就白费了。那我昨天已经同步过来的数据就白费了。所以我们定义了一个概念叫拷贝留存率。经过4个月的整体拷贝拷贝留存率大概是70%多也就是说我们只有70%的带宽是有效的剩下的30%拷过去的数据后面都被删了。 第二个是我们必须得有元数据的分析能力比如说有一个方法能抓到每一个块我要拷的块当前分布是什么样子。我们最开始是用RPC直接裸抓Active NameNode其实对线上的影响还是蛮大的。后面变成了我们通过FsImage去拉文件的列表形成文件和块的列表然后再到把请求发到standby那边开了一个小口子允许它去读。因为FsImage里面是没有block在哪一个DataNode的元信息的。 这里需要注意的一点就是我们每天都会有一个按天的数据生产为了保证它的一致性必须在当天完成。在切换之前让被切换集群的NNNameNode进入SafeMode的状态然后就不允许写了所有的写请求停止所有的任务停止。我们当时上线大概花了5~6个小时吧先停然后再去拷贝数据把当天的所有新生产的数据都拷过来然后再去做操作。这里最基本的要做到一点就是我们离线的大数据带宽不能跟线上的服务的带宽抢资源所以一定要跟基础设施团队去商量让他们做一些基于打标签的带宽隔离策略。 融合 当我们把集群搬到了原美团侧的机房之后又做了一层融合。想让它看起来像一个集群的样子基本上只需要3步。首先是“把冰箱门打开”把原点评侧集群的那个NN作为一个federation合到原美团侧的集群只需要改cluster ID去客户端改mount table配置cluster ID是在元数据里面。第二个是对Hive进行元数据的融合。我们恰好两侧元数据存储都是用MySQL的把对应的表导出来灌到这边然后持续建一个同步的pipeline。它是长期活动的到时候把上传的服务一切就可以。 前面说的那个做了跨域认证的配置我们还是要拆掉的必须进行服务认证的统一不然的话以后没法看起来像一个集群这个时候把原来的KDC里面的账号进行导出之后逐步地去切换每一个配置让它慢慢切到新的KDC。切的过程当中我们各种请求还是有跨域情况的我们认为两个域是一体的是一样的。等切干净之后也就是原来的KDC没有请求了之后我们再把它干掉。 开发工具融合 集群融合结束后我们就做了开发工具的融合。由于这个跟大数据基础架构这个主题关系不是特别大开发工具都是我们内部自研的涉及的程序也很复杂是一个特别大的项目涉及一系列复杂的工具每个模块的融合、打通。所以这个暂时不讲了。另外我觉得比较有意思的是下面这一点就是原点评侧的一个拆库这个在很多公司的数据平台慢慢扩大的过程当中可能会用到。 原点评侧拆库 难点 先说一下背景由于原点评和原美团整体历史上发展经验、周期和阶段不同如上图所示原点评侧的数据仓库是先有的Hadoop集群后有的数据仓库平台因此有很多平台完全没法掌控的私有库但是他们对于数仓所在库的掌控是非常强的所有的任务都在这一个大的Hive库里面里面有七八千张表。而原美团侧是先有的数据平台后来因为数据平台整个体量撑不住了底层改成了Hadoop。同时在平台化的演进过程中已经慢慢把各个业务进行独立拆分了每个业务都有一个独立的私有库简单来说就是库名和库名的规范不一样。我们希望能让这两套规范进行统一。 我们如何去做呢 原来任务的内容大概是insert into一个BI库里面的一张表接着select from BI库里面的某两张表然后where group by。像这样的任务我们有七八千个它们在我们平台上配置着每天的依赖调度。我们希望把它都改成下图中的样子。所有涉及到的这些表都需要改名字说白了就是一个批量改名字的事儿。 改名字听起来很简单实际上并不是我们有近8000个这样的任务需要改同时这些任务相互之间都有非常复杂的依赖。下图是我随便找的一个原美团侧某一个任务所有上游和下游的依赖关系图如此复杂任务的平均深度大概有10层这还是平均数最严重的可能要有大几十层。如果我们改这里面的任务表达就只能分层推动。但是当我们每改其中一个的时候可能上下游都得跟着改具体是什么样子的呢 下图是我们的原始结构首先这里有一个大前提是每一个任务只对一个结果表。原始的结构中a表只依赖o1表b表依赖o1、o2然后c表只依赖o2它们之间相互关联。这时候我希望可以对库名和表名进行一次性的修改。那如果我们逐层地去改写怎么办呢首先要先把最上层的mart表改了而我一旦改上游的某一个表所有跟对它有依赖的表都必须改任务内容。每推动一层改动下面一层都要变动多次这样一来我们这个流程就非常受限。 刚刚那个情况基本上是类似的就是说我们对它们的改动没法批量化、信息化、流水线化所有的用户和数据开发们需要跟我们去聊最近改了多少然后谁谁谁没改完谁谁谁又说要依赖他整个依赖图是非常大的我们整个项目又不可控了。那怎么办呢 解决方案 很简单我们只干了一件事情就是在Hive层面上进行了一波Hack。比如说我要让原来叫bi.o2的表未来会变成mart_b.o2我就同时允许你以mart_b.o2和bi.o2这两种方式去访问bi.o2这张表就好了。不管是写入还是读取我们只需要在Hive的元数据层面去做一层Hack然后做一个对应表这个对应表我们是有规范的、能梳理出来的。在这之后任何一个人都可以把他的任务改写成他希望的样子而不受任何影响他写的那些表还是原来的那些表真正在物理上的存在还是bi.什么什么这样的表我们整个项目就run起来了。 具体的实施流程是这样首先先梳理业务确定整体的映射关系。然后Hive元数据入口上去做别名能力我们是在Hive metaserver里面去改的大部分请求都在这里面包括Spark的、Presto的、Hive的等都能兼容掉推动分批次改写单任务内以及任务链条内完全不需要做依赖关系的约束最终真正实现的是自动化地把SQL文本替换掉了。业务的同学们只需要批量看一个检测报告比如说数据对应上有没有什么问题然后一键就切了。 我们用了一个季度业务侧来磨合、尝试练习和熟练同时做工具的开发。然后第二个季度结束后我们就完成了7000多个任务中90%SQL任务批量的改写。当任务都切完了之后我们还有手段因为所有的请求都是从Hive的metaserver去访问的当你还有原有的访问模式的时候我就可以找到你你是哪一个任务来的然后你什么东西改没改改完了之后我们可以去进行物理上的真正切分干掉这种元数据对应关系。 物理上的真正切分其实就是把原来都统一的库按照配置去散到真实的物理上对应的库上本质还是改NN一个事情。 未来——常态化多机房方案 我们目前正在做的一个项目就是常态化地把集群跨机房去跑其中最核心的就是我们需要对跨机房的数据进行非常强的管理能力本质上是一个Block粒度Cache的事情比如说Cache的击穿、Cache的预热或者Cache的等待等等都是一个Cache管理的事情。我们会引入一个新的server叫zone Server所有的Client请求NameNode进行块分布的时候调整和修改。之后大家会在美团技术博客上看到我们的方案。 反思——技术换运营 数据平台做起来是很痛苦的痛苦在哪儿呢第一数据平台对上层提供的不只是RPC接口它要管的是数据表和计算任务。所以我们做SLA很难但是我们还在努力去做。第二就是最开始的时候一定是基于开源系统拼接出来的然后再到平台化这一定是一个规范的收敛也是限制增多的过程。在这个过程中我们必须去推动上面应用的、不符合规范的部分推动他们去符合新的规范。平台的变更即使做到兼容我们的整体收尾还是要尽快扫清的不然整个平台就会出现同时进行大量灰度、每一个模块当前都有多种状态的情况这是不可维护的。 综上我们定义了一个概念叫“可运营性”推动用户去做迁移、做改动是一个”运营的事情”。可运营性基本上的要求如下。 可灰度。任务的改动是可灰度的。可关门。当某一刻我不允许你再新增不符合新规范的任务、表或者配置我们内部叫“关门打狗”就是说先把新增的部分限制住然后再去慢慢清理老的。进度可知。清理老的我们需要有一个进度可知需要有手段去抓到还有哪些任务不符合我们新的规范。分工可知。抓到任务的分工是谁推动相关团队去改动。变更兼容/替代方案。我们肯定过程中会遇到一些人说不行我改不动了你deadline太早了我搞不定。这时候得有一些降级或者兼容变更的一些方案。那我们什么时候去使用技术降低运营成本呢前面已经有两个例子就集群的迁移和融合还有Hive表别名去帮助他们改任务名这都是用技术手段去降低运营成本的。 怎么做到呢 第一是找核心问题我们能否彻底规避运营、能不能自动化在集群融合的过程当中其实已经彻底避免了运营的问题用户根本都不需要感知相当于在这一层面都抽象掉了。第二是即使我没法规避那我能不能让运营变得批量化、并行化、流水线化、自动化然后当你抓核心问题有了一个方案之后就小范围去迭代、去测试。最后还有一点引入架构变更的复杂度最终要能清理掉新增的临时功能最后是可被下线的。 体会——复杂系统重构与融合 最后稍微聊一下复杂系统的重构与融合。从项目管理的角度上来讲怎么去管控复杂系统的重构还有融合本质上最大的挑战其实是一个复杂度管理的事情我们不可能不出问题关键是出问题后对影响的范围可控。 从两个层面去拆分第一个层面是先明确定义目标这个目标是能拆到一个独立团队里去做的比如说我们最开始那四个大的目标这样保证团队间能并行地进行推动其实是一点流水线的思路。第二我们在团队内进行目标的拆分拆分就相对清晰了先确定我要变更什么然后内部brainstorming翻代码去查找、测试、分析到底会对什么东西产生影响然后去改动、测试、制定上线计划。 内部要制定明确的上线流程我记得当时在做的时候从11月到12月我们拆分了应该是有11次上线基本上每次大的上线都是在周末做的10、11、12月总共有12个周末一共上线11次大的上线应该是占了7到8个周末吧。要提前准备好如何管理依赖如何串行化然后准备上线上线完怎么管理这些都是在整个项目管理过程当中需要考虑的。 其中两个可能大家都持续提的东西第一个是监控要知道改完了之后发生了什么在改的时候就像加测试用例一样把改动部分的监控加好。第二要有抓手如果我线上垮了这个时候重复恢复的成本太高也就是完全重启、完全回滚的成本太高我能不能线上进行一些改动 最后这张图献给大家希望大家在对自己系统改动的时候都能像这哥们一样从容。
