基于数据中台的建筑企业数据治理探索与实践

文｜中国建筑一局（集团）有限公司信息部 周志萍 蒋圣平 于旭旭 袁哲

0 引言

随着数据被国家列为生产要素[1]，数据的价值日益彰显，数据的治理工作成为推动大数据与实体经济深度融合、助力经济转向高质量发展阶段的重要内容。建筑施工行业也积极推进数字化转型，在集团运营和项目现场管理等方面实施了不少业务系统，如项目管理平台、财务管理平台、智慧工地集成平台等。这些业务系统的实施厂商众多，大多数是分期建设、间隔时间长、缺少标准、功能模块之间相对独立，在企业内部形成多个“数据孤岛”，并且指标在定义和计算逻辑上可能各不相同，无法真正实现数据的开放共享，导致建筑行业虽有大量数据，但数据利用率低，无法发挥数据的价值。建筑企业的全域数据具有明显的大数据5V 特征[2]：数据量大（Volume）、数据种类和来源多样化（Variety）、数据增长快且分析处理和实效性高（Velocity）、数据准确性要求高（Veracity）、潜在的数据价值高（Value）。建筑行业的软件厂商也关注数据应用，但往往局限于自身软件模块数据的治理和挖掘，甚至没有建立专门的数据仓库。笔者单位基于传统的数据仓库架构建立数据分析中心，解决企业内部集团层面项目管理、资源管理等信息系统的数据治理问题，在集团管控层面提升了数据的应用和价值[3]，但无法应对大数据量计算、非结构化数据集成等问题。总体而言，在建筑企业仍没有一个成熟的解决方案实现从集团到项目间全域的数据治理和数据共享。

互联网的发展让我们可以收集和获取的数据以不可预计的速度增长，大数据的分析及其应用成为了一大科研热点。2008年，Hadoop 分布式处理软件成为Apache开源基金会的顶级项目，互联网行业率先采用基于Hadoop 分布式计算框架进行企业级数据处理，其分布式和高容错等特性使得企业可以使用廉价的普通服务器构建大规模集群，提高数据的处理能力。阿里巴巴提出的数据中台概念[4]，将数据统一化、工具组件化、应用服务化，极大的屏蔽了大数据技术本身的复杂性，在电力、教育、金融等行业得到了很好的应用[5-7]。

针对建筑企业全域的数据治理现状，结合数据中台技术的发展，本文探索性的将数据中台引入到建筑行业全域数据的治理中，并提供全域数据治理和数据共享解决方案，对比了数据中台架构和传统数据仓库架构的优缺点，为企业在数据治理方案选择提供参考。

1 基于数据中台的数据治理解决方案

1.1 总体架构

数据中台基本功能包括数据采集、数据清洗、数据转换与数据同步等[8]。部分数据中台产商引入数据资产管理理念，在数据中台产品中设计了数据标准、数据质量、数据安全、数据价值、数据共享管理等功能[9]。结合建筑企业特点，设计架构如图1所示。

图1 数据治理架构图

1.2 数据采集方案

数据采集指从企业内外获取数据的过程，数据包括结构化数据，如数据库表数据、半结构化数据如Excel、XML、JSON 数据和非结构化数据如网页、文档、视频、图片等。针对数据源的不同，采集方案如下：

（1）数据库采集

企业内部业务系统的数据大多存储在数据库中，数据采集只需通过配置ODBC/JDBC 链接，即可实现数据同步到Hadoop。数据中台产品基本都配置相应插件，通过简单配置，即可实现数据采集。

（2）半结构化数据采集

建筑企业内一些数据仍存在Excel 台账管理，此外，以API 方式从外部获取一些公共数据如天气信息，返回的格式通常是JSON 或XML。针对这些半结构化数据，数据中台产品提供内嵌Python/Shell 脚本，通过自定义编写Python/Shell 程序实现半结构化数据采集。

（3）网络数据采集

如果网络数据不能以API 方式提供，可使用Python 开发爬虫程序或者选择专门的RPA（Robotic Process Automation）工具，实现将网络数据抓取到本地的业务数据库，然后利用数据中台产品通过数据库采集方式同步到Hadoop。

（4）文档、图片、视频类采集

针对文档/图片/视频等文件的大数据处理，需要在文件同步到大数据平台后，基于Python 程序开发。以视频为例，通过Python 加载视频后，对视频进行分帧处理，运用合理的模式识别算法，提取图片有用信息，转换为业务场景需要的数据模型,将结果保存到数据库。

在数据采集阶段，根据数据时效性的不同要求，可采用离线采集和实时采集进行。对时效性要求不高的数据，通过全量或增量的方式按天或者按小时等进行数据同步，实现大批量数据的周期性迁移；对低时延、高时效的流数据应用场景，通过读取日志或消息通知的方式，来实现数据的实时处理。

1.3 数据开发方案

1.3.1 建立数据仓库模型

尽管数据中台架构不同，但数据仓库建模方法还是一致的，推荐以维度建模搭建企业数据仓库模型[10]。维度建模以分析决策的需求出发，根据不同维度和主题域建立数据模型。数据仓库模型设计后，需要利用数据中台产品创建物理数据仓库。

1.3.2 数据治理开发

（1）离线数据治理开发

离线数据治理采用分层处理，将复杂问题简单化，减少重复开发，降低对业务变更的影响。数据分层开发从下到上可分为：操作数据层(ODS：Operation Data Store)、数仓明细层(DWD：Data Warehouse Detail)、数仓汇总层(DWS：Data Warehouse Summary)、应用数据层(ADS:Application Data Store)、公共维度层(DIM:Dimension)、数据应用层，整体的数据分层开发模型如图2所示。

