亿信华辰

连续4年稳坐商务智能应用榜首

与此同时,亿信华辰在数据治理领域也获得殊荣,摘得榜眼

首页关于行业资讯数据治理

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

时间:2019-01-08来源:亿信华辰浏览数:303

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

 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的列表中,需要及时改造。还有就是缓存服务器的监控也是需要关注的。


(部分内容来源网络,如有侵权请联系删除)
立即免费申请产品试用 申请试用

微信
咨询

立即扫码
享受一对一服务

亿信微信二维码

联系
电话

您好,商务咨询请联系

咨询热线:400-0011-866转0

手机咨询:137-0121-6790