『壹』 Flink主节点如何访问工作节点日志
在命令行查看任务日志设置 yarn.log-aggregation-enable 为 true ，默认为 false 。日志聚合是 yarn 提供的日志中央化管理功能，收集每个容器的日志并将这些日志移动到文件系统中，比如 HDFS 上，方便用户查看日志。yarn.nodemanager.log.retain-seconds: 保存在本地节点的日志的留存时间, 默认值是 10800，单位：秒，即 3 小时。当开启日志聚合功能后，该配置无效。yarn.nodemanager.delete.debug-delay-sec：默认值为 0，表示在开启日志聚合功能的情况下，应用完成后，进行日志聚合，然后 NodeManager 的 DeletionService 立即删除应用的本地日志。如果想查看应用日志，可以将该属性值设置得足够大（例如，设置为 600 = 10 分钟）以允许查看这些日志。
『贰』 Apache Flink是什么
Flink其实就是Apache Flink，是一款业内非常火的大数据产品，由Apache软件基金会开发，核心是用java和Scala编写的分布式流数据流引擎。Apache Flink是个旨在提供‘一站式’ 的分布式开源数据处理框架。Flink以数据并行和流水线方式执行任意流数据程序，Flink的流水线运行时系统可以执行批处理和流处理程序。此外，Flink的运行时本身也支持迭代算法的执行。虽然，spark和storm的计算框架非常成熟，但是Flink仍然占据了一席之地。主要在于flink在设计event time处理模型上比较优秀：watermark的计算实时性高，输出延迟低，而且接受迟到数据没有spark那么受限。另外，Flink提供的window programming模型非常的灵活，不但支持spark、storm没有的session window，而且只要实现其提供的WindowAssigner、Trigger、Evictor就能创造出符合自身业务逻辑的window，flink可谓功能非常强大。
『叁』 chrome://fflinkfilter/content/IKavLinkHighlightFilter.js:25停止运行是什么问题火狐狸经常提示
您好！很高兴为您答疑。这个提示应该是来自于您某个扩展的提示，该扩展出现了兼容或损坏等情况，其实它本身不会对您的使用造成多大影响，如果觉得该提示比较烦的话，您可以尝试使用安全模式（firefox-safe-mode）或新建配置文件（firefox-p-no-remote），在排除扩展的干扰下进行问题的定位。找到有问题的扩展将其禁用或删除即可。如果对我们的回答存在任何疑问，欢迎继续问询。
『肆』 这个php错了什么
从代码上看，在读取文件时，文件指针已经在文件尾部了，自然读不到数据，应将文件指针重置到起始位置后再读取，即fseek( $flink, 0 );$content = fread($flink,9999); 另外，如果图片是查看源码的结果，有两种可能，一是php没配置好，另一种可能是没有开启short_open_tag。如果是前者，先配置好运行环境，如果是后者，用<?php替代<?，或者改配置文件，short_open_tag = On
『伍』 flink如何去接受kafka安装和配置
纯java开发的软件在linux下面也可以应用自如。那么首先就需要配置好linux下的java环境，具体说来，就是配置jdk环境变量。介绍在linux下配置jdk环境变量的几种常用方法。首先在linux下安装jdk，如果出现提示权限不够（且root下也提示权限不够）
『陆』 flink窗口的种类及详述
flink窗口的种类及详述： 滚动窗口（tumblingwindow）将事件分配到长度固定且互不重叠的桶中。 实际案例：简单且常见的分维度分钟级别同时在线用户数、总销售额 Java设置语句：window(TumblingProcessingTimeWindows.of(Time.seconds(5))) 该语句为设置滚动窗口的窗口时长为5秒钟 sql设置语句：FROM TABLE(TUMBLE( TABLE source_table , DESCRIPTOR(row_time) , INTERVAL '60' SECOND)) Windowing TVF 滚动窗口的写法就是把 tumble window 的声明写在了数据源的 Table 子句中，即 TABLE(TUMBLE(TABLE source_table, DESCRIPTOR(row_time), INTERVAL '60' SECOND))，包含三部分参数。 第一个参数 TABLE source_table 声明数据源表；第二个参数 DESCRIPTOR(row_time) 声明数据源的时间戳；第三个参数 INTERVAL '60' SECOND 声明滚动窗口大小为 1 min滑动窗口：分配器将每个元素分配给固定窗口大小的窗口。与滚动窗口分配器类似，窗口的大小由 window size 参数配置。还有一个window slide参数用来控制滑动窗口的滑动大小。因此，如果滑动大小小于窗口大小，则滑动窗口会重叠。在这种情况下，一个元素会被分配到多个窗口中。 实际案例：简单且常见的分维度分钟级别同时在线用户数，1 分钟输出一次，计算最近 5 分钟的数据 java设置语句：window(SlidingProcessingTimeWindows.of(Time.seconds(10), Time.seconds(5))) window size ：窗口大小为 10秒钟 window slide：窗口间隔为5秒钟 sql设置语句： hop(row_time, interval '1' minute, interval '5' minute) 第一个参数为事件时间的时间戳；第二个参数为滑动窗口的滑动步长；第三个参数为滑动窗口大小。会话窗口：分配器通过活动会话对元素进行分组。与滚动窗口和滑动窗口相比，会话窗口不会重叠，也没有固定的开始和结束时间。当会话窗口在一段时间内没有接收到元素时会关闭。会话窗口分配器需要配置一个会话间隙，定义了所需的不活动时长。当此时间段到期时，当前会话关闭，后续元素被分配到新的会话窗口。 实际案例：计算每个用户在活跃期间（一个 Session）总共购买的商品数量，如果用户 5 分钟没有活动则视为 Session 断开 设置语句：基于事件时间的会话窗口window(EventTimeSessionWindows.withGap(Time.minutes(10))) 基于处理时间的会话窗口 Java设置：window(ProcessingTimeSessionWindows.withGap(Time.minutes(10))) 会话间隙,不活动时长为10秒钟 sql设置：session(row_time, interval '5' minute) Group Window Aggregation 中 Session 窗口的写法就是把 session window 的声明写在了 group by 子句中 Session 窗口即支持 处理时间 也支持 事件时间。但是处理时间只支持在 Streaming 任务中运行，Batch 任务不支持。渐进式窗口：在其实就是 固定窗口间隔内提前触发的的滚动窗口，其实就是 Tumble Window + early-fire 的一个事件时间的版本。例如，从每日零点到当前这一分钟绘制累积 UV，其中 10:00 时的 UV 表示从 00:00 到 10:00 的 UV 总数。渐进式窗口可以认为是首先开一个最大窗口大小的滚动窗口，然后根据用户设置的触发的时间间隔将这个滚动窗口拆分为多个窗口，这些窗口具有相同的窗口起点和不同的窗口终点。 应用场景：周期内累计 PV，UV 指标（如每天累计到当前这一分钟的 PV，UV）。这类指标是一段周期内的累计状态，对分析师来说更具统计分析价值，而且几乎所有的复合指标都是基于此类指标的统计（不然离线为啥都要累计一天的数据，而不要一分钟累计的数据呢）。 实际案例：每天的截止当前分钟的累计 money（sum(money)），去重 id 数（count(distinct id)）。每天代表渐进式窗口大小为 1 天，分钟代表渐进式窗口移动步长为分钟级别 sql设置：FROM TABLE(CUMULATE( TABLE source_table , DESCRIPTOR(row_time) , INTERVAL '60' SECOND , INTERVAL '1' DAY)) Windowing TVF 滚动窗口的写法就是把 cumulate window 的声明写在了数据源的 Table 子句中，即 TABLE(CUMULATE(TABLE source_table, DESCRIPTOR(row_time), INTERVAL '60' SECOND, INTERVAL '1' DAY))，其中包含四部分参数： 第一个参数 TABLE source_table 声明数据源表；第二个参数 DESCRIPTOR(row_time) 声明数据源的时间戳；第三个参数 INTERVAL '60' SECOND 声明渐进式窗口触发的渐进步长为 1 min。第四个参数 INTERVAL '1' DAY 声明整个渐进式窗口的大小为 1 天，到了第二天新开一个窗口重新累计全局窗口:分配器将具有相同 key 的所有元素分配给同一个全局窗口。仅当我们指定自定义触发器时，窗口才起作用。否则，不会执行任何计算，因为全局窗口没有我们可以处理聚合元素的自然结束的点（译者注：即本身自己不知道窗口的大小，计算多长时间的元素） window(GlobalWindows.create())平时滑动窗口用得比较多，其次是滚动窗口
『柒』 flink组件擅长什么
Flink是一个框架和分布式处理引擎，用于对无限制和有限制的数据进行有状态的计算。Flink被设计为可在所有常见的集群环境中运行，以内存速度和任何规模执行计算。Flink擅长处理无边界和有界的数据集。对事件和状态的精确控制使Flink的运行时能够在无限制的流上运行任何类型的应用程序。有界流由专门为固定大小的数据集设计的算法和数据结构在内部进行处理，从而产生出色的性能。部署Flink应用程序时，Flink会根据应用程序配置的并行性自动识别所需的资源，并向资源管理器请求它们。如果发生故障，Flink会通过请求新资源来替换发生故障的容器。提交或控制应用程序的所有通信均通过REST调用进行。简化了Flink在许多环境中的集成。Flink旨在运行任何规模的有状态流应用程序。将应用程序并行化可能在集群中分布并同时执行的数千个任务。因此，应用程序几乎可以利用无限数量的CPU，主内存，磁盘和网络IO。并且，Flink易于维护非常大的应用程序状态。它的异步和增量检查点算法可确保对处理延迟的影响降至最低，同时保证一次状态一致性。
『捌』 Flink 维表Join/双流Join 方法总结
事实表通常存储在kafka中，维表通常存储在外部设备中(比如MySQL，HBase)。对于每条流式数据，可以关联一个外部维表数据源，为实时计算提供数据关联查询。维表可能是会不断变化的，在维表JOIN时，需指明这条记录关联维表快照的时刻。需要注意是，目前Flink SQL的维表JOIN仅支持对当前时刻维表快照的关联(处理时间语义)，而不支持事实表rowtime所对应的的维表快照。 引 这个方案的优点就是实现起来比较简单，缺点也比较明显，因为我们要把每个维度数据都加载到内存里面，所以它只支持少量的维度数据。同时如果我们要去更新维表的话，还需要重启作业，所以它在维度数据的更新方面代价是有点高的，而且会造成一段时间的延迟。对于预加载维表来说，它适用的场景就是小维表，变更频率诉求不是很高，且对于变更的及时性的要求也比较低的这种场景。 改进：open()新建一个线程定时加载维表，这样就不需要人工的去重启 Job 来让维度数据做更新，可以实现一个周期性的维度数据的更新。 因为数据要加载到内存中，所以支持的数据量比较小。而且如果维度数据需要更新，也是需要重启作业的。 那么它适用的场景就是维度数据是文件形式的、数据量比较小、并且更新的频率也比较低的一些场景，比如说我们读一个静态的码表、配置文件等等。 如上图展示的这样的一个流程。在 Cache 这块的话，比较推荐谷歌的 Guava Cache，它封装了一些关于 Cache 的一些异步的交互，还有 Cache 淘汰的一些机制，用起来是比较方便的。 异步 IO 可以并行发出多个请求，整个吞吐是比较高的，延迟会相对低很多。如果使用异步 IO 的话，它对于外部存储的吞吐量上升以后，会使得外部存储有比较大的压力，有时也会成为我们整个数据处理上延迟的瓶颈。所以引入 Cache 机制是希望通过 Cache 来去减少我们对外部存储的访问量。 这个方案的优点就是维度数据不用全量加载到内存中，不受限于内存大小。 但是需要依赖热存储资源，再加上cache过期时间，所以最后结果会有一定的延迟。 适用于维度数据量比较大，能接受维度更新有一定延迟的情况。 广播维表虚啊维度的变更可以及时的更新到结果，但是数据还是需要保存在内存中，因为它是存在 State 里的，所以支持维表数据量仍然不是很大。适用的场景就是我们需要时时的去感知维度的变更，且维度数据又可以转化为实时流。 它的实现是通过 UDTF 去做 probe 流和 Temporal table 的 join，称之 Temporal table function join。这种 Join 的方式，它适用的场景是维度数据为 Changelog 流的形式，而且我们有需要按时间版本去关联的诉求。 维表Join方案对比 批处理有两种方式处理两个表的Join，一种是基于排序的Sort-Merge Join，更一种是转化为Hash Table 加载到内存里做Hash Join。 在双流Join的场景中，Join的对象是两个流，数据是不断进入的，所以我们Join的结果也是需要持续更新的。基本思路是将一个无线的数据流，尽可能拆分成有限数据集去做Join。 Interval Join 是同时支持 processing time 和 even time去定义时间的。如果使用的是 processing time，Flink 内部会使用系统时间去划分窗口，并且去做相关的 state 清理。如果使用 even time 就会利用 Watermark 的机制去划分窗口，并且做 State 清理。
『玖』 Flink on Yarn两种模式启动参数及在Yarn上的恢复
注意:系统和运行脚本在启动时解析配置.对配置文件的更改需要重新启动Flink JobManager和TaskManagers
Flink on Yarn模式安装部署要做的其实不多，正常的步骤： 1、上传二进制包 ===》2、解压缩 ===》 3、更改文件名称 ===》 4、配置环境变量。Flink on yarn的job运行模式大致分为两类：
第一种模式分为两步：yarn-session.sh(开辟资源)—>flink run（提交任务）
另外，jobmanager和taskmanager分别占有容器，示例： ./bin/yarn-session.sh -n 10 -tm 8192 -s 32 上面的例子将会启动11个容器(即使仅请求10个容器)，因为有一个额外的容器来启动ApplicationMaster 和 job manager,一旦flink在你的yarn集群上部署，它将会显示job manager的连接详细信息。
第二种模式其实也分为两个部分，依然是开辟资源和提交任务，但是在Job模式下，这两步都合成一个命令了。 这里，我们直接执行命令
在job结束后就会关闭flink yarn-session的集群
sudo /usr/lib/flink/bin/flink run -m yarn-cluster -yn 1 -yjm 1024 -ytm 1024 -ys 1 -p 1 xz-flink-examples-1.0.jar • “run” 操作参数:
注意：client必须要设置YARN_CONF_DIR或者HADOOP_CONF_DIR环境变量，通过这个环境变量来读取YARN和HDFS的配置信息，否则启动会失败。 经试验发现，其实如果配置的有HADOOP_HOME环境变量的话也是可以的。HADOOP_HOME ，YARN_CONF_DIR，HADOOP_CONF_DIR 只要配置的有任何一个即可。 独立job模式客户端命令行参数参考： flink独立Job命令
Flink 的 YARN 客户端具有以下配置参数来控制容器故障时的行为方式。这些参数可以从 conf/flink-conf.yaml 中设置，或者在启动会话时使用-D参数设置 如：
参考： flink中文官网关于参数的解释
『拾』 基于flink sql构建实时数据仓库
根据目前大数据这一块的发展，已经不局限于离线的分析，挖掘数据潜在的价值，数据的时效性最近几年变得刚需，实时处理的框架有storm，spark-streaming，flink等。想要做到实时数据这个方案可行，需要考虑以下几点：1、状态机制 2、精确一次语义 3、高吞吐量 4、可弹性伸缩的应用 5、容错机制，刚好这几点，flink都完美的实现了，并且支持flink sql高级API，减少了开发成本，可用实现快速迭代，易维护等优点。 离线数仓的架构图： 实时数仓架构图: 目前是将实时维度表和DM层数据存于hbase当中，实时公共层都存于kafka当中，并且以写滚动日志的方式写入HDFS（主要是用于校验数据）。其实在这里可以做的工作还有很多，kafka集群，flink集群，hbase集群相互独立，这对整个实时数据仓库的稳定性带来一定的挑战。 一个数据仓库想要成体系，成资产，离不开数据域的划分。所以参考着离线的数据仓库，想着在实时数仓做出这方面的探索，理论上来讲，离线可以实现的，实时也是可以实现的。 并且目前已经取得了成效，目前划分的数据域跟离线大致相同，有流量域，交易域，营销域等等。当然这里面涉及到维表，多事务事实表，累计快照表，周期性快照表的设计，开发，到落地这里就不详述了。 维度表也是整个实时数据仓库不可或缺的部分。从目前整个实时数仓的建设来看，维度表有着数据量大，但是变更少的特点，我们试想过构建全平台的实时商品维度表或者是实时会员维度表，但是这类维度表太过于复杂，所以针对这类维度表下面介绍。还有另外一种就是较为简单的维度表，这类维度可能对应着业务系统单个mysql表，或者只需要几个表进行简单ETL就可以产出的表，这类维表是可以做成实时的。以下有几个实施的关键点： 如下是离线数据同步架构图： 实时数据的接入其实在底层架构是一样的，就是从kafka那边开始不一样，实时用flink的UDTF进行解析，而离线是定时（目前是小时级）用camus拉到HDFS，然后定时load HDFS的数据到hive表里面去，这样来实现离线数据的接入。实时数据的接入是用flink解析kafka的数据，然后在次写入kafka当中去。 由于目前离线数据已经稳定运行了很久，所以实时接入数据的校验可以对比离线数据，但是离线数据是小时级的hive数据，实时数据存于kafka当中，直接比较不了，所以做了相关处理，将kafka的数据使用flink写HDFS滚动日志的形式写入HDFS，然后建立hive表小时级定时去load HDFS中的文件，以此来获取实时数据。 完成以上两点，剩余还需要考虑一点，都是小时级的任务，这个时间卡点使用什么字段呢?首先要确定一点就是离线和实时任务卡点的时间字段必须是一致的，不然肯定会出问题。目前离线使用camus从kafka将数据拉到HDFS上，小时级任务，使用nginx_ts这个时间字段来卡点，这个字段是上报到nginx服务器上记录的时间点。而实时的数据接入是使用flink消费kafka的数据，在以滚动日志的形式写入HDFS的，然后在建立hive表load HDFS文件获取数据，虽然这个hive也是天/小时二级分区，但是离线的表是根据nginx_ts来卡点分区，但是实时的hive表是根据任务启动去load文件的时间点去区分的分区，这是有区别的，直接筛选分区和离线的数据进行对比，会存在部分差异，应当的做法是筛选范围分区，然后在筛选nginx_ts的区间，这样在跟离线做对比才是合理的。 目前实时数据接入层的主要时延是在UDTF函数解析上，实时的UDTF函数是根据上报的日志格式进行开发的，可以完成日志的解析功能。 解析流程图如下： 解析速率图如下： 该图还不是在峰值数据量的时候截的，目前以800记录/second为准，大概一个记录的解析速率为1.25ms。 目前该任务的flink资源配置核心数为1，假设解析速率为1.25ms一条记录，那么峰值只能处理800条/second，如果数据接入速率超过该值就需要增加核心数，保证解析速率。 介绍一下目前离线维度表的情况，就拿商品维度表来说，全线记录数将近一个亿，计算逻辑来自40-50个ods层的数据表，计算逻辑相当复杂，如果实时维度表也参考离线维度表来完成的话，那么开发成本和维护成本非常大，对于技术来讲也是很大的一个挑战，并且目前也没有需求要求维度属性百分百准确。所以目前（伪实时维度表）准备在当天24点产出，当天的维度表给第二天实时公共层使用，即T-1的模式。伪实时维度表的计算逻辑参考离线维度表，但是为了保障在24点之前产出，需要简化一下离线计算逻辑，并且去除一些不常用的字段，保障伪实时维度表可以较快产出。 实时维度表的计算流程图： 目前使用flink作为公司主流的实时计算引擎，使用内存作为状态后端，并且固定30s的间隔做checkpoint，使用HDFS作为checkpoint的存储组件。并且checkpoint也是作为任务restart以后恢复状态的重要依据。熟悉flink的人应该晓得，使用内存作为状态后端，这个内存是JVM的堆内存，毕竟是有限的东西，使用不得当，OOM是常有的事情，下面就介绍一下针对有限的内存，如果完成常规的计算。
