gitweixin
  • 首页
  • 小程序代码
    • 资讯读书
    • 工具类
    • O2O
    • 地图定位
    • 社交
    • 行业软件
    • 电商类
    • 互联网类
    • 企业类
    • UI控件
  • 大数据开发
    • Hadoop
    • Spark
    • Hbase
    • Elasticsearch
    • Kafka
    • Flink
    • 数据仓库
    • 数据挖掘
    • flume
    • Kafka
    • Hive
    • shardingsphere
    • solr
  • 开发博客
    • Android
    • php
    • python
    • 运维
    • 技术架构
    • 数据库
  • 程序员网赚
  • bug清单
  • 量化投资
  • 在线查询工具
    • 去行号
    • 在线时间戳转换工具
    • 免费图片批量修改尺寸在线工具
    • SVG转JPG在线工具

DataX DorisWriter 插件DorisWriterManager类详细解读

精品微信小程序开发门户,代码全部亲测可用

  • 首页   /  
  • 作者: east
  • ( 页面33 )
doris 8月 25,2023

DataX DorisWriter 插件DorisWriterManager类详细解读

DorisWriterManager 的类,用于将数据写入到 Doris 中。以下是代码的具体作用和功能解释:

  1. 导入必要的包和类: 代码开头导入了所需的包和类,包括日志记录、线程池、字符编码和其他相关工具类。
  2. 类成员变量定义: 下面是一些类的成员变量定义,这些变量在类的不同方法中使用:
    • LOG: 用于记录日志的 Logger 对象。
    • visitor: DorisStreamLoadObserver 类的实例,用于处理数据写入 Doris 的观察者。
    • options: Keys 类的实例,包含了一些配置选项。
    • buffer: 存储待写入 Doris 的数据。
    • batchCount: 当前批次中的记录数量。
    • batchSize: 当前批次中的数据大小。
    • closed: 标志位,表示是否已关闭写入。
    • flushException: 异步刷新数据时可能发生的异常。
    • flushQueue: 用于异步刷新数据的队列。
    • scheduler: 用于定期刷新数据的调度器。
    • scheduledFuture: 用于取消定时任务的句柄。
  3. 构造函数 DorisWriterManager: 构造函数接受一个 Keys 对象作为参数,设置了初始化的配置信息,并初始化了 visitor 和 flushQueue。接着,它调用 startScheduler() 启动定期刷新任务,以及 startAsyncFlushing() 启动异步刷新线程。
  4. startScheduler() 方法: 此方法负责启动定时刷新任务。它首先调用 stopScheduler() 停止之前的定时任务。然后,创建一个单线程的调度器(scheduler),并设置一个定时任务,定期触发数据刷新操作。在定时任务内部,它会检查是否关闭了写入操作,然后根据配置信息进行数据刷新。如果当前批次为空,重新启动定时任务,确保数据持续刷新。
  5. stopScheduler() 方法: 此方法用于停止定时任务。它会取消之前的定时任务并关闭调度器。
  6. writeRecord(String record) 方法: 该方法用于将记录写入缓冲区。它首先调用 checkFlushException() 方法检查是否存在刷新异常。然后,将记录转换成字节数组并添加到缓冲区中,同时更新批次计数和数据大小。如果当前批次的记录数量或数据大小超过了阈值,就会触发数据刷新。
  7. flush(String label, boolean waitUntilDone) 方法: 此方法用于手动触发数据刷新操作。它首先检查是否存在刷新异常,然后根据当前批次的情况决定是否执行刷新。如果当前批次为空,且 waitUntilDone 为真,它会等待之前的异步刷新操作完成。否则,它将当前批次的数据放入刷新队列,并根据 waitUntilDone 参数决定是否等待刷新操作完成。
  8. close() 方法: 此方法用于关闭 DorisWriterManager。它首先检查是否已经关闭,然后触发一次最终的数据刷新操作。如果当前批次有数据,会记录相应日志。最后,它检查是否有刷新异常并抛出相应异常。
  9. createBatchLabel() 方法: 此方法用于创建批次标签,用于标识一批数据。它根据配置的前缀和随机 UUID 生成标签。
  10. startAsyncFlushing() 方法: 此方法启动一个异步刷新线程。线程会循环调用 asyncFlush() 方法,将数据异步刷新到 Doris 中。
  11. waitAsyncFlushingDone() 方法: 该方法用于等待之前的异步刷新操作完成。它向刷新队列添加空的 WriterTuple,以确保之前的刷新操作完成。然后,它检查是否存在刷新异常。
  12. asyncFlush() 方法: 此方法用于异步刷新数据到 Doris。它从刷新队列中取出 WriterTuple,然后根据批次的标签执行数据刷新操作。如果发生异常,它会尝试多次,直到达到最大重试次数。如果需要重新创建批次标签,则生成新的标签。重试之间会休眠一段时间。成功后,重新启动定时任务。
  13. checkFlushException() 方法: 此方法用于检查是否存在刷新异常,如果存在则抛出异常。

这个 DorisWriterManager 类的目的是管理数据写入到 Doris 数据库的操作。它通过定时任务和异步刷新线程来控制数据的批量写入,同时处理异常情况,确保数据的稳定写入。

