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

月度归档8月 2023

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

  • 首页   /  2023   /  
  • 8月
  • ( 页面2 )
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
Flink 8月 19,2023

英特尔在 Flink Forward 上展示分布式模型推理平台

Flink Forward 全球虚拟会议 2020 将于下个月拉开帷幕,届时 Flink 社区将探讨流处理和 Apache Flink 的未来。此次会议免费参加,时间为 2020 年 10 月 21 日至 22 日。另外,组织者还将于 10 月 19 日至 20 日举办六场由讲师指导的实践培训课程,内容涵盖了 Apache Flink 的多个方面,具体包括:

  • Flink 开发(2 天)
  • SQL 开发(2 天)
  • 运行时和操作(1 天)
  • 有状态函数(1 天)
  • 调优和故障排除(简介和高级,各 1 天)

我们有幸能够展示英特尔团队如何在 Intel Analytics Zoo 内的 Cluster Serving 服务中利用 Apache Flink。请仔细阅读我们的 Flink Forward 会议,并了解集群服务:在 Analytics Zoo 中使用 Apache Flink 进行分布式模型推理,时间为 2020 年 10 月 21 日。如果您尚未注册,请务必在 10 月 1 日之前完成注册,确保您的席位,并准备好聆听来自不同行业、公司规模和地点的公司代表就最新技术发展和 Flink 用例进行的一些有趣演讲!

集群服务:在 Analytics Zoo 中使用 Apache Flink 进行分布式模型推理

随着深度学习项目从实验发展到生产阶段,部署深度学习模型以进行大规模实时分布式推理的需求日益增长。尽管有许多可用工具可用于不同任务,如模型优化、模型服务、集群调度、集群管理等,但深度学习工程师和科学家仍然面临部署和管理分布式推理工作流程的挑战性过程,这些工作流程可以扩展到以直观和透明的方式实现大型集群。

在我们的会议中,我们将讨论以下内容:我们将介绍成功交付模型服务的两个主要领域,即大数据与机器学习的结合。一旦模型训练完成,为模型提供直观的服务成为构建机器学习管道的关键任务。在模型服务场景中,我们关注两个主要基准,即延迟和吞吐量。为满足机器学习管道中对极低延迟模型服务的需求,我们开发了 Cluster Serving:Intel Analytics Zoo 内的自动分布式服务解决方案。Cluster Serving 利用 Flink 的流处理运行时及其低延迟的连续处理引擎。此外,为满足高吞吐量需求,Cluster Serving 在 Flink 的统一数据处理引擎中实现了批处理。此外,集群服务还支持多种深度学习模型,包括 TensorFlow、PyTorch、Caffe、BigDL 和 OpenVINO。我们的模型服务解决方案提供了简单的发布-订阅(pub/sub)API,允许用户使用简单的 Python 或 HTTP API 轻松将推理请求发送到输入队列。

在我们的会议中,我们将介绍集群服务及其架构设计给 Flink Forward 的观众,并讨论将深度学习模型部署和管理到分布式、大数据和统一数据处理引擎中的底层设计模式和权衡。我们还将展示一些已经采用 Cluster Serving 来开发和部署分布式推理工作流程的用户实际用例、经验和示例。

您将在我们的会议中学到:

  • Cluster Serving 在 Apache Flink 的实现设计及其核心特性
  • 并行化昂贵操作
  • 使用消息队列等数据管道作为并行源
  • 最大限度地减少机器学习管道中的数据传输

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

作者 east
CDH 8月 17,2023

如何在CDH的Yarn配置中增加内存

在CDH集群中,您可以通过以下步骤来增加YARN的内存配置,以满足运行Spark任务所需的内存需求:

  1. 登录到CDH管理界面(Cloudera Manager)。
  2. 导航至 “YARN” 服务配置页面。
  3. 在 “Configuration” 选项卡下,找到 “ResourceManager” 部分。
  4. 在 “ResourceManager Java Configuration Options” 配置项中,找到或添加以下属性(如果已存在,请更新其值):
    • yarn.nodemanager.resource.memory-mb: 这是每个节点管理器(NodeManager)可用于YARN任务的最大内存量。您可以将其增加以提供更多内存。例如,将其设置为较大的值,如 8192 表示每个节点管理器可用的最大内存为8GB。
    • yarn.scheduler.maximum-allocation-mb: 这是单个YARN任务的最大内存分配量。同样,您可以将其增加以允许更大的任务内存。例如,将其设置为 4096 表示单个任务最多可以使用4GB的内存。
  5. 确保在同一配置页面的 “Resource Management” 部分中检查以下属性:
    • yarn.nodemanager.vmem-check-enabled: 确保此属性设置为 false,以禁用虚拟内存检查,以避免不必要的内存限制。
  6. 完成配置更改后,点击 “Save Changes”(保存更改)。
  7. 在 Cloudera Manager 中,重启 YARN 服务,以便使更改生效。

请注意,这些设置的具体值应根据您的集群硬件配置、可用内存和Spark任务的需求进行调整。增加内存分配可能会影响集群中其他服务的可用性,因此请谨慎调整。

在进行任何更改之前,建议您备份现有配置,以便在需要时可以恢复到先前的状态。同时,确保监控集群资源使用情况,以便及时调整配置以满足不同任务的需求。

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

作者 east

上一 1 2 3 4 下一个

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

标签

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

官方QQ群

小程序开发群:74052405

大数据开发群: 952493060

近期文章

  • 详解Python当中的pip常用命令
  • AUTOSAR如何在多个供应商交付的配置中避免ARXML不兼容?
  • C++thread pool(线程池)设计应关注哪些扩展性问题?
  • 各类MCAL(Microcontroller Abstraction Layer)如何与AUTOSAR工具链解耦?
  • 如何设计AUTOSAR中的“域控制器”以支持未来扩展?
  • C++ 中避免悬挂引用的企业策略有哪些?
  • 嵌入式电机:如何在低速和高负载状态下保持FOC(Field-Oriented Control)算法的电流控制稳定?
  • C++如何在插件式架构中使用反射实现模块隔离?
  • C++如何追踪内存泄漏(valgrind/ASan等)并定位到业务代码?
  • C++大型系统中如何组织头文件和依赖树?

文章归档

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

功能

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

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