大数据平台架构设计

 

大数据架构

大数据架构，如下图：

1、通过ETL工具将数据源抽取到HDFS存储；

2、通过Hive清洗、处理和计算原始数据；

3、Hive清洗处理后的结果，如果是面向海量数据随机查询场景的可存入Hbase;

4、数据应用从HBase查询数据；

      

       大数据架构实例1，如下图：

大数据架构实例2，如下图：

大数据架构实例3，如下图：

大数据架构实例4，如下图：

大数据架构实例5：

大数据架构实例6：

一、场景

1.数据源主要为 Mysql，希望实时同步 Mysql 数据到大数据集群中（肯定是越快越好）。

2目前每日 20 亿数据，可预见的一段时间后的规模是 100 亿每日以上。

3.能快速地查到最新的数据，这里包含两部分含义：从 Mysql 到大数据集群的速度快、从大数据集群中查询的速度要快。

二、方案选型

遇到这个场景的时候，根据经验我们主要考虑下面两个点：数据抽取引擎和存储引擎。

数据抽取引擎

这里我们主要考虑两种方案：

1.Sqoop 定时抽取 Mysql 数据到 HDFS 中，可以每天全量抽取一份，也可以隔段时间就抽取一份变更的数据。

2.Canal 监听 Mysql 的 binlog 日志，相当于是 Mysql 有一条数据久变动，我们就抽取一条数据过来。

优缺点的对比也很明显：

1.Sqoop 相对比较通用一些，不管是 Mysql 还是 PostgreSql都可以用，而且很成熟。但是实时性较差，每次相当于是启动一个 MR 的任务。

2.Canal 速度很快，但是只能监听 Mysql 的日志。

存储引擎

存储引擎主要考虑 HDFS、Hbase 和 ES。

一般情况下，HDFS 我们尽量都会保存一份。主要纠结的就是 Hbase 和 ES。本来最初是想用 Hbase 来作为实时查询的，但是由于考虑到会有实时检索的需求，就暂定为ES

三、方案设计

最终，我们使用了下面的方案。

1.使用 Canal 来实时监听 Mysql 的数据变动

2.使用 Kafka 作为消息中间件，主要是为了屏蔽数据源的各种变动。比如以后即使用 Flume 了，我们架构也不用大变

3.数据落地，有一份都会落地 HDFS，这里使用 Spark Streaming，算是准实时落地，而且方便加入处理逻辑。在 落地 ES 的时候可以使用 Spark Streaming，也可以使用 Logstach，这个影响不大

 

Hive和Hbase

Hive主要解决海量数据的清洗、处理和计算的问题。严格来说Hive不是数据库，它通过元数据来描述Hdfs上的结构化文本数据，就是定义一张表来描述HDFS上的结构化文本，包括各列数据名称、数据类型等，方便处理数据。当前很多SQL ON Hadoop的计算引擎均用的是hive元数据，如Spark SQL、Impala。

Hive会将SQL翻译为Mapreduce来处理数据，适用于离线的批量数据计算，但仅限于查找和分析，而不是更新、增加和删除。它的底层是MapReduce，MapReduce在实时计算上性能很差。它的做法是把数据文件加载进来作为一个hive内部表或者外部表，让你觉得你的sql操作的是传统的表。但Hive使用load data操作的时候，不管是外部表还是内部表，如果源数据存在于HDFS层，都是数据的移动，即源数据从HDFS存储路径移动到Hive数据仓库默认路径。

Hadoop是hive和hbase的基础，hive依赖hadoop，而hbase仅依赖hadoop的hdfs模块。

Hive适用于离线数据的分析，操作的是通用格式的（如通用的日志文件）、被hadoop管理的数据文件，它支持类sql，比编写MapReduce的java代码来的更加方便，它的定位是数据仓库，存储和分析历史数据
hbase适用于实时计算，采用列式结构的nosql，操作的是自己生成的特殊格式的HFile、被hadoop管理的数据文件，它的定位是数据库，或者叫DBMS

Hive可以直接操作hdfs中的文件作为它的表的数据，也可以使用hbase数据库作为它的表.

 

Hbase主要用于海量明细数据（十亿、百亿）的随机实时查询的问题，如日志明细、交易清单、轨迹行为等。

