希嘉线上技术沙龙已经举办了多期，在主题报告之外，我们每期也会在线解答老师们关注的数据治理相关问题。现将2020年4月2日“高校数据治理项目中对传统共享库的改造实践”一期的精彩问答记录如下，供大家交流。

问 题 一

我们现在讲的是共享库的改造，学校之前还没有建数据平台，目前建设上有没有什么合理的建议呢？

1)   首先，数据平台可以单独立项建设，而且是可以先于信息系统建设的；

2)   其次，数据平台先于大量MIS系统上线应该说治理阻力更小，对数据管理、质量提升反而是好事；

3)   对于之前没有数据平台的学校，建议采用标准先行、统一要求建设、逐步接入管理、优化迭代的步骤进行；

4)   标准先行，即在大量MIS系统未建设时，通过已有部分MIS系统或线下数据的整理，结合学校业务开展特点，先行建设数据标准，定义校级平台所需元数据标准、代码表标准和编码标准，后期MIS建设中统一使用该套标准；

5)   统一要求建设，即对信息化建设过程中的各环节提出具体要求。如项目立项阶段规定数据所有权属学校，建设过程中需对数据质量进行验证，涉及校级代码和编码的必须使用校级平台统一数据，建设完成后必须提供数据库管理员账号、数据字段、配合学校进行数据接入等；

6)   逐步接入管理，即根据MIS系统建设进度，建设一个接入一个，并在数据平台上对该批数据权责、数据质量检测规则、数据交换关系等进行管理配置，将数据一批一批的逐步完善和管理起来；

7)   优化迭代，即随着MIS数据接入越来越多，首先通过管理行为，发现质量问题溯源修正，逐步提升数据质量。其次通过数据样本的增加，修正之前因MIS系统少数标准考虑不周的情况。再次，通过长时间的治理行为，积累管理流程和经验，从管理方法上优化；

总体来说，没有MIS系统或建设较少的情况，从信息化建设初期即进行相应规范，先行建设数据平台，反而数据治理面临的配合困难和管理阻力更小，可以实现后发先至、弯道超车的效果。

问 题 二

信息化处为了增加对数据库的管控能力，全校就一套数据库，这种方案可行吗？

高校教师是否需要对不同的数据库有比较深入的了解？

这套模式（你们碰到）使用的高校多吗？

API开放平台使用是不是很方便，可以快速从数据库构建API接口？

就数据共享方式而言，过去数据表的共享效率相对较高，API方式则更安全，但在共享数据量较多的情况下效率较低，如何解决？

1） 当前高校普遍面临数据安全、数据分散、数据运维的困难，业务系统建设时是分散的，而且更加偏重软件功能的实现而忽略了备份、安全方面的问题。因此，在当前数据安全、数据利用更加频繁的时代，使用“数据一个库”的方式更加便于统一管理和运维，但相应带来了集中的风险。如一个数据库的操作不规范引起宕机，可能影响其他系统数据库的运行。所以推荐的方式是：信息中心建立统一的数据中心平台，也可以是虚拟化，提供不同种类、版本的数据库服务器资源，由信息中心统一分配数据库资源并承担数据库运维工作（分配、优化、备份、巡检），业务系统厂商只对自己的数据库有DDL和DML权限，而无管理员权限。这样整体数据库环境在信息中心的统一管理之下，数据的协调不存在问题，业务系统互相之间独立互不影响。所以我们推荐的方式是：“数据一个库”，但不是一个物理库，而是一个大的数据中心，信息中心整体分配、运维，厂商各自使用自己的数据库。

2） 这种情况对于高校老师的数据库运维能力确实要求较高，需要熟悉不同数据库的部署、运维操作、架构等。不过，通过数据库整体运维，数据收集、厂商协调的瓶颈将不复存在。整体运维的技术门槛，参考金融、证券行业，可以委托专业的数据库运维厂商以年度为服务周期，定期、定次对数据中心全部数据库进行备份检查、巡检、调优、配合迁移等。无论是投入精力还是协调数据所需的接口费用，整体运维服务外包的投入要低得多。

