实时计算

摘要：基于对数据工夫旅行的思考，引出了对目前三种数仓状态和两种数仓架构的思考。联合数据湖在 Flink 的利用和数据湖元数据类型的思考，摸索了基于数据湖的 Flink SQL 流批一体的实际，在流批一体 SQL 表白统一、后果一致性、流批工作拆散、混合调度依赖等进行了设计和摸索。同时，欢送大家多分享具体实际，一起共筑新的数据实际形式。一、数据的工夫旅行和业务对数据的实质要求大规模的数据处理衰亡于 Hadoop 生态的倒退，关键在于分布式贮存和分布式计算的倒退，造就了现在近百种无关大数据的生态技术。数仓实践和建模实践基于大数据技术体系得以疾速倒退，其中离线数仓的标准化建设失去了广泛应用。数据的实质是一种行为的具象，业务在对数据的需要，外围在于对行为的可摸索和可察看。基于此，咱们须要明确一点，大数据技术是否齐全满足了业务对数据需要在工夫维度上的确定性了呢，这点是值得思考的。那么咱们先来看一下数据的工夫旅行。 业务冀望的数据：用户空间下的工夫数据，t1工夫数据，用户天然工夫点或天然时间段的明细或者统计数据。 传输提早：App 用户，数据发送到网关或者日志服务零碎，或者 Server 日志落文件系统所产生的提早。Event 进入到存储空间，能够代表数据曾经是确定的，根本可察看，个别状况下，这个提早很小。然而，在某些状况，比方 APP 的日志产生之后，然而因为网络等问题始终没有发送，或者 Server 宕机，导致提早发送或者最终失落。总体而言，传输提早属于不可控提早，临时没有什么好的技术计划来解决。 存储空间：数据承载于理论的存储中，离线数仓承载于具体的分布式文件系统，实时数仓基于 Kafka 的音讯队列零碎，近实时数仓承载于数据湖存储中。这里能够形象来看离线数仓，Event 承载于分布式文件系统，以小时分区为例，某个小时的分区实质是天然工夫产生的文件的汇合，工夫精度进化为小时级别。 计算提早：数据进入存储之后，与进入计算空间的时间差，t3-t2。实时数仓中，计算提早是数据的 ProcessTime-IngestTime。离线数仓中，计算提早是调度产生实例运行工夫-数据进入存储空间的时间差。实质离线数仓和实时数仓的计算提早在形象上看是统一的。计算提早在不同的数仓体系下，产生的时效不同，咱们会划分为三种支流的数仓体系，秒级的实时数仓，分钟级的近实时数仓，小时级的离线数仓。能够看出，数仓的时效性差别，因为传输提早的不可控，进化为计算提早的差别。 二、离线、近实时、实时三种数仓在工夫维度下的成因在离线数仓和实时数仓，经常会提到数据的有界和无界，认为离线数仓的数据是有界的，实时数仓的音讯流是无界的。精确与否在于数据的确定性考量。 离线数仓的确定性，在于文件天然生成工夫的确定性和不可更改性，某个小时的天然文件生成，近似等于事件工夫在天然工夫的确定性，反例就是咱们能看到数据漂移的状况，事件工夫会或多或少落入上个小时或者下个小时的天然文件生成工夫。那么离线数仓的确定性，本质是数据的 IngestTime 的确定性，具备人造的文件属性，易于宰割。当咱们说离线数仓计算的数据是精确的时候，默认了传输提早带来的影响很小或者默认了以后小时的数据指标的规范是文件的天然造成工夫。 实时数仓，经常会提及不确定性或者说 Lambda 架构理论是对实时数仓的不确定性的代替计划。这种不确定性的起因是什么呢？这里分为四类状况阐明，一是 ETL 的解决，从窗口上来说，是单条数据即为一个窗口，窗口的产生和销毁在一个 Event 中实现，y=window(data)。二是基于 EventTime 的工夫窗口，如果再定义延迟时间，y=window(datas, datas.EventTime, delay)，第三种和第四种别离就是 IngestTime 和 ProcessTime 的工夫窗口函数。比照离线数仓，能够看出，基于 IngestTime 的工夫窗口和离线数仓的工夫语义最为统一。离线数仓在工夫窗口上，能够看做为数据进入文件的天然工夫所对应的小时窗口，数据所承载的文件的确定性，保障了小时窗口的数据确定性，y=window(files)。 近实时数仓，比方基于 Iceberg 的数据湖建设的近实时数仓，在于离线数仓比照中，理论是将基于小时文件细分到分钟级别的快照文件上来，y=window(snapshots)。比照实时数仓，因为 Kafka 的 IngestTime 目前在精确性上是不准确的，基于快照的文件划分，在精确性上有肯定的保障，同时在升高时效水平，从秒进化为分钟，很多场景是能够容忍的。 三种在工夫维度比照上看，一是在某个工夫，统计的实质对业务的需要都是近似的，这个实质是传输提早所带来的，然而这个在实践中，不影响数据的可用性和统计学意义。二是不同数仓的划分，是存储和计算技术倒退所带来的。三是离线数仓的确定性含糊了传输提早，实时数仓的不确定性，是对传输提早的一种取舍，人为的限定了 EventTime 的最大延迟时间，从而保障了指标的时效性，都是具备实际的意义所在。 三、Lambda 和 Kappa 架构在工夫维度下的取舍当离线数仓刚刚倒退的时候，只有一种数仓架构，也是基于大数据分布式解决刚刚倒退的起因。随着实时技术的倒退，大家在时效性上有了更多要求，然而同离线数仓比照的时候，在数据的准确性上，因为统计的窗口不同，必然会导致某个时刻的指标后果的不严格统一。 为了解决这种不严格统一的状况，Lambda 架构（由 Storm 的作者 Nathan Marz 提出的）产生的，实时确保时效，离线确保精确。最终会以确保离线三个工夫窗口的统计一个事件工夫窗口的后果，来回补实时数仓认为 EventTime 窗口，因为时效性抛弃的提早数据的后果，从而保障业务上对 EventTime 窗口的要求，或者默认为离线的 IngestTime 所产生的文件分区近似认为 EventTime 的工夫窗口。这种带来的弊病，保护两套数据路线，而大家总在想方法解决。 ...

FBEC将来商业生态链接大会于2023年2月24日在深圳福田大中华喜来登酒店隆重召开，本次大会由广东省游戏产业协会、深圳市互联网文化市场协会领导，陀螺科技主办。 大会以“勇毅前行·逐光而上”为主题，以具备行业前瞻洞察的“探索者”为视角，逐“光”之旅为主线，聚焦元宇宙、XR、游戏、电竞、数字营销等前沿行业，全方位出现科技前沿成绩，探讨时代与商业议题，筹划新科技、新商业、新模式将来价值，与时代同行者共赴巨变变革下的勇毅逐光之道！ FBEC主会场C：置信的力量——FBEC寰球元宇宙CEO峰会由武汉东湖新技术开发区治理委员会与陀螺科技联结主办，邀请到瑞云科技 CTO 赵志杰带来主题为“元宇宙时代的基础设施——实时云渲染”的精彩演讲。赵志杰认为，元宇宙将来的趋势必定是越来越粗劣、越来越宏大的场景建设，背地离不开实时云渲染技术的反对。 01 元宇宙的撑持技术之一是实时云渲染 我是来自瑞云科技的赵志杰，明天给大家分享对于实时云渲染方面的见解。 咱们的观点是：元宇宙的撑持技术之一是实时云渲染。元宇宙将来的趋势必定是越来越粗劣、越来越宏大的场景建设，如何撑持这些货色的实现，背地离不开实时云渲染技术的反对。 讲实时云渲染之前，先讲讲渲染这个概念。目前渲染和咱们的生存密不可分，无论影视作品，还是各种游戏的实现，背地都离不开渲染技术。以往的渲染过程通常都部署在本地端，当渲染过程部署在云端，咱们则称之为云渲染。目前的趋势，咱们心愿云渲染的能力越来越强，可能补救轻量化终端的低性能劣势。 对于最近比拟火的AIGC，AIGC其实也是渲染的体现形式，通过这种形式，会加强咱们在元宇宙当中体验的真实感、高级感，加强元宇宙的体验。在元宇宙当中，人们能够随时切换身份，在外面进行各种各样的操作，无论是学习，又或者工作、交友、购物、旅行等。为了实现更好的体验，更好的画面成果，咱们则须要更好的云端实时云渲染服务体系的撑持。 02 实时云渲染技术倒退依赖以下几个方面 实时云渲染技术能达到当初的倒退水平，次要依赖于以下几方面技术的晋升和推动： • 5G时代，5G网络带来了技术的引进； • 云计算的倒退为云计算提供了更好的扩展性，用户通过网络能够取得更好、更有限的资源。 • 游戏引擎的倒退，不仅是对游戏行业自身有微小的带动作用，尤其在真实性、模仿性等方面给用户带来了更好的体验。所以游戏引擎的根底倒退，对整个技术也有很大的推动作用。 • 还有显卡技术的倒退，对于所有行业的利用来说也是离不开的。 03 实时云渲染技术原理 实时云渲染技术的原理非常简单。当咱们用手机或者轻量化的终端来操作的时候，个别状况下，它的利用大小和画面成果是受限制的。举个例子，如果咱们要在手机上看到十分真切的几十万根头发的虚拟人，靠手机、Pad的算力其实无奈实现实在实时的渲染。 对于如何在手机等轻量化的终端上实现高画质的渲染和大场景输入，咱们的思路是把重度的和图形图像相干的算力部署在云端。云端能够借助于高性能的服务器，把图形图像的重度计算放在云端执行，当云端实时渲染的画面进行编解码之后，再通过网络传送到各种各样的终端，除了手机、平板外，也包含VR设施等，这就解决了轻量化终端算力有余的问题。 04 瑞云科技实时云渲染技术特点 首先，是依靠于利用的运行平台。无论是什么利用，须要把这个平台先托管到云渲染平台上，在平台上的真正计算节点，都能够在计算平台上实时调取利用，实时运行。 第二，实时云渲染集成了当先的SaaS服务，登陆咱们的网站，只用简略的几步操作就能够体验SaaS服务，流程非常简单。 第三，依靠于自主研发的协定。一些大型开发我的项目，用现在支流的引擎软件，打进去的包变得越来越大，从原来的几百兆倒退到几十G，当须要把利用上传到云端的时候，都会面临传输速度的瓶颈。而通过咱们自研的协定，能够把上传过程大大放慢，10G的文件几分钟就可能传完。此外，咱们这个协定能够通过浏览器进行拜访，这对分享来说十分便当，大家能够通过微信、小程序推送给用户。 05 3DCAT技术劣势 接下来简略谈一下咱们的技术劣势，包含：反对各种各样的引擎、适配WebRTC协定、反对提供多规格、自适应的码流能力等。咱们有业界当先的调度性能，也反对多零碎的平台调度，反对调度策略的灵便设置。咱们当初用不同的卡，以匹配对应的工作性能。比方Unity利用对显卡要求不高，1660就能够满足，而有些利用对显卡的需要更高，比方帕斯卡等，这时候咱们能够指定不同的利用，指定不同的显卡类型。并且还能够提供浏览器来监控和治理后盾。 06 3DCAT分为私有云和公有云两个版本 对于实时云渲染，咱们本人有一个品牌，叫3DCAT，分为私有云和公有云两个版本。 私有云的架构比较简单，底层是X86，外面从属了自研的推流零碎。登陆咱们的网站注册之后，只须要几步就能够实现。这种原理决定了咱们对终端的兼容性特地好，无论是手机、平板，还是PC，甚至VR头显都能够用同样的形式来进行输入。此外，咱们也反对微信、小程序等。 为了让用户有更好的体验，咱们在国内建设了各种各样的多个边缘计算节点，当用户有申请的时候，零碎主动判断调用离用户最近的计算中心，为用户提供更好的网络服务，缩小用户的延时和期待。 无论是资源老本，还是服务方面，咱们都有相应的劣势，因为咱们做云渲染相干服务有超过10年的历史，对于利用平安较有保障。举个例子，个别手机上浏览一些3D在线数据的时候，它会缓存到本地终端，从安全性上来讲，实时云渲染的安全性会高很多。 咱们还通过了TPN认证，是国内少数几家有TPN认证的厂家。咱们计划的劣势包含： • 云端部署：所有货色都部署在云端； • 全域反对：除了提供平台，也提供从利用制作到散发一体化的解决方案； • 所有的货色都能够进行对立的治理：以往装置或者运行交互式的利用，须要逐台机器去装置运行，而当初能够对所有利用进行对立的治理，比方降级一次或者是内容替换之后，所有的用户再次关上都是对立更新过的画面； • 端云联合：所有的简单运算都集中在云端，轻量化终端变成接管工具，这样就能够实现升高终端配置需要； • 极简操作：所有的操作都十分的便捷，只有几步就能够实现； • 数据安全：内容存储在云端，数据与用户拆散，无效爱护知识产权，平台取得TPN权威认证 除了方才说的私有云，咱们也提供公有云的计划。公有云的计划特地适宜于对安全性要求十分高的单位，比方军事单位，或者是对性能要求比拟高的场景，比方VR头显。如果是同样的内容，立体类的利用对带宽的要求不高，但VR头显对带宽要求会比拟高，个别推流码率能达到40～60兆，所以私有化的计划也特地适宜对性能要求比拟高的场景。 07 3DCAT领有丰盛的落地案例 最初，我再聊一下咱们曾经落地的案例。一是Matterverse（次元跃升），它通过实时云渲染的形式，在手机上也能够关上。通过云渲染，它能够进行各种各样的交互，实现虚构角色的各种操作。对于目前比拟火的数字人，咱们也有一些本人的体验。 当初的趋势是往越来越实在的方向走，但凭借目前的手机算力，想打造十分真切的数字人并不简略，而咱们能够通过实时云渲染的形式，将这个画面实时推送到手机终端。还有一个是汽车畛域的案例，咱们与奥迪进行了相应的单干，借助实时云渲染技术甚至是光线追踪技术，能实现实时交互的高精度画面输入。 以上讲的案例都是运行在实时云渲染的平台之上，心愿将来有更多、更好的利用能够运行在咱们的平台之上，谢谢大家！ 文字起源：VR陀螺本文 《FBEC大会 | 瑞云科技 CTO 赵志杰：元宇宙时代的基础设施——实时云渲染》内容由3DCAT实时云渲染解决方案提供商整顿公布，如需转载，请注明出处及链接。

