CN110928906A - 基于flink仅一次写入carbonData的方法 - Google Patents

Abstract

本发明提供一种基于flink仅一次写入carbonData的方法，包括以下步骤：1)、数据采集进入kafka；2)、flink使用BucketingSink将从kafka消费的数据进行处理后分桶以csv格式储存；3)、flink的checkPoint回调函数调用脚本储存的数据刷入carbonData。本发明的flink有很好的二次提交法的下沉数据支持。最后spark是微批处理的，flink是每来一条数据都能做处理，虽然现有方案能解决很多场景了，但是flink的处理机制会让这一切变得更加灵活，我们可以根据现实中的实际场景选择任意的方法来处理数据。

Description

基于flink仅一次写入carbonData的方法

技术领域

本发明涉及一种写入方法，具体涉及一种基于flink仅一次写入carbonData的方法。

背景技术

流式计算引擎(Flink)：flink是新生代的流式大数据计算引擎，说它是真正的流式是因为他是来一条数据立马处理的，并且也支持窗口等批业务需求的场景。另外内置多种数据结构的状态来满足业务上需要状态的场景。Flink通过check point的barrier对齐机制来实现内部的exactlyonce语义。反压机制也让它在流式计算中相对稳定。最早有成功的应用是在我国的阿里巴巴，那里有上万台的flink集群用于处理电商的实时推荐，搜索，大屏展示等等功能，并后续广泛在国内例如美团，腾讯，唯品会等大型公司有成功使用案例。

carbonData：Apache CarbonData是一种新型的大数据文件格式，使用先进的柱状存储、索引、压缩和编码技术，提高计算效率，在pb级数据上加快查询速度。根据apache官方的原话来看它的性能(it supports queries on a single table with 3PB data(morethan 5 trillion records)with response time less than 3 seconds！)

这里说在5万亿3pb的数据下单表查询不会超过3秒的响应时间，这就是cb的优势了。

现有技术为使用spark sreaming写入cb格式的数据：

cabonData和spark是强耦合的，所以sparkStreaming可以直接调用API写入。Spark streaming采用的是微批次的方式，拉入数据后也能准实时的写入cb。

现有技术的缺点为：首先spark对分流并不能很好的支持，因为它是批处理更加优势的技术，这样会导致当业务增多的时候会启动多个job占用比较大的资源，对中小型的集群十分不友好。再者sparkstreaming直接写cb没有很好的仅一次语义。

因此，需要对现有技术进行改进。

发明内容

本发明要解决的技术问题是提供一种高效的基于flink仅一次写入carbonData的方法。

为解决上述技术问题，本发明提供一种基于flink仅一次写入carbonData的方法，包括以下步骤：

1)、数据采集进入kafka；

2)、flink使用BucketingSink将从kafka消费的数据进行处理后分桶以csv格式储存；

3)、flink的checkPoint回调函数调用脚本储存的数据刷入carbonData。

作为对本发明基于flink仅一次写入carbonData的方法的改进：

步骤2中数据储存到第三方存储系统，第三方存储系统为hdfs。

作为对本发明基于flink仅一次写入carbonData的方法的进一步改进：

在步骤2中结合flink的checkPoint机制，手动提交offset以保证exactly once。

作为对本发明基于flink仅一次写入carbonData的方法的进一步改进：

flink的job manager决定做一次checkpoint的时候，会把barrier放入到流中，当所有处理流程都接收完这个barrier的时候，会通知本次的checkpoint完成了。

作为对本发明基于flink仅一次写入carbonData的方法的进一步改进：

通过check point外加文件名的状态来对exactly-once语义保证，通过引入中间状态in-progress及pending和最终可用状态finished来实现exactly once。

作为对本发明基于flink仅一次写入carbonData的方法的进一步改进：

使用spark程序，或者hive的bee line或者java程序，引入对应的依赖，进行查询。

本发明基于flink仅一次写入carbonData的方法的技术优势为：

本发明的flink有很好的二次提交法的下沉数据支持。最后spark是微批处理的，flink是每来一条数据都能做处理，虽然现有方案能解决很多场景了，但是flink的处理机制会让这一切变得更加灵活，我们可以根据现实中的实际场景选择任意的方法来处理数据。

本发明解决实时入库要求仅一次语义下的场景，以及脱离spark后如何写入大数据格式carbonData的数仓以支持高效率的复杂查询。几乎适用所有大数据行业，包括目前在用的明天鉴态势感知的数据中台，以及绝大多数传统的离线仓库