添加详细注释代码如下:

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.List;
import java.util.UUID;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingDeque;
import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledFuture;
import java.util.concurrent.TimeUnit;
import org.apache.commons.lang3.concurrent.BasicThreadFactory;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class DorisWriterManager {

    private static final Logger LOG = LoggerFactory.getLogger(DorisWriterManager.class);

    private final DorisStreamLoadObserver visitor;
    private final Keys options;
    private final List<byte[]> buffer = new ArrayList<>(); // 缓冲区,用于存储待写入 Doris 的数据
    private int batchCount = 0; // 当前批次中的记录数量
    private long batchSize = 0; // 当前批次中的数据大小
    private volatile boolean closed = false; // 标志位,表示是否已关闭
    private volatile Exception flushException; // 异步刷新数据时可能发生的异常
    private final LinkedBlockingDeque<WriterTuple> flushQueue; // 用于异步刷新数据的队列
    private ScheduledExecutorService scheduler; // 用于定期刷新数据的调度器
    private ScheduledFuture<?> scheduledFuture;

    public DorisWriterManager(Keys options) {
        this.options = options;
        this.visitor = new DorisStreamLoadObserver(options);
        flushQueue = new LinkedBlockingDeque<>(options.getFlushQueueLength());
        this.startScheduler(); // 启动定期刷新调度器
        this.startAsyncFlushing(); // 启动异步刷新线程
    }

    // 启动定期刷新调度器
    public void startScheduler() {
        stopScheduler(); // 停止之前的调度器
        this.scheduler = Executors.newScheduledThreadPool(1, new BasicThreadFactory.Builder()
                .namingPattern("Doris-interval-flush").daemon(true).build());
        this.scheduledFuture = this.scheduler.schedule(() -> {
            synchronized (DorisWriterManager.this) {
                if (!closed) {
                    try {
                        String label = createBatchLabel();
                        LOG.info(String.format("Doris interval Sinking triggered: label[%s].", label));
                        if (batchCount == 0) {
                            startScheduler(); // 如果当前批次为空,重新启动定时任务
                        }
                        flush(label, false);
                    } catch (Exception e) {
                        flushException = e;
                    }
                }
            }
        }, options.getFlushInterval(), TimeUnit.MILLISECONDS);
    }

    // 停止定期刷新调度器
    public void stopScheduler() {
        if (this.scheduledFuture != null) {
            scheduledFuture.cancel(false);
            this.scheduler.shutdown();
        }
    }

    // 写入一条记录到缓冲区
    public final synchronized void writeRecord(String record) throws IOException {
        checkFlushException(); // 检查是否有刷新异常
        try {
            byte[] bts = record.getBytes(StandardCharsets.UTF_8);
            buffer.add(bts);
            batchCount++;
            batchSize += bts.length;
            if (batchCount >= options.getBatchRows() || batchSize >= options.getBatchSize()) {
                String label = createBatchLabel();
                LOG.debug(String.format("Doris buffer Sinking triggered: rows[%d] label[%s].", batchCount, label));
                flush(label, false); // 当记录数量或数据大小超过阈值时触发刷新
            }
        } catch (Exception e) {
            throw new IOException("Writing records to Doris failed.", e);
        }
    }

    // 手动触发刷新缓冲区的数据
    public synchronized void flush(String label, boolean waitUntilDone) throws Exception {
        checkFlushException(); // 检查是否有刷新异常
        if (batchCount == 0) {
            if (waitUntilDone) {
                waitAsyncFlushingDone(); // 如果当前批次为空,等待之前的刷新操作完成
            }
            return;
        }
        flushQueue.put(new WriterTuple(label, batchSize, new ArrayList<>(buffer))); // 将数据放入刷新队列
        if (waitUntilDone) {
            waitAsyncFlushingDone(); // 等待刷新操作完成
        }
        buffer.clear();
        batchCount = 0;
        batchSize = 0;
    }

    // 关闭 DorisWriterManager,触发最后一次刷新操作
    public synchronized void close() {
        if (!closed) {
            closed = true;
            try {
                String label = createBatchLabel();
                if (batchCount > 0) LOG.debug(String.format("Doris Sink is about to close: label[%s].", label));
                flush(label, true); // 关闭时触发刷新操作
            } catch (Exception e) {
                throw new RuntimeException("Writing records to Doris failed.", e);
            }
        }
        checkFlushException();
    }

    // 创建批次标签,通常用于标识一批数据
    public String createBatchLabel() {
        StringBuilder sb = new StringBuilder();
        if (!Strings.isNullOrEmpty(options.getLabelPrefix())) {
            sb.append(options.getLabelPrefix());
        }
        return sb.append(UUID.randomUUID().toString()).toString();
    }

    // 启动异步刷新线程
    private void startAsyncFlushing() {
        Thread flushThread = new Thread(new Runnable() {
            public void run() {
                while (true) {
                    try {
                        asyncFlush(); // 异步刷新数据
                    } catch (Exception e) {
                        flushException = e;
                    }
                }
            }
        });
        flushThread.setDaemon(true);
        flushThread.start();
    }

    // 等待之前的刷新操作完成
    private void waitAsyncFlushingDone() throws InterruptedException {
        for (int i = 0; i <= options.getFlushQueueLength(); i++) {
            flushQueue.put(new WriterTuple("", 0L, null));
        }
        checkFlushException();
    }

    // 异步刷新数据到 Doris
    private void asyncFlush() throws Exception {
        WriterTuple flushData = flushQueue.take();
        if (Strings.isNullOrEmpty(flushData.getLabel())) {
            return;
        }
        stopScheduler(); // 停止定时任务
        LOG.debug(String.format("Async stream load: rows[%d] bytes[%d] label[%s].", flushData.getRows().size(), flushData.getBytes(), flushData.getLabel()));
        for (int i = 0; i <= options.getMaxRetries(); i++) {
            try {
                // 利用 DorisStreamLoadObserver 进行数据刷新
                visitor.streamLoad(flushData);
                LOG.info(String.format("Async stream load finished: label[%s].", flushData.getLabel()));
                startScheduler(); // 
     break;
            } catch (Exception e) {
                LOG.warn("Failed to flush batch data to Doris, retry times = {}", i, e);
                if (i >= options.getMaxRetries()) {
                    throw new IOException(e);
                }
                if (e instanceof DorisWriterExcetion && (( DorisWriterExcetion )e).needReCreateLabel()) {
                    String newLabel = createBatchLabel();
                    LOG.warn(String.format("Batch label changed from [%s] to [%s]", flushData.getLabel(), newLabel));
                    flushData.setLabel(newLabel);
                }
                try {
                    Thread.sleep(1000l * Math.min(i + 1, 10));
                } catch (InterruptedException ex) {
                    Thread.currentThread().interrupt();
                    throw new IOException("Unable to flush, interrupted while doing another attempt", e);
                }
            }
        }
    }

    private void checkFlushException() {
        if (flushException != null) {
            throw new RuntimeException("Writing records to Doris failed.", flushException);
        }
    }
}
作者 east
大数据开发 8月 24,2023

银行业数字化转型

大多数公司会愉快地谈论他们如何进行“数字化转型”。问高管这对他们的组织意味着什么,通常你会得到一份精心策划的词沙拉。这是因为在可以衡量之前,银行业的数字化转型是一个模糊的术语。数字部分相当简单。这是难以量化的变革方面。

推动数字化转型的是需要不断改进所有类别客户的用户体验。无论是零售银行客户、中小型商业实体、交易对手方,还是接受资金和金融服务的上市公司,他们都希望对每笔交易和查询做出比以往更好的高效和定制化响应。前一个。

对于一些公司来说,这是一个让自己脱颖而出并抢占更多市场份额的绝好机会,因为客户可以轻松地从一家供应商转移到另一家供应商。为了帮助读者踏上这段旅程,这篇文章强调了测量的概念,认为它是数字化转型中最实用、最可操作的方面之一。如果底层服务不处于持续优化的状态,客户体验就无法细化,无法衡量的东西就无法优化。

作为一个社会,我们已经从模拟转向数字。但从转型的角度来看,例如,通过传真机运行文档与扫描和通过电子邮件发送文档没有太大区别。这是因为您仍在分发相同的文档,尽管效率更高。

有人会认为机器人处理自动化 (RPA) 是将您推向数字化转型下一个领域的绝佳方式。但如果出于相同原因发送相同类型的文档,则情况并非如此,即使发送速度更快、规模更大。在这种情况下,您可以自豪地将运营效率添加到您的 LinkedIn 个人资料中,以及一系列节省成本和改进资源分配的好处。这是当之无愧的,因为它本身就是一个挑战,但它不是数字化转型。

那么什么是数字化转型?简单来说,就是将数字技术嵌入到业务运营的各个方面,从而导致思维、模式和行为发生变化(转变)。

这不仅仅是将技术应用于业务,因为公司已经这样做了几十年。数字化转型是对公司如何利用人工智能、机器学习和大数据等先进技术构建不断发展的自动化流程的根本性反思。自动化不再是人为驱动的任务,而是一个由人监督的自动化过程,其中每个决策和行动都是通过经验证据和对市场驱动事件的分析来精确确定的。

如果执行得当,就会启动新的业务模型,这些模型会应用从与越来越多的场景中越来越多的客户实时交互中获得的见解。

数字化转型的一个当代例子是汽车保险理赔处理。传统上,这是一项纸张密集型操作,遵循非常线性的检查和批准流程,一次一个文件。然而,对于一些创新型公司来说,它已经转变为一种低接触的全自动端到端流程。 “文书工作”不仅效率更高,而且处理索赔的方式也从根本上从成本控制功能转变为交叉销售和追加销售机会。理赔流程现在是一种方便的自助式体验,还可以建议额外的、定制的服务,这些服务与客户在那个时间点和地点的情绪状态完全相关。

为了满足客户的期望,该行业进行了数字化转型,这个例子在金融服务行业的所有领域都在发生。

早期的汽车保险应用程序允许客户拍摄事故照片,然后由具有多年经验的人手动查看。该人亲自审查了数千起事故的经验使他们能够仅通过查看图片来评估损失,从而得出成本估算。