Hbase基于hdfs实现对分布式数据文件的管理，比如增删改查。也就是说，hbase只是利用hadoop的hdfs帮助其管理数据的持久化文件（HFile），它跟MapReduce没任何关系。hbase的优势在于实时计算，所有实时数据都直接存入hbase中，客户端通过API直接访问hbase，实现实时计算。由于它使用的是nosql，或者说是列式结构，从而提高了查找性能，使其能运用于大数据场景，这是它跟MapReduce的区别。

在Hbase中日志即数据，数据就是日志，他们是一体化的。为什么这么说了，因为Hbase的更新时插入一行，删除也是插入一行，然后打上删除标记，则不就是日志吗？

     在Hbase中，有Memory Store,还有Store File，其实每个Memory Store和每个Store File就是对每个列族附加上一个B+树(有点像Oracle的索引组织表，数据和索引是一体化的)， 也就是图的下面是列族，上面是B+树，当进行数据的查询时，首先会在内存中memory store的B+树中查找，如果找不到，再到Store File中去找。

     如果找的行的数据分散在好几个列族中，那怎么把行的数据找全呢？那就需要找好几个B+树，这样效率就比较低了。所以尽量让每次insert的一行的列族都是稀疏的，只在某一个列族上有值，其他列族没有值，

一，索引不同造成行为的差异。Hbase只能建立一个主键索引，而且之后的数据查询也只能基于该索引进行简单的key-value查询；但是Oracle可以建立任意索引，也可以按照任意列进行数据查询。

二，Hbase适合大量插入同时又有读的情况，读一般为key-value查询大数据、高并发正合Hbase的胃口

三，Hbase的瓶颈是硬盘传输速度，Oracle的瓶颈是硬盘寻道时间。Hbase都是大量往硬盘上写数据（没有delete、update，都是insert），即使是读数据，也是优先MemStore，所以硬盘传输速度成为其瓶颈；而Oracle由于具有随机访问特性（select、update等），所以硬盘寻道时间成为其瓶颈，而寻道时间主要由转速决定。

四，Hbase很适合寻找按照时间排序top n的场景。Hbase数据都具有时间戳（Hbase默认就有时间戳）

       五Hbase的优缺点：

1 列的可以动态增加，并且列为空就不存储数据,节省存储空间.

2 Hbase自动切分数据，使得数据存储自动具有水平scalability.

3 Hbase可以提供高并发读写操作的支持

4 不能支持条件查询，只支持按照Row key来查询.

5 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.

6另外，由于在Hbase中，同一个列里面数据格式比较接近，或者长度相近，从而可以对数据进行大幅度的压缩，结果就是节省了硬盘空间，也减少了IO。

1.数据类型，HBase只有简单的字符类型，所有的类型都是交由用户自己处理，它只保存字符串。而关系数据库有丰富的类型和存储方式。

2.数据操作：HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接操作。 

3.存储模式：HBase是基于列存储的，每个列族都由几个文件保存，不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的

4.数据维护，HBase的更新操作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改

5.可伸缩性，Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能

 

Flume和Kafka

Flume基于agent思路架构，设计了3个组件source、channel、sink。source面向各种形式的数据源提供数据源对接与数据采集功能，以event格式将数据发送给channel。channel提供数据缓冲能力，保证数据传输的事务性和安全性，channel接收source发送过来的event数据并缓冲起来，直到被sink消费掉为止。Sink对接各种形式的数据存储，把数据存储起来，或者再次对接source形成传递接力。

Flume通过内置种类丰富的source提供强大的数据源对接与数据采集能力，通过channel提供了微弱的数据缓冲能力，并保证数据传递的事务性与安全性，通过内置的拦截器，可以对流经数据进行过滤和屏蔽，具有微弱的计算能力。

Flume中event的相关概念：Flume的核心是把数据从数据源（source）收集过来，在将收集到的数据送到指定的目的地（sink）。为了保证输送的过程一定成功，在送到目的地（sink）之前，会先缓存数据（channel）,待数据真正到达目的地（sink）后，Flume再删除自己缓存的数据。

