数极客首页

Uber推出Databook平台:自动收集元数据并转化为大数据洞见

Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

  • 作者|Luyao Li 等人
  • 译者|无明
  • 编辑|Debra
  • 微信公众号“AI 前线”(ID:ai-front)

指数级业务(和数据)增长

自 2016 年以来,Uber 已在平台上增加了几项新业务,包括 Uber Eats、Uber Freight 和 Jump BIkes。往常

,Uber 平台每天发作
1500 万次买卖
,每月有超越
7500 万生动

用户。在过去的八年中,Uber 曾经
从一家小型创业公司展开

成为一个在全球具有
18,000 名员工的巨头公司。

随着业务的增长,数据系统和工程架构的复杂性也日益增加。我们的剖析

引擎中存在数万个表,包括 Hive、Presto 和 Vertica。由于
数据太过火
散,我们必需
对可用的信息有全面的了解

,特别是当我们继续添加新业务数据和员工时。2015 年,Uber 开端
运用
一些手动维护的静态 HTML 文件对这些数据表中止

编目。

随着公司的展开

,我们需求
更新的表的数据量
和相关元数据的数据量
也在增长。为了确保我们的数据剖析

能够

跟上公司展开

的步伐,我们需求
一种更简单、更快捷的方式来更新这些信息。在这种范围
和增长速度的背景下,具有
一个可用于发现数据集及其相关元数据的强大系统曾经
到了刻不容缓的地步。Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图1

为了能够

更容易发现和探求

数据集,我们开发了 Databook。Databook 可用于管理和展示

Uber 数据集的元数据,让 Uber 的员工能够

在 Uber 探求

、发现和有效应用
这些数据。Databook 能够

保证数据的上下文(数据的意义、质量等)关于
成千上万试图剖析

它们的人来说是有意义的。简单地说,Databook 元数据让 Uber 的工程师、数据科学家和运营团队从原先的查看原始数据转变为往常

的控制
可操作信息。

有了 Databook,我们从手动更新转变为应用
高级自动化元数据存储来搜集
各种经常刷新的元数据。Databook 具备以下几项特性:

可扩展性:易于添加新的元数据、存储和实体。

可访问性:效劳
能够

以编程的方式访问一切
元数据。

可伸缩性:支持高吞吐量读取。

其他:跨数据中心读写。

Databook 提供了各种源自 Hive、Vertica、MySQL、Postgres、Cassandra 和其他几种内部存储系统的元数据,包括:表的方式

、表 / 列阐明

、样本数据、统计信息、Lineage、表的新颖
度、SLA 和一切
者、个人数据分类。

一切
的元数据都能够

经过
一个集中式 UI 和 RESTful API 来访问。Databook UI 为用户访问元数据提供了一种便利的方式,而 Restful API 则为 Uber 的其他效劳
和用例提供支持。

固然
往常

曾经
有像 LinkedIn WhereHows 这样的开源处置

计划

,但在开发 Databook 的过程中,Uber 不支持 Play Framework 和 Gradle。WhereHows 缺乏对跨数据中心读写的支持,而这关于
我们来说却至关重要。因而

,我们开端
构建自己

的内部处置

计划

,并运用
Java 开发,充沛

应用
Java 的内置功用
和成熟的生态系统。

接下来,我们将分享我们是怎样
创建

Databook 的,以及在这一过程中遇到了哪些应战

Databook 架构

Databook 的架构能够

分为三个部分

:怎样
搜集
元数据、怎样
存储元数据以及怎样
显现
元数据。下图描画
了 Databook 的整体架构:Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图2

Databook 将多个源作为输入,存储相关元数据,并经过
RESTful API 输出这些信息。其中 Databook UI 也运用
了这些 API。

在设计 Databook 之初,我们必需
做出一个严重
的决议
:存储搜集
到的元数据还是按需获取?我们的效劳
需求
支持高吞吐量和低延迟读取,假定

我们将操作拜托
给元数据源,一切
源都要支持高吞吐量和低延迟读取,这将带来更大的复杂性和更高的风险。例如,用于获取表方式

的 Vertica 查询通常需求
几秒钟,所以不适合

