饿了么元数据管理实践之路

  • 时间:
  • 浏览:1
  • 来源:5分PK10_5分PK10官网



根据SQL的input、output构建表的依赖关系,进一步构建任务的DAG依赖形状。可不也能对任务进行DAG调度,重新编排任务执行序列。

Q7:数据血缘关系可能使用Hive hook最好的最好的办法获取,是可不也能在每个执行节点中做捕捉吗?

A:Hive hook也不执行时调用,可不也能去了解下底层。

提供动态的表依赖血缘关系查询。节点是表基础信息,节点之间的边是Operation信息,一起附加任务执行Id、执行时间等属性。列血缘形状展示等同表血缘形状。

大数据挑战



input: id,

operation: coalesce(name, count(id)),

output:lineage_name

Q3:把从SQL中的分派数据存储到MySQL中,是怎样规划的?哪些分派信息不应该像是日志数据一样被出理 吗?存储在MySQL中是有自增全局ID的么?还是说亲戚亲戚大伙儿是对任务和表分别有MySQL表,但会 更新MySQL表中任务和表甚至列的信息么?这里的MySQL表也不您说的DataSet么?

A:任务jobid进行唯一,MySQL只保存执行的SQL,以及任务一种生活的信息,比如owner time jobid等等。



饿了么解析血缘的SQL支持的操作有:Query(中有 selectinsert intoinsert overwrite)、CreateTable、CreateTableAsSelect、DropTable、CreateView、AlterView。基本覆盖饿了么生产环境99%+的SQL语法。

元数据定义与价值

举个栗子

Q1:咱们的数据生命周期是怎样管理的,能具体说下吗?

A:表级数据进行热度分析,比如近有两个多多多月没有 访问,是算不算可不也能下线,不得劲是你是什么临时表 可不也能定时清理。

Q6:亲戚亲戚大伙儿管理的表分线上表和线下表么?在出理 的但是用到了你是什么临时表该为啥出理 ?

A:对的,线上还是线下,任务调度系统分派,临时表根据temp就知道了。

input:name,

operation: coalesce(name, count(id)),

output: lineage_name;

Atlas是Apache开源的元数据治理方案。Hook执行中分派数据(比如HiveHook),发送Kafka,消费Kafka数据,生成Relation关系保存图数据库Titan,并提供REST接口查询功能,支持表血缘,列级支持不完善。

大数据时代,饿了么面临数据管理、数据使用、数据现象等多重挑战。具体可不也能参考下图:



SQL分派与分派

静态的Hive MetaStore表,比如DBS、TBLS、SDS、COLUMNS_V2、TABLE_PARAMS、PARTITIONS,保存表、字段、分区、Owner等基础信息,便于表、字段的信息检索功能。

但对于SELECT *、CTAS等操作,直接遍历AST,不去获取Schema信息来检查表名、列名,就无法判定SQL的正确性,原应数据污染。

元数据打通数据源、数据仓库、数据应用,记录了数据从产生到消费的完正链路。它中有 静态的表、列、分区信息(也也不MetaStore);动态的任务、表依赖映射关系;数据仓库的模型定义、数据生命周期;以及ETL任务调度信息、输入输出等。

Q5:亲戚亲戚大伙儿是为啥做热度分析的?刚才的讲解里,你是什么点讲得比较少。

A:任务操作的SQL产生input output表,对表进行counter就能top counter,列也一样。

有了input、operation、output关系,将input、output保存为图节点,operation保存为图边。图数据库选者Gremlin+Neo4j。

计算引擎实现相关的监听接口,比如Hive实现Execute With Hook Context接口;Spark实现Spark Listener接口;Presto实现Event Listener接口。将计算引擎相关的上下文Context、元数据MetaData、统计Statistics等信息存入DB。

三、饿了么每项使用场景

以本土做简单示例,先经过Semantic Analyzer Factory类进行语法分析,再根据Schema生成执行计划QueryPlan。关于表、列的血缘,可不也能从LineageInfo、LineageLogger类中获得出理 方案。