在整个数据的传输的过程中，流动的是event，即事务保证是在event级别进行的。那么什么是event呢？Event将传输的数据进行封装，是Flume传输数据的基本单位，如果是文本文件，通常是一行记录。Event也是事务的基本单位。Event从source，流向channel，再到sink，本身为一个字节数组，并可携带headers（头信息）信息。Event代表着一个数据的最小完整单元，从外部数据源来，向外部的目的地去。 

Flume之所以这么神奇，是源于它自身的一个设计，这个设计就是agent。Agent本身是一个Java进程，运行在日志收集节点——所谓日志收集节点就是服务器节点。 Agent里面包含3个核心的组件：source、channel和sink，类似生产者、仓库、消费者的架构。

Source：source组件是专门用来收集数据的，可以处理各种类型、各种格式的日志数据,包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、自定义。 

Channel：source组件把数据收集来以后，临时存放在channel中，即channel组件在agent中是专门用来存放临时数据的——对采集到的数据进行简单的缓存，可以存放在memory、jdbc、file等等。 

Sink：sink组件是用于把数据发送到目的地的组件，目的地包括hdfs、logger、avro、thrift、ipc、file、null、Hbase、solr、自定义。

Flume的核心就是一个agent，这个agent对外有两个进行交互的地方，一个是接受数据输入的source，一个是数据输出的sink，sink负责将数据发送到外部指定的目的地。source接收到数据之后，将数据发送给channel，chanel作为一个数据缓冲区会临时存放这些数据，随后sink会将channel中的数据发送到指定的地方，例如HDFS等。注意：只有在sink将channel中的数据成功发送出去之后，channel才会将临时数据进行删除，这种机制保证了数据传输的可靠性与安全性。

Kafka基于分布式高可用的borker提供强大的数据缓冲能力，producer对接数据源采集数据，并将数据发送到broker上，数据就在borker上缓存下来（从这个角度看borker很像数据库），直到sink消费完数据为止。

Kafka基于分布式架构提供高容错功能，基于offset记录已经处理过的数据，消息写入topic有顺序，consumer记录自己的offset，topic数据存储在分区上，分区有副本，分布在不同节点上.

Kafka提供consumer group概念。某些topic拥有数百万甚至数千万的消息量，如果仅仅靠单个消费者消费，那么消费速度会非常慢，所以我们需要使用消费组功能，同一个消费组的多个消费者就能分布到多个物理机器上以加速消费。每个消费者组都会有一个独一无二的消费者组id来标记自己。每一个消费者group可能有一个或者多个消费者，对于当前消费组来说，topic中每条数据只要被消费组内任何一个消费者消费一次，那么这条数据就可以认定被当前消费组消费成功。消费组有如下三个特征:

1、每个消费组有一个或者多个消费者。

2、每个消费组拥有一个唯一性的标识id。

3、消费组在消费topic的时候，topic的每个partition只能分配给一个消费者。

Kafka的producer和consumer通常需要定制，所以对接各种数据源不灵活、不方便。

所以，在生产环境中，一般将Flume和Kafka搭配使用，Flume采集kafka缓冲，来完成实时流式的数据处理。

       1、生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。

       2、如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。

       3、Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。

       4、Kafka与Flume都可以通过配置保证数据不丢失。但是，Flume不会复制消息，因此即使使用可靠的文件渠道，当Flume进程宕机后，你就无法访问这些消息了（当然Flume进程重启，从磁盘上恢复之前状态后，可以继续对消息进行处理）。因此如果对 HA高可用性具有很高要求，我们建议Kafka；

       另外Flume常用的场景是：直接将数据写入存储，如hadoop或habase中。Flume对HDFS/HBase具有更好的优化，同时它也集成了Hadoop安全组件。如果数据需要被多个应用程序处理，我们建议Kafka；如果数据主要是用于Hadoop，我们建议Flume；

       另外如果希望将Kafka上的数据导入Hadoop，可以启动一个内置Kafka源与Hadoop槽的Flume进程。这样就不需要去实现自定义的消费者，同时还可以得到Flume对HDFS/HBase优化带来的好处。

      

       Kafka为什么能做到高吞吐

