我们将每期线上沙龙中，老师们关注的问题做了摘录，供大家交流探讨。本期是关于2020年4月16日“数据治理管理‘工具篇’——希嘉数据纠错填报系统（一表通）”一期的精彩问答回顾。

01 自动修改业务系统数据库中的数据，需要业务系统做二次开发吗，还是要给数据库权限就可以了？

不需要业务系统去做二次开发，只需提供待修改数据库中对应表的写入权限即可。

02 像高基表类统计性质的表，是否可以通过一表通来解决？

我们可以对高基表数据进行采集，但是暂时没有对采集的数据进行统计分析的功能。一表通核心是采集数据，填报本身不具备统计分析功能。

03 反写业务系统、业务系统的回滚是怎么做的？回滚的话，有可能会造成业务系统表格逻辑上的错误，这个是怎么规避的？如果数据是一对多的形式，能自动写入数据库吗？

反写业务系统前会做数据备份，反写数据是针对具体信息找到具体数值，回滚是针对修改的具体某一个数值进行回滚。反写数据和回滚数据有一定的风险，我们会在安全策略上做一些调整，比如说数据的备份等。直接修改数据只是提供的修改方式之一，根据大部分用户需求，业务系统数据还是由业务部门维护。所以我们产品支持推送消息给业务部门，由业务部门去修改数据。

修改数据，会在技术层面设置一个逻辑主键，辅助判断能不能改和改动之后数值正确性，需要根据具体场景去分析。

目前不支持一对多的形式，因为会有风险，暂时只支持基于某个数据库发布的表单修改该库数据。

04 数据修改后是保存在数据平台的数仓里，还是在业务系统的数据库中？会不会存在数据不一致的情况？如果存在数据不一致的情况，如何解决？

数据修改后是保存在数据平台的数仓里，还是在业务系统的数据库中，取决于表单的数据来源，基于某个数据库发布的表单去修改该库数据。

可能会出现数据不一致的情况。当表单是基于数仓发布，修改后数据回写到数仓中，而原始业务系统没有修改，数据会在下个任务执行之后，把业务系统中的错误数据同步到数仓中替换修改后的数据。

解决的思路有两种，第一种，有数据治理工程，知道权威的数据来源，基于业务系统去发布表单；另外一种，基于数仓发布的表单，当用户提出修改申请，同步申请给业务部门，业务部门负责人在业务系统中把数据做同步修改，就可以解决这个问题。

05 会议中提到，某校数据中心和数据开放平台是希嘉建设的，数据纠错和填报平台由其他厂商提供，中间使用过程衔接不好，原因是不是主要因数据交互的实时性问题？这是不是说希嘉的数据开放平台和第三方系统对接有问题？反过来说，如果数据开放平台是其他厂商的，对接希嘉的数据纠错和填报系统，是否有弊端，是否可行？

首先，衔接不好的原因在于业务和数据的断层，并不是实时性的问题。数据断层包含两种情况，第一种是业务系统厂商由于没有做数据治理，因此在发布表单时不了解数据的权威来源，该用户数据治理工程是由希嘉完成的，因此用户将希嘉的数据治理成果推送到中间表再由厂商调用。第二种是做业务的厂商并不擅长数据开放，而用户采数据的目的核心是为了支撑应用，用户将厂商采集的数据通过希嘉的开放平台开放给其他厂商使用。以上两个场景都是因为数据脱节导致的，并不是数据交互实时性存在问题。

其次，希嘉的纠错填报和第三方系统之间对接不存在弊端。在我们的产品体系设计上，兼顾自身数据产品融合的同时，也考虑到用户没有采购希嘉的数据产品或数据服务，因此产品中有强大的配置功能用以对表单的细节进行配置，相较于我们直接调用自身的数据治理成果，用时可能会稍长一些，但是并不会出现不能兼容或不能独立部署的情况。

06 填报的过程中数据纠错、补全是一个很方便完善的途径，但是这个功能横向涉及到很多部门，很多数据源的操作权限，纵向涉及到某一个部门某一个数据源的多级审批权限，纠错功能现在是否能很好的实现？

我们产品已经实现纠错的功能。我们提供横向和纵向的审批，通过内置的流程引擎完成横向的审批，通过产品权限体系完成纵向审批。

07 产品界面如何和领导驾驶舱结合？

领导驾驶舱是一个应用，我们产品不仅可以和领导驾驶舱结合，也可以和任何应用结合。设计表单后会生成分享的链接，链接可以嵌入到任何的应用中。应用中添加一个入口，比如按钮，按钮绑定链接，点击按钮之后就可以去表单中纠错或者填报了。

08 看到产品支持移动端的审批，移动端的填报是不是支持？

我们产品目前只做了移动端审批，移动端的填报也已经进入规划阶段。移动端既要保证填报的准确性和便捷性，更重要的是符合移动端操作习惯。