一种民航数据管理平台及方法

摘要

本申请提供一种民航数据管理平台及方法，该平台包括：交换中心，与外部系统通信连接，治理中心，用于接收所述交换中心获取的所述民航业务数据；所述治理中心包括主题治理模块，所述主题治理模块用于基于预设的主题划分规则对所述民航业务数据进行归类；存储中心，包括前置主题区，所述前置主题区用于存储所述治理中心对所述民航业务数据进行归类后的主题数据。在本申请实施例中，通过治理中心的主题治理模块可以实现对民航业务数据的归类，进而使得相关联的业务实体归为一个主题，相关联的主题同属于一个主题域，通过该方式实现了对数据更加科学的治理，进而通过该平台可以提供更加便捷的服务。

权利要求

1.一种民航数据管理平台，其特征在于，包括：交换中心，与外部系统通信连接，所述外部系统包括上游系统和下游系统，所述交换中心用于获取所述上游系统的民航业务数据，及将治理后的数据发送至所述下游系统；

治理中心，用于接收所述交换中心获取的所述民航业务数据；所述治理中心包括主题治理模块，所述主题治理模块用于基于预设的主题划分规则对所述民航业务数据进行归类；其中，所述主题划分规则的层次包括主题域、主题及业务实体；每个所述主题域包括至少一个所述主题；每个所述主题包括至少一个所述业务实体；

存储中心，包括前置主题区，所述前置主题区用于存储所述治理中心对所述民航业务数据进行归类后的主题数据；

其中，所述民航数据管理平台还包括计算引擎，所述计算引擎的内部底层采用开源的Flink框架；所述Flink框架的基础单元为Job，一个Job包含至少一个Flow，每个Flow对应一个处理通道；不同的Flow可用于并行处理不同的业务；所述处理通道采用管道‑过滤器模式；所述处理通道包括Source单元、Processor单元及Sink单元；其中，所述Source单元作为所述处理通道的输入端，用于接收所述民航业务数据，所述Processor单元作为处理数据的过滤器；其中，通过增设所述Processor单元以增设所述民航数据管理平台的业务，所述Sink单元作为所述处理通道的输出端，用于将处理后的数据进行存储或共享；所述Processor单元具体用于将所述民航业务数据进行抽象，生成抽象数据；并基于预设的映射规则将所述抽象数据转为抽象主题模型的模型对象；其中，所述抽象主题模型包括根对象；

每个所述根对象对应一个主题，所述根对象包括元数据、基础信息及业务实体；每个所述抽象数据对应所述抽象主题模型的一个业务实体；

所述治理中心还包括多源处理模块；所述多源处理模块用于基于预设的优先级规则对所述民航业务数据进行筛选，以去除所述民航业务数据中的重复数据；其中，所述优先级规则包括上游系统优先级和/或数据字段优先级。

2.根据权利要求1所述的民航数据管理平台，其特征在于，所述多源处理模块还用于基于所述预设的优先级规则对所述归类后的主题数据进行筛选，以得到目标主题数据；所述目标主题数据为所述归类后的主题数据去除重复主题数据之后的剩余主题数据；

相应的，所述存储中心还包括细节主题区，所述细节主题区用于存储所述目标主题数据。

3.根据权利要求1所述的民航数据管理平台，其特征在于，所述交换中心通过数据探针获取所述上游系统的民航业务数据，所述数据探针包括：消息数据探针、API数据探针及文件数据探针；

所述消息数据探针、所述API数据探针及所述文件数据探针在获取到所述民航业务数据后，将所述民航业务数据添加至所述交换中心的交换队列；

相应的，所述存储中心还包括贴源区；所述贴源区用于存储所述交换队列中的数据。

4.根据权利要求3所述的民航数据管理平台，其特征在于，所述数据探针还用于为所述民航业务数据添加消息头元数据；

所述消息头元数据包括：数据ID、数据源系统归属的组织、数据来源的上游系统、所述数据探针对接的采集数据源及获取到所述民航业务数据的时间戳。

5.根据权利要求1所述的民航数据管理平台，其特征在于，所述治理中心还包括数据处理模块；

所述数据处理模块用于在所述主题治理模块对所述民航业务数据进行归类之前通过APT工具对所述民航业务数据进行数据验证。

6.根据权利要求1所述的民航数据管理平台，其特征在于，所述Processor单元还具体用于获取所述下游系统的样式文件，基于所述样式文件，将样式数据进行抽象，生成抽象样式数据，并基于所述预设的映射规则将所述抽象样式数据转为抽象主题模型的模型对象；

其中，所述抽象样式数据为所述民航业务数据中与所述样式文件所对应的数据；

