什么是数据架构，通常的角度理解会有两种常见观点：

• 大数据架构：后端大数据采集、存储、计算、分析等场景的通用架构设计。在当前大数据的概念异常火爆的情况下，随便搜索一下“数据架构师”的招聘职位，80%以上的数据架构师职位都是指大数据架构师，或者数据平台架构师。

• 数据库架构：前端业务数据库的高可用、高性能、可扩展架构选型、规划、实施、优化等，应对海量数据和高并发业务需求。
  这两种观点都有一些偏颇，从整个公司的角度来看，企业架构包含业务架构、技术架构和数据架构。数据架构应该是面向业务的数据定义、数据生产、数据分析、数据使用的整体架构，与业务架构、技术架构相辅相成，密不可分，故大数据架构和数据库架构都只是数据架构的一个子集。当然，由于在实际工作当中职责范围的局限性，不大可能涵盖到所有的数据架构场景，这里就以自身在互联网金融公司的经验和工作内容来谈谈数据架构实践。

  数据架构的有限理解

  数据架构我们所面临的问题：

• 互联网金融、支付业务的复杂性高，与钱打交道，随时有资金损失风险。

• 数据标准及数据质量决定数据价值高低。

• 高一致性、高可用性、高性能与低成本要求。
  从数据生命周期来看，目前主要涉及到三种角色：

• 开发DBA：负责研发项目的数据库支持，包括数据库设计、SQL审核及优化。

• 运维DBA：负责线上数据库的日常运维，包括数据库部署、备份、监控、变更及故障处理。

• 数据仓库：负责离线数据的抽取、建模、分析、挖掘等。
  当然，所有DBA还得共同为线上数据库的可用性、扩展性、高性能负责。

这种模式相对比较传统，也能够应对大部分数据架构问题和场景，但还是存在一些不足：

• 开发DBA缺乏对数据标准、数据质量关注。传统的开发DBA更关注于前端数据库，对后端数据仓库所面临的问题没有太多感同身受，比如直接关系到数据价值的数据标准和数据质量，在数据定义阶段(项目开发阶段)就已经定型了，数据被抽取到数据仓库做分析和挖掘时，对这些问题已经于事无补。

• 运维DBA、数据仓库介入时间过晚。线上数据库的性能和扩展性主要由数据库模型设计和SQL性能决定，数据标准和数据质量同样主要由数据定义阶段决定，数据生产和数据分析阶段已经处于事后的阶段了，只能被动地解决这些问题。
  可见，要做好数据架构工作，一方面要尽量在事前和事中(项目的设计和开发阶段)提前介入，另外一方面需要同时关注数据生产和数据分析中面临的问题。

数据架构的工作主线，是要从开发源头规划控制数据逻辑架构和物理架构：

• 逻辑架构：主导数据建模，制定并推行数据标准，控制数据质量，主数据管理。

• 物理架构：数据库架构，数据库性能、容量、可用性方案规划及实施，偏重于前端业务，和应用、中间件结合。
  另外，正如前面所说的，数据架构需要与其他架构工作协同，要充分利用业务架构、技术架构的力量。为什么这么说呢？举例来说，数据架构中的主数据管理(主数据指系统间共享数据，如客户等)要解决的一个最大的问题就是消除多个系统间冗余主数据的不一致，如果在业务架构中规划了主数据中心(如用户中心)将主数据统一集中管理，就从源头上解决了主数据的一致性问题；数据架构中的数据库中间件，则要依赖于技术架构的力量了。
  数据架构需要具备数据库、业务、开发、数据治理知识。数据库方面需要对关系型数据库和非关系型数据库都有一定了解，特别是现在在互联网场景使用较多的Oracle、MySQL、Hbase、Mongodb、Redis等，需要知道它们的底层原理和适用场景；业务方面需要对公司的整体业务流程有一个全面的认识，这样可以帮助我们更好地理解数据的使用场景，针对性地进行架构设计，并且很多问题在数据库层面是无法解决的，需要业务上的配合才能够达到效果；开发能力在现阶段已经越来越重要，不说现在的自动化运维工具开发、数据库中间件开发，和研发同事打交道必须要有一定的开发知识，所谓知己知彼，百战不殆；最后是数据治理的知识体系(主数据管理、元数据管理、数据标准、数据质量)。

数据架构的工作实践

• 1. 流程规范

  数据架构的流程规范主要目的是保证对研发项目的提前介入和数据库方面的管控，数据库管控主要包含两部分：

• 数据库环境的统一管理：不仅仅是线上数据库环境需要由DBA来统一管理，线下环境也同样需要交由DBA管理，这个是一切的基础。

• 数据库变更的统一控制：在数据库环境统一管理的基础上，所有数据库(线上、线下)的数据库变更由DBA统一进行。
  通过对数据库的管控，在开发测试阶段即可以将数据库方面的设计和评审进行收口，保证数据库设计的合理性，保障项目上线后的SQL性能。
  研发项目的介入则需要有相应的研发项目流程支持，需要有明确定义的立项、开发、测试、上线的里程碑和评审会议，并且保证通知到相关人员参与，具体的流程节点可以根据实际情况有所调整。

