Spark、Flink、CarbonData技术实践最佳案例解析

Spark Structured Streaming特性介绍

作为Spark Structured Streaming最核心的开发人员、Databricks工程师,Tathagata Das(以下简称“TD”)在开场演讲中介绍了Structured Streaming的基本概念,及其在存储、自动流化、容错、性能等方面的特性,在事件时间的处理机制,最后带来了一些实际应用场景。

首先,TD对流处理所面对的问题和概念做了清晰的讲解。TD提到,因为流处理具有如下显著的复杂性特征,所以很难建立非常健壮的处理过程:

• 一是数据有各种不同格式(Jason、Avro、二进制)、脏数据、不及时且无序;

• 二是复杂的加载过程,基于事件时间的过程需要支持交互查询,和机器学习组合使用;

• 三是不同的存储系统和格式(SQL、NoSQL、Parquet等),要考虑如何容错。

因为可以运行在Spark SQL引擎上,Spark Structured Streaming天然拥有较好的性能、良好的扩展性及容错性等Spark优势。除此之外,它还具备丰富、统一、高层次的API,因此便于处理复杂的数据和工作流。再加上,无论是Spark自身,还是其集成的多个存储系统,都有丰富的生态圈。这些优势也让Spark Structured Streaming得到更多的发展和使用。

流的定义是一种无限表(unbounded table),把数据流中的新数据追加在这张无限表中,而它的查询过程可以拆解为几个步骤,例如可以从Kafka读取JSON数据,解析JSON数据,存入结构化Parquet表中,并确保端到端的容错机制。其中的特性包括:

• 支持多种消息队列,比如Files/Kafka/Kinesis等。

• 可以用join(), union()连接多个不同类型的数据源。

• 返回一个DataFrame,它具有一个无限表的结构。

• 你可以按需选择SQL(BI分析)、DataFrame(数据科学家分析)、DataSet(数据引擎),它们有几乎一样的语义和性能。

• 把Kafka的JSON结构的记录转换成String,生成嵌套列,利用了很多优化过的处理函数来完成这个动作,例如from_json(),也允许各种自定义函数协助处理,例如Lambdas, flatMap。

• 在Sink步骤中可以写入外部存储系统,例如Parquet。在Kafka sink中,支持foreach来对输出数据做任何处理,支持事务和exactly-once方式。

• 支持固定时间间隔的微批次处理,具备微批次处理的高性能性,支持低延迟的连续处理(Spark 2.3),支持检查点机制(check point)。

• 秒级处理来自Kafka的结构化源数据,可以充分为查询做好准备。

Spark SQL把批次查询转化为一系列增量执行计划,从而可以分批次地操作数据。

在容错机制上,Structured Streaming采取检查点机制,把进度offset写入stable的存储中,用JSON的方式保存支持向下兼容,允许从任何错误点(例如自动增加一个过滤来处理中断的数据)进行恢复。这样确保了端到端数据的exactly-once。

在性能上,Structured Streaming重用了Spark SQL优化器和Tungsten引擎,而且成本降低了3倍!!更多的信息可以参考作者的blog。

Structured Streaming隔离处理逻辑采用的是可配置化的方式(比如定制JSON的输入数据格式),执行方式是批处理还是流查询很容易识别。同时TD还比较了批处理、微批次-流处理、持续流处理三种模式的延迟性、吞吐性和资源分配情况。

在时间窗口的支持上,Structured Streaming支持基于事件时间(event-time)的聚合,这样更容易了解每隔一段时间发生的事情。同时也支持各种用户定义聚合函数(User Defined Aggregate Function,UDAF)。另外,Structured Streaming可通过不同触发器间分布式存储的状态来进行聚合,状态被存储在内存中,归档采用HDFS的Write Ahead Log (WAL)机制。当然,Structured Streaming还可自动处理过时的数据,更新旧的保存状态。因为历史状态记录可能无限增长,这会带来一些性能问题,为了限制状态记录的大小,Spark使用水印(watermarking)来删除不再更新的旧的聚合数据。允许支持自定义状态函数,比如事件或处理时间的超时,同时支持Scala和Java。

TD在演讲中也具体举例了流处理的应用情况。在苹果的信息安全平台中,每秒将产生有百万级事件,Structured Streaming可以用来做缺陷检测,下图是该平台架构:

在该架构中,一是可以把任意原始日志通过ETL加载到结构化日志库中,通过批次控制可很快进行灾难恢复;二是可以连接很多其它的数据信息(DHCP session,缓慢变化的数据);三是提供了多种混合工作方式:实时警告、历史报告、ad-hoc分析、统一的API允许支持各种分析(例如实时报警系统)等,支持快速部署。四是达到了百万事件秒级处理性能。