相应的，所述Sink单元还用于将经所述Processor单元对所述抽象样式数据进行归类后的主题数据发送至该下游系统。

7.一种民航数据管理方法，应用于服务器，所述服务器中搭载如权利要求1所述的民航数据管理平台，其特征在于，所述方法包括：通过所述交换中心获取所述上游系统的民航业务数据；

通过所述治理中心接收所述民航业务数据，并基于预设的主题划分规则对所述民航业务数据进行归类；

通过所述存储中心存储所述治理中心对所述民航业务数据进行归类后的主题数据。

说明书

一种民航数据管理平台及方法

技术领域

[0001] 本申请涉及数据管理技术领域，具体而言，涉及一种民航数据管理平台及方法。

背景技术

[0002] 随着航天技术的发展与进步，目前航空业务显著增多，民航空管局在生产运行和职能管理过程中产生大量的数据。同时，民航空管局的生态合作伙伴如航司、机场也会在业
务运行中产生大量的数据。数据逐渐成为了支撑各系统运行的核心资产。为提高对各系统
的数据的管理及提高空港地面交通的服务效率和质量，必然面临各系统的数据梳理和汇
聚，因此，数据管理平台应运而生。但是，目前的数据管理平台仅仅能够实现数据的收集和
存储，功能单一，并不能够提供更加便捷的服务。

发明内容

[0003] 本申请实施例的目的在于提供一种民航数据管理平台及方法，以实现对数据的归类，进而完成对数据更加科学的治理，提供更加便捷的服务。

[0004] 本发明是这样实现的：

[0005] 第一方面，本申请实施例提供一种民航数据管理平台，包括：交换中心，与外部系统通信连接，所述外部系统包括上游系统和下游系统，所述交换中心用于获取所述上游系
统的民航业务数据，及将治理后的数据发送至所述下游系统；治理中心，用于接收所述交换
中心获取的所述民航业务数据；所述治理中心包括主题治理模块，所述主题治理模块用于
基于预设的主题划分规则对所述民航业务数据进行归类；其中，所述主题划分规则的层次
包括主题域、主题及业务实体；每个所述主题域包括至少一个所述主题；每个所述主题包括
至少一个所述业务实体；存储中心，包括前置主题区，所述前置主题区用于存储所述治理中
心对所述民航业务数据进行归类后的主题数据。

[0006] 在本申请实施例中，通过治理中心的主题治理模块可以实现对民航业务数据的归类，进而使得相关联的业务实体归为一个主题，相关联的主题同属于一个主题域，通过该方
式实现了对数据更加科学的治理，进而通过该平台可以提供更加便捷的服务。

[0007] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述治理中心还包括多源处理模块；所述多源处理模块用于基于预设的优先级规则对所述民航业务数据进
行筛选，以去除所述民航业务数据中的重复数据；其中，所述优先级规则包括上游系统优先
级和/或数据字段优先级。

[0008] 在本申请实施例中，治理中心还包括多源处理模块，通过多源处理模块可以对重复数据进行筛选，对偏差数据进行整合，进而保证最终数据的一致性和正确性。同时，多源
处理模块支持系统优先级和/或数据字段优先级的配置，满足各种场景下的多源处理需求。

[0009] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述多源处理模块还用于基于所述预设的优先级规则对所述归类后的主题数据进行筛选，以得到目标主题
数据；所述目标主题数据为所述归类后的主题数据去除重复主题数据之后的剩余主题数
据；相应的，所述存储中心还包括细节主题区，所述细节主题区用于存储所述目标主题数
据。

[0010] 在本申请实施例中，多源处理模块还用于基于预设的优先级规则对归类后的主题数据进行筛选，以得到目标主题数据。通过该方式使得同一类型的主题数据只会有一条数
据，进而保证了细节主题区的主题数据的唯一性和完整性。

[0011] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述交换中心通过数据探针获取所述上游系统的民航业务数据，所述数据探针包括：消息数据探针、API数
据探针及文件数据探针；所述消息数据探针、所述API数据探针及所述文件数据探针在获取
到所述民航业务数据后，将所述民航业务数据添加至所述交换中心的交换队列；相应的，所
述存储中心还包括贴源区；所述贴源区用于存储所述交换队列中的数据。

[0012] 在本申请实施例中，通过消息数据探针、API数据探针及文件数据探针可以获取到不同格式的数据。此外，贴源区由交换队列形成，也即，将交换队列作为一个内存缓存加高
性能数据库，进而可以短时间的存储原始数据，以便于平台其他模块的利用。