在第一次变革迭代中,流程得到了技术的增强,而不是转变。但将数字图像上传到数据库的第一步为转型奠定了基础。多年来,同一家公司最终收集了大量数字化的汽车事故数据。通过将所有这些信息存储在大数据集群中,他们就有机会构建和训练复杂的人工智能模型。

一起运行这些模型的集合从而使完整的端到端索赔流程自动化,生成并确认您选择的车身修理厂的工作估算,将资金汇入适当的账户,并管理汽车租赁。一个漫长的高接触手动过程转变为具有实时操作和响应的低接触体验。这种便利会赢得客户的信任,并有更好的机会从他们那里获得更多的收入机会。

但这并不是银行业一夜之间的数字化转型。它经过多年酝酿,需要深入反思如何利用各自的技术应用开展业务。它也不是一个一次性的项目。随着越来越多的公司这样做,该流程需要不断优化和完善才能保持相关性。

虽然从客户的角度来看,上面的示例使它看起来很容易,但完全自动化和实时的流程是一项复杂的工作,需要利用许多公司内部领域的主题专业知识。这意味着您有多个团队在开发同一产品,每个团队同时采用多种技术和数据工作负载。一系列流程中任何时候的一个瓶颈都可能同时毁掉成千上万客户的整个体验。衡量高度复杂的相互依赖的工作负载的进展情况,并在持续实时的基础上优化各种环境中的每一次交互,对于数字化转型至关重要。

一切都必须考虑,从机器学习应用程序性能、网络延迟和第三方支付 API,到管理大量非结构化图像数据和大量其他类型的工作负载。它需要一组专门的软件工具来查看这些组件、生成指标并实时推荐最佳优化路径。

虽然客户满意度有很多变数,但性能和响应时间是客户感知用户体验的重要组成部分。使用上述类型的复杂系统来解决和管理客户期望是一场持久战。

作者 east
Spark 8月 24,2023

spark cacheTable的作用

DataFrame.sqlContext.cacheTable 是一种用于缓存 Spark DataFrame 中数据表的方法。它可以用来在内存中缓存数据,以提高查询性能和加速数据分析过程。

作用:

当你使用 DataFrame.sqlContext.cacheTable 方法缓存一个数据表时,Spark 会将该表的数据加载到内存中,以便在后续的查询和操作中快速访问数据,而不必每次都从磁盘读取。这可以带来以下好处:

  1. 加速查询性能: 缓存数据表可以显著提高查询性能,因为查询操作可以在内存中快速执行,而不需要再次访问磁盘。特别是对于复杂的查询或多次重复的查询,性能的提升会非常明显。
  2. 减少磁盘IO: 缓存表可以减少磁盘IO操作,从而减少整体的数据读取时间。这对于大规模数据集或需要频繁访问的数据表特别有用。
  3. 优化迭代计算: 在迭代计算中,如果同一数据表被多次使用,缓存该表可以避免重复加载和计算,加快迭代过程。
  4. 交互式分析: 在交互式分析环境中,缓存数据表可以让你更快地尝试不同的查询和分析操作,提高工作效率。

使用示例:

以下是一个示例,展示了如何使用 DataFrame.sqlContext.cacheTable 方法来缓存一个数据表:

python复制代码from pyspark.sql import SparkSession

# 创建 SparkSession
spark = SparkSession.builder.appName("CacheTableExample").getOrCreate()

# 读取数据并创建 DataFrame
data_df = spark.read.csv("data.csv", header=True, inferSchema=True)

# 缓存数据表
data_df.createOrReplaceTempView("my_cached_table")
spark.sql("CACHE TABLE my_cached_table")

# 执行查询
result = spark.sql("SELECT * FROM my_cached_table WHERE age > 25")

# 关闭 SparkSession
spark.stop()

在这个示例中,数据表 “my_cached_table” 被缓存到内存中,然后可以执行快速的查询操作。需要注意的是,缓存数据表会占用一定的内存空间,因此在内存有限的情况下,需要根据实际需求进行权衡和管理。同时,缓存的数据在某些情况下可能会被自动清除,例如当内存不足时。

作者 east
Spark 8月 23,2023

spark sql对表某个字段拆分成多条记录

需求:数据库某个表,有个字段area,里面有多个省份,用逗号分隔,例如”广东省,浙江省,北京市“,要求分隔成多条记录。

要使用Spark SQL对表中的某个字段根据逗号拆分成多条记录,你可以使用split()函数来实现。以下是具体的Scala代码示例:

scala复制代码import org.apache.spark.sql.functions._

// 假设你已经创建了一个SparkSession对象,命名为spark

// 加载原始数据作为DataFrame
val df = spark.read.format("csv").option("header", "true").load("path_to_your_file.csv")

// 使用split函数将目标字段拆分成多列,并使用explode函数将拆分后的数组转换成多行
val explodedDF = df.withColumn("split_col", split(col("your_column"), ",")) 
                   .selectExpr(df.columns: _*)
                   .withColumn("exploded_col", explode(col("split_col")))

// 显示处理后的结果
explodedDF.show()

你需要将代码中的以下部分进行替换以适应你的场景:

  • path_to_your_file.csv:指定你的CSV文件的路径。
  • your_column:要拆分的字段的名称。

这段代码会将指定字段按逗号拆分成多个记录,并把拆分后的记录显示在控制台上。你可以根据自己的需求进一步处理和操作拆分后的数据。

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east
Flink 8月 22,2023

Flink SQL 配方:窗口 Top-N 和连续 Top-N

Flink SQL 已成为低代码流分析的标准,并设法统一批处理和流处理,同时保持 SQL 标准。此外,它还提供了一组丰富的实时数据分析高级功能。简而言之,Flink SQL 是两全其美的:它使您能够使用 SQL 处理流数据,但它还支持批处理。

Ververica Platform 使 Flink SQL 更易于跨团队访问和高效扩展。该平台附带了用于开发 SQL 脚本、管理用户定义函数 (UDF)、目录和连接器以及操作生成的长时间运行查询的附加工具。

我们已经看到了 Flink SQL 的许多用例,我们很高兴向您展示你可以用它构建什么。在本系列博文中,我们将探讨如何使用 Flink SQL 以多种方式处理数据。这篇文章将特别关注两个查询:Window Top-N 和 Continuous Top-N。

提示:访问我们的案例研究,探索其他人如何使用 Apache Flink。

什么是 Window Top-N 和 Continuous Top-N 查询?

Window Top-N 和 Continuous Top-N 是两种相似但略有不同的数据处理方式。在这两种情况下,我们都希望找到数据流中的前 N 项,但存在一些关键差异:

在 Window Top-N 中,我们在固定大小的窗口中处理数据。例如,我们可能希望每分钟找到前 10 个项目。

在 Continuous Top-N 中,我们连续处理数据。我们不使用窗口,而是在数据到达时对其进行处理。连续 Top-N 比窗口 Top-N 更难实现,但它有一些优点。例如,它可以更快地为我们提供结果,因为我们不必等待窗口关闭才能看到结果。

窗口 Top-N 和连续 Top-N 查询的常见用例

窗口 Top-N 和连续 Top-N 查询对于各种任务都很有用。例如,它们可以用于:

  • 欺诈检测:在金融交易流中,我们可能希望找到每分钟按金额排名前 10 的交易。它可以帮助我们识别可疑活动。
  • 用户交互流:在用户交互流中,我们可能希望找到正在查看或购买的前 10 件商品。它可以帮助我们向用户提出建议。
  • 异常检测:在传感器读数流中,我们可能希望找到读数最高的前 10 个传感器。它可以帮助我们识别监控中出现故障的传感器。
  • 日志消息流:在日志消息流中,我们可能希望按数量查找前 10 条日志消息。它可以帮助我们识别系统问题。

