Apache Flink

摘要： 在本篇文章中我们将对 RocksDB、Heap 和 Gemini 在相同场景下进行压测，并对其资源消耗进行对比。测试的 Flink 内核版本为 1.10.0。 微博机器学习平台使用 Flink 实现多流 join 来生成在线机器学习需要的样本。时间窗口内的数据会被缓存到 state 里，且 state 访问的延迟通常决定了作业的性能。开源 Flink 的状态存储主要包括 RocksDB 和 Heap 两种，而在去年的 Flink Forward 大会上我们了解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini，并对其进行了测试和试用。 测试场景 我们使用真实的样本拼接业务作为测试场景，通过将多个流的数据 union后对指定key做聚合（keyby），在聚合函数里从各个流中获取相应的字段，并将需要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer，用 timer 功能来替代 TimeWindow，窗口结束时将数据发射到下游算子。使用 timer 功能的主要原因是 timer 更灵活，更方便用户自定义，在平台的实用性，可扩展性上表现更好。 MemoryStateBackend vs. RocksDBStateBackend 首先需要说明的是，MemoryStateBackend 不建议在线上使用

近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。 如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点 一大数据技术栈 大数据整体流程涉及很多模块，每一个模块都比较复杂，下图列出这些模块和组件以及他们的功能特性，后续会有专题去详细介绍相关模块领域知识，例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。 二、lambda架构和kappa架构 目前基本上所有的大数据架构都是基于lambda和kappa架构，不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。 它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性，关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系，从而带来的各种成本问题，这也是目前流批一体化研究方向，很多企业已经开始使用这种更为先进的架构。 Lambda架构

output操作概览 Output Meaning print 打印每个batch中的前10个元素，主要用于测试，或者是不需要执行什么output操作时，用于简单触发一下job。 saveAsTextFile(prefix, [suffix]) 将每个batch的数据保存到文件中。每个batch的文件的命名格式为：prefix-TIME_IN_MS[.suffix] saveAsObjectFile 同上，但是将每个batch的数据以序列化对象的方式，保存到SequenceFile中。 saveAsHadoopFile 同上，将数据保存到Hadoop文件中 foreachRDD 最常用的output操作，遍历DStream中的每个产生的RDD，进行处理。可以将每个RDD中的数据写入外部存储，比如文件、数据库、缓存等。通常在其中，是针对RDD执行action操作的，比如foreach。 output操作 DStream中的所有计算，都是由output操作触发的，比如print()。如果没有任何output操作，那么，压根儿就不会执行定义的计算逻辑。 此外，即使你使用了foreachRDDoutput操作，也必须在里面对RDD执行action操作，才能触发对每一个batch的计算逻辑。否则，光有foreachRDD output操作，在里面没有对RDD执行action操作

在前面的文章中，有详细地介绍java字节码相关的知识，有兴趣的可以提前了解一下。 1. Java字节码的一段旅行经历——提升硬实力1 2. Java字节码角度分析a++ ——提升硬实力2 3. Java字节码角度分析条件判断指令 ——提升硬实力3 4. Java字节码角度分析循环控制 ——提升硬实力4 下面我们将以字节码的视角来分析判断结果 // 从字节码角度来分析：判断结果 public class T08_ByteAnalyseJudgeResult { public static void main(String[] args) { int i = 0 ; int x = 0; while (i < 10) { x = x++; i++; } System.out.println(x); // 结果是0 } } T08_ByteAnalyseJudgeResult 字节码：使用javap -v T08_ByteAnalyseJudgeResult.class，将java程序对应的字节码如下，并做了执行的注释。 0: iconst_0 // int型常量值0进栈 1: istore_1 // 将栈顶int型数值存入第二个局部变量，从0开始计数 (1号槽位 i) 2: iconst_0 // int型常量值0进栈 3: istore_2 // 将栈顶元素存入第三个本地变量

在前面的文章中，有详细地介绍java字节码相关的知识，有兴趣的可以提前了解一下。 1. Java字节码的一段旅行经历——提升硬实力1 2. Java字节码角度分析a++ ——提升硬实力2 3. Java字节码角度分析条件判断指令 ——提升硬实力3 下面我们将以字节码的视角来分析循环控制指令 循环控制指令： 其实循环控制还是前面介绍的那些指令，例如while循环： // 从字节码角度来分析：循环控制指令 public class T05_ByteAnalyseWhile { public static void main(String[] args) { int a = 0; while (a < 10) { a++; } } } T05_ByteAnalyseWhile 字节码：使用javap -v T05_ByteAnalyseWhile.class，将java程序对应的字节码如下，并做了执行的注释。 0: iconst_0 // int型常量值0进栈 1: istore_1 // 将栈顶int型数值存入第二个局部变量，从0开始计数 2: iload_1 // 第二个int型局部变量进栈，从0开始计数 3: bipush 10 // 将一个byte型常量值推送至栈顶 5: if_icmpge 14 // 比较栈顶两int型数值大小，当结果大于等于0时跳转到14行 8: iinc

首先clone源码 git clone git://github.com/apache/flink.git 然后切换到blink分支 git checkout blink 编辑 flink-filesystems 下的pom文件，注释掉 mapr，如下 <modules> <module>flink-hadoop-fs</module> <!--<module>flink-mapr-fs</module>--> <module>flink-s3-fs-hadoop</module> <module>flink-s3-fs-presto</module> <module>flink-swift-fs-hadoop</module> </modules 最后编译， 使用参数“-Dskip.npm”跳过npm编译 mvn clean package -Dmaven.test.skip=true -Dskip.npm -Dmaven.javadoc.skip=true -Dcheckstyle.skip=true -Dlicense.skip=true -Drat.ignoreErrors=true 最后编译出的文件在flink-dist目录下，如图 来源： oschina 链接： https://my.oschina.net/jingshishengxu/blog/4294090