更多信息,可以参考在线的文档:

• Structured Streaming编程在线指南

• Databricks的blog

• Databricks的产品

CarbonData原理、应用和新规划

华为大数据架构师蔡强在以CarbonData为主题的演讲中主要介绍了企业对数据应用的挑战、存储产品的选型决策,并深入讲解了CarbonData的原理及应用,以及对未来的规划等。

企业中包含多种数据应用,从商业智能、批处理到机器学习,数据增长快速、数据结构复杂的特征越来越明显。在应用集成上,需要也越来越多,包括支持SQL的标准语法、JDBC和ODBC接口、灵活的动态查询、OLAP分析等。

针对当前大数据领域分析场景需求各异而导致的存储冗余问题,CarbonData提供了一种新的融合数据存储方案,以一份数据同时支持支持快速过滤查找和各种大数据离线分析和实时分析,并通过多级索引、字典编码、预聚合、动态Partition、实时数据查询等特性提升了IO扫描和计算性能,实现万亿数据分析秒级响应。蔡强在演讲中对CarbonData的设计思路做了详细讲解。

• 在数据统一存储上:通过数据共享减少孤岛和冗余,支持多种业务场景以产生更大价值。

• 大集群:区别于以往的单机系统,用户希望新的大数据存储方案能应对日益增多的数据,随时可以通过增加资源的方式横向扩展,无限扩容。

• 易集成:提供标准接口,新的大数据方案与企业已采购的工具和IT系统要能无缝集成,支撑老业务快速迁移。另外要与大数据生态中的各种软件能无缝集成。

• 高性能:计算与存储分离,支持从GB到PB大规模数据,十万亿数据秒级响应。

• 开放生态:与大数据生态无缝集成,充分利用云存储和Hadoop集群的优势。

数据布局如下图,CarbonData用一个HDFS文件构成一个Block,包含若干Blocklet作为文件内的列存数据块,File Header/Fille Footer提供元数据信息,内置Blocklet索引以及Blocklet级和Page级的统计信息,压缩编码采用RLE、自适应编码、Snappy/Zstd压缩,数据类型支持所有基础和复杂类型:

Carbon表支持索引,支持Segment级(注:一个批次数据导入为一个segment)的读写和数据灵活管理,如按segment进行数据老化和查询等,文件布局如下:

• Spark Driver将集中式的索引存在内存中,根据索引快速过滤数据,Hive metastore存储表的元数据(表的信息等)。

• 一次Load/Insert对应生成一个Segment, 一个Segment包含多个Shard, 一个Shard就是一台机器上导入的多个数据文件和一个索引文件组成。每个Segment 包含数据和元数据(CarbonData File和Index文件),不同的Segment可以有不同的文件格式,支持更多其他格式(CSV, Parquet),采用增量的数据管理方式,处理比分区管理的速度快很多。

查询时会将filter和projection下推到DataMap(数据地图)。它的执行模型如下:

• 主要包括Index DataMap和MV DataMap两种不同DataMap,三级Index索引架构减少了Spark Task数和磁盘IO,MV可以进行预汇聚和join的操作,用数据入库时间换取查询时间。

• DataMap根据实际数据量大小选择集中式或者分布式存储,以避免大内存问题。

• DataMap支持内存或磁盘的存储方式。

最后,蔡强也分析了CarbonData的具体使用和未来计划。

在使用上,CarbonData提供了非常丰富的功能特性,用户可权衡入库时间、索引粒度和查询性能,增量入库等方面来灵活设置。表操作与SparkSQL深度集成,支持高检测功能的可配置Table Properties。语法和API保持SparkSQL一致,支持并发导入、更新、合并和查询。DataMap类似一张视图表,可用于加速Carbon表查询,通过datamap_provider支持Bloomfilter、Pre-aggregate、MV三种类型的地图。流式入库与Structured Streaming集成,实现准实时分析。支持同时查询实时数据和历史数据,支持预聚合并自动刷新,聚合查询会先检查聚合操作,从而取得数据返回客户端。准实时查询,提供了Stream SQL标准接口,建立临时的Source表和Sink表。支持类似Structured Streaming(结构化流)的逻辑语句和调度作业。

CarbonData从2016年进入孵化器到2017年毕业,一共发布了10多个稳定的版本,今年9月份将会迎来1.5.0版的发布。1.5.0将支持Spark File Format,增强对S3上数据的支持,支持Spark2.3和Hadoop3.1以及复杂类型的支持。而1.5.1主要会对MV支持增量的加载,增强对DataMap的选择,以及增强了对Presto的支持。

更多信息,可以参考在线的文档:

• 官网 http://carbondata.apache.org/

