睿治

智能数据治理平台

睿治作为国内功能最全的数据治理产品之一，入选IDC企业数据治理实施部署指南。同时，在IDC发布的《中国数据治理市场份额,2022》报告中，蝉联数据治理解决方案市场份额第一。

在线免费试用 DEMO体验视频介绍

睿治智能数据治理平台

IDC蝉联数据治理解决方案市场第一

应用系统的数据治理一些关注点

时间：2019-01-08来源：亿信华辰浏览数：796次

现在互联网公司业务发展都是非常飞速，当业务发展到一定规模，就得考虑如何去做服务治理，大家的重心一般放在微服务的应用架构设计层面，往往比较容易忽略关系数据库的设计规划。无论上层服务治理的如何，其实关系数据库还是各个系统的基础和核心，系统的稳定性，高可用性，高性能是和数据库有最直接的关系，所以服务治理的同时也需要同时考虑数据方面的相关规划和实现，但是只有基础扎实了，上层服务才能更加稳固，也才能飞的更高更快。

1.设计规范

对于数据库，表，字段，索引等的命名需要统一规范，方便dba的管理，提升开发团队之间的沟通成本，最好是提供数据库change log平台来统一上线管理，这样可以进行审核和规范落地。数据库索引设计，数据库的稳定性，高可用性，高性能都和索引息息相关，按照最左前缀原则来设计，没有把握时，可以找dba进行求助

一定要给每个表设计主键，创建时间，修改时间字段，可以对数据修改的纪录进行跟踪，也可以方便数据仓库进行增量数据拉取，创建时间／修改时间可以通过封装DAO组件默认设置值

对于互联网应用，尽量遵守范式设计规范，但是冗余字段的设计也应该适时考虑，如果两个以上业务功能点需要同时join某3个表，建议设计冗余字段来解决

数据库设计的规范还有很多，就不一一例举，最主要还是如何保证规范的施行。数据库设计的规范很多公司都有，但是并没有很好的实施，导致数据库看起来还是非常混乱，很多情况是缺少流程的管理和工具的辅助，一些硬性的规范就可以通过工具来控制，对于线上应用的DDL发版都需要DBA进行审核才能进行。对于高频或者数据量大的DML语句同样需要DBA进行审核才能发布更新。

2.数据分域

当业务经过野蛮增长，单一系统无法支撑业务时，就需要进行业务拆分，同样也应该进行数据拆分，业务应用和schema需要做到一一对应，并且进行权限隔离，一个schema只能被一个应用所有，所有对这个schema的数据的查询，新建，修改只能通过这个系统的接口来调用。公共数据服务统一管理，比如国家，城市，交易日历，不能会产生有大量相同数据的表，造成数据重复隐患，这些数据保存时也尽量原子化，避免事后拆分

数据指标也要做到统一来源，如投资量，投资收益率，AUM，累积收益等统计指标，其他应用应该根据同一来源数据进行业务逻辑处理，如果有不同来源或者每个系统自己计算的话，不但公司内部容易混淆，而且很容易被用户投诉

复杂计算的业务尽量不要根据用户的请求来做实时计算，比如互联网金融网站的资产类，收益类数据，一般都需要跨越多个schema来获取，金融产品形态越多，计算就越复杂。如果进行实时计算的话，会很耗费系统资源特别是数据库资源，可以考虑由每个金融产品系统自身保存这个数据，也就是每个用户投资不同类型的产品，都需要为这个用户建立虚拟帐户，这个账户可以维护用户的资产，收益等情况。另外一个思路时定义一个标准的消息，当用户的资产，收益有变化时，发送消息，由资产服务来统一处理这些消息，不过需要考虑消息的丢失，延时等情况，难度比较大。如果对数据的实时性要求不高的话，能够线下大数据等方式来计算这些数据的话更好。

3 .开发优化

数据库设计时不单要考虑业务的实现，也要同时考虑代码的性能，更胜者还需要考虑给其他的数据使用者（数据聚合／数据分析等）提供方便

不要过度设计，每个系统都会有些表的字段从来没有值，可能是当时预留字段，但是现在看来，很多预留字段都是浪费的，建议还是真正需要时再添加不迟

无论是做数据结构设计还是sql的编写，都应该控制复杂度，复杂的sql会导致数据库load的冲高，当PV上来时，系统响应变慢，然后系统请求堆积，严重的最后会导致整个系统完全无法提供服务，所以每个开发童鞋写sql时需要优先考虑性能问题，让每条sql尽量简单，都能走到对的索引，通过应用程序去解决复杂的sql逻辑查询

不要把所有数据都丢到数据库，特别是数据量大的日志型数据可以通过日志输出，通过elk／flume+storm等方式拉取到es中进行查询跟踪，如果硬是要保存到数据库，那只需要保存异常数据即可。用户行为数据可以发送消息出去，由其他应用来监听消息并且保存到Redis／MongDB中，比如登陆相关数据，投资行为等数据，如果这些数据需要用来做业务流控，如现在登录次数等业务场景，可以使用redis的数据过期机制来实现

不要给用户太大的空间进行数据的输入，尽量提供选择框让用户选择，防止脏数据的产生，关键字段要设置为必填，否则会给数据分析时的数据清洗带来麻烦

设计好表的UK，可以避免数据的重复，也可以给接口的幂等性提供支持

对于数据量大的业务处理建议使用异步化的方式来实现，通过发送消息的方式进行数据分片，然后可以对数据进行分布式处理，提高数据处理速度

对于大表，首先考虑数据库的优化，然后再考虑读写分离，是否可以做分区表，数据归档来提升性能，最后才去考虑进行分表分库的设计，分表分库无论对于系统本身的设计开发很难的把握，同时对于数据的使用者也是增加了复杂度

对于缓存数据的使用，尽量不要缓存用户唯度的数据，这种类型的数据不但给缓存服务器带来压力，更主要是缓存的命中率低，所以对于缓存的使用也是设计的关注点，不要因为某个缓存数据的暴增而拖垮整个缓存服务器

随着数据量的积累，有些数据过了其的生命周期，也就是说这些数据变成了冷数据，没有系统需要再使用它了，那么我们就要定时的去做一些数据的归档，腾出数据库资源给热数据来使用

涉及数据量大的更新，如某个表新增的非空字段等，建议分批进行更新。分批不但为了数据库的稳定，防止引起数据库的死锁，同时也防止ETL工具拉取大量的更新数据，因为很多报表需要依赖ETL同步完成数据，如果ETL同时超时的话，很多定时报表会运行失败，有可能需要手工再次运行报表任务，所以进行大数据量更新时，一定要通知DBA和数据团队进行跟踪关注。

4.数据监控

监控是最后的守护者，可以及时的发现系统的性能问题，对于数据库来说，

DBA可以通过数据库的监控工具来实时的对数据库进行监控，对于核心表的数据量增长趋势，核心表相关的sql查询性能都需要进行跟踪。但是提前发现sql的性能问题，进行合适的预防则是开发团队需要关注的。这就需要监控中心对sql的运行时间和次数等指标进行跟踪和汇总,如果当前没有监控中心，也可以使用DruidDatasource的statFilter功能进行跟踪，开发团队需要定时的去关注sql运行时间，运行次数等指标，随着业务量的增长，之前高性能的sql可能会变慢，高频sql绝对不能出现在long sql的列表中，需要及时改造。还有就是缓存服务器的监控也是需要关注的。

（部分内容来源网络，如有侵权请联系删除）

立即申请数据分析/数据治理产品免费试用我要试用

上一篇：数据治理能力正在成为互联网+时代城市竞争新优势...

下一篇：数据治理——精细科学的政策平衡...