精华内容
下载资源
问答
  • > 随着互联网业务发展和对容灾的需求,以及对访问加速、多供应商成本控制等要求,互联网公司通过跨云部署和迁移来更好的控制成本逐渐成为刚需,跨云部署和迁移也就成为运维...**首先是数据完整和一致挑战。**
    随着互联网业务发展和对容灾的需求,以及对访问加速、多供应商成本控制等要求,互联网公司通过跨云部署和迁移来更好的控制成本逐渐成为刚需,跨云部署和迁移也就成为运维圈子里的一个热门话题,而在此过程中,对运维和研发最头痛就是数据的迁移和分布。

    粤语中有一句谚语“上屋搬下屋,搬洒一箩谷”,意思是在各种各样的搬动过程中,或多或少都会伴随一些资产的流失,这对于互联网业务来说是难以接受的。

    通过对最近几次客户的多云部署进行总结,过程中存在的挑战有三点:

    首先是数据完整性和一致性挑战。

    其次是时效性,迁移窗口期相对有限。

    再者是依赖性和各种访问关系。

    在大多数实际环境中都存在着应用依赖性,如何万千关系中理顺每条访问关系也是让人望而却步的事情。

    跨云迁移涉及到的资源一般可以分成三大类:

    第一类是EIP、VPC、负载均衡和NAT网关这类网络服务,在跨云迁移的过程中这些都会发生变化,而且是无状态服务,配置并不复杂,对于这部分资源可以通过人工的方法对齐配置。

    接下来是最为常见的云主机资源,这部分我们可以通过USMC服务器迁移工具来进行迁移,对于一些例如zookeeper的服务,也可以通过人手同步配置的方式来迁移。

    而第三类就是包括数据库、文件存储和对象存储在内的一些存储服务,我们可以通过UDTS等工具进行迁移,而这正是本文所重点讨论的实践内容。

     

    跨云迁移

    在这些客户的多云部署和迁移过程中,如何在有限的业务暂停时间里,将大量数据进行迁移,并且保证数据一致,有了较多实践和沉淀。为给大家提供有效的借鉴意义,花了一些时间从实践总结了共性,将跨云迁移划分为三个阶段:数据同步阶段、数据规整阶段(清理测试产生脏数据)和数据割接阶段进行阐述。

    1. 数据同步阶段

    数据同步阶段主要是需要解决两个问题,其中最主要的还是跨云迁移的核心,即将数据复制到新平台,并且让应用程序在新平台运行,其次就是利用真实数据对应用程序进行测试,确认应用程序在目标平台可以符合预期地运行。我们都知道数据可以分为结构化数据和非结构化数据,用来存储数据的方法众多,无法逐个深入分析,所以笔者在这里只提供一些最常见的存储组件的迁移实践,其它不同的存储组件各有不同,但也是可以参考这几个组件的迁移逻辑来处理的。

    下面将分别讨论MySQL、文件存储和对象存储的数据同步方式。

    1.1 MySQL同步

    一般来说,我们认为对于MySQL的同步,只要存量数据和增量数据都能做到一致,那么整个数据库的同步就是一致的。

    而常见的MySQL数据迁移方式有两种:一种是基于MySQL主从的方式,通过mysqldump记录下binlog位置,然后把这个binlog位置前的数据完整导出,恢复出一个备库,然后再从记录的binlog位置开始向主库追平增量数据。另一种就是UDTS工具,但总体上也是分为存量阶段和增量阶段,增量阶段的追及是将从存量同步发起的一瞬间开始往后的数据变化通过binlog的形式同步到目标库。

    增量同步依靠binlog完成,这是MySQL主从同步的基础,是我们需要默认信任的数据一致性机制,所以反过来说,如果我们不信任MySQL的binlog机制,那么其它MySQL的数据一致性机制也是需要怀疑的,包括数据落地的fsycn()调用是否真正的把数据写入到磁盘和事务等等,这样就陷入了怀疑论了。当然我们最终需要以数据校验结果来确认数据是否一致。

    简而言之,跨云迁移过程中MySQL的数据一致性主要就集中在存量数据的迁移如何保证一致。

    【案例】

    以近期的xx公司迁移到UCloud为例,其涉及数据库实例有数十个,并且由于应用依赖的原因需要进行整体迁移。在这案例中,如果采用mysqldump的方法,那么这数十个数据库都需要经过导出、传输、导入和配置主从这样的操作,给整个迁移任务增加了不少工作量。同时也正如很多商业智能应用需要将数据汇总用作分析,他们业务系统也有类似的汇总数据库,这种级联关系会让数据同步操作进一步复杂化。最终客户使用了UDTS作为跨云数据同步的解决办法,在保障数据一致的同时,DBA只需要提供两边数据库的连接和账号信息即可将数据同步任务托管,释放了精力去处理业务上的数据库工作需求。

    1.1.1 数据同步

    前面提到MySQL事务,在理解存量数据迁移过程中的数据一致性时,需要先了解InnoDB为代表的事务引擎和MyISAM代表的非事务引擎。使用MyISAM引擎的数据表确实没有很好的数据一致性确保手段,存量数据只能对数据表加读锁并迁移,在完成存量数据同步后,通过binlog追平,这样因为读锁会阻塞数据的写入,会导致业务的写入功能不可用,而且这一不可用的时间视表中数据体量而定。

    幸而因为MyISAM的不灵活,实际互联网公司中已经很少使用MyISAM引擎了。而InnoDB引擎因为它支持事务和行级锁的特性,在数据同步过程中对业务的影响小很多,但也因此对数据一致性的保护方法也相对复杂,而这一套一致性保护方法,核心就在于基于连接session的事务隔离和基于MVCC的数据版本管理。

    在存量数据同步启动的时候,数据迁移工具会在自己对数据库的连接session上设置事务隔离级别为REPEATABLE READ,自动提交设置关闭,并且启动一个事务。这个时候,只要这个session上的这个事务最终没有隐式或显式的提交,这个session里看到的数据就不再发生变化,这样就可以保证存量阶段的数据都是同步任务启动那个瞬间的数据,而不管其它session连接会对数据库做怎么的修改。之所以能做到这样,是因为使用了InnoDB引擎的表有三个隐藏列,分别是行ID DB_ROW_ID,行事务ID DB_TRX_ID和回滚指针DB_ROLL_PTR,同时在相同表空间内维护undo log。

    对于insert操作,会在表空间内写入一行数据,记录DB_ROW_ID 和DB_TRX_ID,但DB_ROLL_PTR为null;对于update操作,则undo log是写入一行数据并且根据update语句更新字段数值,记录DB_ROW_ID 和DB_TRX_ID,同时DB_ROLL_PTR指向被修改前的数据行;至于delete操作,则复制数据到undo log中,记录数据删除位,并且将DB_ROLL_PTR指向原先数据。假设数据导出事务启动的同时,mysql上面还有多个活跃事务,这时候数据导出事务就是存量事务中DB_TRX_ID最新的一个,记为Tmax,而这些事务中最老的事务ID为Tmin,而从表空间中导出的每一行的数据为T,通过这些事务ID和一定的比较方法,就可以判断读出的数据对于数据导出任务是否应该保留。

    如果T比Tmin还小,或者T小于Tmax且不属于数据导出事务启动时的任何活跃事务,说明这一行数据在数据导出前已经落地,如果还没有被删除则应该予以保留,而其他行则通过DB_ROLL_PTR从undo log中找到数据的上一版本,再通过上一版本的DB_TRX_ID再进行迭代判断。这一处理过程,就是InnoDB引擎的MVCC版本控制实现。

    InnoDB的undo log和MVCC实现

    1.1.2 数据校验

    数据一致性的关键,除了数据同步过程中的一致性保障,更加简单直接的手段是数据校验,只要对比过数据是一致的,那才是真正的一致。MySQL数据校验的手段有很多,其中最经典的是pt-table-checksum。

    pt-table-checksum会新建一个临时的checksum表,并且获取与主库有主从关系的所有从库信息。在校验工作时,工具会将该session的binlog格式设置为statement,这样是为了利用mysql的binlog机制,将主库上执行的sql语句同步到从库去。接着工具会以chunk为单位从主库中读取数据和计算校验,将校验结果写入checksum表,这个过程会在一个语句中完成,随后这个语句由于对checksum表进行修改,会被同步到从库并且被从库执行。这样从库也会在自己的checksum表写入校验值。这个时候工具再从库中把checksum值读出,就可以与主库的计算值进行对比。

    pt-table-checksum的优势在于使用方便,在经历了多年迭代也有非常好的可靠性保证。但是它的技术限制也是明显,那就是要求被校验的两个库需要是主从关系,同时也要求数据表有索引,因为chunk大小的计算是通过索引完成的。

    【案例】

    以近期的xx公司迁移到UCloud为例,在数据同步的阶段由于数据库实例众多,需要减少DBA的工作负担而采用了UDTS来进行数据库迁移,但是这样就打破了源和目标库的主从关系,进而导致pt-table-checksum无法使用。当然实际上数据导出-传输-导入-配置主从这样的机械化操作可以通过制作脚本来解决,但是为了迁移而开发一套重用率不高的脚本代码并不明智。这时候sync_diff_inspector工具的优势就体现出来了。

    sync_diff_inspector是TiDB团队为了方便用户在MySQL数据迁移到TiDB后对数据一致性进行检查的开源工具,它不要求被校验的两个数据库存在主从关系,也没有对数据表索引的要求,甚至允许源库和目标库有不同的库名和表名,只要有明确的映射,就可以对数据本身进行校验。同时,在sync_diff_inspector发现某一块数据存在差异的时候,会通过二分对比的办法,最终找到实际不一致的行,缩小了疑似不一致的数据范围。

    虽然这种相对松耦合的环境下对数据进行校验,可能会出现记录下一些数据不一致,例如主库的某个写入还没有完全即时的同步到从库,这时候进行检查可能会存在数据差异,但是除非源库insert/delete/update操作非常频繁,否则一般期望工具检查发现的差异不会太多。这时候只需要针对检查报告中的少数差异做第二次的手工或脚本校验,就可以确认数据一致性。当然如果一致性检查工具发现有较多数据不一致,我们一是可以用检查工具生成的一致性修复脚本来修复一致性,也可以对通过对数据进行重新同步来完成。

    需要留意的是,pt-table-checksum和sync_diff_inspector都是对实体数据进行校验的工具,在数据量较大的情况下校验操作会相对缓慢,不适合在割接时间窗口中操作。在实际项目中笔者测得一个500G的数据库的完整校验耗时大约28小时。在割接时间窗口中,一般通过select max(id)或者select count(id)对数据进行简单对比。

    1.2 文件存储同步

    1.2.1 文件同步

    相比于MySQL,文件作为一种非结构化的存储方式,迁移方法相对较少,也没有太多的数据一致性保障方法。与此同时,海量小文件的处理效率有限一直都是技术难题。

    一般来说,文件存储的方式一般是硬盘本地存储或者基于NFS协议的存储服务,这两种存储服务中NFS存储的同步会更困难一些。单个文件的同步是简单的,将文件复制到目标空间然后再对文件计算md5校验和,只要两边的数据是一致的就行。难点在于获知文件是否有发生变化。在linux kernel中可以利用 inotify机制了解到本机对文件的修改动作。

    inotify应用在启动的时候除了初始化监听和创建事件队列以外,还会在文件系统操作的函数中加入inotify hook函数以将文件系统事件通知到inotify系统中,这些都是操作系统内核中的系统调用。所以对于NFS而言inotify就失效了,因为相关调用都是本机环境中的系统调用而没有经过网络,挂载了同一个NFS的多台主机没有机制了解对方在什么时候对文件进行了操作。

    当然也有一些实现了分布式锁的文件系统,例如vmware的vmfs和oracle的ocfs,可以共享文件系统数据的同时,通过锁机制来实现操作系统对文件变化的感知,但这是另一个故事了。

    所以这时候,从业务中对出现变化的文件进行记录就很有必要,因为实际上所有对文件的增、删、改都是业务所需的操作行为。所以在数据同步阶段,我们依然通过rsync或类似方法来同步数据,并且通过业务日志记录发生了变化的文件,最后在割接阶段解析业务日志,将出现过变化的文件做最后的增量同步,从而实现数据追平。典型的组件可以参考FastDFS。FastDFS实现了类似binlog的方式,来记录每个storaged接受到哪些文件的更新,是哪种更新操作。在启动storaged之后,就可以实现自动读取其它同副本关系的storaged的数据来恢复。例如大C表示源创建,小c表示创建副本,大A表示源追加,小a标识副本追加,大D表示源删除,小d表示副本删除等等。

     

    实际生产环境中的fastdfs binlog

    1.2.2 文件校验

    文件的校验,这里会涉及到存储静默错误的问题。我们回忆硬盘坏道这个概念,就会发现硬盘自己也不知道某个扇区目前状态是否良好,需要专门进行扫描才能确认。一个扇区写了数据,在长久的运行中这一扇区成为了坏道导致不能读出数据,这时候应用不读取就不知道底层数据出现问题,这就是静默错误。

    要解决静默错误的唯一办法是全链路数据校验:

    在数据上传前,确认数据正常,生成校验和;

    上传到某个存储服务之后,存储服务存储文件并且记录这个文件的校验和;

    定期对数据进行巡检,重新计算文件校验和并且和记录值比较;

    取出数据时,也对数据进行校验和比较,这样才能保证文件数据一致。

    因此从技术层面来说建议从一开始就使用带有全链路数据校验功能的服务,自建存储服务的全链路一致性也需要自行建设,否则在迁移后只能通过md5sum这类工具对全部数据进行校验,确保迁移前后数据没有差异,而不保证迁移后的文件依然是访客当初上传的文件。尽管需要做这样的妥协,海量小文件的迁移和校验依然会造成迁移工期的压力。

    利用md5sum递归遍历整个目录,生成所有文件的md5结果,可以通过以下命令完成:

    find ./ -type f -print0 | xargs -0 md5sum > ./my.md5

    相应的,可以通过以下命令对迁移后的整个目录进行递归遍历校验。

    md5sum -c my.md5

    1.3 对象存储同步

    1.3.1 数据同步

    对象存储的数据同步和校验的复杂度介于数据库和文件存储之间,因为它基本上是基于HTTP协议的,镜像回源的功能就能派上用场了,即如果一个文件在我们平台上不存在,那对象存储会尝试到源站去获取并保存下来。而相对于InnoDB数据表这中结构化数据,对象存储的数据一致性保障还是相对较弱。

    目前市面上各种平台的对象存储服务对S3协议都有较好支持,而通过ufile-import工具就可以将其他支持S3协议的对象存储数据迁移到US3中。虽然US3也支持镜像回源,但是在数据同步的刚开始时,不建议将原平台bucket配置为回源目标之后就将US3作为服务入口来使用起来,因为这个时候US3 bucket中还没有数据,直接使用US3会造成大量镜像回源,一是从而导致整体访问延迟变大,其次也容易出现访问失败的情况。

    ufile-import工具与redis协同工作。在数据同步开始前,ufile-import工具会通过S3协议的列表接口,将一定数量的源bucket对象key以及这些key的同步状态记录进redis中。每当一个文件完成从源bucket的下载、缓存和上传到US3后,导入工具就会在redis中将数据标记为已同步。这样在ufile-import工具因为一些可能的原因,例如网络环境不好等问题故障挂起之后,只需要重启ufile-import,它都可以从断点开始续传。

    当完成一轮数据导入之后,就可以开始配置镜像回源配置了,这时候直接访问US3也能得到不错的命中率。当然也可以选择再运行一次ufile-import工具,如果这样操作需要注意ufile-import工具原本的功能是断点续传的,所以我们应该把redis的内容清除。

    但是直接清理掉redis再重新跑,ufile-import工具的行为是重新加载文件列表并且重写写入US3,这样会导致所有数据都要重新写一次,效率很低。在这个时候,我们可以配置ufile-import工具为文件比对模式,在获取文件列表后将文件都通过HEAD获取文件大小,这时候只要将源bucket HEAD成功,但是US3为not found或者文件大小不同的数据同步到US3即可。在实际的数据迁移实践中,我们可以更加灵活的使用续传和比对模式来提高工作效率。

    【案例】

    以近期的xx公司迁移到UCloud为例,该公司的CDN和对象存储从金山云迁移到UCloud的过程里面,有一个bucket中存在文件数量达到了12亿,将所有key存储到redis中并不合理,会导致redis数据膨胀,进而对迁移中转主机提出非常高的内存需求。这时候应该从一开始就使用比对模式对数据进行迁移,进而避免不合理的redis内存使用。

    1.3.2 数据校验

    对象存储的数据校验方面,大多数对象存储都支持给文件提供ETag的Header,且ETag的生成都跟原始数据有一定关系,所以可以根据源平台的ETag计算方式,在下载到文件后对文件进行一次计算,看看ETag是否相符。而ufile-import功能本身也会按照US3的ETag计算规则预先计算我们的ETag,在上传成功后对比US3返回的ETag和导入工具自行计算的值,来实现对数据的校验。

    2. 数据规整阶段

    2.1 脏数据处理

    正如前面提到,为了了解新平台中应用是否能正常运行,一般来说迁移过程中涉及到的应用测试都会尽量使用真实数据,甚至采用流量重放的方法对新系统进行测试,以便通过原平台环境中真实行为的结果来校验新平台用应用是否正常工作。在测试之后,新平台就会出现脏数据,需要对其进行处理。实际上脏数据的处理也有两种思路可以使用。其一是回滚,就是在开展业务测试前先对数据进行备份或者记录还原点。

    对于MySQL数据库可以备份binlog然后基于binlog进行回滚,也可以通过云平台能力利用备份直接回滚数据库。对于文件存储和对象存储,文件变更日志的作用就很显著了,所有变更过的文件从日志中解析出来之后从源头重新同步,这样可以避免所有文件的重新同步。当然也可以丢掉全部脏数据,采取跟第一章相同的数据迁移手段对数据进行重新同步,这样虽然慢一些,但是整个数据同步过程就是幂等的,可重复性更强。两种脏数据的处理方式可以视乎数据量灵活采用。

    2.2 保障数据一致性

    在割接准备阶段时候进行的数据同步,这时候所得到的数据就是割接和割接后的生产数据了,所以需要通过一定的手段,保障数据的持续同步,同时避免数据被意外修改。下面说说几种保障的办法。

    2.2.1 基于用户的数据库只读

    对于MySQL而言,通过对数据同步和业务设置不同的账户,并且对不同用户分配不同的权限,这几乎是最简单易行的实践方式。设立数据同步账户,赋予增删查改权限和DDL语句的权限,这样可以满足存量和增量数据同步的需要,然后将数据同步账户严格控制只配置给UDTS数据同步工具和sync_diff_inspector数据校验工具。而对于业务应用的配置文件,或者记录到配置中心中的配置,上面所使用的数据库账户就只分配select语句权限,这样就能保障业务应用、脚本或者各种定时任务都无法对数据进行更改。而且这样做还有一个好处,对于一些没有实现数据库重连逻辑的业务应用,这时候数据库是可以正常连接的,这意味着在割接的时候不需要重启应用,而是只需要调整MySQL中业务账户的权限。

    对于一些场景,不重启对于割接过程来说是非常重要的。例如由于分布式框架的引入,对象和方法可以轻松的通过RPC获取,这时候业务团队也专注于业务的实现,忽略了底层重连机制的实现。结果就是应用系统成为了一个分布式的紧耦合系统,主机A上某个进程的正常运行需要依赖主机B上进程的正常运行,而且B还不能随便重启,因为重启后A不会重连。这时候如果应用不用重启,那意味着清理脏数据后,应用保持当前的运行状态即可,而不是调查所有应用的启动顺序,在割接时确认数据同步后再按顺序逐个启动,这样对于割接后的业务稳定性和割接操作复杂度都是大有裨益的。

    通过数据库只读来保障数据一致性的方式受限会比较多。MySQL有基于用户的只读方法,与此同时redis,sql server,mongodb,Elastic Search,文件存储,对象存储等等组件又有各自不同的只读方法,在组件数量和种类增加以后,这种操作方式的优势会逐渐丧失。所以对于数据库数量在数十个,且只有少数几款数据库应用的时候,数据库只读会是一个很有优势的数据一致性保障方法。

    总结一下,数据库只读的方式适用于MySQL数据库且实例数量不多的情况,例如整体迁移以模块化方式进行的情况。另外对于需要尽量减少应用重启操作的系统可以优先考虑。

    2.2.2 结束应用进程

    前面提到,在一些应用系统里重启应用并不是易事;那自然就有一些应用系统,重启造成的困扰并没有那么大,可以相对自由的重启应用。实际上对于一个系统而言,会有三类程序可能对数据存储进行修改,分别是应用程序和操作系统定时任务脚本,对于数据库而言还需要多加一个定时任务。只需要保证这三类程序都是停止的,那么就可以保证没有同步服务以外的程序对数据进行修改,从而保障数据一致性。

    通过这种方法来保证数据不被意外修改的优势在于他是普遍适用的,不管提供存储服务的是数据库或者琳琅满目的各种存储服务,只要进程停了数据就不可能被修改。但是这种处理方法的限制也是很明显的。首先就是应用可以随意重启。更重要的是在分布式环境下面,需要具备批量的启动或者关闭应用程序,以及修改操作系统定时任务的能力,不管是基于ansible或者其他方式,除此以外也需要确保生产环境中应用程序和脚本的统计是正确的,也就是说所有应用程序和脚本都是运维和开发共同知晓的。例如运维为了短时间方便,编写脚本作用在生产环境的数据而不被其他同事所了解,那在停止应用的时候自然也不会被考虑到。

    总结来说,结束应用程序的方式适合应用可以各自独立启停,且生产环境应用、脚本和数据库定时任务都完全统计清楚明确的情况下使用。

    2.2.3 ACL网络隔离

    通过ACL对网络数据存储服务做隔离是一个操作上相对比较简单的方法。简单来说,就是在网络环境上配置ACL,允许数据同步服务连接存储并且禁止其它应用主机连接。这种方法的优势在于规则的套用和解除都相对简单,在数据同步是直接对一整个VPC子网生效,在割接时候又只需要在控制台上解除,对整个子网的存储服务做到批量控制。而且相比于数据库只读和结束应用进程,这两种方法都依赖于运维团队对全系统所有细节的掌握,通过网络ACL进行隔离则可以忽略应用系统细节,而且对所有基于网络的存储服务都能覆盖,可以说完全具备了前面两种数据一致性保护方式的优点。

    当然ACL网络隔离的方法也有它的适用场景限制。其中最主要的是这个方法的实施要求运维团队对各个子网的功能划分是清晰明确的,网络入口、业务应用和数据存储分别在不同的子网,所以如果应用习惯了大二层的部署方式,那么网络ACL的批量管理优势就会大打折扣。其次,由于对于应用的网络中断,所以对于没有重连机制的应用,也网络重新开通后依然需要重启应用。最后就是这一方法对于不走网络的应用是无法限制的,例如云硬盘本地存储,这种情况需要以挂载云硬盘的主机为单位去考虑网络隔离。

    经过对上面几种保障数据一致性方法的了解,其实我们可以发现这几种方法其实并没有相互冲突的点,可以灵活组合来匹配更多实际环境的要求,例如同时使用结束应用进程和ACL网络隔离。

    【案例】

    在XX公司的跨云迁移任务中,有几个条件是在前期调研中发现的。首先是数据库实例数量众多,源库和目标库既有自建的也有云平台产品,具体操作方式各有差异;其次是数据存储服务种类众多,除了MySQL以外,还有MongoDB、SQL Server、NFS存储、Elastic Search等,逐个组件去设计读写-只读切换的逻辑需要运维人员很大的精力投入;再次,目标系统对存储和应用有比较好的网段划分,虽然组件众多,但是至少都在相同子网内,适合使用ACL来隔离;最后就是,应用方面也确实没有读写-只读的切换开关,而且也没有实现重连机制。所以,在实际操作过程中,笔者使用了结束应用进程和ACL网络隔离的双重保险,因为应用不具备重连实现的情况下,割接测试前应用至少需要重启一次的,ACL和结束应用的限制都会被接受,与此同时ACL隔离也补充了结束应用的覆盖面,从网络层面保障不会有数据同步组件以外的系统连接到数据存储层面来进行操作。

     

    3. 数据割接阶段

    3.1 数据校验时机

    不管是整体割接,还是以业务模块为单位的割接,时间窗口大小总是有限的,而且从业务角度也希望割接窗口越小越好。

    数据校验最早应该在完成数据规整后才启动,这一点应该是可以简单理解的,因为数据规整前的数据不用作割接后投产,没有校验价值。而在前面数据校验章节中提到,数据校验分为两种,一种是sync_diff_inspector这类实体数据校验,另一种是select max(id)这类元数据校验,两种方法并不冲突,在实际任务中可以灵活安排来减少对割接时间窗口的压力。

    【案例】

    以近期XX公司迁移到UCloud项目为例,割接时间只有凌晨12点到早上6点的6个小时,中间需要进行应用配置和业务测试,留给数据校验的时间不多,所以早在数据割接之前就启动了sync_diff_inspector对实体数据进行校验。结果数据校验时间和效果都如前预料,最大一个500G数据库的实体数据校验花费了1天多的时间,同时多个数据库的校验也发现了少量的不一致,这一部分不一致经过人工对比后发现发现也实际一致。随后在割接过程中进行元数据校验,结果随着消息队列完成消费和定时任务结束,两边的select max(id)或者select count(id)结果最终一致了。

    3.2 割接与回滚

    在割接阶段,不得不考虑的一个问题就是回滚,在割接过程中发现数据确实出现了不一致,这时候需要对不一致的范围做合理的评估。如果在割接时间窗口中的元数据校验如果发现不一致,这时候最明智的处理手段就是回滚,而保障原平台没有脏数据则是回滚的基础。

    【案例】

    以xx公司迁移到UCloud为例,在托管IDC迁移到UCloud混合云的过程中,由于业务依赖较少,所以采用了可以敏捷割接和回滚的业务模块迁移方式。在这一案例的割接实践中,运维团队不仅在为数据库设置了只读,而且也在业务应用中嵌入了只读开关,只要通过配置中心发布开启只读开关即可生效。在数据库只读后就参考数据同步阶段的数据校验方式,对数据或者元数据进行校验,最后在确认应用的读取功能都正常以后再解除目标库的只读,开放业务。在这样的案例中回滚也是相对简单的,如果发现应用的读取功能异常,这时候只需将应用重新部署回原平台,启动和解除数据库只读即可。

    而对于需要进行整体割接的任务,割接过程相比于模块化的割接会复杂一些,但是与模块化割接的机理大同小异。在割接过程中先通过停用负载均衡、设置ACL的方式停止业务入口,等待消息队列完成消费数据落地以及定时任务运行完成,然后参考割接准备阶段的方法对原平台数据进行保护。在完成原平台的数据封存后,需要等待同步任务最终完成同步以及对数据进行校验,具体的数据校验方法是参考前面数据校验章节完成的。在确认两边平台数据一致后,就可以停止同步,在新平台启动应用和进行内部测试。

    至于回滚操作,本身也是有时间边界的,当新平台业务入口做了灰度开放后就不能进行回滚操作了,因为这时候有很大机率真正的客户数据已经写入到新平台,但是这部分新数据又没有同步回原平台,这样两边数据就是不一致的。

    但是一般而言,只要保证迁移两边平台数据是一致的,应用程序大多是应用状态或者代码逻辑问题,相对可控。

    本文由UCloud华南架构部团队成员创作

    如有疑问或咨询,欢迎留言探讨!

    展开全文
  • 其结果将对其性能、可用和兼容产生直接影响。 通过简单地改变数据的存储格式,我们就可以解锁新的功能,提高整个系统的性能,这很有启发意义。 Apache Hudi、Apache Iceberg 和 Delta Lake是目前为数据湖设计的...

    一、介绍

    在构建数据湖时,也许没有比数据格式存储更具有意义的决定。其结果将对其性能、可用性和兼容性产生直接影响。

    通过简单地改变数据的存储格式,我们就可以解锁新的功能,提高整个系统的性能,这很有启发意义。

    Apache HudiApache IcebergDelta Lake是目前为数据湖设计的最佳格式。这三种格式都解决了数据湖最迫切的一些问题。

    1. 原子事务–保证对数据湖的更新或追加操作不会中途失败,产生脏数据。

    2. 一致的更新–防止在写入过程中读取失败或返回不完整的结果。同时处理潜在的并发写入冲突。

    3. 数据和元数据的可扩展性–当表增长到数千个分区和数十亿文件的大小时,避免对象存储API和相关元数据的瓶颈。

    让我们仔细分析下每种格式在更新性能、并发性和与其他工具的兼容性方面的做法。最后,我们将就某种格式对你的数据湖建设提出最有意义的建议

    二、平台兼容

    2.1、Hudi

    Hudi 最初是由 Uber 开源的,它被设计成支持通过列式数据格式进行增量更新。它支持从多个来源摄取数据,主要是Apache Spark 和 Apache Flink。它还提供了一个基于Spark的实用程序(DeltaStreamer)来读取外部资源,如Apache Kafka。

    支持从 Apache Hive、Apache Impala 和 PrestoDB 读取数据。还有一个专门的工具(HiveSyncTool)可以将Hudi表模式同步到Hive Metastore 中。PS: Hudi 社区也支持 DLA

    2.2、iceberg

    Iceberg 最初由 Netflix 发布,旨在解决在 S3 上存储大型 Hive-Partitioned 数据集时出现的性能、可扩展性和可管理性挑战。

    iceberg 支持 Apache Spark 的读和写,包括Spark的结构化流。Trino (PrestoSQL)也支持读取,但对删除的支持有限。同时支持Apache Flink 的读和写。最后,Iceberg 为 Apache Hive 提供了读支持。

    2.3、Delta Lake

    Delta Lake是由Databricks(Apache Spark的创建者)作为一个开源项目进行维护,并不奇怪,它与Spark在读写方面都进行了深度集成。

    使用Hive的SymlinkTextInputFormat为Presto、AWS Athena、AWS Redshift Spectrum和Snowflake提供读取支持。尽管这需要为每个Delta表分区导出一个symlink.txt文件,而且正如你所说,对于较大的表来说,维护成本变得很高。

    三、更新性能与吞吐

    对大型、不可变对象的行级更新的支持可以通过几种方式来实现,每种方式都有其独特的关于性能和吞吐量的权衡。

    让我们看看每种数据格式对UPSERT操作采用的策略。我们还将谈到与读取性能相关的额外优化。

    3.1、Hudi

    Hudi 表在处理 UPSERTS 时提供的性能权衡是灵活的(明确的)。两种不同类型的 Hudi 表之间的权衡是不同的。

    Copy on Write Table

    • 更新完全写在列式拼接文件中,创建新的对象。这增加了写的成本,但将读放大降低到零,使其成为读负载重理想选择

    Merge on read Table

    • 更新立即写入基于行的日志文件中,并定期合并到列式parquet中。有趣的是,查询可以包含最新的日志文件数据(快照视图),也可以不包含(读优化视图),为用户在数据延迟和查询效率之间提供不同的选择性

    Hudi 通过利用关键索引进一步优化压缩,有效地跟踪哪些文件包含陈旧的记录。

    3.2、Iceberg

    随着去年夏天 Spark 3.0 的发布,Iceberg 通过 MERGE INTO 查询支持 upserts。它们使用直接的 Copy On Write 的方式工作,其中包含需要更新记录的文件会立即被重写。

    Iceberg 的优势在于包含大量分区的表的读取性能。通过维护 manifest 文件,将对象映射到分区,并保持列级统计,Iceberg避免了昂贵的对象存储目录列表或需要从 Hive 获取分区数据。

    此外,Iceberg 的清单允许一个文件同时分配到多个分区。这使得 Iceberg 表能高效地进行分区修剪,并改善了高选择性查询的延迟。

    3.3、Delta Lake

    在 MERGE 操作过程中,Delta 使用元数据信息的数据跳转,将文件分类为需要插入、更新或删除的数据。然后,它执行这些操作,并将它们作为 "提交 "记录在一个名为 Delta Log 的 JSON 日志文件中。这些日志文件每10次提交就会重写一次,作为Parquet 的 "检查点 "文件,保存整个表的状态,以防止昂贵的日志文件遍历。

    为了保持性能,Delta 表需要定期进行压缩处理,将许多小的 Parquet 文件合并成较少的大文件(最佳情况下约1GB,但至少128MB大小)。Databricks 的专有版本 Delta Engine 支持自动压实,该过程会自动触发,并支持其他幕后写优化。

    Delta Engine 通过使用 Bloom Filters 提供关键索引、Z-Ordering 以在读取时更好地修剪文件、本地缓存等,进一步提升了其开源版本的性能。

    四、并发保证

    允许数据表的 in-place 更新意味着要处理并发性问题。

    如果有人在更新表的同时读取表,会发生什么?而当多个 writer 同时进行冲突的修改时,又会怎样?

    通常数据库通过多版本并发控制(MVCC)来解决这个问题,这种方法利用一个逻辑事务日志,所有的更改都会被追加。

    另一种称为优化并发控制(OCC)的方法允许同时发生多个写入,只在最后提交前检查冲突。如果检测到冲突,其中一个事务会被重试,直到成功。

    4.1、Hudi

    True to form,Hudi 提供 MVCC 和 OCC 并发控制。

    Hudi 的 MVCC 意味着所有的写入必须在其中心日志中完全有序。为了提供这种保证,Hudi将写并发量限制为 1,这意味着在一个给定的时间点上,只能有一个writer对一个表进行写。

    为了防止这种限制,Hudi 现在提供了 OCC。这个功能需要 Apache Zookeeper 或者 Hive Metastore 来锁定单个文件并提供隔离。

    4.2、Iceberg

    Iceberg 通过在更新过程中对元数据文件进行原子交换操作来支持优化并发(OCC)

    其工作方式:

    • 每次写入都会创建一个新的表 “快照”。
    • 然后,写入者会尝试对一个持有当前快照ID的特殊值进行比较和交换(CAS)操作。
      • 如果在提交过程中没有其他写入者替换快照,则操作成功。
      • 如果在此期间有另一个写入者进行提交,另一个写入者将不得不重试,直到成功。

    在分布式文件系统上,如HDFS,这可以在本地完成。对于 S3,需要一个额外的组件来存储指针(目前只支持Hive Metastore)。

    4.3、Delta Lake

    据 Delta 文档解释,它使用Optimistic Control来处理并发性,因为大多数数据湖操作都会将数据追加到一个时间排序的分区,不会发生冲突。

    在两个进程向Delta Log文件添加提交的情况下,Delta会 "默默地、无缝地 "检查文件变化是否重叠,如果可能的话,会让两个进程都成功。

    不过这意味着,底层对象存储需要提供一种方式,当多个写入者开始覆盖对方的日志条目时,要么提供CAS操作,要么提供一种写入失败的方式。

    与 Iceberg 类似,这个功能在 HDFS 上是可以开箱即用的,但S3不支持。因此,在 AWS 上的 Delta 不支持从多个Spark集群进行写入,且没有真正的事务性保证。

    注意:专有的 Delta Engine 版本支持使用 Databricks 自己管理的外部同步服务器在 S3 上进行多集群写入。

    五、如何选择合适的

    如果你看到这里,我们已经了解了 Apache Hudi、Delta Lake 和 Apache Iceberg 之间的一些重要的相似之处和不同之处。

    现在是时候决定哪种格式对你的用例最有意义了! 我的建议是取决那种情况最适用

    5.1、Iceberg 的应用场景

    你的主要痛点不是对现有记录的更改,而是在对象存储上管理巨大的表(超过10k个分区)的元数据负担。采用Iceberg将缓解与S3对象列表或Hive Metastore分区枚举相关的性能问题。

    相反,对删除和变更的支持还是初步的,而且涉及到数据保留的操作开销。

    5.2、Hudi 的应用场景

    你使用各种查询引擎,并且需要灵活管理变更的数据集。请注意,支持工具和整体的开发者体验可能较差。尽管有可能,但为实际的大规模生产工作负载安装和调试Hudi也需要一定的操作开销。

    如果你正在使用AWS管理服务,如Athena,Glue或EMR - Hudi已经预装和配置,并由AWS支持。

    5.3、Delta Lake 的应用场景

    你主要是一个Spark商店,并且期望相对较低的写入吞吐量。如果你也已经是Databricks的客户,Delta Engine为读写性能和并发量都带来了显著的改善,对他们的生态系统进行双重开发是很有意义的。

    对于其他Apache Spark发行版来说,要明白Delta Lake虽然是开源的,但很可能会一直落后于Delta Engine,以起到产品差异化的作用。

    5.4、Integration With lakeFS

    如果你想知道 “我可以用 lakeFS 和这些数据格式一起使用吗?”…答案是肯定的。

    lakeFS可以与Delta、Iceberg或Hudi中的任何一种共生,提供跨任何数量的表进行分支、合并、回滚等操作的能力。

    由于这些格式都是在表级操作,所以对跨多个表的操作没有提供保证。通过 lakeFS,可以在一个孤立的分支上修改多个表,然后将这些修改原子地合并到一个主分支上,实现跨表的一致性

    Further Reading

    • ARTICLE: Diving Into Delta Lake: Unpacking the Transaction Log

    • DOCS: Branching Recommendations: Cross Collection Consistency

    • VIDEO: A Thorough Comparison of Delta Lake, Iceberg and Hudi

    • ARTICLE: In-depth Comparison of Delta, Iceberg, and Hudi

    • BLOG: Efficient Upserts into Data Lakes with Databricks Delta

    • ARTICLE: Comparison of Big Data storage layers: Delta vs Apache Hudi vs Apache Iceberg

    This article was contributed to by Paul Singman, Developer Advocate at lakeFS.

    关注我的公众号【宝哥大数据】,更多干货

    在这里插入图片描述

    展开全文
  • 知识点:MVC数据验证概述、验证属性的使用、自定义验证、扩充基于 Entity Framework 的数据模型。 ASP.NET MVC 中的视图(View)负责向用户呈现操作界面、收集数据并传回服务器。在用户使用过程中,由于用户疏忽...

    知识点:MVC数据验证概述、验证特性的使用、自定义验证、扩充基于 Entity Framework 的数据模型。

    1、MVC 数据验证概述

    1.1  为什么要进行数据验证

    ASP.NET MVC 中的视图(View)负责向用户呈现操作界面、收集数据并传回服务器。在用户使用过程中,由于用户疏忽或恶意原因,用户输入数据对系统可能存在各种隐患,因此需要对从用户界面收集的数据进行各种规则的验证,确保数据符合系统要求。

     

    1.2  数据验证的方案(双重验证

    Web应用程序必须对用户输入进行验证,不仅需要在客户端进行验证,在服务器端也需要进行验证。客户端进行验证会对用户向表单中输入的数据给出即时的反馈,提高用户体验;在服务器端进行用户输入验证除了服务器端验证可以实现更复杂的验证逻辑外,主要是由于来自网络的数据是不能信息的。

    用户输入数据的验证既包括逻辑验证,也需要实现用户友好的错误提示信息,当

    展开全文
  • 点击上方蓝色字体,选择“设为星标”回复”资源“获取更多资源作者丨石秀峰今天我们来探讨一下关于数据治理的灵魂三问:1、数据治理治什么,治的是数据吗?2、数据治理在哪里治,中台还是后台?3、数...

    点击上方蓝色字体,选择“设为星标

    回复”资源“获取更多资源

    作者丨石秀峰

    今天我们来探讨一下关于数据治理的灵魂三问:

    1、数据治理治什么,治的是数据吗?

    2、数据治理在哪里治,中台还是后台?

    3、数据治理到底怎么治?

    一、数据治理 治的是“数据”吗?

    数据是指对客观事件进行记录并可以鉴别的符号,是对客观事物的性质、状态以及相互关系等进行记载的物理符号或这些物理符号的组合。其实在我看来,数据可以分为两个部分,一是数字,二是文字。数字是没有意义的抽象符号,数据是有意义的数字。文字表意,数字表量,当两者结合起来,数据就产生了。

    在我们的生活和工作当中,数据无处不在。对企业来讲,有很多数据是无关企业重大利益的数据,是没有治理的必要的。数据治理的对象必须是重要的数据资源,是关乎企业重大商业利益的数据资源,这样的数据资源可以称其为“数据资产”。正如北大教授王汉生先生所说:“数据治理不是对“数据”的治理,而是对“数据资产”的治理,是对数据资产所有相关方利益的协调与规范。”

    我们需要分开来理解这句话:

    ①什么是数据资产?

    ②数据资产的相关利益方是谁?

    ③协调与规范什么?

    先说一说什么是数据资产。我们说不是所有数据都是数据资产,那到底什么才是数据资产呢?

    《企业会计准则-基本准则》第20条规定:“资产是指企业过去的交易或者事项形成的、由企业拥有或者控制的、预期会给企业带来经济利益的资源。” 如果照猫画虎修改一下,不难获得一个关于数据资产的定义:“数据资产是指企业过去的交易或者事项形成的,由企业拥有或者控制的,预期会给企业带来经济利益的数据资源。”由此可见,数据要成为数据资产,至少要满足3个核心必要条件:

    ①数据资产应该是企业的交易或者事项形成的;

    ②企业拥有或者控制;

    ③预期会给企业带来经济利益。

    数据资产的利益相关方是谁?

    根据数据资产的定义,数据资产的利益相关方,包括:

    ①数据的生产者,即通过业务交易或事项产生数据的人或组织。

    ②数据的拥有或控制者,生产数据的人不一定是拥有数据,就像我们天天上网的各种数据都不归我们自己所有,而是落在了各个互联网公司的数据库中。

    ③数据价值和经济利益的收益者。数据治理就是对数据生产者、拥有或控制者,数据价值获益者的规范和协调。

    都什么是需要协调和规范?

    首先是数据的标准化,定义统一的数据标准,“写中国字、说普通话”让数据资产的相关利益方在同一个“频道”沟通。数据的标准化包含几个层面:①数据模型标准化。②核心数据实体的标准化(主数据的标准化)。③关键指标的标准化。

    其次是数据的确权。数据一旦成为资产,就一定有拥有方,或者实际控制人,可以把他们统称产权人。与实物不同的是,实物的产权是比较明确的,数据则比较复杂。产品在生产制造过程中,并没有与消费者交易之前,制造商拥有完全产权。产品生产出来后,消费者通过购买支付相应的货币,便拥有了产品的产权。而数据的生产过程就不一样了,我们的各种上网行为每天都会产生大量的数据,例如:网上购物、浏览网页、使用地图、评论/评价……。这些数据到底归谁所有?控制权该如何治理?这是摆在面前的一个难题!我们看到近几年一些不良商家,利用我们的上网数据,导致安全隐私泄密的事件也层出不穷。希望随着技术和商业的进步,尽快能够找到解决方案!

    第三是流程的优化。数据治理的两个目标:一个是提质量,一个是控安全。互联网数据的确权目前已经是一个世界级难题,做好企业业务流程的优化可能会对隐私保护起到一定的作用。通过业务流程优化,规范数据从产生、处理、使用到销毁的整个生命周期,使得数据在各阶段、各流程环节安全可控,合规使用。另外,通过一定的流程优化,通过对相关流程进行监管,按照数据的质量规则进行数据校验,符合“垃圾进、垃圾出”的数据采集、处理、存储原则,提升数据治理,赋能业务应用。

    二、数据治理 到底在哪里治?

    数据治理到底应该放在中台,还是后台,我个人的理解是:小数据标准化治理靠人工、大数据预测性分析靠智能,将两者结合起来:“人工+智能”形成了完整的数据治理技术体系。一个企业的数据治理既离不开小数据的标准化治理,也离不开大数据的预测性分析。

    这里的小数据,是在承载事物实体的数据,例如:人、财、物等,是企业所有业务开展的载体。其实说白了就是主数据管理。对于主数据的治理笔者认为是一个后台行为,治理核心是“唯一数据源、统一数据标准”,而要达到这一目标是需要从数据的源头抓起的,并且需要大量的人为干预,比如:数据标准的制定和落实,数据质量的清洗,数据的申请审批,数据的分发和共享等。从这里也能够看出小数据的治理,追求的是标准化、精确化,应该是一个后台行为。

    而在大数据时代,得益于大数据技术的突破,大量的结构化、非结构化、异构化的数据能够得到储存、处理、计算和分析,这一方面提升了我们从海量数据中获取知识和洞见的能力。对于大数据,传统的一味追求精确的思维受到了挑战。而对于大数据的治理,允许一定程度上的容错,反而可以在宏观层面拥有更好的知识和洞察力。对于大数据的治理更多的是采用AI技术,例如:知识图谱、语音识别等,对大数据的采集、处理、使用过程加以控制,使其能够合规使用。所以,大数据的治理放在中台似乎更为合适。

    三、数据治理 到底应该怎么治?

    1、找症状,明确目标

    任何企业实施数据治理都不是为了治理数据而治理数据,其背后都是管理和业务目标的驱动。企业中普遍存在的数据质量问题有:数据不一致、数据重复、数据不准确、数据不完整、数据关系混乱、数据不及时等。

    由于这些数据问题的存在对业务的开展和业务部门之间的沟通造成了较大的困扰,产生了很大的成本;各异构的系统中数据不一致,导致业务系统之间的应用集成无法开展;数据质量差无法支撑数据分析,分析结果与实际偏差较大。然而要实现数据驱动管理、数据驱动业务的目标,没有高质量的数据支撑是行不通的。

    目标:企业实施数据治理的第一步,就是要明确数据治理的目标,理清数据治理的关键点。

    技术工具:实地调研、高层访谈、组织架构图。

    输入:企业数据战略规划,亟待解决的业务问题,经营发展需求,业务需求等;

    输出:数据治理的初步沟通方案,项目任务书,工作计划表;

    2、理数据,现状分析

    针对企业数据治理所处的内外部环境,从组织、人员、流程、数据四个方面入手,进行数据治理现状的分析。

    某企业数据治理痛点分析

    组织方面:是否有专业的数据治理组织,是否明确岗位职责和分工。

    人员方面:数据人才的资源配置情况,包括数据标准化人员、数据建模人员,数据分析人员,数据开发人员等,以及数据人才的占比情况。

    流程方面:数据管理的现状,是否有归口管理部门,是否有数据管理的流程、流程各环节的数据控制情况等;

    数据方面:梳理数据质量问题列表,例如:数据不一致问题,数据不完整,数据不准确、数据不真实、数据不及时、数据关系混乱,以及数据的隐私与安全问题等。

    目标:分析企业数据管理和数据质量的现状,确定初步数据治理成熟度评估方案。

    技术工具:实地访谈、调研表、数据质量问题评议表、关键数据识别方法论(例如:主数据特征识别法);

    输入:需求及现状调研表、访谈记录、数据样本、数据架构、数据管理制度和流程文件;

    输出:数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估方案;

    3、数据治理成熟度评估

    数据治理成熟度反映了组织进行数据治理所具备的条件和水平,包括元数据管理、数据质量管理、业务流程整合、主数据管理和信息生命周期管理。

    CMMI DMM数据管理能力成熟度评估模型

    数据治理成熟度评估是利用标准的成熟度评估工具结合行业最佳实践,针对企业的数据治理现状进行的客观评价和打分,找到企业数据治理的短板,以便制定切实可行的行动方案。数据治理成熟度结束后形成初步的行动方案,一般包括数据治理战略,数据治理指标,数据治理规则,数据治理权责。数据治理愿景和使命是数据治理的整体目标;数据治理指标定义了数据治理目标的衡量方法;数据治理规则和定义包括与数据相关的政策、标准、合规要求、业务规则和数据定义等;权利和职责规定了由谁来负责制订数据相关的决策、何时实施、如何实施,以及组织和个人在数据治理策略中该做什么。

    目标:结合业界标准的数据治理成熟度模型,根据企业管理和业务需求进行数据治理成熟的评估,形成初步的数据治理策略和行动路线。

    技术工具:数据治理评估模型,例如:DCMM,CMMI DMM,IBM数据治理成熟度评估模型等;

    输入:第2步的输入以及数据治理评估模型、数据治理评估工具(评估指标、打分表等);

    输出:数据治理评估结果,数据治理策略,初步的行动方案;

    4、数据质量问题根因分析

    数据治理的目的是解决数据质量问题提升数据质量,从而为数据驱动的数字化企业提供源动力,而提到数据质量问题,做过BI、数仓的同学一定知道,这是一个技术和业务“经常打架”相互推诿的问题。

    某企业数据问题根因分析鱼骨图

    产生数据质量问题的原因有很多,有业务方面的、有管理方面的、也有技术方面的,按照80/20法则,80%的问题是由20%的原因造成起的。所以,如果能够解决这20%的问题,就能得到80%的改进。

    目标:分析并找到数据质量问题产生的根本原因,制定行之有效的解决方案;

    技术工具:头脑风暴、5W1H、SWOT、因果(鱼刺)图、帕拉图等;

    输入:数据问题列表、数据U/C矩阵、数据治理现状分析报告、数据治理评估结果;

    输出:数据质量评估结果、对业务的潜在影响和根本原因。

    5、业务影响及实施优先级评估

    通过数据治理成熟度评估,从组织、流程、制度、人员、技术等方面找到企业在数据治理的待提升的领域和环节,再通过数据质量根因分析找到数据质量问题发生的根本原因,进一步明确了数据治理的目标和内容。再接下来,就需要确定数据治理策略,定义数据治理的实施优先级。

    某企业主数据治理实施优先级评估

    不同的数据治理领域解决的是不同的问题,而数据治理的每个领域都有它的实施难点,对企业来说,需要从业务的影响程度,问题的紧急程度、实施的难易程度等多个维度进行分析和权衡,从而找到符合企业需求并满足企业发展的方案。

    目标:确定数据治理核心领域和支撑体系的建设/实施优先级;

    技术工具:四象限法则(分别从业务影响程度/实施难以程度,问题重要程度/问题紧急程度绘制优先级矩阵)、KANO模型

    输入:数据治理成熟度能力评估结果、数据质量问题根因分析结果;

    输出:数据治理实施优先级策略

    6、制定数据治理行动路线和计划

    路线图是使用特定技术方案帮助达到短期或者长期目标的计划,用于新产品、项目或技术领域的开发,是指应用简洁的图形、表格、文字等形式描述技术变化的步骤或技术相关环节之间的逻辑关系。路线图是一种目标计划,就是把未来计划要做的事列出来,直至达到某一个目标,就好像沿着地图路线一步一步找到终点一样,故称路线图。

    某企业数据治理实施路线图

    企业数据治理的实施路线图的制定是以企业数据战略——愿景和使命为纲领,以急用优先为原则,以分步实施为策略进行了整体设计和规划。实施路线图主要包含的内容:分几个阶段实施,每个阶段的目标、工作内容、时间节点要求、环境条件等。笔者观点:任何一个企业的数据治理都不是一蹴而就,一步到位的,需要循序渐进、持续优化!实施路线图就是基于此产生的,因此说数据治理实施路线图也是说服利益相关者支持的一个重要手段。

    目标:确定数据治理的阶段以及每个阶段的目标;

    技术工具:路线图法

    输入:数据治理成熟度能力评估结果、业务影响及实施优先级评估结果;

    输出:数据治理实施路线图或称阶段目标计划

    7、制定数据治理详细实施方案

    数据治理详细实施方案是用于指导主数据的各项实施工作,一般包括:数据治理核心领域、数据治理支撑体系、数据治理项目管理三个方面。

    数据治理总体框架图

    数据治理核心领域包括:数据架构、数据服务、元数据管理、数据质量管理、数据标准管理、主数据管理、数据安全管理、数据生命周期管理。

    数据治理支撑体系包括:组织(组织架构、组织层次、岗位职责)、制度(管控模式、规章制度、考核机制)、流程(归口部门、管理流程、流程任务等)、技术(数据集成、数据清洗、数据开发、数据应用、数据运营、支撑平台、实施方案等)。

    数据治理项目管理方案包括:项目组队、项目计划、质量保证计划、配置管理计划、培训和售后等。

    关于数据治理的核心领域,详见笔者之前分享的数据治理框架解读系列文章。

    关于数据治理的支撑体系,详见笔者之前分享的数据治理成功关键要素系列文章。

    目标:基于数据质量根因分析、业务影响和实施优先级评估结果,制定详细实施方案;

    输入:业务影响及实施优先级评估结果,行动路线和计划;

    输出:数据治理详细实施方案。

    8、数据治理实施过程控制

    数据治理实施过程控制是对数据治理项目的范围控制、进度控制、质量控制和成本控制,通过对企业的各项资源的合理协调与利用,而达成的数据治理目标的各种措施。从项目管理的角度来讲也是项目管理的黄金三角:范围、时间、质量、成本。

    任何项目的质量和进度是需要良好的项目管理来保证的,数据治理也一样。与传统的软件工程项目不同,数据治理项目有着范围边界模糊、影响范围广、短期难见效、实施周期长等特点:

    ①范围边界模糊,数据治理涉及到的关键领域如元数据管理、数据质量管理、数据标准管理、主数据管理等很多是存在交叉的,边界很难界定,例如:实施数据质量管理项目,会涉及元数据管理、数据标准管理等,同样一个元数据管理项目也会涉及数据标准和数据质量。

    ②影响范围广,数据治理的实施不是一个部门能够完成的,是需要从高级管理层、到各业务部门、信息部门通力协作,共同完成的;

    ③短期难见效,数据治理项目实施完成后,其数据治理的效果被每个业务点滴操作所“稀释”,并不像其他项目,例如BI,那样明显的体现出来,所以主导数据治理的部门会经常遭到质疑。

    ④实施周期长,在没有清晰的数据治理目标和范围约定的情况下,数据治理是一个“无底洞”。所以,在实施数据治理项目之前制定好实施路线图和详细的实施方案就显得格外重要(第6、7步)。

    目标:通过对数据治理项目实施过程的进度控制、质量控制和成本控制以实现数据治理的目标;

    技术工具:PP(项目计划)、PMC(项目控制)、IPM(集成项目管理)、RSKM(风险管理)——CMMI过程域;

    输入:6-7步的输出:数据治理实施路线图,数据治理详细实施方案;

    输出:各项项目控制措施,例如:项目计划、SOW、项目风险列表、项目报告、项目总结等;

    9、监控评估数据治理实施效果

    随着大数据技术的不断发展,应当从企业的全局数据治理环境的角度,明确数据治理关键技术运用及其标准规范,构建成效评估指标体系,进行治理效果评价;并运用数据治理能力成熟度模型再次评估,界定数据管理层次,从而使得跨系统、跨业务、跨部门的数据治理体系的建设与实施能够通过各方协作顺利进行,实现卓越数据治理,进而通过数据驱动业务、数据驱动管理和运营以实现企业的降本、增效、提质、创新。

    某企业数据治理看板(数据已脱敏)

    数据治理成效评估指标体系应根据企业及数据治理项目的实际情况制定,一般包括:时间性、数量性、完整性、准确性四个维度。

    ①时间性即数据的及时性。该维度主要通过源业务系统数据接入的上报及时性、接入及时性等方面进行核对。通过分析月指标、周指标、日指标的数据及时率,得出在规定时间和频度周期内接入系统的比例,以此反映数据接入及时性。

    ②数量性。该维度是从数据存量,数据增量,数据访问量,数据交换量、数据使用量等指标反映数据的使用情况,可以分为月度指标、周指标、日指标、时分指标等。

    ③准确性。这个维度主要由各类数据中逻辑的准确性、数据值的准确性、数据频段和字段之间的准确性以及数据的精度等内容组成。该准确率同样包括:月度、每周、每日等准确率指标。 

    ④完整性。此维度主要以单元维度完整性、数据业务维度组合完整性、索引值完整性等不同方面进行核对,是验证数据质量完整性的主要组成部分,包括月度指标、周指标、日指标数据的完整性等内容。 

    目标:检验各项数据治理指标的落实情况,查漏补缺,夯实数据治理效果;

    技术工具:数据治理效果的评价指标体系、各种数据图表工具;

    输入:数据治理效果评估指标;

    输出:数据治理评估的月报、周报、日报等;

    10、数据治理持续改进

    数据治理模式应业务化、常态化,不应是一个项目、“一阵风”的模式。

    数据治理工作应向企业生产、销售业务一样作为一项重点的业务工作来开展,构建专业的数据治理组织,设置合适的岗位权责,建立相应的管理流程和制度,让数据标准贯彻到每个业务环节,形成一种常态的工作。在笔者看来,在数据源头加强企业数据的治理,让常态化治理成为日常业务,才能从根本上彻底解决企业数据质量的各种问题,让数据真正转化为企业资产,以实现数据驱动流程优化、数据驱动业务创新、数据驱动管理决策的目标。

    目标:数据治理常态化,持续提升数据质量,驱动流程优化和管理创新。

    输入:持续的、规范的、标准的各项业务操作;数据治理监控的各项指标和报告;

    输出:持续输出的高质量的数据。

    四、美团配送数据治理实战

    从大的阶段来看,数据治理主要分为存量数据“由乱到治”的阶段,以及增量数据严格按照规章制度实施确保“行不逾矩”的运营阶段。在“由乱到治”的过程中,我们需要沉淀出规章制度、标准规范,以及辅以规章制度标准规范实施的工具和组织。在增量数据的运营阶段,我们主要靠对应的组织确保规章制度的落实,通过审计定期考察实施效果,并在长期的运营中不断完善规章制度。在实现存量数据“由乱到治”的阶段,我们主要采取了“两步走”策略,具体执行策略如下所示。

    4.1 定标准,提质量

    4.1.1 业务标准

    业务标准主要是指标的管理和运营标准,我们主要解决三个问题:指标由谁来定义,指标该如何定义,指标该如何运营。基于这三个问题,我们同时提出了三条原则:

    • 业务团队负责指标的定义。

    • 产研商分负责给出指标定义标准和辅助工具,辅助业务团队完成指标的规范定义,达成指标认知一致性这一目标。

    • 最后由指标管理委员会负责指标的管理与运营,保障指标从创建、审核、上线以及到最后消亡的整个生命周期的运营。   

    为统一指标的定义,我们将指标分为原子指标、衍生指标和派生指标,原子指标通过限定条件和时间的限定生成衍生指标。衍生指标间的“四则混合运算”构成了派生指标。我们不但制定了指标的标准定义,还对其做了准确的资产归属,一个指标出自一个具体的业务过程,一个业务过程归属于不同的数据域,多个数据域构成了美团配送业务线下的分析场景,如下图所示:

    指标定义标准

    4.1.2 技术标准

    这里所说的技术标准,主要是针对数据RD提出的建模标准和数据生产规范,通过建模标准来明确数仓分层架构,并清晰定义每一层的边界与职责,采用维度建模的设计理念。我们的整个仓库架构分为四层:操作层、基础事实层、中间层和应用层,并在每一层同步制定对应的建模规范,如下图所示:

    数仓架构以及建模标准

    除了建模标准外,我们还制定了涵盖从生产到运维环节的生产规范以保障模型的质量,主要包括上线前的模型评审、生产过程中的完成元数据配置、DQC、SLA和生命周期设置以及上线后的日常运维机制等等。尤其针对元数据管理和生命周期管理,我们分别制定了仓库每一层元数据维护规范和生命周期管理规范,其中元数据管理规范,是依据数仓各层级中各种类型表的建模标准来制定,需要做到规范命名,明确数据归属,并打通业务元数据和技术元数据之间的关系。而生命周期管理规范,是依据配送业务特点和数仓各层级现状来制定的,如下表所示:

    仓库各层元数据管理标准

    仓库各层生命周期管理策略

    4.1.3 安全标准

    围绕数据安全标准,首先要有数据的分级、分类标准,确保数据在上线前有着准确的密级。第二,针对数据使用方,要有明确的角色授权标准,通过分级分类和角色授权,来保障重要数据拿不走。第三,针对敏感数据,要有隐私管理标准,保障敏感数据的安全存储,即使未授权用户绕过权限管理拿到敏感数据,也要确保其看不懂。第四,通过制定审计标准,为后续的审计提供审计依据,确保数据走不脱。

    安全标准建设

    4.1.4 资源管理标准

    在资源管理方面,配送技术工程部已经对资源管理涉及的内容进行了合理抽象和准确定义,抽象出租户、资源和项目组等概念。不管是后续的资源预算还是资源管理,我们都需要基于租户和项目组来进行运营,因此,对于业务团队而言,我们只需要将租户和项目组特定职能划分清楚,然后根据不同的职能归属我们的资产,并分配生产该资产所需要的资源。为了方便后续的运营,我们对每个租户和项目组分配确定了责任人,由责任人对运营结果负责。

    对业务部门来说,资源管理的关键是对数据资产做清晰的分类,基于数据的分类划分不同的租户和项目组,将数据和租户、项目组实现一一映射。由于租户和项目组都有特定的责任人对其负责,因此,我们通过这种映射关系,不仅实现了资产的隔离,还实现了资产确权(项目组负责人同时对资产负责和运营)。我们整体将数据分为两大类,一是原始数据,包括流到数据中心的数据和日志中心的数据,针对流入数据中心的数据,根据其产生的方式不同,又进一步分为业务数据和流量数据。二是加工数据,对应着数据团队的仓库建设和其他团队的集市建设。基于上述的描述,针对资源管理,我们做了如下划分和确权:

    资源划分与管理

    4.2 重实施,保落实

    第二步,落实第一步的标准,完成数据治理第一阶段的目标,实现存量数据“由乱到治”,并完成相应组织和工具的建设,为实现第二阶段“行不逾矩”这一目标提供工具和组织能力。在此过程中,主要分成三个方面的治理工作:第一,架构模型“由乱到治”的治理,消除模型冗余、跨层引用和链路过长等问题,在架构上保证模型的稳定性和数据一致性;第二,元数据“由乱到治”的治理,实现指标的标准定义、技术元数据的完整采集并建立指标与表、字段的映射关系,彻底解决指标认知一致性,以及用户在使用数据过程中的“找数难”等问题;第三,围绕着隐私安全和共享安全加强数据的安全管控来实现数据走不脱、拿不走,以及隐私数据看不懂这一目标。

    4.2.1 架构治理

    总结起来,架构方面的治理主要是解决两个问题:第一,模型的灵活性,避免需求变更和业务迭代对核心模型带来的冲击,让RD深陷无休止的需求迭代中;第二,数据一致性,消除因模型冗余、跨层引用等问题带来的数据一致性问题。

    模型灵活性

    配送解决的是效率、成本和体验三者之间的平衡问题,即在满足一定用户体验的条件下,如何提升骑手配送效率,服务更多的商家,以及如何管控骑手,降低配送成本。抽象到数据层面,基本上反映为上游包裹来源的变化、配送对外提供服务的变化以及对内业务管控的变化。为屏蔽业务迭代给核心模型带来的冲击,我们通过对外封装包裹属性和对内封装运单属性,抽象出包裹来源、提供服务、业务架构等一致性维度,任何业务迭代在数据层面只涉及维度的调整,大大降低了对核心模型冲击和“烟囱式”数据建设问题(新来一个业务,就拉起一个分支进行建设)。

    包裹事实分配到运单明细构造单一运单模型

    配送指标体系建设的一个重点就是要输出各组织层级的规模、体验和效率指标,实现对运力的有效管控,运力所属组织的层级关系会随业务的迭代而不断变化。为了适应这种变化,避免仅仅因增加维度带来中间层数据的重复建设,我们将组织层级维表由固定层级建模方式调整为桥接表的方式来自适配组织层级变化,从而实现了中间层模型可以自动适配组织层级的变化,能自动产生新维度的指标。如下图所示:

    桥接表自适配组织层级灵活变动

    在精细化分析的场景下,业务会有分时段、分距离段以及分价格段的数据分析诉求。我们以分时段为例,有晚高峰、午高峰、下午茶等不同的分时段,不同的业务方对同一个时段的定义口径不同,即不同的业务方会有不同的分时段策略。为解决该场景下的分析诉求,我们在事实表中消除退化维度,将原来封装到事实表的时段逻辑迁移到维度表中,并将事实表中的时间进行按特定的间隔进行刻度化作为维表中的主键,将该主键作为事实表的外键。这样,针对业务不同的时间策略需要,我们就可以在维表中进行配置,避免了重复调整事实表和反复刷数的问题。即通过将时间、价格、距离事实刻度化,实现灵活维度分析。如下图所示:

    通过将时间刻度化,实现灵活分析

    数据一致性

    数据一致性得不到保障的一个根本原因,是在建模的过程中没有实现业务口径标签化,并将业务口径下沉到主题层。很多同学在基于需求进行开发时,为实现方便,将新指标口径通过“Case When”的方式在应用层和中间层进行封装开发,主题层建设不能随着业务的迭代不断完善,RD在开发过程中会直接引用仓库的快照表在中间层或应用层完成需求开发。久而久之,就会造成数据复用性低下,相同指标的口径封装在不同的应用表来满足不同报表的需求,但随着应用的增多,很难保障相同指标在不用应用表封装逻辑的一致性,数据一致性难以得到保障,同时这种方式还带来两个严重后果:第一,跨层引用增多,数据复用性低下,造成计算和存储成本的浪费;第二,一旦指标口径发生变化,将是一个“灾难”,不仅影响评估是一个问题,而且涉及该指标的应用层逻辑调整对RD来说也是一个巨大的挑战。

    治理前模型架构

    因此,我们在“由乱到治”的治理过程中,以衍生事实的方式实现业务口径标签化,将业务逻辑下沉到主题层,消除跨层引用和模型冗余等问题,从技术层面保障数据一致性是该阶段架构治理的重点。我们在业务上,已经划分了严格的数据域和业务过程,在主题建设层面,将业务划分的数据域作为我们的主题,并基于业务过程进行维度建模,将属于该业务过程的指标口径封装在对应业务过程下的衍生事实中。

    治理后模型架构

    4.2.2 元数据治理

    元数据治理主要解决三个问题:首先,通过建立相应的组织、流程和工具,推动业务标准的落地实施,实现指标的规范定义,消除指标认知的歧义;其次,基于业务现状和未来的演进方式,对业务模型进行抽象,制定清晰的主题、业务过程和分析方向,构建完备的技术元数据,对物理模型进行准确完善的描述,并打通技术元数据与业务元数据的关系,对物理模型进行完备的刻画;第三,通过元数据建设,为使用数据提效,解决“找数、理解数、评估”难题以及“取数、数据可视化”等难题。

    首先,为保障业务标准的顺利实施,实现业务对指标认知一致性这一目标。我们协同产研、商分、业务部门推动成立了度量衡委员会,并建立起指标运营机制,通过组织保障来实现指标运营按照规范的标准和流程实施。如下图所示:

    指标注册流程

    其次,基于配送业务的现状和未来演进方式,我们进行了高度的业务抽象,完成了主题、业务过程和分析方向等元数据内容的建设。配送即物流,通过线上系统和线下运营,我们将用户的配送需求和美团的运力进行有效的资源配置,实现高服务体验、低成本的配送服务。对外,我们将配送服务通过平台化的方式,提供给用户、商户和电商平台,以满足不同用户在不同业务场景下的配送需求。对内,我们通过不同的调度模式将运单池中的运单调度给合适的骑手来完成履约,平衡规模、成本和体验之间的关系。如下图所示:

    配送业务模式抽象

    基于以上的业务模式,我们划分了运单主题(对履约数据域下的数据进行构建,支撑规模和体验的数据分析需求)、调度主题(调度数据域下产生的数据,用于支撑调度策略的分析)、结算、评价、投诉、取消主题(用于支撑体验、成本数据分析需求)和管控主题(用于支撑运力奖惩、违规和招募分析需求)等各种主题,并在每个主题下划分对应的业务过程,在应用层制定分析方向的分析标签,通过对元数据内容的建设完成对业务的抽象,为物理模型的刻画准备了基础数据。

    第三,元数据服务建设,我们打通了元数据从采集到构建再到应用的整条链路,为使用数据提效,解决“找数、理解数、评估”难题以及“取数、数据可视化”难题。在整个建设过程中,我们围绕着元数据采集、元模型构建、元数据服务以及最后的产品应用进行展开,整体架构如下图所示:

    元数据建设架构图

    元数据采集

    元数据采集分为人工录入和自动抽取,通过人工录入的方式实现物理表的准确归属(包括该表属于仓库哪一层、对应的主题、业务过程、星型模型关系等)以及指标的采集,从而完成技术元数据和业务元数据的采集,通过自动抽取的方式完成生产元数据的采集和使用元数据的采集,主要包括:物理模型的依赖关系、存储占用、热度、等信息。

    元模型构建

    分为以物理表为核心的基础元模型构建,以及以血缘为中心的血缘元模型。基础元模型构建以物理表为中心,打通其与技术元数据(主题、业务过程、Schema)的关系,实现了物理表的清晰归属,打通其与生产元数据的关系,为其加上了物理表查询热度、资源消耗、查询密级等生产使用信息,打通其与指标、维度和应用的对应关系,为上层的取数应用建立了完备的元数据。血缘元模型以血缘为中心,不仅构建了从上游业务表到仓库离线表的物理血缘,而且打通了仓库离线表到下游对应报表的血缘,为后续的影响评估构建了完备的元数据基础。

    元数据服务

    统一元数据服务(OneService),主要提供两类元数据服务,提供查询表、指标、维度基本信息的基础元数据服务以及查询表级血缘、字段级血缘的血缘服务。

    元数据应用

    主要孵化出了三个产品,以“找数、理解数、影响评估”为应用场景的数据地图(Wherehows),以“取数、数据可视化”为应用场景的数据可视化(QuickSight),以及以管理审计为目的的管理审计报表。

    4.2.3 安全治理

    安全治理主要加强了敏感数据的安全治理和数据共享环节的安全治理。通过对隐私数据的安全治理,不仅要保证其在存储环节的不可见性,而且还要保证在其使用环节对用户进行双重鉴权,字段的密级鉴权和解密的密钥鉴权;通过对数据共享环节的安全治理,我们在数据分级分类的基础上,使数据的权限控制从表级权限控制扩展到行级权限控制。

    敏感数据安全治理

    敏感数据的安全治理,主要是解决敏感数据的存储安全和使用安全。离线场景下,敏感数据存储安全要解决两大挑战:

    • 确保仓库侧处理方案既要屏蔽上游业务系统变动带来的影响,又要屏蔽自身策略对下游BI系统的影响。

    • 要避免敏感数据在整个加工链路中的扩散。

    因此,为解决仓库处理方案与上游业务系统和下游BI系统的解耦问题,我们在上游敏感数据落到ODS环节,确保落到ODS层的敏感数据必须是明文,为保障其安全,对ODS层的所有数据进行文件加密,但是在使用层面,对下游链路透明保障下游链路的正常生产,并限制ODS层数据权限的开放。

    ODS层数据只用于安全生产,通过此方案既屏蔽了上游处理方案对仓库的影响,又解决了敏感数据的安全问题。当数据从离开仓库时,在传输环节对敏感数据进行可逆操作,将敏感数据以明文的形式推入BI库,实现与下游BI系统的解耦。为解决敏感数据在整个生产链路的扩散,我们在快照层对敏感数据进行脱敏处理,从快照层开始消除敏感数据,为保障敏感数据的可逆性,将ODS层的敏感数据抽取到安全库中并进行加密存储,实现安全独立管理。具体执行如下图所示:

    针对敏感数据的使用安全,我们通过对敏感字段的权限控制和对解密密钥的权限控制,来实现敏感数据使用安全这一目标。针对单独抽取的敏感数据,我们除了针对敏感数据设置其相应的密级确保敏感数据的权限管控外,还基于"暗语"的加密方式为每个项目组分配一个相同的密钥,并且将该密钥存放到与Hadoop集群集成的KMS进行管理(确保支撑离线计算的高并发),确保解密时实现密钥的权限管控。

    共享环节安全治理

    针对共享环节的安全治理,我们主要是在数据生产环节完成数据的分级分类和数据确权,在数据的使用环节完成数据的表级权限控制和行级权限控制。确保数据在使用环节规范的审批流转,权限开放以后的安全审计,保证数据走不脱。

    首先,我们在生产环节B3、B2、B1层数据按照主题或实体C层数据按照应用方向进行逻辑划分,并设定资源的密级和权限负责人。特别地为实现B3层数据在查询环节可按照业务线进行权限管控这一目标(即行级鉴权),针对B3层数据,我们标记该数据需要在查询环节进行行级权限管控,标记使用行级鉴权所需的字段和该字段对应的枚举值。

    其次,在使用环节,我们按照资产密级和使用人角色完成数据的审批流转,实现数据的安全共享。

    第三,针对B3层数据,审计是否设置了行级权限管控。在数据开放时是否存在越权使用的情况,以及针对即将离职员工加强数据的使用审计,保证数据走不脱。

    在数据“由乱到治”的治理过程中,我们不仅实现了存量数据的“由乱到治”,并且在此过程中沉淀出了一系列的建模方法论、工具,并建立了相应的安全小组和指标运营组织。同时,我们为后续增量数据治理确保数据建设“行不逾矩”,提供了强有力的组织保障、稳定的辅助工具和严格的执行标准。在数据治理的第二阶段实现增量数据的“行不逾矩”的过程中,我们主要围绕大数据架构审计、大数据安全与隐私管理审计、大数据质量管理审计和大数据生命周期管理审计这四方面的工作展开,保障治理工作的持续进行,不断提高了组织的治理水平。

    5. 工具简介

    5.1 数据地图(Wherehows)

    数据地图作为元数据应用的一个产品,聚焦于数据使用者的“找数”场景,实现检索数据和理解数据的“找数”诉求。我们通过对离线数据集和在线数据集的元数据刻画,满足了用户找数和理解数的诉求,通过血缘图谱,完成物理表到产品的血缘建设,消除用户人肉评估的痛苦。

    离线数据场景

    1. 关键字检索和向导查询共同解决了“找数据”的问题:大部分的检索数据场景下,数据使用者都可以通过关键字检索来得到匹配结果。剩下的一小部分场景,例如,对于新人入职后如何了解整个数仓和指标的体系(数仓分几层,每层解决什么问题,都孵化出什么模型;整个指标、维度体系都是怎么分类,有哪些指标和维度),这部分场景可以使用向导查询功能。向导查询相当于分类查询,将表和指标按照业务过程进行分类,用户可以按照分类逐步找到想要的表或指标。


    2. 我们打通了业务元数据和技术元数据之间的关系,提高了“找数据”的能力:通过“Wherehows”查找到指标后,不仅不可查看指标的业务定义,还能查看指标的技术实现逻辑,指标在哪些维度或维度组合中已经实现,并且能够在哪张表里找到这些维度,或维度组合的指标数据。反之,也可以知道在某个维度下已经实现了哪些指标,对应的指标在哪些表里。这些功能能让用户更加方便地找到想要的数据。

    3. 我们提供了较为完善的数据信息,帮助用户更好理解数据:对于表的信息,“Wherehows”除了提供表和字段的中英文名称、描述信息等基础信息外,为了帮助用户更好地理解表的建设思路,我们还提供了表的星型模型(可以关联的一致性维度及对应的维度表)、表的血缘关系等信息。

    4. 我们通过评论问答功能,帮助用户可以快速得到问题反馈:如果用户看了信息后还是感到有问题,“Wherehows”提供评论问答的功能,用户通过这个功能可以进行提问,会有相应的负责人进行回复。对于重复问反复问的问题,用户通过查看其它人的提问和回复就能找到答案。并且负责人还会定期的将问答信息沉淀到对应的元数据里,不断地对元数据进行补充和完善。

    业务数据场景

    业务数据场景主要想解决的一个问题是,如何知道一个业务表(MySQL表)有没有同步到数仓。如果没有同步,能够找谁进行同步。因为已经打通“业务表 -> 数仓表 -> 产品”三者之间的血缘关系,我们能够轻松解决业务数据场景的问题。

    生产评估场景

    在日常数据生产工作中,我们经常需要对表进行影响评估、故障排查、链路分析等工作,这些工作如果靠纯人工去做,费时费力。但现在我们已经打通了“业务表/字段 -> 数仓表/字段 -> 产品”三者之间的血缘关系,就能够在10分钟内完成评估工作。对于不同的场景,血缘链路提供了两个便捷的功能:过滤和剪枝。例如,某个表逻辑需要修改,需要看影响哪些下游表或产品?应该要通知哪些RD和PM?这种情况下,血缘工具直观地显示影响了哪些负责人和产品,以及这个表的下游链路。

    有些表的链路很长,整个血缘关系图很大,这样会导致用户定位信息或问题。所以血缘工具提供了剪枝的功能,对于没用的、不想看到的分支可以剪掉,从而让整个链路变得更加直观。

    5.2 数据可视化(QuickSight)

    聚焦于数据使用者“取数”场景,使用QuickSight,用户可以不再关心数据的来源,不再担心数据的一致性,不再依赖RD的排期开发。通过所选即所得的方式,满足了用户对业务核心指标的二次加工、报表和取数诉求。首先,我们通过指标池、数据集等概念对离线生产的指标进行逻辑隔离,针对不同用户开发不同的数据集以达到权限控制的目的,如下图所示:

    用户、指标池与数据集间的关系

    其次,我们为用户提供一系列的组件,帮助用户基于为其开放的数据集实现指标的二次加工和数据可视化功能,满足其在不同业务场景下的取数和可视化应用。如下图所示:


    指标加工组件

    6. 总结与展望

    经过三个阶段的治理工作,我们在各个方面都取得了较好的效果:

    • 在数据标准方面,我们制定了业务标准、技术标准、安全标准、资源管理标准,从而保障了数据生产、管理、使用合规。

    • 在数据架构方面,我们通过桥接表、时间刻度化、业务口径下沉等手段提升模型灵活性,并保障数据一致性,消除跨层引用和模型冗余等问题。

    • 在数据安全方面,我们加强了对敏感数据和数据共享环节的安全治理,保证数据拿不走、走不脱,隐私数据看不懂。

    • 在元数据建设方面,我们打通了从采集到构建再到应用的整条链路,并为数据使用人员提供数据地图、数据可视化等元数据应用产品,帮助他们解决了“找数”、“取数”、“影响评估”等难题。

    未来,我们还会继续通过组织、规范、流程等手段持续对数据安全、资源利用、数据质量等各方面进行治理,并在数据易用性上下功夫,持续降低用户的数据使用成本。

    • 在数据架构方面,随着数据库技术的飞速进步,现在已经有很多数据库能够支持千万级乃至亿级数据的现算先用,我们也在尝试使用这些数据库帮助提升数据开发效率,改善数仓分层管理和应用支撑效率。

    • 在数据产品方面,我们将持续完善数据地图、数据可视化等数据应用产品,帮助用户快速探查、高效分析,真正发挥数据的业务价值。

    Elasticsearch在各大互联网公司的应用案例

    你爱或者不爱,他都在那里 - 云/边/端三协同下的边缘计算

    快手基于 RocketMQ 的在线消息系统建设实践

    欢迎点赞+收藏+转发朋友圈素质三连

    文章不错?点个【在看】吧! 

    展开全文
  • 1月25日上午主讲人:邓旭东课程安排:python语法入门1、Python跟英语一样是一种语言2、数据类型之字符串3、数据类型之列表元组集合4、数据类型之字典5、数据类型之布尔值、None6、逻辑语句(if&for&tryexcept...
  • 数据仓库系列4-维度表

    千次阅读 2021-12-02 10:58:10
    文章目录一. 维度表技术基础1.1 维度表结构1.2 ... 使用一致维度集成2.1 一致维度2.2 缩减维度2.3 跨表钻取2.4 价值链2.5 企业数据仓库总线架构2.6 企业数据仓库总线矩阵2.7 总线矩阵实现细节2.8 机会/利益相关
  • Introduction在构建数据湖时,也许没有比数据格式存储更具有意义的决定。其结果将对其性能、可用和兼容产生直接影响。通过简单地改变数据的存储格式,我们就可以解锁新的功能,提高整个...
  • 数据仓库 Inmon

    2021-05-01 12:27:48
    第一章 决策支持系统的发展 1.1 演化 1.1.1 直接存取储存设备的出现 磁盘储存器/DBMS/OLTP 1.1.2 个人计算器/第四代编程语言技术 ...搜索文件或数据库,将符合标准的数据抽取到指定位置 ...数据源/口径/算法/数据 ...
  • 点击上方蓝字关注我们数据权属界定面临的问题困境与破解思路何波中国信息通信研究院,北京 100191摘要:随着数据成为关键生产要素,如何界定数据权属成为各方高度关注的重要问题。首先分析数据...
  • 读透《华为数据之道》

    千次阅读 2020-12-28 07:30:00
    这是傅一平的第361篇原创【提醒:公众号推送规则变了,如果您想及时收到推送,麻烦右下角点个在看,或者把本号置顶】正文开始很多年前阿里出了《大数据之路》一书,在数据技术层面给出了有价值的指...
  • 数据倾斜处理

    2021-10-23 20:34:19
    数据倾斜 ---------------------- 数据倾斜的处理思路 1. 数据倾斜产生原因 做数据运算的时候会涉及到,count distinct、group by、join on等操作,这些都会触发Shuffle动作。一旦触发Shuffle,所有相同key的值...
  • 散列表,Hash Table,用数组支持按照下标随机访问数据的特性,所以散列表其实就是数组的一种扩展,由数组演化而来。 假如有89名候选人参加大选。为了方便记录投票,每个候选人胸前会贴上自己的参赛号码。这89名选手...
  • 摘要本文阐释数据资产和数据资产价值评估的概念,分析和总结了数据资产价值评估的一般方法及其优缺点,经比较分析得出基于业务收益评估数据资产价值具有一定的可行。本文提出了基于业务计划和收益的...
  • 简单介绍一下实证论文中双重差分法(DID)的安慰剂检验(Placebo Test)在Stata中如何操作。 (本文首发于个人微信公众号DMETP,是往期两篇推文的合辑,欢迎关注!) 下面的内容根据实际使用的数据集分为两个部分...
  • 《中华人民共和国数据安全数据安全法》(以下简称《数据安全法》)于本月初开始施行,重点强调了数据全生命周期的各环节的安全保护,对于数据访问、检索、修改等各项行为需做到身份核验、权限控制及风险监测。...
  • 今天,数据资产日益成为企业的核心竞争力。但如果企业在走向数字化过程中遗忘了数据治理,可能再多的投入都会变成一种“徒劳”。今天的文章来自美团配送数据治理团队,他们从数据治理的概念、达成的目标...
  • (一)重要数据:原则上境内存储,确有必要跨境提供需进行安全评估 我国《网络安全法》和《数据安全法》确立了重要数 据出境的基本框架,即重要数据原则上应当在境内存储, 确需向境外提供时应当进...
  • 为引导银行业金融机构加强数据治理,充分发挥数据价值,全面向高质量发展转变,银监会于2018年发布了《银行业金融机构数据治理指引》,主要内容如下:近年来银行业金融机构在业务快速发展过程中,积...
  • ↑↑↑关注后"星标"Datawhale每日干货&每月组队学习,不错过Datawhale干货作者:Dipanjan,来源:机器之心数据聚合、汇总和可视化是支撑...
  • 单例模式是比较常见的一种设计模式,它的实现方式有很多种,曾经见过一篇文章中列了十几种实现方式,比如饿汉式、懒汉式、双重检查锁、枚举。。。等等,大家也应该非常熟悉常见的实现方式,本文简单的谈谈其中的...
  • “读史明智,鉴史知今。”01 不断发展的历史我们先看一下,数据仓库在整个数据平台中的地位。我们需要思考,究竟在什么背景下会出现某种特定形式的数仓呢?这背后的原因是什么呢?数据仓库的定义:...
  • 用户获取所需数据的过程太长和复杂,且缺乏有效数据开发工具,导致用户获取和使用数据存在困难。 1.2.2 数据应用场景持续扩展,敏捷、易用、实时、智能化要求提升 为了充分发挥数据的价值,数据驱动的决策和...
  • 什么是大数据?免费指南和定义 知识中心» 数据整合» 什么是大数据?免费指南和定义…… ... 大数据和隐私:公司需要知道什么才能...大数据是指对于传统的数据处理和数据管理应用来说过于庞大和复杂的数据集。随...
  • 本文根据神策数据业务咨询师潘书荟《数据智能打造“百人百态 & 千人千面”》的主题演讲整理,从判断企业是否需要千人千面、如何实现千人千面以及效果追踪三大方面展开。(文末附 PPT 下载地址) 一、判断企业...
  • 数据清洗该怎么做?

    2021-11-21 11:50:39
    要精确建模,数据是重中之重,但是... 可能破坏数据集预测有效性的最明显就是不属于集合的异常值。例如,iphone手机9.9元,那可能是并夕夕带来的噪声。为了解决这个问题,可以基于数据的四分位数范围应用标准公式...
  • 拆分可用的数据有效训练和评估模型的一项重要任务。在这里,我将讨论 scikit-learn 中的不同数据拆分技术、选择特定方法以及一些常见陷阱。 本文包含易于使用的代码块,并提供快速总结以供参考。 随意将本文加入...
  • 数据中心是数字经济时代的核心基础设施和国家战略资源。《关于加快构建全国一体化大数据中心协同创新体系的指导意见》中指出,优化数据中心基础设施建设布局,加快实现数据中心集约化、规模化、绿色化发...
  • 在集中式的数据交易模式下,大多数据代理混淆数据所有权和数据使用权,以服务换数据,未经数据所有者同意就采集和出售数据,导致数据所有者失去对数据的知情权和控制权。对此,只能通过法律手段对数据代理和交易平台...
  • 作为最重要的数据保护方式之一,NVMe端到端数据保护被众多企业用户所看重,它可以有效降低静默错误的发生,保护范围涵盖数据自Host端生成直至写入SSD NAND当中,以及从SSD NAND读取直至返回Host的全部流程。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 31,096
精华内容 12,438
关键字:

双重数据有效性