我们将每期线上沙龙中,老师们关注的问题做了摘录,供大家交流探讨。本期是关于2020年4月16日“数据治理管理‘工具篇’——希嘉数据纠错填报系统(一表通)”一期的精彩问答回顾。
01 自动修改业务系统数据库中的数据,需要业务系统做二次开发吗,还是要给数据库权限就可以了?
不需要业务系统去做二次开发,只需提供待修改数据库中对应表的写入权限即可。
02 像高基表类统计性质的表,是否可以通过一表通来解决?
我们可以对高基表数据进行采集,但是暂时没有对采集的数据进行统计分析的功能。一表通核心是采集数据,填报本身不具备统计分析功能。
03 反写业务系统、业务系统的回滚是怎么做的?回滚的话,有可能会造成业务系统表格逻辑上的错误,这个是怎么规避的?如果数据是一对多的形式,能自动写入数据库吗?
反写业务系统前会做数据备份,反写数据是针对具体信息找到具体数值,回滚是针对修改的具体某一个数值进行回滚。反写数据和回滚数据有一定的风险,我们会在安全策略上做一些调整,比如说数据的备份等。直接修改数据只是提供的修改方式之一,根据大部分用户需求,业务系统数据还是由业务部门维护。所以我们产品支持推送消息给业务部门,由业务部门去修改数据。
修改数据,会在技术层面设置一个逻辑主键,辅助判断能不能改和改动之后数值正确性,需要根据具体场景去分析。
目前不支持一对多的形式,因为会有风险,暂时只支持基于某个数据库发布的表单修改该库数据。
04 数据修改后是保存在数据平台的数仓里,还是在业务系统的数据库中?会不会存在数据不一致的情况?如果存在数据不一致的情况,如何解决?
数据修改后是保存在数据平台的数仓里,还是在业务系统的数据库中,取决于表单的数据来源,基于某个数据库发布的表单去修改该库数据。
可能会出现数据不一致的情况。当表单是基于数仓发布,修改后数据回写到数仓中,而原始业务系统没有修改,数据会在下个任务执行之后,把业务系统中的错误数据同步到数仓中替换修改后的数据。
解决的思路有两种,第一种,有数据治理工程,知道权威的数据来源,基于业务系统去发布表单;另外一种,基于数仓发布的表单,当用户提出修改申请,同步申请给业务部门,业务部门负责人在业务系统中把数据做同步修改,就可以解决这个问题。
05 会议中提到,某校数据中心和数据开放平台是希嘉建设的,数据纠错和填报平台由其他厂商提供,中间使用过程衔接不好,原因是不是主要因数据交互的实时性问题?这是不是说希嘉的数据开放平台和第三方系统对接有问题?反过来说,如果数据开放平台是其他厂商的,对接希嘉的数据纠错和填报系统,是否有弊端,是否可行?
首先,衔接不好的原因在于业务和数据的断层,并不是实时性的问题。数据断层包含两种情况,第一种是业务系统厂商由于没有做数据治理,因此在发布表单时不了解数据的权威来源,该用户数据治理工程是由希嘉完成的,因此用户将希嘉的数据治理成果推送到中间表再由厂商调用。第二种是做业务的厂商并不擅长数据开放,而用户采数据的目的核心是为了支撑应用,用户将厂商采集的数据通过希嘉的开放平台开放给其他厂商使用。以上两个场景都是因为数据脱节导致的,并不是数据交互实时性存在问题。
其次,希嘉的纠错填报和第三方系统之间对接不存在弊端。在我们的产品体系设计上,兼顾自身数据产品融合的同时,也考虑到用户没有采购希嘉的数据产品或数据服务,因此产品中有强大的配置功能用以对表单的细节进行配置,相较于我们直接调用自身的数据治理成果,用时可能会稍长一些,但是并不会出现不能兼容或不能独立部署的情况。
06 填报的过程中数据纠错、补全是一个很方便完善的途径,但是这个功能横向涉及到很多部门,很多数据源的操作权限,纵向涉及到某一个部门某一个数据源的多级审批权限,纠错功能现在是否能很好的实现?
我们产品已经实现纠错的功能。我们提供横向和纵向的审批,通过内置的流程引擎完成横向的审批,通过产品权限体系完成纵向审批。
07 产品界面如何和领导驾驶舱结合?
领导驾驶舱是一个应用,我们产品不仅可以和领导驾驶舱结合,也可以和任何应用结合。设计表单后会生成分享的链接,链接可以嵌入到任何的应用中。应用中添加一个入口,比如按钮,按钮绑定链接,点击按钮之后就可以去表单中纠错或者填报了。
08 看到产品支持移动端的审批,移动端的填报是不是支持?
我们产品目前只做了移动端审批,移动端的填报也已经进入规划阶段。移动端既要保证填报的准确性和便捷性,更重要的是符合移动端操作习惯。