简介： 为了让广大开发者清晰了解技术体系，打造属于自己的系统学习路径。今天，开发者社区整理了10+知识图谱，供大家交流学习，持续更新中~ 知识的学习从来就不是孤立的，学习任何知识（概念、定义、公式、问题、观念、理论等）都需要联系，你创造的联系越多，它们就会记得越牢、理解得越好。把孤立的知识点关联起来，是避免遗忘的重要手段。 正如Google的辛格博士在介绍知识图谱时提到的： “The world is not made of strings , but is made of things.” 知识体系可以方便地给出所学知识的地图全貌。在学习过程中给人进度反馈。 知识体系还提供了可拓展性。新学知识可以有规律地添加在原有体系之中。 梳理知识体系，可以提炼出知识的主干网络，方便知识的调用，加深对知识点的理解。 知识体系为知识的关联提供的指导，发掘知识点之间的关联，正是创新的核心。 为了让广大开发者清晰了解技术体系，打造属于自己的系统学习路径。今天，开发者社区整理了10+知识图谱，供大家交流学习，持续更新中~ 1、容器服务知识图谱 Kubernetes 作为云原生时代的“操作系统”，熟悉和使用它是每名用户的必备技能。本篇文章概述了容器服务 Kubernetes 的知识图谱，部分内容参考了网上的知识图谱，旨在帮助用户更好的了解 K8s 的相关知识。 2、大数据技术知识图谱 对海量数据进行存储

近日，在Spark开源十周年之际，Spark3.0发布了，这个版本大家也是期盼已久。登录Spark官网，最新的版本已经是3.0。而且不出意外，对于Structured Streaming进行了再一次的加强，这样Spark和Flink在实时计算领域的竞争，恐怕会愈演愈烈。 Spark 3.0 主要的新特性如下： 相比于Spark2.4，性能提升了2倍，主要体现在自适应查询执行，动态分区修剪等方面。 Pandas API改动，包括Python类型的提示和UDF函数。 对于PySpark的异常处理进行了增强。 新的Structured Streaming UI页面。 而且解决了大量Jira问题。 Structured Streaming最初于Spark 2.0引入，并且停止了SparkStreaming的更新，很明显Structured Streaming的出现是为了在实时计算领域可以与对水印，窗口等支持更好的Flink一战。 3.0版本添加Structured Streaming的专用UI，可以方便的查看流作业的执行信息。 虽然与Flink比起来，Structured Streaming还有很长的路要走，但是可以期待Spark 3.0版本对于Structured Streaming的持续加强。 更多实时数据分析相关博文与科技资讯，欢迎关注 “实时流式计算” 来源： oschina 链接

前言 不知不觉，2020年已经过去一半了，最近突然反应过来自己也看了不少文献资料了，就想着把看过的文献和觉得比较好的书籍做一个总结，基本都是大数据分布式领域的，回顾自己学识的同时，也给想从事或这个领域的小伙伴一些参考 😃。最后顺便把接下来要看的东西列个列表，也会将自己学习的心得和经验分享出来，有需要的童鞋可以参考参考。 另外有些文献看完我会进行整理和输出，这部分链接我一并附在文献的介绍后面，后面看的书或是文献也会保持这种习惯，如果觉得有兴趣欢迎各位大佬交流，顺便也可以点波关注~~ 论文总结 MapReduce 《MapReduce Simplified Data Processing on Large Clusters》 从现在的眼光来看，Mapreduce可以说可圈可点。但在那个年代，这个思想可以说是相当先进的。不得不说Google一直引领技术潮流，包括近几年流行的k8s也是Google主导。 这篇文章主要介绍了Mapreduce的流程还有一些细节方面的介绍，如果已经有使用过Mapreduce编程的小伙伴应该看一遍就能懂。另外，看完如果想加以巩固的话，推荐做MIT6.824的Lab1，用go实现一个Mapreduce。至于什么是Mit6.824，百度一下就知道喔。我以前也有写过一篇介绍MR，有兴趣的童鞋不妨看看： 从分治算法到 Hadoop MapReduce 。 地址：

Spark憋了一年半的大招后，发布了3.0版本，新特性主要与Spark SQL和Python相关。这也恰恰说明了大数据方向的两大核心：BI与AI。下面是本次发布的主要特性，包括性能、API、生态升级、数据源、SQL兼容、监控和调试等方面的升级。 本次主要整理了性能方面的优化，包括了自适应查询与动态分区裁剪。 1 自适应查询 AQE，Adaptive Query Execution，说的简单点就是让Spark在运行中根据搜集到的信息灵活采取优化手段，提升性能。 说起这个可以先回想下Spark的发展历史，在1.x时代Spark通过RDD的编程形成DAG图，这个阶段可以说没啥优化完全是按照规则来执行；在2.x时代，引入了代价计算，Spark会通过提前进行代价计算，选择代价最小的查询计划（跟大部分的数据库类似，代价计算依赖于数据本身的统计，如数据量、文件大小、分区数等，由于Spark是存储与计算分离的模式，因此这些统计信息有时候会缺失或者不准确，那么得到的查询代价自然也就不准确了）；在3.x时代，引入自适应查询，即在运行的过程中可以根据得到的缓存数据信息动态调整分区策略、join策略等。这样就保证了刚开始表的统计信息不准，可能查询计划不是最高效的，但是随着查询的执行，可以动态优化整个查询计划。 那么到底自适应都可以做什么呢？ 1.1 动态分区合并 在Spark的经典优化策略里