3） 目前还比较少，因为高校信息化建设是分阶段、分厂商独立建设的，当时也没有现在数据时代对数据资源这么重视，主要还是分散建设的，没有项目驱动也不可能有大规模的迁移动作。但这是一个趋势，也是一种好的管理方式，可以朝着这个方向努力。

4） 数据开放平台操作较之ESB这类重型的业务总线相对简单得多，数据API封装流程10分钟可以学会，基于软件的操作一个接口2分钟就可以完成。

5） 数据API的使用也是需要分场景的。在高校传统的数据共享场景，使用数据API在绝大部分场景是没有问题的，因为共享的数据体量不大，即使是厂商提出要求要大批量数据，也是可以通过业务优化，如：增加筛选条件、优化业务需求逻辑，来减少共享的数据体量。对于必要的大批量数据供给场景，可以在平台中通过开放数据库链接让其自助获取，因为数据库底层为ADG方案，其获取的是备库数据，不可修改，解决大批量数据的共享问题，同时保障数据安全，实现可管理的目标。

问 题 三

我们经常听说主数据平台和大数据平台，希嘉数据产品体系来讲，是一套东西，还是分开不同的？

1)   这两个词汇是在不同分类下的概念术语。主数据是根据数据分类，将数据分为业务数据、主数据、元数据这些，而主数据专指在不同业务系统之间均需用到的这一部分数据，如单位表、人员表、客户表、产品表这些。而大数据平台则是指有基于传统关系型数据仓库概念，结合近些年来Hadoop生态，进化出的一类可以完成不同类型、体量的数据存储、交换、批量/实时性计算的一套综合平台；

2)   主数据平台侧重于主数据在组织内部的统一和交换，而大数据平台则侧重于大规模批量计算分析、算法挖掘、实时流数据供给等；

3)   在高校行业，希嘉提供的是一套基于关系型数据库与Hadoop平台混合物理实现的大数据平台，主数据是其中的一部分。除了主数据，这一套大数据平台还有全量集成的业务系统其他业务数据，以及校内大体量的认证、防火墙、网络等日志数据，还有基于治理过程中产生的数据全责、数据结构、映射关系、质量问题等业务或技术元数据；

4)   所以，大数据平台包含主数据，主数据是大数据平台的组成部分。

问 题 四

治理总是阶段性的，治理完成之后怎么能维持战果？

1)   阶段性的数据治理项目完成后，需要从两个方面维持战果：一方面是数据管理技术体系的持续使用和维护，一方面是管理体系的形成和执行；

2)   数据管理技术体系使用和维护，依赖于校方老师掌握并基于数据管理相关软件工具，持续的使用其进行数据的集成、开发和管理工作，重要性为30%。希嘉的数据中台产品定位是高教行业数据治理产品，希望交付给客户能够自主使用和管理数据的工具和能力。因此，产品在设计之初就考虑使用门槛的问题。如希嘉统一数据集成管道均基于可视化界面进行接口配置，少了重型ETL工具的概念层、模型层，所见即所得，省去理解操作困难。希嘉统一数据开放平台产品发布API，根据产品文档基于软件界面2分钟即可配置一个数据API，供数据使用者申请调用；

3)   管理体系的形成和执行，则需要在治理过程中总结数据治理的主要困难，对这些困难制定校级的管理制度、流程和技术规范，这样在下阶段的治理工作中就有法可依、有章可循，我们称之为数据治理的长效机制，重要性为70%。例如，当前治理的主要困难是数据收不上来、质量问题很大，针对该情况，需要结合当期治理工具体系、流程，在制度层面进行规范：数据属于学校，业务系统厂商需无条件开放数据库账号，并对数据权属进行明确定义。数据质量问题经治理过程中发现，那么相应的要有数据质量问题反馈、修正、重新接入等标准工作流程定义。

问 题 五

ODI是指Oracle的ODI还是希嘉自己的产品？

数据治理是应在什么情况下（或阶段）开始治理？

1)   ODI指的就是Oracle Data Integrator（ODI）产品；