[0013] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述数据探针还用于为所述民航业务数据添加消息头元数据；所述消息头元数据包括：数据ID、数据源系统
归属的组织、数据来源的上游系统、所述数据探针对接的采集数据源及获取到所述民航业
务数据的时间戳。

[0014] 在本申请实施例中，通过添加消息头元数据，可以保证数据的可追溯性，以及便于后续数据的管理。

[0015] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述治理中心还包括数据处理模块；所述数据处理模块用于在所述主题治理模块对所述民航业务数据进行
归类之前通过APT工具对所述民航业务数据进行数据验证。

[0016] 在本申请实施例中，通过APT工具可以减少代码的侵入，使得开发者可以无感知，自动的完成验证代码的生成以及对民航业务数据的数据验证。

[0017] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述民航数据管理平台还包括计算引擎，所述计算引擎的内部底层采用开源的Flink框架；所述计算引擎的
处理通道采用管道‑过滤器模式；所述处理通道包括Source单元、Processor单元及Sink单
元；其中，所述Source单元作为所述处理通道的输入端，用于接收所述民航业务数据，所述
Processor单元作为处理数据的过滤器，所述Sink单元作为所述处理通道的输出端，用于将
处理后的数据进行存储或共享。

[0018] 在本申请实施例中，计算引擎所有的处理数据过程均可以通过Processor单元实现，在管道‑过滤器模式中可以设置一个或多个Processor单元，进而在后续业务的开发过
程中，若需要增设一个业务，仅需增设一个Processor单元即可，通过该方式，可以实现以最
小的开发量完成业务的开发和运行，且该方式支持数据计算能力的水平扩展，即基于Flink
框架，可以并行执行多个通道，每个通道均包括Source单元、Processor单元及Sink单元。

[0019] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述Processor单元具体用于将所述民航业务数据进行抽象，生成抽象数据；并基于预设的映射规则将所述
抽象数据转为抽象主题模型的模型对象；其中，所述抽象主题模型包括根对象；每个所述根
对象对应一个主题，所述根对象包括元数据、基础信息及业务实体；每个所述抽象数据对应
所述抽象主题模型的一个业务实体。

[0020] 在本申请实施例中，对民航业务数据进行抽象，生成抽象数据。且该抽象数据与抽象主题模型的业务实体所匹配，通过该方式实现对数据的统一处理，完成数据到主题模型
的转换。此外，抽象主题模型采用“树”的 形式，一个根对象代表一个主题，有利于为根对象
定义对外的属性。此外该方式业务独立性强，高内聚、封装性好。抽象主题模型可以支持不
断的延伸。

[0021] 结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述Processor单元还具体用于获取所述下游系统的样式文件，基于所述样式文件，将样式数据进行抽象，生
成抽象样式数据，并基于所述预设的映射规则将所述抽象样式数据转为抽象主题模型的模
型对象；其中，所述抽象样式数据为所述民航业务数据中与所述样式文件所对应的数据；相
应的，所述Sink单元还用于将经所述Processor单元对所述抽象样式数据进行归类后的主
题数据发送至该下游系统。

[0022] 在本申请实施例中，通过下游系统的样式文件，对主题数据进行封装进而实现了不同需求的配置。

[0023] 第二方面，本申请实施例提供一种民航数据管理方法，应用于服务器，所述服务器中搭载如第一方面实施例所提供的民航数据管理平台，所述方法包括：通过所述交换中心
获取所述上游系统的民航业务数据；通过所述治理中心接收所述民航业务数据，并基于预
设的主题划分规则对所述民航业务数据进行归类；通过所述存储中心存储所述治理中心对
所述民航业务数据进行归类后的主题数据。

[0024] 第三方面，本申请实施例提供一种服务器，包括：处理器和存储器，所述处理器和所述存储器连接；所述存储器用于存储程序；所述处理器用于调用存储在所述存储器中的
程序，执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式
提供的方法。

[0025] 第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被处理器运行时执行如上述第一方面实施例和/或结合上述第一方面实
施例的一些可能的实现方式提供的方法。

附图说明

[0026] 为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看
作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以
根据这些附图获得其他相关的附图。

[0027] 图1为本申请实施例提供的一种民航数据管理平台与外部系统交互的示意图。

[0028] 图2为本申请实施例提供的另一种民航数据管理平台与外部系统交互的示意图。

[0029] 图3为本申请实施例提供的一种Flink框架的结构示意图。

[0030] 图4为本申请实施例提供的一种抽象消息模型的结构示意图。

[0031] 图5为本申请实施例提供的一种抽象主题模型的结构示意图。

[0032] 图6为本申请实施例提供的一种消息出口的过程示意图。