附图说明

下面结合附图对本发明的具体实施方式作进一步详细说明。

图1为本发明基于flink仅一次写入carbonData的方法的流程示意图。

具体实施方式

下面结合具体实施例对本发明进行进一步描述，但本发明的保护范围并不仅限于此。

实施例1、基于flink仅一次写入carbonData的方法，如图1所示，主要流程步骤是：

1)、数据采集进入kafka；

2)、flink使用BucketingSink将从kafka消费的数据进行处理后按照一定时间(天、小时、分钟等)分桶以csv格式写入第三方存储系统；

flink接入kafka管理kafka的消费offset，存储在flink的状态(state)中。结合flink的checkPoint机制，手动提交offset以保证exactly once；

3)、flink的checkPoint回调函数中调用脚本把第三方存储系统中储存的数据刷入carbonData。

数据采集进入kafka，之后flink接入kafka管理kafka的消费offset，然后结合flink的checkPoint机制，手动提交offset以保证exactly once。数据采用BucketingSink按照一定时间分桶以csv格式写入hdfs，然后再flink的checkPoint回调函数上写入把数据刷入carbonData。

步骤2中flink管理offset包括：

Flink支持各种格式的状态，并且有很好的checkpoint机制来保证在故障的时候能够恢复之前的状态，这是实现仅一次语义最重要的依赖。

Flink kafka consummer在消费到数据之后，需要对它进行状态的存储，可以用简单的map数据结构来存储每个分区下的offset，这样做checkpoint会把我们的offset状态刷新到设置的第三方存储系统中，比如说hdfs。当job manager(集群主节点)决定做一次checkpoint的时候，会把barrier放入到流中，当所有处理流程都接收完这个barrier的时候，会通知本次的checkpoint完成了。我们这时候调用flink的checkPoint回调函数来进行offset的提交和管理。提交之后我们可以把它存入到redis等第三方存储。另外也可以不用这么做，因为flink也支持从ck中来恢复作业。

但是这里要注意，需要开启flink的barrier对齐，因为Flink的可靠性机制是基于Chandy-Lamport这个算法的思想的改进版来实现的。引入了barrier，可以在不停止整个流处理系统的前提下，保存和恢复每个subtask的snapshot，让每个节点独立地做状态保存和恢复。所以kafka能指定消费的offset以及flink的检查点机制让我们很容易实现这部分的exactly once机制。

步骤2中flink进行数据的清洗和转换包括：

使用flink的好处就是：可以很容易的在采集入库之前做etl工作。Flink提供丰富的算子让我们对数据进行预先处理。比如可以调用stream.filter(fn)过滤掉一些垃圾数据，也可以根据黑白名单把这些数据单独的提取出来。或者调用stream.map(fn)来进行一些数据的转换，转换成想要的字段格式。也可以调用stream.join(s2)来进行一些关联，关联到其他表的数据。当然这些是灵活的，需要根据业务场景在这个阶段做不同的事情。这一步基本上是大数据领域必须做的事情。

步骤2中使用BucketingSink插入数据到HDFS，利用回调函数刷到carbonData：

Flink提供bucketingSink算子来操作hdfs，只需要在之前把流数据处理成csv的格式，然后分桶写入hdfs。这个阶段如何保证exactly once呢，flink写入文件的时候，文件会分为下述三种状态：

1)、in-progress：分桶下正在被写入的文件，一个分桶只会有一个。

2)、pending：in-progress状态的文件关闭后进入pending状态，文件重命名，等待Checkpoint。

3)、Finished：Checkpoint成功之后，pending状态的文件即可置为finished状态，文件重命名，该状态的文件即为最终产生的可用文件；

通过check point外加文件名的状态来对exactly-once语义保证，通过引入中间状态(in-progress及pending)和最终可用状态(finished)来实现的，这是一种两阶段提交(2PC)的方案，即预先提交，预先提交虽然写入了但是却给了标识，表示这不是真正的数据。当故障发生时，对处于中间状态的数据进行回滚，正因为有了标识我们很容易的找出未完成的数据，这部分数据不在checkpoint中，可以放心的对它进行回滚。数据只有流转(Checkpoint成功)到最终状态，这时候我们才会认为它是可靠的数据，并且因为checkpoint已经完成这部分数据不会重复写。

步骤3在checkpoint的自定义函数上把数据刷到carbonData包括：

数据写好之后，这一次的checkPoint就会结束，这时候可以改写flink的checkPoint回调函数，可以在checkPoint回调函数里面添加一些逻辑，比如说调用一个shell命令，那么可以把已经写好的文件刷到carbonData里面去，具体的命令格式如下所示：

