2017 年 Google 在论文《Attention Is All You Need》中提出 Transformer 模型架构，该架构是基于 Encoder-Decoder （编码器-解码器）的架构。作为当下最先进的深度学习架构之一，Transformer 被广泛应用于自然语言处理领域，它不仅替代了以前流行的循环神经网络（RNN）和长短期记忆网络（LSTM），而且后来的 BERT、GPT-3 等网络架构也是基于 Transformer 架构演化而来。 RNN 和 LSTM 已经在时序任务方面有了广泛的的应用，例如像文本预测、机器翻译、文章生成等等，但是这些应用都面临着如何记录长期依赖的问题，而使用 Transformer 架构就能解决这类问题。 自注意力（Self-Attention） Transformer 架构的核心主要是基于自注意力机制（Self-Attention），在详解 Transformer 架构之前，我们有必要理解一下自注意力这个概念，我们以《BERT 基础教程：Transformer 大模型实战》这本书的讲解来概述，这本书中的讲解非常浅显易懂。 给定一个英文句子： A dog ate the food because it was hungry. 句子中的代词 it 可能代表句子里的名词 food 或者 dog，虽然我们人类非
按作者浏览文章: Yanjun
开源对话模型 ChatGLM2-6B 安装部署与微调实践
ChatGLM2-6B 是清华大学KEG和数据挖掘小组(THUDM)开源中英双语对话模型，这个模型能够实现低门槛部署，对话流畅，并且非常方便研究和探索下游应用场景。具体介绍，我们引用官网的详细介绍，如下所示： 更强大的性能：基于 ChatGLM 初代模型的开发经验，我们全面升级了 ChatGLM2-6B 的基座模型。ChatGLM2-6B 使用了 GLM 的混合目标函数，经过了 1.4T 中英标识符的预训练与人类偏好对齐训练，评测结果显示，相比于初代模型，ChatGLM2-6B 在 MMLU（+23%）、CEval（+33%）、GSM8K（+571%） 、BBH（+60%）等数据集上的性能取得了大幅度的提升，在同尺寸开源模型中具有较强的竞争力。 更长的上下文：基于 FlashAttention 技术，我们将基座模型的上下文长度（Context Length）由 ChatGLM-6B 的 2K 扩展到了 32K，并在对话阶段使用 8K 的上下文长度训练，允许更多轮次的对话。但当前版本的 ChatGLM2-6B 对单轮超长文档的理解能力有限，我们会在后续迭代升级中着重进行优化。 更高效的推理：基于 Multi-Query Attention 技术，ChatGLM2-6B 有更高效的推理速度和更低的显存占
StarRocks 技术内幕：查询原理浅析
作者 康凯森 | StarRocks 核心研发、StarRocks 查询团队负责人 | 2022/04/26 15:46 | https://my.oschina.net/u/5658056/blog/5519656 一条查询 SQL 在关系型分布式数据库中的处理，通常需要经过 3 大步骤： 将 SQL 文本转换成一个 “最佳的” 分布式物理执行计划 将执行计划调度到计算节点 计算节点执行具体的物理执行计划 本文将详细解释在 StarRocks 中如何完成一条查询 SQL 的处理。 首先来了解 StarRocks 中的基本概念： FE: 负责查询解析，查询优化，查询调度和元数据管理 BE： 负责查询执行和数据存储 #01 从 SQL 文本到执行计划 从 SQL 文本到分布式物理执行计划，在 StarRocks 中，需要经过以下 5 个步骤: SQL Parse：将 SQL 文本转换成一个 AST（抽象语法树） SQL Analyze：基于 AST 进行语法和语义分析 SQL Logical Plan：将 AST 转换成逻辑计划 SQL Optimize：基于关系代数、统计信息、Cost 模型，对逻辑计划进行重写、转换，选择出 Cost “最低” 的物理执行计划 生成 Plan Fragment：将 Optimizer 选择的物理执行计划转换为 BE 可以直接执行
StarRocks-2.1.5 集群安装部署
StarRocks 是新一代的 MPP 数据库，它具有很高的查询性能，能够支持各种场景的数据查询分析使用，主要包含如下几个场景： OLAP多维分析 实时数据分析 高并发查询 统一分析 关于 StarRocks 更详细的介绍，可以查看官方文档，非常详细（见后面参考链接）。 下面，我们基于开源的 StarRocks 社区版，版本是 2.1.5 来进行集群的安装配置。StarRocks 集群的部署模式，采用 FE 与 BE 分离的模式。 集群部署规划 1 基础环境和软件 软件 版本 操作系统 CentOS-7.8 StarRocks 2.1.5 JDK jdk1.8.0_212 MySQL Client 5.7.37 2 集群主机规划 IP 地址 主机名称 角色 备注信息 172.168.0.1 VM-0-1-centos FE FE Master 172.168.0.2 VM-0-2-centos FE FE OBSERVER 172.168.0.3 VM-0-3-centos FE FE FOLLOWER 172.168.0.4 VM-0-4-centos BE BE 172.168.0.5 VM-0-5-centos BE BE 172.168.0.6 VM-0-6-centos BE BE 172.168.0.7 VM-0-7-centos BE BE 172.168.0.8 VM-0-8-centos BE BE 172.168.0.9 VM-0-9-centos BE BE 3 集群主机目录规划
Apache Hudi 架构设计和基本概念
Apache Hudi 是一个 Data Lakes 的开源方案，Hudi 是 Hadoop Updates and Incrementals 的简写，它是由 Uber 开发并开源的 Data Lakes 解决方案。Hudi 具有如下基本特性/能力： Hudi 能够摄入（Ingest）和管理（Manage）基于 HDFS 之上的大型分析数据集，主要目的是高效的减少入库延时。 Hudi 基于 Spark 来对 HDFS 上的数据进行更新、插入、删除等。 Hudi 在 HDFS 数据集上提供如下流原语：插入更新（如何改变数据集）；增量拉取（如何获取变更的数据）。 Hudi 可以对 HDFS 上的 parquet 格式数据进行插入/更新操作。 Hudi 通过自定义 InputFormat 与 Hadoop 生态系统（Spark、Hive、Parquet）集成。 Hudi 通过 Savepoint 来实现数据恢复。 目前，Hudi 支持 Spark 2.x 版本，建议使用 2.4.4+ 版本的 Spark。 基本架构 与 Kudu 相比，Kudu 是一个支持 OLTP workload 的数据存储系统，而 Hudi 的设计目标是基于 Hadoop 兼容的文件系统（如 HDFS、S3 等），重度依赖 Spark 的数据处理能力来实现增量处理和丰富的查询能力，Hudi 支持 Incremental Pulling 而 Kudu 不
Flink 批处理生成最佳执行计划（上篇）
生成最佳执行计划，过程比较复杂，我们分成两篇来详细分析：上篇和下篇，本文为上篇。 生成最佳执行计划是一个递归计算的过程：正向从 DataSinkNode 开始直到 DataSourceNode，分别计算每个 OptimizerNode 的最佳计划，然后反向逐步将整个 OptimizerNode DAG 图转换为 PlanNode DAG 图，得到一个最优计划。其中，PlanNode 的类继承结构，如下图所示： 通过与 OptimizerNode 对应的节点结构类图对比，PlanNode 更加抽象了一个层次，更关注 Operator 之间的数据交换策略。 其中，生成最佳执行计划的过程，可以在 Optimizer 类中看到，如下代码所示： // the final step is now to generate the actual plan alternatives List<PlanNode> bestPlan = rootNode.getAlternativePlans(this.costEstimator); 这是一个递归的过程，每个 OptimizerNode 都会通过获取到其孩子节点的最佳执行计划，从而递归地处理，从 OptimizerNode DAG 转换为 PlanNode DAG。后面，我们会对 SourcePlanNode、SinkPlanNode、SingleInputPlanNode、DualInputPlanNode 创建的处理过程
经典的卷积神经网络
这里，我们主要简单介绍在卷积神经网络发展过程中，一些经常用的改进模型，主要包括 LeNet-5、AlexNet、VGGNet、GoogLeNet、ResNet、DenseNet、ZFNet 这 7 个模型。本文不会非常深入讲解各个 CNN 模型，而是希望能够快速了解到各个模型起源，基本结构是什么样子，以及其它模型相比有什么明显的不同。 LeNet-5 LeNet-5 是第一个由 Yann LeCun 提出的卷积神经网络，它也是最基础的一个卷积神经网络，网络结构可以参考论文《Gradient-Based Learning Applied To Document Recognition》，如下图所示： LeNet-5 是一个 8 层 CNN 网络（包含输入层），其中包含卷积层块和全连接层块两个部分。卷积层用来识别图像里的空间模式，如线条和物体局部，之后的最大池化层则用来降低卷积层对位置的敏感性，卷积层块由两个这样的基本单位重复堆叠构成。当卷积层块的输出传入全连接层块时，全连接层块会将小批量中每个样本变平（Flatten）。 AlexNet AexNet 模型的名字来源于论文第一作者 Alex Krizhevsky 的名字，使用了 8 层卷积神经网络，并以很大的优势赢得了 ImageNet 2012 图
卷积神经网络介绍
卷积神经网络（Convolutional Neural Networks，CNN）是由纽约大学的 Yann Lecun 于 1998 年提出的，其本质是一个多层感知机，它是一类包含卷积计算且具有深度结构的前馈神经网络（Feedforward Neural Networks），是深度学习（Deep Learning）的代表算法之一。卷积神经网络是一种特殊的多层神经网络，像其它的神经网络一样，卷积神经网络也使用一种反向传播算法来进行训练，不同之处在于网络的结构。 卷积神经网络（CNN）具有一些传统技术所没有的优点： 良好的容错能力、并行处理能力和自学习能力，可处理环境信息复杂，背景知识不清楚，推理规则不明确情况下的问题； 它允许样本有较大的缺损、畸变，运行速度快，自适应性能好，具有较高的分辨率； 它是通过结构重组和减少权值将特征抽取功能融合进多层感知器，省略识别前复杂的图像特征抽取过程。 CNN 基本特征 下面，我们根据网上大家分享的有关卷积神经网络（CNN）的内容，梳理总结 CNN 所具有的一些特征，如下所示： 具有多层层次网络结构 卷积神经网络（CNN）被认为是第一个真正成功的、采用多层层次结构
使用 TensorFlow 处理 MNIST 手写体数字识别问题
使用 TensorFlow 官方提供的一个例子，基于 MNIST 数据集，实现一个图片分类的应用，本文是基于 TensorFlow 2.0 版本来学习和实践的。 MNIST 数据集是一个非常出 名的手写体数字识别数据集，它包含了 60000 张图片作为训练集，10000 张图片作为测试集，每张图片中的手写体数字是 0~9 中的一个，图片是 28×28 像素大小，并且每个数字都是位于图片的正中间的。 使用 TensorFlow 对 MNIST 数据集进行分类，整个实现对应的完整的 Python 代码，如下所示： from __future__ import absolute_import, division, print_function, unicode_literals import tensorflow as tf # 下载 MNIST 数据集 mnist = tf.keras.datasets.mnist (x_train, y_train), (x_test, y_test) = mnist.load_data() x_train, x_test = x_train / 255.0, x_test / 255.0 # 创建 tf.keras.Sequential 模型 model = tf.keras.models.Sequential([ tf.keras.layers.Flatten(input_shape=(28, 28)), tf.keras.layers.Dense(128, activation='relu'), tf.keras.layers.D
Flink 批处理生成 OptimizerNode DAG 图
OptimizerNode DAG，是基于程序 Plan 中创建好的 Operator DAG，并以 OptimizerNode 作为 DAG 图节点构建完成的。所以，我们先看一下组成 OptimizerNode DAG，都有哪些类型的 OptimizerNode，如下图所示： 通过上面类图，可以看到其中主要有 SingleInputNode、TwoInputNode、DataSourceNode、DataSinkNode 等这几大类，根据各个 OptimizerNode 具体实现类名称，可以对应到具体操作功能的 Operator 实现类。比如，MapNode 对应 map 操作，JoinNode 对应 join 操作，等等。 OptimizerNode 结构 下面看一下 OptimizerNode 的数据结构，了解它都抽象了哪些内容，如下图所示： 上图中的结构是每个 OptimizerNode 都包含的内容，具体到每个 OptimizerNode 实现，都会根据 Operator 的属性及行为，补充一些其他的信息。上面的 cachedPlans 是一个基于 PlanNode 的 DAG 的列表，在生成 OptimizerNode 过程中并没有用到，而是基于 OptimizerNode DAG 生成最佳执行计划的时候，通过 PlanNode DAG 来表示的，后续文章我们会单独详细分析，这里先跳过。 下面将对 OptimizerNod
Flink 批处理生成执行计划
我们这里所说的优化执行计划，是指从生成 Plan 之后，一直到生成 JobGraph 之前这一期间对 Plan 进行各种转换、增强、优化处理。从用户编程的 Flink 批处理程序开始，一直到生成 JobGraph 的整个过程，这个过程中，会创建很多数据结构来完成执行计划的优化工作，而且，通过分层增强与优化的方式，有利于我们对每层进行了哪些处理有一个很好地理解。 我们从整理流程上来看，都有哪些核心的处理，然后会对每一步进行概要说明，从宏观上理解每一步都做了哪些操作。批处理执行计划生成及优化的主要流程，如下图所示： 根据上图，我们将Flink批处理执行计划生成的流程，分为如下几个阶段进行说明。 构建用户编程 Operator DAG 把用户程序中设置的各种 DataSource、Transformation、DataSink 及其配置信息进行收集，以最原始的形态保存在 ExecutionEnvironment 上线文环境对象中，当然也跟踪了从 DataSource 到 DataSink 之间的操作顺序，最后通过 ExecutionEnvironment 对象，基于 DataSink 就可以从后向前遍历，直接链接到 DataSource。 在上面的处理过程中，涉及到3
Flink 批处理生成 JobGraph 流程分析
我们先通过一个简单的批量处理 WordCount 的程序，来了解一下，在编程 API 层面的基本使用方法，以及 Flink 是如何基于 Pipeline 风格的 API 实现一个完整的应用程序的，还有就是每一步操作的底层，都是如何进行转换的。WordCount 程序代码，示例如下所示： final MultipleParameterTool params = MultipleParameterTool.fromArgs(args); final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment(); env.getConfig().setGlobalJobParameters(params); // get input data DataSet<String> text = env.readTextFile(input); DataSet<Tuple2<String, Integer>> counts = // split up the lines in pairs (2-tuples) containing: (word,1) text.flatMap(new Tokenizer()) // group by the tuple field "0" and sum up tuple field "1" .groupBy(0) .s