[0033] 图7为本申请实施例提供的一种民航数据管理方法的步骤流程图。

具体实施方式

[0034] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

[0035] 请参阅图1，本申请实施例提供一种民航数据管理平台。该平台包括：交换中心、治理中心及存储中心。

[0036] 其中，交换中心与外部系统通信连接。

[0037] 外部系统包括上游系统和下游系统，交换中心用于获取上游系统的民航业务数据，及将治理后的数据发送至下游系统。

[0038] 需要说明的是，上游系统为数据流出的系统，当数据的传输路径为系统A传输至民航数据管理平台，则系统A为上游系统。上游系统可以是，但不限于ACDM（Airport‑
Collaborative Decision‑Making，机场协同决策）系统、CDM（Collaborative Decision‑
Making，协调决策）系统、出舱系统。上游系统还可以是一些网站，应用程序所对应的服务
器，本申请不作限定。

[0039] 下游系统为数据流入的系统，当数据的传输路径为民航数据管理平台传输至系统B，则系统B为下游系统。下游系统可以是，但不限于旅客服务系统、航班监控系统。

[0040] 治理中心，用于接收交换中心获取的民航业务数据。治理中心包括主题治理模块，主题治理模块用于基于预设的主题划分规则对民航业务数据进行归类。

[0041] 其中，主题划分规则的层次包括主题域、主题及业务实体。每个主题域包括至少一个主题；每个主题包括至少一个业务实体。即按照业务实体的相关性，将其划分为同一主
题，再根据主题的相关性，将其划分为同一主题域。

[0042] 示例性的，主题域可以包括机场信息、人员信息；主题可以包括航班主题、机场员工主题、旅客主题；业务实体包括航班号、飞机起飞时间、旅客姓名、旅客性别等，本申请不
作限定。

[0043] 上述划分满足以下原则：1.同一层次的分类处于同一个抽象层次。2.分类按照业务相关性进行划分。3.分类满足业务的正交性。

[0044] 需要说明的是，业务的正交性表示不同主题下的业务实体不相交，不同主题下的业务实体互不影响。如针对航班主题和机场员工主题可能都包括机长信息，而为了满足业
务的正交性，将机长信息归属于机场员工主题，进而避免业务实体的重复出现，通过该方式
有利于后续平台的维护与更新。

[0045] 存储中心，包括前置主题区，前置主题区用于存储治理中心对民航业务数据进行归类后的主题数据。

[0046] 前置主题区可以使用NoSQL（Not  Only  SQL，非关系型数据库）数据库ElasticSearch（一种搜索引擎）进行存储，其允许追加数据，无论交换中心采集到的数据在
业务上是新增、修改、删除，在前置主题区都是追加数据，如此即可完整地保存治理后主题
数据的历史轨迹。在追加主题数据时，需要根据数据类型确定每条主题数据的Delta标志，
用以标记该数据的操作类型。

[0047] 综上，在本申请实施例中，通过治理中心的主题治理模块可以实现对民航业务数据的归类，进而使得相关联的业务实体归为一个主题，相关联的主题同属于一个主题域，通
过该方式实现了对数据更加科学的治理，进而通过该平台可以提供更加便捷的服务。

[0048] 请参阅图2，下面对本申请实施例所提供的民航数据管理平台进行详细说明。

[0049] 首先对交换中心进行说明，交换中心可以具体包括数据采集模块、数据发布模块及数据同步模块。

[0050] 数据采集模块主要用于通过数据探针获取上游系统的民航业务数据。通过选择不同的数据探针可实现不同场景的数据采集，及通过不同的数据探针可以获取到不同格式的
数据。数据探针可以独立于平台进行部署。根据采集的数据源协议、数据类型与性能需求的
不同，本申请实施例所提供的数据探针包括：消息数据探针、API（Application 
Programming Interface，应用程序接口）数据探针及文件数据探针。

[0051] 消息数据探针支持的数据格式包括但不限于XML（Extensible Markup Language，可拓展标记语言）、JSON（JavaScript Object Notation，JS 对象简谱）、报文等。消息数据
探针会通过分布式的实时流处理平台订阅消息，一旦消息到达即可实时采集，并将采集后
的消息（民航业务数据）发布到交换中心的交换队列。

[0052] API数据探针面向HTTP（Hyper Text Transfer Protocol，超文本传输协议）协议类（WebService、RestFul）接口，API数据探针可以通过一定频率以轮询方式主动获取数据
源的数据，支持的数据格式包括但不限于XML、JSON、报文等，获取民航业务数据后会即时将
其发送到交换中心的交换队列。