作者：vivo 互联网实时计算团队- Chen Tao 本文依据“2022 vivo开发者大会"现场演讲内容整顿而成。 vivo 实时计算平台是 vivo 实时团队基于 Apache Flink 计算引擎自研的笼罩实时流数据接入、开发、部署、运维和经营全流程的一站式数据建设与治理平台。 一、vivo 实时计算业务现状2022年，vivo互联网在网用户总数达到2.8亿，多款互联网利用的日活超过了千万甚至冲破了1亿，为了向用户提供优质的内容和服务，咱们须要对如此大规模的用户所产生的海量数据进行实时处理，帮忙咱们进行经营决策、精准举荐、晋升终端用户体验，同时通过晋升咱们的商业化能力为广告主提供更加优质的广告服务。 近几年，大数据实时计算技术和公司的实时数据业务都在飞速发展，截止到往年8月，vivo实时计算每日解决数据量达到5PB，无效工作数超过4000，目前已接入98个我的项目，从趋势上来看，每年都有超过100%的规模增长，如此大的业务规模和业务增速给咱们实时计算团队带来的十分大的挑战。首先，咱们要确保业务的稳固，高速增长的数据、简单的业务场景和零碎架构须要咱们自底向上的全方位的稳定性建设；为了帮忙用户疾速落地业务，咱们须要升高开发门槛，提供良好的易用性和笼罩各种场景的性能个性，业务的高效接入和运维能带来长期的降本收益。同时，大规模的数据和计算咱们也心愿可能以尽可能低的老本去运行，这就须要咱们提供高效的存储、计算能力，并且对于许多要害业务，实时计算时效性保障的要求也十分高。在简单的数据环境中要保障数据安全须要有十分良好的且具备前瞻性的设计，优良的平安能力须要可能提前防备可能的危险。 咱们从2019年下半年启动了实时计算平台的建设，2020年关注在稳定性建设，初步上线了SQL能力，2021年引入了Flink 1.13版本并启动了容器化建设，2022年次要关注在效率晋升，包含流批一体、工作诊断等，到目前为止，咱们平台已初步具备了一些能力，所以明天我代表咱们团队简略给大家介绍一下咱们的平台建设实际。 二、实时计算平台建设实际 从咱们大数据平台的体系架构上来看，咱们通过汇聚层能力收集整个vivo互联网的埋点、服务器日志，通过计算、存储、剖析等能力从海量数据中挖掘出业务价值。实时计算作为平台的外围能力之一，它同时满足了大规模数据计算和高时效计算的需要，咱们通过实时计算平台来承载和向业务提供这方面的能力。 vivo实时计算平台是基于Apache Flink计算引擎自研的笼罩实时流数据接入、开发、部署、运维和经营全流程的一站式数据建设与治理平台。接下来我会从根底服务建设、稳定性建设、易用性建设、效率晋升和平安能力建设五个方面来介绍咱们团队的建设思路和实际过程。 2.1 根底服务建设 咱们自研的实时平台后端架构包含两个外围服务： SubmissionServer：负责作业的提交，以及跟资源管理零碎的交互，具备高可用、高可扩大能力，反对多版本Flink和多种工作类型。ControlServer：负责工作运行状态的保护，咱们定义了9种工作状态，通过一个内置状态机进行实时的状态保护，状态的更新提早在秒级。根底服务还包含对立的元数据服务和实时的监控告警服务。这两个局部做一下简略介绍。 咱们应用HiveMetaStore作为元数据根底服务，基于TIDB的扩大能力，以后元数据实体规模已达到亿级，通过对MetaStore服务的优化，大分区表操作性能晋升了10倍，目前已接入Spark、Hive、Flink、Presto等引擎，同时，对立的权限管制、数据分类分级、数据血统、元数据变更记录等能力也为数据治理提供了良好的根底。 咱们基于Flink的CEP能力构建了一套秒级提早、反对动静规定配置的监控告警零碎，同时从基础设施、根底服务、实时工作和业务多个维度构建了全方位的监控体系。以上这三个方面形成了咱们的根底服务。根底服务都具备高可用个性，然而要保障业务稳固，还须要关注整个零碎以及在零碎上运行的业务数据链路，这里最重要的有两个方面：大数据组件服务的稳定性和工作自身的稳定性。 2.2 稳定性建设 咱们应用HDFS作为状态的长久存储和业务数据落地的存储，随着存储规模和读写量的增长，咱们遇到了DataNode的StaleNode问题、低版本HDFS流式写无奈复原问题和越来越重大的小文件问题，为此咱们通过平滑降级HDFS到3版本、优化Flink Sink性能和基于Spark3建设小文件合并服务来解决这些问题。 Kafka是次要的流存储组件，然而在集群运维上存在一些痛点，比方扩缩容和节点硬件故障会导致资源不平衡和生产生产的异样，Kafka团队建设了流量平衡和动静限流能力，显著晋升了Kafka服务的稳定性，同时咱们也晋升了Flink对Kafka Broker重启的容忍度，可能无效缩小Broker故障对运行工作带来的影响。 另外，Flink工作的高可用依赖于Zookeeper，为了防止ZK leader切换对实时作业的影响，咱们对1.10和1.13版本的Flink进行了容忍度加强，对更低版本的工作做了版本升级，也依据社区教训优化了Flink HA局部的性能，以及增强了对ZK的全面监控和治理，保障了ZK的稳定性。 通过这些对相干组件的优化措施缩小了工作异样工夫和次数，无效的晋升了工作稳定性。接下来介绍一下咱们针对某种特定场景的Flink工作稳定性优化实际。 在内容实时举荐场景，产生自在线预估服务的用户特色快照须要与用户实时数据进行拼接，因为数据量微小在做Join时须要一个大缓存，相比于原来采纳Redis作为缓存的计划，Flink的RocksDB状态后端是一个更适合的计划，然而在状态大小达到TB级别时，工作稳定性很难保障。咱们基于对RocksDB内存模型的深刻理解，扩大原生监控指标，降级RocksDB版本，建设了状态治理相干能力，把工作稳定性晋升到了生产可用级别。在多个业务场景上线后，样本和模型的时效性和稳定性失去保障，举荐成果失去很大晋升。 后续咱们布局通过减少读缓存和优化前缀匹配策略进一步晋升RocksDB状态后端的性能。 咱们始终在思考如何进一步晋升业务的稳定性，绝对于工作的稳定性咱们的用户更加关怀他们所须要的数据是否准时、数据品质是否合乎预期，而工作的稳固不齐全等同于时效和品质。在时效这个维度咱们定义了数据准时率的SLI指标，这对咱们有两方面的指引：更自动化和精细化的故障分级保障和流计算的弹性能力的建设。其中前者正在建设中，后者也在咱们的布局之中。 2.3 易用性建设 从实时作业开发角度， 咱们提供了功能完善、体验良好的FlinkSQL开发环境。相比于社区版本Flink，咱们对SQL能力进行了扩大，比方更加可控的窗口计算触发性能，兼容性更强的DDL性能，更加不便的流表创立性能，咱们对Format、Connector、UDF都做了一些扩大和优化，实用于更多业务场景，晋升了性能；同时咱们建设了运行于Standalone集群的SQL调试能力，具备数据抽样、上传、DAG图展现、调试后果实时展现等性能。通过一年的建设，新增SQL运行工作占比从5%晋升到了60%。 从实时作业运维角度， 咱们提供了实时全链路的血统与提早监控性能。为了实现数据业务，实时计算链路往往是很长的，而一个团队个别只负责其中一段，为了解决链路中呈现的问题，可能须要上下游多个团队配合，效率很低。咱们作为平台团队为用户提供了一个全局的视角，这样能够迅速定位到异样工作节点，十分高效。血统数据能够实时生成，并且不须要工作的重启，因而不存在血统不全的问题。同时，咱们也能够输入端到端全链路提早数据和工作解决提早数据，帮忙咱们的用户做品质监控。 2.4 效率晋升 往年，降本提效是咱们的重点工作方向，咱们从计算、存储和资源治理三个方面做了一些工作，获得初步成果。YARN资源管理的粒度较大，而K8s更精密的资源粒度从整体上来看能够无效晋升资源利用效率。YARN尽管开启了cgroups，然而对系统资源的隔离能力依然较弱，个别异样工作耗尽机器资源可能影响失常运行的工作。因而平台反对了K8s的资源管理能力，借助于Flink社区提供的Native K8s个性以及平台良好的可扩展性，咱们以后反对JAR工作的容器化部署，并且通过在开发、运维、资源交付等方面的建设确保了用户体验与YARN是统一的。借助于容器化，咱们能够确保开发、测试、线上等环境的一致性，研发效率也失去晋升。目前已接入3个业务，明年会比拟大规模的利用。 多年以来，大数据畛域在倒退过程中造成了批和流两套架构并存的现状，很多时候，业务在落地过程中不得不同时思考和投入建设两套链路。比方离线数仓和实时数仓独立建设，数据口径和计算结果的一致性保障须要付出额定的致力，Hive表不反对数据更新、探查较慢，Kafka数据回溯和查问艰难等问题也始终困扰着数据开发人员。 侥幸的是，业界曾经摸索进去基于数据湖组件在分布式存储之上构建流批对立存储的技术，咱们依据vivo的业务特点抉择并设计了咱们的流批一体计划，目前曾经实现基于Hudi的对立存储引擎、基于Flink的对立入湖、基于HMS的对立元数据建设，目前业务曾经实现试用并开始接入。往年咱们次要接入实时业务，明年会有离线业务的接入。这也是咱们大数据平台构建湖仓一体很重要的一步。 在长期的实时作业运维过程中，咱们积攒的大量作业调优和问题解决教训，随着运维压力的减少，咱们在思考如何晋升运维效率。咱们也发现用户资源队列用满的同时，机器的CPU利用率却处于较低水平，因而咱们思考如何缩小资源节约，晋升集群的资源利用效率。资源诊断和异样诊断这两类问题都是作业优化问题，要优化作业，首先须要把握作业及其运行环境的信息，包含运行指标、运行日志、GC日志、依赖组件运行状况、操作系统过程级别信息，以及作业配置、环境配置等等，而后须要将运维教训和思路转化为启发式算法的规定和数据，使用这些数据、算法和规定去找到优化的办法。基于这个思路，咱们建设了一个诊断服务，具备灵便的信息收集、规定配置、数据调优性能，可能在作业启动或运行时，诊断作业的衰弱水平，提供一些作业的优化倡议给咱们的用户。目前资源诊断能力曾经在运行，异样诊断还在建设中。 2.5 平安能力建设 作为一个根底的大数据服务，平安在咱们看来是一个十分重要的命题，因而咱们在零碎设计之初就思考了实时数据拜访、离线数据读写、各个系统与服务之间的平安隔离能力等方面的设计，在实时数仓具备肯定规模后，咱们又建设了数据分类分级、日志审计等能力。去年，依据最新的合规要求，离线存储反对了列级别通明加密，实时数据反对了敏感字段自动检测等能力。平安无止境，咱们也在对DSMM进行钻研解读，以继续晋升大数据的平安能力。 以上是咱们平台建设的一些实际，总结来看，咱们基于Flink建设了性能比较完善的实时计算开发和运维能力，业务复杂度越来越高，咱们的挑战还有很多，比方Flink引擎的优化与难点问题的解决、计算效率的进一步晋升、流批一体、容器化的大规模利用等，都是咱们后续的重点方向。 后面有提到，基于实时计算平台，公司的多个中台团队建设了五大中台能力，笼罩了各种各样的实时场景，这里就跟大家简略分享下其中两个典型场景。 ...

Flink Forward Asia 2022 将于 11 月 26-27 日在线上举办，议程内容正式上线！往年是 Flink Forward Asia（下文简称 FFA）落地中国的第五个年头，也是 Flink 成为 Apache 软件基金会顶级我的项目的第八年。过来这几年，Flink 一方面继续优化其流计算外围能力，一直进步整个行业的流计算解决规范，另一方面沿着流批一体的思路逐步推进架构革新和利用场景落地。随同着实时化浪潮的倒退和深入，Flink 已逐渐演进为流解决的领军角色和事实标准。 作为开源大数据畛域的顶级盛会之一，往年的 FFA 将持续集结 Flink 最新技术动静和最佳行业实际 ，并踊跃拥抱生态搭档，共建凋敝开源大数据生态。 连续 FFA 常规，会议所有议题均为凋谢征集而来，并由业余的议题评比委员会评分筛选，确保内容代表行业领先水平，为开发者们输入更加优质的干货。往年，咱们将在 FFA 上看到阿里巴巴、字节跳动、快手、美团、华为、Shopee、运满满、米哈游、蔚来汽车、集度汽车、菜鸟、网易等寰球 40+ 各行业一线厂商，围绕 Flink 核心技术、行业实际、平台建设、实时风控、实时湖仓、数据集成等多个时下热门方向，分享 80+ 干货议题，带来一场专属于开发者的技术盛宴。 Flink Forward Asia 2022 工夫：11月26日-27日 PC端直播观看：https://flink-forward.org.cn/ 「点击议题，即可查看议题详情以及讲师介绍」挪动端倡议观看 ApacheFlink 视频号预约观看: 一、重量级内容评审团FFA 2022 邀请了 11 位行业首领及开拓者组成议题评比委员会，并持续由阿里巴巴开源技术委员会负责人贾扬清负责主席，独特为大会内容护航，他们别离是： 二、Apache Flink 新方向、新利用及新成绩在去年的 FFA 2021 主题演讲中，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰提出了 Flink 下一步的倒退方向——流式数仓（Streaming Warehouse，简称 Streamhouse），预示着 Flink 要从 Stream Processing 走向 Streaming Warehouse 去笼罩更大的场景，帮忙开发者解决更多问题。Flink 社区也把拓展适宜流批一体的数据存储作为重点技术方向来推动，并在前不久公布了 Flink Table Store 0.2.0。过来这一年，Flink Table Store 这一全新数据湖存储我的项目获得了哪些新进展？又有哪些利用实际新成绩？Flink 接下来还有什么新打算？将在这次 FFA 2022 主会场上一一揭晓。 ...

