|
他，是中国银行业IT发展史的亲历者和见证人； 他，是“宇宙行”开发体系的奠基人和建设者； 他，友朋遍四方，桃李满天下； 他，就是中国工商银行开发中心前总经理，梁礼方。 蒙梁老准允，优智汇独家开辟《金语梁言》专栏，我们将以各种形式发表梁老对中国金融IT业的思考与见解，并接受广大“梁（凉）粉”的提问，梁老将抽取其中具有代表性的问题，在专栏中答疑解惑。我们期待，《金语梁言》对于转型中的中国金融IT业具有启示和借鉴作用。 上期回顾 在《数据的存储、分布与流转（上）》中，我们介绍了包括联机交易数据库、批量数据库、ODS、数据仓库、数据集市、联机日志在内的几类信息系统数据库，并分析了上述各类数据库的定位。接下来我们将会为大家带来数据架构的规划，详细介绍数据组织、数据分布与封装、数据流转与冗余等几方面的内容。 （接上期） 二、数据架构的规划 （一）现状 现实中，对信息系统的应用架构、数据架构、流程架构，通常数据架构和流程架构都没能得到系统设计人员的足够重视。实际上，没有一个好的数据架构，根本不可能有一个好的应用架构。数据的松耦合是应用松耦合的基础和前提。可以说，数据架构与应用架构相互关系密不可分。 在许多没有严格数据架构规划的信息系统里，数据库与程序的关系是一种多对多的关系。见下图：
如上图。假设信息系统有5组程序，5组数据库。这些程序与数据库的关连关系如图所示。例如，程序1会访问数据库A、B、C、D，程序2会访问数据库A、B、D、E，……。在这种没有严格数据架构的系统里，不管系统的应用架构如何设置，都不可能达到系统内部架构真正松耦合的目的，其原因是明显的： 首先，我们考虑程序的修改引起的变化。如果程序1由于某种原因需要进行修改。例如增加、修改或提升某些功能。该修改本来也许只与数据库A有直接关系，数据库A要进行同步修改。但由于程序1与数据库B、C、D也相关，所以数据库B、C、D也极可能被程序1的修改所影响。我们不得不认真审查该修改是否会涉及数据库B、C、D。就算认为该修改与数据库B、C、D基本无关，起码也要在修改测试中验证这一点。同样，如果程序2要进行修改，数据库A、B、D、E也极可能要修改。 反过来考虑数据库的修改引起的变化。如果数据库A由于某种原因需要进行修改，该修改本来也许只与程序1有直接关系，程序1要进行同步修改。但由于程序2、3、4也要访问数据库A，无论数据库A修改了什么东西，程序2、3、4也肯定要修改。起码数据定义要修改。同样，如果数据库B要进行修改，程序1、2、3、5也要同步修改。 这种牵一发而动全身、殃及无辜的耦合关系，是系统发展和维护的噩梦。实际上也是系统维护成本和风险的最大部分。 以上举例仅仅是几组程序和几组数据库作为例子。而实际上，程序和数据库的数量要比上述例子多得多。如上面举例的某大银行，程序与数据库的数量都是上万的数量级。如果还是维持这种程序与数据库多对多的关系，那么其关系的数量就是上百万甚至更多。在系统维护中，要管理和维护好这种数量级的关系，无论投入多少成本，可以说基本上是不可能的。正因为这样，系统的修改、升级往往千虑一失。由于考虑不周（实际上是不可能周到），结果是千里之堤毁于蚁穴，一丝疏忽，造成重大故障，给服务带来重大损失。 从上面的分析还可以得出一个结论：数据架构的重要性甚至比应用架构高。程序的修改，不一定带来相关数据库的修改；但数据库的修改，肯定要带来所有相关程序的修改。 以信息系统的联机事务处理系统为例，数据架构规划包含数据组织、数据分布与封装、数据流转与冗余等几方面的内容。 （二）数据组织 首先，我们要给数据分类，把相互关系密切的数据组织成一个个数据库表。那么，什么样的数据可以放在一个表里呢，可以参考如下几点： 1、 根据业务分类银行业务的分类，有多个维度。如按客户群分：有法人客户、个人客户等；按产品线分：有资产业务、负债业务、代理业务等。 那么，我们的数据也应该对应这几方面的业务组织相应的数据库表。 2、 根据数据结构分类在一个业务分类里，还会存在许多业务数据。同一类业务数据的数据结构通常是相同的，可以组成一个数据库表。如根据不同的客户类，组织客户信息数据库表；根据不同的银行账户类，组织不同的账户数据库表。 3、 根据相互关系有一些数据，其数据结构一样，但相互之间基本没有什么关系的，应该分别组织数据库。例如对应个人卡和公司卡业务，其中卡管理和卡消费的数据库结构可能基本一样。但是，如果业务上两者基本没有交集，那么，我们宁愿配置两个数据结构一模一样的数据库表而不把它们合成一个。 （二）数据分布与封装对于面向应用的数据库，数据分布的概念是，根据应用架构的分类分层，对数据库也进行分类分层。数据库分类、分层是数据架构最重要的规划。也是与应用架构关系最密切的系统规划。 关于应用架构和应用分层，此前已有论述，让我们在此回顾一下应用分层架构。 信息系统的应用架构，最基础的元素是程序。应用则是一组关系密切的程序的集合、应用组则是一组关系密切的应用的集合、应用群则是一组在信息系统中逻辑定位相同的应用组的集合。可见，不管是应用、应用组、应用群，都是一组程序的集合，只是集合的规模大小不一样而已。见下图：
假设我们如上图，把信息系统的应用架构分为四层，那么我们可以把我们的所有数据库分为四层。即程序层、应用层、应用组层、应用群层。 数据库分层分类的原则非常简单，该数据库应该由哪一层的哪一个程序的集合访问，就把该数据库配置在哪一层的哪一个程序集合中。 数据库封装的概念是，被封装的数据，只能由封装自己的那一层的那一个程序集合的所有程序访问。其他程序决不能跨界访问。 数据架构通过这样的分层分组规划，很明显，其架构的模型与应用架构基本完全一样。是一种自顶而下的树形结构。如下图所示：
1、 程序（模块）层所有属于这一层的数据库，每个数据库均仅属于某个程序，仅允许该程序对其进行访问。如数据库1-1-1仅允许程序1-1-1访问；数据库2-1-1仅允许程序2-1-1访问。 处于这一层的数据库通常是一些专用的数据库。在所有数据库里，这类数据库所占比例不会很多。 2、 应用层所有属于这一层的数据库，每个数据库均仅属于某个应用，允许属于该应用的所有程序对其进行访问，但不允许其他应用的访问。如数据库1-1允许程序1-1-1访问，也允许程序1-1-2访问；数据库2-1允许程序2-1-1访问，也允许程序2-1-2访问。由于一个应用也许会包含了许多程序，所以，属于应用层的数据库将可能允许许多程序对其进行访问。该数据库的修改会带来所有属于该应用的许多程序的修改。 处于这一层的数据库通常是一些对应产品的数据库。在所有数据库里，这类数据库所占比例相对较多。 3、 应用组层所有属于这一层的数据库，每个数据库仅属于某个应用组，允许属于该应用组的所有程序对其进行访问，但不允许其他应用组的访问。如数据库1允许程序1-1-1访问，也允许程序1-2-2访问；数据库2允许程序2-1-1访问，也允许程序2-2-2访问。由于一个应用组会包含了大量程序，所以，属于应用组层的数据库将允许大量程序对其进行访问。该数据库的修改会带来所有属于该应用组的大量程序的修改。为了使应用组里的应用相互能够尽量的松耦合，在规划数据架构时，应尽量减少该层数据库的数量。并且应该只把数据结构是相对稳定、甚至是不变的数据库配置在该层。 处于这一层的数据库通常是一些产品线通用的数据库。系统设计人员应该尽量减少这类数据库在所有数据库里所占的比例。 4、 应用群层接下来的问题是，是否要规划归属于某个应用群的数据库呢？要回答这个问题，我们要回到建立良好数据架构的初衷。 建立良好的数据架构就是为了能实现应用的松耦合。一个大的信息系统，程序动辄是万的数量级。而一个大系统通常也就几个应用群，那么，最大的应用群程序也许上万。如果我们配置了属于某个应用群的数据库，由于该数据库由该应用群内所有的程序共享，一个由上万程序共享的数据库，会成为该应用群内应用松耦合的障碍。 当然，不配置这类数据库是理想的想法。实际上，如果不得不配置处于应用群的数据库，这种数据库一定要是相对静态的数据库。也就是说，该数据库数据结构不会变化，数据内容在日常应用里也基本不会变化。 最后，对数据封装作一个总结： 根据需要，我们把整个信息系统的所有数据库按应用架构的层次，封装到某一个层次的某个程序集合里。 封装在某一层的某个程序集合里的数据库，只允许该层该程序集合的所有程序对其进行访问例。而不允许其他程序对其进行访问。可见，越配置在高层的数据库，越多程序可以访问。从极端来设想，如果我们把所有数据库都配置在信息系统的最顶层，就是说，信息系统的所有程序都可以访问信息系统的任何一个数据库。那么，就等于完成没有架构可言。所以，从程序与数据松耦合的概念出发，封装在上层的数据库应该越少越好。这才是好的数据架构。 （二）数据流转与冗余数据封装带来的好处一方面是数据隔离、数据安全，另一方面是松耦合。理论上，如果不能做到数据封装，就不可能做到应用的松耦合。 那么，在数据封装的前提下，如何保证数据流转与共享的效率。如果由于数据封装严重影响数据的流转效率，数据的封装是否可行。这一直是令系统设计人员纠结的一个问题。 数据冗余给数据封装带来可行性。 在不讲究数据架构时，所有数据是随意流转与共享的。如果不考虑其他因素，数据完全共享对任意信息的取得效率是最高的。但在构建了上述数据架构后，数据全封装起来了，数据变成好像是私有的。 与程序的服务调用管理规则一样，数据的服务与流转也是一种自顶而下的服务管理。如果某一个应用需要的某个信息不在其封装的数据库里，该应用只能通过其父系节点，向目标数据库所属的应用进行数据服务的调用，以取得所需信息。 举例来说，如果程序1-1-1希望取得数据库2.2.2的信息，其数据服务流程是：应用群A→应用组2→应用2-2→程序2-2-2。应用群A通过程序2-2-2取得相应信息后，通过流程：程序2-2-2→应用2-2→应用组2→应用群A→应用组1→应用1-1→程序1-1-1把信息交给程序1-1-1。这么一来，增加了环节，增加了系统内部的信息交换流量，增加了机器处理开销，增加了响应时间。一句话，降低了效率。见下图：
上述情况应该是一个特例。如果程序1-1-1真的会经常需要取得数据库2-2-2的信息，我们这样的数据架构设计就是一个失败的例子。因为我们数据架构规划的原则就是程序与数据库关系越是密切的，就越应该配置在一起。并且应该配置在同一个低层里（例如应该把程序2-2-2和数据库2-2-2配置在应用1-1里）。 但不理想的特例总会存在。如果我们在系统设计的时候已经非常清楚程序1-1-1在某种情况下需要数据库2-2-2的某些信息。而程序2-2-2与数据库2-2-2有有充分的理由应该配置在应用2-2里。那么，为了平衡松耦合与效率，我们还可以通过把数据库2-2-2中程序1-1-1会需要的信息冗余封装到程序1-1-1里。如果不光程序1-1-1会需要该信息，程序1-1-2也会需要该信息，我们可以把信息冗余封装在应用1-1里。 数据冗余的设计把相同的数据配置多个版本。其中数据母体我们称之为源数据，冗余版本称之为辅数据。数据冗余要遵循以下原则： 1、 兼顾效率数据冗余可以提高效率，但数据冗余增加了系统的复杂度，带来额外的空间开销和管理维护开销，不应该滥用。在兼顾效率时要平衡效率与复杂的关系。 2、 数据同步源数据的增、删、改的权限在源数据归属的应用。当源数据发生变化时，辅数据要及时同步变化。以保证数据的一致性和准确性。至于怎么样算“及时”，用什么手段进行数据同步，要视具体冗余数据的性质而定。 3、 冗余数据的选择由于存在数据同步的管理，为了减少同步的频繁度和复杂度，冗余数据通常应该是一些静态数据或者同步实时性要求不高的数据。
|
|
|