LOAD DATA INPATH$path INTO TABLE$tableName OPTIONS('DELIMITER'＝'\u0004'，'COMPLEX_DELIMITER_LEVEL_1'＝'\u0001'，'BAD_RECORDS_ACTION'＝'fail'，'HEADER'＝'false'，'MULTILINE'＝'true'，'QUOTECHAR'＝'\"')

这里没有列出全部的参数可以在官网上查到(例如参数可以从hive官网上查到)。其中path就是csv的文件目录，tableName是要插入数据库的表，并且指定了csv文件的分隔符为\004，数组结构的分割符为\001。这样就能把数据载入到Carbondata了。

如果样例数据里面包含了若干carbondata的关键字，那么可以定义指定的转义符号，只需要在flink的程序中对这些数据进行处理，在这些符号的前面加上对应的转移符号。

高性能的查询：

接下来可以在很多地方对这些carbondata的数据进行查询了，比如说可以直接使用任何spark程序，或者hive的bee line或者java程序，只需要引入对应的依赖。Carbondata的特点如下：

File Header：

文件头File Header的格式比较简单，保存了存储格式的版本和模式信息。(这部分通常是稳定不可变的内容)

Blocklet

单Blocklet最大的容量阀值为64M，也就是说单个HDFS的Block可以容纳多个Blocklet(视Block的大小而定)。这块内容与ORCFile与Parquet的设计一脉相承，都是利用Pax的存储模型来优化数据查询时的性能表现。

File Footer

在文件尾部File Header保存了存储数据的索引和摘要，索引是CarbonData最为核心的关键实现，正是由于索引的存在，大大提高了CarbonData在不同查询场景之下的性能表现。并且它还设计了二级索引又一次提高了数据的查询性能。

具体实例：

接入安全告警这一类数据，数据由flume从软硬探针syslog中采集到kafka里面，flink消费kafka数据把offset存入状态中(状态可以设置为hdfs或者本地文件)。接着用BucketingSink来按小时写入数据，BucketingSink用了一个状态记录所有文件的当前状态，可以从中获取文件是否已经写完，notifyCheckpointComplete方法可以在接收到checkpoint后对这些状态进行判断，可以在这个方法中加入自己的逻辑，当状态为完成的时候，触发脚本把数据load进入hdfs。这样就完成了入库的工作。

术语仅一次语义：数据仅仅在实时计算中被处理一次不重复也不丢弃

术语flink：近两年兴起的流式处理引擎

术语hdfs：分布式存储系统

术语carbonData：新兴apache顶级项目，支持索引的数据结构，查询极快。

术语exactly once：仅一次语义，表示分布式流数据在处理过程中不会因为机器故障，网络抖动等不良因素造成重复消费或者数据丢失。

最后，还需要注意的是，以上列举的仅是本发明的若干个具体实施例。显然，本发明不限于以上实施例，还可以有许多变形。本领域的普通技术人员能从本发明公开的内容直接导出或联想到的所有变形，均应认为是本发明的保护范围。

Claims (6)

1.基于flink仅一次写入carbonData的方法，其特征在于：包括以下步骤：

1)、数据采集进入kafka；

2)、flink使用BucketingSink将从kafka消费的数据进行处理后分桶以csv格式储存；

3)、flink的checkPoint回调函数调用脚本储存的数据刷入carbonData。

2.根据权利要求1所述的基于flink仅一次写入carbonData的方法，其特征在于：

步骤2中数据储存到第三方存储系统，第三方存储系统为hdfs。

3.根据权利要求2所述的基于flink仅一次写入carbonData的方法，其特征在于：

在步骤2中结合flink的checkPoint机制，手动提交offset以保证exactly once。

4.根据权利要求3所述的基于flink仅一次写入carbonData的方法，其特征在于：

flink的job manager决定做一次checkpoint的时候，会把barrier放入到流中，当所有处理流程都接收完这个barrier的时候，会通知本次的checkpoint完成了。

5.根据权利要求4所述的基于flink仅一次写入carbonData的方法，其特征在于：

通过check point外加文件名的状态来对exactly-once语义保证，通过引入中间状态in-progress及pending和最终可用状态finished来实现exactly once。

6.根据权利要求5所述的基于flink仅一次写入carbonData的方法，其特征在于：

使用spark程序，或者hive的bee line或者java程序，引入对应的依赖，进行查询。

Images