图2 离线数据开发分层架构

图中，ODS 层提供了对原始数据的备份，避免直接调用业务系统的数据；DWD层对ODS 层的数据进行过滤、清洗、转换，形成最细粒度的明细表；DWS 层将DWD层的明细数据，按照不同维度、不同粒度进行汇总聚合，构建命名规范、口径统一的统计指标，形成不同业务需求的汇总表；ADS 层对DWD 层或DWS 层数据进行个性化加工、数据汇总，形成某一个主题域的服务数据，为数据应用提供数据支持；DIM层整合不同业务系统的维度相关信息，建立统一的标准的企业维表；数据应用层同步ADS 层的交易数据和DIM 层的维度数据到关系型数据库，面向最终应用。

（2）实时数据治理开发

实时数据治理逻辑简单，但特别消耗资源，总体开发过程如图3所示。

图3 实时开发流程

实时采集通过读取数据库中的日志，利用数据抽取插件解析日志，逐条读取各种数据库操作，以流式数据的方式记录到Kafka；Flink 作为实时计算的计算引擎，以SQL 的形式处理Kafka 中的流式数据：将Kafka 中的数据映射为源表，然后通过Flink 计算引擎以及特定的数据计算逻辑，完成对实时数据的分析处理，并将数据输出到数据库中。

1.4 数据共享服务

数据共享将数据变为一种服务能力，主要包括以下3 种方式：

（1）API 方式

开发服务接口，发布到API 市场后，企业内外部的人员可以授权申请使用，最终实现企业内外的数据共享。

（2）数据库同步

数据库同步提供面向目标数据源的跨数据源类型转换的数据同步能力，实现直接向目标数据库表以增量或全量的方式推送数据，主要用于企业内部的数据交换。

（3）多租户模式

多租户模式让所有子企业共享集团统一的数据中台及大数据平台。考虑到Hadoop 集群资源和多任务并行，多租户使用时，需实现多重隔离：

逻辑隔离。从租户的角度出发，每个租户都有独立的逻辑模型，拥有独立的资源以及基于相同的逻辑模型实现的统一授权模型。

资源隔离。对于不同租户的任务，在集群运行时，能够实现统一的、全局最优的任务调度能力以及资源隔离能力。

运行隔离机制。用户任务请求运行在yarn 调度上，相互无影响，各进行隔离。

2 应用效果分析

笔者单位于2019年采用传统数据仓库架构，成功实施数据分析中心项目。为了更好探索大数据在建筑企业的应用，在2021年申请并实施基于数据中台的数据治理科研课题。实践表明，相比传统的数据仓库架构（以商用ETL 工具SAP Data Services为例），基于数据中台架构（以数栈为例）的数据治理主要有如下优缺点：

2.1 功能方面

数据源：数据中台支持更多数据源，无缝对接处理大数据产品，ETL 工具对大数据产品的支持不够；数据中台产品不能直接对关系型数据库增删改查，ETL 工具可以自由操作。

离线开发：数据中台产品支持Python/Shell/Spark 等多种工具开发，易于扩展；传统的ETL 工具在逻辑控制（如控制数据流是否抽取、循环抽取等）更灵活。

实时开发：数据中台产品通过Kafka、Flink 等实现实时开发；ETL 工具不支持。

数据共享：传统的ETL 工具仅支持数据库同步，不具有API 和多租户模式功能。

版本管理：数据中台产品有良好的版本管理和团队协作功能；ETL 工具较差。

其他：数据中台产品功能更全，集成数据资产管理，提供可视化分析如数据地图、价值分析等；ETL 工具不支持。

2.2 性能方面

通过对比3000 万条和6000 万条SAP凭证进行数据治理，数据中台架构数据加载到HIVE，ETL 架构加载到Oracle。设计两种业务场景：场景一是对凭证进行简单的数据转换操作（减少输出字段、更改日期类型、过滤无效记录）；场景二是对凭证进行复杂的业务处理，生成项目的营业收入、监理批量等关键财务指标。测试环境：数据中台架构，数据中台服务器2 台，数据节点3 台；传统数据仓库架构，ETL 服务器1 台，数据仓库服务器一台。对比结果如表1所示。

从表1可知，简单的凭证清洗操作，相比传统ETL 工具，数据中台架构在3000万记录提升35.6%，6000 万记录提升50%；复杂的逻辑转换，数据中台架构在3000 万记录提升43.8%，6000 万记录提升66.7%。此外，针对复杂逻辑处理，数据中台架构在数据量增大后，耗时增长为12.9%，也远远低于传统ETL 工具的耗时增长48.4%。可见，数据中台架构在大数据量的处理方面，性能优势明显，而且数据量越大，性能差异越大。

表1 数据中台架构和传统ETL 架构处理性能结果对比

3 结论

针对建筑企业的全域数据，传统的数据仓库架构在进行数据治理时存在很多问题和挑战，这与大数据的本质特征密不可分。本文提出的数据中台架构数据治理方案，可集成各种数据类型的数据源，支持实时和离线数据治理，提供灵活的数据共享服务，测试结果表明数据中台架构在大数据处理方面性能优势明显，而且随着数据量的增长可灵活扩展，能够满足建筑企业全域数据的数据治理。下一步，将聚焦建筑企业大数据潜在价值的挖掘及更多实际场景的应用。