Uber 推出数据湖集成神器 DBEvents，支持 MySQL、Cassandra 等_uber cassandra

在全球市场保持 Uber 平台的可靠性和实时性是一项 7*24 小时不能间断的任务。当旧金山的人们进入梦乡时，巴黎的上班族们正发送着 Uber 车辆订单准备出门工作。而同一时刻在地球的另一端，孟买的居民可能正在用 Uber Eats 订购晚餐。

我们在 Uber 的大数据平台上促成各种互动，使用我们的Marketplace来匹配乘客和司机；食客、餐馆和配送伙伴；货车司机和运货人。从数据的角度来洞察这些交互有助于我们为全球用户提供优质且有意义的产品体验。

食客们希望食物能及时送达，乘客也希望在最短的时间内被接到，我们的数据必须尽可能快的反映出现场发生的事件。但随着四面八方的数据汇入我们的数据湖，在这种规模下保持数据的新鲜度成为了一项重大的挑战。

虽然现在已经有一些为公司提供 24 小时数据新鲜度的方案，但对于 Uber 的实时性需求来说还是过时了。此外，对于 Uber 的数据规模和运营规模，这种方案无法保证可靠运行。

为了满足我们的特殊需求，我们开发了 DBEvents——一种专为高数据质量和新鲜度而设计的变更数据获取系统。变更数据获取系统（CDC, Change Data Capture System）可以用来确定哪些数据发生了变更，以便采取一些操作，比如获取或是复制。DBEvents 有助于引导、获取已有表格的快照，以及增量的流式更新。

作为 Uber 其他软件（例如Marmaray和Hudi）的补充，DBEvents 从 MySQL、Apache Cassandra 和 Schemaless 中获取数据，以更新我们的 Hadoop 数据湖。这个解决方案可管理 PB 级的数据并可在全球范围内运营，帮助我们为内部数据客户提供最好的服务。

快照数据获取

从历史上看，Uber 的数据获取一般会先确认要获取的数据集，然后使用 MapReduce 或是 Apache Spark 运行一个大型处理作业，从源数据库或表中高并发地读取数据。接下来，我们会将这个作业的输出发送到离线的数据湖，如 HDFS 或 Apache Hive。我们把这个过程称为快照，根据数据集大小的不同，一般会花费几分钟到几小时的时间，这对于我们内部客户的需求来说还不够快。

当一个作业开始获取数据时，它会分散成多个并行任务，与上游的表格（如 MySQL）建立并行的连接并拉取数据。从 MySQL 读取大量数据会对其实时应用流量施加很大的压力。我们可以使用专用的服务器执行 ETL 操作来减轻压力，但这会影响到数据的完整性，也会因为这个备份的数据库服务器增加额外的硬件成本。

获取数据库或表的时间会随着数据量的增加而延长，并在某些时刻无法再满足业务的需求。由于大多数的数据库每天仅更新部分数据，只有极少量的新纪录会被添加，而整个快照过程会一遍又一遍地读取和写入整张表的数据，包括未修改的行，这会导致计算和存储资源无法被有效利用。

DBEvents 的要求

为了 Uber 对更新鲜更快速的数据洞察需求，我们需要设计一种更好的方式来将数据提取到数据湖中。当我们开始设计 DBEvents 时，为最终的解决方案定义了三个业务要求：新鲜度、质量和效率。

新鲜度

数据的新鲜度指它更新得有多频繁。假设在时间 t1 更新 MySQL 表中的一行。数据提取作业在时间 t1+1 时刻开始运行，并消耗 N 个单位时间完成作业。则用户可以在 t1+1+N 时刻获得数据。这里，数据的新鲜度延迟是 N+1，即数据实际更新到数据湖中并可被获取的时间延迟。

Uber 有很多用例都要求 N+1 尽可能的小，最好是几分钟。这些用例包括欺诈检测，因为即使是最轻微的延迟也会影响到客户的体验。出于这些原因，我们在 DBEvents 中将数据新鲜度的要求排在了最高优先级。

质量

如果我们无法描述或理解数据湖中的数据，它们是无法发挥出价值的。设想不同的上游服务对不同的表有不同的