当然，在当前敏捷开发的趋势下，要尽量将数据库管控对应用开发的影响降到最低，需要有相应的工具平台对流程规范进行支持：

• 变更平台：数据库变更提交、审核与执行流程。

• 自助审核平台：数据库SQL(DDL、查询SQL)的自助审核。

  2. 数据治理

  数据治理是一个关注于管理信息的质量、一致性、可用性、安全性和可得性的过程。这个过程与数据的管理职责紧密相关。数据治理主要包含四方面内容：

• 数据标准：对分散在各系统中的数据提供一套统一的数据命名、数据定义、数据类型、赋值规则等的定义基准。

• 数据质量：对支持业务需求的数据进行全面质量管理，通过数据质量相关管理办法、组织、流程、评价考核规则的制定，及时发现并解决数据质量问 题，提升数据的完整性、及时性、准确性及一致性，提升业务价值。

• 元数据：关于数据的数据，用以描述数据及其环境的结构化信息，便于查找、理解、使用和管理数据。

• 主数据：用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等；它是具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据。
  数据标准通俗理解就是要建立数据对象(表、列、域)的统一命名规则，和数据库命名规范有点类似，不同的是数据库命名规范更偏向于数据库维护的视角，数据标准更偏向于数据模型设计的视角。数据标准主要包括以下两部分内容：

• 数据标准的制定：包括标准单词、标准域、标准用语词典的制定。

• 数据标准变更流程：数据标准的新增和修改管控流程和平台。
  要做好数据标准的管控工作，同样需要有相应的工具进行支持：

• 数据建模平台：与PL/SQL Developer等数据库客户端软件类似，提供界面化的建表操作功能，所不同的是将数据标准和数据库规范的规则内嵌在数据建模平台中。

• 数据标准管控平台：数据标准的维护和新增管理。
  数据质量问题需要对数据进行稽核时才能够发现。由于在开发测试数据库中的数据并不是真实数据，故只能在数据生产之后的阶段才能够进行。当然，可以结合实际的数据质量问题制定数据质量规范，并推广实施。
  元数据管理主要是数据模型的管理，在当前数据库设计中，显式的主外键约束已经很少使用，这样带来的问题就是无法从数据库中获取到实体之间的参照关系和参照字段，对数据模型的理解造成困扰，并且可能在各个不同系统中对同一属性的定义不同而造成数据传递出现问题。故需要对数据模型进行定期管理和维护，尤其是主外键关系和数据流。
  主数据管理不能够寄希望于通过技术手段(如分发、复制、同步)来实现各个系统中冗余主数据的一致性，关键还是要从业务架构的角度出发，建立全局统一的主数据中心，从源头消除主数据的问题。在主数据管理上，需要数据架构与业务架构紧密配合。
  总之，对流程规范和数据治理来说，需要有一个统一的数据定义阶段的建模标准和建模平台。

  3. 数据库中间件

  数据库中间件主要解决关系型数据库的扩展性，以及关系型/非关系型数据库的数据迁移、交换问题。
  数据库存取中间件用来解决关系型数据库的扩展性问题，需要重点考虑两方面的现状和需求：

• 业务系统开发语言：是多种语言，还是单一Java语言。

• 数据库类型：是同时存在Oracle、MySQL等的混合数据库环境，还是单一MySQL环境。
  上面两点决定了是采用客户端数据库中间件类型，还是服务端数据库中间件类型。由于我们是单一Java开发语言，并且是同时存在Oracle、MySQL等的混合数据库环境，故自主研发了客户端数据库中间件： CDS(Completed Database Splitter)。

在对关系型数据库做水平扩展时，会碰到两个很难逾越的问题：

资料推荐

• 分布式事务

• 跨库join
  目前来说对这两个问题尚没有非常完美的解决方案，建议通过调整设计规避这两个问题。非关系型数据库正是打破了这两个桎梏，才换来了高度灵活的可扩展性。
  数据迁移中间件，主要应对以下的需求场景：

• 去O迁移

• 集群扩容

• 水平拆分历史数据初始化
  针对以上需求场景，我们推出了支持异构数据库、支持全量和增量数据迁移方式的数据迁移中间件，并且可以和数据库存取中间件配合使用。

  数据架构的挑战

  数据架构工作目前的困难和挑战：

• 行业环境上

  • 对数据架构重要性认识不足，当然也与IT产业的当前发展阶段有关。

  • 专业岗位和人才较少，传统的DBA并不都可以或者愿意从事数据架构的工作。

  • 重物理架构轻逻辑架构，数据模型的设计合理性不太受关注。

• 工作模式上

  • 数据架构在敏捷开发流程中如何较好地实施，敏捷开发往往会要求流程和评审越少越好(当然不一定正确)，而数据架构需要通过一些流程规范介入和指导研发中的数据库相关工作。

  • 业务需求与数据架构需求资源冲突，数据架构需求有时只能为业务需求让路。

  • 数据架构是一项系统工程，需要上层领导的鼎力支持，也需要兄弟部门的全力配合，才可能取得一定的成果。
     

  •  

  • 关于：中科研拓

  • 深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务，十年研发经验，上百成功案例，中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值，致力于为用户提供很好的软件解决方案。联系电话400-0316-532，邮箱sales@zhongkerd.com，网址www.zhongkerd.com