客流数仓数据朔源的方法、装置、系统和存储介质

技术领域

本申请涉及表级别、字段级别的数仓血缘关系的解析技术领域，尤其是涉及一种客流数仓数据朔源的方法、装置、系统和存储介质。

背景技术

数字经济是以数据资源为关键要素，以现代信息网络为主要载体，以信息通信技术融合应用、全要素数字化转型为重要推动力，促进公平与效率更加统一的新经济形态，可见数字化时代已成必然趋势。

当前数据安全已成为事关国家安全与经济社会发展的重大问题，与此同时国家相继出台了《数据安全法(草案)》和《个人信息保护法》，旨在为落实数据安全保护责任。可见数据对于个人、企业乃至国家的重要性是不言而喻的。

现有公司数仓体系数据朔源难,一旦出现了数据问题,需要开发人员逐一去开发脚本里一个一个去找关联关系,使得数仓运维及数据追责变得极为困难。问题体现在如下方面：

1、客流系统的客流日志数据的采集和汇总、解析、注入大数据系统的问题；2、没有有效的利用客流的客流日志数据；

3、不方便客流数仓数据价值的挖掘及客流数仓数据质量的评估。

发明内容

为了解决上述技术缺陷之一，本申请实施例中提供了一种客流数仓数据朔源的方法、装置、系统和存储介质。

根据本申请实施例的第一个方面，提供了一种客流数仓数据朔源的方法，包括：

获取轨道交通客流日志数据；包括车站客流、换乘客流、途经客流、列车运力数据源的数据，实现不同数据源的数据采集；

将客流日志数据进行格式化入库解析；

将解析后的客流日志数据导入大数据平台,基于Hadoop大数据技术，实现存储实时和离线精细数据，在大数据存储之上建立ODS层、DWD层、DWS层、ADS层的设计和建模开发工作；

对每层的客流日志数据进行字段级血缘解析，得到客流数据仓库的血缘元数据信息，所述血缘元数据为用于解释所述血缘关系数据的数据；

将获取的血缘元数据信息存入元数据管理平台数据库。

根据本申请实施例的第二个方面，提供了一种客流数仓数据朔源的装置，包括；

获取单元，用于获取轨道交通客流日志数据；包括车站客流、换乘客流、途经客流、列车运力数据源的数据，实现不同数据源的数据采集；

格式化入库解析单元，用于将客流日志数据进行格式化入库解析；

导入单元，用于将解析后的客流日志数据导入大数据平台,基于Hadoop大数据技术，实现存储实时和离线精细数据，在大数据存储之上建立ODS层、DWD层、DWS层、ADS层的设计和建模开发工作；

生成单元，用于通过对于客流日志数据进行维度建模与分析生成客流数仓；

构建单元，用于构建ODS,DWD,DWS,ADS层；

字段级血缘解析单元，用于对每层的客流日志数据进行字段级血缘解析，得到客流数仓的血缘元数据信息；

储存单元，用于将获取的血缘元数据信息存入元数据管理平台数据库。

根据本申请实施例的第三个方面，提供了一种系统，其特征在于，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如上所述方法。

根据本申请实施例的第四个方面，提供了一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时运行如上所述方法。

本申请的有益效果主要在于：

1、解决客流系统的客流日志数据的采集和汇总、解析、注入大数据系统的问题；

2、通过在多维度建模和大数据技术支持，实现客流日志数据的采集，建立相应的数据模型，以更加有效的利用客流的客流日志数据；

3、通过对建模的客流日志数据进行表级别、字段级的血缘解析,实现对于客流数仓数据的朔源及血缘关系的可视化展示。方便客流数仓数据价值的进一步挖掘及客流数仓数据质量的评估。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例一提供的客流数仓数据朔源的方法流程图。

具体实施方式

为了使本申请实施例中的技术方案及优点更加清楚明白，以下结合附图对本申请的示例性实施例进行进一步详细的说明，显然，所描述的实施例仅是本申请的一部分实施例，而不是所有实施例的穷举。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本申请提供一种客流数仓数据朔源的方法，能够对客流数仓数据进行挖掘和处理。实际应用中，该客流数仓数据朔源的方法可以通过计算机程序实现，例如，应用软件等；或者，该方法也可以实现为存储有相关计算机程序的介质，例如，U盘、云盘等；再或者，该方法还可以通过集成或安装有相关计算机程序的实体装置实现，例如，芯片、可移动智能设备等。