如何使用 Flink SQL 编写 Window Top-N 查询

首先我们来看看如何使用 Flink SQL 编写 Window Top-N 查询。我们将向您展示如何计算每个翻滚 5 分钟窗口中销售额最高的前 3 名供应商。

sql复制代码
CREATE TABLE orders (
  bidtime TIMESTAMP(3),
  price DOUBLE,
  item STRING,
  supplier STRING,
  WATERMARK FOR bidtime AS bidtime - INTERVAL '5' SECONDS
) WITH (
  'connector' = 'faker',
  'fields.bidtime.expression' = '#{date.past ''30'',''SECONDS''}',
  'fields.price.expression' = '#{Number.randomDouble ''2'',''1'',''150''}',
  'fields.item.expression' = '#{Commerce.productName}',
  'fields.supplier.expression' = '#{regexify ''(Alice|Bob|Carol|Alex|Joe|James|Jane|Jack)''}',
  'rows-per-second' = '100'
);

SELECT *
FROM (
  SELECT *, ROW_NUMBER() OVER (PARTITION BY window_start, window_end ORDER BY price DESC) as rownum
  FROM (
    SELECT window_start, window_end, supplier, SUM(price) as price, COUNT(*) as cnt
    FROM TABLE(TUMBLE(TABLE orders, DESCRIPTOR(bidtime), INTERVAL '5' MINUTE))
    GROUP BY window_start, window_end, supplier
  )
) WHERE rownum <= 3;

源表(orders)由 thefaker 连接器支持,该连接器根据 Java Faker 表达式在内存中不断生成行。注意:此示例利用 Window Top-N 功能来显示排名前 3 的供应商每 5 分钟最高销售额。

如何使用 Flink SQL 编写连续 Top-N 查询

编写连续 Top-N 查询比编写 Window Top-N 查询更困难。这样做的原因是,在 Continuous Top-N 中,我们在数据到达时对其进行处理,而不是使用窗口。这个示例将带我们进入神奇的领域,因为流处理通常被外行认为是这样。然而,它实际上只是在数据流上执行的一组指令。

我们将展示如何使用 OVER window 和 ROW_NUMBER() 函数根据给定属性连续计算“Top-N”行。源表 (spells_cast) 由 thefaker 连接器支持,该连接器基于 Java Faker 在内存中连续生成行。

sql复制代码
CREATE TABLE spells_cast (
  wizard STRING,
  spell STRING
) WITH (
  'connector' = 'faker',
  'fields.wizard.expression' = '#{harry_potter.characters}',
  'fields.spell.expression' = '#{harry_potter.spells}'
);

SELECT wizard, spell, COUNT(*) AS times_cast
FROM spells_cast
GROUP BY wizard, spell;

此结果可以在 OVER 窗口中用于计算 Top-N。使用 wizard 列对行进行分区,然后根据施法次数(times_cast DESC)进行排序。内置函数 ROW_NUMBER() 根据排序顺序为每个分区的行分配序号。通过筛选序号小于等于 N 的行,我们可以获得每个巫师施法次数前 N 的法术。

以下是一个示例查询:

sql复制代码
SELECT wizard, spell, times_cast
FROM (
  SELECT wizard, spell, times_cast,
         ROW_NUMBER() OVER (PARTITION BY wizard ORDER BY times_cast DESC) AS row_num
  FROM (
    SELECT wizard, spell, COUNT(*) AS times_cast
    FROM spells_cast
    GROUP BY wizard, spell
  )
)
WHERE row_num <= 3;

在此查询中,我们首先计算每个巫师施法次数的统计信息。然后,我们在内部查询中使用 ROW_NUMBER() 函数对每个巫师的法术按照施法次数进行降序排列,为每个法术分配行号。最后,在外部查询中,我们筛选出行号小于等于 3 的记录,以获取每个巫师施法次数前 3 的法术。

这就是如何使用 Flink SQL 编写连续 Top-N 查询的方式。通过以上方法,您可以处理实时数据流并获取持续更新的 Top-N 数据。

请注意,上述示例中的 SQL 查询是根据您提供的上下文进行的翻译和还原,可能会因为特定上下文的变化而略有不同。

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east
python 8月 22,2023

python自动发文章到微信公众号4-群发消息

使用Python发送群发消息。具体的实现步骤如下:

  1. 导入必要的库:
pythonCopy Codeimport requests
  1. 构建请求的URL和参数:
pythonCopy Codeurl = "https://api.weixin.qq.com/cgi-bin/message/mass/sendall?access_token=ACCESS_TOKEN"

需要替换ACCESS_TOKEN为有效的访问令牌。

  1. 构建请求的数据,这里以发送图文消息为例:
pythonCopy Codedata = {
   "filter": {
      "is_to_all": False,
      "tag_id": 2
   },
   "mpnews": {
      "media_id": "123dsdajkasd231jhksad"
   },
   "msgtype": "mpnews",
   "send_ignore_reprint": 0
}

其中,filter用于设置接收者,mpnews用于设置即将发送的图文消息,media_id是需要群发的消息的媒体ID。

  1. 发送POST请求:
pythonCopy Coderesponse = requests.post(url, json=data)
  1. 处理响应:
pythonCopy Coderesult = response.json() if result["errcode"] == 0:     print("群发消息发送成功!")     print("消息ID:", result["msg_id"]) else:     print("群发消息发送失败,错误信息:", result["errmsg"])

微信API文档如下:


根据标签进行群发【订阅号与服务号认证后均可用】
接口调用请求说明
http请求方式: POST https://api.weixin.qq.com/cgi-bin/message/mass/sendall?access_token=ACCESS_TOKEN
POST数据示例如下:
图文消息(注意图文消息的media_id需要通过上述方法,或通过 “草稿箱 / 新建草稿” 接口来得到,海外微信公众号仅支持发送图文(mpnews)消息):
{ "filter":{ "is_to_all":false, "tag_id":2 }, "mpnews":{ "media_id":"123dsdajkasd231jhksad" }, "msgtype":"mpnews", "send_ignore_reprint":0 }


参数说明

参数是否必须说明
filter是用于设定图文消息的接收者
is_to_all否用于设定是否向全部用户发送,值为true或false,选择true该消息群发给所有用户,选择false可根据tag_id发送给指定群组的用户
tag_id否群发到的标签的tag_id,参见用户管理中用户分组接口,若is_to_all值为true,可不填写tag_id
mpnews是用于设定即将发送的图文消息
media_id是用于群发的消息的media_id
recommend否推荐语,不填则默认为“分享图片”
msgtype是群发的消息类型,图文消息为mpnews,文本消息为text,语音为voice,音乐为music,图片为image,视频为video,卡券为wxcard
title否消息的标题
description否消息的描述
thumb_media_id是视频缩略图的媒体ID
send_ignore_reprint是图文消息被判定为转载时,是否继续群发。 1为继续群发(转载),0为停止群发。 该参数默认为0。

返回说明

参数说明
type媒体文件类型,分别有图片(image)、语音(voice)、视频(video)和缩略图(thumb),图文消息为news
errcode错误码
errmsg错误信息
msg_id消息发送任务的ID
msg_data_id消息的数据ID,该字段只有在群发图文消息时,才会出现。可以用于在图文分析数据接口中,获取到对应的图文消息的数据,是图文分析数据接口中的msgid字段中的前半部分,详见图文分析数据接口中的msgid字段的介绍。

请注意:在返回成功时,意味着群发任务提交成功,并不意味着此时群发已经结束,所以,仍有可能在后续的发送过程中出现异常情况导致用户未收到消息,如消息有时会进行审核、服务器不稳定等。此外,群发任务一般需要较长的时间才能全部发送完毕,请耐心等待。

返回数据示例(正确时的JSON返回结果):