摘要：本文整顿自智慧芽数据仓库架构师曲明星在 Flink Forward Asia 2021 实时数仓专场的分享。本篇内容次要分为三个局部： 产品架构技术架构将来打算点击查看直播回放 & 演讲PPT 一、产品架构 上图是智慧芽APP 的产品架构图，包含后盾管理系统、AI、内容引擎、帮忙核心，为客户提供知识产权信息化服务和科技翻新情报系统。 二、技术架构2.1 原实时剖析计划 上图是原来的实时剖析计划。流程大抵是客户检索一个条件，通过剖析 API 把客户检索的相干条件发送到不同的搜索引擎。这种计划会产生 4 个问题： 对检索性能产生影响；简单剖析须要开发插件反对；跨多个搜索引擎剖析复杂度高；不同维度的数据无奈存储。在建设实时数仓前，收集了业务要求实时数仓特点： 秒级响应；准实时数据更新；能反对一定量的并发能力；与搜索引擎数据保持一致；反对简单剖析的能力；反对对立应用形式及支流个性；反对与搜索引擎交互；反对存储容量横向扩大的能力。 上图是数据平台概览。从下往上看： 最上层是数据底座，包含数据存储和数据计算，其中数据计算层由 Spark、Kafka、Flink 组成；中间层是数据平台，包含数据开发、数据分类、数据管理和数据服务；下层是数据利用，次要有数据业务、内部剖析服务和外部剖析业务形成。2.2 新实时剖析计划 新的技术选型次要基于 TiDB，次要包含数据存储、数仓服务两个局部。数仓服务分为安全检查、驱动表治理、缓存治理、集群负载查看以及执行器等局部。 抉择 TiDB 是因为它是云原生并且社区沉闷、满足 TP 及 AP 业务场景、丰盛的生态工具及多平台以及其应用简略，兼容 MySQL 以及大数据能力。 抉择 Flink 也是因为它是一个开源的大数据计算引擎，并且有沉闷的云原生社区，可能满足对数据的及时性要求，一致性方面有 exactly-once 语义，同时具备低提早高吞吐量。 在线业务数据写入流程：把源头的数据变更放到音讯队列中去，通过索引程序将数据散发到不同的搜索引擎，同时搜索引擎也会给索引程序发送音讯。 离线剖析技术体系：整个离线剖析技术体系比拟依赖于 oss。将每日的增量数据离线放到 oss 里，对全量的数据进行一些比较复杂的剖析。 离线业务数据写入流程：数据变更会触发长久流化至 oss，oss 同时会和历史流进行合并在 oss 放一份全量数据。 2.3 原用户行为剖析计划原用户行为剖析计划是非常复杂的计划，这个计划在前端有 JS 和 Java 的 API，JS 会将用户的埋点数据搁置到 Segment 中去，同时有 Gainsight 和 AMPLITUDE 两个合成化引擎。 2.4 新用户行为剖析计划 ...

本⽂由社区志愿者邹志业整顿，内容起源⾃阿里云实时计算产品经理李佳林（风元）在 7 月 5 日 Flink 峰会（CSDN 云原生系列）的演讲。次要内容包含： 基于 Flink 构建风控系统阿里风控实战大规模风控技术难点阿里云 FY23 风控演进打算点击查看直播回放 & 演讲PPT 目前 Flink 根本服务于团体的所有 BU ，在双十一峰值的计算能力达到 40 亿条每秒，计算工作达到了 3 万多个，总共应用 100 万+ Core ；简直涵盖了团体内的所有具体业务，比方：数据中台、AI中台、风控中台、实时运维、搜寻举荐等。 一、基于 Flink 构建风控系统风控是一个很大的话题，波及到规定引擎、NoSQL DB、CEP 等等，本章次要讲一些风控的基本概念。在大数据侧，咱们把风控划分成 3 × 2 的关系： 2 代表风控要么是基于规定的，要么是基于算法或模型的；3 代表包含三种风控类型：当时风控、事中风控和预先风控。1.1 三种风控业务 对于事中风控和预先风控来讲，端上的感知是异步的，对于当时风控来讲，端上的感知是同步的。 对于当时风控这里稍做一些解释，当时风控是把曾经训练好的模型或者把曾经计算好的数据存在 Redis 、MongoDB 等数据库中； 一种形式是端上有相似 Sidden 、Groovy 、Drools 这样的规定引擎间接去 Redis 、MongoDB 取数据来返回后果；另外一种形式是基于 Kubeflow KFserving ，端上申请过去之后基于训练好的算法和模型返回后果。整体来讲这两种形式的时延都在 200 毫秒左右，能够作为一个同步的 RPC 或 HTTP 申请。 对于 Flink 相干的大数据场景是一个异步的风控申请，它的异步时效性非常低，通常是一秒或者两秒。如果谋求超低时延，则能够认为它是一种事中的风控，风控决策过程能够由机器染指解决。 很常见的一种类型是用 Flink SQL 做指标阈值的统计、用 Flink CEP 做行为序列规定剖析，还有一种是用 Tensorflow on Flink ，在 Tensorflow 中进行算法形容，而后用 Flink 来执行 Tensorflow 规定的计算。 ...

业务介绍新东方教育科技团体定位于以学生全面成长为外围，以科技为驱动力的综合性教育团体。团体由1993年成立的北京新东方学校发展壮大而来，领有短期培训零碎、基础教育零碎、文化流传零碎等业务。 在互联网大潮中，新东方在IT技术上也一直重构，继续投入大数据建设，研发大数据的相干技术和利用，从而疾速而精准地响应业务需要，并用数据为团体各级领导提供决策依据。新东方的大数据利用次要包含两局部： 企业应用端的业务场景（B端）：包含交易，教学，人员等数据，数据规模为TB级。数据会被依照不同的条件和学校层级等，造成营收、教学、客服、财产人事等实时报表，为CRM零碎的成千上万名业务参谋提供线索和商机的明细报表查问，同时也供各级管理人员理解业务的运行状况，辅助业务决策。互联网间接面向用户场景（C端）：次要为招生引流类、云教室等利用，包含网页版，App端，H5等，数据量为PB级。这部分数据记录了用户（学员和潜在用户）在新东方的教学闭环轨迹，C端数据除了生成惯例的经营报表外，还会绘制用户画像，进而开发举荐零碎和圈选等利用，改善C端各种利用的用户体验，进一步精细化经营。数仓建设和利用痛点为了满足日益增长的业务需要，团体开始投入数仓建设。在数据仓库建设的初期，以业务驱动为主。通过阿里云的MaxCompute为外围构建数据仓库，间接集成业务库数据以及WEB利用的OSS日志等，而后在数据仓库中剖析业务数据并产生统计分析后果。初期的架构如下： 依据业务须要，将中小型规模的后果导入MySQL并反对数据更新。数据规模较大的只读后果则导入 MongoDB。而后Web服务层查问MySQL和MongoDB并向用户提供服务接口， Web服务层也能够通过Lightning减速接口间接查问MaxCompute的数据， Lightning协定是MaxCompute查问减速服务，反对以PostgreSQL协定及语法连贯拜访MaxCompute数据，相比MaxCompute提供的odps jdbc接口速度要快得多。起因是后者把每次拜访作为一个Map-Reduce解决，即便很小的数据量查问响应工夫也要超过10秒，而 Lightning能将延时降到百毫秒内，满足业务后果报表的展现需要。目前Lightning服务进入服务下线阶段，新的减速服务由Hologres减速集群代替。 应用这套架构能够在较短的工夫内满足报表开发、用户画像和举荐服务等需要，为新东方的日常经营和招生引流提供较好的数据反对。然而随着业务的发展，这套架构越来越难以满足用户的需要，次要体现在： 实时性，业务心愿可能达到1分钟级甚至秒级的实时性，而应用MaxCompute只能实现批量解决，个别只能提供分钟级（个别5分钟以上）的延时来自Web服务层的高并发查问，MaxCompute的大数据量查问只能反对到100左右的QPS，满足不了来自C端利用的高并发查问简单逻辑的大数据量剖析和Ad-hoc查问，随着剖析数据迅速从数百G上涨到TB级，在多个数亿行以上的数据进行简单报表开发，单实例MySQL难以反对；而MongoDB无奈应用规范的SQL进行简单查问，同时MongoDB自身简单的查问业务，开发效率很低。Lightning接口尽管反对规范的SQL并且某些场景上速度比拟快，然而Lightning开始逐步下线，须要找到替换的办法。实时数仓选型要解决以上的业务痛点，就须要找到能满足实时数仓建设需要的产品。大数据团队调研了多种实时数仓计划，基于新东方的数据和利用特点进行选型，计划比对如下： 产品Ad-hoc查问高并发反对（QPS）SQL反对TP(交易)反对与MaxCompute/Flink集成文档和技术支持ClickHouse 20.1反对PB级以上默认反对100的并发查问，qps取决于单个查问的响应工夫单表查问反对较好，简单报表查问反对较弱通过mutation反对update，较弱反对文档丰盛，社区反对较好Doris 0.9反对PB级以上数百兼容MySQL不反对通过兼容MySQL与MaxCompute集成,与Flink的集成 不明确文档和社区都较差Hologres 1.1反对PB级以上数万以上兼容PostgreSQLDDL反对与MaxCompute间接在存储层集成，并且都兼容PostgreSQL，提供Flink Connector集成阿里在线文档和技术支持Tidb 4.x （含Tiflash）反对PB级以上数万以上兼容MySQL反对反对文档丰盛，社区反对较好Elastic Search 7.x反对PB级以上数万以上不反对规范SQL不反对反对与MaxCompute集成，Flink Connector只反对Source文档丰盛，社区反对较好从以上的表格能看出，Tidb和Hologres能够较好地解决新东方在大数据方面面临的问题。然而Tidb须要公有云部署并运维，而MaxCompute部署在私有云，两者在不同的云环境。Hologres是阿里云提供的云原生服务，并与MaxCompute都部署在私有云，且在Pangu文件层严密集成，数据交换效率远高于其余内部零碎，两者都兼容PostgreSQL，从离线数据仓库开发迁徙到实时数据仓库开发难度升高。 基于以上的剖析，抉择Hologres作为实时数仓。 实时数仓建设实时数仓是在离线数仓的根底上，基于Lambda架构构建，离线和实时同时进行建设。无关Lambda的，参阅：[Lambda architecture] 架构的各组件阐明：1）数据源： Binlog，即各类利用（B端和C端）的数据库Binlog，对于SQL SERVER的数据库则是CT log;App音讯，即App运行时上报的事件;Web日志/埋点日志，即Web服务器所产生的ngix日志，以及Web app/H5运行时埋点服务产生的日志2）CDC数据总线（简称CDC） CDC数据总线采集数据源，写入Kafka Topic。对于离线数仓和实时数仓, CDC都是间接交互的数据源/CDC包含Source Connector、Kafka 集群、Sink Connector三局部。 Source Connector 负责从数据源采集数据并写入Kafka集群的Topic，而Sink Connector则将Kafka Topic的数据ETL到指标库，包含实时和离线数仓。CDC易于部署和监控，并提供了简略的数据过滤，老本较低，数据ETL工作尽量采纳CDC。3）离线数据处理 离线数据处理基于MaxCompute搭建，用于计算全量数据，数据源来自于CDC的实时导入。离线数据通过离线数仓计算（ODS->DWD/DWS→ADS）导入Hologres作为存量数据，一部分离线的DWD/DWS数据也导入Hologres作为维表的存量数据。Flink计算工作会将ADS层后果Sink到MaxCompute， 用于数据备份。4）实时数据处理实时数据处理基于阿里云托管的 Flink流式计算引擎。与离线数仓解决固定日期的数据（如T+1）不同，实时数仓解决的是流式数据，从工作启动开始，就始终运行，除非异样终止，否则不会完结。数仓的档次与离线数仓相似，依据实时处理的特点做了简化。如下表所示: 数仓档次形容数据载体ODS层与数据源表构造类似，数据未通过解决Kafka Topic/cdc ConnectorDWD/DWS层数据仓库层，依据业务线/主题解决数据，可复用Kafka TopicDIM层维度层holo 维表，Kafka TopicADS层应用层，面向利用创立，存储处理结果holo实时后果表，Kafka Topic5）Hologres 数据查问 数据表名称形容数仓档次数据源维度数据表维度建模后的数据表，在实时计算时事实表通过JDBC查问DIM层初始化数据来自离线数仓dim 层、CDC、Flink维表计算工作实时后果表实时数仓的计算结果表实时数仓DWS/ADS层实时数仓的DWS/ADS层计算工作存量后果表离线数仓的计算结果表实时数仓DWS/ADS层离线数仓的DWS/ADS层计算工作查问view合并实时和存量后果，对外提供对立的展现View实时数仓ADS层存量后果表实时后果表 表面来自MaxCompute的数据表援用各层次离线数仓备份表备份实时计算一段时间内的数据，用于做数据校验和问题诊断DWD/DWS层实时数仓利用场景通过新的架构，反对了新东方团体内如下利用场景： 实时报表查问：为CRM零碎的成千上万名业务参谋提供线索和商机的明细报表查问，同时为管理层提供实时流动看板服务，延时秒级，辅助业务决策。Ad-hoc查问：B端和C端经营人员能够间接通过Hologres定制本人的简单业务查问用户轨迹和画像场景：实时处理用户来自B端和C端的数据，生成用户轨迹和标签，为业务疾速决策提供根据。举荐零碎和圈选业务：通过Maxcompute训练离线模型，并通过Flink数据调整模型的参数。基于用户的实时轨迹数据圈选出符合条件的用户并推送服务，进一步精细化经营。应用实际一个典型的实时工作解决流程如下图所示： ODS层数据通过CDC数据总线导入MaxCompute， 提供离线计算源数据。 同时也会将数据写入到Hologres,用于做数据验证。 在Hologres中，维表存储全量数据。而其余类型的ODS数据表个别存储工夫>离线的计算周期即可，如离线T+1，则存储2天，无相应的离线计算工作依据验证数据周期而定。Flink工作读取ODS层数据作为输出，与存储在Hologres中的维表做关联，计算的后果存储到DWD/DWS层的Kafka Topic中，同时将后果写入到Hologres用于数据验证，数据存储工夫与ODS层雷同Flink工作读取DWD/DWS层数据，与存储在Hologres中的维表做关联， 将结算的后果存储到Hologres。依据利用须要，如果是Lambda架构，存储工夫>离线的计算周期即可，如离线T+1，则存储2天，如果是Kappa架构，保留全副数据， 同时将后果数据写入离线数仓用于离线剖析用（可选）。上面具体介绍在每一步解决流程中的应用实际与教训优化，以帮忙达到更好的成果。 数据验证因为实时处理源数据和后果都是动静的，数据验证无奈在工作中进行。能够在Hologres中，对实时数仓的各层落仓后果进行验证。因为实时处理和工夫相干，每一档次的数据都须要带上一个解决工夫戳(Process Time)。在Lambda架构中，将实时后果和离线后果进行比对，假如离线解决周期为T+1, 则实时处理取工夫戳与昨天的数据进行比对，计算出准确率。如果是Kappa架构，须要进行逻辑验证，并与业务人员解决的后果数据进行比对。 全量数据初始化Kafka Topic个别存储几天内的数据，不能提供全量数据，所以须要从离线数仓进行全量数据初始化，将维表、ADS层后果等导入Hologres。 Hologres维表的Lookup和性能优化1）Lookup在Flink计算工作中，流表和Hologres的维度数据表Join，就是Lookup。Lookup须要解决两个问题： ...

