汪巡的博客

记录了 Elastic Search、Logstash 和 Kibana 的简单安装方法和 ES 的常用查询操作命令，Logstash还未整理，去官网查比较全。Elastic Search 安装# 下载安装包wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.2.1-linux-x86_64.tar.gz# 解压修改文件夹名tar -zxvf elasticsearch-7.2.1-linux-x86_

读写 Excel使用的是 crealytics 的 spark-excel （CSDN 的国内镜像仓库）解决 Excel 的读写问题，可以直接读取为 DataFrame ，常用的表头、读取 sheet 以及读取位置等参数都可以配置，写入的话支持写入到单个 Excel 文件而不是目录，常用的参数有写入表头、写入位置以及写入模式都参数配置，还支持同一个Excel文件多次写入。导入 Maven 依赖：<dependency> <groupId>com.crealytics<

窗口函数在我的理解下首先是解决 OLAP 系统的复杂分类问题，它可以定制不同规模的窗口让聚合函数在窗口内执行并返回结果到当前行，理解窗口函数脑中需要有一张表，模拟函数在计算时数据的来源，也就是窗口的定义和界限，在最新的 SQL 中支持 over 窗口函数，我们一般所说的窗口函数也就是over函数。over 开窗函数可以配合 sum，avg，count，max，min 等聚合函数，也可以配合 rank，dense_rank和row_number 等专用开窗函数。当 over 函数中未使用 partition

环境空间 ( environment ) 对于刚接触 R 语言的我来说，是比较陌生的。虽然不了解它的运行原理，但也不影响我使用 R 语言。环境空间是 R 语言中关于计算机方面的底层设计，主要用于R语言是环境加载器。通过环境空间，封装了加载器的运行过程，让使用者在不知道底层细节的情况下，可以任意加载使用到的第三方的 R 语言程序包。介绍在R语言中，不管是变量，对象，或者函数，都存在于 R 的环境空间中，R程序在运行时都自己的运行时空间。R 语言的环境 (environment) 是由内核定义的一个数据结构

R 语言结合了面向对象编程语言和函数式编程语言的特性，由于拥有函数式编程的特性，R 的每一个运算符，实际上也是函数，同样，面向对象的特性决定了你接触到的 R 中所有东西(从数字到字符串到矩阵等)都是对象。这些综合的特质决定了 R 这门语言的特殊性，最大的特点就是开源。之前简单了解了 R 语言的 S3 对象以及泛型函数，下面介绍 R 语言的函数式编程，主要包含三个模块：匿名函数，闭包（由函数编写的函数）和函数列表。其主要目的还是为了减少代码量或提高效率。匿名函数在 R 语言中，函数本身就是一个对象，使用

数据仓库建模在数据仓库建设中有很重要的地位，是继业务梳理后的第二大要点，是将概念模型转化为物理模型的一个过程。关于建模一向被吹得神乎其神，相关介绍文章以及招聘需求中对此都要求很高，那么了解主流的建模方法和各自的优劣势以及应用场景就变得至关重要了。选择合适的建模方法要考虑几点要素，分别是：性能、成本、效率和质量，性能是能够快速的查询所需的数据，减少数据IO的吞吐；成本是减少不必要的冗余，实现计算结果的复用，减少大数据系统的计算成本和存储成本；效率则是改善使用数据的效率，计算、查询效率也算在内；质量是改善数据

最近开始接触数据仓库，要了解一项技术或者一个工具，就得先去了解它在某个链路中所处的位置，以及它的出现是为了解决什么问题，那么就有了这篇文章，从数据仓库的诞生环境、所能解决的问题以及主流的上层架构，简单介绍了数据仓库这项技术。产生背景数据仓库的诞生离不开环境的因素，在数据量加剧的当今社会和数据分析挖掘需求日益增加的环境下，传统面向业务的 MySQL、Oracle 等 OLTP 型数据库已经不能满足当下一些特殊的需求。OLTP 型数据库主要是解决业务需求，构造也具有遵循 3NF 范式，避免冗余等特点，但这些

这节来说说数据仓库的架构，关于架构并没有一个统一的标准，按照数据量以及使用环境可以搭建适合当下场景的数据仓库，下面主要是介绍比较大众或者说比较通用的数据仓库架构。传统的数据仓库架构按层级可分为 ETL、ODS、DWD、DWS 和 ADS 五个层级，层次结构如下图所示。这五个层级针对不同的需求解决各阶段各自的问题，在数据量少的情况下个别层次可以继续简化，也可以在层次之间增加数据中间件，让整个过程更加规范化，对于层级结构没必要细究，重点是每个层级所解决的问题以及在整个链路所处的位置。ETLETL（Ext