{
   "errcode":0,
   "errmsg":"send job submission success",
   "msg_id":34182, 
   "msg_data_id": 206227730
}

错误码

返回码含义
41040字数≥300字,才能声明文字原创

完整流程请看: 自动发文章到微信公众号

相关视频:
如何自动发表文章到微信公众号实现躺赚1-思路流程篇

代码拿走即用!如何自动发表文章到微信公众号实现躺赚实现篇

作者 east
Flink 8月 21,2023

磁盘对 Flink 中 RocksDB 状态后端的影响:案例研究

RocksDB 在 Flink 中的性能问题分析

正如最近的博客文章所述,RocksDB 是 Flink 中的一个状态后端,它允许作业的状态大于可用内存量,因为状态后端可以将状态溢出到本地磁盘。这意味着磁盘性能可能会对使用 RocksDB 的 Flink 作业的性能产生影响。通过一个案例研究,这篇博文说明了使用 RocksDB 的 Flink 作业的吞吐量下降问题,并演示了我们如何将底层磁盘的性能确定为根本原因。

背景和问题描述

我们正在处理一个典型的物联网 (IoT) 作业,该作业处理从数百万台设备发出的事件流。每个事件都包含设备标识符 (ID)、事件类型以及事件生成时的时间戳。该作业根据设备 ID 对流进行分区,并在状态中存储从每个事件类型到接收到该类型事件时的最新时间戳的映射。事件类型可能有数百种。对于每个传入事件,作业需要从接收事件类型的状态读取时间戳,并将其与传入事件进行比较。如果传入的时间戳较新,它会更新状态中存储的时间戳。

该作业在使用官方 AWS 命令​​行工具 eksctl 创建的 Amazon Elastic Kubernetes Service (EKS) 集群上运行,并具有所有默认设置。 Flink TaskManager 分配有 1.5 个 CPU 核和 4 GB 内存。该作业使用 RocksDB 状态后端,该后端配置为使用 Flink 的托管内存。state.backend.rocksdb.localdir 配置选项未显式设置,因此默认情况下底层 EC2 实例根卷上的 /tmp 目录用于 RocksDB 运行状态(即工作状态)。

吞吐量下降问题的观察

这篇博文指出,该作业最初在 EKS 上运行良好。但一段时间后(几小时或几天,具体取决于传入事件)作业吞吐量突然大幅下降。该下降可以很容易地再现。吞吐量指标图表显示,在某一天的 23:50 后不久,从每秒超过 10k 个事件下降到每秒几百个事件。此外,使用保存点停止作业然后从中恢复并没有帮助:重启后作业吞吐量仍然很低。尽管当作业从空状态重新启动时恢复了高吞吐量,但这不是一个选择,因为(1)作业状态会丢失,(2)作业吞吐量会在较短的时间后再次下降。

性能问题的定位

通过检查CPU指标,我们发现当吞吐量下降时,TaskManager 容器的 CPU 利用率也会降低。由于TaskManager容器可能会使用更多的CPU资源,因此CPU使用率的减少在这里只是一个症状。TaskManager容器的内存使用率在吞吐量下降之前很长时间就达到了分配限制,并且在 23:50 左右没有明显变化。

为了进一步调查性能问题,我们启用了 TaskManager 的 JMX 监控,并使用 VisualVM 进行 CPU 采样。结果显示,93% 的 CPU 时间都被 threadUpdateState 消耗了,这是运行 operatorUpdateState 的线程,该线程读取并更新 RocksDB 中的状态。几乎所有的CPU时间都被本机方法 org.rocksdb.RocksDB.get() 占用。这表明作业在从 RocksDB 读取状态时遇到了瓶颈。

磁盘性能分析

为了深入了解 RocksDB 的性能问题,我们启用了 Flink RocksDB 指标。块缓存是在内存中缓存数据以供读取的地方。块缓存在作业启动后的前几分钟内迅速被填满,主要是状态条目。然而,这并不能完全解释在 23:50 左右吞吐量下降的原因。

我们继续检查根卷的磁盘指标。读取吞吐量下降至每秒约 230 次,写入吞吐量也出现类似的下降。检查磁盘每秒输入/输出操作数 (IOPS) 容量,我们发现默认情况下,使用 eksctl 创建的 EKS 集群中的每个 EC2 实例都是 am5.large 实例,并带有一个通用 (gp2) 弹性块存储 (EBS) 根卷。根卷的大小为 80GB,提供 240 IOPS 的基准速率。这表明作业在磁盘 IO 上遇到了瓶颈。一开始能够实现更高 IOPS 的原因是 AWS 为每个 gp2 卷提供了初始 I/O 信用来维持突发 IO 请求。然而,初始 I/O 积分耗尽后,问题就出现了。

解决方案

为了解决性能问题,我们建议附加具有高 IOPS 率的专用卷,如 gp3 或 io1/io2 卷,并将 Flink 配置 state.backend.rocksdb.localdir 设置为该卷上的目录。需要注意的是,RocksDB 本机指标在默认情况下处于禁用状态,因为它们可能会对作业性能产生负面影响。但是在你面临性能问题时,启用这些指标可以帮助你更好地了解 RocksDB 的内部行为,以便更好地诊断和优化问题。

要实施这个解决方案,你可以按照以下步骤进行操作:

  1. 创建高性能的磁盘卷:
    • 使用 AWS 控制台或 AWS 命令行工具创建一个 gp3 或 io1/io2 卷,它提供足够的 IOPS 来支持你的作业需求。你可以根据作业的负载情况来选择适当的磁盘类型和大小。
  2. 将 RocksDB 目录配置到新卷上:
    • 在 Flink 配置中,将 state.backend.rocksdb.localdir 配置选项设置为新创建的高性能卷的挂载路径。这将使 RocksDB 在新卷上运行,并获得更高的磁盘性能。
  3. 启用 RocksDB 指标(可选):
    • 如果你想深入了解 RocksDB 的性能状况,你可以在 Flink 配置中启用 RocksDB 本机指标。这些指标将提供更多关于 RocksDB 内部运行情况的信息,帮助你更好地监视和优化作业。
  4. 重新部署作业:
    • 在进行了上述更改后,重新部署你的 Flink 作业。确保作业配置正确地指向新的 RocksDB 目录,并验证作业在新磁盘上运行。
  5. 监控和调整:
    • 监控你的作业性能,特别是 CPU 利用率、磁盘 IOPS 和延迟等指标。根据观察到的情况,你可能需要调整作业配置、磁盘类型或作业规模来进一步优化性能。

总之,通过将 RocksDB 目录配置到高性能的磁盘卷上,你可以显著改善 Flink 作业的性能,并避免在处理大量数据时出现吞吐量下降的问题。同时,启用 RocksDB 指标可以让你更深入地了解 RocksDB 在作业中的行为,从而更好地优化和监控作业性能。

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east
Flink 8月 21,2023

Flink SQL 连接 – 第 1 部分

Flink SQL 已成为低代码数据分析的事实标准。它成功地统一了批处理和流处理,同时保持了 SQL 标准。此外,它还为实时用例提供了一组丰富的高级功能。简而言之,Flink SQL 提供了两全其美的功能:它使您能够使用 SQL 处理流数据,但它还支持批处理。由于 Flink SQL 始终遵循 ANSI-SQL 2011 标准,因此所有功能都来自兼容的数据库应该管用。这包括内部联接和外部联接,以及 SQL 标准中描述的所有其他联接类型。

常规连接、间隔连接和查找连接

在这个由三部分组成的博客文章系列中,我们将向您展示 Flink SQL 中不同类型的联接以及如何使用它们以各种方式处理数据。这篇文章将重点介绍常规连接、间隔连接和查找连接。

常规连接

