随着高校各项管理活动、服务事项的规范化、高效化，跨部门工作流程普遍增多，用户对工作流程的连贯性、时效性要求也越来越高，这就涉及到多个管理系统之间的业务交互问题。例如，我们在与高校客户交流中常被问道：教务和学工、教务和财务的数据如何交换、如何实时共享。
由于高校信息化发展的历程特点，难以采用其他行业广泛使用的应用集成、业务集成等架构，而是更多的使用数据集成方式实现业务交互。例如，通过周期性ETL接口推送数据到中间表的方式，就是高校信息化环境中最常见的数据集成方法。但是，这种方法在一些对实时性要求非常高的场合会面临一些技术困难。
在3月12日一期的线上技术沙龙中，我们曾为大家介绍了一些高校常见的实时数据交换场景及解决方案，引起不少技术老师的共鸣。应老师们的热情邀约，我们特将报告内容做了文字整理，下面就从几个案例入手，看看解决高校数据实时问题应该从哪些方面考虑，采用什么样的解决方案，以及方案的技术实现原理如何。
高校常见数据交换方案及特点
在谈实时场景之前，我们先来看一下目前高校常见的数据交换方案都有哪些。首先是线下电子文档。在相当长的一段历史时间里，它都占据举足轻重的地位，即便是现在，每个学校也都肯定存在这样的数据交换方式。高等教育质量监测国家数据平台，就是一个典型的例子。后来，随着信息化的发展，线上数据交换开始出现，基于应用间程序接口的交换，数据库远程访问和利用ETL工具进行数据交换等方式开始进入高校。再后来，随着三大平台之一的数据交换平台建设，数据共享库建设，数据交换由原先点对点无法管理的方式向集中式可管理的方式转变，最终形成了目前高校数据交换方式百花齐放的现状。
这些数据交换方式的实时性怎么样呢？我们大致做了一些疏理。
综上我们可以认为，使用ETL工具或者集中式数据接口这两种方式，在能够保证实时性的前提下，可以满足高校保障数据安全、管理数据、对外提供数据服务的需求。其中，使用ETL工具的实时性是不确定的，具体与所使用的交换方案有关。那么，都有哪些ETL工具或集中式数据接口的交换方案呢？在需要达成保障数据安全管理和对外提供服务的前提下，我们如何使用ETL工具，或者数据接口的方案，满足高校例如新生报道、学生离校、新教工入职、一卡通充值消费记录实时查询等场景。下面我们将从三个案例入手，看看能否从案例中找到问题的答案。
案例1 高校常见数据交换方案及特点
高校A已建设统一数据开放平台（希嘉数据交换平台产品，可以基于源库封装数据接口供数据使用方调用，以下简称“开放平台”），共享库使用数据库的只读账号，通过ETL任务从一卡通前置库每日定时采集数据，并且在开放平台上根据共享库发布了数据接口，移动校园通过封装的数据接口获取数据。移动校园中的一卡通消费流水查询功能上线后，学生普遍反馈：为什么一卡通终端上可以查询到实时的消费流水，但手机端却只能查询到一天前的消费流水，该问题被校领导得知，要求信息部门解决该问题。
步骤一
直接通过开放平台将一卡通流水表封装成API，让移动校园调用开放平台的API接口进行数据的实时查询。该方案的本质是由数据交换变成了数据转发，从而由原来的需要时间变为不需要时间，转发与交换的差异点见下图。
陷阱规避
选对表。实际在一卡通数据库里面存在有两张记录流水信息的表，一张表记录当天实时的记录，叫做未结账流水表，另一张表记录除过今天的所有历史记录，叫做已结账流水表。所有当天的流水记录每天需要经过财务入账才能进进入一结账流水表，如果只将历史表封装成数据接口供移动校园调用，则无法解决消费流水实时查询问题。
步骤二
将未结账流水表封直接装成数据接口，供移动校园查询当天的流水记录，已结账的流水表每日定时ETL进入数据仓库后封装成数据接口，供移动校园查询历史的流水记录。至于为什么选择已结账流水表进入数仓，是因为已结账流水表是经过财务确认过的数据，既然不需要高实时，自然需要尽可能保证数据的准确。
同时，针对已结账的流水表，我们需要采用增量同步方式。下面我们具体看一下时间和增量的具体实现的过程。这里有两张表，源表跟目标表，它们都会有刷卡时间的字段，目标表是有3月1日、2日、3日的三条数据，源表有四条数据。第一步我们会在目标表中取刷卡时间的最大值，得到的是3月3日的时间，接下来对源表数据进行过滤，筛选出大于目标表刷卡时间最大的3月3日的时间，得到了3月4日这一条记录。最后就是对差异的数据进行同步，找到3月4日的数据，把他抽取到目标表中。
这是在一卡通场景当中具体的实现，如果不是基于特定的场景，这种增量的交换方式有一定的条件限制。能够实现这种方式，首先因为一卡通流水表只会对数据做插入的操作，不会对历史的数据做修改。还有刷卡的时间能够真实反映数据插入的时间。除了同步插入的操作以外，时间戳的增量的方式没有办法同步对数据的删除操作，如果这条记录被删除了，通过取最大值去过滤的方式没有办法找到这条数据，所以删除操作是没有办法进行同步的。
此处我们再延伸介绍一下，除了一卡通基于刷卡时间的方式之外，如果在源表中，时间戳的字段除了反映数据的插入时间，还能反应数据的更新时间，那么数据的更新操作也可以被增量同步，这完全取决于你的时间戳所能够代表的插入或更新的时间。下面我们看一下能够实现插入更新的情况是怎么实现的。
首先还是要取到时间戳目标表的最大值，对源表做过滤操作，找到变化的数据。因为时间戳无论做插入操作还是做更新的操作，都会进行变化。所以找到差异的数据，然后跟目标表对应的数据进行对比。这里面变化的数据从过滤条件大于3月3日，3月4日的数据就有两条，目标表中需要对比的是先找主键为3的记录，发现它原来的值是赵六，这个数据肯定是发生了变化。再有主键为4的记录我在目标表中并没有找到，我可以认为它是一条新增的记录。完成对比之后针对于刚才识别出来的差异情况做一个同步操作，将主键为3的数据进行更新将它替换成现有的状态，对主键为4的新增记录进行插入的操作，这就是基于时间戳增量交换实现插入和更新的基本原理。
陷阱规避
注意使用基于时间戳的增量交换方案，避免选择全表对比方式。由于已结账流水表存放的数据量很大，在一天的周期中无法完成数据的对比，将导致数据同步任务不能完成，无法查询前一天的结账数据。此处通过一张图片简单了解一下全量与增量的差异。
案例2 教工数据的实时同步
高校B在疫情期间，建设线上教职工每日健康信息上报的应用，要求应用建设方从开放平台中获取人员相关数据，但由于业务部门对人员状态、手机号等维护的不准确，导致很多教职工反馈自己无法填报或手机号码错误，信息部门也想借此机会提高数据质量，但是疲于跟业务部门沟通、跟反馈问题的教职工沟通，无法抽身专注于数据问题本身，导致忙中出乱，连本职的同步数据的工作也出现问题，进而扩大矛盾，造成业务部门和教职工用户两边都不讨好的局面。
针对于这个场景，我们发现主要矛盾集中在上图中左边的部分，数据交换采取了全表对比的方式。那么，我们可以通过转发代替交换解决问题吗？还是通过全量和增量的转换？
案例2与案例1的最大差异在于，所要共享的数据既非单一来自于人事系统，也非单一来自于教务系统，而是对两个数据库的多张表进行了转换，最终形成了需要共享的教职工基本信息数据。然而，转换的方案是无法解决跨库、异构场景问题的，所以我们无法使用转换的方案解决案例2的问题。
那么基于时间戳的增量解决方案可行吗？也不行，原因是人事、教务系统关于人员的数据表没有时间戳字段。那还有其他的增量数据同步的方案么？
结合学校使用ODI作为ETL工具的实际情况，我们可以直接利用ODI中的同步CDC方式，利用触发器的原理来识别变化数据，减少数据交换量，做到数据的高实时同步。我们来看一下ODI同步CDC的实现原理及步骤。
除了同步CDC方式，ODI中还提供了一种异步CDC模式，是一种基于日志识别变化数据的增量交换模式。但只有ODI企业版中才有，需单独购买。基于日志的CDC需要的权限较高，甚至要求源库开启最小补全日志、归档日志及强制归档模式，增加了源业务库的存储及维护压力，但对源系统的性能影响几乎没有。
案例3 减轻源库压力的据实时同步
高校C随着信息化建设程度的日益深入，各式各样的分析型应用、微应用、微服务的建设，对人员数据的实时性要求越来越高，但采用传统的高实时方案对源库的性能已造成较大影响，影响了实际业务的正常运行。
要解决性能影响的问题，首先要减少对源业务库直接的访问。我们去掉从数据交换平台到源库的访问，所有的交换平台的访问都基于数据中心的数据仓库。第二步减少触发操作对于源库的性能影响。之前采用ODI的CDC方式，这种方式如果说业务数据的变化情况比较频繁，对源库的性能影响是比较高的。第三步是既然没有用触发的方式实现数据增长交换，这个空缺由谁进行补充呢？我们采用的方案是使用基于日志的存量交换方式就是OGG
OGG是一种基于日志进行结构化数据和备份的软件，通过解析数据库的在线日志或者归档日志获得数据的增量变化，再将这些变化应用到目标数据库，从而实现源数据库与目标数据库的同步。具体实现过程及优劣势见下图。
OGG与传统的ETL方式，数据转换的差异。OGG方式是基于配置文件，传统ETL是通过SQL语句。OGG配置较繁琐，且对于复杂映射及转换，甚至需要通过配合触发器实现。
回顾
实际上数据的实时性并不是越高越好，实时性越高势必会造成对源系统入侵性的增加，或者是对源库运维压力的加大，再有可能是对源库的性能造成一定影响。所以我们在选择使用数据交换的时候，应该在最大限度满足业务场景要求的前提下，综合考虑数据的体量，变化频率，基础环境、成本等因素，给出具体适用于特定场景的解决方案，最终能解决实际问题的方案都是好方案，不必一味追求高实时性。
实现数据实时交换的解决方案和具体的方法