开发者社区官方技术圈

阿里云开发者社区官方技术圈,用户产品功能发布、用户反馈收集等。

阿里云开发者社区官方技术圈,用户产品功能发布、用户反馈收集等。

“Quick引擎”是Quick BI产品自研的计算内核,该引擎的搭建旨在解决大数据的场景下已制作完毕的报表以及分析人员做交互式分析时计算缓慢的问题。“Quick引擎”架构在“数据源”和“数据集”两个模块中间,用来处理上层数据作品发送到数据集最终下放到数据源上的查询,在技术实现上Quick引擎分为五条链路,数据库直连、数据库实时加速模式、数据库抽取模式、智能缓存以及维值加速,在这五条链路进行了技术层抽象。

直连模式:默认的数据结果计算方式,计算负载直接跑在连接到BI产品的数据库或数仓上,非常适用于底层计算资源满足查询负载或小数据量的分析场景。

实时加速:基于阿里云DLA(Data Lake Analysis)内存计算引擎,查询时实时从用户数据库取数据,中间用DLA内存引擎加速计算,专业版用户可用,默认提供12C48G的容量,目前支持阿里云MaxCompute数仓,非常适合Max Compute数仓的实时分析。

抽取加速:把用户数据库或数仓的数据抽取到Quick引擎的高性能列式存储引擎中,支持全量模式和增量模式,分析计算负载直接跑在Quick引擎中,充分利用Quick引擎性能的同时,减少用户数仓的负担,非常适用于企业没有独立数仓或高峰时期数仓负载过重导致资源争抢时报表查询或订阅推送延迟的情况。

智能缓存:应用端报表、仪表板在访问时临时查询结果会被缓存下来,在配置的缓存有效时间内,接下来其他用户相同的查询直接取缓存结果,加快返回速度同时避免重复计算的资源消耗,非常适合应用端是重复查询较多的场景,例如高频使用报表的可视化展示类。

维值加速:通过将高频耗时的维度字段查询下放到数据库维表而不是当前待分析的明细表来查询以提高返回速度和节省计算资源。适合使用频率较高的例如分公司、渠道等维度字段。

以上内容摘自《企业级云原生白皮书项目实战》电子书,点击https://developer.aliyun.com/ebook/download/7774可下载完整版

胡嘞嘞 评论 0

Quick BI同时提供报表的订阅和业务指标的监控推送服务作为数据应用与消费的一种方式。日度月度更新的仪表盘以及定期报送的电子表格可以通过订阅功能定时推送,并且携带所需要的数据附件和报表链接。而业务侧的指标也可以通过指标监控的方式设置并及时发现异常,主动推送提示。 订阅任务设定与下发是传统BI应用于数据下发的核心功能。

在新建订阅任务时,可以自定义任务主题,选择需求所对应的仪表盘或者电子表格,同时在发送内容中选择是否包含数据附件,并按照每小时、每日、每周等业务周期,设定发送时间,最后选择需要接收该分析报表的用户和用户组即可完成订阅任务的设定。

订阅任务将在指定的时间根据报表的默认配置(查询控件,过滤器等)进行数据的查询和维度的聚合,并将报表截图,报表链接以及数据附件(如勾选)发送至指定联系人绑定的邮箱来达到数据下发分析和报送的目的。

数据指标监控与告警作为新型的数据应用与消费的方式,在Quick BI企业用户的使用中非常频繁,常被用于检测诸如指标的异常波动亦或是非预期内数据量的增长。

指标监控告警的新建需要经从报表进入,选择指定维度和聚合度量的图表,在图表选项中选择指标监控进行设置。在设置面板中,可以在左侧按需添加1至10条“监控规则”,每条“监控规则”都可以设置一个监控度量和5个监控维度,在设置了周期性检测时间后,需要精细化的配置告警条件,告警条件包含针对当前度量值以及日、月等周期的同、环比的值进行各种范围或不等比较,同时也可以勾选“智能告警”,由系统内置的神经网络-异常值检测算法判断异常指标,最后在配置告警接收方式和接收人后完成指指标监控告警的设置。

指标监控告警任务会根据设定的检测时间对拆解维度下指标的按照告警条件进行判断,如果触发了告警条件则会按照告警方式推送到用户侧,并将拆解指标的条件、具体值、触发告警的原因以及报表的链接推送到邮件中,用以及时发现指标或者数据的异常,从而快速知悉并针对性的给出相关的解决方案。

以上内容摘自《企业级云原生白皮书项目实战》电子书,点击https://developer.aliyun.com/ebook/download/7774可下载完整版