2)   数据治理在任何情况下都可以进行，在MIS系统相对较少或基本没有的情况，可以采用标准先行的方案，在MIS系统建设之前即对数据标准进行统一的校级规定，规范信息化建设过程，从数据产生开始就规范数据的质量要求，甚至是在有些数据还处于线下管理时，倒逼业务部门进行信息化建设。在系统较多，且存在标准不一、质量不高、共享效率低下等问题时，数据治理更加宜早不宜迟。越早治理，则面临的改动风险越小、校内各方协同效率越高。

问 题 六

中台产品对实时数据和非实时数据的计算分别采取哪种计算模式？效率如何？我了解到现在很多大数据的框架都提供流式计算的能力，不知道希嘉平台有没有提供这方面的能力？在学校场景里，实时数据要求场景虽不是很多，但我们在建设过程中也遇到过，怎么保证数据的实时性和准确性？达到的实时性是秒级还是豪秒级？

1） 分为两个场景：实时和非实时数据共享交换场景，实时和非实时共享计算场景；

2） 实时和非实时数据共享交换场景：对于其中的非实时场景，一般基于共享库提供API或者ETL推送方式；对于实施共享交换场景，交换共享的目标是业务通过数据联动实现某个业务的开展，即业务层交互。这种场景首选是ESB或SOA架构在两个业务系统间通过消息通讯实现业务交互。这种技术在高校中的使用并不是很广泛，尤其是高校各个厂商之间缺乏统一的业务交换标准和规范，所以导致业务集成上面有一定的困难，因此退一步进行实时性数据集成，其中一种方式就是使用开放平台直接封装源头数据库实现数据实时供给。这种方式与原来ETL过程相比，都是点对点的交换共享，但有几个区别：1.实时性更高；2.数据源数据通过开放平台封装，所有申请审核和使用的记录在平台上是有记录的可管理。还有一些技术手段，如ODI的CDC同步、OGG等。

3） 实时和非实时共享计算场景：这种要求在我们的架构中也有体现。我们的数据底层平台是关系型数据库与Hadoop平台实现的，因此对于实时和非实时的计算场景，我们可以基于 Flume + Kafka 对数据进行采集，使用Spark Streaming流计算或者HIVE之类的离线批量计算组件实现计算，这方面在希嘉的一些应用产品，如校园公共安全中有较为具体的落地方案；

4） 因为数据产生的频率、计算分析过程的原因，目前应该是十秒级。

问 题 七

希嘉的数据湖和传统的ODS有什么区别？

不严格区分的话，数据湖就是传统的ODS，设置数据湖或者ODS的目的是尽量减小对业务系统数据库的性能压力。严格区分的话，传统ODS是将需要继承的数据，“脉冲式”的采集到ODS，而希嘉的数据湖概念是，将业务系统数据库中用不着的一些临时表、备份表、系统表等过滤掉，把带有业务属性的数据全量抽取过来，集中到一个数据湖中，并添加对应注释，以便后期需要使用时能够识别、找到对应数据。

问 题 八

能不能介绍一下文档型数据的管理和使用经验？

1） 我们的体系中有一个数据填报工具，用来处理线下的Excel表格的数据形态。因为高校的确有很多数据都在线下，所以这个数据我们是不能忽略的，需要把这部分数据集成到数据平台中；

2） 填报工具能够批量建表，可以使用Excel一次性定义很多表结构，实现批量建表；

3） 能够批量导入数据的同时，进行初步的数据质量问题过滤。比如，有一个字段是性别，这个性别本身存的是男/女，Excel表填写得很自由，如果多一个空格，那么在计算机严格的字符匹配函数中，多一个空格的数据与没有空格的数据就是两个字符串，在关联查询时会引起数据匹配问题；

4） 填报工具能够实现权限管控。对于不同用户设置不同权限，比如某一个用户只能查看数据，另外一个用户可以修改数据结构，还有一个用户可以修改表中某几个字段，再有一个用户可以修改表中的另外几个字段，用这样的方式可以实现数据线上化的编辑和修改，保障数据安全；

5） 总结来说，一些线下的数据，例如当前校内的临时人员，并不在人事管理系统中管理，那么通过填报工具，可以实现对这部分数据的采集和入库。