本实施例中的部分英文简称说明：

ETL：数据接口和数据仓库Extract-Transform-Load；

ODS：数据准备层Operation Data Store；

DWD：细节数据层Data Warehouse Details；

DWS：主题数据层Data Warehouse Topic；

ADS：应用数据服务Application Data Service；

DIM：维表层Dimension；

DWS：数据服务层Data WareHouse Servce；

DAG：无回路有向图Directed Acyclic Graph；

SemanticAnalyzer：语义分析器；

getTableSpec：java获取表元数据信息；

Schema：结构信息；

postExecHook：钩子函数；

LineageLogger：血缘关系日志；

Hive：数据仓库工具；

如图1所示，本申请的客流数仓数据朔源的方法包括以下步骤：

101、获取轨道交通客流日志数据。

在本实施例中，客流日志数据准备，通过ETL技术连接车站客流、换乘客流、途经客流、列车运力数据源的数据，实现不同数据源的数据采集。

102、将客流日志数据进行格式化入库解析。

在本实施例中，将客流日志数据进行格式化入库解析,为导入大数据平台做准备。

103、将解析后的客流日志数据导入大数据平台,通过对于客流日志数据进行维度建模与分析生成客流数仓，并构建ODS层、DWD层、DWS层、ADS层。

在本实施例中，将解析好的客流日志数据导入到大数据平台,基于Hadoop等大数据技术，实现存储实时和离线精细数据，在大数据存储之上建立ODS层、DWD层、DWS层、ADS层的设计和建模开发工作。

ODS层属于客流原始数据层，是直接从客流日志系统采集过来的最原始的数据；

数据明细详情，去除空值，脏数据，超过极限范围的明细解析；

DWD为明细数据层，按照客流业务不同的数据维度及粒度对原始数据层ODS层进行粗粒度的聚合生成，例如两小时A站进站客流量，两小时A站出站客流量等数据，供下游DWS层做进一步数据聚合使用；

DWS为汇聚数据层，客流数据中按照相同维度进行进一步数据聚合的操作，例如将一天内B站进站客流量，三天内B站进站客流量,七天内B站进站客流量进行数据汇总，方便后续的ADS指标层进行指标计算时的数据调用。

ADS为指标数据层，根据不同的业务指标，根据前期开发的DWD,DWS层数据及指标逻辑进行数据开发，生成指标数据供业务使用，例如断面运力、线路换乘客流、站台候车人数、换乘铜套通过人数等指标。最终将开发出的指标数据存入Redis数据库供BI及业务方调用。

104、对每层的客流日志数据进行字段级血缘解析，得到客流数仓的血缘元数据信息。

所述血缘元数据信息至少包括以下字段之一或组合：当前节点名称、父节点名称、子节点名称、表名称、输入对象列表、输出对象列表、表注释、数据源类型、数据库、数据位置、元数据sql文件位置、元数据修改时间。元数据信息并不是唯一的，可以根据客流仓的需要进行设置。

在本实施例中，1.在解析之前,先了解一下hive sql的执行流程,如图1所示，HQL解析(生成AST语法树)＝>语法分析(得到QueryBlock)＝>生成逻辑执行计划(Operator)＝>逻辑优化(LogicalOptimizer Operator)＝>生成物理执行计划(TaskPlan)＝>物理优化(Task Tree)＝>构建执行计划(QueryPlan)＝>执行引擎执行。

具体展开如下:

Hive根据Antlr定义的词法、语法规则完成词法、语法分析将HQL解析为AST Tree即抽象语法树；

2)深度遍历抽象语法树进行语义解析，得到相应的查询的基本组成单元QueryBlock；

AST Tree生成QueryBlock的过程是一个递归的过程，先序遍历AST Tree，遇到不同的Token节点，保存到相应的属性中，主要包含以下几个过程:

·TOK_QUERY＝>创建QB对象，循环递归子节点

·TOK_FROM＝>将表名语法部分保存到QB对象的aliasToTabs等属性中

