数据架构难点

数据架构是架构设计中很重要的一环，可能对于很多DBA而言，数据管理，数据优化，数据迁移类的工作居多，而对于数据架构方面的工作也会思考少一些，这方面就会薄弱一些。

如果在这个行业里有一定的经验，就会发现如果细细来看数据架构，原来很多东西我们是在这么用，但是没有一个系统的整理和分类来归纳出来，有些时候我们做技术很容易陷入一个漩涡，那就是很容易去考虑一些非常具体的事情，而很难从整体上来把握。今天下午看了下温昱老师的书《一线架构师实践指南》，这方面的很多盲点都得到了一个系统的解答。

数据架构中的一个难点：数据分布问题在数据架构中是很重要的一环。随着数据，系统量级，业务场景的需求，数据分布有6中具体策略。分别是独立Schema,集中，分区，复制，子集，重组。

这几个概念听起来可能有些抽象，我们逐个来说一下，其实我们很多场景就是这么在用。

独立Schema：一个大系统由很多子系统组成，比如业务A有表testa,业务B有表testb,则他们都有独立的Schema来定义存放，这样能够减少系统之间的相互影响，避免将问题复杂化。

这一点来说在Oracle是用户Schema,在MySQL则是database这个层级体现出来。

集中：这种策略的核心就是“集中存储，分布访问”，比如很多业务都会访问表test1,test2,test3,则这些数据是集中存储起来的，不同的业务根据需求来分布访问。这一点用Oracle RAC来解释最清晰不过了。可以使用共享存储来集中式存储应用数据，然后通过多个计算节点来扩展读写需求。

分区：这个分区和数据库里的分区表不同，这个是基于架构层面，水平分区和垂直分区，水平分区的使用场景要广泛的多，比如一个用户信息表，存放了不同的区域的用户数据，我们可以根据地域来作为区分依据，这样就把这个表的数据做这样的拆分，放在不同的用户下，或者放在同一个用户表结构相同，表名不同的表里里面。 而相对来说，垂直分区的使用场景就局限很多，比如表test有a,b,c,d四个字段，做垂直分区就可以拆分，比如(a,b），（c,d） 。总体来说分区随着数据量的增长需要提前规划和设计。

复制：这个概念说通俗一些就是多副本，存在多分数据的情况，这个主要是通过实时或者快照级别来保持多个数据副本的数据一致性。这个策略在MySQL中Master,Slave的读写分离就是一个很典型的例子，或者是MySQL最新的MGR就是一个很经典的说明。 Oracle中的Primary,Active Data Guard也是一种体现。

最终是保证有多分数据副本，达到数据一致性。

子集：这个模式相对有些抽象，和复制有一些相似，但是是子集数据的一致性，比如我们有大量的用户交易数据，根据不同的渠道，比如网银渠道，手机微信支付，支付宝支付等会做特定的数据子集的一致性同步。

重组，这个分为两种类型，统计性重组和结构性重组，就是从不同的维度来进行数据钻取。比如我们根据一些交易数据的细节，需要得到一个基本的数据情况，比如交易流水总量，账单信息等，在很多统计分析的场景中就会存在，这是统计性重组。

而如果我们有用户的概要信息，用户的详细信息放在更多具体表中关联，这样的情况就是结构性重组。其实Oracle中的物化视图刷新在平日的工作中，这两种类型就很常见。

我们简单总结一下，比如一个医院的用户数据和病历数据，从数据架构的分布角度来考虑，该怎么设计，首先是用户数据，这个极可能要统一集中式管理，所以集中就是一个相对合适的方案，而用户的病历数据考虑到地域性的特点，为了提高性能和访问情况，可以考虑使用复制的方案。

比如电信行业的计费数据，数据量非常大，在数据架构的分布上，就需要采用分区的策略，比如我们按照账期的业务规则来划分，把不同账期的数据分布在不同的数据存储中。

比如游戏行业数据架构中的数据分布，不同的游戏服彼此独立，没有强耦合关联，就可以考虑使用分区的策略，而用户的基础信息这些需要做到平台化，基于管理和安全角度，最好能够统一规划，所以集中就是一个很不错的方案。

当然从质量属性方面来看。这6中方案还是有一定的特点，有优势有劣势。

我们就从可靠性，可伸缩性，通信开销，客观理性，数据一致性这几个方面来看看六种数据分布方案的情况。

可靠性上，复制最佳。

可伸缩性方面，分区中的水平分区最佳

通信开销方面，独立Schema最佳

可管理性方面，独立Schema和几种策略最佳

数据一致性方面，集中最佳。

可以发现，子集和重组均没有入榜，也能够间接说明这两种数据分布还是有一些特定的使用场景，不具有普适性。