现在互联网公司业务发展都是非常飞速，当业务发展到一定规模，就得考虑如何去做服务治理，大家的重心一般放在微服务的应用架构设计层面，往往比较容易忽略关系数据库的设计规划。无论上层服务治理的如何，其实关系数据库还是各个系统的基础和核心，系统的稳定性，高可用性，高性能是和数据库有最直接的关系，所以我觉得服务治理的同时也需要同时考虑数据方面的相关规划和实现，但是只有基础扎实了，上层服务才能更加稳固，也才能飞的更高更快。本人最近在公司做些数据相关的工作，以下是我总结的数据治理一些关注点，希望能给开发童鞋一点帮助，尽量少挖坑：
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的列表中，需要及时改造。还有就是缓存服务器的监控也是需要关注的。
以上是个人的粗浅认识，欢迎各位童鞋拍砖。
