数据架构实践简介
数据架构应该是面向业务的数据定义、数据生产、数据分析、数据使用的整体架构。
从数据生命周期来看，目前主要涉及到三种角色：
开发DBA：负责研发项目的数据库支持，包括数据库设计、SQL审核及优化。
运维DBA：负责线上数据库的日常运维，包括数据库部署、备份、监控、变更及故障处理。
数据仓库：负责离线数据的抽取、建模、分析、挖掘等。 当然，所有DBA还得共同为线上数据库的可用性、扩展性、高性能负责。
数据架构的工作主线，是要从开发源头规划控制数据逻辑架构和物理架构：
逻辑架构：主导数据建模，制定并推行数据标准，控制数据质量，主数据管理。
物理架构：数据库架构，数据库性能、容量、可用性方案规划及实施，偏重于前端业务，和应用、中间件结合。
数据架构的工作实践
1. 流程规范
数据架构的流程规范主要目的是保证对研发项目的提前介入和数据库方面的管控，数据库管控主要包含两部分：
数据库环境的统一管理：不仅仅是线上数据库环境需要由DBA来统一管理，线下环境也同样需要交由DBA管理，这个是一切的基础。
数据库变更的统一控制：在数据库环境统一管理的基础上，所有数据库(线上、线下)的数据库变更由DBA统一进行。 通过对数据库的管控，在开发测试阶段即可以将数据库方面的设计和评审进行收口，保证数据库设计的合理性，保障项目上线后的SQL性能。 研发项目的介入则需要有相应的研发项目流程支持，需要有明确定义的立项、开发、测试、上线的里程碑和评审会议，并且保证通知到相关人员参与，具体的流程节点可以根据实际情况有所调整。
当然，在当前敏捷开发的趋势下，要尽量将数据库管控对应用开发的影响降到最低，需要有相应的工具平台对流程规范进行支持：
变更平台：数据库变更提交、审核与执行流程。
自助审核平台：数据库SQL(DDL、查询SQL)的自助审核。
2. 数据治理
数据治理是一个关注于管理信息的质量、一致性、可用性、安全性和可得性的过程。这个过程与数据的管理职责紧密相关。数据治理主要包含四方面内容：
数据标准：对分散在各系统中的数据提供一套统一的数据命名、数据定义、数据类型、赋值规则等的定义基准。
数据质量：对支持业务需求的数据进行全面质量管理，通过数据质量相关管理办法、组织、流程、评价考核规则的制定，及时发现并解决数据质量问 题，提升数据的完整性、及时性、准确性及一致性，提升业务价值。
元数据：关于数据的数据，用以描述数据及其环境的结构化信息，便于查找、理解、使用和管理数据。
主数据：用来描述企业核心业务实体的数据，比如客户、合作伙伴、员工、产品、物料单、账户等；它是具有高业务价值的、可以在企业内跨越各个业务部门被重复使用的数据。 数据标准通俗理解就是要建立数据对象(表、列、域)的统一命名规则，和数据库命名规范有点类似，不同的是数据库命名规范更偏向于数据库维护的视角，数据标准更偏向于数据模型设计的视角。数据标准主要包括以下两部分内容：
数据标准的制定：包括标准单词、标准域、标准用语词典的制定。
数据标准变更流程：数据标准的新增和修改管控流程和平台。 要做好数据标准的管控工作，同样需要有相应的工具进行支持：
数据建模平台：与PL/SQL Developer等数据库客户端软件类似，提供界面化的建表操作功能，所不同的是将数据标准和数据库规范的规则内嵌在数据建模平台中。
数据标准管控平台：数据标准的维护和新增管理。
<wbr>
<wbr>
数据架构的挑战
数据架构工作目前的困难和挑战：
行业环境上
对数据架构重要性认识不足，当然也与IT产业的当前发展阶段有关。
专业岗位和人才较少，传统的DBA并不都可以或者愿意从事数据架构的工作。
重物理架构轻逻辑架构，数据模型的设计合理性不太受关注。
工作模式上
数据架构在敏捷开发流程中如何较好地实施，敏捷开发往往会要求流程和评审越少越好(当然不一定正确)，而数据架构需要通过一些流程规范介入和指导研发中的数据库相关工作。
业务需求与数据架构需求资源冲突，数据架构需求有时只能为业务需求让路。
数据架构是一项系统工程，需要上层领导的鼎力支持，也需要兄弟部门的全力配合，才可能取得一定的成果。