作者｜爱奇艺大数据团队 数据作为互联网时代的根底生产资料，在各大公司企业领有无足轻重的位置。数据的价值在互联网公司的体现，大抵而言能够分成三类： 挖掘数据中的信息来领导决策，如产品经营、用户增长相干的 BI 报表依靠数据优化用户体验和变现效率，如信息散发场景下的个性化举荐、成果广告等基于数据统计的业务监控，如监控大盘、平安风控等在这些体现大数据价值的业务场景上，存在一个广泛的法则，即数据产生的价值，随着工夫的推移而衰减。因而，随着公司业务的倒退，传统的 T+1 式（隔日）的离线大数据模式越来越无奈满足新兴业务的倒退需要。发展实时化的大数据业务，是企业深刻开掘数据价值的一条必经之路。 爱奇艺大数据团队自 2014 年开始引入Kafka、Storm、Spark Streaming 等实时化技术，2017 年引入 Apache Flink 实时计算框架，逐渐建设了一套买通数据采集、加工、散发、剖析、利用等残缺数据流程的实时大数据体系。这套实时大数据体系反对了峰值超过 3000 万 QPS 的实时数据处理，反对了如春晚直播、青春有你、尖叫之夜等大型流动的实时计算需要。本文将介绍爱奇艺实时大数据体系的次要架构、平台性能以及倒退过程中的一些思考。 一、传统实时 ETL 模式的问题在实时技术倒退初期，大团队为各业务提供的是单纯的日志数据的实时解析服务。通过 Flink ETL 程序，将用户端上报日志、后盾服务器日志、数据库 binlog 日志，解析成 key-value 组装的 json 状态的结构化数据，发送到 Kafka 中供各业务应用。其中，ETL 逻辑能够由内部配置平台注入，不便在解析逻辑批改时能够动静加载，缩小 Flink 工作的重启频率。这个实时 ETL 的体系如下图所述： 随着实时大数据业务的倒退，它的弊病一直呈现： 实时数据大量反复生产，各业务烟囱式开发，数据难以复用数据治理程度低下，数据生产者不晓得数据在被谁生产稳定性差，不能抵挡 Flink 和 Kafka 故障为了解决这些问题，爱奇艺大数据团队开始建设实时大数据体系，推出治理 Kafka 的流数据服务平台、基于 Flink 的实时数据生产平台、基于 Kafka 的实时数仓等组件，买通实时数据流程。 二、实时数仓与传统数仓的区别在传统的 BI 体系中，基于离线大数据构建数据仓库的过程，大部分是 T+1 的隔日离线计算。即每天凌晨开始从原始日志数据构建数仓，将多层级的离线计算工作，通过工作流零碎进行串联。数仓构建工作失败后能够有由工作流零碎触发工作重跑。一般来说，离线数仓构建工作的失败重跑，只影响数据生产进去的工夫，不影响数据的完整性、正确性。 在设计离线数仓模型和对应的计算工作时，个别会从以下几个角度去兼顾均衡： 数据收缩的老本束缚（Hive 存储）计算资源的老本束缚（YARN 队列）开发的人力老本束缚用户体验，蕴含数据的时效性以及数仓表应用的便捷性在实时数仓中，这几个约束条件产生了微小的变动： 基于这些变动，构建实时数仓的时候，切记不能照搬离线数仓的分层模型和构建逻辑，须要联合实时大数据业务的需要，依照实时业务的特点进行构建。实时数仓的构建，外围有以下几个特点： 1、器重数仓的程度拆分。在离线数仓中，数据的载体是 Hive 表，借助 Hive 的分区字段和谓词下推机制，咱们能够在各个层级构建一些稍大的表，而将要害的维度字段设置成分区，使用户在查大表的时候达到查小表的成果。在实时数仓中，数据的载体是 Kafka 队列，如果向用户提供一个大流，须要用户在生产数据实时过滤出其中的一小部分数据进行应用，那么对 Kafka 的带宽资源和 Flink 的计算资源都是极大的节约。因而，咱们须要尽量将罕用的维度进行程度拆分构建，例如“挪动端用户行为”“PC 端用户行为”能够拆分到两个流供用户应用。 ...

简介： 实时方面次要是补足咱们对游戏经营的体验，比如说在游戏里玩完一局或者做完一个工作后，立马就能失去相应的处分，或者下一步的玩法指引。对用户来说，这种及时的刺激和干涉，对于他们玩游戏的体验会更好。其实不单单是游戏，其余方面也是一样的，所以咱们在做这套零碎的时候，就是离线+实时联合着用，但次要还是往实时方面去聚拢，将来大数据的方向也是，尽量会往实时方向去走。 大家好我是许振文，明天分享的主题是《基于 Flink+ServiceMesh 的腾讯游戏大数据服务利用实际》，内容次要分为以下四个局部： 背景和解决框架介绍实时大数据计算 OneData数据接口服务 OneFun微服务化& ServiceMesh一、背景和解决框架介绍1、离线数据经营和实时数据经营 首先介绍下背景，咱们做游戏数据经营的工夫是比拟久的了，在 13 年的时候就曾经在做游戏离线数据分析，并且能把数据使用到游戏的经营流动中去。 但那时候的数据有一个缺点，就是大部分都是离线数据，比方明天产生的数据咱们算完后，第二天才会把这个数据推到线上。所以数据的实时性，和对游戏用户的实时干涉、实时经营成果就会十分不好。尤其是比方我明天中的奖，今天能力拿到礼包，这点是玩家很不爽的。 当初提倡的是：“我看到的就是我想要的”或者“我想要的我立马就要”，所以咱们从 16 年开始，整个游戏数据逐步从离线经营转到实时经营，但同时咱们在做的过程中，离线数据必定少不了，因为离线的一些计算、累计值、数据校准都是十分有价值的。 实时方面次要是补足咱们对游戏经营的体验，比如说在游戏里玩完一局或者做完一个工作后，立马就能失去相应的处分，或者下一步的玩法指引。对用户来说，这种及时的刺激和干涉，对于他们玩游戏的体验会更好。 其实不单单是游戏，其余方面也是一样的，所以咱们在做这套零碎的时候，就是离线+实时联合着用，但次要还是往实时方面去聚拢，将来大数据的方向也是，尽量会往实时方向去走。 2、利用场景■ 1）游戏内工作零碎 这个场景给大家介绍一下，是游戏内的工作零碎，大家都应该看过。比方第一个是吃鸡里的，每日实现几局？分享没有？还有其余一些流动都会做简历，但这种简历咱们当初都是实时的，尤其是须要全盘计算或者分享到其余社区里的。以前咱们在做数据经营的时候，都是工作做完回去计算，第二天才会发到处分，而当初所有工作都能够做到实时干涉。 游戏的工作零碎是游戏中特地重要的环节，大家不要认为工作零碎就是让大家实现工作，收大家钱，其实工作零碎给了玩家很好的指引，让玩家在游戏中能够失去更好的游戏体验。 ■ 2）实时排行版 还有一个很重要的利用场景就是游戏内的排行榜，比如说王者光荣里要上星耀、王者，其实都是用排行榜的形式。但咱们这个排行榜可能会更具体一些，比如说是明天的战力排行榜，或者明天的对局排行榜，这些都是全局计算的实时排行榜。而且咱们有快照的性能，比方 0 点 00 分 的时候有一个快照，就能立马给快照里的玩家发处分。 这些是实时计算的典型利用案例，一个工作零碎一个排行榜，其余的咱们前面还会缓缓介绍。 3、游戏对数据的需要 再说一下为什么会有这样一个平台，其实咱们最后在做数据经营的时候，是筒仓式或者手工作坊式的开发。当接到一个需要后，咱们会做一个资源的评审、数据接入、大数据的编码，编码和数据开发完后，还要做线上资源的申请、公布、验证，再去开发大数据计算实现后的服务接口，而后再开发页面和线上的零碎，这些都完了后再发到线下来，做线上监控，最初会有一个资源回收。 其实这种形式在很晚期的时候是没有问题的，那为什么说当初不适应了？次要还是流程太长了。咱们当初对游戏经营的要求十分高，比如说咱们会接入数据挖掘的能力，大数据实时计算实现之后，咱们还要把实时的用户画像，离线画像进行综合，接着举荐给他这个人适宜哪些工作，而后指引去实现。 这种状况下，原来的做法门槛就比拟高了，每一个都要独自去做，而且老本高效率低，在数据的复用性上也比拟差，容易出错，而且没有方法积淀。每一个做完之后代码回收就扔到一块，最多下次做的时候，想起来我有这个代码了能够略微借鉴一下，但这种借鉴基本上也都是一种手工的形式。 所以咱们心愿能有一个平台化的形式，从我的项目的创立、资源分配、服务开发、在线测试、独立部署、服务上线、线上监控、成果剖析、资源回收、我的项目结项整个综合成一站式的服务。 其实这块咱们是借鉴 DevOps 的思路，就是你的开发和经营应该是一个人就能够独立实现的，有这样一个零碎可能去撑持这件事。当一个服务在平台上出现进去的时候，有可能会复用到计算的数据，比说实时的登录次数或击杀数，那这个指标在前面的服务中就能够共用。 而且有了这样一个平台之后，开发者只需次要关注他的开发逻辑就行了，其余两条运维公布和线上经营都由平台来保障。所以咱们心愿有一个平台化的形式，把数据计算和接口服务对立起来，通过数据的标准化和数据字典的对立，可能造成下面不同的数据利用，这个是咱们的第一个指标。 其实咱们当初都是这种形式了，第一是要在 DevOps 的指导思想上来做，尤其是腾讯去做的时候数据服务的量是十分大的，比方咱们去年一共做了 5、6 万的营销服务，在这种状况下如果没有平台撑持，没有平台去治理和治理这些服务，单靠人的话老本十分大。 4、思路3 个现代化，大数据利用的 DevOps。 咱们的思路也是这样，三个现代化，而且把大数据利用的 DevOps 思路实现起来。 规范化：流程标准、数据开发标准和开发框架；自动化：资源分配、公布上线、监控部署（这是 DevOps 里不可短少的）；一体化：数据开发、数据接口开发、测试公布、运维监控。所以咱们针对大数据的利用零碎，会把它拆成这样三块，一个是大数据的开发，另外一个是数据服务接口的开发，当然接口前面就是一些页面和客户端，这些完了后这些开发还要有一个残缺的开发流程反对。 这样咱们就可能为各种数据利用场景提供一站式的数据开发及利用解决服务、对立的流动治理、数据指标计算开发治理和各种数据利用接口自动化生产治理的一站式的服务。 这样的零碎能保障这些的事件，而且咱们这里也正当拆分，不要把大数据和接口混到一块去，肯定要做解耦，这是一个十分要害的中央。 5、数据服务平台整体架构 ■ 1）计算存储这个框架大家能够看一下，我认为能够借鉴，如果你外部要去做一个数据服务平台的话，基本上思路也是这样的，底层的 Iass 能够不必管，间接用腾讯云或者阿里云或者其余云上的服务就能够了。 咱们次要是做下层这一块的货色，最上面的计算存储这个局部咱们外部在做零碎的时候也不是 care 的，这块最好是能承包进来。当初 Iass 倒退到这个水平，这些货色在云上能够间接像 MySQL 数据库或者 Redis 数据库一样购买就行了，比方 Kafka、Pulsar、Flink、Storm。 ...

数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务，数据仓库的建设也是“数据智能”中必不可少的一环。本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容。 1.数据仓库简介数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展。数据仓库的趋势： 实时数据仓库以满足实时化&自动化决策需求；大数据&数据湖以支持大量&复杂数据类型（文本、图像、视频、音频）； 2.数据仓库的发展数据仓库有两个环节：数据仓库的构建与数据仓库的应用。 早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。 随着业务和环境的发展，这两方面都在发生着剧烈变化。 随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求；互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策。比如欺诈检测和用户审核。 总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。 注：这里不讨论数据湖技术。3.数据仓库建设方法论3.1 面向主题从公司业务出发，是分析的宏观领域，比如供应商主题、商品主题、客户主题和仓库主题 3.2 为多维数据分析服务数据报表；数据立方体，上卷、下钻、切片、旋转等分析功能。 3.3 反范式数据模型以事实表和维度表组成的星型数据模型 4.数据仓库架构的演变数据仓库概念是 Inmon 于 1990 年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。 后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是 Lambda 架构。 再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的 Kappa 架构。 4.1 离线大数据架构数据源通过离线的方式导入到离线数仓中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层： ODS，操作数据层，保存原始数据；DWD，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；DM，数据集市/轻度汇总层，在 DWD 层的基础之上根据不同的业务需求做轻度汇总；典型的数仓存储是 HDFS/Hive，ETL 可以是 MapReduce 脚本或 HiveSQL。 4.2 Lambda 架构随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。 注：流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果。（这仅仅是流处理引擎不完善做的折中）Lambda 架构问题： 同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分 4.3 Kappa 架构Lambda 架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着 Flink 等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的 Jay Kreps 提出了 Kappa 架构。 ...

本文根据 Apache Flink 系列直播课程整理而成，由 Apache Flink PMC，阿里巴巴高级技术专家 孙金城 分享。重点为大家介绍 Flink Python API 的现状及未来规划，主要内容包括：Apache Flink Python API 的前世今生和未来发展；Apache Flink Python API 架构及开发环境搭建；Apache Flink Python API 核心算子介绍及应用。 一.Apache Flink Python API 的前世今生和未来发展1.Flink 为什么选择支持 PythonApache Flink 是流批统一的开源大数据计算引擎，在 Flink 1.9.0 版本开启了新的 ML 接口和全新的Python API架构。那么为什么 Flink 要增加对 Python 的支持，下文将进行详细分析。 最流行的开发语言 Python 本身是非常优秀的开发语言，据 RedMonk 数据统计，除 Java 和 JavaScript 之外，受欢迎度排名第三。 RedMonk 是著名的以开发人员为中心的行业分析公司，其更详细的分析信息，大家在拿到我的PPT之后，可以点击链接进行详细查阅。好了，那么Python的火热，与我们今天向大家分享的流批统一的大数据计算引擎，Apache Flink有什么关系呢？带着这个问题，我们大家想想目前与大数据相关的著名的开源组件有哪些呢？比如说最早期的批处理框架Hadoop？流计算平台Storm，最近异常火热的Spark？异或其他领域数仓的Hive，KV存储的HBase？这些都是非常著名的开源项目，那么这些项目都无一例外的进行了Python API的支持。 众多开源项目支持 Python 的生态已相对完善，基于此，Apache Flink 在 1.9 版本中也投入了大量的精力,去推出了一个全新的 Pyflink。除大数据外，人工智能与Python也有十分密切的关系。 ML青睐的语言 ...