·TOK_INSERT＝>循环递归子节点

·TOK_DESTINATION＝>将输出目标的语法部分保存在QBParseInfo对象的nameToDest属性中

·TOK_SELECT＝>分别将查询表达式的语法部分保存在destToSelExpr、destToAggregationExprs、destToDistinctFuncExprs三个属性中

·TOK_WHERE＝>将Where部分的语法保存在QBParseInfo对象的destToWhereExpr属性中

遍历Query Block，解析为操作树OperatorTree，生成逻辑执行计划；

4)逻辑优化器进行操作树变换，合并多余的ReduceSinkOperator，减少shuffle，即对应的列剪枝、分区剪枝以及join顺序优化等操作；

5)遍历Operator Tree，将操作树转变为对应的MapReduce任务，生成物理执行计划；

6)物理优化器进行MapReduce任务变换，针对最后生成DAG图进行优化，生成最终的执行计划。

7)逻辑计划执行；

通过以上对Hive SQL解析流程描述，血缘解析以此为基础进行展开。同时注意到传统Hive SQL解析流程相对比较繁琐，递归次数多，自定义函数无法识别，以及HiveSchema不能支持企业级应用等问题，在血缘解析中进行调整与优化，充分支撑企业数仓级应用。

2.在字段级血缘解析之前先说明一下表级别血缘关系解析优化的实现,具体流程如下:

表级别血缘解析是HIVE SQL解析的基础，通过SQL快速定位到SQL语句中的源表和目标表以及相关条件，通过DAG图展示源表与目标表的关系。进一步直观展现数据表的流传。特别是在复杂的SQL逻辑下，涉及到多张表部分数据的join、union等连接形式，通过DAG图展示给数据分析师或ETL数仓工程师，对企业数据仓库的构建以及数据监控起到重要支撑作用。

表级别血缘关系解析流程如下。

对Hive SQL进行词法分析和语法分析，获取对应的AST原始的抽象语法树。

抽象语法树验证与优化；

(1)语法树有效性验证，通过验证，辅助ETL工程师判定书写SQL的正确性；

(2)AST语法树剪枝优化，减少遍历次数，提高语义解析的效率，具体主要做两方面的优化：

(2.1)针对token中涉及到的无效解析节点进行删除,如order by，distributedby,cluster by,sort by以及limit。

(2.2)针对token_where/having的子查询，在保证SQL语法正确性以及语义完整性的前提下，采用1＝1等价策略进行等价替换，降低了血缘关系解析的复杂性；

通过以上两种剪枝操作，既可以减少SQL语句的复杂性，又可以降低AST语法树的层级，进一步减少了遍历AST树递归次数，降低血缘分析的复杂性，提高了语句解析效率；

3.遍历AST获取上游表名(TOK_TAB)和下游表名(TOK_TABREF)，在SQL语句中存在大部分SQL语句片段即CTE。由于其在血缘关系解析中不起关键作用，且对SQL解析带来很大困扰，因此血缘关系解析需对cte类型进行识别，并进行替换与删除。

105、将获取的血缘元数据信息存入元数据管理平台数据库。

本实施例中，系统获取客流日志数据、解析并导入大数据平台、通过对于客流日志数据进行维度建模与分析生成客流数仓,构建ODS,DWD,DWS,ADS层、对每层的客流日志数据进行字段级血缘解析、将获取的血缘元数据存入Neo4j图数据库进行可视化展示,血缘关系数据存入元数据管理平台数据库,实现客流数仓数据可朔源,数仓数据质量可评估。

在本实施例中，字段级别的血缘关系梳理是Hive解析中具有重要环节，并支撑血缘关系DAG的核心作用。字段级别血缘解析贯穿到HIVE SQL语义解析之后，结合企业数仓应用的需求，如需支持UDF自定义函数解析，丰富Hive元数据信息，Hive数据表等权限认证，支持Hook监听策略等需求进行改进，具体改进方式如下：

1.注册客流数据字段级血缘解析UDF自定义函数；注册UDF自定义函数，便于血缘关系提取时，标记识别特殊函数，保证血缘关系解析的准确性。

