星环科技李栗：Transwarp Data Catalog智能数据目录为数据资产保驾护航

2019年5月21-23日，由上海星环大数据产业技术发展促进中心主办的第三届前沿科技论坛在上海举办。本次大会，星环科技联合众多合作伙伴、用户展开应用案例分享，让更多行业人士了解大数据在不同行业中的应用效果。

特此推出嘉宾演讲速记，与大家分享，最大限度弥补未到场的遗憾。此为速记整理，一切以现场信息为准。

【演讲内容】

1. 企业数据应用过程中面临的问题

2. 数据资产化建设阶段性效果

3. Transwarp Data Catalog技术特点

4. 数据交换共享架构

5. 元数据采集架构

6. 案例1：某大型零售企业元数据管理系统

7. 案例2：某市政务数据中心共享交换系统

大家好！我是星环科技的高级产品经理李栗，今天带来的分享主题是Transwarp Data Catalog智能数据目录为数据资产保驾护航。我的分享分为几部分，第一，为什么我们要做数字资产管理，第二，怎么做数字资产管理，第三，星环科技数据资产的管理软件跟市场上已有的软件有什么不同，最后是一个案例分享。

1. 企业数据应用过程中面临的问题

企业在数据资产应用的过程中往往会出现几个问题，第一个是数据溯源，企业有时候出现表的变化，需要理解表的变化影响范围，在数据应用的过程中，很容易出现指标出错，这时候需要查看整个指标溯源的过程，定位问题。

第二，数据理解困难，现在企业动辄上百万张表，除了某些技术人员对各自负责的表熟悉之外，技术人员做应用开发时，对这个表不是很理解，不知道这个表能做什么，被谁用过，怎么用。

第三，现在很多企业，尤其是大型企业，总公司和子公司或者各个部门各自存储、开发数据，形成数据孤岛，数据很难进行融合应用。

第四， IDC的研究表明，目前分析师有80%的时间花在数据准备和探索上，对分析师以及业务人员的工作效率影响很大。

第五，数据资产融合应用困难，很多企业知道把数据归集到一起，形成数据湖，但是数据湖仅仅是把数据物理地融合在一起，往往不能融合应用，形成了数据沼泽。数据虽然融合在一起，但是不知道别的部门的数据是如何应用的；可以获取别的部门的数据，但是不知道别的部门的数据的接口如何，使用情况如何，使用场景如何，没有相关的描述信息。

最后是数据资产管理，这不是一个新兴的话题，在十几年前已经有企业做相应的解决方案，但是数据资产管理往往变成一个人力密集型的方案，效果也不尽如人意，这导致了企业在承受高治理成本的同时，还达不到目标。

2. 数据资产化建设阶段性效果

针对以上几个问题，尤其在企业对数据资产管理有很高的期望下，我们把数字资产管理分为三个步骤。

从企业的数据资产化建设角度来看，企业可以分为多个阶段来完成其数据资产的规划与建设，第一阶段先将元数据管理起来，帮助技术人员完善数据管理流程；第二阶段，构建包含业务字典在内的数据资产目录，直接构建业务人员与技术人员之间的沟通桥梁；第三阶段，构建企业的统一数据资产管理平台，打通数据壁垒，促进数据的价值业务化体现。Transwarp Data Catalog为企业数据治理的各个阶段提供可靠、便捷、智能的全流程工具支撑。

接下来我会根据每个不同阶段为大家介绍数据资产目录的功能支持。

1） 元数据管理

元数据管理分为四个步骤。首先采集元数据，很多企业的数据采集和维护管理通过人工来完成，用Excel登记每个表的使用过程、版本管理变化，甚至血缘数据、上下游数据都用Excel管理，这个过程会耗费大量的人力而且精确度无法保证。我们提供的功能是自动采集所有的元数据并且实时更新同步，支持主流的数据源包括分布式数据库、关系型数据库以及一些文件系统等。

第二步，采集元数据之后需要有展示，我们提供的是元数据的描述信息、标签信息，比如采样数据，类型数据，使用记录、修改记录等操作记录，用这些信息来帮助使用者更快地去理解数据。

第三步，元数据分析，最有代表性的就是血缘分析，血缘分析能够解决数据溯源问题，提供包括表变更影响性分析，或者说指标的溯源管理等，提供从文件系统开始传输到ETL，然后到整个数据仓储相关的修改过程，一直到BI或者应用层的全条数据链路的展现，可以帮助我们快速地定位问题。