常规连接在 SQL 中用于组合两个或多个表中的数据。使用联接时,您可以指定每个表中要用于创建新表的列。您还可以使用联接来创建包含多个表中的数据的单个表。例如,如果您有一个包含客户信息的表和另一个包含订单信息的表,则可以使用联接创建一个同时包含客户信息和订单信息的表。

sql复制代码
CREATE TABLE NOC (
    agent_id STRING,
    codename STRING
);

CREATE TABLE RealNames (
    agent_id STRING,
    name STRING
);

SELECT
    name,
    codename
FROM NOC
INNER JOIN RealNames ON NOC.agent_id = RealNames.agent_id;

间隔连接

间隔连接用于比较相隔一定时间的两组数据。每组数据被分为多个区间,每个区间由开始时间和结束时间定义。间隔连接在处理具有时间上下文的事件时非常有用。例如,您可以将销售数据按小时间隔与客户数据按天间隔连接起来。

sql复制代码
CREATE TABLE orders (
    id INT,
    order_time TIMESTAMP
);

CREATE TABLE shipments (
    id INT,
    order_id INT,
    shipment_time TIMESTAMP
);

SELECT
    o.id AS order_id,
    o.order_time,
    s.shipment_time,
    TIMESTAMPDIFF(DAY, o.order_time, s.shipment_time) AS day_diff
FROM orders o
JOIN shipments s ON o.id = s.order_id
WHERE o.order_time BETWEEN s.shipment_time - INTERVAL '3' DAY AND s.shipment_time;

查找连接

查找连接用于在公共键上连接两个数据集,其中一个数据集是静态的,不会随时间变化。通过查找连接,您可以在流数据中丰富外部参考数据表中的信息。这对于实时数据分析非常有用。

sql复制代码
CREATE TABLE subscriptions (
    id STRING,
    user_id INT,
    type STRING,
    start_date TIMESTAMP,
    end_date TIMESTAMP,
    payment_expiration TIMESTAMP,
    proc_time AS PROCTIME()
);

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    username VARCHAR(255) NOT NULL,
    age INT NOT NULL
);

SELECT
    s.id AS subscription_id,
    s.type AS subscription_type,
    u.age,
    CASE WHEN u.age < 18 THEN 1 ELSE 0 END AS is_minor
FROM subscriptions s
JOIN users FOR SYSTEM_TIME AS OF s.proc_time AS u ON s.user_id = u.user_id;

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east
Flink 8月 21,2023

Flink SQL:使用 MATCH_RECOGNIZE 检测模式

Flink SQL 已成为低代码数据分析的事实上的标准。它成功地统一了批处理和流处理,同时保持了 SQL 标准。此外,它还为实时用例提供了一组丰富的高级功能。简而言之,Flink SQL 是两全其美的:它使您能够使用 SQL 处理流数据,但它还支持批处理。

Ververica Platform 使 Flink SQL 更易于跨团队访问和高效扩展。该平台附带了额外的工具,用于开发 SQL 脚本、管理用户定义函数 (UDF)、目录和连接器,以及操作生成的长时间运行的查询。

我们已经看到 Flink SQL 有很多用例,我们很兴奋看看您将用它构建什么。在这篇博文中,我们将向您展示 MATCH_RECOGNIZE 函数可以做什么。

什么是 MATCH_RECOGNIZE?

MATCH_RECOGNIZE 是 SQL 标准中的一个子句,允许您检测数据中的模式。它类似于许多编程语言中的正则表达式功能。MATCH_RECOGNIZE 允许您:

  • 定义模式
  • 根据这些模式匹配数据
  • 提取与模式匹配的数据部分
  • 对与模式匹配的数据执行操作

例如,您可以使用 MATCH_RECOGNIZE 查找所有表中代表股票价格趋势的行。然后,您可以提取与模式匹配的数据并对其执行进一步分析。

SQL 日常工作中的一个常见(但历史上很复杂)任务是识别数据集中有意义的事件序列 – 也称为复杂事件处理(CEP)。在处理流数据时,这一点变得更加重要,因为您希望对已知模式或不断变化的趋势做出快速反应,以提供最新的业务洞察。在 Flink SQL 中,您可以使用标准 SQL 子句 MATCH_RECOGNIZE 轻松执行此类任务。

如何使用 MATCH_RECOGNIZE 的示例

在此示例中,您将使用 Flink SQL 和 MATCH_RECOGNIZE 来查找从高级级别之一降级其服务订阅的用户( type IN (‘premium’,’platinum’)) 到基本层。完整的 Flink SQL 查询源表(订阅)由 thefaker 连接器支持,它基于 Java Faker 表达式在内存中不断生成行。

 
CREATE TABLE 订阅 (
    ID STRING,
    user ID INT,
    输入 STRING,
    开始日期 TIMESTAMP(3),
    结束日期 TIMESTAMP(3),
    payment_expiration TIMESTAMP(3),
    proc_time AS PROCTIME()
)
WITH (
    'connector' = 'faker',
    'fields.id.expression' = '#{Internet.uuid}',
    'fields.user_id.expression' = '#{number.numberBetween ''1'',''50''}',
    'fields.type.expression' = '#{regexify ''(basic|premium|platinum){1}''}',
    'fields.start_date.expression' = '#{date.past ''30'',''DAYS''}',
    'fields.end_date.expression' = '#{date.future ''15'',''DAYS''}',
    'fields.payment_expiration.expression' = '#{date.future ''365'',''DAYS''}'
);

SELECT *
FROM 订阅
MATCH_RECOGNIZE (
    PARTITION BY user ID
    ORDER BY proc_time
    MEASURES
        LAST(PREMIUM.type) AS premium_type,
        AVG(TIMESTAMPDIFF(DAY, PREMIUM.start_date, PREMIUM.end_date)) AS premium_avg_duration,
        BASIC.start_date AS downgrade_date
    AFTER MATCH SKIP TO LAST ROW
    PATTERN (PREMIUM+ BASIC)
    DEFINE
        PREMIUM AS PREMIUM.type IN ('premium', 'platinum'),
        BASIC AS BASIC.type = 'basic'
) AS MR;

MATCH_RECOGNIZE 的输入参数将是基于订阅的行模式表。第一步,必须对输入行模式表应用逻辑分区和排序,以确保事件处理正确且具有确定性:

 
PARTITION BY user ID
ORDER BY proc_time

然后在 MEASURES 子句中定义 ORDER BY proc_timeOutputRow 模式列,可以将其视为 MATCH_RECOGNIZE 的 SELECT。如果您有兴趣获取与降级之前的最后一个事件关联的高级订阅类型,可以使用逻辑偏移运算符 LAST 获取它。降级日期可以从任何现有高级订阅事件之后的第一个基本订阅事件的开始日期推断出来。AFTER MATCH SKIP 子句指定在非空之后模式匹配恢复的位置找到 y 匹配项。

sql复制代码
AFTER MATCH SKIP TO LAST ROW

模式定义模式在 PATTERN 子句中使用行模式变量(即事件类型)和正则表达式来指定。这些变量还必须使用 DEFINE 子句与事件必须满足才能包含在模式中的匹配条件相关联。在这里,您有兴趣匹配一个或多个高级订阅事件 (PREMIUM+),后跟基本订阅事件 (BASIC)。您可以使用正则表达式语法来定义模式的结构。在这个例子中,PREMIUM+ 表示一个或多个连续的高级订阅事件,而 BASIC 表示一个基本订阅事件。

在 MEASURES 子句中,您定义了要在匹配后提取的数据。在这个查询中,您从匹配的最后一个 PREMIUM 事件中提取高级订阅类型(premium_type),从所有匹配的 PREMIUM 事件中计算平均持续时间(premium_avg_duration),以及降级的日期(downgrade_date)。