• 代码 https://github.com/apache/carbondata

• JIRA https://issues.apache.org/jira/browse/CARBONDATA

• 提问 [email protected]

Flink在美团的实践与应用

美团点评数据平台的高级工程师孙梦瑶介绍了美团的实时平台架构及当前痛点,带来了美团如何在Flink上的实践以及如何打造实时数据平台,最后介绍了实时指标聚合系统和机器学习平台是如何利用Flink进行赋能。

孙梦瑶首先介绍了美团目前实时计算平台的架构:

首先,在数据缓存层,Kafka作为最大的数据中转层(所有日志类的数据),支撑了美团线上的大量业务,包括离线拉取,以及部分实时处理业务等。其次,引擎层由计算引擎和存储引擎来支撑,计算引擎由Storm和Flink混合使用,存储引擎则提供实时存储功能。接着,平台层为数据开发提供支持,为美团的日志中心、机器学习中心、实时指标聚合平台提供支撑。架构最顶层的数据应用层 就是由实时计算平台支撑的业务。

目前,美团实时计算平台的作业量已达到近万,集群的节点的规模达到千级别,天级消息量已经达到了万亿级,高峰期的秒级消息量则高达千万条。但是,随着业务的快速扩增,美团点评在实时计算层面仍面临着一系列的痛点及问题:

• 一是实时计算精确性问题:由于Storm的At-Least-Once特性导致数据重复,而满足Exactly-Once的Trident无法保证某些业务的毫秒级延迟要求。

• 二是流处理中的状态管理问题:基于Storm的流处理的状态如果管理不好,会引起故障难以恢复的尴尬状况。

• 三是实时计算表义能力的局限性:基于对实时计算场景的业务需求,发现之前的系统在表义能力方面有一定的限制。

• 四是开发调试成本高:不同生态的手工代码开发,导致后续开发、调试、维护成本的增加。

在这样的的背景下,美团点评基础数据团队也开始引入Flink并探索相对应的创新实践之路。Flink在美团点评的实践主要包括三大维度:一是稳定性实践,二是Flink的平台化,三是生态建设:

• 稳定性实践层面,美团点评首先按不同的业务(取决于不同的高峰期、运维时间、可靠性、延迟要求、应用场景等)进行对应的资源隔离,隔离策略是通过YARN在物理节点上打标签和隔离离线DataNode与实时计算节点。

其次,再实施基于CPU、基于内存的智能调度,目前方案是从CPU和内存两个方面进行调度优化。还包括对Flink的JobManager部署HA(High Availability),保证节点的高可用性。针对网络连接故障,采用自动拉起的方式,通过checkpoint恢复失败的作业。

此外,针对Flink对Kafka 08的读写超时,美团点评会根据用户的指定次数对异常进行重试,这种方式在解决大规模集群的节点故障问题时可以做更好的平衡。在容灾方面,其采用了多机房和各种热备提升系统的抗故障能力,即使断电断网也能进行保证作业继续进行数据处理。

• Flink平台化层面,通过内部的作业管理的实时计算平台,其团队可以看到总览的作业状态,以及资源运行和占用情况。针对实时作业中可能出现的状态,比如延迟、失败,提供监控报警并能便捷地进行消息预订(电话,邮件,短信等方式)。针对显著的性能差别,也提供了调优诊断的手段进行自助查询、对比、诊断。

接下来,孙梦瑶还主要讲解了Flink在美团的应用,其中主要包括两点:一是在Petra实时指标聚合系统的应用,二是用于MLX机器学习平台的构建。

• Petra实时指标聚合系统主要完成对美团业务系统指标的聚合和展示。它对应的场景是整合多个上游系统的业务维度和指标,确保低延迟、同步时效性及可配置。因此美团点评团队充分利用了Flink基于事件时间和聚合的良好支持、Flink在精确率(checkpoint机制)和低延迟上的特性,以及热点key散列解决了维度计算中的数据倾斜问题。

• MLX机器学习平台

MLX机器学习平台主要通过特征数据的提取和模型的训练,支持美团点评的搜索和推荐以及其他业务的应用。它需要满足提供离线模式——通过批处理抽取离线特征数据,同时也提供近线模式——通过Flink抽取实时日志系统中的特征数据。接着训练综合了离线和近线数据的特征数据集群,提取特征并进行模型训练,最终产生有意义的特征。目前,它能支持现有离线场景下的特征提取体系,通过Flink支持增量在线日志交易类数据,有了离线和在线数据就能较好的支持模型训练、特征提取、在线预估、实时预测等。

未来,美团点评还将从三方面优化Flink相关实践:

• 状态的统一方面:对状态进行统一的管理以及大状态性能优化。