Kafka虽然是基于磁盘做的数据存储，但却具有高性能、高吞吐、低延时的特点，其吞吐量动辄几万、几十上百万。Kafka是将消息记录持久化到本地磁盘中的，一般人会认为磁盘读写性能差，可能会对Kafka性能如何保证提出质疑。实际上不管是内存还是磁盘，快或慢关键在于寻址的方式，磁盘分为顺序读写与随机读写，内存也一样分为顺序读写与随机读写。基于磁盘的随机读写确实很慢，但磁盘的顺序读写性能却很高，一般而言要高出磁盘随机读写三个数量级，一些情况下磁盘顺序读写性能甚至要高于内存随机读写。

磁盘的顺序读写是磁盘使用模式中最有规律的，并且操作系统也对这种模式做了大量优化，Kafka就是使用了磁盘顺序读写来提升的性能。Kafka的message是不断追加到本地磁盘文件末尾的，而不是随机的写入，这使得Kafka写入吞吐量得到了显著提升 。

Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。    相比于使用JVM或in-memory cache等数据结构，利用操作系统的Page Cache更加简单可靠。首先，操作系统层面的缓存利用率会更高，因为存储的都是紧凑的字节结构而不是独立的对象。其次，操作系统本身也对于Page Cache做了大量优化，提供了 write-behind、read-ahead以及flush等多种机制。再者，即使服务进程重启，系统缓存依然不会消失，避免了in-process cache重建缓存的过程。

      通过操作系统的Page Cache，Kafka的读写操作基本上是基于内存的，读写速度得到了极大的提升。 

 linux操作系统 “零拷贝” 机制使用了sendfile方法， 允许操作系统将数据从Page Cache 直接发送到网络，只需要最后一步的copy操作将数据复制到 NIC 缓冲区， 这样避免重新复制数据 。

通过这种 “零拷贝” 的机制，Page Cache 结合 sendfile 方法，Kafka消费端的性能也大幅提升。这也是为什么有时候消费端在不断消费数据时，我们并没有看到磁盘io比较高，此刻正是操作系统缓存在提供数据。

零拷贝并非指一次拷贝都没有，而是避免了在内核空间和用户空间之间的拷贝。

Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。

      通过这种分区分段的设计，Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后数据文件建立了索引文件，就是文件系统上.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作并行度。

Kafka数据读写也是批量的而不是单条的。除了利用底层的技术外，Kafka还在应用程序层面提供了一些手段来提升性能。最明显的就是使用批次。在向Kafka写入数据时，可以启用批次写入，这样可以避免在网络上频繁传输单个消息带来的延迟和带宽开销。假设网络带宽为10MB/S，一次性传输10MB的消息比传输1KB的消息10000万次显然要快得多。

      在很多情况下，系统的瓶颈不是CPU或磁盘，而是网络IO，对于需要在广域网上数据中心之间发送消息的数据流水线尤其如此。进行数据压缩会消耗少量CPU资源,不过对于kafka而言,网络IO更应该需要考虑。如果每个消息都压缩，但是压缩率相对很低，所以Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩

Kafka允许使用递归的消息集合，批量的消息可以通过压缩的形式传输并且在日志中也可以保持压缩格式，直到被消费者解压缩。Kafka支持多种压缩协议，包括Gzip和Snappy压缩协议。Kafka速度的秘诀在于，它把所有的消息都变成一个批量的文件，并且进行合理的批量压缩，减少网络IO损耗，通过mmap提高I/O速度，写入数据的时候由于单个Partion是末尾添加所以速度最优；读取数据的时候配合sendfile直接暴力输出。

 

ETL

Ketlle优劣分析总结：

免费开源：基于java的免费开源的软件，对商业用户也没有限制

易配置：可以在Window、Linux、Unix上运行，绿色无需安装，数据抽取高效稳定

不同数据库：ETL工具集，它允许你管理来自不同数据库的数据

两种脚本文件：transformation和job，transformation完成针对数据的基础转换，job则完成整个工作流的控制

图形界面设计：通过图形界面设计实现做什么业务，无需写代码去实现

定时功能：在Job下的start模块，有一个定时功能，可以每日，每周等方式进行定时

Kettle家族目前包括4个产品：Spoon、Pan、CHEF、Kitchen。

SPOON：允许你通过图形界面来设计ETL转换过程（Transformation），Spoon有丰富的Steps可以组装开发出满足多种复杂应用场景的数据集成作业，方便实现全量、增量数据同步。缺点是通过定时运行，实时性相对较差。

