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

文章插图
4. Parquet 优化方案
Lyft 的准实时数据分析平台在 Parquet 方面做了很多优化，比如文件数据值大小范围统计信息、文件系统统计信息、基于主键数据值的排序加快 presto 的查询速度以及二级索引的生成。
文章插图
5. 基于数据回填的平台容错机制
如下两个图所示的是 Lyft 准实时数据分析平台的基于数据回填的平台容错机制。对于 Flink 而言，因为平台的要求是达到准实时，而 Flink 的 Job 出现失效的时候可能会超过一定的时间，当 Job 重新开始之后就会形成两个数据流，主数据流总是从最新的数据开始往下执行，附加数据流则可以回溯到之前中断的位置进行执行直到中断结束的位置。这样的好处是既能保证主数据流的准实时特性，同时通过回填数据流保证数据的完整性。
文章插图
对于 ETL 而言，基于数据回填的平台容错机制则表现在 Airflow 的幂等调度系统、原子压缩和 HMS 交换操作、分区自建自修复体系和 Schema 整合。
文章插图
04
总结与未来展望
1. 体验与经验教训
利用 Flink 能够准实时注入 Parquet 数据，使得交互式查询体验为可能。同时， Flink 在 Lyft 中的应用很多地方也需要提高，虽然 Flink 在大多数情况的延时都能够得到保证，但是重启和部署的时候仍然可能造成分钟级别的延时，这会对于 SLO 产生一定影响。
此外， Lyft 目前做的一件事情就是改善部署系统使其能够支持 Kubernetes ，并且使得其能够接近 0 宕机时间的效果。因为 Lyft 准实时数据分析平台在云端运行，因此在将数据上传到 S3 的时候会产生一些随机的网络情况，造成 Sink Subtasks 的停滞，进而造成整个 Flink Job 的停滞。而通过引入一些 Time Out 机制来检测 Sink Subtasks 的停滞，使得整个 Flink Job 能够顺利运行下去。
ETL 分区感应能够降低成本和延迟，成功文件则能够表示什么时候处理完成。此外， S3 文件布局对性能提升的影响还是非常大的，目前而言引入熵数还属于经验总结，后续 Lyft 也会对于这些进行总结分析并且公开。因为使用 Parquet 数据，因此对于 Schema 的兼容性要求就非常高，如果引入了不兼容事件则会使得下游的 ETL 瘫痪，因此 Lyft 已经做到的就是在数据链路上游对于 Schema 的兼容性进行检查，检测并拒绝用户提交不兼容的 Schema 。
文章插图
【Lyft 基于 Flink 的大规模准实时数据分析平台】2. 未来展望
Lyft 对于准实时数据分析平台也有一些设想：

首先， Lyft 希望将 Flink 部署在 Kubernetes 集群环境下运行，使得 Kubernetes 能够管理这些 Flink Job ，同时也能够充分利用 Kubernetes 集群的高可扩展性。
其次， Lyft 也希望实现通用的流数据导入框架，准实时数据分析平台不仅仅支持事件，也能够支持数据库以及服务日志等数据。
再次， Lyft 希望平台能够实现 ETL 智能压缩以及事件驱动 ETL ，使得回填等事件能够自动触发相应的 ETL 过程，实现和以前的数据的合并，同时将延时数据导入来对于 ETL 过程进行更新。
最后， Lyft 还希望准实时数据分析平台能够实现存储过程的改进以及查询优化，借助 Parquet 的统计数据来改善 presto 的查询性能，借助表格管理相关的开源软件对存储管理进行性能改善，同时实现更多的功能。

文章插图
作者：
徐赢博士是 Lyft 数据平台流媒体平台的技术领导（Technical Lead），目前主导准实时数据分析平台的架构开发。在 Lyft 之前，他曾在领英(Linkedin)以及 IBM 担任技术领导职位，主导领英跨数据中心数据库复制的上线，以及 IBM 高速数据传输技术的研发。
高立博士在 Lyft 的数据平台团队中工作，目前领导 Lyft 数据平台内的多个数据基础架构项目，包括实时数据仓库，自服务机器学习平台项目等。曾在 Salesforce ， Fitbit ， Groupon 和其他初创公司担任关键技术领导职务。