胡嘞嘞 评论 0

1

回答

image.png

电子表格制作报表的整体流程与仪表盘相似,额外功能与传统Excel的功能相近,当我们创建一个新的电子表格后,可以看到如上图所示,工作区整体分为4大部分。

1.最上方的是工具栏部分,这部分的图标以及功能和Excel中的大体相同,仅在右侧添加了“查询控件”以及“插入数据集”。“查询控件”作用于整个“电子表格”,可以根据需要对指定的维度进行筛选;“插入数据集”与“仪表盘”中的“交叉表”相同,可以将指定维度下的度量进行聚合或者展示非聚合的明细数据。

2.中间较大的区域为数据表的创作区。最上方为筛选控件和查询按钮,可以对插入电子表格的数据集进行指定维度和区间范围的筛选;下方的表格区域与Excel一致,每个表格都可以进行手动的数据编辑,也可以插入构建好的数据模型中的数据集,并且根据需要配置表格的条件样式用于下载和展示;同时,电子表格也支持Excel的各种函数,帮助您自动化的完成一些指标的统计和判断。

3.最下方为多sheet页签,当您使用的版本为专业版时,可以创建多个sheet页,结合自动更新的数据集和配置好的公式轻松的输出一份多维度的报表。

4.右侧的数据面板和仪表盘中的功能及使用方式一致。在面板中可以根据自己的业务切换所需要的数据集,并且以指定的维度展示到表格中的任意位置。

以上内容摘自《企业级云原生白皮书项目实战》电子书,点击https://developer.aliyun.com/ebook/download/7774可下载完整版

胡嘞嘞 评论 0

当Flink的任务出现checkpoint失败的时候,一般不会导致任务直接失败,但是checkpoint的失败会导致用户异常重启的时候无法从最近的checkpoint记录来恢复,会导致任务只能从最初的时间点或者是savepoint来进行恢复,可能会导致下游数据的重复,以及数均延迟增大,所以正常的checkpoint增量生成是flink任务健康度的体现,如下图是一个checkpoint生成失败的情况。

image.png

由上图可以看到,当前该任务是一直存在生成checkpoint失败的情况,Checkpoint 失败大致分为两种情况:Checkpoint Decline 和 Checkpoint Expire,此种情况经过分析后是 Checkpoint Expire的情况。

(1) Checkpoint Expire导致的Checkpoint失败

如果 Checkpoint 做的非常慢,超过了 timeout 还没有完成,则整个 Checkpoint 也会失败。当一个 Checkpoint 由于超时而失败是,会在 jobmanager.log 中看到如下的日志,同时也可以通过作业参数execution.checkpointing.interval 设置做Checkpoint的间隔时间。具体的JM日志可以发现如下

Checkpoint 1 of job 78d268e6fbc19411185f7e4868a44178 expired before completing.

表示 Chekpoint 1 由于超时而失败,这个时候可以可以看这个日志后面是否有类似下

面的日志:

Received late message for now expired checkpoint attempt 1 from 0b60f08bf3793875b59f8d9bc74ce2e1 of job 78d268e6fbc194111c

如果任务开启了debug日志,我们按照下面的日志把 TM 端的 snapshot 分为三个阶段,开始做 snapshot 前,同步阶段,异步阶段:

DEBUGStarting checkpoint (604) CHECKPOINT on task taskNameWithSubtasks

(4/4)

这个日志表示 TM 端 barrier 对齐后,准备开始做 Checkpoint。

DEBUG2019-08-06 13:43:02,613 DEBUG org.apache.flink.runtime.state.AbstractSnapshotStrategy - DefaultOperatorStateBackend snapshot (FsCheckpointStorageLocation {fileSystem=org.apache.flink.core.fs.SafetyNetWrapperFileSystem@70442baf, checkpointDirectory=xxxxxxxx, sharedStateDirectory=xxxxxxxx, taskOwnedStateDirectory=xxxxxx, metadataFilePath=xxxxxx, reference=(default), fileStateSizeThreshold=1024}, synchronous part) in thread Thread[Async calls on Source: xxxxxx_source -> Filter (27/70),5,Flink Task Threads] took 0 ms.

上面的日志表示当前这个 backend 的同步阶段完成,共使用了 0 ms。

DEBUGDefaultOperatorStateBackend snapshot (FsCheckpointStorageLocation {fileSystem=org.apache.flink.core.fs.SafetyNet- WrapperFileSystem@7908affe, checkpointDirectory=xxxxxx, sharedStateDirectory=xxxxx, taskOwnedStateDirectory=xxxxx, metadataFilePath= xxxxxx, reference=(default), fileStateSizeThreshold=1024}, asynchronous part) in thread Thread[pool-48-thread-14,5,Flink Task Threads] took 369 m