最近开始接触数据仓库，要了解一项技术或者一个工具，就得先去了解它在某个链路中所处的位置，以及它的出现是为了解决什么问题，那么就有了这篇文章，从数据仓库的诞生环境、所能解决的问题以及主流的上层架构，简单介绍了数据仓库这项技术。产生背景数据仓库的诞生离不开环境的因素，在数据量加剧的当今社会和数据分析挖掘需求日益增加的环境下，传统面向业务的MySQL、Oracle等OLTP型数据库已经不能满足当下一些特殊的需求。OLTP型数据库主要是解决业务需求，构造也具有遵循3NF范式，避免冗余等特点，但这些特点在面向分析

Spark 在对 MySQL 进行读写的时候使用自带的 read 和 write 方法就可以满足，而在对 ElasticSearch 进行读写的时候则要用到其他依赖，在数据结构较为复杂时还需要使用 GSON 或其他 JSON 包进行解析。所以就记录一下 MySQL 的读写以及 ES 的读以及解析为 DataFrame 的方法。MySQLSpark 可以使用 read 和 write 方法直接连接 MySQL，只需传入指定的 option 即可。Spark 读 MySQLdef con(): Stri

累加器Spark 中累加器用来解决一些特殊的需求。假设有一个需求，对 RDD 中的数据进行累加求和并返回，当然使用 reduce 可以很好地实现，但我们想尝试一下定义一个新的变量，依次遍历 RDD 对每个元素进行累加最后返回这个变量的值。val spark: SparkSession = SparkSession.builder().master("local[*]").getOrCreate()val sc: SparkContext = spark.sparkContextval rdd: R

在 Spark 处理数据的过程中，虽然 DataSet 下的算子不多，但已经可以处理大多数的数据需求，但仍有少数需求需要自定义函数。UDF(User Defined Functions) 是普通的不会产生 Shuffle 不会划分新的阶段的用户自定义函数，UDAF(User Defined Aggregator Functions) 则会打乱分区，用户自定义聚合函数。UDF因为 UDF 不需要打乱分区，直接对 RDD 每个分区中的数据进行处理并返回当前分区，所以可以直接注册 UDF 函数，甚至可以传入匿

Spark 在运算过程中提供了几个不同程度的持久化操作，通过将数据保存在内存中、磁盘中或者 HDFS 中来满足我们计算中的持久化需求。持久化（Persist、Cache）在实际开发中某些 RDD 的计算或转换可能会比较耗费时间，如果这些 RDD 后续还会频繁的被使用到，那么可以将这些 RDD 进行持久化/缓存，这样下次再使用到的时候就不用再重新计算了，提高了程序运行的效率。Spark 提供了 Persist 和 Cache 两个操作对 RDD 的运算结果进行持久化。先看一个例子，我们要对一个文件内的单

Spark中比较重要的一块就是血缘关系和阶段划分，虽说并不能像累加器或者广播变量解决特定的需求，但对于理解Spark计算的任务执行调度有很大的帮助。Lineage（血缘关系）RDD 只支持粗粒度转换，即在大量记录上执行的单个操作。将创建 RDD 的一系列 Lineage (血统)记录下来，以便恢复丢失的分区。RDD 的 Lineage 会记录 RDD 的元数据信息和转换行为，当该 RDD 的部分分区数据丢失时，它可以根据这些信息来重新运算和恢复丢失的数据分区。RDD不保存数据，在没有缓存和检查点的情况

OverviewSpark中常用的算子加起来有几十个，其中针对key的聚合算子有五个，分别是groupBy、groupByKey、reduceByKey、aggregateByKey和flodByKey，有几个底层其实调用的都是一个方法，只不过传入的参数不一样产生了这几个算子，但我仍打算分开来详解每个算子的计算过程，加深理解。这几个聚合算子要解决的问题都是将所需操作的RDD中的key值相同的value值聚合在一起然后两两做计算也就是聚合最终得出一个结果，这里有三个点需要注意，一是两两聚合的初始值，是

RDD(Resilient Distributed Dataset)叫做弹性分布式数据集，是 Spark 中最基本的数据处理模型。代码中是一个抽象类，它代表一个弹性的、不可变、可分区、里面的元素可并行 计算的集合。而DataFrame和DataSet分别是Spark1.3版本和1.6版本开始支持的数据集类型。它们之间彼此依赖也可以互相转换，分别应用在不同的场景下。RDDRDD是Spark计算的基础数据集合，之后的DataFrame和DataSet底层也是封装了RDD，所以掌握RDD对是学习Spark