2018 年 12 月，Apache Flink Community China 成功举办了国内首届 Flink Forward China，并在诸多合作伙伴的帮助下成功将其打造为规模最大、参与人数最多的 Flink Forward 大会。 今年，Apache Flink 年度最高规格的盛会即将再次拉开帷幕！Flink Forward China 已正式升级为 Flink Forward Asia，并计划于 11 月底举办，规模将逾2000 人。 参与调研送周边为进一步提高会议质量，让 Apache Flink 社区与开发者更近距离地接触，我们诚挚地邀请您参与会前调研，想听什么议题，想见哪位大佬，想要什么礼品，由你决定！福利活动奉上： 点击文末链接，推荐您的小伙伴填写问卷，并在问卷底部的「问卷推荐人」一栏中正确填入您的姓名，可获取相应周边奖励：1. 推荐1-4人填写：Apache Flink 社区限量版专刊 S2 实体书籍2. 推荐5-10人填写：Apache Flink 社区定制马克杯3. 推荐10人以上填写：Apache Flink 社区定制T恤本次问卷调研福利我们首次送出最新定制的 Apache Flink 社区 T 恤、人气最高的社区定制马克杯以及限量纸质版 Apache Flink 第二季专刊《重新定义计算：Apache Flink 实践》。 社区周边展示Apache Flink 社区周边大饱眼福时间到，看看你最想要哪一款！ Apache Flink 定制版T恤，小姐姐同款，Meetup 来撞衫！ 用 Apache Flink 旗舰款马克杯，喝水都会更开心！ ...

7 月 6 日，Apache Flink Meetup X Apache RocketMQ · 上海站，来自阿里巴巴、网易的 Flink 技术专家与 Apache RocketMQ 社区大咖一起分享关于 Flink、RocketMQ 的应用实践与前沿技术。 ▼ PPT 下载 ▼ Apache Flink Meetup X Apache RocketMQ · 上海站，嘉宾分享的PPT下载请在后台回复关键字“0706PPT”领取。 《网易云音乐消息队列改造之路与 Apache Flink 应用实践》 林德智 | 网易云音乐 消息队列负责人 岳猛 | Apache Flink Contributor，网易云音乐 实时计算平台研发工程师 本次分享主要介绍了网易云音乐消息队列基于 RocketMQ 的应用以及在消息队列的基础上深度融合的 Flink 流式处理引擎为云音乐提供的实时计算解决方案，分享了在直播，广告，曲库，内容等取得的应用效果。 云音乐消息队列的历史基于 RocketMQ 改造消息队列部分高级特性与 bug 修复RocketMQ 与 Flink 结合应用实践《万亿级消息及流处理引擎 - Apache RocketMQ 的现在和未来》 ...

作者 | 贺飞 公司介绍：有赞是一个商家服务公司，提供全行业全场景的电商解决方案。在有赞，大量的业务场景依赖对实时数据的处理，作为一类基础技术组件，服务着有赞内部几十个业务产品，几百个实时计算任务，其中包括交易数据大屏，商品实时统计分析，日志平台，调用链，风控等多个业务场景，本文将介绍有赞实时计算当前的发展历程和当前的实时计算技术架构。 1.实时计算在有赞发展从技术栈的角度，我们的选择和大多数互联网公司一致，从早期的 Storm，到 JStorm， Spark Streaming 和最近兴起的 Flink。从发展阶段来说，主要经历了两个阶段，起步阶段和平台化阶段；下面将按照下图中的时间线，介绍实时计算在有赞的发展历程。 1.1 起步阶段这里的的起步阶段的基本特征是，缺少整体的实时计算规划，缺乏平台化任务管理，监控，报警工具，用户提交任务直接通过登录 AG 服务器使用命令行命令提交任务到线上集群，很难满足用户对可用性的要求。但是，在起步阶段里积累了内部大量的实时计算场景。 1.1.1 Storm 登场2014 年初，第一个 Storm 应用在有赞内部开始使用，最初的场景是把实时事件的统计从业务逻辑中解耦出来，Storm 应用通过监听 MySQL 的 binlog 更新事件做实时计算，然后将结果更新到 MySQL 或者 Redis 缓存上，供在线系统使用。类似的场景得到了业务开发的认可，逐渐开始支撑起大量的业务场景。早期，用户通过登录一组线上环境的 AG 服务器，通过 Storm 的客户端向 Storm 集群做提交任务等操作， 这样在 2 年多的时间里，Storm 组件积累了近百个实时应用。Storm 也同样暴露出很多问题，主要体现在系统吞吐上，对吞吐量巨大，但是对延迟不敏感的场景，显得力不从心。 1.1.2 引入 Spark Streaming2016 年末，随着 Spark 技术栈的日益成熟，又因为 Storm 引擎本身在吞吐 / 性能上跟 Spark Streaming 技术栈相比有明显劣势，所以从那时候开始，部分业务团队开始尝试新的流式计算引擎。因为有赞离线计算有大量 Spark 任务的使用经验，Spark Streaming 很自然的成为了第一选择，随着前期业务日志系统和埋点日志系统的实时应用的接入，大量业务方也开始逐渐接入。同 Storm 一样，业务方完成实时计算应任务开发后，通过一组 AG 服务器，使用 Spark 客户端，向大数据 Yarn 集群提交任务。 ...

6 月 30 日，阿里云实时计算专场北京站，由来自格灵深瞳的大数据总监与阿里巴巴产品专家、技术专家一起与大家探讨实时计算的应用实践与场景化解决方案。 实时计算是基于 Apache Flink 构建的一站式高性能实时大数据处理平台，在 PB 级别的数据集上可以支持亚秒级别的处理延时，赋能用户标准实时数据处理流程和行业解决方案。2019 年 6 月阿里云实时计算通过数据中心联盟最新制定的大数据分布式流处理平台基础能力评测，成为国内首批通过流计算产品能力评测的产品。 ▼ PPT 下载 ▼ 阿里云实时计算专场北京站，四位嘉宾分享的PPT下载请在后台回复关键字“0630PPT”领取。 《Flink在人脸识别实时业务中的应用》 陈新宇 | 格灵深瞳 大数据总监 Flink 作为下一代流计算引擎，以其高效、低延迟等特性获得了大量关注与应用。格灵深瞳自2017年开始就将 Flink 应用在生产之中，为客户提供基于人脸识别的实时数据分析服务及面向不同行业的整体解决方案，本次分享介绍了 Flink 在格灵深瞳人脸识别实时业务场景中的技术选型原因、具体应用、遇到的一些问题及改进。 背景及现状应⽤用及⽅方案问题与优化后续与局限《实时计算场景化解决方案》 高旸 | 阿里巴巴 高级产品专家 主要内容是介绍实时计算产品商业架构及技术架构，对比其他商业化流计算产品及开源软件，实时计算的产品优势，产品典型的应用场景划分，在数字媒体、在线教育、新零售以及城市大脑中的应用场景介绍及相应的解决方案分享。 实时计算产品形态产品架构 / 定位 / Unified SQL / Unified Runtime阿里云实时计算被集成方案轻量化 PaaS 解决方案实时计算典型场景演进路线典型场景 《如何构建基于 Flink on Kubernetes 的大数据平台》 任春德 | 阿里巴巴 高级技术专家 本次分享从大数据领域，初露头角的 Kubernetes 如何 PK 日臻完善的基于 Yarn 调度的平台、新一代的批流一体的大数据处理引擎 Flink 与 Kubernetes 结合形成的新平台有哪些优势、如何将其构建成一套易运维、高可用、高利用率的平台等三部分内容进行分享。 ...

6月29日，Apache Flink Meetup 北京站圆满落幕，Apache Flink 1.9 版本是自 Flink 1.0 之后变化最大的版本，社区对 Flink 进行大量重构并且加入了很多新 Feature。此次 Meetup 重点解读 Flink 1.9 版本新特性。 ▼ PPT下载 ▼关注Apache Flink 社区公众号Ververica，回复关键字“0629PPT”即可下载Apache Flink Meetup 北京站全部嘉宾分享的PPT. 本期 Meetup 由 Apache Flink PMC 与 Committer 开场，对 Flink 1.9 版本新特性进行全面分享；阿里巴巴技术专家从 Table API 和算法层面分享 Flink 的机器学习生态；还有 Flink on Kubernetes 、Flink 1.9 版本与 Hive 的兼容性解读，以及超过千台集群、日处理条目超过 264 亿条，处理峰值超过 3.6 千万条 / s 的 Flink 在快手的应用实践。 《Apache Flink 1.9 特性解读》 ...

作者：陈守元、戴资力 一、Apache Flink 的定义、架构及原理Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态或无状态的计算，能够部署在各种集群环境，对各种规模大小的数据进行快速计算。 1. Flink Application了解 Flink 应用开发需要先理解 Flink 的 Streams、State、Time 等基础处理语义以及 Flink 兼顾灵活性和方便性的多层次 API。 Streams：流，分为有限数据流与无限数据流，unbounded stream 是有始无终的数据流，即无限数据流；而 bounded stream 是限定大小的有始有终的数据集合，即有限数据流，二者的区别在于无限数据流的数据会随时间的推演而持续增加，计算持续进行且不存在结束的状态，相对的有限数据流数据大小固定，计算最终会完成并处于结束的状态。State，状态是计算过程中的数据信息，在容错恢复和 Checkpoint 中有重要的作用，流计算在本质上是 Incremental Processing，因此需要不断查询保持状态；另外，为了确保 Exactly- once 语义，需要数据能够写入到状态中；而持久化存储，能够保证在整个分布式系统运行失败或者挂掉的情况下做到 Exactly- once，这是状态的另外一个价值。Time，分为 Event time、Ingestion time、Processing time，Flink 的无限数据流是一个持续的过程，时间是我们判断业务状态是否滞后，数据处理是否及时的重要依据。API，API 通常分为三层，由上而下可分为 SQL / Table API、DataStream API、ProcessFunction 三层，API 的表达能力及业务抽象能力都非常强大，但越接近 SQL 层，表达能力会逐步减弱，抽象能力会增强，反之，ProcessFunction 层 API 的表达能力非常强，可以进行多种灵活方便的操作，但抽象能力也相对越小。2.Flink Architecture在架构部分，主要分为以下四点： 第一， Flink 具备统一的框架处理有界和无界两种数据流的能力 第二， 部署灵活，Flink 底层支持多种资源调度器，包括 Yarn、Kubernetes 等。Flink 自身带的 Standalone 的调度器，在部署上也十分灵活。 第三， 极高的可伸缩性，可伸缩性对于分布式系统十分重要，阿里巴巴双11大屏采用 Flink 处理海量数据，使用过程中测得 Flink 峰值可达 17 亿/秒。 ...

作者 | 知乎数据工程团队 “数据智能” (Data Intelligence) 有一个必须且基础的环节，就是数据仓库的建设，同时，数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务。从智能商业的角度来讲，数据的结果代表了用户的反馈，获取结果的及时性就显得尤为重要，快速的获取数据反馈能够帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可替代的作用。 本文主要讲述知乎的实时数仓实践以及架构的演进，这包括以下几个方面： 实时数仓 1.0 版本，主题：ETL 逻辑实时化，技术方案：Spark Streaming。实时数仓 2.0 版本，主题：数据分层，指标计算实时化，技术方案：Flink Streaming。实时数仓未来展望：Streaming SQL 平台化，元信息管理系统化，结果验收自动化。实时数仓 1.0 版本1.0 版本的实时数仓主要是对流量数据做实时 ETL，并不计算实时指标，也未建立起实时数仓体系，实时场景比较单一，对实时数据流的处理主要是为了提升数据平台的服务能力。实时数据的处理向上依赖数据的收集，向下关系到数据的查询和可视化，下图是实时数仓 1.0 版本的整体数据架构图。 第一部分是数据采集，由三端 SDK 采集数据并通过 Log Collector Server 发送到 Kafka。第二部分是数据 ETL，主要完成对原始数据的清洗和加工并分实时和离线导入 Druid。第三部分是数据可视化，由 Druid 负责计算指标并通过 Web Server 配合前端完成数据可视化。 其中第一、三部分的相关内容请分别参考：知乎客户端埋点流程、模型和平台技术，Druid 与知乎数据分析平台，此处我们详细介绍第二部分。由于实时数据流的稳定性不如离线数据流，当实时流出现问题后需要离线数据重刷历史数据，因此实时处理部分我们采用了 lambda 架构。 Lambda 架构有高容错、低延时和可扩展的特点，为了实现这一设计，我们将 ETL 工作分为两部分：Streaming ETL 和 Batch ETL。 Streaming ETL这一部分我会介绍实时计算框架的选择、数据正确性的保证、以及 Streaming 中一些通用的 ETL 逻辑，最后还会介绍 Spark Streaming 在实时 ETL 中的稳定性实践。 计算框架选择在 2016 年年初，业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架，Spark Streaming 用 Micro Batch 模拟流式计算，前者比后者更实时，后者比前者吞吐量大且生态系统更完善，考虑到知乎的日志量以及初期对实时性的要求，我们选择了 Spark Streaming 作为实时数据的处理框架。 ...

作者 | 知乎数据工程团队 “数据智能” (Data Intelligence) 有一个必须且基础的环节，就是数据仓库的建设，同时，数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务。从智能商业的角度来讲，数据的结果代表了用户的反馈，获取结果的及时性就显得尤为重要，快速的获取数据反馈能够帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可替代的作用。 本文主要讲述知乎的实时数仓实践以及架构的演进，这包括以下几个方面： 实时数仓 1.0 版本，主题：ETL 逻辑实时化，技术方案：Spark Streaming。实时数仓 2.0 版本，主题：数据分层，指标计算实时化，技术方案：Flink Streaming。实时数仓未来展望：Streaming SQL 平台化，元信息管理系统化，结果验收自动化。实时数仓 1.0 版本1.0 版本的实时数仓主要是对流量数据做实时 ETL，并不计算实时指标，也未建立起实时数仓体系，实时场景比较单一，对实时数据流的处理主要是为了提升数据平台的服务能力。实时数据的处理向上依赖数据的收集，向下关系到数据的查询和可视化，下图是实时数仓 1.0 版本的整体数据架构图。 第一部分是数据采集，由三端 SDK 采集数据并通过 Log Collector Server 发送到 Kafka。第二部分是数据 ETL，主要完成对原始数据的清洗和加工并分实时和离线导入 Druid。第三部分是数据可视化，由 Druid 负责计算指标并通过 Web Server 配合前端完成数据可视化。 其中第一、三部分的相关内容请分别参考：知乎客户端埋点流程、模型和平台技术，Druid 与知乎数据分析平台，此处我们详细介绍第二部分。由于实时数据流的稳定性不如离线数据流，当实时流出现问题后需要离线数据重刷历史数据，因此实时处理部分我们采用了 lambda 架构。 Lambda 架构有高容错、低延时和可扩展的特点，为了实现这一设计，我们将 ETL 工作分为两部分：Streaming ETL 和 Batch ETL。 Streaming ETL这一部分我会介绍实时计算框架的选择、数据正确性的保证、以及 Streaming 中一些通用的 ETL 逻辑，最后还会介绍 Spark Streaming 在实时 ETL 中的稳定性实践。 计算框架选择在 2016 年年初，业界用的比较多的实时计算框架有 Storm 和 Spark Streaming。Storm 是纯流式框架，Spark Streaming 用 Micro Batch 模拟流式计算，前者比后者更实时，后者比前者吞吐量大且生态系统更完善，考虑到知乎的日志量以及初期对实时性的要求，我们选择了 Spark Streaming 作为实时数据的处理框架。 ...

