- 数据分析
- 数据治理
- 产品解决方案
- 行业解决方案
- 案例
- 数据资产入表
- 赋能中心
- 伙伴
- 关于
时间：2022-06-17来源：小怪兽浏览数：301次
简单一点，数据架构就是怎么让数据分布的更合理，更高效的支持应用功能，快速的满足业务各个流程中的增删查改要求，同时解决好系统里各功能模块间的引用关系，以及多个系统间的引用关系。
近年来，数字化转型如火如荼，业务模式、产品和服务的竞争力转变是目的，而新技术的应用则是支点和手段，数据的采集、整合、应用、管理才是数字化转型的基础。数据的形态、格式以及类型的转变已经势不可挡，半结构化、非结构化的数据越来越多，数据的体量和复杂性正在快速增长，而应用快节奏的迭代变更同时又要求数据架构的变化也得跟上，新角色（数据分析师)对数据多样性需求只增不减，这就对数据架构的设计和管理提出了更高的要求。
1、数据分布要求多样化
数据量增长迅猛，数据类型千变万化，使得数据库技术发展迅速。全世界目前已经有363个数据产品，有传统的关系型数据库，用来进行结构化数据存储和相关事务处理。新兴的NoSQL数据库及专用型数据库，具有高并发高吞吐量的特点，用于存储和处理非结构化或半结构化数据（如文档，图，时序、时空，K-V）；其他的如列式存储的分析型数据库，既进行海量的数据存储和复杂的分析计算，又可以支持深度的智能化分析。数字化转型后各个应用系统应用场景多样化，数据访问方式及访问性能要求复杂化，同时对数据生命周期的要求也更精细化，以上决定了在数据分布设计时需要选择适合自己的不同的数据库技术开展整体方案设计，满足业务需求。
2、数据建模个性化
DMBOK2将数据建模和设计定义为“数据模型是形式化的表达和沟通数据需求的过程和产物”，数据模型的主要目的是识别或确认数据要求，换句话说是业务需求定义的扩展，做到能够在少变动数据结构的情况下支持未来的应用功能，支持基于组件和敏捷的开发这是模型设计的方向。灵活但不能失控，复杂但需要溯源，高效但需要高质，数据模型设计和管理需要适应新形势的发展要求，量体裁衣、因地制宜。数据模型分为概念建模、逻辑建模和物理建模三个阶段。概念和逻辑模型阶段是为了与业务人员更好的沟通，便于业务人员理解，而到了物理模型阶段，如何能让系统简化数据冗余、减少磁盘空间、提升传输效率，系统拥有良好的兼容性，对外服务的窗口时效性、传输安全性、数据的全面完整性成为了设计第一考虑因素。
面对不同类型的数据库，我们需要对不同业务条线的系统，采用不同的数据建模设计方法，以满足业务对数据的读写性能等需求。强数据一致性业务功能需要采用传统的关系型数据库进行技术支撑，其数据架构设计可以继续沿用业内认可的数据模型设计及模型管理方法论开展相关工作，制定并执行企业数据标准，做好数据一致性的管理，同时按照企业的发展要求做好数据的生命周期管理，继续采用发布数据模型及文件的方式提供数据服务。高并发查询或全文检索等场景需求需要借助一些非关系型数据库进行功能实现，其数据架构需要结合不同的场景下读写模式要求进行设计才以达到自己的目标。这类数据库的存储体系强化了对数据Schema灵活变化的支持，所以降低了数据的一致性容忍度，弱化了数据可用性和灾难恢复的需求，加大了数据的延迟性，在数据架构的设计过程中它们不用遵循关系数据库中的范式约定，但为了性能考虑，必要的规范和原则还是需要。没有规矩不成方圆，不能因为灵活就放弃原则，比如HBase 中的行键（rowkey）结构的定义，行键应该包含什么信息以及分布,表应该有多少列族等；Redis中Key值的格式规范，value值大小的控制等；Elasticsearch里 索引设置及分词选择，Index Mapping配置（字段配置，索引关系处理）等。不能因为它们no Schema或less Schema理念就不去做模型的管控，其实更需要做好这类数据库中实体和关系的管理，避免出现数据大量的存储浪费等失控现象。
3、架构管理服务化
转变思维，我们要以面向服务和运营的方式进行数据管理。这是要求数据架构管理方多方位的提供全部数据的目录、记录、共享、报告、分析等信息给相关利益相关者，通过建立数据共享机制，保证数据源的唯一性；通过数据质量审核，保证数据的准确性、完整性；加强数据分布的集中维护、定期更新、策略备份等管理工作，避免数据源计入不受控，造成数据浪费，从而最终实现数据的真正共享。有句话很有道理：数据和信息的来源很重要，甚至比数据和信息本身还要重要。这要求我们必须清楚的做好数据血缘关系，清晰的知晓数据的来龙去脉，避免最后数据形成了糊涂账。伴随着数字化转型，数据已经变成了企业的数据资产，作为资产就要通过运营以达到其最大化的收益。为了体现数据的价值，需要从数据的正确性、时效性、安全性、全面性、完整性上建立数据运营体系，通过设置相关指标以可视化的方式完成相关统计和展示，以达到数据管理到数据资产管理的提升。如何对数据资产管理的流程性、安全性和有效性进行保障需要我们对已有的组织架构和管理制度进行调整。
4、安全保护重要化
2018年欧盟提出的GDPR法案以及我国近些年提出的《数据安全法》、《个人信息保护法》《个人金融信息（数据）保护试行办法》等，主要是对数据使用和流动提出了一些要求，比如个人数据敏感界定问题、数据匿名化问题、数据地图应用问题、数据角色问题。
这些问题需要我们在数据的加工设计上要采用一定的分离措施，达到最小化目的；在数据访问的设计上结合个人敏感信息的要求进行差异化对待，实现数据保护。在数据生命周期的设计上，对信息的“收集、传输、存储、使用、删除、销毁”等每一个环节做好分类分项的规划。整个上述内容需要我们在数据架构的管控上做好敏感数据识别和数据等级分类指导，通过设立专业的数据保护管理组织，制定相应的流程、业务实践和策略，提升数据合规管理的能力。
5、数据治理场景化
传统的根据元数据管理为驱动或者以主数据管理为驱动开展数据治理工作，做不到全面的数据治理工作；以监管要求为出发点进行数据治理，治理的价值难以体现到实际业务端。
随着数据资产化的深入以及价值体现要求，数据要对业务进行赋能，所以我们需要从启动从数据服务的某个场景化里开展数据治理，结合已有的元数据或主数据治理方案，两头并进，持续开展，逐步提升数据价值。
1、数据库能力紧跟发展变化
农行信息系统建设经历了几十年，以数据流程进行划分，数据生产系统主要以联机交易为主，这些系统用户群体大，业务量大，对交易的响应速度有要求，最开始使用Sybase ASE，随着应用的并发要求越来越高，引入了Oracle，结合自主可控的发展要求，引入了开源的MySQL数据库以及相关商业组件。为了进一步的提高响应速度，行内进一步的使用了一些开源的内存数据库，比如Redis、MemCache等，拓展了系统的应用支持能力。数据消费系统，主要是农行在大数据计算及分析领域的相关应用系统，结构化的数据库方面最开始使用Sybase IQ，随着大数据计算的升级，引入了MPP架构的数据库GBASE，并结合Hadoop生态开展相关计算及存储，同时建设数据中台对外提供数据服务。非结构化方面主要采用Hadoop生态以及ElasticSearch生态开展相关工作。随着业务的进一步发展，为满足应用的快速开发，实现对用户透明、按需无感扩容，支持应用级的隔离等要求引入了MongoDB，同时为满足客户营销（获客）、反洗钱模型、信用卡虚假申请，信贷风险监控等等大数据量关系建模、实时复杂关系遍历查找需求,引入了图数据库。
2、数据架构管理双管齐下
农行目前建设了数据架构管理系统，实现了企业级数据模型的全流程管理，涵盖基础数据项、概念模型、逻辑模型，通过基础数据项的复用，实现数据标准的落地实施，提高数据标准化水平，提升数据间一致性，落地实施了《中国农业银行软件开发中心应用系统数据模型设计与开发指引》。目前该系统中已经实现了主机DB2，Oracle,开放DB2，GBASE，HBASE以及MongoDB等多种数据库类型的模型设计及管理。同时农行建设元数据管理系统，一方面以数据模型为枢纽，将数据治理与数据应用结合起来，强化数据标准的落地执行，在数据应用过程中发现问题、推动治理、提升质量。另一方面打造了企业级的数据资产管理统一视图，向农行全体用户或分析挖掘平台等各管理应用提供全面、稳定、统一的数据资产服务，满足目前大数据时代下的元数据需求，从而提高对数据的管理、使用、质量管理、贯标等工作能力。
3、数据安全管理合规开展
目前农行已经以数据保护影响评估（DPIA）为切入点，在项目全流程实施隐私数据保护，降低数据风险。首先在系统需求阶段需要参照GDPR（通用数据保护条例）要求，对收集或处理欧盟区个人数据等敏感事项，是否进行了数据保护影响评估，其次农行建设了个人数据标识平台，结合数据架构管理系统对涉及个人信息字段进行安全级别标识，产生的数据内容将作为个人信息保护和安全控制的依据，为行内各系统开发、数据使用的过程当中提供相应的数据安全服务。
数据决策能力体现了一个企业数字化转型的程度，如何让数据更好的支持业务开展、服务决策制定这是数字化转型的目标。数据架构的设计和管理是业务、数据、技术融合的产出物，要解决“烟囱式重复”，做好“服务能力的沉淀”，实现数据服务的组件化、平台化和共享化，体现出数据作为生产要素的价值。