• SQL开发效率的提升:基于Flink在语义上的优势解决配置、查询方面的问题,在性能、开发、维护方面做进一步优化。

• 新应用场景的探索:除流处理外,进一步整合业务场景下离线和在线数据,通过统一的API为业务提供更多的服务。

Flink和Spark流框架对比 + 华为流计算技术演进

华为云技术专家时金魁作为最后一位演讲嘉宾,系统性地梳理、比较了Flink/Spark的流框架,同时介绍了华为流计算技术演进过程,并详解了华为CloudStream的服务能力及应用。

时金魁一开始即列举了最常用的流计算框架Storm、Nifi、Spark和Flink等。提供了下面常见开源流计算框架以便大家了解这个生态圈的最新情况。

其中,华为云CloudStream同时支持Flink和Spark(Streaming和Structured Streaming)。时金魁提到,华为流计算团队在研发过程中发现,Spark Streaming能力有限,无法完全满足实时流计算场景,而华为自研多年的流框架生态不足,Storm日薄西山,所以华为在2016年转向Flink为主Spark为辅的组合。今年Spark Structured能力越来越丰富,与Flink之间的gap正快速缩小,也是幸事。

时金魁认为,流计算就是实时处理当下正在发生的流数据,逐条进行大数据分析或算法运算。它具备以下几个特征:

• 数据先后顺序不确定导致的乱序问题。

• 内存计算。

• 流速不定(数据大小不能预测),数据倾斜(分布不均匀),导致计算资源分配不均,能力受限。

• Long running 永远不结束。

• 基于消息事件的逐条处理。

• 提供可靠的快照。

从新技术、用户耐心、大数据增长几个方面,时金魁介绍了实时流计算最大限度挖掘数据的价值,是商业驱动和市场价值的一种体现。实时流计算具有丰富的使用场景,如实时商品的广告推荐、金融风控、交通物流、车联网、智慧城市等等。只要需要对实时的大数据推荐或者实时大数据分析,都能找到流计算的应用价值。

时金魁在演讲中重点讲解了数据流模型,即它是一个实时往下流的过程。在Flink中,客观的理解就是一个无限的数据流,提供分配和合并,并提供触发器和增量处理机制。如下图所示:

时金魁介绍说,对华为而言,Spark,Flink以及CloudStream,这三部分构成了LOGO中的“三条杠”,华为实时流计算服务俗称“华为云三道杠”,为客户主要提供云计算的服务。

通过对Flink的内核分析以及运行分析,他解释了如何实现一个完整的数据流处理过程:

• 解析:逻辑关系解析,生成StreamTransformation

• 分析:构建StreamGraph,DAG,为生成执行计划准备

• 生成:构建ExecutionGraph,为运行做准备

• 执行:申请资源,执行计划(算子)

• 最后生成数据流(DataStream)

下图是Flink的技术栈图,包括了一个完整的数据流框架:

此外,时金魁还对Flink和Spark做了详细的对比。Flink的优势包括具备成熟的数据流模型,能提供大量易用的API供使用,在SQL、Table、CEP、ML、Graph方面都提供完善的功能。对比之下,Spark拥有活跃的社区和完善的生态,Structured Streaming能提供统一标准,保证低延迟。

而华为根据Flink与Spark框架各自的特点,摒弃其劣势,设计开发出一款全新的实时流计算服务Cloud Stream Service(简称CS)。CS采用Apache Flink的Dataflow模型,实现完全的实时计算,同时采用在线SQL编辑平台编写的Stream SQL,自定义数据流入、数据处理、数据流出,并完全兼容Spark和Flink的API。

总结来说,Cloud Stream具有易用、按需计费、开箱即用、低延时(毫秒)高吞吐(百万消息每秒)、完整生态、完全可靠等几大优势。

例如,在易用性维度,Cloud Stream利用可视化的StreamSQL编辑器,因此可以方便地定义SQL,可在线调试和监控作业。

在安全性维度,华为实时流计算团队在行业首创了全托管的serverless独享集群模式。第一,它采用物理隔离,使得用户在作业运行时和资源上无共享,多用户之间无交叉;二是在业务上实现隔离,使得连接、数据和计算相互独立无干扰;三是沙箱在共享资源池中很难完全防语言、应用、OS等方面的共计,而且对Spark和Flink有一定的侵入性。

在线机器学习方面,CloudStream通过了流式随机森林算法应用于实时故障检测;通过特征工程应用于实时推荐;通过在线机器学习应用于智慧城市;通过地理分析函数应用于卡车运输位置检测。

到最近给大家推荐一个大数据学习qun:

猜你喜欢

转载自blog.csdn.net/qq_42002449/article/details/83188717