Lyft 基于 Flink 的大规模准实时数据分析平台如何基于Flink搭建大规模准实时

如何基于 Flink 搭建大规模准实时数据分析平台？来自 Lyft 公司实时数据平台的徐赢博士和计算数据平台的高立博士分享了 Lyft 基于 Apache Flink 的大规模准实时数据分析平台。本次分享主要分为四个方面：

Lyft 流数据与场景
准实时数据分析平台和架构
平台性能及容错深入分析
总结与未来展望

01
Lyft 流数据与场景
1. 关于 Lyft
Lyft 是位于北美的一个共享交通平台，和大家所熟知的 Uber 和国内的滴滴类似， Lyft 也为民众提供共享出行的服务。 Lyft 的宗旨是提供世界最好的交通方案来改善人们的生活。

文章插图
2. Lyft 的流数据场景
Lyft 的流数据可以大致分为三类，秒级别、分钟级别和不高于 5 分钟级别。分钟级别流数据中，自适应定价系统、欺诈和异常检测系统是最常用的，此外还有 Lyft 最新研发的机器学习特征工程。不高于 5 分钟级别的场景则包括准实时数据交互查询相关的系统。

文章插图
3. Lyft 数据分析平台架构
如下图所示的是 Lyft 之前的数据分析平台架构。 Lyft 的大部分流数据都是来自于事件，而事件产生的来源主要有两种，分别是手机 APP 和后端服务，比如乘客、司机、支付以及保险等服务都会产生各种各样的事件，而这些事件都需要实时响应。

文章插图
在分析平台这部分，事件会流向 AWS 的 Kinesis 上面，这里的 Kinesis 与 Apache Kafka 非常类似，是一种 AWS 上专有的 PubSub 服务，而这些数据流都会量化成文件，这些文件则都会存储在 AWS 的 S3 上面，并且很多批处理任务都会弹出一些数据子集。在分析系统方面， Lyft 使用的是开源社区中比较活跃的 presto 查询引擎。 Lyft 数据分析平台的用户主要有四种，即数据工程师、数据分析师以及机器学习专家和深度学习专家，他们往往都是通过分析引擎实现与数据的交互。
4. 既往平台的问题
Lyft 之所以要基于 Apache Flink 实现大规模准实时数据分析平台，是因为以往的平台存在一些问题。比如较高的延迟，导入数据无法满足准实时查询的要求；并且基于 Kinesis Client Library 的流式数据导入性能不足；导入数据存在太多小文件导致下游操作性能不足；数据 ETL 大多是高延迟多日多步的架构；此外，以往的平台对于嵌套数据提供的支持也不足。

文章插图
02
准实时数据分析平台和架构
1. 准实时平台架构
在新的准实时平台架构中， Lyft 采用 Flink 实现流数据持久化。 Lyft 使用云端存储，而使用 Flink 直接向云端写一种叫做 Parquet 的数据格式， Parquet 是一种列数据存储格式，能够有效地支持交互式数据查询。 Lyft 在 Parquet 原始数据上架构实时数仓，实时数仓的结构被存储在 Hive 的 Table 里面， Hive Table 的 metadata 存储在 Hive metastore 里面。
平台会对于原始数据做多级的非阻塞 ETL 加工，每一级都是非阻塞的 ( nonblocking ) ，主要是压缩和去重的操作，从而得到更高质量的数据。平台主要使用 Apache Airflow 对于 ETL 操作进行调度。所有的 Parquet 格式的原始数据都可以被 presto 查询，交互式查询的结果将能够以 BI 模型的方式显示给用户。

文章插图
2. 平台设计
Lyft 基于 Apache Flink 实现的大规模准实时数据分析平台具有几个特点：

首先，平台借助 Flink 实现高速有效的流数据接入，使得云上集群规模缩减为原来的十分之一，因此大大降低了运维成本。
其次， Parquet 格式的数据支持交互式查询，当用户仅对于某几个列数据感兴趣时可以通过分区和选择列的方式过滤不必要的数据，从而提升查询的性能。
再次，基于 AWS 的云端存储，平台的数据无需特殊存储形式。
之后，多级 ETL 进程能够确保更好的性能和数据质量。
最后，还能够兼顾性能容错及可演进性。

文章插图
3. 平台特征及应用
Lyft 准实时数据分析平台需要每天处理千亿级事件，能够做到数据延迟小于 5 分钟，而链路中使用的组件确保了数据完整性，同时基于 ETL 去冗余操作实现了数据单一性保证。