第四步，元数据监控，我们提供SQL的监控管理，比如SQL的执行情况、数据资产的使用、变更情况、用户的使用情况以及元数据采集情况等监控指标，形成一个综合性的数据监控大屏，帮助运维人员更准确和便捷的完成运维监控工作。

2） 数据资产管理目录

解决完技术人员的问题之后，我们来解决业务人员/分析人员的效率问题，之前说业务人员或者分析人员花了80%的时间在数据探索及数据准备上，我们经过调研，发现主要是因为以下几个问题。

第一个问题，缺乏统一的业务理解，业务人员/分析人员在数据分析时，并没有充分地理解他们需要做什么，在具体的分析过程中应该如何来计算指标，如何计算数据分析过程，这很容易出现方向性的失误。

第二个问题，数据质量差，好不容易找到数据之后发现数据脏乱差，需要花费大量的时间做数据准备。

第三个问题，知道怎么做数据分析了，但是却不知道应该用什么数据做分析，因为企业可能存在大量的数据表，想要在巨量的数据表中找到想要的数据，要问各个部门的技术人员，需要花费大量的时间做数据探索。

第四个问题，数据理解，好不容易找到数据了，这些数据是不是真的符合需求？如何使用这些数据？按照现在的大多数企业的数据展示情况，业务人员/分析人员无法快速地理解这些数据代表什么意思，怎么使用。

我们提供了全局的数据搜索功能和统一的业务字典管理，包括定制存储的展示格式和使用格式，同时业务支持跟技术数据做关联，打破技术人员和业务人员的壁垒，最后提供一个数据质量管理的功能，我们认为数据质量管理应该有业务人员参与进来，看到整个数据质量的结果和过程。

最后经过清洗完数据质量情况，统一了业务理解，高效地发现数据、并结合前一个阶段的元数据展示页面理解数据之后，业务人员可以花更多的时间在数据分析或者业务洞察上，提高分析效率。

3） 统一数据资产管理平台

第三个阶段是搭建统一的数据资产管理平台，这个阶段要基于前面两个阶段已经完成，业务人员和技术人员已经提高效率，大部分企业人员开始使用资产平台。在此基础上，我们要解决数据治理效率低下和数据资产融合应用难两个问题。

我们通过两个方法解决数据治理效率低下的问题，第一个通过业务智能化功能，根据数据的使用情况、数据的元数据信息等得出某某匹配，最后结合人和物形成智能推荐和智能标签算法，帮助企业提高做数据标签的效率。第二个是数据社区，最有价值的数据资产往往是整个用户群体的经验沉淀，包括评分、点赞、收藏、标签、使用记录等等信息，可以快速地提高数据资产的理解。

接下来解决数据资产融合应用难的问题，我们提供了跨租户的数据共享功能，用户通过搜索、数据理解，找到对应的数据之后，使用审批工单流程，快速地申请数据、得到数据、应用数据、共享数据，进而反哺社区，重新发布新的数据资产。

与此同时结合对报表数据的统一采集和管理，向用户展示报表背后的详细数据链路，提供相关信息的搜索、查看和二次开发，结合社区化功能形成报表集市，加速数据和应用的融合。

这是我们整个数字资产管理平台的解决方案，主要就是通过智能化、社区化的手段去解决传统的数据管理方式费时费力的问题，通过数据共享和报表集市等这些偏社区化的功能解决数据资产融合应用的问题。

3. Transwarp Data Catalog技术特点

What makesTranswarp Data Catalogdifferent?

右侧三个特点对应星环科技的ABC战略：AI + BIG DATA + CLOUD。AI技术帮我们创造新的使用场景以及解放密集人力的方案问题；Big Data 技术帮助我们高效存储和管理数据资产，同时拥有强大的数据流转和搜索性能；Cloud技术帮助我们基于最新K8S容器化平台可伸缩扩展的弹性化部署，以便更好地支持不同规模的应用场景。

4. 数据交换共享架构

接下来讲两个核心技术特点的技术架构，偏技术一些。

数据交换共享架构主要关注安全、性能和流程化。在实现这个架构的时候，从安全和管理角度考虑，我们需要一个统一的数据平台来管控或者存储数据；第二，考虑到不同用户群体之间的资源和权限的隔离，我们采用多租户的架构。

下面是统一的平台，系统租户，上面是各个租户。