PAN：允许你批量运行由Spoon设计的ETL转换 (例如一个时间调度器)。Pan是后台执行程序，没有图形界面

CHEF：允许你创建任务（Job）。 任务通过允许每个转换，任务，脚本等等，更有利于自动化更新数据仓库的复杂工作。任务通过允许每个转换，任务，脚本等等。任务将会被检查，看看是否正确地运行了

KITCHEN：允许你批量使用由Chef设计的任务 (例如一个时间调度器)。KITCHEN也是一个后台运行的程序

适用场景：数据量及增量不大，业务规则变化较快，要求可视化操作，对技术人员的技术门槛要求低。

Sqoop优劣分析总结：

主要用于在HADOOP(Hive)与传统的数据库(mysql、postgresql...)间进行数据的传递。

数据吞吐量大：依赖hadoop集群可进行大批量数据集成。

操作有技术要求：sqoop操作没有可视化设计器，对使用人员有较专业的技术要求。

多种交互方式：命令行，web UI，rest API。

部署不方便：sqoop依赖大数据集群，使用sqoop要求数据传输的源要与大数据集群的所有节点能进行通信。

适用场景：适用于能与大数据集群直接通信的关系数据库间的大批量数据传输。

Flume优劣分析总结：

分布式：flume分布式集群部署，扩展性好。

可靠性好: 当节点出现故障时，日志能够被传送到其他节点上而不会丢失。

易用性：flume配置使用较繁琐，对使用人员专业技术要求非常高。

实时采集：flume采集流模式进行数据实时采集。

适用场景：适用于日志文件实时采集。

Canal优劣分析总结：

很多大型的互联网项目生产环境中使用，包括阿里、美团等都有广泛的应用，是一个非常成熟的数据库同步方案，基础的使用只需要进行简单的配置即可。

DataX优劣分析总结：

阿里开源软件异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。

易用性：没有界面，以执行脚本方式运行，对使用人员技术要求较高。

性能：数据抽取性能高。

部署：可独立部署

适用场景：在异构数据库/文件系统之间高速交换数据。

 

Flume是一个海量日志采集、聚合和传输的系统，支持在日志系统中定制各类数据发送方，用于收集数据。同时，Flume提供对数据进行简单处理，并写到各种数据接受方的能力。Flume以流方式处理数据，可作为代理持续运行。当新的数据可用时，Flume能够立即获取数据并输出至目标，这样就可以在很大程度上解决实时性问题。

Flume是最初只是一个日志收集器，但随着flume-ng-sql-source插件的出现，使得Flume从关系数据库采集数据成为可能。下面简单介绍Flume，并详细说明如何配置Flume将MySQL表数据准实时抽取到HDFS。

利用Flume采集关系数据库表数据最大的优点是配置简单，不用编程，Flume只要在flume.conf文件中配置source、channel及sink的相关属性，已经没什么难度了。再有该方案采用普通SQL轮询的方式实现，具有通用性，适用于所有关系库数据源。

这种方案的缺点与其优点一样突出，主要体现在以下几方面。 

1. 在源库上执行了查询，具有入侵性。
2. 通过轮询的方式实现增量，只能做到准实时，而且轮询间隔越短，对源库的影响越大。
3. 只能识别新增数据，检测不到删除与更新。
4. 要求源库必须有用于表示增量的字段。

 

Sqoop是一款开源的工具，主要用于在Hadoop(Hive)与传统的数据库(mysql、postgresql...)间进行数据的传递，可以将一个关系型数据库中的数据导进到Hadoop的HDFS中，也可以将HDFS的数据导进到关系型数据库中。Sqoop专为大数据批量传输设计，能够分割数据集并创建Hadoop任务来处理每个区块。通过导入导出命令加配套参数控制操作。

使用Sqoop抽取从MySQL数据库增量抽取数据到HDFS，这种方式只需要很少量的配置即可完成数据抽取任务，但缺点同样明显，那就是实时性。Sqoop使用MapReduce读写数据，而MapReduce是为了批处理场景设计的，目标是大吞吐量，并不太关心低延时问题。就像实验中所做的，每天定时增量抽取数据一次。

Sqoop导入：导入工具从RDBMS到HDFS导入单个表。表中的每一行被视为HDFS的记录。所有记录被存储在文本文件的文本数据或者在Avro和序列文件的二进制数据。

