万物互联时代，大数据在改变人们创造、获取、分享及消费信息的模式。快速、高效的数据支持探索，可以助力传统企业加快数字化转型的步伐。火山引擎技术探索类产品智能数据洞察（原 DataWind）的技术负责人熊云近期在火山引擎智能增长技术专场的演讲上分享了火山引擎技术探索类产品智能数据洞察技术从无到有的实践经验。
智能数据洞察这款产品在内部现在是受到比较广泛的使用，是我们技术 2B 重要的一分子，在对外的版本里面主要包含了 ABI 和 CDP 两部分，分别用于通用的数据分析和确定业务主题的深度分析。我自己在互联网行业做了很多年的对内支持，又在过去几年经历着大型互联网 2B 的一个历程，有一些感想和心得，这里就借此机会和大家探讨一下。
本次演讲的主题叫《极速数据探索驱动数字转型》，顾名思义希望呈现这样一个逻辑，通过快速的做数据支持的探索，来助力传统企业推进数字化转型。
我讲的内容主要包含四个方面，首先是我过去一段时间和各种企业交流过程当中感受到的一些核心的冲突点，也就是业务的快速变化和探索应对方式的速度之间存在很大的落差，例如在数字化转型方面，就会体现在对数据本身、信息的汇聚对知识的提取和价值的探索的速度上，会显得尤为不足。
然后是过去这一段时间的总结，看看针对数字化转型过程当中所的几种常见的顶层设计思路，进而引出并建立一种兼顾长期发展和短期收益的一种相对折中的方式。虽然现在没有用到中台，但其实讲的内涵和数据中台的建设内涵是比较一致的。
接着我会在第三个章节里面深度地探讨一下这种兼顾的方式下，一些主要的支撑点和特点，阐述如何做快速的数据探索以支撑起业务探索的速度。
最后总结一下我们过去的一些实战经验，衬托出我们的一些理念，也就是建设一个能沉淀客户自身领域知识的分析性的数据探索平台。
业务的变化与探索速度的不足方面 ， 首先来分享一下自己的一些感受，还是那句老话“计划赶不上变化”，大家都知道会发生变化，也希望积极的去面对，但是总是感觉对变化探索应对的速度显得不够。在数字化转型的过程当中，我们会发现很多事情的基本面还是那个样子，可是它的内涵却在改变，而且是快速的改变，甚至由两边引起质量。
首先我们来看数据角度，我们会发现大数据还是那个大数据，大数据的思维特点还是那个特点：容量大、速度快、种类大、价值高。但现在发生的变化是这些之前往往主要出现在互联网企业里面的特点，逐渐以非常快的速度在传统企业里面做渗透甚至更加的凸显。
技术还像以前一样，仍旧是在数据和业务之间的重要的桥梁，但是技术早已经不是以前的那些技术，以人工智能、大数据和云为热点的 ABC 的提法也早已经深入人心。
在业务方面，也许我们各个企业的主营业务并没有发生本质的改变，但业务的协作模式、各种跨界竞争互联网的溢出，现在是层出不穷。
对于企业来讲普遍的是需要继续的去追逐价值，变化是追逐的路径，更加具有多样性，更加具有挑战性，需要我们更加积极地去拥抱变化，需要我们更加积极地去拥抱互联网。
在这样一个变化节奏之下，显然传统的应对方式已经无法满足现在对急剧变化应对的诉求。
就以数据需求来说，我们会发现提需求的人和接需求的人都非常痛苦，上面的领导总是会抱怨要个数要个报表怎么就这么慢这么难，终于好不容易看到数字了，发现不是自己想要的，终于看到自己想要的结果了，又产生了新的想法，这样的过程再来一遍。接需求的人看到的却是另外一番风景，会觉得老板的需求总是琢磨不透，难以意会，产品经理提的需求有一些时候提都提不清楚，还老变。IT 事情又多，人又少，有收益的时候轮不到自己，背锅的时候总是少不了自己，实际的链条会更加的漫长。
从最原始的需求到业务部门的拆解再到建设部门的拆解规划，再到去寻求解决方案、供应商做产品的差异化的分拆，再到最终做个性化的迭代去弥补这样产品的 gap，再一点点的测试内部验收集成上线再做 UAT，再培训使用，最终呈现给提原始需求的人。整个的链条 3 个月、6 个月甚至一年都会有。
这种时候往往人们就会感叹互联网的节奏真的会非常不错，提起互联网的节奏就是快、加班多，但迭代也快。
但是我其实更想说的是——互联网本身它是一个人才密集型的行业，很多速度也是靠人才、能力堆出来的，互联网作为一个真正受数据驱动的行业，强就强在对数据支持的探索速度，牛也是牛在对数据价值兑现的速度。
我们可以简单这样说，应用数据价值的极致，可以认为是一个推荐系统，完全靠机器自动化的端到端来完成物和人之间的匹配，这当然是最优目标。对于传统企业来说，这个毕竟因为各种各样的原因，比如说数据不够充分，业务的复杂性、基础建设的不够牢固，往往很难一步达到最优级别。
我们可以看看次优目标，包括两大类，比如说面向确定性问题的，基于固定的业务数据模型，对于业务数据问题的一个探查。举例里讲像 CDP，还有一类是针对不确定性的数据模型做更加自由灵活的数据洞察，比如说 API 系统。其他的像大数据的工程架构、开发套件、数据治理工具等等这些，都是围绕着挖掘数据的价值来展开的。
于是我们就会发现有大量的围绕数据工作的岗位，在互联网行业里面出现，BP、分析师、数据科学家、数据研发岗等等，甚至在传统企业这些岗位也逐渐开始出现。借此我们可以下一个非常简单的结论：数据知识洞察的速度一定程度上驱动着数字化转型的速度。
如何做好数据的知识洞察？如何做好数据价值的应用？这两年有一个很时髦的词：数据中台。
各种各样的中台都出现了，但是这里我们没有特别写这个词，是因为我们还是比较务实的，追求内涵，去避免因为过多注重时髦的叫法使人失去了对它真正核心内涵东西的关注。特别在经过和大量的传统企业交流之后，互联网企业和传统企业在能力上有很大的不同，在大型互联网企业里面，几十个部门大家开发能力都很强大，会出现很多做重复建设的团队。
传统企业里面，它开发力量往往不会那么充分，更多的是在同一个团队里面因为不同的阶段建设了类似的东西，为了避免重复建设的名头，还要去想各种各样的项目名义去达成建设的意图。所以中台化在互联网企业有一些时候更多体现在只能分工的边界特质，而在非互联网企业里面，核心的是建设思维的变化，需要从以前偏纵向建设的思维转变成纵向结合横向的思维。
一直以来基于业务的需要，我们会建设各种垂类的应用，做了很多烟囱式的建设，在数字化转型的课题之下，我们同时需要的是有横向建设的思维，并不是说我们不要这些垂类的应用了，而是需要在建设的同时甚至之前就要想清楚横向的顶层设计落地时候的横向拉通，面向未来的横向扩展。
毕竟业务系统解决了它特定的业务问题，有它特有的价值，在顶层设计的时候，就应该去想好整体横向拉通的节奏以及未来的扩展，对于数字化建设持续的高效的运行非常有帮助。
当然物极必反，过去两年这个横向拉通也有一些非常极端的例子，就是赶时髦，运动式搞中台，搞数据中台，最后什么也没有搞成，因为没有理清楚内涵的中台建设是极其危险的，投入很大，价值的兑现周期很长，但是有视角才有中台的意义，有被全面使用的潜质才有定制成中台的空间。节奏如果把控不好成绩出不来，会给前台带来额外的很多成本，中间如果又没有产出，如何顶住持续的外部压力都是挑战。
这种情况下，中台在自身企业到底要长成什么样子？还没有想清楚，就冲着大中台的理想理念往里冲，必然是水土不服的，没有什么东西或者说它的理想状况就靠一个概念就能达成的，这也是为什么我们不希望去提很多时髦的提法，更多的是去关注它的内涵的原因。
当有好的方面在出现，是在去年年底和今年年初的时候，感受到有一些企业注意到这一点，思考内涵开始多于追求时髦，也会有专门的部门和领导岗位来负责推动数字化转型的中台建设，这是一个明显的进步，虽然还会提中台这个词，但是同时也体现了一些内涵的东西。这也是横向顶层设计的一种体现。
这个时候我们看到的典型特征就是把中台作为一个业务目标来推动，定义好阶段性的成果以及和业务部门之间相互支撑的关系，这个时候其实考验的是上层的耐心和对成绩的兑现之间的时间差，本质上是上层默许了兑现价值的时间，允诺了成长的空间，至少对于中台化建设增加了几分成功的可能性。
虽然是进步，但其实还是比较有风险的一件事情，如何综合考虑、长期建设与短期收益，我们需要有一些更加务实的操作，以更加明确的建设主题去驱动数字化中台的建设。
什么叫明确的主题呢？举个例子来说，就是要确定一些业务目标或者非常接近业务目标来搞主题建设，比如说做 CDP，CDP 某种意义上里讲可以说是互联网数据中台的缩微版，但是它更加强调了对数据面的应用，以更加简单的方式去完成数据的集成、打通，更多的把用户的精力引导到如何利用数据快速的形成对自己的用户的理解。
数据仓库在这里可以是一个已经存在的东西，也可以是借着 CDP 的建设隐含着一起搭建的东西，而把数据的打通、数据的标记、基于标记的探索作为重点，把对上层应用的支撑作为支点。再比如做更加通用的数据分析平台，实现给业务部门基于最原始的数据做各种灵活的探索分析。
同样地，基于已有的数据仓库可以快速的完成对于大量离线数据在线式的明细级别的分析，把贴近业务同学的数据的感觉给他发挥出来，让他们能够以一种以自服务的形式完成端到端的数据探索，形成整个数字化转型的支点。
这里和之前的思路有一个非常显著的不同点就是视角，更多的是以贴近数据的视角，而不是工具的角度，贴近价值的角度，而不是过程的角度。
我们始终坚持的一个观点就是数据探索的速度支撑起业务探索的速度，没有数据的视角就没有数据的快速应用，对数据的集成对信息的提取，对知识的抽象，对知识的兑现整个链条都是极其重要的，工程、工具都是底层的支撑，目的向来都是以数据角度出发，这才是我们数据驱动的一个真正意义所在。
上面我们介绍完了过去一段时间里面常见的一些建设模式和理念，也介绍了一种以更加主题化的方式去建设，能够兼顾长期的规划和短期的落地价值，并且反复地提到了数据知识的探索速度，支撑起业务的探索速度。
那么，到底又是什么拖慢了我们呢？我们常见的场景是这样的：
技术会说业务总是在变，需求提不清楚，还没有做完项目产品经理又变了想法，业界的技术也总是不停在变，好不容易刚把一个工具用会了，用熟了新的技术又出现了。
对于需求部门来讲结果分析太慢，想法总难兑现，跑数据要求提了很久还是出不来，更加别提那些经常碰到的，不同口径出来的指标总是对不上，要个数都要不清楚，核对要对很久，总体来说数据越来越多，口径越来越乱，不知不觉之间人越来越忙了，事情却越来越慢了。
其实上文介绍的四个核心的因素，如果我们把视角分为工具和数据的视角，把问题分为具体和抽象的问题，我们核心要面对的就是这个四象限的问题。下面两个象限表达的是用工具解决问题，解决具体的问题工具像是大数据套件、大数据开发套件等等。解决抽象的问题是虽然有规矩，但需要管理方面长期投入的，目标偏抽象一些的，比如说数据治理。
上面两个象限表达的是通过探索数据解决问题，包括了对具体的领域知识的探索，对不确定主题数据的探索。对于数据知识洞察的四象限是支撑起数字化转型的底层命题，其实也是构成了我所理解的数据中台的四大核心命题。这四个命题很好地破解和结合，就会形成我们这张图所展示的更加自动化、智能化、场景化的探索闭环。
我们简单理一下，从发起新需求开始，可以从数据治理类的工具里面获取相应的数据描述、数据知识，像从里面拿到一些全局的指标、全局的标签，或者说数据和数据之间的血缘。
从这里开始就可以自动或者半自动的生成数据建模，根据模型来自动生成数据准备任务，把这些数据从原头的地方导入到目标想放的地方，再将这些数据完成一条工作，并导入到 OLAP 引擎，这里我们会用一个能够处理大数据明细级别的完成交互性分析的一个引擎，支撑起上层继续探索分析的场景。
在分析的过程当中，我们既会去使用权威的指标平台，还会反哺生成的新指标回到指标平台当中去，不仅基于数据血缘构建数据模型，还会将生成的指标结果、图表等等这些基于原始的大宽表形成的图表，这种新的上层的血缘数据反哺到血缘系统当中去。
在分析过程当中，我们还能够结合一些 AI 化的手段，比如说去做归因分析，去做预测分析等等，在这里，我们就体现了如何去快速的洞察分析，有几个方面：
第一是建模快。我们充分利用已有的知识去给构建数据模型，并且能够在日常的分析报告中去沉淀新的知识，形成一个应用与知识沉淀相结合的闭环，举个例子来说，假如说我们在指标平台有一个销售量，本来是一个全局统一好的指标，我们在探索过程当中，就可以在新的模型里面直接引用这样一个指标，派成出来新的指标，比如说销售增量，我们发现它能更加的体现业务发展的状况，那么把这个指标和指标平台打通，再反哺到指标平台当中去，这样就使得探索工具和治理工具都互补，互相都具有很强的生命力。同时，平时做好知识沉淀，在用的时候，你的建模也是非常快的，一键就能完成对一些全局指标的应用。
第二是集成快。很多业务分析的场景并不需要人工介入，就可以根据数据建模自动的完全底层的数据建模，这一点对于一些没有开发能力的，没有思考能力的人是非常重要的，如果通过无编码的方式简单的拖拉拽就可以完成对一些重要数据的引入，来做探索分析，那么就逐渐能够走向自服务，让那些运营岗位的同学，不依赖于 IT 的人来完成自己的数据分析。这一点其实对于业务方也好，对于建设方也好，都是非常有利的。
第三是查询快。基于 PB 级的毫秒分析能力，完成大数据明细级别的交互式的分析，这对业务人员无疑是一种无障碍的子服务的体验，这个和分析半天等结果，分析半个小时等结果相比，都是不可同日而语的，简单算，你如果半个小时出一个结果，半天出一个结果，你一天能有多少次分析？更夸张地是说当这个时间很长的情况下很难形成，而当你的查询做到秒级甚至毫秒级的时候，你的想法是能够根据你看到的数据做一个反馈，再进一步的做深入一些的洞察，这些在分析场景里面是非常非常重要的。
第四是分析快。我们除了一些常规的个人的操作，当然如果你自己比较精通，你对业务知识也比较理解，你对工具也比较懂，你自己可能也分析得很好，但往往我们会有大量的人员可能并不是那么高阶，分析起来也比较费劲。这个时候我们把那些更加专业的人，更加专业的分析师他们常规分析的路径沉淀下来，去做一些自动分析的活，去把他们分析的像比如说做归因、做预测这些活给它融入到算法里面去，帮助一些稍微初阶的同学也能够很好的完全做归因的分析、做预测的分析，给他们做一些图表的推荐，让他们也能组合出来高价值的图表，这些都是非常有意义的。
从长期的运行来讲，这里最关键的有一点是四大命题的综合使用，使得这样一个分析平台具备了端到端的能力，具备了一定的治理能力。治理还是指基于分析平台之上的治理，以及不是非常初阶的提法只是说做做数据地图、做做指标平台这么一些简单的事情。
要做到刚才所说的这些，我们先来看一下解决具体问题的大数据工具，看看工具层面上如何快速的支撑起数据开发。
当然我们希望能帮助所有的人去做数据开发，而不仅仅是说提到开发只是一个研发人员的事情。我们从底层到上层可以归纳为四个层次，首先是研发同学可以介入的编程形式的数据开发，他们处理了最难最个性化的那一部分，需要去写代码来完成。像我们内部也有像数据开发套件这种重器物去辅助同学们做开发的事情。其次再往上对应那些具备 SQH 技能的角色来说，比如说分析师，我们可以有联邦查询的能力，往往是他们的最爱，能够通过统一的 SQL 语句，完成不同来源的异构数据的联邦分析。
再往上对于偏业务类的岗位来说，最好是能通过自主服务的方式，不用写代码，不用写 SQL，通过拖拉拽的方式完成对数据模型的构建，对数据知识的探索，那效率绝对是非常高的，可以使他们专注于数据本身，而不被工具类限制所打断。同时也减少他们对于开发人员的一个依赖。
再往上对于一些移动端的人员，对于一些领导层面上，我们结合一些文本类的问答系统，能够更加有效的让他们获取到所需要的更加全局的均匀情况。这些综合的都成为了能够支撑像我们智能数据洞察这种产品快速探索数据的基础，一个工程基础，一个数据链路上面的基础。
我们再来看治理工具如何和数据洞察相结合。数据治理其实是一个比较难的课题，它难并不是在于工具有多复杂，工具还是比较简单的，难就难在长期性，不是一朝一夕就能完成的，正是因为它工具比较简单，工具功能非常有限，有一些时候如果说各个系统之间没有很好的打通，也就意味着可能会产生大量人力的工作去维护你的数据血缘，去维护你的数据指标。
把东西沉淀下去，有时候是一件比较痛苦，也比较难的一件事情。从整体建设角度上来讲，我们一般建议是说在早期你做数仓的时候，可以有一个数仓的视角去重点做一下梳理，把公司核心的主题域收拢起来，把它从 DWD 或者更上一层都规整好，那么在业务视角上我们可以按需构建，有什么样的需求，有什么样的主题，我们根据这个需求牵引，再建设其他的部分。
在建设过程当中，因为横向拉通非常重要，在建设过程当中我们希望能够自动化的把建设过程当中形成的数据之间的依赖，能够以血缘的方式沉淀到数据血缘里面去。再进一步的比如说我们开发过程当中形成了一些指标，能够沉淀到指标平台里面。当然首先我们得有这样一些工具，其次我们管理上必须是要跟上的。
那么，这些基础工作做了之后，其实整个事情顺了之后，用起来还是很方便的，至少当你数据治理类的东西和数据探索类的工具模型打通，平时也积累好了之后，我们就可以基于模型驱动去做一些探索分析，同时我们在构成过程当中也可以把整个过程当中形成数据治理类的一些知识沉淀下来，相互成就相互成长，而且相互使得对方更加有生命力。当我们的探索类平台上面的数据越来越有公信力、有权威性的时候，那么使用的人也会越来越多。当我们的指标平台，当我们的数据血缘能够跟分析系统打通的，它的一个生命力也会更加的顽强。
接下来介绍完工具侧两个维度的事情之后，我们再来聊聊 CDP。和刚才提到的 ABI 探索一样，也是从便捷的数据开发开始，完成集成接入，通过 ABI 的手段我们完成了数据的融合，在平台上构建一些标签体系，除了自身具备的洞察能力之外，还能够和 ABI 的系统相融合，标签作为一种知识输入给 ABI 做探索分析。其次 CDP 确实是一个互联网数据应用的缩影，它底层会有各种数据接入的活，会有数据打通的活，中间会有类似于像画像一样的东西，包括对上也会对业务方做各种支撑，同时也会和分析系统打平，做各种更加灵活的分析，本质上就是一个小型的互联网的数据应用的中台。
这里我们在知识落地的时候，也举一个更加聚焦的例子来讲，是叫 CDP，名字来由还是关注于用户自己的客户，我们常见的用户一般确实会有两个核心维度，一个是人的维度，一个是物的维度。
从人的维度上来讲，我们有三个阶段的事情是要做的，一个是识别，一个是刻画，一个是预测，为什么会有识别这样的问题呢？主要是说我们现在传统企业触达用户的手段越来越多了，有一些是已经注册的登陆用户，有一些是没有登陆的匿名用户，如何他他们做打通变成一个自然人，就需要有识别过程，比如说做 ID-Mapping，把那个登陆用户和匿名用户都关联起来，同时在有一些场景里面，我们关注的点可能不仅仅是个体，而是群体，像一个家庭，或者说临时性的动态关系的。这个时候我们可以做一些社交关系的挖掘，去把一些团体的活动给它挖掘出来，这是识别这一步骤。
接下来说刻画，我们也可以简单说做三个方面的阐述，第一个是基于事实的刻画，比如说一人一档，我们把他的行为细则都给他归纳起来，形成一个事实性的档案。特别在我们做上层应用的时候，当你追求一些解释性的时候，这些事实性的档案还是非常有帮助的。包括支持上层 CDP 去构建标签，这也是一个事实基础。
第二块是定型的刻画，一般标签的提取去做用户画像。第三大块是分析的刻画，常规我们会做一些意图的识别，包括意图的标签，最终会和人和物之间形成相应的匹配，包括你的行为喜好、职业，以及可能我们如果是销售类的行业，还会有自己的 SKU，有你要售卖的东西、人和物之间怎么去做匹配，怎么做预测，这个可能在不同场景里面有不同的体现。但是对人的刻画确实大体可以分成这三个步骤识别、刻画、预测，来最终完成我们想完成的业务目标。
在刚才的章节我们介绍了整体数据洞察四象限的命题，且呈现了如何通过这些组合共同去完成自动化、智能化、场景化的数据洞察。做这些的目的其实都是为了最后能够帮助用户快速的洞察自己的数据，系统上线开始就可以快速的获得结果。最后这一章节介绍我们通过实战沉淀下来的几条新的体会和经验，总体目标都是为了达成建设知识沉淀型的分析平台。
第一、数据的极速反馈。我们在任何一家客户去落地，包括我们内部，都希望从部署实施完成的那一刻开始，我们的用户就能够跟数据以及更细节的数据保持零距离，想看的时候随时都能看到，想查的时候随时都能查到，而且这一切都是秒级甚至毫秒级的交互时间。这里最重要的理念就是需要这种非常强的数据反馈，用上了就能立刻得到数据，而不用等待别人帮你去建设，不用等待数据准备的时间。
刚才反复的提到这些特性，需要的是无代码建模且自动生成集成任务，使得用户非常低的门槛就可以自服务的形式完成操作，在最后的环节可以基于最明细的数据做继续查询继续分析，更加进一步的缩短了探查数据的周期。整个平台屏蔽到了底层数据集成的复杂性，使用户能够聚焦于关注数据本身，也不用特别去等 IT 的排期，自己就可以完成，想到便能得到，得到便能看到。用户不仅能和明细数据保持零距离的接触，和业务支持同样如此，多样的标签生成能力，对知识的沉淀的能力，跨源的融合能力，都使得用户能够快速的生成基于不同群体的洞察。其实说到反馈和自服务也是息息相关的，其实完成这一些之后让我们客户自助的可以完成对数据的使用，也可以使得 IT 人员脱离无尽的数据开发需求。
第二大点是全面使用，全简化门槛全覆盖，促进全面使用。有被全面使用的潜质才具有中台化的空间，简化产品使用的门槛，使得全员可以使用分析平台，是非常非常重要的一件事情。无论是在数据集成阶段，使得集成过程透明化，还是使得知识融合，沉淀知识方面整个非研发团队都能够兴趣比较高一点，各种角色都能够按照自身的需求，自在的去探索数据。比如说开发人员可以通过 notebook 做分析后的二次开发，分析师也可以通过 SQL 查询生成可视化，PM 通过拖拉拽的方式完成自服务，甚至连领导层都可以通过有自己专属的移动驾驶舱、大屏之类的组件，这样几乎所有的全员角色都能够把分析平台用起来，把它用好。
最后是我们的分析平台，通过实践走出来的不一样的特点，也是形成了知识沉淀型的带有治理能力的分析平台。知识沉淀型分为几个层次：一个是基于使用热度的比较权威的报表，正因为被全面使用了，也就意味着有足够多的用户基础，充分代表了使用的情况，对于使用频度高的内容赋予它更加特定的知识语义；还有一些像指标知识的沉淀，我们定义了维度和指标的组合关系，把它们定义成标签，维度作用在人的 ID 上面就变成了人的标签，或者说全局指标。还可以把经过反复确认的指标定义为认证指标，经过认证的全局的指标往往能节省很多的交流成本，也能减少后续再进一步反复核实这种成本；第三个就是标签知识的沉淀，可以定义基本标签，也可以定义标签和标签之间的组合标签。
治理型指的是核心用户可以通过平台完成自身的报表知识的治理，能够和治理工具相互打通，首先是形成全面的血缘关系，一般的血缘工具可能只做到了从源头数据到数据仓库，最多再来一个 OLAP 引擎。我们真正意义的是做到了端到端的血缘，从源头去定义，源头定义到数据仓库，再到 OLAP 引擎再到报表，到具体的指标项，端到端的血缘其实是有很多好处的，能够通过血缘关系去对比指标的差异，有助于形成全局的指标，这个和知识沉淀其实是有交叉，有相互的关系的，进一步的去消除一些不合理的指标，能够快速地去引用关联实体的指标维度，生成字段级别的热度，计算出来得出真正意义上重要性最大的一些字段；另外，我们也可以通过血缘看到字段级别的使用情况，针对使用不频繁的进行清理。这些对于企业成本来讲还是非常重要的。
二是生成访问热度，包括字段级别的、报表级别的、看板级别的、数据集级别的热度，在数据治理方面，有一个非常重要但却是容易忽略的点，就是资源清理，各个层次都存在，访问热度有助于帮助管理同学去完成无用资源的收集和清理，也有助于定位高价值的资源，上面也提到了字段级别的热度。三是和数据探查相结合，形成对数据的描述，辅助在数据分析的时候给出相应的建议，避免对低价值数据做无用的计算。
以上这些就帮助我们构建出了知识沉淀型的、治理型的分析平台，这也是当前我们对自己的产品、自己的解决方案一个差异化的点，也希望能帮助我们未来可能的合作伙伴，去把自己的分析平台做好，很好地完成数字化的转型。