2.重构SemanticAnalyzer，重写SQL解析主要逻辑。SemanticAnalyzer类作为hiveSQL解析的核心工具类，用于遍历AST树，并将其转化为Query Block。然而血缘关系解析时，需要元数据管理模块获取数据表的基本信息如表信息以及字段信息，以及数据表验证，表与字段信息的填充，因此为方便对血缘关系的梳理，特重构SemanticAnalyzer类并继承BaseSemanticAnalyzer类型，完善对列字段血缘关系的提取；

3.客流数仓字段级血缘解析逻辑计划生成和逻辑计划优化，此过程主要依据操作树，推到出结果集schema,并初始化逻辑计划和物理计划依赖的配置信息，保证血缘关系分析的基础配置信息的完整性,同时对操作树进行优化，合并操作符，减少mapreduce job的stage数量，提高血缘关系解析的执行效率；

4.客流数仓字段级血缘关系解析中，采用单独封装getTableSpec方法实现了元数据信息的切换，通过其方法获取相关hive表Schema，分区信息以及表权限信息。

5.Hooks是一种事件和消息机制，可以将事件绑定在内部Hive的执行流程中，用于监听Hive的各种事件，如表创建，更新等操作，通过对postExecHook的配置与调用，可以hive列级别血缘管理封装到LineageContext中。

添加postExecHook，执行LineageLogger获得LineageContext.在血缘关系解析中，将此步骤前置到执行逻辑计划之后，由LineageLogger类调用执行SQL逻辑计划，获取到字段级别的血缘信息封装到Lineage Context中。

6.读取LineageContext信息，组装数据表与字段血缘关系信息。通过对AST树进行血缘解析之后，具体的字段血缘信息存储LineageContext中，通过得LineageContext的索引对象，便可获取列字段血缘关系，通过LineageContext.index信息，将源头和目标用向量连接起来，形成列字段边信息，同时将各个边的节点连接起来，形成列的有向无环图。

通过优化后的字段级血缘关系解析,获取到客流数仓的血缘元数据信息,将血缘元数据存入到Neo4j中,通过Neo4j图数据库查询字段之间的依赖关系,并进行可视化展示。

本实施例还提供了一种客流数仓数据朔源的装置，该装置包括：获取单元、格式化入库单元、导入单元、生成单元、构建单元、字段级血缘解析单元和存储单元。其中，

获取单元用于获取轨道交通客流日志数据。

格式化入库解析单元，用于将客流日志数据进行格式化入库解析。

导入单元，用于将解析后的客流日志数据导入大数据平台。

生成单元，用于通过对于客流日志数据进行维度建模与分析生成客流数仓。

构建单元，用于构建ODS,DWD,DWS,ADS层。

字段级血缘解析单元，用于对每层的客流日志数据进行字段级血缘解析，得到客流数仓的血缘元数据信息。

储存单元，用于将获取的血缘元数据信息存入元数据管理平台数据库。

进一步的，还包括：可视化单元，用于将血缘元数据信息存入Neo4j图数据库进行可视化展示。

进一步的，上述字段级血缘解析单元具体包括：注册子单元、重构子单元、逻辑子单元、切换子单元、函数执行子单元以及组装子单元。其中，

注册子单元用于注册UDF自定义函数。

重构子单元用于重构SemanticAnalyzer，重写SQL解析主要逻辑。

逻辑子单元用于逻辑计划生成和逻辑计划优化。

切换子单元用于在血缘关系解析中，采用单独封装getTableSpec方法实现元数据信息的切换，通过其方法获取相关hive表Schema，分区信息以及表权限信息。

函数执行子单元，用于添加postExecHook，执行LineageLogger获得LineageContext。

组装子单元，用于读取LineageContext信息，组装数据表与字段血缘关系信息。

本实施例还提供一种系统，包括处理器以及存储器，所述存储器存储有计算机可读取指令，当所述计算机可读取指令由所述处理器执行时，运行如上任一内容所提供的方法。

该发明还包括一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时运行如上实施例方法中的步骤。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。本申请实施例中的方案可以采用各种计算机语言实现，例如，C语言、VHDL语言、Verilog语言、面向对象的程序设计语言Java和直译式脚本语言JavaScript等。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。