Sqoop导出：导出工具从HDFS导出一组文件到一个RDBMS。作为输入到Sqoop文件包含记录，这被称为在表中的行。那些被读取并解析成一组记录和分隔使用用户指定的分隔符。     

Sqoop支持全量数据导入和增量数据导入（增量数据导入分两种，一是基于递增列的增量数据导入（Append方式）。二是基于时间列的增量数据导入（LastModified方式）），同时可以指定数据是否以并发形式导入。

（1）、Append方式

 

（2）、LastModified方式

 

命令简单示例：

 

 

Canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据实时订阅和消费，目前主要支持了MySQL，也支持mariaDB。很多大型的互联网项目生产环境中使用，包括阿里、美团等都有广泛的应用，是一个非常成熟的数据库同步方案，基础的使用只需要进行简单的配置即可。当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x.。

 

Canal是通过模拟成为mysql 的slave的方式，监听mysql 的binlog日志来获取数据，binlog设置为row模式以后，不仅能获取到执行的每一个增删改的脚本，同时还能获取到修改前和修改后的数据，基于这个特性，canal就能高性能的获取到mysql数据数据的变更。

 

DataX是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步功能。DataX采用了框架 + 插件的模式，目前已开源，代码托管在github。从应用的模式，DataX更适合ELT模式。步骤：操作简单通常只需要两步；创建作业的配置文件（json格式配置reader,writer）；启动执行配置作业。

 

Job：一道数据同步作业

Splitter：作业切分模块,将一个大任务与分解成多个可以并发的小任务.

Sub-job：数据同步作业切分后的小任务

Reader(Loader)：数据读入模块,负责运行切分后的小任务,将数据从源头装载入

DataXStorage：Reader和Writer通过Storage交换数据

Writer(Dumper)：数据写出模块,负责将数据从DataX导入至目的数据地

DataX框架内部通过双缓冲队列、线程池封装等技术,集中处理了高速数据交换遇到的问题,提供简单的接口与插件交互,插件分为Reader和Writer两类,基于框架提供的插件接口,可以十分便捷的开发出需要的插件。缺乏对增量更新的内置支持，因为DataX的灵活架构，可以通过shell脚本等方式方便实现增量同步。

DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader+Writer插件，纳入到整个同步框架中。

目前已到datax3.0框架设计：

 

datax使用示例，核心就是编写json配置文件job：

 

 

 

数据集成加载策略，按类型可包括快照、流水、增量、全量、拉链等。

SQL是最好的语言，各种join、嵌套/标量子查询，强大的分析/窗口函数，正则表达式，层次查询，扩展分组，MODEL，递归with，多维分析，排列组合，行列互转，json解析，执行计划，四大类型(dql、dml、ddl、dcl)等。

SQLjoin ， left/rignt/full join，每一个join都是暗藏韵理，on和where也不容小觑。

 

分析函数 简捷高效，4类30+个分析/窗口函数最全总结。

 

SQL开发规范和 执行计划 也需要每个erl·er在实际实践中不断加强、提炼、升级。

 

 

SQL分析函数

分析函数主要分为四类：

        1.聚合分析函数

        2.排名分析函数

        3.数学分析函数

        4.行比较分析函数

一.聚合分析函数

SUM       ：该函数计算组中表达式的累积和
COUNT   ：对一组内发生的事情进行累积计数
MIN        ：在一个组中的数据窗口中查找表达式的最小值
MAX       ：在一个组中的数据窗口中查找表达式的最大值
AVG        ：用于计算一个组和数据窗口内表达式的平均值。

二.排名分析函数

ROW_NUMBER ：-- 正常排序[1,2,3,4] -- 必须有order_by
RANK                ：-- 跳跃排序[1,2,2,4] -- 必须有order_by
DENSE_RANK   ：-- 密集排序[1,2,2,3] -- 必须有order_by
FIRST                ：从DENSE_RANK返回的集合中取出排在最前面的一个值的行
LAST                 ：从DENSE_RANK返回的集合中取出排在最后面的一个值的行
FIRST_VALUE    ：返回组中数据窗口的第一个值
LAST_VALUE     ：返回组中数据窗口的最后一个值。