作者：Nico Kruber 翻译：曹英杰 Flink 的网络协议栈是组成 flink-runtime 模块的核心组件之一，是每个 Flink 作业的核心。它连接所有 TaskManager 的各个子任务(Subtask)，因此，对于 Flink 作业的性能包括吞吐与延迟都至关重要。与 TaskManager 和 JobManager 之间通过基于 Akka 的 RPC 通信的控制通道不同，TaskManager 之间的网络协议栈依赖于更加底层的 Netty API。 本文将首先介绍 Flink 暴露给流算子(Stream operator)的高层抽象，然后详细介绍 Flink 网络协议栈的物理实现和各种优化、优化的效果以及 Flink 在吞吐量和延迟之间的权衡。 1.逻辑视图Flink 的网络协议栈为彼此通信的子任务提供以下逻辑视图，例如在 A 通过 keyBy() 操作进行数据 Shuffle ： 这一过程建立在以下三种基本概念的基础上： ▼ 子任务输出类型（ResultPartitionType）：Pipelined（有限的或无限的）：一旦产生数据就可以持续向下游发送有限数据流或无限数据流。Blocking：仅在生成完整结果后向下游发送数据。 ▼ 调度策略：同时调度所有任务(Eager)：同时部署作业的所有子任务（用于流作业）。上游产生第一条记录部署下游(Lazy)：一旦任何生产者生成任何输出，就立即部署下游任务。上游产生完整数据部署下游：当任何或所有生产者生成完整数据后，部署下游任务。 ▼ 数据传输：高吞吐：Flink 不是一个一个地发送每条记录，而是将若干记录缓冲到其网络缓冲区中并一次性发送它们。这降低了每条记录的发送成本因此提高了吞吐量。低延迟：当网络缓冲区超过一定的时间未被填满时会触发超时发送，通过减小超时时间，可以通过牺牲一定的吞吐来获取更低的延迟。 我们将在下面深入 Flink 网络协议栈的物理实现时看到关于吞吐延迟的优化。对于这一部分，让我们详细说明输出类型与调度策略。首先，需要知道的是子任务的输出类型和调度策略是紧密关联的，只有两者的一些特定组合才是有效的。 Pipelined 结果是流式输出，需要目标 Subtask 正在运行以便接收数据。因此需要在上游 Task 产生数据之前或者产生第一条数据的时候调度下游目标 Task 运行。批处理作业生成有界结果数据，而流式处理作业产生无限结果数据。 批处理作业也可能以阻塞方式产生结果，具体取决于所使用的算子和连接模式。在这种情况下，必须等待上游 Task 先生成完整的结果，然后才能调度下游的接收 Task 运行。这能够提高批处理作业的效率并且占用更少的资源。 下表总结了 Task 输出类型以及调度策略的有效组合： ...

文章目录：Apache Flink 应用程序中的 Exactly-Once 语义Flink 应用程序端到端的 Exactly-Once 语义示例 Flink 应用程序启动预提交阶段在 Flink 中实现两阶段提交 Operator总结Apache Flink 自2017年12月发布的1.4.0版本开始，为流计算引入了一个重要的里程碑特性：TwoPhaseCommitSinkFunction（相关的Jira）。它提取了两阶段提交协议的通用逻辑，使得通过Flink来构建端到端的Exactly-Once程序成为可能。同时支持一些数据源（source）和输出端（sink），包括Apache Kafka 0.11及更高版本。它提供了一个抽象层，用户只需要实现少数方法就能实现端到端的Exactly-Once语义。 有关TwoPhaseCommitSinkFunction的使用详见文档: TwoPhaseCommitSinkFunction。或者可以直接阅读Kafka 0.11 sink的文档: kafka。 接下来会详细分析这个新功能以及Flink的实现逻辑，分为如下几点。 描述Flink checkpoint机制是如何保证Flink程序结果的Exactly-Once的显示Flink如何通过两阶段提交协议与数据源和数据输出端交互，以提供端到端的Exactly-Once保证通过一个简单的示例，了解如何使用TwoPhaseCommitSinkFunction实现Exactly-Once的文件输出一、Apache Flink应用程序中的Exactly-Once语义当我们说『Exactly-Once』时，指的是每个输入的事件只影响最终结果一次。即使机器或软件出现故障，既没有重复数据，也不会丢数据。 Flink很久之前就提供了Exactly-Once语义。在过去几年中，我们对Flink的checkpoint机制有过深入的描述，这是Flink有能力提供Exactly-Once语义的核心。Flink文档还提供了该功能的全面概述。 在继续之前，先看下对checkpoint机制的简要介绍，这对理解后面的主题至关重要。 次checkpoint是以下内容的一致性快照：应用程序的当前状态输入流的位置Flink可以配置一个固定的时间点，定期产生checkpoint，将checkpoint的数据写入持久存储系统，例如S3或HDFS。将checkpoint数据写入持久存储是异步发生的，这意味着Flink应用程序在checkpoint过程中可以继续处理数据。 如果发生机器或软件故障，重新启动后，Flink应用程序将从最新的checkpoint点恢复处理； Flink会恢复应用程序状态，将输入流回滚到上次checkpoint保存的位置，然后重新开始运行。这意味着Flink可以像从未发生过故障一样计算结果。 在Flink 1.4.0之前，Exactly-Once语义仅限于Flink应用程序内部，并没有扩展到Flink数据处理完后发送的大多数外部系统。Flink应用程序与各种数据输出端进行交互，开发人员需要有能力自己维护组件的上下文来保证Exactly-Once语义。 为了提供端到端的Exactly-Once语义 – 也就是说，除了Flink应用程序内部，Flink写入的外部系统也需要能满足Exactly-Once语义 – 这些外部系统必须提供提交或回滚的方法，然后通过Flink的checkpoint机制来协调。 分布式系统中，协调提交和回滚的常用方法是两阶段提交协议。在下一节中，我们将讨论Flink的TwoPhaseCommitSinkFunction是如何利用两阶段提交协议来提供端到端的Exactly-Once语义。 二、Flink应用程序端到端的Exactly-Once语义我们将介绍两阶段提交协议，以及它如何在一个读写Kafka的Flink程序中实现端到端的Exactly-Once语义。Kafka是一个流行的消息中间件，经常与Flink一起使用。Kafka在最近的0.11版本中添加了对事务的支持。这意味着现在通过Flink读写Kafaka，并提供端到端的Exactly-Once语义有了必要的支持。 Flink对端到端的Exactly-Once语义的支持不仅局限于Kafka，您可以将它与任何一个提供了必要的协调机制的源/输出端一起使用。例如Pravega，来自DELL/EMC的开源流媒体存储系统，通过Flink的TwoPhaseCommitSinkFunction也能支持端到端的Exactly-Once语义。 在今天讨论的这个示例程序中，我们有： 从Kafka读取的数据源（Flink内置的KafkaConsumer）窗口聚合将数据写回Kafka的数据输出端（Flink内置的KafkaProducer）要使数据输出端提供Exactly-Once保证，它必须将所有数据通过一个事务提交给Kafka。提交捆绑了两个checkpoint之间的所有要写入的数据。这可确保在发生故障时能回滚写入的数据。但是在分布式系统中，通常会有多个并发运行的写入任务的，简单的提交或回滚是不够的，因为所有组件必须在提交或回滚时“一致”才能确保一致的结果。Flink使用两阶段提交协议及预提交阶段来解决这个问题。 在checkpoint开始的时候，即两阶段提交协议的“预提交”阶段。当checkpoint开始时，Flink的JobManager会将checkpoint barrier（将数据流中的记录分为进入当前checkpoint与进入下一个checkpoint）注入数据流。 brarrier在operator之间传递。对于每一个operator，它触发operator的状态快照写入到state backend。 数据源保存了消费Kafka的偏移量(offset)，之后将checkpoint barrier传递给下一个operator。 这种方式仅适用于operator具有『内部』状态。所谓内部状态，是指Flink state backend保存和管理的 -例如，第二个operator中window聚合算出来的sum值。当一个进程有它的内部状态的时候，除了在checkpoint之前需要将数据变更写入到state backend，不需要在预提交阶段执行任何其他操作。Flink负责在checkpoint成功的情况下正确提交这些写入，或者在出现故障时中止这些写入。 三、示例Flink应用程序启动预提交阶段但是，当进程具有『外部』状态时，需要作些额外的处理。外部状态通常以写入外部系统（如Kafka）的形式出现。在这种情况下，为了提供Exactly-Once保证，外部系统必须支持事务，这样才能和两阶段提交协议集成。 在本文示例中的数据需要写入Kafka，因此数据输出端（Data Sink）有外部状态。在这种情况下，在预提交阶段，除了将其状态写入state backend之外，数据输出端还必须预先提交其外部事务。 当checkpoint barrier在所有operator都传递了一遍，并且触发的checkpoint回调成功完成时，预提交阶段就结束了。所有触发的状态快照都被视为该checkpoint的一部分。checkpoint是整个应用程序状态的快照，包括预先提交的外部状态。如果发生故障，我们可以回滚到上次成功完成快照的时间点。 下一步是通知所有operator，checkpoint已经成功了。这是两阶段提交协议的提交阶段，JobManager为应用程序中的每个operator发出checkpoint已完成的回调。 数据源和 widnow operator没有外部状态，因此在提交阶段，这些operator不必执行任何操作。但是，数据输出端（Data Sink）拥有外部状态，此时应该提交外部事务。 ...

在上一篇入门教程中，我们已经能够快速构建一个基础的 Flink 程序了。本文会一步步地带领你实现一个更复杂的 Flink 应用程序：实时热门商品。在开始本文前我们建议你先实践一遍上篇文章，因为本文会沿用上文的my-flink-project项目框架。 通过本文你将学到： 如何基于 EventTime 处理，如何指定 Watermark如何使用 Flink 灵活的 Window API何时需要用到 State，以及如何使用如何使用 ProcessFunction 实现 TopN 功能实战案例介绍“实时热门商品”的需求，我们可以将“实时热门商品”翻译成程序员更好理解的需求：每隔5分钟输出最近一小时内点击量最多的前 N 个商品。将这个需求进行分解我们大概要做这么几件事情： 抽取出业务时间戳，告诉 Flink 框架基于业务时间做窗口过滤出点击行为数据按一小时的窗口大小，每5分钟统计一次，做滑动窗口聚合（Sliding Window）按每个窗口聚合，输出每个窗口中点击量前N名的商品数据准备这里我们准备了一份淘宝用户行为数据集（来自阿里云天池公开数据集，特别感谢）。本数据集包含了淘宝上某一天随机一百万用户的所有行为（包括点击、购买、加购、收藏）。数据集的组织形式和MovieLens-20M类似，即数据集的每一行表示一条用户行为，由用户ID、商品ID、商品类目ID、行为类型和时间戳组成，并以逗号分隔。关于数据集中每一列的详细描述如下： 列名称说明用户ID整数类型，加密后的用户ID商品ID整数类型，加密后的商品ID商品类目ID整数类型，加密后的商品所属类目ID行为类型字符串，枚举类型，包括(‘pv’, ‘buy’, ‘cart’, ‘fav’)时间戳行为发生的时间戳，单位秒你可以通过下面的命令下载数据集到项目的 resources 目录下： $ cd my-flink-project/src/main/resources$ curl https://raw.githubusercontent.com/wuchong/my-flink-project/master/src/main/resources/UserBehavior.csv > UserBehavior.csv这里是否使用 curl 命令下载数据并不重要，你也可以使用 wget 命令或者直接访问链接下载数据。关键是，将数据文件保存到项目的 resources 目录下，方便应用程序访问。 编写程序在 src/main/java/myflink 下创建 HotItems.java 文件： package myflink;public class HotItems { public static void main(String[] args) throws Exception { }}与上文一样，我们会一步步往里面填充代码。第一步仍然是创建一个 StreamExecutionEnvironment，我们把它添加到 main 函数中。 ...

本文转载自 Jark’s Blog ，作者伍翀（云邪），Apache Flink Committer，阿里巴巴高级开发工程师。本文将从开发环境准备、创建 Maven 项目，编写 Flink 程序、运行程序等方面讲述如何迅速搭建第一个 Flink 应用。在本文中，我们将从零开始，教您如何构建第一个 Flink 应用程序。开发环境准备Flink 可以运行在 Linux, Max OS X, 或者是 Windows 上。为了开发 Flink 应用程序，在本地机器上需要有 Java 8.x 和 maven 环境。 如果有 Java 8 环境，运行下面的命令会输出如下版本信息： $ java -versionjava version "1.8.0_65"Java(TM) SE Runtime Environment (build 1.8.0_65-b17)Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)如果有 maven 环境，运行下面的命令会输出如下版本信息：$ mvn -versionApache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)Maven home: /Users/wuchong/dev/mavenJava version: 1.8.0_65, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jreDefault locale: zh_CN, platform encoding: UTF-8OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"另外我们推荐使用 ItelliJ IDEA （社区免费版已够用）作为 Flink 应用程序的开发 IDE。Eclipse 虽然也可以，但是 Eclipse 在 Scala 和 Java 混合型项目下会有些已知问题，所以不太推荐 Eclipse。下一章节，我们会介绍如何创建一个 Flink 工程并将其导入 ItelliJ IDEA。创建 Maven 项目我们将使用 Flink Maven Archetype 来创建我们的项目结构和一些初始的默认依赖。在你的工作目录下，运行如下命令来创建项目： ...