[0053] 文件数据探针面向的数据源主要针对非结构化数据，包括图片、文本、CSV（Comma‑Separated Values，逗号分隔值）、DBF（Digital Beam Forming，数字波束合成）等文件。这
类文件数据被探针采集后，可以直接发送到非关系型存储系统，也可以根据文件类型的不
同，通过读取文件内容作为消息发送到交换队列。

[0054] 此外，为了保证数据的可追溯性，以便于后续数据的管理。上述的数据探针还用于为民航业务数据添加消息头元数据。

[0055] 消息头元数据包括：数据ID（Identity document，身份标识号码）、数据源系统归属的组织、数据来源的上游系统、所述数据探针对接的采集数据源及获取到民航业务数据
的时间戳。

[0056] 其中，数据ID采用Snow Flake算法，保证数据ID在整个民航数据管理平台中的唯一性。数据源系统归属的组织包括机场、航司、航科院等。数据探针对接的采集数据源表示
数据探针直接对接的数据源，如网站。

[0057] 数据发布模块负责将民航数据管理平台已经处理好的数据以消息推送、服务发布、短信推送等形式发布给需要数据的下游系统。数据发布形式采用推送形式，会将数据发
布到交换中心的交换队列，下游系统通过订阅消息的形式获得数据；若采用服务发布形式，
则以微服务方式对外公开。

[0058] 数据同步模块主要负责完成数据的同步。主要分为增量同步策略与全量同步策略。

[0059] 增量同步策略：民航数据管理平台的存储中心记录了所有记录的完整时间序列，因而可以通过两次不同任务之间的时间差异获取增量变更的数据来完成增量同步。针对数
据库数据源的增量同步，如果没有时间戳，则可以结合Log来还原整个数据库的数据变更记
录，从而获取增量变更的数据完成增量同步。

[0060] 全量同步策略：全量同步策略以新的全量数据为准，而不用考虑两次执行时数据的差异。

[0061] 由于上述的数据同步方式为本领域所熟知，因此，此处不作过多说明。

[0062] 下面对治理中心进行说明，治理中心除了包括主题治理模块，还可以包括多源处理模块及数据处理模块。

[0063] 交换中心获得的数据来自上游系统。对于交换中心所采集的数据中，除了增加了必要的消息头元数据之外，其余部分维持原样的数据，称之为“原始数据”。数据处理模块主
要用于对原始数据进行处理，以提高数据质量。数据处理模块可以具体用于数据验证、数据
过滤及数据标准化。

[0064] 执行数据验证的目的是避免非法无效的数据的进入，同时也可以减少不必要的处理逻辑。数据验证逻辑基于插件模式，可以很好地应对验证逻辑的变化。于本申请实施例
中，通过APT（Annotation Processor Tool，注解处理工具）工具对归类前的民航业务数据
进行数据验证。APT工具采用的是抽象语法解析树。通过APT工具可以减少代码的侵入，使得
开发者可以无感知，自动的完成验证代码的生成以及对民航业务数据的数据验证。

[0065] 数据过滤主要从业务角度进行过滤，如过滤特定的航站或航班的数据。

[0066] 数据标准化主要是将各个上游系统的数据转换为统一的协议对象的过程，经过数据标准化处理后的数据变得更加完整，同时消除数据的歧义性。

[0067] 多源处理模块用于基于预设的优先级规则对所述民航业务数据进行筛选，以去除民航业务数据中的重复数据。

[0068] 需要说明的是，如果数据平台接入的上游系统包含了多条针对相同业务相同场景发送相同主题的数据，则认为数据重复的现象；如果针对相同业务场景，不同的上游系统推
送的数据存在差异，则认为存在数据偏差的现象。引入多源处理功能，可解决数据重复和数
据偏差问题。

[0069] 于本申请实施例中，优先级规则包括上游系统优先级和/或数据字段优先级。

[0070] 示例性的，上游系统优先级可理解成对不同的上游系统划分等级，如系统A的划分等级高于系统B的划分等级，则当从系统A和系统B获取到相同的数据后，处理系统A的数据，
而将从系统B所获取的与系统A相同的数据删除。

[0071] 示例性的，数据字段优先级可理解成对不同的业务实体划分等级。比如系统A的旅客信息的划分等级高于系统B的旅客信息的划分等级，则当从系统A和系统B均获取到旅客
信息后，处理系统A的数据，而将从系统B所获取的旅客信息删除。

[0072] 此外，当优先级规则中同时包括上游系统优先级和数据字段优先级时，优先考虑数据字段优先级。数据是否为相同业务相同场景相同主题的唯一数据，可通过全局标识符
进行判断，每处理一条多源数据，都会记录该数据的历史信息，以帮助多源处理模块确定该
数据是否已经处理过。