每个租户里都有一个统一的安全管控组件 Guardian（星环科技自研），主要任务是配置租户间的互信，因为整个流转过程需要通过安全认证。系统租户这边有一个元数据管理组件和数据目录，数据共享的前提是需要知道整个平台有哪些数据，我们在统一的数据平台上搭建一个元数据管理组件，获取相关平台的元数据，同时根据权限同步到不同用户的数据目录中。

普通的租户用户登陆TCC到数据目录上查看数据，同时进行搜索、理解或者看相关的使用经验，得到一个结论，他需要使用哪些数据，可以在数据目录提供数据申请的窗口，使用数据申请了之后，数据目录会发送一个数据申请的工单到工单系统，工单系统把工单通过租户内的通知系统发送给对应的数据管理员，数据管理员通过之后，数据共享任务组件会解析这个工单，生成一个任务流和数据流，对应的数据流做的事情很简单，使用SQL通过JDBC采集统一的数据平台的数据并导入到对应租户的数据库。

整个架构的好处在于它都是通过上层实现，对于安全和权限的管控比较便捷，但是问题在于它只提供了自动化的流转功能和安全，没有考虑到性能。我们用JDBC来做数据流转，大概的性能是5000条数据/秒，这对于动辄上亿条的数据流转任务来说有点杯水车薪，所以我们把架构做了一些修改。

上层无法解决的问题，我们把目光移到下层，大家都知道，星环科技核心的数据库产品Inceptor底层是用HDFS存储的，走上层JDBC太慢，走底层数据拷贝不就快了吗？借鉴这个思路，我们把统一数据平台中的相关表数据的HDFS文件传输到对应的租户中，并且通过数据目录获得目标数据表的SCHEMA，在对应租户中重建一张相同的表并导入HDFS数据就行了，做了一个比较hack的实现。

具体的实现方式可以看到右下角新增的namespase，一个叫tdc-jobs，一个叫dataplatform，顾名思义，tdc-jobs做的是负责处理HDFS流转的任务，dataplatform其实是作为一个数据中转区，这一部分同样承担着租户共享区的角色。

前面的流程不变，开始变化的是执行任务的流程变了，第一步，先连接目标数据库，将数据导出到HDFS集群，第二步，Workflow将会在tdc-jobs这个namespace下建立一个任务pod，这个pod里面主要的工作就两个，先把数据从HDFS集群get下来，然后再put到租户内的HDFS当中。第三步，Workflow在租户内的Inceptor中对共享进去的数据建立一张外表，最后整个任务完成，发出通知。

整个实现下来之后，性能比之前比提高了十倍以上，大概到10万条每秒，但是其速度明显受限于网络和IO，对上亿级别的数据流转任务来说,性能也依旧不够，所以我们再往下思考，这个事情还能不能优化？速度能不能再快一点？

答案是可以的。具体的实现方式，以及前面提到的一些租户之间要互信等等实现的细节，因为分享时间的关系，如果各位有兴趣的话，可以线下交流。

5. 元数据采集架构

元数据采集面临几个问题，第一，它需要支持多数据源；第二，它需要支持自动化采集存量的数据和实时更新增量数据；第三，性能，它面临数十万张表的数据资产的元数据的存储、搜索和相关应用分析的性能需求。

首先，如何自动化地获取存量数据？大多数据库都有数据字典的功能，数据字典可以获取大部分数据的相关表信息、字段信息，我们可以把存量的信息从数据字典中拉取出来。

如何获取增量元数据的实时同步？用户通过上层的各类应用系统，包括BI、SQL EDITOR以及ETL相关的分析系统等，最终以SQL的形式传到语法解析器中，我们的SQL解析器主要依托Inceptor的语法解析器。

Inceptor是星环科技最核心的数据库产品，我们花了五年多的时间，在替代性市场中无缝地迁移过各种数据库软件，替换原来的Oracle、DB2等数据库，同时Inceptor语法解析器能解析各种主流数据库的语法。

怎么解决实时同步增量数据的问题？在左下角Inceptor Compiler架构中画了一个Driver，Parser解决的是怎么解析SQL，Driver解决的是怎么获得SQL执行过程中相关的信息，包括谁执行了SQL？执行的结果如何？耗时是多少？执行计划是怎么样的？这些信息能够帮助做数据和整个集群的运维。

