转载本文需注明出处：EAWorld，违者必究。
引言：
元数据采集是元数据产品的核心部分，如何提升采集效率是需要仔细斟酌的事情，既要保持稳定性也要保持跟上主流技术的发展趋势。元数据产品从最初集中式WEB应用系统到现在流行的分布式、微服务这种系统架构，原有元数据采集效率已不能满足应用的需求了。目录：
1.元数据采集原理
2.分布式采集策略
3.分布式采集策略的应用
1.元数据采集原理我们要想采集元数据首先得明白，什么是元数据，元数据都存在哪里，为什么采集元数据？元数据MetaData通俗的解释是用来描述数据的数据，实际来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。比如数据库的Schema、Table、Column信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等等。以大数据平台为例，元数据贯穿大数据平台数据流动的全过程，主要包括数据源元数据、数据加工处理过程元数据、数据主题库专题库元数据、服务层元数据、应用层元数据等。数据治理关键就是收集信息，很明显，没有数据就无从分析，也就无法有效的对平台的数据链路进行管理和改进。所以元数据管理平台很重要的一个功能就是信息的收集，至于收集哪些信息，取决于业务的需求和我们需要解决的目标问题。如何采集元数据？元数据采集是指获取数据生命周期中的元数据，对元数据进行组织，然后将元数据写入数据库中的过程。不同来源的元数据获取获取方式也不大相同，在采集方式上有使用包括数据库直连、接口、日志文件等技术手段，对结构化数据的数据字典、非结构化数据的元数据信息、业务指标、代码、数据加工过程等元数据信息进行自动化和手动采集，元数据采集完成后，被组织成符合CWM模型的结构，存储在关系型数据库中。
2.分布式采集架构现在人们对元数据管理工具采集的元数据时效性越来越高，我们元数据管理工具会管理很多来源的元数据，配置很多采集任务定时去采集，如何高效的完成采集任务，影响着元数据管理工具存储的元数据时效性。我们原先采集任务策略是单一采集程序串行执行采集任务，这样的策略采集效率是很低的，为了提高采集效率，我们就采用多个采集程序并发执行采集任务。常见的元数据管理工具架构是传统的集中式WEB应用架构，所有的功能模块都集中在一个应用程序中。3.分布式采集架构的应用我们在某一证券公司做数据治理时，发现该客户的网络架构比较复杂，它的网络架构大概分为三层业务系统层、数据采集层和数据存储层。业务系统分布业务系统层的不同地域，比如A业务系统在北京，B业务系统在上海，C业务系统在广州等。我们要想访问个各个业务系统的数据库只能通过数据采集层的代理IP去访问，不同地域的业务系统代理的IP地址网段也是不同的，数据采集层各个网段之间不能连通，数据存储层是可以和数据采集层的所有网段直接连通的。我们现在元数据的架构是分为应用程序和采集服务两部分，应用程序和采集程序是一对一的关系，针对这种网络情况，我们要对元数据产品的架构做调整。一、将元数据的应用程序与采集服务改为一对多模式，这样我们得需要一个采集服务管理模块，可以对采集服务的信息(IP,端口)进行维护(增删改)，采集的目标数据源与采集程序服务进行映射，一个目标数据源可以配置主备采集服务，主采集服务发生故障后，可以通过备采集服务继续采集工作。采集服务管理模块要考虑易操作性和适用性，如：查看采集服务运行情况、设置默认采集服务等等。二、元数据采集任务调整为并行执行，现在采集元数据步骤为获取元数据>入临时表>与正式表比对，更新元数据ID，得到元数据的变更信息>将元数据和变更信息入正式表。采集任务调整为并行执行的主要的难点是如何取消临时表，因为临时表在元数据存储数据库中只有一份，只有等待当前采集任务执行完毕，清空临时表后，才能执行下一次采集任务。临时表的作用是：更新元数据ID和找出新增、修改和删除的元数据，采集元数据时，都会给每一个元数据生成随机的UUID当作元数据ID，与正式表作比对时，如果某一元数据之前已经入库，需要将该元数据的临时表里的ID更新成正式表里的ID。取消临时表的举措：1、我们选择将元数据编码+元数据类型+元数据父级路径这三项数据进行MD5加密生成的字符串作为元数据的ID，这样元数据的ID也就固定了，不需要和正式表里做比对了。2、通过元数据ID去正式表里查询就可得出哪些元数据是新增和删除的。我们将元数据的所有属性值进行MD5加密生成的字符串作为元数据的属性ID，这样通 过比对元数据的属性ID就可得知该元数据是否修改了。这样我们就可以取消临时表，在采集服务程序中就可以将元数据和正式表数据作比对，得到变化的元数据，将元数据记录直接写入到数据库中的正式表，元数据采集任务也就可以并行执行了。我们在数据采集层各个网段都部署采集服务，这样就实现了高并发元数据采集，这种分布式采集策略优点是：1、采集元数据效率快2、可以并行执行采集任务3、可以适应复杂网络环境的元数据采集。精选提问：
问1：请问如何提高元数据采集的效率，减少对第三方系统的影响？
答：主要有两个方面，1、提高采集效率，减少占用第三方系统的时间，2、选择在第三方系统空闲时间进行采集。
问2：通过元数据ID去正式表里查询就可得出哪些元数据是新增和删除的。删除的元数据，是不是一次采集的全部数据都得在内存中？如果一次采集的数据，内存装不下呢？另外就是，使用数据库事务肯定是不行的了，那如果数据写到一半，因为一些原因出异常了，这数据的一致性是怎么考虑的？
答：采集元数据时可以分批次抽取数据，例如采集某一数据库，可以先采集一部分Schema，入库之后，再采集另一部分，这样可以解决内存的溢出问题。写入数据时，一次采集会在数据库里创建一个临时表(temporary table),先将数据写入到临时表，然后在复制临时表数据到正式表，这样可以保证数据的一致性。
问3：元数据采集过程中和之后，在安全方面应该考虑哪些？
答：采集过程遵循最小权限原则，例如采集数据库元数据时给用户设置最小权限，在使用元数据管理工具时，给不同的用户赋不同的查看、修改、删除等权限。
问4：元数据在金融领域实用哪些场景？
答：金融领域这块主要是监管报送数据来源分析，保证数据来源的准确性。
问5：元数据采集、安全传输、综合应用、版本维护这些在普元的元数据方案中如何体现的？
答：元数据采集是通过分布式采集来实现的，通过部署采集端实现不同来源元数据的采集。传输过程目前是通过数据库jdbc访问方式实现，给用户设置最小权限，保证数据采集过程安全。综合应用中提供了影响分析、数据地图应用场景，版本管理是对元数据版本的管理，是综合运用的一块内容。
问6：元数据是描述数据的数据，元数据的质量如何保障，对于采集到的元数据如何提升挖掘分析能力，也就是元数据的关联分析都有哪些模型？
答：元数据的质量是通过管理+技术的手段来保证的。管理方面要制定元数据的标准，从元数据的完整性、准确性、时效性等不同维度来制定管理的规范。技术方面要提供功能支撑。
问7：元数据分布式采集中，元数据的版本如何管理？元数据存储都有哪些数据库，对于元数据分布式采集和存储，一般支持的数据库有哪些元数据版本管理？
答：你说版本管理应该是元数据变更后的历史信息管理吧，采集时通过元数据ID比对，刷选出新增或删除的元数据，比对属性ID，筛选出修改的元数据，把变更信息记录数据库中。元数据存储库常见的有MySql和Oracle。
问8：元数据采集的核心是什么呢？
答：元数据采集的核心是扩展性和采集的准确性，元数据管理涉及到不同来源和不同类型的数据，要有良好的扩展性，还要保证采集的准确性，如果采集准确性都不能保证，管理员就不能做出有效的决策。
问9：元数据编码+元数据类型+元数据父级路径能详细解释下如何定义，为什么这3个能确定唯一一次变动吗？
答：元数据编码是同类型元数据的区分标识, 元数据类型是标识该元数据是什么类型，元数据父级路径指的元数据所有父级元数据ID组成的字符串，还有一个元数据属性ID，该元数据的所有属性生成的ID，这四个字段能确定元数据是否有变更。
问10：元数据设计时，是否需要带有版本信息；元数据存储时，采用什么方式，便于高效索引或者比对？
答：1、元数据设计时，需要有变更信息表，专门存放元数据的变更历史信息。2、元数据存储时，要有唯一ID和元数据属性ID，这样比对是比较高效的。
问11：正式表md5值是预先就生成好了，然后在采集时直接做调用对比？程序计算md5的效率如何？对程序性能影响大吗？
答：1、MD5值是采集时生成的，然后和元数据存储库里的MD5值比对，得出变更的元数据。2、生成MD5值的效率很快，对采集性能影响不大。
推荐阅读
一文读懂微服务监控之分布式追踪
分布式架构中数据一致性常见的几个问题
区块链技术的本质是分布式数据库
关于作者：追风，普元高级软件工程师，参与普元Metacube7GA设计及研发；有银行、证券等行业数据治理实施的经验。互联网技术爱好者，热衷于研究各种优秀的开源代码，致力于成为一名有腔调的工程师。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！
在看点这里