[0073] 可见，通过多源处理模块可以对重复数据进行筛选，对偏差数据进行整合，进而保证最终数据的一致性和正确性。同时，多源处理模块支持系统优先级和/或数据字段优先级
的配置，满足各种场景下的多源处理需求。

[0074] 可选地，多源处理模块还用于基于预设的优先级规则对归类后的主题数据进行筛选，以得到目标主题数据；目标主题数据为归类后的主题数据去除重复主题数据之后的剩
余主题数据。

[0075] 下面对存储中心进行说明。于本申请实施例中，存储中心还包括细节主题区与贴源区。

[0076] 其中，细节主题区用于存储上述的目标主题数据。细节主题区使用NoSQL进行存储，在多源处理的支持下，针对同一种类型的同一条记录，只会出现一条记录，即它将针对
前置主题区的数据进行融合，从而保证了细节主题区主题数据的唯一性和完整性。

[0077] 贴源区用于存储交换队列中的数据。贴源区由交换队列形成，也即，将交换队列作为一个内存缓存加高性能数据库，进而可以短时间的存储原始数据，以便于平台其他模块
的利用。

[0078] 可选地，存储中心还可以包括：归档区、集市区及元数据区。

[0079] 归档区用于存储上游系统发送来的原始消息，这类数据主要用于数据的血缘关系查询、历史统计分析和海量数据挖掘等，同时提供原始数据的备份，保证在数据丢失的情况
下实现数据的恢复。由于历史数据具有生命周期长、数据格式种类多、数据量大、无需修改
等特点，这类数据除了添加元数据标签外，应按照原始消息格式进行存储。

[0080] 集市区面向业务系统的需求而创建，它需要的数据来自主题区（包括前置主题区和细节主题区）。集市区遵循星型模型的建模方法，将数据分为事实表与维度表，便于支持
后续的多维度分析，满足不同场景的统计分析需求。集市区选择MySQL进行存储。随着时间
推移，集市区的数据会变得越来越多。因此，可以对集市区定期备份和清除，或对集市区进
行分库分表，并引入ShardingSphere框架实现对分库分表的访问支持。

[0081] 元数据区用于存储数据中心的元数据，包括三种类型的元数据，即技术元数据、业务元数据和管理元数据。存储的元数据可用于血缘关系查询、数据审计，并帮助数据生产单
位有效的维护和管理数据。

[0082] 可选地，民航数据管理平台还包括开放中心。

[0083] 开放中心是数据对外开放的通道，根据数据开放能力与服务性质的不同，开放中心包括数据查询服务和OLAP（Online Analytical Processing，联机分析处理）分析服务。

[0084] 数据查询支持各种条件的查询与检索，包括全文本搜索。民航数据管理平台的归档区与主题区选择了ElasticSearch，自身支持半结构和结构化数据的联合查询，也支持中
文分词和全文检索。民航数据管理平台的集市区选择关系型数据库MySQL，它本身兼容国际
SQL92、SQL2003标准支持情况。

[0085] OLAP分析针对各个主题数据进行多维度分析，包括支持基于维度的钻取、指标统计、分类、聚合等统计分析操作。

[0086] 可选地，民航数据管理平台还包括资产中心。

[0087] 为了更好管理和掌握数据，需要对民航数据管理平台采集、存储和处理的数据进行数据资产梳理，建立资产中心。资产中心遵循数据资产管理实践，提供了主数据管理、元
数据管理功能，为数据平台定义数据标准，打造面向民航领域的企业数据资产，支持用户根
据数据标准和元数据对集市区进行数据建模。资产中心还提供了数据质量管理，可根据需
要生成数据质量报告。

[0088] 数据标准包括基础类数据标准和指标类数据标准。

[0089] 基础类数据标准：一般包括参考数据和主数据标准、逻辑数据模型标准、物理数据模型标准、元数据标准、公共代码和编码标准等，主要表现为民航各生产系统直接产生的原
始的未经数理计算的属性数据，如航班号、机号、航司、座位数、航线等。

[0090] 指标类数据标准：一般分为基础指标标准和计算指标（又称组合指标）标准。基础指标一般不含维度信息，且具有特定业务和经济含义，如延误航班数等。计算指标通常由两
个以上基础指标计算得出，如客座率、航班放行正常率等。

[0091] 按照数据标准化的相关原则和方法，对民航行业中主流的业务信息进行科学分类与编码，建立面向民航行业航司方向的数据标准规范，可以作为信息交换和共享的基础。

