C语言网站开发pdf,音乐网页设计材料加字加图片,注册网站租空间哪里租,装修公司加盟十大品牌本次由快手刘建刚老师分享#xff0c;内容主要分为三部分。首先介绍流式计算的基本概念#xff0c; 然后介绍 Flink 的关键技术#xff0c;最后讲讲 Flink 在快手生产实践中的一些应用#xff0c;包括实时指标计算和快速 failover。 一、流式计算的介绍 流式计算主要针对 u…本次由快手刘建刚老师分享内容主要分为三部分。首先介绍流式计算的基本概念 然后介绍 Flink 的关键技术最后讲讲 Flink 在快手生产实践中的一些应用包括实时指标计算和快速 failover。 一、流式计算的介绍 流式计算主要针对 unbounded data无界数据流进行实时的计算将计算结果快速的输出或者修正。 这部分将分为三个小节来介绍。第一介绍大数据系统发展史包括初始的批处理到现在比较成熟的流计算第二为大家简单对比下批处理和流处理的区别第三介绍流式计算里面的关键问题这是每个优秀的流式计算引擎所必须面临的问题。 1、大数据系统发展史 上图是 2003 年到 2018 年大数据系统的发展史看看是怎么一步步走到流式计算的。 2003 年Google 的 MapReduce 横空出世通过经典的 MapReduce 定义和系统容错等保障来方便处理各种大数据。很快就到了 Hadoop被认为是开源版的  MapReduce 带动了整个apache开源社区的繁荣。再往后是谷歌的 Flume通过算子连接等 pipeline 的方式解决了多个 MapReduce 作业连接处理低效的问题。 流式系统的开始以 Storm 来介绍。Storm 在2011年出现 具备延时短、性能高等特性 在当时颇受喜爱。但是 Storm 没有提供系统级别的 failover 机制无法保障数据一致性。那时的流式计算引擎是不精确的lamda 架构组装了流处理的实时性和批处理的准确性曾经风靡一时后来因为难以维护也逐渐没落。 接下来出现的是 Spark Streaming可以说是第一个生产级别的流式计算引擎。Spark Streaming 早期的实现基于成熟的批处理通过 mini batch 来实现流计算在 failover 时能够保障数据的一致性。 Google 在流式计算方面有很多探索包括 MillWheel、Cloud Dataflow、Beam提出了很多流式计算的理念对其他的流式计算引擎影响很大。 再来看 Kafka。Kafka 并非流式计算引擎但是对流式计算影响特别大。Kafka 基于log 机制、通过 partition 来保存实时数据同时也能存储很长时间的历史数据。流式计算引擎可以无缝地与kafka进行对接一旦出现 Failover可以利用 Kafka 进行数据回溯保证数据不丢失。另外Kafka 对 table 和 stream 的探索特别多对流式计算影响巨大。 Flink 的出现也比较久一直到 2016 年左右才火起来的。Flink 借鉴了很多 Google 的流式计算概念使得它在市场上特别具有竞争力。后面我会详细介绍 Flink 的一些特点。 2、批处理与流计算的区别 批处理和流计算有什么样的区别这是很多同学有疑问的地方。我们知道 MapReduce 是一个批处理引擎Flink 是一个流处理引擎。我们从四个方面来进行一下对比 1使用场景 MapReduce 是大批量文件处理这些文件都是 bounded data也就是说你知道这个文件什么时候会结束。相比而言Flink 处理的是实时的 unbounded data数据源源不断可能永远都不会结束这就给数据完备性和 failover 带来了很大的挑战。 2容错 MapReduce 的容错手段包括数据落盘、重复读取、最终结果可见等。文件落盘可以有效保存中间结果一旦 task 挂掉重启就可以直接读取磁盘数据只有作业成功运行完了最终结果才对用户可见。这种设计的哲理就是你可以通过重复读取同一份数据来产生同样的结果可以很好的处理 failover。 Flink 的容错主要通过定期快照和数据回溯。每隔一段时间Flink就会插入一些 barrierbarrier 从 source 流动到 sink通过 barrier 流动来控制快照的生成。快照制作完就可以保存在共享引擎里。一旦作业出现问题就可以从上次快照进行恢复通过数据回溯来重新消费。 3性能 MapReduce 主要特点是高吞吐、高延时。高吞吐说明处理的数据量非常大高延时就是前面说到的容错问题它必须把整个作业处理完才对用户可见。 Flink 主要特点是高吞吐、低延时。在流式系统里Flink 的吞吐是很高的。同时它也可以做到实时处理和输出让用户快速看到结果。 4计算过程 MapReduce 主要通过 Map 和 reduce 来计算。Map 负责读取数据并作基本的处理 reduce 负责数据的聚合。用户可以根据这两种基本算子组合出各种各样的计算逻辑。 Flink 为用户提供了 pipeline 的 API 和批流统一的 SQL。通过 pipeline  的 API 用户可以方便地组合各种算子构建复杂的应用Flink SQL 是一个更高层的 API 抽象极大地降低了用户的使用门槛。 3、流式计算的关键问题 这部分主要通过四个问题给大家解答流式计算的关键问题也是很多计算引擎需要考虑的问题。 1What What 是指通过什么样的算子来进行计算。主要包含三个方面的类型element-wise 表示一对一的计算aggregating 表示聚合操作composite 表示多对多的计算。 2Where aggregating 会进行一些聚合的计算 主要是在各种 window 里进行计算。窗口包含滑动窗口、滚动窗口、会话窗口。窗口会把无界的数据切分成有界的一个个数据块进行处理后面我们会详细介绍这点。 3When When 就是什么时候触发计算。窗口里面有数据由于输入数据是无穷无尽的很难知道一个窗口的数据是否全部到达了。流式计算主要通过 watermark 来保障数据的完备性通过 trigger 来决定何时触发。当接收到数值为 X 的 Watermark 时可以认为所有时间戳小于等于X的事件全部到达了。一旦 watermark 跨过窗口结束时间就可以通过 trigger 来触发计算并输出结果。 4How How 主要指我们如何重新定义同一窗口的多次触发结果。前面也说了 trigger 是用来触发窗口的 一个窗口可能会被触发多次比如1分钟的窗口每 10 秒触发计算一次。处理方式主要包含三种 Discarding丢弃之前的状态重新计算。这种方式每次的触发结果都是互不关联的多次触发结果的组合反映了全部的窗口内容下游一般会再次聚合Accumulating这个就是一个聚合的状态比如说第二次触发的时候是在第一次的结果上进行计算的下游只需要保存最新的结果即可Accumulating 和 retracting这个主要在 Accumulating 的基础上加了一个 retractingretracting 的意思就是撤销。窗口再次触发时会告诉下游撤销上一次的计算结果并告知最新的结果。Flink SQL 的聚合就使用了这种 retract的模式。二、Flink 关键技术 1、Flink 简介 Flink 是一款分布式计算引擎 既可以进行流式计算也可以进行批处理。下图是官网对 Flink 的介绍 Flink 可以运行在 k8s、yarn、mesos 等资源调度平台上依赖 hdfs 等文件系统输入包含事件和各种其他数据经过 Flink 引擎计算后再输出到其他中间件或者数据库等。 Flink 有两个核心概念 StateFlink 可以处理有状态的数据通过自身的 state 机制来保障作业failover时数据不丢失Event Time允许用户按照事件时间来处理数据通过 watermark 来推动时间前进这个后面还会详细介绍。主要是系统的时间和事件的时间。Flink 主要通过上面两个核心技术来保证 exactly-once 比如说作业 Failover 的时候状态不丢失就好像没发生故障一样。 2、快照机制 Flink 的快照机制主要是为了保障作业 failover 时不丢失状态。Flink 提供了一种轻量级的快照机制不需要停止作业就可以帮助用户持久化内存中的状态数据。 上图中的 markers与 barrier 语义相同通过流动来触发快照的制作每一个编号都代表了一次快照比如编号为 n 的 markers 从最上游流动到最下游就代表了一次快照的制作过程。简述如下 系统发送编号为 n 的 markers 到最上游的算子markers 随着数据往下游流动当下游算子收到 marker 后就开始将自身的状态保存到共享存储中当所有最下游的算子接收到 marker 并完成算子快照后本次作业的快照制作完成。一旦作业失败重启时就可以从快照恢复。 下面为一个简单的 demo 说明barrier 等同于 marker。 barrier 到达 Source将状态 offset7 存储到共享存储barrier 到达 Task将状态 sum21 存储到共享存储barrier 到达 Sinkcommit 本次快照标志着快照的成功制作。这时候突然间作业也挂掉 重启时 Flink 会通过快照恢复各个状态。Source 会将自身的 offset 置为 7Task 会将自身的 sum 置为 21。现在我们可以认为 1、2、3、4、5、6 这 6 个数字的加和结果并没有丢失。这个时候offset 从 7 开始消费跟作业失败前完全对接了起来确保了 exactly-once。 3、事件时间 时间类型分为两种 Event time事件时间指事件发生的时间比如采集数据时的时间Processing time系统时间指系统的时间比如处理数据时的时间。如果你对数据的准确性要求比较高的话采用 Event time 能保障 exactly-once。Processing Time 一般用于实时消费、精准性要求略低的场景主要是因为时间生成不是 deterministic。 我们可以看下面的关系图 X 轴是 Event timeY 轴是 Processing time。理想情况下 Event time 和 Processing time 是相同的就是说只要有一个事件发生就可以立刻处理。但是实际场景中事件发生后往往会经过一定延时才会被处理这样就会导致我们系统的时间往往会滞后于事件时间。这里它们两个的差 Processing-time lag 表示我们处理事件的延时。 事件时间常用在窗口中使用 watermark 来确保数据完备性比如说 watermarker 值大于 window 末尾时间时我们就可以认为 window 窗口所有数据都已经到达了就可以触发计算了。 比如上面 [0-10] 的窗口现在 watermark 走到了 10已经到达了窗口的结束触发计算 SUM21。如果要是想对迟到的数据再进行触发可以再定义一下后面 late data 的触发比如说后面来了个 9我们的 SUM 就等于 30。 4、窗口机制 窗口机制就是把无界的数据分成数据块来进行计算主要有三种窗口。 滚动窗口固定大小的窗口相邻窗口没有交集滑动窗口每个窗口的大小是一样的但是两个窗口之间会有重合会话窗口根据活跃时间聚合而成的窗口 比如活跃时间超过3分钟新起一个窗口。窗口之间留有一定的间隔。窗口会自动管理状态和触发计算Flink 提供了丰富的窗口函数来进行计算。主要包括以下两种 ProcessWindowFunction全量计算会把所有数据缓存到状态里一直到窗口结束时统一计算。相对来说状态会比较大计算效率也会低一些AggregateFunction增量计算就是来一条数据就算一条可能我们的状态就会特别的小计算效率也会比 ProcessWindowFunction 高很多但是如果状态存储在磁盘频繁访问状态可能会影响性能。三、快手 Flink 实践 1、应用概括 快手应用概括主要是分为数据接入、Flink 实时计算、数据应用、数据展示四个部分。各层各司其职、衔接流畅为用户提供一体化的数据服务流程。 2、实时指标计算 常见的实时指标计算包括 uv、pv 和 sum。这其中 uv 的计算最为复杂也最为经典。下面我将重点介绍 uv。 uv 指的是不同用户的个数我们这边计算的就是不同 deviceld 的个数主要的挑战来自三方面 用户数多数据量大。活动期间的 QPS 经常在千万级别实际计算起来特别复杂实时性要求高通常为几秒到分钟结果的输出稳定性要求高比如说我们在做春晚活动时候要求故障时间需要低于2%或更少。针对各种各样的 uv 计算我们提供了一套成熟的计算流程。主要包含了三方面 字典方案将 string 类型的 deviceld 转成 long 类型方便后续的 uv 计算倾斜处理比如某些大 V 会导致数据严重倾斜这时候就需要打散处理增量计算比如计算 1 天的 uv每分钟输出一次结果。字典方案需要确保任何两个不同的 deviceId 不能映射到相同的 long 类型数字上。快手内部主要使用过以下三种方案 HBase 基于 partition 分区建立 deviceld 到 id 的映射 通过缓存和批量访问来加速Redis 这种方案严格来说不属于字典主要通过 key-value 来判断数据是否首次出现基于首次数据来计算 uv这样就会把 pv 和 uv 的计算进行统一;最后就是一个 Flink 内部自建的全局字典实现 deviceld 到 id 的转换之后计算UV。这三种方案里面前两种属于外部存储的字典方案优点是可以做到多个作业共享 1 份数据 缺点是外部访问慢而且不太稳定。最后一种 Flink 字典方案基于 state不依赖外部存储 性能高但是无法多作业共享。 接下来我们重点介绍基于Flink自身的字典方案下图主要是建立一个 deviceld 到 id 的映射 主要分成三步走 1建立 Partition 分区 指定一个比较大的 Partition 分区个数该个数比较大并且不会变根据 deviceld 的哈希值将其映射到指定 partition。 2建立 id 映射。每个 Partition 都有自己负责的 id 区间确保 Partition 之间的long 类型的 id 不重复 partition 内部通过自增 id 来确保每个 deviceId 对应一个 id。 3使用 keyed state 保存 id 映射。这样我们的作业出现并发的大改变时可以方便的 rescale不需要做其他的操作。 除了 id 转换后面就是一个实时指标计算的常见问题就是数据倾斜。业界常见的解决数据倾斜处理方案主要是两种 打散再聚合先将倾斜的数据打散计算然后再聚合计算结果Local-aggregate先在本地计算预聚合这样会大大减少下游的数据压力。二者的本质是一样的都是先预聚合再汇总从而避免单点性能问题。 上图为计算最小值的热点问题红色数据为热点数据。如果直接将它们打到同一个分区会出现性能问题。为了解决倾斜问题我们通过hash策略将数据分成小的 partition 来计算如上图的预计算最后再将中间结果汇总计算。 当一切就绪后我们来做增量的 UV 计算比如计算 1 天 uv每分钟输出 1 次结果。计算方式既可以采用 API也可以采用 SQL。 针对 API我们选择了 global statebitmap 的组合既严格遵循了 Event Time 又减少了 state 大小 下面为计算流程需要注意时区问题 定义跟触发间隔一样大小的 window比如 1 分钟Global state 用来保存跨窗口的状态我们采用 bitmap 来存储状态每隔一个 window 触发一次输出起始至今的 UV当前作用域比如 1 天结束清空状态重新开始。针对 SQL增量计算支持的还不是那么完善但是可以利用 early-fire 的参数来提前触发窗口。 配置如下 table.exec.emit.early-fire.enabled truetable.exec.emit.early-fire.delay60 s early-fire.delay 就是每分钟输出一次结果的意思。 SQL 如下 SELECT TUMBLE_ROWTIME(eventTime, interval ‘1’ day) AS rowtime, dimension, count(distinct id) as uv FROM person GROUP BY TUMBLE(eventTime, interval 1 day), dimension 如果遇到倾斜可以参考上一步来处理。 3、快速 failover 最后看下我们部门最近发力的一个方向如何快速 failover。 Flink 作业都是 long-running 的在线作业很多对可用性的要求特别高尤其是跟公司核心业务相关的作业SLA 要求 4 个 9 甚至更高。当作业遇到故障时如何快速恢复对我们来说是一个巨大的挑战。 下面分三个方面来展开 Flink 当前已有的快速恢复方案基于 container 宕掉的快速恢复基于机器宕掉的快速恢复。1Flink 当前已有的快速恢复方案 Flink 当前已有的快速恢复方案主要包括以下两种 region failover。如果流式作业的 DAG 包含多个子图或者 pipeline那么 task 失败时只会影响其所属的子图或者 pipeline 而不用整个 DAG 都重新启动local recovery。在 Flink 将快照同步到共享存储的同时在本地磁盘也保存一份快照。作业失败恢复时可以调度到上次部署的位置并从 local disk 进行快照恢复。2基于 container 宕掉的快速恢复 实际环境中 container 宕掉再申请有时会长达几十秒比如因为 hdfs 慢、yarn 慢等原因严重影响恢复速度。为此我们做了如下优化 冗余资源。维持固定个数的冗余 container一旦 container 宕掉冗余 container 立刻候补上来省去了繁杂的资源申请流程提前申请。一旦发现作业因为 container 宕掉而失败立刻申请新的 container 。以上优化覆盖了很大一部分场景恢复时间从 30s-60s 降到 20s 以内。 3基于机器宕掉的快速恢复 机器宕掉时flink on yarn 的恢复时间超过 3 分钟这对重要作业显然是无法容忍的为了做到快速恢复我们需要做到快速感知和恢复 冗余资源并打散分配确保两个冗余资源不在一个 containerredundantContainerNummax(containerNumOfHost) 1作业宕机Hawk 监测系统 5 秒内发现冗余资源快速候补免去申请资源的流程。通过这种方案我们可以容忍任意一台机器的宕机并将宕机恢复时间由原先的 3 分钟降低到 30 秒以内。 四、总结 本文从大数据系统的发展入手进而延伸出流式系统的关键概念之后介绍了 Flink的关键特性最后讲解了快手内部的实时指标计算和快速 failover希望对大家有所帮助。 五、QA Q1打算做实时计算可以跳过 Storm、Spark 直接上手 Flink 吗 A可以直接使用 Flink。Storm 在 failover 时会丢失数据无法做到 exactly-oncespark streaming 是 Flink 的竞争者是在批处理的基础上实现流计算相比而言Flink 的底层是流处理更加适合流计算。 Q2一般怎么处理 taskmanager heartbeat timeout A默认 10 秒汇报一次心跳心跳超时为 50 秒这个时候作业会失败如果配置了高可用那么会重启。 Q3如何保证 2 天大时间跨度延迟消息的窗口计算 A这里主要的挑战在于时间长、状态大建议 stateBakend 使用 Rocksdb可以利用磁盘存储大状态窗口计算建议使用增量计算来减少状态的大小。 Q4Flink on YarnYarn 重启会自动拉起 Flink 任务吗说不能拉起怎么处理手动启动吗 A如果配置了高可用依赖 zookeeper作业失败了就可以自动拉起。 Q5Kafka 目前多用作数据中转平台Flink 相当于替代了 Kafka Stream 吗 AKafka的核心功能是消息中间件kafka stream 可以跟 kafka 很好的集成但并不是一个专业的计算引擎。相比而言flink 是一个分布式的流式计算引擎功能上更加强大。 Q6你们怎么看待 Apache Beam AApache Beam 在上层进行了抽象可以类比 SQL只定义规范底层可以接入各种计算引擎。     原文链接 本文为阿里云原创内容未经允许不得转载。