用于可视化。同样,我们的 Hive Metastore 管理着一切
的 Hive 元数据,要让它支持高吞吐量读取是有风险的。Databook 能够

支持多种不同的元数据源,因而

我们决议
将元数据保管
在 Databook 中。此外,固然
大多数用例需求
新的元数据,但它们不需求
实时查看元数据变卦
,所以我们能够

中止

定时爬取。

我们还将央求

效劳
层与数据搜集
层分开,每个层都运转
在一个单独的进程中,如下图所示:Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图3

这种方式将两个层隔分开
,从而减少了附带影响。例如,数据搜集
爬虫作业可能会运用
较多的系统资源,从而影响央求

效劳
层 API 的 SLA。此外,与 Databook 的央求

效劳
层相比,数据搜集
层对中缀
不太敏感,假定

数据搜集
层关闭,依然

能够

提供过时的元数据,从而最大限度地减少对用户的影响。

基于事情
的搜集
与调度搜集

我们的下一个应战
是决议
改怎样
最有效地从几个不同的数据源搜集
元数据。我们思索
了多种计划

,包括:创建

散布

式的容错框架,并应用
事情
流来近乎实时地检测和调试问题。

我们先是创建

了爬虫,定时搜集
来自各种数据源和微效劳
的信息,这些数据源和微效劳
会生成数据集的元数据信息,例如由开源工具 Queryparser 生成的数据表的运用
统计信息。(有趣的是,Queryparser 是由 Uber 的数据学问
平台团队开发的)。

我们需求
以可伸缩的方式频繁搜集
元数据信息,同时不能阻塞其他爬虫任务。为此,我们将爬虫部署在不同的计算机上,并且需求
调和

这些散布

式的爬虫。我们运用
了 Quartz 的散布

式方式

(由 MySQL 支持)。但是
,有两个问题障碍
了这个计划

的完成
:第一
,在多台机器上以集群方式

运转
Quartz 需求
定期同步 Quartz 时钟,从而增加了外部依赖。第二
,在调度程序启动后,持续呈现
MySQL 衔接
不稳定的状况

。最终
,我们决议
不运用
Quartz 的集群方式

不过,我们依然

继续运用
Quartz 来完成
内存调度,以便更轻松、更高效地将任务发布到任务队列中。我们运用
了 Uber 开源的任务执行框架 Cherami 来处置
任务队列。这个开源工具能够

用来解耦散布

式系统中的消费者应用程序,让它们能够

以异步方式跨多个消费者群组中止

通讯
。有了 Cherami,我们就能够

爬虫打包成 Docker 容器,并部署到不同的主机和多个数据中心中。借助 Cherami,我们能够

从多个不同来源搜集
各种元数据,而不会阻塞任何任务,同时将 CPU 和内存耗费

坚持
在理想水平

固然
我们的爬虫能够

爬取大多数元数据类型,但是有时分
需求
近乎实时地捕获一些元数据,于是我们决议
过渡到运用
基于事情
的架构(Kafka)。有了这个,我们就能够

立刻

检测并调试数据中缀
。我们的系统还能够

捕获到关键的元数据变卦
,例如数据集 lineage 和新颖
度,如下图所示:Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图4

这种架构让我们的系统能够

以编程方式触发其他微效劳
,并近乎实时地向数据用户发起通讯
。我们依然

运用
爬虫执行其他一些任务,比如

搜集
(或刷新)样本数据、限制目的
资源央求

,以及一些没有必要搜集
的元数据(有些事情
发作
时会自动触发其他系统,如数据集运用
统计)。

除了近乎实时地轮询和搜集
元数据之外,Databook UI 还搜集
来自数据集消费者和消费
者的语义信息,例如对表和列的描画

我们是怎样
存储元数据的

在 Uber,为了能够

中止

失效备援,我们的大多数管道都运转
在多个集群上。因而

,同一张表的某些类型元数据的值(例如延迟和运用
统计)可能因集群的不同而不同,它们是特定于集群的。相反,来自用户的元数据则与群集无关:同一张表的描画

和一切
权信息关于
一切
群集来说都是一样的。为了正确链接这两种类

型的元数据,例如将列描画

与一切
集群数据表的列关联起来,能够

采用两种办法

:写入期间链接或读取期间链接。

写入期间链接