[0092] 元数据是描述数据的数据，按照用途，元数据可以分为技术元数据、业务元数据和管理元数据。

[0093] 技术元数据描述数据系统中技术领域相关概念、关系和规则的数据；包括地面保障数据平台内对象和数据结构的定义、源数据到目的数据的映射、数据转换的描述等。

[0094] 业务元数据描述数据系统中业务领域相关概念、关系和规则的数据；包括业务术语、信息分类、指标、统计口径等。

[0095] 管理元数据描述数据系统中管理领域相关概念、关系、规则的数据，主要包括人员角色、岗位职责、管理流程等信息。

[0096] 元数据管理是数据资产管理的重要基础，是为获得高质量的、整合的元数据而进行的规划、实施与控制行为。地面保障数据平台支持对主题区和集市区的元数据进行采集、
稽核和基本的管理功能，并允许对所有元数据进行查询。

[0097] 可选地，民航数据管理平台还包括管控中心。

[0098] 管控中心提供了数据平台的管理功能，用户对民航数据管理平台的操作主要通过管控中心。它主要针对整个平台进行管理和监控，包括配置管理、权限管理、身份验证、资源
调度、运维监控、集群管理、数据备份等功能模块，满足管理人员与运维人员的操作要求。

[0099] 可选地，民航数据管理平台还包括计算引擎。

[0100] 请参阅图3，计算引擎为自主研发的“海纳（haina）引擎”，该计算引擎的底层采用开源的Flink框架。Flink框架的基础单元为Job。民航数据管理平台的所有数据处理都由
Job来完成。一个Job对应于物理部署的环境（Environment），多个Job也可以共用同一个环
境，一个Job可以包含一到多个Flow，每个Flow对应一个处理通道。处理通道采用管道‑过滤
器模式；所述处理通道包括Source单元、Processor单元及Sink单元。

[0101] Source单元作为处理通道的输入端，用于接收民航业务数据。可以连接网络服务（http）或消息队列（MQ）。

[0102] Processor单元作为处理数据的过滤器，数据处理的逻辑由Processor单元来承担。即Processor单元用于对Source单元接收的民航业务数据进行处理。

[0103] Processor单元的设置原则可以包括：1.业务上对数据流的处理可以拆分为多个阶段，每个Processor单元对应一个阶段。2.有副作用的和无副作用的职责分离到不同的
Processor单元。3.把需要访问外部系统的业务分离到不同的Processor单元。4.保证
Processor单元的代码短小，保证将Processor单元真正的职责转移到别的类。5.每个
Processor单元的上游与下游，即MapFunction或其他接口对应的类型参数T与O，应尽量采
用民航数据管理平台定义的模型对象，而非一些如String之类的基础类型。6.每个
Processor单元的命名规则采用动宾短语，并以Processor作为类的后缀。例如将一条航班
信息拆分成多个机位信息，则命名为SplitFlightToStandsProcessor。7.每个Processor单
元需要的外部数据，都通过Processor单元的构造函数来传递。

[0104] Sink单元作为处理通道的输出端，用于将处理后的数据进行存储或共享。可以连接消息队列（MQ）或数据库（DB）。

[0105] 可见，于本申请实施例中，计算引擎所有的处理数据过程均可以通过Processor单元实现，在管道‑过滤器模式中可以设置一个或多个Processor单元，进而在后续业务的开
发过程中，若需要增设一个业务，仅需增设一个Processor单元即可，通过该方式，可以实现
以最小的开发量完成业务的开发和运行。比如，当需要增设北京至上海的航班信息提取业
务时，仅需增设一个Processor单元并设计对应的代码即可，而无需对其他的代码进行改
动。

[0106] 且上述方式支持数据计算能力的水平扩展，即基于Flink框架，可以并行执行多个通道（对应多个Flow），每个通道均包括Source单元、Processor单元及Sink单元，不同的
Flow可以并行处理不同的业务需求。

[0107] 于本申请实施例中，Processor单元具体用于将民航业务数据进行抽象，生成抽象数据；并基于预设的映射规则将抽象数据转为抽象主题模型的模型对象。

[0108] 可以理解的是，预先构建抽象消息模型及抽象主题模型。其中，抽象消息模型可以参考图4，抽象主题模型可以参考图5。

[0109] 由于民航数据管理平台的数据通常为XML和JSON类型，因此通过抽象模型将这两类消息（民航业务数据）进行抽象。MessageNodes和MessageNode组成了一棵消息树，一个
MessageNode（抽象数据）对应抽象主题模型的业务实体。XMLNodes为XML类型的消息，
JSONNodes为JSON类型的消息。

