说到数据工程，给人的感觉往往是空间数据的采集、核查、规整、入库等过程。这些过程，距离主流IT所说的“数据工程”还是有些差异的。
主流IT对“数据工程”的定义是：“以工程化作为基本出发点的数据处理、分析和应用方法与技术，是计算机科学与技术学科的重要内容、核心与趋势”。
在这个定义中，特别强调了“工程”两个字。“工程”是以解决问题、实现价值为导向的，往往受限于具体业务场景，通常需要综合权衡考虑，并具有实践性较强的、需要与用户反复交互的“服务”方式，而不是以市场为导向的“产品”模式。
一、需不需要全局性数据架构?
很多人会说，“我们只是做数据处理、数据迁移等，不需要数据架构”、“我们只是做数据分析展现，其他事情不需要考虑那么多”……
如果站在项目实施的某个局部角度，只需考虑某项数据处理工作的局部范围和具体要求的话，确实可以这么说。但是，如果站在项目全局的角度，或项目规模较大，就不得不从全局视角统筹考虑数据工程了。否则，就会出现各种各样的问题。比如，产生“数据孤岛”、数据之间无法关联、数据统计结果是否真实可信等问题。
二、在什么阶段考虑全局性数据架构?
还有一种观点比较常见：“我们只是做业务系统，暂时不考虑分析类应用，在以后搭建商务智能(BI)、数据仓库应用时，我们再来考虑数据架构”。
如果只有少数几个业务系统，是否有独立的数据架构，影响可能不大。但是，如果业务系统累积到五个以上时，这种“重系统轻数据”、“重流程轻分析”的导向，会带来很多问题。没有统一的数据架构和数据治理机制，多个系统之间会出现数据标准不统一，数据内容不一致，数据同名不同义和同义不同名等现象，数据质量无法保证，数据集成非常困难，必然影响业务应用系统效能的正常发挥。如果业务系统本身数据质量就有问题，即使数据抽取处理、数据分析展现系统做得再好，也是枉然。所以，对于大型的、复杂的业务应用系统，必须考虑全局的数据架构;至于数据分析型应用，没有数据架构和数据治理机制，将寸步难行。
三、全局性数据架构怎么做?
做全局性数据架构，就是要回答用户的问题：用户的数据资产应该如何组织，才能管得住、用得好?针对这个问题，可以从数据资源目录、数据标准、数据模型、数据分布等多个维度加以考虑。在具体落地时，还要考虑元数据管理、数据集成、数据共享等要素。下图是我们在某个具体项目中的全局性数据架构设计考虑。
某项目的全局数据架构逻辑图
从全局整体角度，把数据按照应用方向，划分几个库：
1、业务库
在“业务应用域”，主要面向的是“业务办理人员”。从数据角度，一个库里有多个数据域，与其相对的，一个平台多个应用，即一个业务平台上面承载多个业务应用，整个“业务应用域”就是一个系统一个库，从根本上解决以前十几个系统十几个库而导致的“烟囱系统”的问题。另外，这个业务库的数据组织形式，是以“办理事项”进行数据建模组织的，数据操作主要是数据增、删、改、查，属于典型的事务性数据库(OLTP)。
2、分析库
在“数据分析域”中，主要面向的是“分析决策人员”。因此，需要建立数据仓库。数据仓库根据不同应用场景分层，包括：操作性数仓(ODS)、核心数仓(DW)、数据集市(DM)等，同样与之相对，搭建相应的“数据应用平台”和一系列的数据应用。分析库按照“分析主题”组织数据。所谓“分析主题”，就是针对某种业务对象或者某个事项的分析需求，比如建设项目情况分析、房源筹集和分配情况分析等。
3、治理库
顾名思义，“数据治理域”主要面向“数据治理人员”。通过数据治理，管理好全局的所有数据。其中，“主数据”是按照“核心业务对象”组织的数据，它提供可共享的核心数据底板，具有统一、完整、准确、及时的特点。比如，在公共住房领域，房源就是一种主数据。“元数据”则用来对数据进行描述的数据，包括数据的类型、关系、流动、变化(血缘)和业务含义等。“参考数据”是指一些重要的数据字典，比如，在公共住房领域，租赁状态、出册原因、交租方式、房屋状态等，都需要采用字典来描述。
4、其他库
除以上核心库外，还有一些其他数据。包括：用于内外数据交换的交换数据，用于空间定位和空间分析的空间数据，以及各种文档材料、电子档案等非结构化数据等。
全局性数据逻辑架构的最大价值在于：从全局上搞清楚有哪些数据?数据和系统之间、不同类型的数据之间，存在什么关系?各种不同数据是怎么存储管理的?除此之外，数据架构还包括：数据模型，它从静态视角，描述数据之间的具体关系，指导后续数据库的逻辑设计、物理设计;数据分布，它从动态视角，描述数据在业务应用系统上的分布、数据流动的全景视图等。由于篇幅所限，在此不一一列举。