最终的查询将返回按用户 ID 分区的每个用户的匹配结果。这些结果显示了每个用户从高级订阅降级到基本订阅的情况,以及有关此过程的相关信息。

 

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east
未分类 8月 19,2023

大数据云调查:企业如何释放其应用程序的全部潜力

查看我们的大数据云技术报告,了解完整故事。

云是一项令人兴奋的范式转换技术。它充满希望和潜力。从降低运营成本到简化业务流程再到创新产品周期,迁移到云对大多数现代组织来说都是一个极具吸引力的前景。

然而,在云中采用大数据并非没有挑战。迁移后的问题甚至困扰着最稳定和健全的企业。在许多情况下,这些挑战导致迁移结果不佳——甚至失败。

我们调查了 750 家企业,以确定他们如何在云中部署大数据工作负载、他们遇到的挑战以及他们寻求的解决方案。

云计算已成为业务增长和成功的关键支柱,大量企业将其关键流程和应用程序从本地模型迁移到云端就表明了这一点。到2022年底,全球90%以上的商业组织将采用大数据云技术,实施混合云战略。

Gartner 副总裁分析师 Mike Cisek 指出,云采用的一个主要驱动力是在减少支出的同时实现数字化转型。云计算即使不能消除,也能减少与硬件维护和维护相关的成本。

企业迁移到云端的关键流程之一是大数据。组织在云中存储、管理和分析他们的大数据,主要是因为云能够处理来自不同来源的大量原始信息。

这就是为什么可扩展性位居采用的首要驱动因素之列。企业可以扩展他们的云基础设施,以保持他们的大数据进程以最佳速度运行。大数据堆栈根据实时要求自动扩展或压缩其计算资源,确保工作负载平稳运行。

云计算通过控制不同的业务系统、统一运营孤岛和自动化时间密集型流程来推动业务敏捷性。有了大数据云流程,企业可以在不影响质量的情况下以最具成本效益的方式快速适应新流程。

这些是云中大数据技术最受吹捧的一些好处。然而,迁移到云端并利用大数据可能比看起来更棘手。

虽然大多数企业都希望在迁移到云后看到他们的运营成本大幅降低,但许多企业还是感到震惊。他们的云支出实际上已经超过了他们最初的预算。

如果云计算旨在降低成本,为什么 80% 的企业会过度分配云计算?

云支出增加的一个主要驱动因素是从资本支出向运营支出的转变。在资本支出模型中,预算很容易确定和分配。相比之下,随着运营需求的变化,OpEx 模型更加棘手,使企业难以定义他们的支出。无限的云资源和基于云的支出治理框架的缺失使组织很容易超支。

自动缩放已被宣传为一种减少云支出的方法,可确保云中的大数据堆栈在流量激增时拥有足够的资源。自动缩放的总体好处是消除了在流量激增时提供额外计算资源的手动干预。

但是,AWS 等云提供商设置的默认自动缩放配置可能会导致更多的云支出。在大多数情况下,云基础架构会根据峰值要求过度配置计算资源。虽然这种方法可以保证一旦流量增加就有可用的计算资源,但这也意味着在流量低于预期的事件期间浪费了大量资源。

如果无法了解云中的大数据堆栈,企业会发现很难全面优化其 IT 基础架构、快速发现问题、解决问题并减少停机时间。整体基础架构性能因此受到影响,导致他们无法满足其 SLA。

作者 east
Flink 8月 19,2023

Apache Flink 部署模式概述

Apache Flink 集群与在其上运行的 Flink 作业之间的关系可能相当灵活。Apache Flink 支持 Flink 作业的不同部署模式,使开发人员可以根据自己的需求和作业特定要求专注于使用适当的模式。

应用程序模式

在 Flink 1.11 中,社区在 Apache Flink 中引入了一种新的部署模式,即“应用程序模式”。Application Mode 是一种优化,旨在让 Flink 作业提交过程变得更加轻量级,特别是针对需要频繁提交多个 Flink 应用程序的情况。这种部署模式的主要目标是减少与本地下载应用程序依赖项相关的步骤和必要的带宽,执行 main() 方法来提取 Flink 运行时可以理解的应用程序表示(即 JobGraph)并传送依赖项和 JobGraph(s) 到集群。Application Mode 提供与 Per-Job 模式相同级别的隔离保证,建议用于生产环境。

Application Mode 为每个提交的应用程序创建一个集群,但这一次,应用程序的 main() 方法在 JobManager 上执行。虽然这种部署看起来与 Per-Job 模式(稍后描述)相对相似,但 Application Mode 允许更加灵活和轻量级的作业执行顺序,因为这不受部署模式的影响,而是受到用于启动应用程序的调用的影响。正在部署的作业(或作业包)。

有关 Apache Flink 中 Application Mode 的详细概述,可以参考这里的这篇博文。

会话模式

会话模式可能是 Flink 应用程序最简单的部署模式。会话模式下的集群是长期存在的,这意味着会话模式下的 Flink 作业将假设正在运行的集群已经存在,并将使用该集群的资源来执行任何提交的应用程序。在会话模式下,同一个集群执行多个作业,这意味着资源之间不存在隔离,因为集群中的所有任务管理器都是或可以共享的。使用会话模式,开发人员无需担心启动任务管理器的额外开销。为提交的 Flink 应用程序创建新集群,因为作业使用现有集群资源。

然而,在会话模式下,由于所有 Flink 应用程序共享同一集群的资源,因此行为不当的作业可能会导致整个集群瘫痪,并可能影响不相关的 Apache Flink 部署。出于同样的原因,在确保部署之间可靠的安全凭证隔离时,会话模式可能会带来额外的挑战。因此,我们建议会话模式最适合具有(相对)可预测行为的相对简单、较短的作业(例如执行简单的 FlinkSQL 查询)。

Per-Job 模式

最后一种模式是 Per-Job 模式。顾名思义,通过 Per-Job 模式,每个 Flink 应用程序都会获得一个隔离的集群,并在集群中保留资源。当 Flink 应用程序以 Per-Job 模式提交时,它将使用底层资源管理框架为每个提交的作业启动一个新集群。当 Flink 部署完成后,集群将变得不可用,并且所有资源或文件都将从集群中删除。

在 Per-Job 模式下,JobManager 监督单个作业的执行,而任何任务管理器进程都是专门专用的执行单个 .jar 文件。由于所有这些原因,Per-Job 模式提供了比会话模式(如上所述)更好的资源隔离保证。然而,与 Application 模式相比,Per-Job 模式在客户端非常繁重,可能会导致巨大的资源成本。因此,目前,Per-Job 模式唯一推荐的用例是当集群无法访问构建作业的依赖项而只有“客户端”可以时。

借助 Apache Flink 中提供的不同部署模式,开发人员可以灵活地以灵活的方式使用其底层资源管理框架(例如 YARN 或 Kubernetes),根据他们的需求和要求进行定制。有关 Apache Flink 可用部署模式的更多信息,您可以参考 Apache Flink® 官方文档。

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east
Flink 8月 19,2023

使用 Flink SQL 进行实时性能监控:AdTech 用例

背景

广告技术(Ad Tech)是一种统称,描述了用于管理和分析程序化广告活动的系统和工具。数字广告的目标是尽可能覆盖尽可能多的相关受众。因此,广告技术本质上与处理大量数据相关。

在这篇博文中,我们将研究如何关联两个事件流——广告投放(所谓的展示次数)和点击次数,并计算一个重要的广告技术指标——点击率(CTR)。我们的计算将使用 Apache Flink 的水平可扩展执行引擎根据运行中的数据进行。我们将专注于获得结果,而不用 Java 或 Scala 编写任何代码,而是完全依赖 SQL。