[0110] 抽象主题模型包括根对象（RootEntity）；每个根对象（RootEntity）对应一个主题，根对象包括元数据（Meta）、基础信息（Basic）及业务实体（BusinessEntity）；每个抽象
数据对应抽象主题模型的一个业务实体。

[0111] 相应的，每个业务实体可以继续细分为leafEntity（叶实体）和BranchEntity（枝实体）以实现不断地延伸。示例性的，业务实体为航班信息，则可以将业务实体继续细分，如
leafEntity表示航节，BranchEntity表示航站。

[0112] 抽象消息模型与抽象主题模型的对应关系通过预设的映射规则提供。预设的映射规则可以以映射schema文件实现。该文件中存储有每个抽象消息所对应的业务实体。

[0113] 此外，需要说明的是抽象主题模型仅包括主题与业务实体的对应关系，而主题与主题域的关系通过数据库的分配进行实现，如同一主题的数据存储于同一数据库。

[0114] 可见，在本申请实施例中，对民航业务数据进行抽象，生成抽象数据。且该抽象数据与抽象主题模型的业务实体所匹配，通过该方式实现对数据的统一处理，完成数据到主
题模型的转换。此外，抽象主题模型采用“树”的形式，一个根对象代表一个主题，有利于为
根对象定义对外的属性。此外该方式业务独立性强，高内聚、封装性好。抽象主题模型可以
支持不断的延伸。

[0115] 请参阅图6，Processor单元还具体用于获取下游系统的样式文件，基于样式文件，将样式数据进行抽象，生成抽象样式数据，并基于预设的映射规则将抽象样式数据转为抽
象主题模型的模型对象。

[0116] 其中，抽象样式数据为民航业务数据中与样式文件所对应的数据。

[0117] 相应的，Sink单元还用于将经Processor单元对抽象样式数据进行归类后的主题数据（出口数据）发送至该下游系统。

[0118] 示例性的，假设下游系统重点关注航班时间、旅客信息。则Processor单元仅提取这两类数据，并构建对应的主题数据下发至该下游系统。通过下游系统的样式文件，对主题
数据进行封装进而实现了不同需求的配置。

[0119] 请参阅图7，本申请实施例还提供一种民航数据管理方法，该方法应用于搭载上述实施例所提供的民航数据管理平台的服务器中，该方法包括步骤S101 步骤S103。
~

[0120] 步骤S101：通过交换中心获取上游系统的民航业务数据。

[0121] 步骤S102：通过治理中心接收民航业务数据，并基于预设的主题划分规则对民航业务数据进行归类。

[0122] 步骤S103：通过存储中心存储治理中心对民航业务数据进行归类后的主题数据。

[0123] 需要说明的是，由于上述处理过程在前述实施例中已有说明，此处不作赘述，相同部分互相参考即可。

[0124] 基于同一发明构思，本申请实施例还提供一种服务器。该服务器搭载上述实施例所提供的民航数据管理平台，并可执行上述民航数据管理方法。在结构上，该服务器包括：
处理器和存储器。

[0125] 处理器与存储器直接或间接地电性连接，以实现数据的传输或交互，例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

[0126] 其中，处理器可以是一种集成电路芯片，具有信号处理能力。处理器也可以是通用处理器，例如，可以是中央处理器（Central Processing Unit，CPU）、数字信号处理器
（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated 
Circuit ，ASIC）、分立门或晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施
例中的公开的各方法、步骤及逻辑框图。此外，通用处理器可以是微处理器或者任何常规处
理器等。

[0127] 存储器可以是，但不限于，随机存取存储器（Random Access Memory，RAM）、只读存储器（Read Only Memory，ROM）、可编程只读存储器（Programmable Read‑Only Memory，
PROM）、可擦可编程序只读存储器（Erasable Programmable Read‑Only Memory，EPROM），以
及电可擦编程只读存储器(Electric Erasable Programmable Read‑Only Memory，
EEPROM）。存储器用于存储程序，处理器在接收到执行指令后，执行该程序。

[0128] 需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过
程，在此不再赘述。

[0129] 基于同一发明构思，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序在被运行时执行上述实施例中提供的方法。

[0130] 该存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如软盘、
硬盘、磁带)、光介质(例如DVD)、或者半导体介质（例如固态硬盘Solid State Disk (SSD)）
等。

[0131] 在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻
辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可
以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间
的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连
接，可以是电性，机械或其它的形式。

[0132] 另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多
个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的
目的。

[0133] 再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

[0134] 在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际
的关系或者顺序。

[0135] 以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的
任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。