接下来聊一下实时获取增量元数据的问题，我们使用了Hook的技术，Hook是数据在处理过程中拦截事件或获取相关信息流的机制，这个拦截或者说事件型驱动的特性，天然支持了准实时或者实时获取信息。Hook分为很多类型，有PreHook、PostHook、FailureHook等等，可以在SQL整个执行过程中，拿到不同阶段的信息，SQL执行后的信息是我们主要获取的信息流。

我们可以看到SQL执行的过程信息和SQL本身解析出来的信息，SQL本身的信息包含了非常多，比如说这个SQL是一个DDL还是一个DML?它是一个insert、select还是update语句?是由谁发动的？它影响的数据表是谁？它是从哪些数据表到哪些数据表？这些信息可以直接帮助我们构建数据目录的应用场景。

我们通过Hook，通过事件型驱动的方式，把消息发给Kfaka，然后再由我们的数据目录消费这些数据。这块就涉及到我们用这些数据干什么和我们怎么处理、存储这些数据。

用这些数据干什么？第一个帮助用户做数据理解，因为我把所有的元数据采集上来了，第二，因为我知道了有哪些用户来做的哪些SQL操作，结果是什么？所以我们可以得出一个操作记录，包括使用记录和修改记录，使用记录可以帮助用户知道别人是怎么用这些数据的；修改记录，可以知道数据的变更历史以及做数据资产的版本管理。最后是经典的血缘分析，我们知道这个数据被谁改过，改过谁，上下游的数据、SQL信息都已经存档在案，所以我们可以糅合起来绘制成一个血缘图谱。

怎么处理和存储这些数据？刚刚聊到了血缘信息，它是关系型的图数据，在普通的数据库中，无论存储还是查询都面临很大的性能瓶颈，所以我们放在图数据库，对应星环科技的图数据库产品StellarDB，可以让我们很方便和高效的存储和应用这些关系型的图数据。

我们面临的是百万甚至更高级别的元数据的存储和搜索，全局搜索的功能帮助用户进行更好的数据探查，我们把数据存在存在自研的搜索引擎Search中，这可以帮助我们解决百万甚至更高数据级搜索的秒级返回，也改善了用户的数据搜索体验。

以上就是我们元数据采集整个架构实现，它主要解决的是自动化采集、实时更新和多数据源支持，以及性能问题。

6. 案例1：某大型零售企业元数据管理系统

我们来看两个落地案例，第一个案例比较有代表性，是刚才我们谈的元数据管理，它的问题在于很多传统企业用的是手工维护，手工维护元数据信息包括一些血缘信息和元数据本身的描述信息，第二，运维部门没有办法很好地监控所有数据源的使用情况，第三，企业中常见的场景是表的变更影响，或者说指标的溯源，如果没有高效的全链路的血缘图谱，很难清晰地定位问题查看的范围。我们通过自动化的元数据采集，解决手工维护的问题，第二个通过相关的SQL的执行情况，给他们提供一个数据监控大屏的应用，帮助运维部门提高效率，最后我们提供自动维护的全链路的血缘图谱帮助他们解决数据溯源的问题。

7. 案例2：某市政务数据中心共享交换系统

第二个案例是现阶段比较火的政务场景。这几年，政务数据处在一个高速爆发增长的时期，政府部门的特性决定了每个部门的数据有非常高的关联性，但是每个政府部门的数据或者应用都是烟囱式开发，形成了一个很标准的数据孤岛，缺乏整体关联，给数据的融合应用和提升城市的治理决策带来非常大的困难。

为了解决这个问题，我们做了以下几个事情。

首先在数据中心搭建了一个统一的私有云Paas平台，用多租户对各委办局和区县租户进行资源、数据和权限的隔离，同时支持数据中心未来规模增长的弹性伸缩部署；然后把数据归集起来，形成一个最基本的数据湖，用前置机的方式做数据增量同步。

接着通过贴源层的数据转换，数据质量管理以及数据域业务主体划分形成市级数据仓库，并且用统一的数据资产目录进行管理，政府和各个委办局可以通过统一的市级数据中心的数据目录，快速地查找他们想要的信息，并且理解这些数据，确定这是他们所想要的数据之后，平台提供给他们一个数据申请的工单，在对应负责人同意后，数据自动地流转到对应租户的数据库内；最后委办局和区县用户根据综合及全面的数据进行融合开发应用，并且进行综合性的数据分析，支持城市治理决策。

今天我的分享就到这里了，谢谢大家！