典型场景

在典型场景中,广告的投放是通过称为实时出价的机制执行的。从本质上讲,实时出价是一种拍卖,众多参与者竞相向特定最终用户展示横幅或视频(统称为创意)。在此过程中,需求方平台 (DSP) 获得向用户展示广告的服务,通过用户的设备 ID 进行识别并回复他们的投注。

 

虽然投放广告的过程在很大程度上是自动化的,但广告活动经理和业务分析师通常仍然采用很大程度的手动控制。通常,活动的定义和受众选择器(例如人口统计数据、原籍国以及活动的绩效标准)都是手动定义的。密切监视活动的表现并调整某些参数可能是必要的,特别是在发布后的早期阶段 – 验证假设的时间。

为什么选择流处理?

传统上,通过以下方式解决洞察大量数据的任务:利用批处理。这种方法与数字广告业务的高度动态性质相矛盾。实时获取洞察至关重要 – 等待一个小时或更长时间来完成定期批处理作业来完成原始数据的处理,同时由于活动的初始参数错误而耗尽预算,这是非常不可取的。此外,对于任何依赖于关联两个后续事件的指标,批处理不会为位于批处理“截止”相反两侧的事件提供正确的结果,因此会由两个不同的批处理作业进行处理。

为什么选择 Flink SQL?

监视活动的任务通常由数据分析师或业务分析师执行。由于业务的动态性质,可以预期与新数据源的潜在临时集成、向现有数据流添加新维度以及其他类似的调整。在这种情况下,希望消除数据分析师在执行日常任务时对数据工程师的依赖。为了实现这一目标,需要一个采用门槛较低的灵活工具集。 SQL 是数据分析的通用语言,其知识非常广泛。在 Flink 中运行 SQL 语句可以让您利用 Flink 水平可扩展流处理引擎的强大功能,而无需成为 Java 或 Scala 开发人员。它可以轻松地利用大量原始飞行数据,并以自助服务方式促进交互式自定义仪表板的创建。

实践

在我们的示例中,我们将使用两个数据流。首先,通过定义其架构和表选项,将这些流注册为表。第一个流是印象流。这些事件中的每一个都表明实时竞价拍卖的胜利以及成功向用户展示创意。它包含广告素材的维度、国家/地区代码和广告活动 ID 等详细信息。

创建临时表“印象数”

CREATE TEMPORARY TABLE impressions (
  bid_id VARCHAR NOT NULL,
  `timestamp` VARCHAR,
  serve_time AS TO_TIMESTAMP(`timestamp`, 'EEE MMM dd HH:mm:ss zzz yyyy'),
  campaign_id INT,
  creative_dimensions VARCHAR,
  country_code VARCHAR(2),
  serve_time AS serve_time - INTERVAL '5' SECOND
)
WITH (
  'connector' = 'kafka',
  'format' = 'json',
  'properties.bootstrap.servers' = 'kafka.svc:9092',
  'properties.group.id' = 'impressions

关注公众号“大模型全栈程序员”回复“大数据面试”获取800页左右大数据面试宝典 ,回复“大数据”获取多本大数据电子书

作者 east

上一 1 … 32 33 34 … 93 下一个

关注公众号“大模型全栈程序员”回复“小程序”获取1000个小程序打包源码。回复”chatgpt”获取免注册可用chatgpt。回复“大数据”获取多本大数据电子书

标签

AIGC AI创作 bert chatgpt github GPT-3 gpt3 GTP-3 hive mysql O2O tensorflow UI控件 不含后台 交流 共享经济 出行 图像 地图定位 外卖 多媒体 娱乐 小程序 布局 带后台完整项目 开源项目 搜索 支付 效率 教育 日历 机器学习 深度学习 物流 用户系统 电商 画图 画布(canvas) 社交 签到 联网 读书 资讯 阅读 预订

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 如何在Chrome中设置启动时自动打开多个默认网页
  • spark内存溢出怎样区分是软件还是代码原因
  • MQTT完全解析和实践
  • 解决运行Selenium报错:self.driver = webdriver.Chrome(service=service) TypeError: __init__() got an unexpected keyword argument ‘service’
  • python 3.6使用mysql-connector-python报错:SyntaxError: future feature annotations is not defined
  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?

文章归档

  • 2025年8月
  • 2025年7月
  • 2025年6月
  • 2025年5月
  • 2025年4月
  • 2025年3月
  • 2025年2月
  • 2025年1月
  • 2024年12月
  • 2024年11月
  • 2024年10月
  • 2024年9月
  • 2024年8月
  • 2024年7月
  • 2024年6月
  • 2024年5月
  • 2024年4月
  • 2024年3月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年8月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年4月
  • 2023年3月
  • 2023年1月
  • 2022年11月
  • 2022年10月
  • 2022年9月
  • 2022年8月
  • 2022年7月
  • 2022年6月
  • 2022年5月
  • 2022年4月
  • 2022年3月
  • 2022年2月
  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年9月
  • 2021年8月
  • 2021年7月
  • 2021年6月
  • 2021年5月
  • 2021年4月
  • 2021年3月
  • 2021年2月
  • 2021年1月
  • 2020年12月
  • 2020年11月
  • 2020年10月
  • 2020年9月
  • 2020年8月
  • 2020年7月
  • 2020年6月
  • 2020年5月
  • 2020年4月
  • 2020年3月
  • 2020年2月
  • 2020年1月
  • 2019年7月
  • 2019年6月
  • 2019年5月
  • 2019年4月
  • 2019年3月
  • 2019年2月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月

分类目录

  • Android (73)
  • bug清单 (79)
  • C++ (34)
  • Fuchsia (15)
  • php (4)
  • python (45)
  • sklearn (1)
  • 云计算 (20)
  • 人工智能 (61)
    • chatgpt (21)
      • 提示词 (6)
    • Keras (1)
    • Tensorflow (3)
    • 大模型 (1)
    • 智能体 (4)
    • 深度学习 (14)
  • 储能 (44)
  • 前端 (5)
  • 大数据开发 (493)
    • CDH (6)
    • datax (4)
    • doris (31)
    • Elasticsearch (15)
    • Flink (79)
    • flume (7)
    • Hadoop (19)
    • Hbase (23)
    • Hive (41)
    • Impala (2)
    • Java (71)
    • Kafka (10)
    • neo4j (5)
    • shardingsphere (6)
    • solr (5)
    • Spark (100)
    • spring (11)
    • 数据仓库 (9)
    • 数据挖掘 (7)
    • 海豚调度器 (10)
    • 运维 (35)
      • Docker (3)
  • 小游戏代码 (1)
  • 小程序代码 (139)
    • O2O (16)
    • UI控件 (5)
    • 互联网类 (23)
    • 企业类 (6)
    • 地图定位 (9)
    • 多媒体 (6)
    • 工具类 (25)
    • 电商类 (22)
    • 社交 (7)
    • 行业软件 (7)
    • 资讯读书 (11)
  • 嵌入式 (71)
    • autosar (63)
    • RTOS (1)
    • 总线 (1)
  • 开发博客 (16)
    • Harmony (9)
  • 技术架构 (6)
  • 数据库 (32)
    • mongodb (1)
    • mysql (13)
    • pgsql (2)
    • redis (1)
    • tdengine (4)
  • 未分类 (7)
  • 程序员网赚 (20)
    • 广告联盟 (3)
    • 私域流量 (5)
    • 自媒体 (5)
  • 量化投资 (4)
  • 面试 (14)

功能

  • 登录
  • 文章RSS
  • 评论RSS
  • WordPress.org

All Rights Reserved by Gitweixin.本站收集网友上传代码, 如有侵犯版权,请发邮件联系yiyuyos@gmail.com删除.