作者：晨笙、缘桥菜鸟供应链业务链路长、节点多、实体多，使得技术团队在建设供应链实时数仓的过程中，面临着诸多挑战，如：如何实现实时变Key统计？如何实现实时超时统计？如何进行有效地资源优化？如何提升多实时流关联效率？如何提升实时作业的开发效率？ 而 Blink 能否解决这些问题？下面一起来深入了解。背景菜鸟从2017年4月开始探索 Blink（即 Apache Flink 的阿里内部版本），2017年7月开始在线上环境使用 Blink，作为我们的主流实时计算引擎。 为什么短短几个月的探索之后，我们就选择Blink作为我们主要的实时计算引擎呢？ 在效率上，Blink 提供 DataStream、TableAPI、SQL 三种开发模式，强大的 SQL 模式已经满足大部分业务场景，配合半智能资源优化、智能倾斜优化、智能作业压测等功能，可以极大地提升实时作业的开发效率；在性能上，诸如MiniBatch&MicroBatch、维表 Async&Cache、利用 Niagara 进行本地状态管理等内部优化方案，可以极大地提升实时作业的性能；在保障上，Blink 自带的 Failover 恢复机制，能够实现线程级的恢复，可以做到分钟级恢复，配合 Kmonitor 监控平台、烽火台预警平台，可以有效地实现实时作业的数据保障。 接下来，我将结合供应链业务的一些业务场景，简要说明，Blink 如何解决我们遇到的一些实际问题。 回撤机制订单履行是供应链业务中最常见的物流场景。什么是订单履行呢？当商家 ERP 推单给菜鸟之后，菜鸟履行系统会实时计算出每笔订单的出库、揽收、签收等节点的预计时间，配送公司需要按照各节点的预计时间进行订单的配送。为了保证订单的准点履约，我们经常需要统计每家配送公司每天各个节点的预计单量，便于配送公司提前准备产能。 看似很简单的实时统计加工，我们在开发过程中遇到了什么问题呢？履行重算！当物流订单的上游某个节点延迟时，履行系统会自动重算该笔订单下游所有节点的预计时间。比如某个物流订单出库晚点后，其后的预计揽收时间、预计签收时间都会重算。而对于大部分的实时计算引擎来说，并不能很友好的支持这种变 Key 统计的问题。以前，数据量没那么大的时候，还可以通过 OLAP 数据库来解决这类场景，当量上来后， OLAP 方案的成本、性能都是很大的问题。 除了 OLAP 方案，我们提倡采用 Blink 已经内置的 Retraction 机制，来解决这类变 Key 统计的问题，这也是我们在2017年初就开始尝试 Blink 的重要原因。Blink 的Retraction 机制，使用 State 在内存或者外部存储设备中对数据进行统计处理，当上游数据源对某些汇总 Key 的数据做更新时，Blink 会主动给下游下发一个删除消息从而“撤回”之前的那条消息，并用最新下发的消息对表做更新操作。Retraction的实现细节，可以参见：Retraction for Flink Streaming。 下面是一个简化后的案例，供了解Blink Retraction的内部计算过程： 对于上述案例，可以通过 Blink 提供的强大的、灵活的、简易的 SQL 开发模式来实现，只需要几行 SQL 即可完成。 ...

随着数据量的爆发，AI走上风口，典型的大数据业务场景下数据业务最通用的做法是：选用批计算的技术处理全量数据，采用流计算的技术处理实时增量数据。在生产环境中，用户通常采用批处理和流处理两套计算引擎来支持这两种场景。弊端就是需要写两套代码，维护两套引擎，毫无疑问，这种架构带来了额外的负担与成本。 面对全量数据和增量数据，能否用一套统一的大数据引擎技术来处理？ Apache Flink 被业界公认为最好的流计算引擎，其计算能力不仅仅局限于做流处理，而是一套兼具流、批、机器学习等多种计算功能的大数据引擎，用户只需根据业务逻辑开发一套代码，无论是全量数据还是增量数据，亦或者实时处理，一套方案即可全部支持。为了让大家更全面地了解 Apache Flink 背后的技术以及应用实践，今天，我们首次免费公开 Apache Flink 系列视频课程。 为什么要收藏 Apache Flink 系列课程？2018年市场调查报告显示 Apache Flink 是2018年开源大数据生态中发展“最快”的引擎，相较于2017年增长了125% 。Flink 的社区生态在不断发展壮大，在中国，越来越多的互联网公司在生产环境中采用Flink解决实时计算、流计算、风控等问题，因而，学习 Flink 迫在眉睫。 此次免费公开课共分为9个课时，课程内容包含 Flink 的基础架构、应用场景、集群部署、运行机制、编程范式，为你系统地拆分讲解大数据计算开发引擎Flink。 1.1 为什么要学习 Apache Flink？ 关键词：Flink 的重要性 课程开篇由阿里巴巴高级产品专家，实时计算产品团队负责人陈守元（巴真）开讲，从开设Apache Flink 系列课程的初衷、Apache Flink 的定义/架构/原理以及学前准备与学习方法与你分享如何高效学习 Flink 系列课程。 1.2 Flink 基本概念 关键词：Apache Flink PMC、有状态的流式处理 本节课程由 Apache Flink PMC、Ververica Software Engineer 戴资力与你探讨 Flink 作为有状态的流式处理引擎的核心概念应当如何理解，Flink 与其他大数据引擎的区别是什么？为什么要使用 Flink 以及有状态的流式处理引擎面临哪些挑战？ 1.3 Flink 安装部署、环境配置及运行应用程序 关键词：开发 Flink 必经第一课 破解“知易行难”的方法是实战，第三节内容由阿里巴巴高级开发工程师沙晟阳带你从Flink开发环境的部署、配置、运行，以及不同模式的应用场景入手，示范如何快速正确安装应用Flink，并为你提供了实际应用中可能出现的问题与相应的解决方案。 1.4 DataStream API 编程 ...

文章目录：Apache Flink 应用程序中的 Exactly-Once 语义Flink 应用程序端到端的 Exactly-Once 语义示例 Flink 应用程序启动预提交阶段在 Flink 中实现两阶段提交 Operator总结Apache Flink 自2017年12月发布的1.4.0版本开始，为流计算引入了一个重要的里程碑特性：TwoPhaseCommitSinkFunction（相关的Jira）。它提取了两阶段提交协议的通用逻辑，使得通过Flink来构建端到端的Exactly-Once程序成为可能。同时支持一些数据源（source）和输出端（sink），包括Apache Kafka 0.11及更高版本。它提供了一个抽象层，用户只需要实现少数方法就能实现端到端的Exactly-Once语义。 有关TwoPhaseCommitSinkFunction的使用详见文档: TwoPhaseCommitSinkFunction。或者可以直接阅读Kafka 0.11 sink的文档: kafka。 接下来会详细分析这个新功能以及Flink的实现逻辑，分为如下几点。 描述Flink checkpoint机制是如何保证Flink程序结果的Exactly-Once的显示Flink如何通过两阶段提交协议与数据源和数据输出端交互，以提供端到端的Exactly-Once保证通过一个简单的示例，了解如何使用TwoPhaseCommitSinkFunction实现Exactly-Once的文件输出一、Apache Flink应用程序中的Exactly-Once语义当我们说『Exactly-Once』时，指的是每个输入的事件只影响最终结果一次。即使机器或软件出现故障，既没有重复数据，也不会丢数据。 Flink很久之前就提供了Exactly-Once语义。在过去几年中，我们对Flink的checkpoint机制有过深入的描述，这是Flink有能力提供Exactly-Once语义的核心。Flink文档还提供了该功能的全面概述。 在继续之前，先看下对checkpoint机制的简要介绍，这对理解后面的主题至关重要。 次checkpoint是以下内容的一致性快照：应用程序的当前状态输入流的位置Flink可以配置一个固定的时间点，定期产生checkpoint，将checkpoint的数据写入持久存储系统，例如S3或HDFS。将checkpoint数据写入持久存储是异步发生的，这意味着Flink应用程序在checkpoint过程中可以继续处理数据。 如果发生机器或软件故障，重新启动后，Flink应用程序将从最新的checkpoint点恢复处理； Flink会恢复应用程序状态，将输入流回滚到上次checkpoint保存的位置，然后重新开始运行。这意味着Flink可以像从未发生过故障一样计算结果。 在Flink 1.4.0之前，Exactly-Once语义仅限于Flink应用程序内部，并没有扩展到Flink数据处理完后发送的大多数外部系统。Flink应用程序与各种数据输出端进行交互，开发人员需要有能力自己维护组件的上下文来保证Exactly-Once语义。 为了提供端到端的Exactly-Once语义 – 也就是说，除了Flink应用程序内部，Flink写入的外部系统也需要能满足Exactly-Once语义 – 这些外部系统必须提供提交或回滚的方法，然后通过Flink的checkpoint机制来协调。 分布式系统中，协调提交和回滚的常用方法是两阶段提交协议。在下一节中，我们将讨论Flink的TwoPhaseCommitSinkFunction是如何利用两阶段提交协议来提供端到端的Exactly-Once语义。 二、Flink应用程序端到端的Exactly-Once语义我们将介绍两阶段提交协议，以及它如何在一个读写Kafka的Flink程序中实现端到端的Exactly-Once语义。Kafka是一个流行的消息中间件，经常与Flink一起使用。Kafka在最近的0.11版本中添加了对事务的支持。这意味着现在通过Flink读写Kafaka，并提供端到端的Exactly-Once语义有了必要的支持。 Flink对端到端的Exactly-Once语义的支持不仅局限于Kafka，您可以将它与任何一个提供了必要的协调机制的源/输出端一起使用。例如Pravega，来自DELL/EMC的开源流媒体存储系统，通过Flink的TwoPhaseCommitSinkFunction也能支持端到端的Exactly-Once语义。 在今天讨论的这个示例程序中，我们有： 从Kafka读取的数据源（Flink内置的KafkaConsumer）窗口聚合将数据写回Kafka的数据输出端（Flink内置的KafkaProducer）要使数据输出端提供Exactly-Once保证，它必须将所有数据通过一个事务提交给Kafka。提交捆绑了两个checkpoint之间的所有要写入的数据。这可确保在发生故障时能回滚写入的数据。但是在分布式系统中，通常会有多个并发运行的写入任务的，简单的提交或回滚是不够的，因为所有组件必须在提交或回滚时“一致”才能确保一致的结果。Flink使用两阶段提交协议及预提交阶段来解决这个问题。 在checkpoint开始的时候，即两阶段提交协议的“预提交”阶段。当checkpoint开始时，Flink的JobManager会将checkpoint barrier（将数据流中的记录分为进入当前checkpoint与进入下一个checkpoint）注入数据流。 brarrier在operator之间传递。对于每一个operator，它触发operator的状态快照写入到state backend。 数据源保存了消费Kafka的偏移量(offset)，之后将checkpoint barrier传递给下一个operator。 这种方式仅适用于operator具有『内部』状态。所谓内部状态，是指Flink state backend保存和管理的 -例如，第二个operator中window聚合算出来的sum值。当一个进程有它的内部状态的时候，除了在checkpoint之前需要将数据变更写入到state backend，不需要在预提交阶段执行任何其他操作。Flink负责在checkpoint成功的情况下正确提交这些写入，或者在出现故障时中止这些写入。 三、示例Flink应用程序启动预提交阶段但是，当进程具有『外部』状态时，需要作些额外的处理。外部状态通常以写入外部系统（如Kafka）的形式出现。在这种情况下，为了提供Exactly-Once保证，外部系统必须支持事务，这样才能和两阶段提交协议集成。 在本文示例中的数据需要写入Kafka，因此数据输出端（Data Sink）有外部状态。在这种情况下，在预提交阶段，除了将其状态写入state backend之外，数据输出端还必须预先提交其外部事务。 当checkpoint barrier在所有operator都传递了一遍，并且触发的checkpoint回调成功完成时，预提交阶段就结束了。所有触发的状态快照都被视为该checkpoint的一部分。checkpoint是整个应用程序状态的快照，包括预先提交的外部状态。如果发生故障，我们可以回滚到上次成功完成快照的时间点。 下一步是通知所有operator，checkpoint已经成功了。这是两阶段提交协议的提交阶段，JobManager为应用程序中的每个operator发出checkpoint已完成的回调。 数据源和 widnow operator没有外部状态，因此在提交阶段，这些operator不必执行任何操作。但是，数据输出端（Data Sink）拥有外部状态，此时应该提交外部事务。 ...

本文授权转自阿里技术官方公众号（ali_tech）：菜鸟供应链业务链路长、节点多、实体多，使得技术团队在建设供应链实时数仓的过程中，面临着诸多挑战，如：如何实现实时变Key统计？如何实现实时超时统计？如何进行有效地资源优化？如何提升多实时流关联效率？如何提升实时作业的开发效率？ 而 Blink 能否解决这些问题？下面一起来深入了解。 背景菜鸟从2017年4月开始探索 Blink（即 Apache Flink 的阿里内部版本），2017年7月开始在线上环境使用 Blink，作为我们的主流实时计算引擎。 为什么短短几个月的探索之后，我们就选择Blink作为我们主要的实时计算引擎呢？ 在效率上，Blink 提供 DataStream、TableAPI、SQL 三种开发模式，强大的 SQL 模式已经满足大部分业务场景，配合半智能资源优化、智能倾斜优化、智能作业压测等功能，可以极大地提升实时作业的开发效率；在性能上，诸如 MiniBatch&MicroBatch、维表 Async&Cache、利用 Niagara 进行本地状态管理等内部优化方案，可以极大地提升实时作业的性能；在保障上，Blink 自带的 Failover 恢复机制，能够实现线程级的恢复，可以做到分钟级恢复，配合 Kmonitor 监控平台、烽火台预警平台，可以有效地实现实时作业的数据保障。 接下来，我将结合供应链业务的一些业务场景，简要说明，Blink 如何解决我们遇到的一些实际问题。 回撤机制订单履行是供应链业务中最常见的物流场景。什么是订单履行呢？当商家 ERP 推单给菜鸟之后，菜鸟履行系统会实时计算出每笔订单的出库、揽收、签收等节点的预计时间，配送公司需要按照各节点的预计时间进行订单的配送。为了保证订单的准点履约，我们经常需要统计每家配送公司每天各个节点的预计单量，便于配送公司提前准备产能。 看似很简单的实时统计加工，我们在开发过程中遇到了什么问题呢？履行重算！当物流订单的上游某个节点延迟时，履行系统会自动重算该笔订单下游所有节点的预计时间。比如某个物流订单出库晚点后，其后的预计揽收时间、预计签收时间都会重算。而对于大部分的实时计算引擎来说，并不能很友好的支持这种变 Key 统计的问题。以前，数据量没那么大的时候，还可以通过 OLAP 数据库来解决这类场景，当量上来后， OLAP 方案的成本、性能都是很大的问题。 除了 OLAP 方案，我们提倡采用 Blink 已经内置的 Retraction 机制，来解决这类变 Key 统计的问题，这也是我们在2017年初就开始尝试 Blink 的重要原因。Blink 的 Retraction 机制，使用 State 在内存或者外部存储设备中对数据进行统计处理，当上游数据源对某些汇总 Key 的数据做更新时，Blink 会主动给下游下发一个删除消息从而“撤回”之前的那条消息，并用最新下发的消息对表做更新操作。 下面是一个简化后的案例，供了解 Blink Retraction 的内部计算过程： 对于上述案例，可以通过 Blink 提供的强大的、灵活的、简易的 SQL 开发模式来实现，只需要几行 SQL 即可完成。 ...

