为您推荐:
精华内容
最热下载
问答
  • 4星
    35.37MB qq_45497280 2020-11-19 14:38:44
  • 本文分为四个章节介绍实时计算,第一节介绍实时计算出现的原因及概念;第二节介绍实时计算的应用场景;第三节介绍实时计算常见的架构;第四节是实时数仓解决方案。 一、实时计算 实时计算一般都是针对海量数据...

    本文分为四个章节介绍实时计算,第一节介绍实时计算出现的原因及概念;第二节介绍实时计算的应用场景;第三节介绍实时计算常见的架构;第四节是实时数仓解决方案。

    一、实时计算

    实时计算一般都是针对海量数据进行的,并且要求为秒级。由于大数据兴起之初,Hadoop并没有给出实时计算解决方案,随后Storm,SparkStreaming,Flink等实时计算框架应运而生,而Kafka,ES的兴起使得实时计算领域的技术越来越完善,而随着物联网,机器学习等技术的推广,实时流式计算将在这些领域得到充分的应用。

    实时计算的三个特征:

    1. 无限数据:无限数据指的是一种不断增长的,基本上无限的数据集。这些通常被称为“流数据”,而与之相对的是有限的数据集。

    2. 无界数据处理:一种持续的数据处理模式,能够通过处理引擎重复的去处理上面的无限数据,是能够突破有限数据处理引擎的瓶颈的。

    3. 低延迟:延迟是多少并没有明确的定义。但我们都知道数据的价值将随着时间的流逝降低,时效性将是需要持续解决的问题。

    现在大数据应用比较火爆的领域,比如推荐系统在实践之初受技术所限,可能要一分钟,一小时,甚至更久对用户进行推荐,这远远不能满足需要,我们需要更快的完成对数据的处理,而不是进行离线的批处理。

    二、实时计算应用场景

    随着实时技术发展趋于成熟,实时计算应用越来越广泛,以下仅列举常见的几种实时计算的应用常见:

    1. 实时智能推荐

    图片

    智能推荐会根据用户历史的购买或浏览行为,通过推荐算法训练模型,预测用户未来可能会购买的物品或喜爱的资讯。对个人来说,推荐系统起着信息过滤的作用,对Web/App服务端来说,推荐系统起着满足用户个性化需求,提升用户满意度的作用。推荐系统本身也在飞速发展,除了算法越来越完善,对时延的要求也越来越苛刻和实时化。利用Flink流计算帮助用户构建更加实时的智能推荐系统,对用户行为指标进行实时计算,对模型进行实时更新,对用户指标进行实时预测,并将预测的信息推送给Web/App端,帮助用户获取想要的商品信息,另一方面也帮助企业提升销售额,创造更大的商业价值。

    2. 实时欺诈检测

    图片

    在金融领域的业务中,常常出现各种类型的欺诈行为,例如信用卡欺诈,信贷申请欺诈等,而如何保证用户和公司的资金安全,是近年来许多金融公司及银行共同面对的挑战。随着不法分子欺诈手段的不断升级,传统的反欺诈手段已经不足以解决目前所面临的问题。以往可能需要几个小时才能通过交易数据计算出用户的行为指标,然后通过规则判别出具有欺诈行为嫌疑的用户,再进行案件调查处理,在这种情况下资金可能早已被不法分子转移,从而给企业和用户造成大量的经济损失。而运用Flink流式计算技术能够在毫秒内就完成对欺诈行为判断指标的计算,然后实时对交易流水进行实时拦截,避免因为处理不及时而导致的经济损失。

    3. 舆情分析

    图片

    有的客户需要做舆情分析,要求所有数据存放若干年,舆情数据每日数据量可能超百万,年数据量可达到几十亿的数据。而且爬虫爬过来的数据是舆情,通过大数据技术进行分词之后得到的可能是大段的网友评论,客户往往要求对舆情进行查询,做全文本搜索,并要求响应时间控制在秒级。爬虫将数据爬到大数据平台的Kafka里,在里面做Flink流处理,去重去噪做语音分析,写到ElasticSearch里。大数据的一个特点是多数据源,大数据平台能根据不同的场景选择不同的数据源。

    4. 复杂事件处理

    图片

    对于复杂事件处理,比较常见的集中于工业领域,例如对车载传感器,机械设备等实时故障检测,这些业务类型通常数据量都非常大,且对数据处理的时效性要求非常高。通过利用Flink提供的CEP进行时间模式的抽取,同时应用Flink的Sql进行事件数据的转换,在流式系统中构建实施规则引擎,一旦事件触发报警规则,便立即将告警结果通知至下游通知系统,从而实现对设备故障快速预警检测,车辆状态监控等目的。

    5. 实时机器学习

    图片

    实时机器学习是一个更宽泛的概念,传统静态的机器学习主要侧重于静态的模型和历史数据进行训练并提供预测。很多时候用户的短期行为,对模型有修正作用,或者说是对业务判断有预测作用。对系统来说,需要采集用户最近的行为并进行特征工程,然后给到实时机器学习系统进行机器学习。如果动态地实施新规则,或是推出新广告,就会有很大的参考价值。

    三、实时计算架构

    我们先来看一张大数据平台的实时架构图:

    图片

    • 数据同步:

    在上面这张架构图中,数据从Web平台中产生,通过数据同步系统导入到大数据平台,由于数据源不同,这里的数据同步系统实际上是多个相关系统的组合。数据库同步通常用 Sqoop,日志同步可以选择 Flume等,不同的数据源产生的数据质量可能差别很大,数据库中的格式化数据直接导入大数据系统即可,而日志和爬虫产生的数据就需要进行大量的清洗、转化处理才能有效使用。

    • 数据存储:

    该层对原始数据、清洗关联后的明细数据进行存储,基于统一的实时数据模型分层理念,将不同应用场景的数据分别存储在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存储中。

    • 数据计算:

    计算层主要使用 Flink、Spark、Presto 以及 ClickHouse 自带的计算能力等四种计算引擎,Flink 计算引擎主要用于实时数据同步、 流式 ETL、关键系统秒级实时指标计算场景,Spark SQL 主要用于复杂多维分析的准实时指标计算需求场景,Presto 和 ClickHouse 主要满足多维自助分析、对查询响应时间要求不太高的场景。

    • 实时应用:

    以统一查询服务对各个业务线数据场景进行支持,业务主要包括实时大屏、实时数据产品、实时 OLAP、实时特征等。

    当然一个好的大数据平台不能缺少元数据管理及数据治理:

    1. 元数据及指标管理:主要对实时的Kafka表、Kudu表、Clickhouse表、Hive表等进行统一管理,以数仓模型中表的命名方式规范表的命名,明确每张表的字段含义、使用方,指标管理则是尽量通过指标管理系统将所有的实时指标统一管理起来,明确计算口径,提供给不同的业务方使用;

    2. 数据质量及血缘分析:数据质量分为平台监控和数据监控两个部分,血缘分析则主要是对实时数据依赖关系、实时任务的依赖关系进行分析。

    以上架构只是大数据平台通用的数据模型,如果要具体的建设,需要考虑以下情况,业务需求需要实时还是准实时即可,数据时效性是秒级还是分钟级等。

    • 调度开销方面,准实时数据是批处理过程,因此仍然需要调度系统支持,调度频率较高,而实时数据却没有调度开销;

    • 业务灵活性方面,因为准实时数据是基于 ETL 或 OLAP 引擎实现,灵活性优于基于流计算的方式;

    • 对数据晚到的容忍度方面,因为准实时数据可以基于一个周期内的数据进行全量计算,因此对于数据晚到的容忍度也是比较高的,而实时数据使用的是增量计算,对于数据晚到的容忍度更低一些;

    • 适用场景方面,准实时数据主要用于有实时性要求但不太高、涉及多表关联和业务变更频繁的场景,如交易类型的实时分析,实时数据则更适用于实时性要求高、数据量大的场景,如实时特征、流量类型实时分析等场景。

    实时架构

    在某些场景中,数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上,逐渐对数据的实时性提出了更高的要求。

    于是随之诞生了大数据实时数仓,并且衍生出了两种技术架构Lambda和Kappa。

    1. Lambda架构

    先来看下Lambda架构图:

    图片

    Lambda架构图

    数据从底层的数据源开始,经过Kafka、Flume等数据组件进行收集,然后分成两条线进行计算:

    • 一条线是进入流式计算平台(例如 Storm、Flink或者SparkStreaming),去计算实时的一些指标;

    • 另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive,Spark SQL),去计算T+1的相关业务指标,这些指标需要隔日才能看见。

    为什么Lambda架构要分成两条线计算?

    假如整个系统只有一个批处理层,会导致用户必须等待很久才能获取计算结果,一般有几个小时的延迟。电商数据分析部门只能查看前一天的统计分析结果,无法获取当前的结果,这对于实时决策来说有一个巨大的时间鸿沟,很可能导致管理者错过最佳决策时机。

    Lambda架构属于较早的一种架构方式,早期的流处理不如现在这样成熟,在准确性、扩展性和容错性上,流处理层无法直接取代批处理层,只能给用户提供一个近似结果,还不能为用户提供一个一致准确的结果。因此Lambda架构中,出现了批处理和流处理并存的现象。

    在 Lambda 架构中,每层都有自己所肩负的任务。

    1. 批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图:

    批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的,能够修复任何错误,然后更新现有的数据视图。输出通常存储在只读数据库中,更新则完全取代现有的预先计算好的视图。

    2. 流处理层会实时处理新来的大数据:

    流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整,但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后,在速度层的数据就可以被替代掉了。

    那Lambda架构有没有缺点呢?

    Lambda架构经历多年的发展,其优点是稳定,对于实时计算部分的计算成本可控,批量处理可以用晚上的时间来整体批量计算,这样把实时计算和离线计算高峰分开,这种架构支撑了数据行业的早期发展,但是它也有一些致命缺点,并在大数据3.0时代越来越不适应数据分析业务的需求。缺点如下:

    • 使用两套大数据处理引擎:维护两个复杂的分布式系统,成本非常高。

    • 批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

    • 数据源变化都要重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都需要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不够迅速。

    导致 Lambda 架构的缺点根本原因是要同时维护两套系统架构:批处理层和速度层。我们已经知道,在架构中加入批处理层是因为从批处理层得到的结果具有高准确性,而加入速度层是因为它在处理大规模数据时具有低延时性。

    那我们能不能改进其中某一层的架构,让它具有另外一层架构的特性呢?

    例如,改进批处理层的系统让它具有更低的延时性,又或者是改进速度层的系统,让它产生的数据视图更具准确性和更加接近历史数据呢?

    另外一种在大规模数据处理中常用的架构——Kappa 架构,便是在这样的思考下诞生的。

    2. Kappa架构

    Kafka的创始人Jay Kreps认为在很多场景下,维护一套Lambda架构的大数据处理平台耗时耗力,于是提出在某些场景下,没有必要维护一个批处理层,直接使用一个流处理层即可满足需求,即下图所示的Kappa架构:

    图片

    Kappa架构

    这种架构只关注流式计算,数据以流的方式被采集过来,实时计算引擎将计算结果放入数据服务层以供查询。可以认为Kappa架构是Lambda架构的一个简化版本,只是去除掉了Lambda架构中的离线批处理部分

    Kappa架构的兴起主要有两个原因

    • Kafka不仅起到消息队列的作用,也可以保存更长时间的历史数据,以替代Lambda架构中批处理层数据仓库部分。流处理引擎以一个更早的时间作为起点开始消费,起到了批处理的作用。

    • Flink流处理引擎解决了事件乱序下计算结果的准确性问题。

    Kappa架构相对更简单,实时性更好,所需的计算资源远小于Lambda架构,随着实时处理的需求在不断增长,更多的企业开始使用Kappa架构。但这不意味着kappa架构能够取代Lambda架构

    Lambda和kappa架构都有各自的适用领域;例如流处理与批处理分析流程比较统一,且允许一定的容错,用Kappa比较合适,少量关键指标(例如交易金额、业绩统计等)使用Lambda架构进行批量计算,增加一次校对过程。

    还有一些比较复杂的场景,批处理与流处理产生不同的结果(使用不同的机器学习模型,专家系统,或者实时计算难以处理的复杂计算),可能更适合Lambda架构。

    四、实时数仓解决方案

    实时数仓分层架构为了避免面向需求响应的烟囱式构建,实时数仓也引入了类似于离线数仓的分层理念,主要是为了提高模型的复用率,同时也要考虑易用性、一致性以及计算成本。

    当然实时数仓的分层架构在设计上并不会像离线数仓那么复杂,避免数据在流转过程中造成的不必要的延时响应

    实时数仓分层架构图:

    图片

    实时数仓分层架构

    1. ODS层:以Kafka为支撑,将所有需要实时处理的相关数据放到Kafka队列中来实现贴源数据层;

    2. DWD层:实时计算订阅业务数据消息队列,然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合,将一些相同粒度的业务系统、维表中的维度属性全部关联到一起,增加数据易用性和复用性,得到最终的实时明细数据;

    3. DIM层:存放用于关联查询的维度信息,可以根据数据现状来选择存储介质,例如使用HBase或者Mysql

    4. DWS层:轻度汇总层是为了便于面向AdHoc查询或者Olap分析构建的轻度汇总结果集合,适合数据维度、指标信息比较多的情况,为了方便根据自定义条件的快速筛选和指标聚合,推荐使用MPP类型数据库进行存储,此层可视场景情况决定是否构建;

    5. APP层:面向实时数据场景需求构建的高度汇总层,可以根据不同的数据应用场景决定使用存储介质或者引擎;例如面向业务历史明细、BI支持等Olap分析场景,可以使用Druid、Greenplum,面向实时监控大屏、高并发汇总指标等需求,可以使用KV模式的HBase;数据量较小的时候,也可以使用Mysql来进行存储。

    这里要注意下,其实APP层已经脱离了数仓,这里虽然作为了数仓的独立分层,但是实际APP层的数据已经分布存储在各种介质中用于使用。

    基于Flink 构建的实时数仓

    随着业务场景的丰富,更多的实时需求不断涌现,在追求实时任务高吞吐低延迟的同时,对计算过程中间状态管理,灵活时间窗口支持,以及 exactly once 语义保障的诉求也越来越多。

    为什么选择Flink实时计算平台?之所以选择用Flink替代原有Storm、SparkStreaming是基于以下原因考虑的,这也是实时数仓关注的核心问题:

    1. 高吞吐、低延时;

    2. 端到端的 Exactly-once,保证了数据的准确性;

    3. 可容错的状态管理,实时数仓里面会进行很多的聚合计算,这些都需要对于状态进行访问和管理;

    4. 丰富的API,对Streaming/Table/SQL支持良好,支持UDF、流式join、时间窗口等高级用法;

    5. 完善的生态体系,实时数仓的构建会涉及多种存储,Flink在这方面的支持也比较完善。

    基于Flink的实时数仓数据流转过程:

    图片

    实时数仓数据流转过程

    数据在实时数仓中的流转过程,实际和离线数仓非常相似,只是由Flink替代Hive作为了计算引擎,把存储由HDFS更换成了Kafka,但是模型的构建思路与流转过程并没有发生变化。

    展开全文
    helloHbulie 2021-07-11 16:34:19
  • 简介:实时计算 Flink 版(Alibaba Cloud Realtime Compute for Apache Flink,Powered by Ververica)是阿里云基于 Apache Flink 构建的企业级、高性能实时大数据处理系统,由 Apache Flink 创始团队官方出品,拥有...
    简介:实时计算 Flink 版(Alibaba Cloud Realtime Compute for Apache Flink,Powered by Ververica)是阿里云基于 Apache Flink 构建的企业级、高性能实时大数据处理系统,由 Apache Flink 创始团队官方出品,拥有全球统一商业化品牌,完全兼容开源 Flink API,提供丰富的企业级增值功能。

    本文整理自直播《实时计算 Flink 版总体介绍 》
    视频链接:https://developer.aliyun.com/learning/course/795

    Apache Flink技术发展

    大数据的高速发展已经超过10年,大数据也正在从计算规模化向更加实时化的趋势演进。

    比如阿里巴巴举办的购物狂环节双11,可以通过实时大屏展示整个双11实时的交易额、成交额,并可实现毫秒级的更新;全球华人都会观看的中央电视台春节联欢晚会,可以通过春晚大屏,实时统计全国的收视率与观众画像;现在多个城市都有的城市大脑项目,通过 IoT的摄像头信息,实时捕获各个城市中的交通、车辆、人流等信息去做交通的监察和治理;还有金融行业,在银行、证券交易所等机构的核心业务场景下,也都在通过大数据实时计算能力实时监控交易行为,进行反作弊反洗钱等行为的探测;除此之外,在整个淘宝电商交易的场景下,实时根据用户的行为进行个性化推荐,基于用户在前一分钟或者30秒内浏览商品情况,在后续的浏览中系统就会根据算法测算用户画像,然后实时向用户推荐可能会喜欢的相关商品等。可以说这么多日常生活中涉及的场景,背后都是由实时计算在推动生产力的提升,日夜不息。

    实时计算需要后台有一套极其强大的大数据计算能力,Apache Flink作为一款开源大数据实时计算技术应运而生。它从设计之初就由流计算开启,因为传统的Hadoop、Spark等计算引擎,本质上是批计算引擎,通过对有限的数据集进行数据处理,其处理延时性是不能保证的。而Apache Flink作为流式计算引擎,它可以实时订阅实时产生的现实数据,并实时对数据进行分析处理并产生结果,让数据在第一时间发挥价值。

    目前Apache Flink也从流计算的引擎逐渐拥有流批一体的计算能力,可以通过日志流,点击流,IoT数据流等进行流式的分析处理,同时也可以对数据库和文件系统中的文件等有限数据集进行批式的数据处理,快速分析结果。Apache Flink 现在是开源社区中非常流行的一个开源大数据技术,并且连续三年成为Apache开源项目中全球活跃度最高的项目之一。它具备强一致性的计算能力、大规模的扩展性,整体性能非常卓越,同时支持SQL、Java、Python等多语言,拥有丰富的API接口方便各种场景业务使用。目前国内外互联网企业中Flink已经成为主流的实时大数据计算技术,是实时计算领域的事实技术标准。

    阿里云实时计算 Flink 版产品,在阿里巴巴集团内部历经多年锤炼和验证,积累了丰富的技术和产品,现已经提供到云上,为各行各业中小企业提供云计算服务。早在2016年,Apache Flink刚刚捐献给Apache之后的第三年,阿里已经开始大规模上线使用实时计算产品了。这个产品最早上线于阿里最核心的搜索推荐以及广告业务场景,在这个场景下我们需要大量的数据实时化的处理,比如实时推荐、实时排序、实时广告等,对整个电商的核心业务有非常大的提升。

    产品发展史

    2017年,基于 Flink 的实时计算平台产品,开始服务于整个阿里巴巴集团,同年双11服务全集团的数据实时化,包括最核心的双11的大屏。在2018年产品正式上云,不仅服务集团内,同时开始服务云上中小企业,这也是第一次将实时计算 Flink 的产品以公共云的形式对外提供服务。

    2019年初,阿里巴巴收购了 Flink 的创始公司 - Ververica,阿里的 Flink 技术团队-实时计算技术团队和德国总部的Flink创始团队顺利会师,成为了全球 Flink 技术最强的团队,也共同推进了整个Apache Flink 开源社区的发展和贡献。目前中国Apache Flink社区有超过20w的开发者参与到社区中,Flink成为Apache基金会大数据领域最活跃的项目之一。

    去年,在全球主流的云计算公司和大数据公司,都大量采用 Flink 的技术推出了自己的 Flink 产品。比如借Hadoop起家的Cloudera也推出全面集成了 Flink 的CDP/CDH,国内的大数据公司也陆续推出了基于 Flink 的实时计算产品。

    实时计算Flink版产品架构

    阿里云的实时计算产品架构和开源版本相比较,有很大的提高和增值。现在很多开发者在自建机房或者云上虚拟机作业时都会使用开源的Apache Flink 去搭建自己的实时计算平台。那么阿里云官方推出的实时计算Flink产品,它的特色是什么呢?

    产品架构

    根据整个产品的架构图,最底层是基于阿里云的完善的云原生的基础设施,通过容器化来构建一套实时计算 Flink 的产品,所有的 Flink 的计算任务都运行在Kubernetes的生态之上,以容器化的方式进行多租户的隔离,保障安全。同时它又是全托管的服务形态,在云上提供高SLA保证的全托管服务,免除用户运维的烦恼。并搭配service架构,用户可以更灵活的判断各类资源的占比,完全配合自己的业务量来选择,无需为机器的规划而烦恼。实时计算 Flink 版产品是一套天然的云原生基础架构。

    在核心计算引擎上,相对于开源的Apache Flink 阿里云进行了多处核心功能的优化,这些优化也通过了阿里内部业务的锤炼。目前实时计算 Flink 产品,支持了阿里集团将近100个事业部的实时数据服务。通过大量业务实践,产品在支持存储,调度、网络传输等方面,都调试到最佳效果。

    插件方面,产品内置几十种增强型的Connector,可以对接所有主流的开源数据存储包括云上像MySQL、 HBase、HDFS、阿里云SLS等,天然集成、开箱即用。开发平台方面,提供企业级的一站式的开发平台,自带开发和运维能力,免除自建烦恼,提高企业用户整体使用感受。

    实时计算 Flink版支持SQL、Java、Python 等多语言开发环境,提供开发任务的全生命周期管理,可支持基于OIDC和RBAC的企业级安全机制,并且拥有基于Prometheus协议的全链路监控报警,同时提供自有AutoPilot的智能调优系统,智能地帮助用户去对 Flink 任务进行参数的调优,包括资源的调优和并发度的调优。产品完全可以去自适应业务的流量,不需要人工做任何的调试(智能调优是实时计算Flink版产品的核心优势)

    实时计算Flink版与开源Apache Flink的区别

    实时计算 Flink 版的产品相对于开源产品,具有数10项的性能优势,通过开发、运维、成本、安全等角度进行对比。

    产品对比

    开发方面具备丰富的数据连接能力和一站式的多语言的开发环境,内置多种函数库,方便用户进行代码调试,还可以进行多租户的开发,任务的调试,测试的模拟等等。运维方面支持全链路的监控报警,用户在使用过程中出现的数据延迟、数据异常、服务中断等都可以进行自动报警。

    智能运维方面支持自动化的智能诊断和调优,能够根据业务流量自动帮用户进行性能调优、作业调优、参数调优和资源调优等,针对问题可以进行诊断优化。资源层面在开源的基础上,做到了更细粒度和更精细化的资源的调配,使得每个作业每个算子都可以在CPU和内存粒度上进行配置,大幅优化资源的利用率,帮助用户节省成本,提升服务的稳定性,降低OM的概率。搭配原厂的运维兜底服务,SLA 99.9%的保证,以及全链路的容错能力,系统稳定性的保证,充分解决用户后顾之忧。

    成本层面,通过云上成本优化,在性能提升的同时降低用户整体的TCO,这也是核心性能的优势。

    基于NexMark的流计算的标准测试中,实时计算 Flink 版的产品性能约为开源的3倍,依托阿里集团强大的研发团队在内部核心业务场景下积累的实践优化,使得产品在降低用户的基础成本上,突出核心优势。

    实时计算Flink版还具备云原生的弹性扩容能力,可帮助用户合理地节省资源,提高资源利用率。产品付费类型支持包年包月付费,也支持按量付费,更好地适配不同需求。

    安全层面通过容器化的任务隔离,提高用户使用感受,并且支持租户隔离、安全隔离、VPC隔离等等多种需求。同时与阿里的账号体系直接打通,用户可以基于阿里云的账号无缝进行产品之间的安全管控,也支持基于角色、OIDC这种开放的身份认证协议,大大提高业务的安全性。

    整体来说,企业版相对于开源版具有更优势的功能性和稳定性,除了运维方面的优势,开箱即用也让用户更加方便。

    产品解决方案

    产品解决方案

    Flink 作为实时计算的一个流式计算引擎,可以处理多种实时数据,包括ECS在线服务日志,IoT场景下传感器数据等各类实时数据。同时可以订阅云上数据库RDS、PolarDB等这种关系型数据库中 binlog的更新。再通过DataHub数据总线产品、SLS日志服务、开源的Kafka消息队列产品等将实时数据进行订阅,收录进实时计算产品中,进行实时的数据分析和处理。最终将分析结果写入不同的数据服务中,比如MaxCompute、MaxCompute-Hologres交互式分析、PAI机器学习、Elasticsearch等产品中,根据业务需求选择最佳数据服务产品,提高数据利用率。

    Flink主要的应用场景就是将各种不同的实时数据源中的数据进行实时的订阅、处理、分析,并把得到的结果写入到其他的在线存储之中,让用户直接生产使用。整个系统具有速度快,数据准,云原生架构以及智能化等特点,是一款非常具有竞争力的企业级的产品。产品运行在阿里云的容器服务ECS等IaaS系统上,跟阿里云的各项系统天然打通,方便客户适用更多场景。

    产品应用场景

    基于实时计算 Flink 版产品总结出4大应用场景,方便用户根据需求轻松构建自己的业务实时计算解决方案。

    产品应用场景

    1、实时数仓

    实时数仓主要应用在网站pv/uv统计、商品销量统计、交易数据统计等各类交易型数据场景中。通过订阅业务实时数据源,将信息实时秒级分析,最终呈现在大屏幕中给决策者使用,方便判断企业经营状况和活动促销的情况。根据实时的商业运营数据作出决策,做到真正数据智能。因场景的特殊性,实时数据尤为重要,在瞬息万变的业务互动中需要对上一分钟甚至上一秒钟发生的数据进行分析决策,实时计算是这种场景下最好的选择。

    2、实时推荐

    实时推荐主要是根据用户喜好进行个性化推荐或者基于AI技术进行推荐,是一个主流的产品形态。常见于短视频场景,电商购物场景,内容资讯场景等,通过之前的用户点击情况实时判断用户喜好,从而进行针对性推荐,增加用户粘性。这种是实时性非常强的场景,可以通过Flink 技术结合AI技术进行实时推荐场景的运作。

    3、ETL场景

    实时的ETL场景常见于数据同步作业中,在数据同步的过程中还要做数据计算处理。比如数据库中不同表的同步、转化、不同数据库的同步,或者是进行数据聚合预处理等操作。最终将结果写入数仓/数据湖进行归档沉淀,为后续深度分析进行前期准备工作,方便用户进行后续的日志类分析等操作。在整个的数据同步和处理链路上,基于 Flink 做这种实时化数据的同步和预处理是非常高效的。

    4、实时监控

    实时监控常见于金融类或者是交易类业务场景下,针对行业的独特性,需要有商业化的反作弊监管,根据实时短时间之内的行为,判定用户是否为作弊用户,做到及时止损。该场景对时效性要求极高,通过对异常数据检测,可以实时发现异常情况而做出一个止损的行为。收集 指标或者日志等统计各个系统的指标,对指标进行实时的观察和监控等等需求场景,都是可以通过实时计算 Flink 产品解决的。

    产品官网:https://www.aliyun.com/product/bigdata/sc


    原文链接:https://developer.aliyun.com/article/784301?

    版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
    展开全文
    alitech2017 2021-06-11 11:26:15
  • 简介:如何使用实时计算 Flink 搞定实时数据处理难题?本文由阿里巴巴高级技术专家邓小勇老师分享,从实时计算的历史回顾着手,详细介绍了阿里云实时计算 Flink 的核心优势与应用场景,文章内容主要分为以下四部分:...
    简介:如何使用实时计算 Flink 搞定实时数据处理难题?本文由阿里巴巴高级技术专家邓小勇老师分享,从实时计算的历史回顾着手,详细介绍了阿里云实时计算 Flink 的核心优势与应用场景,文章内容主要分为以下四部分:历史回眸、选择理由、产品介绍、未来可期

    作者:邓小勇(静行)

    摘要:
    如何使用实时计算 Flink 搞定实时数据处理难题?本文由阿里巴巴高级技术专家邓小勇老师分享,从实时计算的历史回顾着手,详细介绍了阿里云实时计算 Flink 的核心优势与应用场景,文章内容主要分为以下四部分:

    ● 历史回眸
    ● 选择理由
    ● 产品介绍
    ● 未来可期

    众所周知,阿里云的 Slogan 是“计算是为了无法计算的价值”。计算的实体是数据,但是随着时间的推移,数据的价值其实是逐渐递减的。如何从数据产生开始,尽早地发掘它的最大价值,成为实时计算不懈追求的目标。

    随着技术的发展, Flink 已经成为实时计算的工业标准,越来越多的公司正在使用 Flink 作为自己实时计算的工具。在实时计算领域,阿里云也在不断地探索,并推出了实时计算 Flink 的产品。

    本篇内容将通过四个方面,围绕云上实时计算 Flink 向大家展开介绍。

    一、 实时计算的历史回顾

    (一)实时计算发展时间轴

    2013年

    阿里内部已经上线了一些实时计算的典型场景,比如搜索引擎实时增量索引等等。

    2015年

    阿里建设了一个实时计算平台并在内部上线,并承接了当年双11 GMV大屏等关键业务。这些业务的开展,开启了实时计算 Flink 在阿里巴巴的发展。

    2016年7月

    实时计算1.0版本公测。采用Galaxy(基于Storm引擎开发),打响了实时计算上云的第一枪,比业界其他产品都要早。

    image.png

    2017年10月

    阿里基于 Blink 引擎的实时计算2.0版本上线并公测。该版本是基于大集群的全托管,只能运行SQL。当时用户的环境需要VPC,在这种大集群的情况下,要跟不同用户的VPC打通是一个比较大的问题。同时,由于是大集群,无法做到很好的隔离,也就意味着对SQL里面的UDF以及DataStream这些用户自定义逻辑互不影响得运行,所以只能推出纯SQL的作业模式。

    2018年10月

    实时计算2.0独享模式商业化。独享模式是指每个用户拥有独立的小集群,每个小集群跟用户的VPC通过 ENI无缝连接。在这种情况下,既做到了跟用户 VPC内上下游的连接,同时又能做好的物理隔离,解决了大集群很多功能限制的问题。

    2019年的9月

    实时计算基于 Flink 3.0半托管模式公测。由于一些大用户,需要对整个运行环境需要有比较好的掌控,于是我们推出了基于VVP(Ververica Platform)的实时计算半托管模式,即实时计算3.0半托管版本。这个版本是基于中德合作共建的一站式平台VVP,主要支持Yarn和K8S两大主流的调度引擎。用户可以登录K8S或者Yarn,去操作和管控自己的任务,同时也能享受到VVP提供的一些增值服务。

    2020年5月

    实时计算3.0全托管模式公测。相对于2.0版本,阿里推出了一种全新的全托管模式。

    2.0版本底层是基于ECS机器这种资源方式,当用户资源不足的时候,扩容需要扩整台ECS机器,这种弹性有两个缺点,一是速度比较慢,二是整个ECS机器比较重,当用户只需要比如 1core资源的时候,需要弹出整台机器去满足用户的业务,不够灵活。同时由于为每个用户维护一套集群,对于系统运维来说也是一个巨大的挑战。

    实时计算3.0版本推出的基于 Flink 引擎的全新全托管模式,背后是每个Region一套大集群。既能跟用户的VPC打通,又能做到充分隔离,用户就能够运行SQL的UDF和DataStream等作业,并保持跟社区的绝对兼容,按量付费,同时也给运维带来便利。这个版本也是业界在云化实时计算领域里的先行者。

    (二)实时计算领域大事件

    之前在阿里云上的实时计算是基于Blink和RealtimeCompute(产品)的模式,德国是基于 Apache Flink 引擎和VervericaPlatform(产品)的模式。2019年双方合作后,大家统一将基础引擎调整为Apache Flink,并在上面添加增值插件,同时在阿里云上的产品统一以RealtimeCompute提供给用户,powered by Ververica。这样做的主要目的是通过共建的核心引擎和增值的插件,提升商业化能力,打造全球统一的技术品牌Ververica,在阿里云上继续使用原来的产品形态RealtimeCompute。

    image.png

    那么整个的关系是怎样的呢?

    基于 Apache Flink ,阿里做了很多增值项,比如说Connecter、SQL增强、StateBackend增强等等。将这些能力产品化到阿里云上,这就是RealtimeCompute。随着RealtimeCompute对用户的接入和用户不断的反馈,从而不断丰富商业化的基本功能。这些功能又进一步抽象,再推回到Apache Flink社区中,从形成了社区、企业和产品良性循环发展的状态。

    image.png

    阿里技术致力于做最好的实时计算,所谓最好包括性能更强,功能更多,易用性更好。就像产品的Slogan“实时即未来”所表达的,希望更多的计算场景采用实时计算,更多的业务使用 Flink ,希望用 Flink 推动整个实时计算的发展。

    2015年开始,实时计算 Flink 积累了很多基于不同业务领域的场景,包括实时大屏场景、实时机器学习、实时的ETL场景和实时数仓场景等。同时覆盖互联网、在线教育、新零售、交通出行、金融财富等各个领域,培育了很多标杆客户(见下图表格)。这些客户既扩大了对 Flink 的使用,同时客户们宝贵的场景和反馈也促进了实时计算 Flink 的优化和发展。

    二、 为什么选择实时计算Flink

    互联网发展到今天,业务实时化趋势越来越强。在在线应用、在线ML、实时风控、实时ETL等各行各业领域,实时计算的发展越来越越好,实时计算的需求也越来越强。下面罗列了四个选择实时计算Flink的理由。

    理由一 上云优势

    云上实时计算 Flink 具有“云”的天然优势。

    ● 成本的优势:在云上的实时计算,节省了用户建设和维护基础设施的成本,比如说机房、网络等等。
    ● 灵活的优势:一块业务的发展是需要多个引擎或者多款产品的组合,如果用户选择自建,不仅需要建设各个产品,还无法实现按需选择;但是在云上,用户可以根据自己的需要选择需要的产品。
    ● 扩展性的优势:在线下自建,用户需要提前预估好资源,预估多了可能造成资源浪费,预估少了不一定能够扛过业务的峰值。 而在云上可以实现按需索取,更具弹性,完全契合业务需求。

    理由二 原创出品

    实时计算 Flink是阿里与 Flink 原创团队中西合璧共同打造的一个国际化产品。完全兼容社区,用户的作业甚至基本不需改动,就可以平迁到实时计算 Flink中。如果遇到一些用户问题,也可以及时地反馈给社区,并迅速修复。同时,在 Apache Flink 的基础之上,提供了丰富的增值能力,这些能力对云上的使用场景尤为重要,也成为实时计算Flink带给用户的核心价值。

    理由三 丰富经验

    对于实时计算 Flink ,阿里具有丰富的实践经验。阿里巴巴已经使用实时计算 Flink 近10年时间,承接了全阿里集团的实时业务,经历过多次双11的实战大考,在这期间大量的经验和业务场景被积累下来,直接赋能用户。而这些经验和业务场景,是需要用户自己经过漫长时间和人力投入才能获得的。

    理由四 企业增值

    首先是Connector“多”。

    Flink的输入输出需要对接不同上下游,而在阿里云上下游存储也比较多,实时提供的 Connector 基本覆盖了目前云上所有的数据存储,包括开源的和商业的,而这在社区是远远少于企业版的;并且针对一些重要场景的多次打磨和特殊优化,无缝衔接上下游。

    添加了更多内置函数,可以为用户提供垂直领域的函数,使用户做到开箱即用。 “多”还指对系统和业务的监控指标非常多。这些监控指标能够让用户更直接的看到整个系统的情况,省去了自己埋点或查询资料。实时计算的运维也对接了阿里云的运维体系,如果用户有使用阿里云的经验,就可以无缝的使用阿里云的运维工具来维护自己的实时计算 Flink 的任务。

    其次是“快”,指更快的实时计算能力。

    如何做到更快的实时计算呢?在 Apache Flink 基础之上,自研流计算存储引擎Gemini,平均优于开源性能1倍以上。并对某些SQL或 Table API算子进行了深度优化,部分性能也能领先开源2倍。

    版本更新速度快,社区的新版本可以在阿里云上很快地发布出来,同时部分功能也可以优先于社区让用户提前得到体验。提前使用的功能,用户也不用担心只在阿里云上有,后续还能推回到社区中。

    作为企业级产品,7×24小时的服务可以在规定时间里响应客户并及时处理客户问题。如果遇到bug也可以先于社区发布提前解决。

    第三是“好”,主要体现在跟整个云环境技术环境的集成,包括账号权限体系、存储告警、日志链路等等。对于Yarn 和K8S做了深度的优化,对于作业的提交时间以及大量作业提交运行的调度能力都做了深度的优化,达到生产级可用。这些优化都是在阿里巴巴集团内部使用并检验过后再发布到云上的。

    另外,实时计算 Flink 还提供了Web Console,实现一站式开发调试运维服务,用户可以通过白屏化的方式去操作作业。

    阿里还提供了全链路的智能诊断工具,可以让用户更智能的分析、诊断作业的问题,并且给出智能提示。

    最后,阿里提供了OpenAPI,可以让用户做二次开发,方便集成自有系统中去。

    实时计算 Flink内置元数据集成,同时也可以与外界的HMS等元数据系统打通。SQL开发基本上已经成为大数据开发的趋势,用户可以在Web上编辑、调试、运行SQL,或发现SQL问题。同时集成了 Alink 的能力,通过 Flink 来实现传统机器学习的算法。

    image.png

    “省”是用户最关心的,如何省资源、省人力和省钱等。实时计算 Flink为用户提供了单作业粒度的AutoPilot能力,这就意味着随着任务运行,假设遇到业务波峰需要更大并发和更多资源,或遇到波谷需要释放掉并发或资源,可以帮助用户进行自动调节。跟上文提到的实时计算3.0全托管形态深度的结合,单作业可以自动调优,用户还可以根据所需资源按量付费,弹性扩缩容,从而节省成本。

    对于全托管用户,7×24小时运维服务可以为用户节省很多人力成本;对于半托管用户,实时计算 Flink也提供了专业的技术支持,去定位用户问题并给出解决方案。对于全链路的开发运维以及完整的作业生命周期管理,实时计算 Flink也为用户节省了不少时间成本。

    三、 实时计算Flink产品介绍

    实时计算 Flink 的产品介绍主要包括:产品技术栈、云上产品形态和实时打通上下游。

    (一) 产品技术栈

    如下图所示,整个产品技术站分为以下几个部分(由下往上):

    image.png

    计算资源,包括物理机、虚拟机等等。实时计算 Flink 的运行需要一套分布式文件系统,这些文件系统在阿里云上主要用通过OSS、HDFS等分布式文件系统实现。关于调度系统,最主要的是支持了当前比较热门的Yarn和K8S两种调度系统,充分满足了不同调度系统体系用户的需求。

    上层是 Ververica Platform。首先基于Apache Flink 做了增值插件,包括上文提到GeminiStateRockend、对SQL的优化和丰富的Connector;在任务管控层采用微服务架构,给用户提供整个作业生命周期的管理,Web的开发和查看,SQL的开发以及AutoPilot的能力等等。在这做了更多任务管理上的增值和优化。最终的目标是让Apche Flink企业化版本提供一站式处理能力,并提供更多优化插件。

    (二) 云上产品形态

    阿里云的实时计算 Flink这款产品已经成为开源引擎商业化的新星。目前在公共云上,主要有全托管和半托管两种形态,全托管主要适合那些关注业务发展但是不关心集群运维的用户,也就是托管集群的形态。我们强烈推荐使用 Flink 全托管,跟社区完全兼容,无缝跟上下游打通,相互安全隔离,又能按量付费。

    image.png

    半托管主要是将整个Ververica Platform部署到用户的环境中,用户的环境可以是Yarn也可以是K8S。目前半托管的这两款产品都已经商业化,并且仅收取 ECS的费用,对于Yarn或者K8S有偏好的用户,可以选择这两款产品。

    (三) 实时打通上下游

    不管选择哪种产品形态,都要做到打通用户上下游,像数据总线、日志服务、消息队列这样的一些流式表能够流进 Flink ,像表格存储、数据库服务等等能够作为维表。对于一些大型的存储,像MaxCompute,Hbase,OSS数据量不是特别大的情况下,也能够以维表方式加载进来。同时,这些系统也可以做出 Flink 的输出,供用户业务使用。

    image.png

    实时计算 Flink 直接将用户的流式存储作为上游,用户的一些查询存储作为维表,然后再输出到用户的环境中,不需要做数据搬移,可以自动跟用户的环境打通并完成复杂的逻辑计算。

    四、 实时计算 Flink 未来可期

    对于未来的发展,阿里云实时计算 Flink摩拳擦掌,信心满满。

    产品功能持续推出

    SQL的建设正在逐渐完备,比如SQL Preview能力能够提前在SQL提交之前就能够得到SQL的部分产出,用来判断SQL的逻辑是否正确;通过 Flink Session 提交任务,更快且节省成本;更智能的AutoPilot能力,为用户进一步节省成本;还会在SQL层进行深度优化,不断提高运行性能;对于长时间运行的 Flink ,我们将Debug和TrouleShooting能力作为主要建设目标,让用户能够方便地定位目前作业的状态以及健康程度;添加常用的监控报警,让用户能够及时感知作业的异常。

    产品介绍持续更新

    通过入门篇、实操篇和高级篇,由浅入深地持续为大家介绍产品。

    入门篇主要介绍产品的概念以及应用场景如何开通等等;实操篇主要介绍基于实时计算 Flink 用户如何去写自己DataStream作业和SQL作业,如何使用一些AutoPilot等基础的功能;高级篇主要介绍如何使用实时计算 Flink 做Trouble Shooting和更有效的配置,比如 Flink 的内存资源调优等等。

    关于阿里巴巴高级技术专家邓小勇(静行)

    image.png

    2010年加入阿里巴巴,参与搜索Dump中心的数据处理工作。后加入现在的计算平台,先后负责实时数据同步、离线数据同步、实时数据转离线处理等领域的工作。通过这些工作的历练,与大数据传输和处理结下了不解之缘。

    2015年开始到现在,专注在实时计算建设和发展上,经历了几代实时计算的建设,目前是VVP 建设的负责人,主要负责实时计算在阿里集团、阿里云公共云和混合云的产品化建设。

    原文链接:https://developer.aliyun.com/article/780633?

    版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
    展开全文
    alitech2017 2021-01-26 17:30:30
  • 欢迎点赞、收藏、留言 ,欢迎留言交流!...大数据领域自 2010 年开始,以 Hadoop、Hive 为代表的离线计算开始进入各大公司的视野。大数据领域开始了如火如荼的发展。我个人在学校期间就开始关注大数据领域的技术迭代...

      欢迎关注博客主页:https://blog.csdn.net/u013411339
    欢迎点赞、收藏、留言 ,欢迎留言交流!
    本文由【王知无】原创,首发于 CSDN博客!
    本文首发CSDN论坛,未经过官方和本人允许,严禁转载!

    本文是对《【硬刚大数据之学习路线篇】从零到大数据专家的学习指南(全面升级版)》的面试部分补充。

    大数据领域自 2010 年开始,以 Hadoop、Hive 为代表的离线计算开始进入各大公司的视野。大数据领域开始了如火如荼的发展。我个人在学校期间就开始关注大数据领域的技术迭代和更新,并且有幸在毕业后成为大数据领域的开发者。

    在过去的这几年时间里,以 Storm、Spark、Flink 为代表的实时计算技术接踵而至。2019 年阿里巴巴内部 Flink 正式开源。整个实时计算领域风起云涌,一些普通的开发者因为业务需要或者个人兴趣开始接触Flink。

    Apache Flink(以下简称 Flink)一改过去实时计算领域为人诟病的缺陷,以其强大的计算能力和先进的设计理念,迅速成为实时计算领域先进生产力的代表。各大小公司纷纷开始在 Flink 的应用上进行探索,其中最引人瞩目的两个方向便是:实时计算平台和实时数据仓库。

    Flink 实时计算

    如果你是一位大数据领域的开发人员或者你是一名后端的开发者,那么你对下面这些需求场景应该不会陌生:

    我是抖音主播,我想看带货销售情况的排行?我是运营,我想看到我们公司销售商品的 TOP10?我是开发,我想看到我们公司所有生产环境中服务器的运行情况?...... 

    在 Hadoop 时代,我们通常的做法是将数据批量存储到 HDFS 中,在用 Hive 产出离线的报表。或者我们使用类似 ClickHouse 或者 PostgreSQL 这样的数据库存储生产数据,用 SQL 直接进行汇总查看。

    那么这样的方式有什么问题呢?

    第一种,基于 Hive 的离线报表形式。大部分公司随着业务场景的不断丰富,同时在业界经过多年的实践检验,基于 Hadoop 的离线存储体系已经足够成熟。但是离线计算天然时效性不强,一般都是隔天级别的滞后,业务数据随着实践的推移,本身的价值就会逐渐减少。越来越多的场景需要使用实时计算,在这种背景下实时计算平台的需求应运而生。

    第二种,基于 ClickHouse 或者 PostgreSQL 直接进行汇总查询。这种情况在一些小规模的公司使用非常常见,原因只有一个就是数据量不够大。在我们常用的具有 OLAP 特性的数据库的使用过程中,如果在一定的数据量下直接用复杂的 SQL 查询,一条复杂的 SQL 足以引起数据库的剧烈抖动,甚至直接宕机,对生产环境产生毁灭性的影响。这种查询在大公司是坚决不能进行的操作。

    因此基于 Flink 强大实时计算能力消费实时数据的需求便应运而生。在实时数据平台中,Flink 会承担实时数据的采集、计算和发送到下游。

    Flink 实时数据仓库

    数据仓库最初是指的我们存储的 Hive 中的表的集合。按照业务需求一般会分为原始层、明细层、汇总层、业务层。各个公司根据实际业务需要会有更为细致的划分。

    传统的离线数据仓库的做法一般是将数据按天离线集中存储后,按照固定的计算逻辑进行数据的清洗、转换和加载。最终在根据业务需求进行报表产出或者提供给其他的应用使用。我们很明显的可以看到,数据在这中间有了至少 T+1 天的延迟,数据的时效性大打折扣。

    这时,实时数据仓库应运而生。一个典型的实时数据仓库架构图如下:

    图片

    技术选型

    这一部分作者结合自身在阿里巴巴这样的公司生产环境中的技术选择和实际应用的中一些经验,来讲解实时计算平台和实时数据仓库的各个部分是如何进行技术选型的。

    实时计算引擎

    我们在上面提到,实时计算解决的最重要的问题就是实时性和稳定性。

    实时计算对数据有非常高的稳定性和精确性要求,特别是面向公众第三方的数据大屏,同时要求高吞吐、低延迟、极高的稳定性和绝对零误差。随时电商大促的成交记录一次次被刷新,背后是下单、支付、发货高达几万甚至十几万的峰值 QPS。

    你可以想象这样的场景吗?天猫双十一,万众瞩目下的实时成交金额大屏突然卡住没有反应。我估计所有开发人员都要被开除了…

    我们以一个最常见和经典的实时计算大屏幕来举例。

    在面向实际运营的数据大屏中,需要提供高达几十种维度的数据,每秒的数据量高达千万甚至亿级别,这对于我们的实时计算架构提出了相当高的要求。那么我们的大屏背后的实时处理在这种数据量规模如何才能达到高吞吐、低延迟、极高的稳定性和绝对零误差的呢?

    图片

    在上图的架构图中,涉及几个关键的技术选型,我们下面一一进行讲解。

    业务库 Binlog 同步利器 - Canal

    我们的实时计算架构一般是基于业务数据进行的,但无论是实时计算大屏还是常规的数据分析报表,都不能影响业务的正常进行,所以这里需要引入消息中间件或增量同步框架 Canal。

    我们生产环境中的业务数据绝大多数都是基于 MySQL 的,所以需要一个能够实时监控 MySQL 业务数据变化的工具。Canal 是阿里巴巴开源的数据库 Binlog 日志解析框架,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据订阅和消费。

    图片

    Canal 的原理也非常简单,它会伪装成一个数据库的从库,来读取 Binlog 并进行解析。Canal 在阿里巴巴内部有大规模的应用,因为阿里有众多的业务是跨机房部署,大量业务需要进行业务同步,Canal 功能强大,性能也很稳定。

    解耦和海量数据支持 - Kafka

    在实时大屏的技术架构下,我们的数据源绝大多数情况下都是消息。我们需要一个强大的消息中间件来支撑高达几十万 QPS,同时支持海量数据存储。

    首先,我们为什么需要引入消息中间件?主要是下面三个目的:

    • 同步变异步

    • 应用解耦

    • 流量削峰

    在我们的架构中,为了和业务数据互相隔离,需要使用消息中间件进行解耦从而互不影响。另外在双十一等大促场景下,交易峰值通常出现在某一个时间段,这个时间段系统压力陡增,数据量暴涨,消息中间件还起到了削峰的作用。

    为什么选择 Kafka?

    Kafka 是最初由 Linkedin 公司开发,是一个分布式、高吞吐、多分区的消息中间件。Kafka 经过长时间的迭代和实践检验,因为其独特的优点已经成为目前主流的分布式消息引擎,经常被用作企业的消息总线、实时数据存储等。

    Kafka 从众多的消息中间件中脱颖而出,主要是因为高吞吐、低延迟的特点;另外基于 Kafka 的生态越来越完善,各个实时处理框架包括 Flink 在消息处理上都会优先进行支持。并且 Flink 和 Kafka 结合可以实现端到端精确一次语义的原理。

    Kafka 作为大数据生态系统中已经必不可少的一员,主要的特性如下所示。

    • 高吞吐:

      可以满足每秒百万级别消息的生产和消费,并且可以通过横向扩展,保证数据处理能力可以得到线性扩展。

    • 低延迟:

      以时间复杂度为 O(1) 的方式提供消息持久化能力,即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。

    • 高容错:

      Kafka 允许集群的节点出现失败。

    • 可靠性:

      消息可以根据策略进行磁盘的持久化,并且读写效率都很高。

    • 生态丰富:

      Kafka 周边生态极其丰富,与各个实时处理框架结合紧密。

    实时计算服务 - Flink

    Flink 在当前的架构中主要承担了消息消费、维表关联、消息发送等。在实时计算领域,Flink 的优势主要包括:

    • 强大的状态管理

      Flink 使用 State 存储中间状态和结果,并且有强大的容错能力;

    • 非常丰富的 API

      Flink 提供了包含 DataSet API、DataStream API、Flink SQL 等等强大的API;

    • 生态支持完善

      Flink 支持多种数据源(Kafka、MySQL等)和存储(HDFS、ES 等),并且和其他的大数据领域的框架结合完善;

    • 批流一体

      Flink 已经在将流计算和批计算的 API 进行统一,并且支持直接写入 Hive。

    对于 Flink 的一些特点我们不做过多展开了。这里需要注意的是,Flink 在消费完成后一般会把计算结果数据发往三个方向:

    • 高度汇总,高度汇总指标一般存储在 Redis、HBase 中供前端直接查询使用。

    • 明细数据,在一些场景下,我们的运营和业务人员需要查询明细数据,有一些明细数据极其重要,比如双十一派送的包裹中会有一些丢失和破损。

    • 实时消息,Flink 在计算完成后,有一个下游是发往消息系统,这里的作用主要是提供给其他业务复用;

      另外,在一些情况下,我们计算好明细数据也需要再次经过消息系统才能落库,将原来直接落库拆成两步,方便我们进行问题定位和排查。

    百花齐放 - OLAP 数据库选择

    OLAP 的选择是当前实时架构中最有争议和最困难的。目前市面上主流的开源 OLAP 引擎包含但不限于:Hive、Hawq、Presto、Kylin、Impala、SparkSQL、Druid、Clickhouse、Greeplum 等,可以说目前没有一个引擎能在数据量,灵活程度和性能上做到完美,用户需要根据自己的需求进行选型。

    我曾经在之前的一篇文章 《实时数仓 | 你需要的是一款强大的 OLAP 引擎》用了两万字分析了目前市面上主流的 OLAP 数据库的选型问题,这里直接给出结论:

    • Hive、Hawq、Impala:

      基于 SQL on Hadoop

    • Presto 和 Spark SQL 类似:

      基于内存解析 SQL 生成执行计划

    • Kylin:

      用空间换时间、预计算

    • Druid:

      数据实时摄入加实时计算

    • ClickHouse:

      OLAP 领域的 HBase,单表查询性能优势巨大

    • Greenpulm:

      OLAP 领域的 PostgreSQL

    如果你的场景是基于 HDFS 的离线计算任务,那么 Hive、Hawq 和 Imapla 就是你的调研目标。

    如果你的场景解决分布式查询问题,有一定的实时性要求,那么 Presto 和 SparkSQL 可能更符合你的期望。

    如果你的汇总维度比较固定,实时性要求较高,可以通过用户配置的维度 + 指标进行预计算,那么不妨尝试 Kylin 和 Druid。

    ClickHouse 则在单表查询性能上独领风骚,远超过其他的 OLAP 数据库。

    Greenpulm 作为关系型数据库产品,性能可以随着集群的扩展线性增长,更加适合进行数据分析。

    Flink 实时数据仓库

    实时数据仓库的发展经历了从离线到实时的发展,一个典型的实时数据仓库架构如下如图所示:

    图片

    一般实时数据仓库的设计也借鉴了离线数仓的理念,不但要提高我们模型的复用率,也要考虑实时数仓的稳定性和易用性。

    在实时数据仓库的技术选型中,用到的核心技术包括:Kafka、Flink、Hbase 等。

    其中 Kafka 和 Flink 的优势我们在上述实时数据平台的技术选型中已经做过详细的介绍。这其中还有两个关键的指标存储系统:Hbase 和 Redis。

    其中 Hbase 是典型的列式分布式存储系统,Redis 是缓存系统中首选,他们的主要优势包括:

    • 强一致性

    • 自动故障转移和容错性

    • 极高的读写 QPS,非常适合存储 K-V 形式的指标

    批流一体是未来

    随着 Flink 1.12 版本的发布,Flink 与 Hive 的集成达到了一个全新的高度,Flink 可以很方便的对 Hive 直接进行读写。

    这代表了什么?

    只要我们还在使用实时数据仓库,那么我们可以直接对 Hive 进行读写,Flink 成为了 Hive 上的一个处理引擎,既可以通过批的方式也可以通过流的方式。从 Flink 1.12 开始会有大批的离线实时一体的数据仓库出现。

    我们数据仓库架构就变成了:

    图片

    其中 Flink SQL 统一了实时和离线的逻辑,避免出现离线和实时需要两套架构和代码支撑,也基本解决了离线和实时数据对不齐的尴尬局面。

    大厂的实时计算平台和实时数仓技术方案

    这部分小编结合自身在实际生产环境中的经验,参考了市面上几个大公司在实时计算平台和实时数仓设计中,选出了其中最稳妥也是最常用的技术方案,奉献给大家。

    作者的经验

    在我们的实时计算架构中采用的是典型的 Kappa 架构,我们的业务难点和重点主要集中在:

    • 数据源过多

    我们的实时消息来源多达几十个,分布在各大生产系统中,这些系统中的消息数据格式不一。

    • 数据源之间时间 GAP 巨大

    我们业务数据之间需要互相等待,举个最简单的例子。用户下单后,可能 7 天以后后还会进行操作,这就导致一个问题,我们在建设实时数仓时中间状态 State 巨大,直接使用 Flink 原生的状态会导致任务资源消耗巨大,非常不稳定。

    • 离线数据和实时数据要求强一致性

    我们的数据最终会以考核的形式下发,直接指导一线员工的工资和奖金发放。要求数据强一致性保障,否则会引起投诉甚至舆情。

    基于以上的考虑,我们的实时数据仓库架构如下:

    图片

    几个关键的技术点如下:

    第一,我们使用了 Hbase 作为中间状态的存储。我们在上面提到,因为在 Flink SQL 中进行计算需要存储中间状态,而我们的数据源过多,且时间差距过大,那么实时计算的状态存储变得异常巨大,在大数据量的冲击下,任务变得非常不稳定。另外如果任务发生 Fail-over,状态会丢失,结果严重失真。所以我们所有的数据都会存储在 Hbase。

    第二,实时数据触发模式计算。在 Flink SQL 的逻辑里,Hbase 的变更消息发出,我们只需要接受其中的 rowkey 信息,然后所有的数据都是反查 Hbase。我们在上面的文章中讲到过,Hbase 因为极高的读写 QPS 被各大公司普遍应用在实时存储和高频查询中。

    第三,双写 ADB 和 Hologres。ADB 和 Hologres 是阿里云提供的强大的 OLAP 引擎。我们在 Flink SQL 计算完毕后将结果双写,前端查询可以进行分流和负载均衡。

    第四,离线数据同步。这里我们采用的是直接将消息通过中间件进行同步,在离线数仓中有一套一样的逻辑将数据写入 Hive 中。在 Flink 1.12 后,离线和实时的计算逻辑统一为一套,完全避免了离线和实时消息的不一致难题。

    但是,客观的说这套数据架构有没有什么问题呢?

    • 这套数据架构引入了 Hbase 作为中间存储,数据链路变长。导致运维成本大量增加,整个架构的实时性能受制于 Hbase 的变更信息能不能及时发送。

    • 指标没有分层,会导致 ADB 和 Hologres 成为查询瓶颈。在这套数据架构中,我们完全抛弃了中间指标层,完全依赖 SQL 直接汇总查询。一方面得益于省略中间层后指标的准确性,另一方面因为 SQL 直接查询会对 ADB 有巨大的查询压力,使得 ADB 消耗了巨大的资源和成本。

    在未来的规划中,我们希望对业务 SQL 进行分级。高优先级、实时性极高的指标和数据直接查询数据库。非高优先级和极高实时性的指标可以通过历史数据加实时数据结合的方式组装结果,减少对数据库的查询压力。

    腾讯看点的实时数据系统设计

    腾讯看点数据中心承接了腾讯 QQ 看点、小程序、浏览器、快报等等业务的开发取数、看数的需求。腾讯看点一天上报的数据量可以达到万亿级规模,对低延迟、亚秒级的实时计算和多维查询带来了巨大的技术挑战。

    首先,我们来看一下腾讯看点的实时数据系统的架构设计:

    图片

    上图是腾讯看点的整体的实时架构设计图。我们可以看到整体的架构分为三层:

    • 数据采集层

    在这层中,腾讯看点完全使用消息队列 Kafka 进行了解耦操作,避免直接读取业务系统数据。

    • 实时数据仓库层

    在这一层中腾讯看点使用 Flink 分别做分钟级别的聚合和中度聚合,大大减轻了实时 SQL 查询的压力。

    • 实时数据存储层

    腾讯看点使用 ClickHouse 和 MySQL 作为实时数据存储,我们在下面会分析 ClickHouse 作为实时数据存储的优势和特点。

    关于数据选型,实时数仓的整体架构腾讯看点选择了 Lambda 架构,主要是因为高灵活性、高容错性、高成熟度、极低的迁移成本。

    在实时计算上,腾讯看点选择了 Flink 作为计算引擎,Flink 受到青睐的原因包括 Exactly-once 语义支持,轻量级的快照机制以及极高的吞吐性。另一一个很重要的原因就是 Flink 高效的维表关联,支持了实时数据流 (百万级/s) 关联 HBase 维度表。

    在数据存储上,腾讯看点重度使用 ClickHouse。ClickHouse 的优势包括:

    • 多核 CPU 并行计算

    • SIMD 并行计算加速

    • 分布式水平扩展集群

    • 稀疏索引、列式存储、数据压缩

    • 聚合分析优化

    最终腾讯看点的实时数据系统支撑了亚秒级响应多维条件查询请求:

    • 过去 30 分钟内容的查询,99% 的请求耗时在1秒内

    • 过去 24 小时内容的查询,90% 的请求耗时在5秒内,99% 的请求耗时在 10 秒内

    阿里巴巴批流一体数据仓库建设

    我们在上面介绍了 Flink 的优势,尤其是在 Flink 1.12 版本后,Flink 与 Hive 的集成达到了一个全新的高度,Flink 可以很方便的对 Hive 直接进行读写。

    阿里巴巴率先在业务实现了批流一体的实时数据仓库,根据公开的资料显示,阿里巴巴在批流一体上的探索主要包含三个方面:

    • 统一元数据管理

    Flink 从 1.11 版本开始简化了连接 Hive 的方式,Flink 通过一套简单的 Hive Catelog API 打通了与 Hive 的通信。使得访问 Hive 变得轻而易举。

    • 统一计算引擎

    在我们传统的实时数仓的建设中,基于离线和实时引擎的不同,需要编写两套 SQL 进行计算和数据入库操作。Flink 高效解决了这个问题,基于 ANSI-SQL 标准提供了批与流统一的语法,并且使用 Flink 引擎执行可以同时读写 Hive 与其他的 OLAP 数据库。

    • 统一数据存储

    在这个架构下,离线数据成为了实时数据的历史备份,离线数据也可以作为数据源被实时摄入,批量计算的场景变成了实时调度,不在依赖定时调度任务。

    基于以上的工作,基于 Flink 和 Hive 的批流一体实时数仓应运而生,整体的架构如下:

    图片

    我们可以看到,原来的离线和实时双写链路演变成了单一通道,一套代码即可完成离线和实时的计算操作。并且基于 Flink 对 SQL 的支撑,代码开发变得异常简洁,阿里巴巴的批流一体数据仓库在 2020 年落地并且投入使用,效果显著,支撑了双十一的数据需求。

    实战案例

    这部分我们我们将以一个实时统计项目为背景,介绍实时计算中的架构设计和技术选型以及最终的实现。其中涉及了日志数据埋点、日志数据采集、清洗、最终的指标计算等等。

    架构设计

    我们以统计网站的 PV 和 UV 为例,涉及到几个关键的处理步骤:

    • 日志数据上报

    • 日志数据清洗

    • 实时计算程序

    • 结果存储

    基于以上的业务处理流程,我们常用的实时处理技术选型和架构如下图所示:

    图片

    整体的代码开发包括:

    • Flume 和 Kafka 整合和部署

    • Kafka 模拟数据生成和发送

    • Flink 和 Kafka 整合时间窗口设计

    • Flink 计算 PV、UV 代码实现

    • Flink 和 Redis 整合以及 Redis Sink 实现

    Flume 和 Kafka 整合和部署

    我们可以在 Flume 的官网下载安装包,在这里下载一个 1.8.0 的稳定版本,然后进行解压:

     
    

    tar zxf apache-flume-1.8.0-bin.tar.gz

    图片

    可以看到有几个关键的目录,其中 conf/ 目录则是我们存放配置文件的目录。

    接下来我们整合 Flume 和 Kafka。整体整合思路为,我们的两个 Flume Agent 分别部署在两台 Web 服务器上,用来采集两台服务器的业务日志,并且 Sink 到另一台 Flume Agent 上,然后将数据 Sink 到 Kafka 集群。在这里需要配置三个 Flume Agent。

    首先在 Flume Agent 1 和 Flume Agent 2 上创建配置文件,修改 source、channel 和 sink 的配置,vim log_kafka.conf 代码如下:

    # 定义这个 agent 中各组件的名字
    a1.sources = r1
    a1.sinks = k1
    a1.channels = c1
    
    # source的配置,监听日志文件中的新增数据
    a1.sources.r1.type = exec
    a1.sources.r1.command  = tail -F /home/logs/access.log
    
    #sink配置,使用avro日志做数据的消费
    a1.sinks.k1.type = avro
    a1.sinks.k1.hostname = flumeagent03
    a1.sinks.k1.port = 9000
    
    #channel配置,使用文件做数据的临时缓存
    a1.channels.c1.type = file
    a1.channels.c1.checkpointDir = /home/temp/flume/checkpoint
    a1.channels.c1.dataDirs = /home/temp/flume/data
    
    #描述和配置 source channel sink 之间的连接关系
    a1.sources.r1.channels = c1
    a1.sinks.k1.channel = c

    上述配置会监听 /home/logs/access.log 文件中的数据变化,并且将数据 Sink 到 flumeagent03 的 9000 端口。

    然后我们分别启动 Flume Agent 1 和 Flume Agent 2,命令如下:

    $ flume-ng agent -c conf -n a1 -f conf/log_kafka.conf >/dev/null 2>&1 &

    第三个 Flume Agent 用来接收上述两个 Agent 的数据,并且发送到 Kafka。我们需要启动本地 Kafka,并且创建一个名为 log_kafka 的 Topic。

    然后,我们创建 Flume 配置文件,修改 source、channel 和 sink 的配置,vim flume_kafka.conf 代码如下:

    # 定义这个 agent 中各组件的名字a1.sources = r1a1.sinks = k1a1.channels = c1
    #source配置a1.sources.r1.type = avroa1.sources.r1.bind = 0.0.0.0a1.sources.r1.port = 9000
    #sink配置a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSinka1.sinks.k1.topic = log_kafkaa1.sinks.k1.brokerList = 127.0.0.1:9092a1.sinks.k1.requiredAcks = 1a1.sinks.k1.batchSize = 20
    #channel配置a1.channels.c1.type = memorya1.channels.c1.capacity = 1000a1.channels.c1.transactionCapacity = 100
    #描述和配置 source channel sink 之间的连接关系a1.sources.r1.channels = c1a1.sinks.k1.channel = c1    

    配置完成后,我们启动该 Flume Agent:

    $ flume-ng agent -c conf -n a1 -f conf/flume_kafka.conf >/dev/null 2>&1 &

    当 Flume Agent 1 和 2 中监听到新的日志数据后,数据就会被 Sink 到 Kafka 指定的 Topic,我们就可以消费 Kafka 中的数据了。

    我们现在需要消费 Kafka Topic 信息,并且把序列化的消息转化为用户的行为对象:

     
    
    public class UserClick {
        private String userId;    private Long timestamp;    private String action;
        public String getUserId() {        return userId;    }
        public void setUserId(String userId) {        this.userId = userId;    }
        public Long getTimestamp() {        return timestamp;    }
        public void setTimestamp(Long timestamp) {        this.timestamp = timestamp;    }
        public String getAction() {        return action;    }
        public void setAction(String action) {        this.action = action;    }
        public UserClick(String userId, Long timestamp, String action) {        this.userId = userId;        this.timestamp = timestamp;        this.action = action;    }}
    enum UserAction{    //点击    CLICK("CLICK"),    //购买    PURCHASE("PURCHASE"),    //其他    OTHER("OTHER");
        private String action;    UserAction(String action) {        this.action = action;    }}

    在计算 PV 和 UV 的业务场景中,我们选择使用消息中自带的事件时间作为时间特征,代码如下:

    由于我们的用户访问日志可能存在乱序,所以使用 BoundedOutOfOrdernessTimestampExtractor  来处理乱序消息和延迟时间,我们指定消息的乱序时间 30 秒,具体代码如下

    ​​​​​​​

    SingleOutputStreamOperator<UserClick> userClickSingleOutputStreamOperator = dataStream.assignTimestampsAndWatermarks(new BoundedOutOfOrdernessTimestampExtractor<UserClick>(Time.seconds(30)) {    @Override    public long extractTimestamp(UserClick element) {        return element.getTimestamp();    }});

    到目前为止,我们已经通过读取 Kafka 中的数据,序列化为用户点击事件的 DataStream,并且完成了水印和时间戳的设计和开发。

    接下来,按照业务需要,我们需要开窗并且进行一天内用户点击事件的 PV、UV 计算。这里我们使用 Flink 提供的滚动窗口,并且使用 ContinuousProcessingTimeTrigger 来周期性的触发窗口阶段性计算。​​​​​​​

    dataStream     .windowAll(TumblingProcessingTimeWindows.of(Time.days(1), Time.hours(-8))).trigger(ContinuousProcessingTimeTrigger.of(Time.seconds(20)))

    为了减少窗口内缓存的数据量,我们可以根据用户的访问时间戳所在天进行分组,然后将数据分散在各个窗口内进行计算,接着在 State 中进行汇总。

    首先,我们把 DataStream 按照用户的访问时间所在天进行分组:​​​​​​​

    userClickSingleOutputStreamOperator         .keyBy(new KeySelector<UserClick, String>() {            @Override            public String getKey(UserClick value) throws Exception {                return DateUtil.timeStampToDate(value.getTimestamp());            }        })        .window(TumblingProcessingTimeWindows.of(Time.days(1), Time.hours(-8)))        .trigger(ContinuousProcessingTimeTrigger.of(Time.seconds(20)))        .evictor(TimeEvictor.of(Time.seconds(0), true))        ...

    然后根据用户的访问时间所在天进行分组并且调用了 evictor 来剔除已经计算过的数据。其中的 DateUtil 是获取时间戳的年月日:​​​​​​​

    public class DateUtil {    public static String timeStampToDate(Long timestamp){        ThreadLocal<SimpleDateFormat> threadLocal                = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));        String format = threadLocal.get().format(new Date(timestamp));        return format.substring(0,10);    }}

    接下来我们实现自己的 ProcessFunction:​​​​​​​

    public class MyProcessWindowFunction extends ProcessWindowFunction<UserClick,Tuple3<String,String, Integer>,String,TimeWindow>{
        private transient MapState<String, String> uvState;    private transient ValueState<Integer> pvState;
        @Override    public void open(Configuration parameters) throws Exception {
            super.open(parameters);        uvState = this.getRuntimeContext().getMapState(new MapStateDescriptor<>("uv", String.class, String.class));        pvState = this.getRuntimeContext().getState(new ValueStateDescriptor<Integer>("pv", Integer.class));    }
        @Override    public void process(String s, Context context, Iterable<UserClick> elements, Collector<Tuple3<String, String, Integer>> out) throws Exception {
            Integer pv = 0;        Iterator<UserClick> iterator = elements.iterator();        while (iterator.hasNext()){            pv = pv + 1;            String userId = iterator.next().getUserId();            uvState.put(userId,null);        }        pvState.update(pvState.value() + pv);
            Integer uv = 0;        Iterator<String> uvIterator = uvState.keys().iterator();        while (uvIterator.hasNext()){            String next = uvIterator.next();            uv = uv + 1;        }
            Integer value = pvState.value();        if(null == value){            pvState.update(pv);        }else {            pvState.update(value + pv);        }
            out.collect(Tuple3.of(s,"uv",uv));        out.collect(Tuple3.of(s,"pv",pvState.value()));    }}
    

    我们在主程序中可以直接使用自定义的 ProcessFunction :​​​​​​​

    userClickSingleOutputStreamOperator        .keyBy(new KeySelector<UserClick, String>() {            @Override            public String getKey(UserClick value) throws Exception {                return value.getUserId();            }        })        .window(TumblingProcessingTimeWindows.of(Time.days(1), Time.hours(-8)))        .trigger(ContinuousProcessingTimeTrigger.of(Time.seconds(20)))        .evictor(TimeEvictor.of(Time.seconds(0), true))        .process(new MyProcessWindowFunction());
    

    到此为止,我们已经计算出来了 PV 和 UV,下面我们分别讲解 Flink 和 Redis 是如何整合实现 Flink Sink 的。

    在这里我们直接使用开源的 Redis 实现,首先新增 Maven 依赖如下:​​​​​​​

    <dependency>    <groupId>org.apache.flink</groupId>    <artifactId>flink-connector-redis_2.11</artifactId>    <version>1.1.5</version></dependency>

    可以通过实现 RedisMapper 来自定义 Redis Sink,在这里我们使用 Redis 中的 HASH 作为存储结构,Redis 中的 HASH 相当于 Java 语言里面的 HashMap:​​​​​​​

    public class MyRedisSink implements RedisMapper<Tuple3<String,String, Integer>>{
        /**     * 设置redis数据类型     */    @Override    public RedisCommandDescription getCommandDescription() {        return new RedisCommandDescription(RedisCommand.HSET,"flink_pv_uv");    }
        //指定key    @Override    public String getKeyFromData(Tuple3<String, String, Integer> data) {        return data.f1;    }    //指定value    @Override    public String getValueFromData(Tuple3<String, String, Integer> data) {        return data.f2.toString();    }}

    上面实现了 RedisMapper 并覆写了其中的 getCommandDescription、getKeyFromData、getValueFromData 3 种方法,其中 getCommandDescription 定义了存储到 Redis 中的数据格式。这里我们定义的 RedisCommand 为 HSET,使用 Redis 中的 HASH 作为数据结构;getKeyFromData 定义了 HASH 的 Key;getValueFromData 定义了 HASH 的值。

    然后我们直接调用 addSink 函数即可:

    ...userClickSingleOutputStreamOperator            .keyBy(new KeySelector<UserClick, String>() {                @Override                public String getKey(UserClick value) throws Exception {                    return value.getUserId();                }            })            .window(TumblingProcessingTimeWindows.of(Time.days(1), Time.hours(-8)))            .trigger(ContinuousProcessingTimeTrigger.of(Time.seconds(20)))            .evictor(TimeEvictor.of(Time.seconds(0), true))            .process(new MyProcessWindowFunction())            .addSink(new RedisSink<>(conf,new MyRedisSink()));...

    到此为止,我们就会将结果存进了 Redis 中,我们在实际业务中可以选择使用不同的目标库例如:Hbase 或者 MySQL 等等。

    总结

    以 Flink 为代表的实时计算技术还是飞速发展中,众多的新特性例如 Flink Hive Connector、CDC 增量同步等持续涌现,我们有理由相信基于 Flink 的实时计算平台和实时数据仓库的发展未来会大放异彩,解决掉业界在实时计算和实时数仓领域的痛点,成为大数据领域先进生产力的代表。

    展开全文
    u013411339 2021-08-29 13:47:27
  • weixin_46370858 2021-04-19 15:09:19
  • weixin_42299944 2021-03-15 18:08:50
  • alitech2017 2021-07-20 14:21:15
  • CLKTOY 2021-09-12 15:48:53
  • Sprite_CJ 2021-01-20 14:23:55
  • u013411339 2021-01-17 20:00:51
  • alitech2017 2021-09-03 13:53:33
  • dzzxjl 2021-10-01 12:31:15
  • u011250186 2021-04-05 11:36:59
  • alitech2017 2021-01-26 16:15:11
  • pbrlovejava 2021-04-23 23:13:49
  • weixin_43970890 2020-12-31 11:57:19
  • weixin_45508154 2021-08-15 11:02:01
  • weixin_43970890 2021-01-05 11:13:09
  • weixin_36852563 2020-12-26 22:05:24
  • weixin_42796403 2021-03-13 23:20:33
  • weixin_42796403 2021-03-13 23:17:43
  • w397090770 2021-11-17 00:35:13
  • duan_zhihua 2021-05-31 12:46:36
  • ddxygq 2021-06-07 00:27:36
  • bigdata_wangzhe 2021-03-07 21:31:38
  • chybin500 2021-01-27 19:31:36
  • weixin_51687288 2021-12-08 17:49:48
  • weixin_44775255 2021-05-14 11:23:44
  • chenshijie2011 2021-10-25 10:12:45
  • weixin_55873049 2021-12-07 18:19:11

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 551,274
精华内容 220,509
关键字:

实时计算

友情链接: 聚束SAR2.rar