row_number() 是没有重复值的排序(即使两行记录相等也是不重复的)
rank() 是跳跃排序，两个第二名下来就是第四名
dense_rank() 是连续排序，两个第二名仍然跟着第三名
NTILE(n)，用于将分组数据按照顺序切分成n片

三.数学分析函数

STDDEV      ：计算当前行关于组的标准偏离

STDDEV_POP：该函数计算总体标准偏离，并返回总体变量的平方根

STDDEV_SAMP：该函数计算累积样本标准偏离，并返回总体变量的平方根

VAR_POP       ：该函数返回非空集合的总体变量（忽略null）

VAR_SAMP    ：该函数返回非空集合的样本变量（忽略null）

VARIANCE     ：如果表达式中行数为1，则返回0，如果表达式中行数大于1，则返回VAR_SAMP

COVAR_POP   ：返回一对表达式的总体协方差

COVAR_SAMP ：返回一对表达式的样本协方差

CORR        ：返回一对表达式的相关系数

CUME_DIST   ：计算一行在组中的相对位置

NTILE        ：将一个组分为"表达式"的散列表示（类于Hive的分桶原理）

PERCENT_RANK ：和CUME_DIST（累积分配）函数类似

PERCENTILE_DISC ：返回一个与输入的分布百分比值相对应的数据值

PERCENTILE_CONT ：返回一个与输入的分布百分比值相对应的数据值

RATIO_TO_REPORT ：该函数计算expression/(sum(expression))的值，它给出相对于总数的百分比

REGR_ (Linear Regression) Functions ：这些线性回归函数适合最小二乘法回归线，有9个不同回归函数可使用

四.行比较分析函数

LAG         ：可以访问结果集中的其它行而不用进行自连接      -- 落后 -- lag(xx,1,0)

LEAD      ：LEAD与LAG相反，LEAD3可以访问组中当前行之后的行    -- 领先 -- lead(xx,1,0)

lag(field, N) 取前N行的值

lead(field, N) 取后N行的值

注意:取前/后N行的值是当前行往前/后数第n行的值

first_value，取分组内排序后，截止到当前行，第一个值

根据组内排序获得第一行的

last_value，取分组内排序后，截止到当前行，最后一个值

也就是当前行的值

 

concat_ws：实现多行记录合并成一行

collect_set：对记录去重

collect_list：不对记录去重

 

分析函数的语法结构一般是：

分析函数名(参数) OVER (PARTITION BY子句 ORDER BY子句 ROWS/RANGE子句)

分析函数名：sum、max、min、count、avg等聚集函数,或lead、lag行比较函数 或 排名函数等；

over：关键字，表示前面的函数是分析函数，不是普通的集合函数；

分析子句：over关键字后面挂号内的内容；分析子句又由以下三部分组成：

partition by：分组子句，表示分析函数的计算范围，不同的组互不相干；

ORDER BY：排序子句，表示分组后，组内的排序方式；

ROWS/RANGE：窗口子句，是在分组(PARTITION BY)后，组内的子分组（也称窗口），是分析函数的计算范围窗口。窗口有两种，ROWS和RANGE；

 

 

 

range是逻辑窗口，是指定当前行对应值的范围取值，行数不固定，只要行值在范围内，对应列都包含在内。

rows是物理窗口，即根据order by 子句排序后，取的前N行及后N行的数据计算（与当前行的值无关，只与排序后的行号相关）。“ROWS” 是按照行数进行范围定位的，而“RANGE”则是按照值范围进行定位的，这两个不同的定位方式 主要用来处理并列排序的情况     前后遇到相同的值的时候会进行累加

 

 

1）同时存在

 spark.sql("""

 SELECT cookieid, createtime, pv,

        SUM(pv) OVER(PARTITION BY cookieid ORDER BY createtime) AS pv1

 FROM t1

 """).show

正常显示

2) partition by出现

       spark.sql("""

       SELECT cookieid, createtime, pv,

              SUM(pv) OVER(PARTITION BY cookieid ) AS pv1

       FROM t1

       """).show

没有排序仅分组内没有一个个迭代计算

都是分组的计算值

3) order by 出现

只有排序 两两相加再加上,上一个的和(两两是计算机分组的数)

4) 都没有

显示总计算值