上面的日志表示异步阶段完成,异步阶段使用了 369 ms。

在现有的日志情况下,我们通过上面三个日志,定位 snapshot 是开始晚,同步阶段做的慢,还是异步阶段做的慢,然后再按照情况继续进一步排查flink任务情况,比如是否任务是否出现反压,任务数据量如何生生成的checkpoint大小等情况。"

以上内容摘自《企业级云原生白皮书项目实战》电子书,点击https://developer.aliyun.com/ebook/download/7774可下载完整版

胡嘞嘞 评论 0

当 checkpoint coordinator(job manager 的一部分)指示 task manager 开始checkpoint 时,它会让所有 sources 记录它们的偏移量,并将编号的 checkpointbarriers 插入到它们的流中。这些 barriers 流经 job graph,标注每个checkpoint 前后的流部分。Checkpoint n将包含每个 operator 的 state,这些 state 是对应的operator 消费了在 checkpoint barrier n之前的所有事件,当 job graph 中的每个operator 接收到 barriers 时,它就会记录下其状态。拥有两个输入流的 Operators(例如 CoProcessFunction)会执行 barrier 对齐(barrier alignment) 以便当前快照能够包含消费两个输入流 barrier 之前(但不超过)的所有 events 而产生的状态。

image.png

Flink 的 state backends 利用写时复制(copy-on-write)机制允许当异步生成旧版本的状态快照时,能够不受影响地继续流处理。只有当快照被持久保存后,这些旧版本的状态才会被当做垃圾回收。整体流程:

•JM trigger checkpoint

•Source 收到 trigger checkpoint 的 PRC,开始做 snapshot,并往下游发送barrier

•下游接收 barrier(需要 barrier 都到齐才会开始做checkpoint)

•Task 开始同步阶段 snapshot

•Task 开始异步阶段 snapshot

•Task snapshot 完成,汇报给 JM

以上内容摘自《企业级云原生白皮书项目实战》电子书,点击https://developer.aliyun.com/ebook/download/7774可下载完整版

胡嘞嘞 评论 0

定位到反压节点后,分析造成原因的办法要结合出现反压时候实际现场情况来进行分析,主要的情况主要包含有如下的情况,包含数据倾斜,资源不足数据突增,代码性能问题,节点TM的GC问题,下游的数据源性能问题。

数据倾斜:通过 Web UI 各个 SubTask 的 Records Sent 和 Records Received 来确认,另外,还可以通过 Checkpoint detail 里不同的 SubTask 的 State Size 来判断是否数据倾斜。

代码问题:最有用的办法就是对 TaskManager 进行 CPU profile,从中我们可以分析到 Task Thread 是否跑满一个 CPU 核:如果是的话要分析 CPU 主要花费在哪些函数里面,比如我们生产环境中就偶尔遇到卡在 Regex 的用户函数(ReDoS);如果不是的话要看 Task Thread 阻塞在哪里,可能是用户函数本身有些同步的调用,可能是 checkpoint 或者 GC 等系统活动导致的暂时系统暂停。目前flink版本提供了火焰图的来分析CPU的性能瓶颈。

image.png

GC 问题分析:包括 TaskManager JVM 各区内存不合理导致的频繁 Full GC 甚至失联。推荐可以通过给 TaskManager 启用 G1 垃圾回收器来优化 GC,并加上 -XX-:+PrintGCDetails 来打印 GC 日志的方式来观察 GC 的问题。通过 GC 日志,分析出单个 Flink TaskManager 堆总大小、年轻代、老年代分配的内存空间,Full GC 后老年代剩余大小等。

image.png

数据突增资源不足:这种情况下场景一般是任务运行正常一段时间后,上游数据量出现增大的情况,导致消耗节点大量的CPU或者内存(特别是join节点)从而形成了反压,这种情况可以通过手动调大节点资源或者是使用自动调优。

image.png

下游的数据源性能:在发现Sink 端写入性能较差,sink的上游节点出现反压情况,需要结合sink的数据端性能情况是否存在问题需要提升。"

以上内容摘自《企业级云原生白皮书项目实战》电子书,点击https://developer.aliyun.com/ebook/download/7774可下载完整版

胡嘞嘞 评论 0

公告

阿里云开发者社区官方技术圈,用户产品功能发布、用户反馈收集等。

展开