在关联特定于群集的元数据和群集无关的元数据时,最直接的战略
是在写入期间将元数据链接在一同
。例如,当用户将列描画

添加到给定的表列时,我们将信息保管
到一切
集群的表中,如下图所示:Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图5

这个办法

可确坚持
久数据处于洁净

状态。例如,在上图中,假定

“列 1”不存在,它将会拒绝

央求

。不过这样就存在一个问题:在写入期间将与群集无关的元数据链接到特定于群集的元数据,一切
特定于群集的元数据必需
存在,并且只需

一次机遇

。例如,当图 4 中的描画

被触发时,只需

集群 1 有“列 1”,因而

对集群 2 的写入会失败。稍后,群集 2 中同一个表的方式

会被更新,但曾经
没有链接元数据的机遇

了,除非我们中止

定时重试,否则这个描画

将永远不可用,从而让系统变得更复杂。下图描画

了这种场景:Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图6

读取期间链接

另一种办法

是在读取期间链接群集无关和特定于群集的元数据。这个办法

处置

了写入期间链接会丧失
元数据的问题,由于
只需
特定于群集的元数据存在,这两种类

型的元数据就能够

在读取期间中止

链接。方式

更新后,“列 1”就会呈现
,并在用户读取时被兼并
,如下图所示:Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图 7

存储选择

MySQL 最初用于为 Databook 的后端提供支持,由于
用它开发速度快,还能够

经过
Uber 的基础

设备
门户中止

自动配置。不过,当触及
多数据中心时,共享 MySQL 集群的效果并不理想,缘由
有三:

单个主节点:第一
,Uber 只支持单个主节点,招致
其他数据中心的写入较慢(每次写入增加了约 70 毫秒)。

手动切换主节点:第二
,当时还不支持自动切换主节点。因而

,假定

主节点宕机,需求
几小时才干
切换到新的主节点。

数据量:我们弃用 MySQL 的另一个缘由
是 Uber 的大量数据。我们打算保管

一切
的历史变卦
记载
,并希望我们的系统能够

支持未来

的扩展,而无需在集群维护上破费

太多时间。

鉴于这些缘由
,我们运用
Cassandra 取代了 MySQL,由于
它提供了强大的 XDC 复制支持,能够

在简直

不增加延迟的状况

下从多个数据中心写入数据。而且 Cassandra 是线性可扩展的,能够

顺应
Uber 不时
增长的数据量。

我们是怎样
提供数据的

Databook 提供了两种访问元数据的办法

:RESTful API 和 UI 控制台。Databook 的 RESTful API 由 Dropwizard 提供支持,Dropwizard 是一个用于开发高性能 RESTful Web 效劳
的 Java 框架,可部署在多台计算机上,并经过
Uber 的内部央求

转发效劳
中止

负载均衡

在 Uber,大部分

效劳
经过
编程的方式访问 Databook 的数据。例如,我们的查询解析 / 重写效劳
就依赖于 Databook 的表方式

信息。API 能够

支持高吞吐量读取,并且支持水平

扩展,每秒的峰值查询大约为 1,500。UI 控制台运用
React.js、Redux 以及 D3.js 开发,整个公司的工程师、数据科学家、数据剖析

师和运营团队都在用它诊断数据质量问题以及辨认

和探求

相关数据集。

搜索

搜索是 Databook UI 的一项重要功用
,用户因而

能够

轻松访问和阅读
表的元数据。我们运用
Elasticsearch 作为全索引搜索引擎,Elasticsearch 会从 Cassandra 同步数据。用户能够

运用
Databook 中止

跨维度搜索,例如称号
、一切
者、列和嵌套列,如下图所示,从而完成
更及时、更精确

的数据剖析

Uber推出Databook平台:自动搜集元数据并转化为大数据洞见

图 8

Databook 的下一个篇章

有了 Databook,Uber 的元数据比以往更具可操作性和适用
性,但我们仍在努力经过
构建更强大的功用
来扩展我们的影响力。我们希望增加的功用
包括应用
机器学习模型生成数据洞见,以及创建

高级的问题检测、预防缓和

解机制。

英文原文:

https://eng.uber.com/databook/

发表评论

评论已关闭。

相关文章