EDW是饿了么的调度系统,比拟开源的AirFlow。调度系统执行任务,并将任务相关的信息,比如appId、jobId、owner、SQL等信息存入DB。

表血缘形状

原文发布时间为:2018-07-26

本文作者:王金海

本文来自云栖社区媒体商务合作伙伴“DBAplus社群”,了解相关信息可不也能关注“DBAplus社群”。

Q4:当前的支持非SQL形式生成表么?比如直接用Spark RDD任务可能Spark MLlib任务取表和珍成表?

A:只支持SQL表达。

解析SQL的方案,以Hive为例。先定义词法规则和语法规则文件,但会 使用Antlr实现SQL的词法和语法解析,生成AST语法树,遍历AST语法树完成后续操作。

Q8:解析那种繁杂度很高的HQL的血缘,亲戚亲戚大伙儿平台的解析思路是哪些样子的?怎样保证正确率呢?

A:会有好多好多 繁杂的ppt有代码示例,会有每项SQL可不也能修改Hive解析实现。

DB保存任务的SQL数据、任务基础信息、执行引擎上下文信息;

Extract循环抽取SQL并解析成表、列级血缘Lineage;

DataSet中有 Lineage关系数据+任务信息+引擎上下文;

将DataSet数据集保存到Neo4j,并提供关系查询;保存ES,提供表、字段等信息检索。

图存储



综上所述,饿了么的SQL解析方案,直接参考Hive的底层源码实现。

举个栗子,根据上端的SQL,分别产生表、列血缘形状。

一、背景

数据现象:多种执行、存储引擎,分钟、小时、天级的任务调度,怎样梳理数据的时间线变化?

数据使用:任务、表、列、指标等数据,怎样进行检索、复用、清理、热度Top计算?

数据管理:怎样对表、列、指标等进行权限控制、任务治理以及上下游依赖影响分析?

Q2:质量监控会影响到任务调度编排么?

A:会影响质量编排,构建DAG依赖执行。

Q10:SQL分派,引擎分派,是要去重写Hive等的源码吗?

A:重写倒不至于,倘若实现ppt里的接口,很简单。

Gremlin是图语言,存储实现方案比较多,Cypher查询不太直观,且只能Neo4j使用。社区版Neo4j只能单机跑,亲戚亲戚大伙儿正在测试OrientDB。

下面是饿了么在元数据应用上的每项场景:

input是表、列输入值;output是表、列输出值;operation代表操作类型。比如表A+B通过insert,生成表C,则延展成A insert C; B insert C。

当然,你可不也能针对每项类型SQL设置Hive Conf,比如“开启动态分区非严格模式”。对于CTAS类型,可不也能设置Context。UDF函数可不也能修改每项Hive源码,出理 UDF Registry检查。

二、饿了么元数据系统架构

列式也一样:

元数据是数据管理、数据内容、数据应用的基础。类似于可不也能利用元数据构建任务、表、列、用户之间的数据图谱;构建任务DAG依赖关系,编排任务执行序列;构建任务画像,进行任务质量治理;数据分析时,使用数据图谱进行字典检索;根据表名查看表详情,以及每张表的来源、去向,每个字段的加工逻辑;提供你是什么人或BU的资产管理、计算资源消耗概览等。

WhereHows是LinkedIn开源的元数据治理方案。Azkaban调度器抓取job执行日志,也也不Hadoop的JobHistory,Log Parser后保存DB,并提供REST查询。WhereHows太重,可不也能部署Azkaban等调度器,以及只支持表血缘,功能局限。

Q9:表血缘图上端的上下级关系也不数据的流向?从上到下?字段的血缘是哪些样子的跟表的血缘哪些不同?有字段的血缘图吗?

A:ppt里解析那里可不也能看得人,字段也一样,input output列但会 operation

列血缘形状

Q & A

开源出理 方案

饿了么的SQL数据,以执行中分派为主+保存前submit为辅。可能任务的SQL可能中有 你是什么时间变量,比如dt、hour,以及任务可能是天调度、小时调度。执行中分派SQL实时性更高,也更容易出理 。

SQL解析