本文转载自 Jark’s Blog ，作者伍翀（云邪），Apache Flink Committer，阿里巴巴高级开发工程师。本文将从开发环境准备、创建 Maven 项目，编写 Flink 程序、运行程序等方面讲述如何迅速搭建第一个 Flink 应用。在本文中，我们将从零开始，教您如何构建第一个 Flink 应用程序。开发环境准备Flink 可以运行在 Linux, Max OS X, 或者是 Windows 上。为了开发 Flink 应用程序，在本地机器上需要有 Java 8.x 和 maven 环境。 如果有 Java 8 环境，运行下面的命令会输出如下版本信息： $ java -versionjava version "1.8.0_65"Java(TM) SE Runtime Environment (build 1.8.0_65-b17)Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)如果有 maven 环境，运行下面的命令会输出如下版本信息：$ mvn -versionApache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-18T02:33:14+08:00)Maven home: /Users/wuchong/dev/mavenJava version: 1.8.0_65, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jreDefault locale: zh_CN, platform encoding: UTF-8OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"另外我们推荐使用 ItelliJ IDEA （社区免费版已够用）作为 Flink 应用程序的开发 IDE。Eclipse 虽然也可以，但是 Eclipse 在 Scala 和 Java 混合型项目下会有些已知问题，所以不太推荐 Eclipse。下一章节，我们会介绍如何创建一个 Flink 工程并将其导入 ItelliJ IDEA。创建 Maven 项目我们将使用 Flink Maven Archetype 来创建我们的项目结构和一些初始的默认依赖。在你的工作目录下，运行如下命令来创建项目： ...

作者：陈越晨 整理：刘河 本文将为大家介绍Apache Flink在爱奇艺的生产与实践过程。你可以借此了解到爱奇艺引入Apache Flink的背景与挑战，以及平台构建化流程。主要内容如下： 爱奇艺在实时计算方面的的演化和遇到的一些挑战爱奇艺使用Flink的User Case爱奇艺Flink平台化构建流程爱奇艺在Flink上的改进未来工作爱奇艺简介 爱奇艺在2010年正式上线，于2018年3月份在纳斯达克上市。我们拥有规模庞大且高度活跃的用户基础，月活跃用户数5.65亿人，在在线视频领域名列第一。在移动端，爱奇艺月度总有效时长59.08亿小时，稳居中国APP榜第三名。 一、爱奇艺在实时计算方面的演化和遇到的一些挑战1. 实时计算在爱奇艺的演化过程 实时计算是基于一些实时到达、速率不可控、到达次序独立不保证顺序、一经处理无法重放除非特意保存的无序时间序列的数据的在线计算。 因此，在实时计算中，会遇到数据乱序、数据延时、事件时间与处理时间不一致等问题。爱奇艺的峰值事件数达到1100万/秒，在正确性、容错、性能、延迟、吞吐量、扩展性等方面均遇到不小的挑战。 爱奇艺从2013年开始小规模使用storm，部署了3个独立集群。在2015年，开始引入Spark Streaming，部署在YARN上。在2016年，将Spark Streaming平台化，构建流计算平台，降低用户使用成本，之后流计算开始在爱奇艺大规模使用。在2017年，因为Spark Streaming的先天缺陷，引入Flink，部署在独立集群和YARN上。在2018年，构建Streaming SQL与实时分析平台，进一步降低用户使用门槛。 2. 从Spark Streaming到Apache Flink 爱奇艺主要使用的是Spark Streaming和Flink来进行流式计算。Spark Streaming的实现非常简单，通过微批次将实时数据拆成一个个批处理任务，通过批处理的方式完成各个子Batch。Spark Streaming的API也非常简单灵活，既可以用DStream的java/scala API，也可以使用SQL定义处理逻辑。但Spark Streaming受限于微批次处理模型，业务方需要完成一个真正意义上的实时计算会非常困难，比如基于数据事件时间、数据晚到后的处理，都得用户进行大量编程实现。爱奇艺这边大量使用Spark Streaming的场景往往都在于实时数据的采集落盘。 Apache Flink框架的实时计算模型是基于Dataflow Model实现的，完全支持Dataflow Model的四个问题：What，支持定义DAG图；Where：定义各类窗口（固定窗口、滑动窗口和Session窗口）；When：支持灵活定义计算触发时间；How：支持丰富的Function定义数据更新模式。和Spark Streaming一样，Flink支持分层API，支持DataStream API，Process Function，SQL。Flink最大特点在于其实时计算的正确性保证：Exactly once，原生支持事件时间，支持延时数据处理。由于Flink本身基于原生数据流计算，可以达到毫秒级低延时。 在爱奇艺实测下来，相比Spark Streaming，Apache Flink在相近的吞吐量上，有更低的延时，更好的实时计算表述能力，原生实时事件时间、延时数据处理等。 二、在爱奇艺使用Flink的一些案例下面通过三个Use Case来介绍一下，爱奇艺具体是怎么使用Flink的，包括海量数据实时ETL，实时风控，分布式调用链分析。 1. 海量数据实时ETL 在爱奇艺这边所有用户在端上的任何行为都会发一条日志到nginx服务器上，总量超过千万QPS。对于具体某个业务来说，他们后续做实时分析，只希望访问到业务自身的数据，于是这中间就涉及一个数据拆分的工作。 在引入Flink之前，最早的数据拆分逻辑是这样子的，在Ngnix机器上通过“tail -f /xxx/ngnix.log | grep "xxx"”的方式，配置了无数条这样的规则，将这些不同的数据按照不同的规则，打到不同的业务kafka中。但这样的规则随着业务线的规模的扩大，这个tail进程越来越多，逐渐遇到了服务器性能瓶颈。 于是，我们就有了这样一个设想，希望通过实时流计算将数据拆分到各个业务kafka。具体来说，就是Nginx上的全量数据，全量采集到一级Kafka，通过实时ETL程序，按需将数据采集到各个业务Kafka中。当时，爱奇艺主的实时流计算基本均是基于Spark Streaming的，但考虑到Spark Streaming延迟相对来说比较高，爱奇艺从这个case展开开始推进Apache Flink的应用。 海量数据实时ETL的具体实现，主要有以下几个步骤： 解码：各个端的投递日志格式不统一，需要首先将各个端的日志按照各种解码方式解析成规范化的格式，这边选用的是JSON风控：实时拆分这边的数据都会过一下风控的规则，过滤掉很大一部分刷量日志。由于量级太高，如果将每条日志都过一下风控规则，延时会非常大。这边做了几个优化，首先，将用户数据通过DeviceID拆分，不同的DeviceID拆分到不同的task manager上，每个task manager用本地内存做一级缓存，将redis和flink部署在一起，用本地redis做二级缓存。最终的效果是，每秒redis访问降到了平均4k，实时拆分的P99延时小于500ms。拆分：按照各个业务进行拆分采样、再过滤：根据每个业务的拆分过程中根据用户的需求不同，有采样、再过滤等过程 2. 实时风控 防机器撞库盗号攻击是安全风控的一个常见需求，主要需求集中于事中和事后。在事中，进行超高频异常检测分析，过滤用户异常行为；在事后，生成IP和设备ID的黑名单，供各业务实时分析时进行防刷使用。 以下是两个使用Flink特性的案例： CEP：因为很多黑产用户是有固定的一些套路，比如刚注册的用户可能在短时间内会进行一两项操作，我们通过CEP模式匹配，过滤掉那些有固定套路的黑产行为多窗口聚合：风控这边会有一些需求，它需要在不同的一些时间窗口，有些时间窗口要求比较苛刻，可能是需要在一秒内或亚秒内去看一下某个用户有多少次访问，然后对他进行计数，计数的结果超过某些阈值就判断他是异常用户。通过Flink低延时且支持多窗口的特点，进行超高频的异常检测，比如对同一个用户在1秒内的请求进行计数，超过某个阈值的话就会被识别成黑产。3. 分布式追踪系统 ...

表格存储: 数据存储和数据消费All in one表格存储（Table Store）是阿里云自研的NoSQL多模型数据库，提供PB级结构化数据存储、千万TPS以及毫秒级延迟的服务能力。在实时计算场景里，表格存储强大的写入能力和多模型的存储形态，使其不仅可以作为计算结果表，同时也完全具备作为实时计算源表的能力。通道服务是表格存储提供的全增量一体化数据消费功能，为用户提供了增量、全量和增量加全它量三种类型的分布式数据实时消费通道。实时计算场景下，通过为数据表建立数据通道，用户可以以流式计算的方式对表中历史存量和新增数据做数据消费。利用表格存储存储引擎强大的写入能力和通道服务完备的流式消费能力，用户可以轻松做到数据存储和实时处理all in one！Blink: 流批一体的数据处理引擎Blink是阿里云在Apache Flink基础上深度改进的实时计算平台，同Flink一致Blink旨在将流处理和批处理统一，但Blink相对于社区版Flink，在稳定性上有很多优化，在某些场景特别是在大规模场景会比Flink更加稳定。Blink的另一个重大改进是实现了全新的 Flink SQL 技术栈，在功能上，Blink支持现在标准 SQL 几乎所有的语法和语义，在性能上，Blink也比社区Flink更加强大，特别是在批 SQL 的性能方面，当前 Blink 版本是社区版本性能的 10 倍以上，跟 Spark 相比，在 TPCDS 这样的场景 Blink 的性能也能达到 3 倍以上[1]。从用户技术架构角度分析，结合表格存储和Blink可以做到：1. 存储侧，使用表格存储，则可以做到写一份数据，业务立即可见，同时原生支持后续流式计算消费，无需业务双写；2. 计算侧，使用Blink流批一体处理引擎，可以统一流批计算架构，开发一套代码支持流批两个需求场景。本文就将为大家介绍实时计算的最佳架构实践：基于表格存储和Blink的实时计算架构，并带快速体验基于表格存储和Blink的数据分析job。更优的实时计算架构：基于表格存储和Blink的实时计算架构我们以一个做态势感知的大数据分析系统为例，为大家阐述表格存储和Blink实时计算的架构优势。假如客户是大型餐饮企业CEO，连锁店遍布全国各地，CEO非常关心自己有没有服务好全国各地的吃货，比如台湾顾客和四川顾客在口味评价上会不会有不同？自己的菜品是否已经热度下降了？为了解决这些问题，CEO需要一个大数据分析系统，一方面可以实时监控各地菜品销售额信息，另一方面也希望能有定期的历史数据分析，能给出自己关心的客户变化趋势。用技术角度来解读，就是客户需要：1. 客户数据的实时处理能力，持续聚合新增的订单信息，能大屏展示和以日报形式展示；2.对历史数据的离线分析能力，分析离线数据做态势感知、决策推荐。经典的解决方案基本上基于Lambda大数据架构[2]，如下图1，用户数据既需要进入消息队列系统（New Data Stream如Kafka）作为实时计算任务的输入源，又需要进入数据库系统(All Data如HBASE)来支持批处理系统，最终两者的结果写入数据库系统(MERGED VIEW)，展示给用户。这个系统的缺点就是太庞大，需要维护多个分布式子系统，数据既要写入消息队列又要进入数据库，要处理两者的双写一致性或者维护两者的同步方案，计算方面要维护两套计算引擎、开发两套数据分析代码，技术难度和人力成本很高。利用表格存储同时具备强大的写入能力、实时数据消费能力，Blink + SQL的高性能和流批融合，经典Lambda架构可以精简为下图2，基于表格存储和Blink的实时计算架构：该架构引入的依赖系统大大减少，人力和资源成本都明显下降，它的基本流程只包括：用户将在线订单数据或者系统抓取数据写入表格存储源表，源表创建通道服务数据通道；实时计算任务(黄线)，使用Blink表格存储数据源DDL定义SQL源表和结果表，开发和调试实时订单日聚合SQL job；批处理计算任务(绿线)，定义批处理源表结果表[1]，开发历史订单分析SQL job;前端服务通过读取表格存储结果表展示日报和历史分析结果；快速开始介绍完架构，我们就来迅速开发一个基于TableStore和Blink的日报实时计算SQL，以流计算的方式统计每日各个城市的实时用餐单数和餐费销售额。在表格存储控制台创建消费订单表consume_source_table(primary key: id[string])，并在订单表->通道管理下建立增量通道blink-demo-stream, 创建日统计结果表result_summary_day(primary key: summary_date[string])；在Blink开发界面，创建消费订单源表、日统计结果表、每分钟聚合视图和写入SQL：—消费订单源表CREATE TABLE source_order ( id VARCHAR,– 订单ID restaurant_id VARCHAR, –餐厅ID customer_id VARCHAR,–买家ID city VARCHAR,–用餐城市 price VARCHAR,–餐费金额 pay_day VARCHAR, –订单时间 yyyy-MM-dd primary(id)) WITH ( type=‘ots’, endPoint =‘http://blink-demo.cn-hangzhou.ots-internal.aliyuncs.com’, instanceName = “blink-demo”, tableName =‘consume_source_table’, tunnelName = ‘blink-demo-stream’,);—日统计结果表CREATE TABLE result_summary_day ( summary_date VARCHAR,–统计日期 total_price BIGINT,–订单总额 total_order BIGINT,–订单数 primary key (summary_date)) WITH ( type= ‘ots’, endPoint =‘http://blink-demo.cn-hangzhou.ots-internal.aliyuncs.com’, instanceName = “blink-demo”, tableName =‘result_summary_day’, column=‘summary_date,total_price,total_order’);INSERT into result_summary_dayselect cast(pay_day as bigint) as summary_date, –时间分区count(id) as total_order, –客户端的IPsum(price) as total_order, –客户端去重from source_ods_fact_log_track_actiongroup by pay_day;上线聚合SQL, 在表格存储源表写入订单数据，可以看到result_summary_day持续更新的日订单数，大屏展示系统可以根result_summary_day直接对接；总结使用表格存储和Blink的大数据分析架构，相对于传统开源解决方案，有很多优势：1、强大的存储和计算引擎，表格存储除了海量存储、极高的读写性能外，还提供了多元索引、二级索引、通道服务等多种数据分析功能，相对HBASE等开源方案优势明显，Blink关键性能指标为开源Flink的3到4倍，数据计算延迟优化到秒级甚至亚秒级；2、全托管服务，表格存储和Blink都全托管的serverless服务，即开即用；3、低廉的人力和资源成本，依赖服务全serverless免运维，按量付费，避免波峰波谷影响；篇幅原因，本文主要介绍了表格存储和Blink结合的大数据架构优势，以及简单SQL演示，后续更复杂、贴近场景业务的文章也会陆续推出，敬请期待！参考文献1. Blink解密，https://yq.aliyun.com/articles/6891172. Lambda大数据架构，https://mapr.com/developercentral/lambda-architecture/本文作者：竹千代_阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...