partition

一、kafka基础介绍 Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一，Kafka可以实现高效文件存储，实际应用效果极好。 1.1） kafka名词解释（架构的四个部分） - producer：生产者。 - consumer：消费者。 - topic: 消息以topic为类别记录,Kafka将消息种子(Feed)分门别类,每一类的消息称之为一个主题(Topic)。 - broker：以集群的方式运行,可以由一个或多个服务组成

学习kafka必会名词 producer：生产者，就是它来生产“鸡蛋”的。 consumer：消费者，生出的“鸡蛋”它来消费。 topic：你把它理解为标签，生产者每生产出来一个鸡蛋就贴上一个标签（topic），消费者可不是谁生产的“鸡蛋”都吃的，这样不同的生产者生产出来的“鸡蛋”，消费者就可以选择性的“吃”了。相当于“队列” broker：就是篮子了。 kafka的架构 一个典型的Kafka包含若干Producer，若干broker（Kafka支持水平扩展，一般broker越多，吞吐量越高），若干Consumer Group，以及一个zookeeper集群，通过zookeeper管理集群配置，选举leader，Producer使用push将消息发送到broker，Consumer使用pull模式从broker订阅并消费消息。 Kafka会为每一个Consumer Group保留一些metadata信息——当前消费的消息的position，也即offset。这个offset由Consumer控制。正常情况下Consumer会在消费完一条消息后递增该offset。 使用Consumer high level API时，同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。 优化：

1、row_number() over()排序功能： （1） row_number() over()分组排序功能： 在使用 row_number() over()函数时候，over()里头的分组以及排序的执行晚于 where group by order by 的执行。 partition by 用于给结果集分组 ，如果没有指定那么它把整个结果集作为一个分组，它和聚合函数不同的地方在于它能够返回一个分组中的多条记录，而聚合函数一般只有一个反映统计值的记录。 例如：employee,根据部门分组排序。 SELECT empno,WORKDEPT,SALARY, Row_Number() OVER (partition by workdept ORDER BY salary desc) rank FROM employee -------------------------------------- A00 152750 1 A00 66500 2 A00 49250 3 A00 46500 4 A00 39250 5 B01 94250 1 C01 98250 1 C01 73800 2 　　 （2）对查询结果进行排序：（无分组） SELECT empno,WORKDEPT,SALARY, Row_Number() OVER (ORDER BY salary desc) rank

[root@localhost xiaofeng]# fdisk -l 磁盘 /dev/sdb：2147 MB, 2147483648 字节，4194304 个扇区 Units = 扇区 of 1 * 512 = 512 bytes 扇区大小(逻辑/物理)：512 字节 / 512 字节 I/O 大小(最小/最佳)：512 字节 / 512 字节 磁盘 /dev/sda：16.1 GB, 16106127360 字节，31457280 个扇区 Units = 扇区 of 1 * 512 = 512 bytes 扇区大小(逻辑/物理)：512 字节 / 512 字节 I/O 大小(最小/最佳)：512 字节 / 512 字节 磁盘标签类型：dos 磁盘标识符：0x00076ca1 设备 Boot Start End Blocks Id System /dev/sda1 * 2048 411647 204800 83 Linux /dev/sda2 411648 30408703 14998528 83 Linux /dev/sda3 30408704 31457279 524288 82 Linux swap / Solaris 使用fdisk -l命令查看硬盘有没有被识别。 使用fdisk命令分区： [root@localhost xiaofeng]#fdisk /dev/sdb

背景 本文针对的是Win10与Ubuntu分别装在双硬盘的情况下完全删除Ubuntu的方法，仅供参考，目的是为了记录自己的经验。 双系统的安装过程详见 双硬盘双系统安装Ubuntu18.04 . 本文参考：https://blog.csdn.net/L_smartworld/article/details/88590780 1.查看电脑分区信息 在Win10系统下，对 我的电脑 右键，选择 管理 ，选择其中的 磁盘管理 可以直接删除分配给Ubuntu的所有分区(Ubuntu的EFI分区除外) 接下来要做的就是删除EFI分区以及修改win10的EFI分区(不修改的话还会有Ubuntu启动项)。 删除Ubuntu的EFI分区 直接用windows下的diskpart来删除 首先用管理员权限打开 cmd ，输入 diskpart ，利用 list disk 查询磁盘信息 这里我们Ubuntu装在磁盘1中，所以选择磁盘1 select disk 1 ，然后查看磁盘1下所有分区信息 list partition ，可以看到我们Ubuntu的EFI分区为488MB，根据分区大小这里选择分区4 select partition 4 ，然后删除它 delete partition override 。 删除之后，可以在Win10的 磁盘管理 中发现多了一块未分配的硬盘空间

create table ware_retail_part --创建一个描述商品零售的数据表 ( id integer primary key,--销售编号 retail_date date,--销售日期 ware_name varchar2(50)--商品名称 ) partition by range(retail_date) ( --2011年第一个季度为part_01分区 partition par_01 values less than(to_date('2011-04-01','yyyy-mm-dd')) tablespace TBSP_1, --2011年第二个季度为part_02分区 partition par_02 values less than(to_date('2011-07-01','yyyy-mm-dd')) tablespace TBSP_1, --2011年第三个季度为part_03分区 partition par_03 values less than(to_date('2011-10-01','yyyy-mm-dd')) tablespace TBSP_2, --2011年第四个季度为part_04分区 partition par_04 values less than(to_date('2012-01-01','yyyy-mm-dd'))

一、什么是Shuffle机制 在MapReduce中，shuffle更像是洗牌的逆过程，指的是将map端的无规则输出按指定的规则“打乱”成具有一定规则的数据，以便reduce端接收处理。其在MapReduce中所处的工作阶段是 map输出后到reduce接收前 ，具体可以分为map端和reduce端前后两个部分。在shuffle之前，也就是在map阶段，MapReduce会对要处理的数据进行分片（split）操作，为每一个分片分配一个MapTask任务。接下来 map()函数会对每一个分片中的每一行数据进行处理得到键值对（key,value），其中key为偏移量，value为一行的内容 。此时得到的键值对又叫做“中间结果”。此后便进入shuffle阶段，由此可以看出shuffle阶段的作用是处理“中间结果”，Shuffle机制是整个MapReduce框架中最核心的部分。 二、Shuffle的执行阶段流程 上图是官方对Shuffle过程的描述，通过图片我们可以大致的了解到Shuffle的工作流程。Shuffle并不是Hadoop的一个组件，只是map阶段产生数据输出到reduce阶段取得数据作为输入之前的一个过程。 所以Shuffle阶段应该分为map之后（ map的shuffle阶段 ）以及 reduce之前（ reduce的shuffle阶段 ），如下图所示： 1

Oracle数据库分区是作为Oracle数据库性能优化的一种重要的手段和方法，做手头的项目以前，只聆听过分区的大名，感觉特神秘，看见某某高手在讨论会上夸夸其谈时，真是骂自己学艺不精，最近作GPS方面的项目，处理的数据量达到了几十GB，为了满足系统的实时性要求，必须提高数据的查询效率，这样就必须通过分区，以解燃眉之急! 先说说分区的好处吧! 1) 增强可用性：如果表的某个分区出现故障，表在其他分区的数据仍然可用; 2) 维护方便：如果表的某个分区出现故障，需要修复数据，只修复该分区即可; 3) 均衡I/O：可以把不同的分区映射到磁盘以平衡I/O，改善整个系统性能; 4) 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索速度。 Oracle数据库提供对表或索引的分区方法有三种： ü 范围分区 ü Hash分区(散列分区) ü 复合分区 一、范围分区详细说明 范围分区就是对数据表中的某个值的范围进行分区，根据某个值的范围，决定将该数据存储在哪个分区上。如根据序号分区，根据时间等来进行分区。根据序号，比如小于2000000的放在part01, 2000000~4000000的放在part02。。。 create table AAA ( id number primary key, indate date not null ) partition by range

一. 创建数据库 CREATE DATABASE [IF NOT EXISTS] database_name [COMMENT database_comment] [LOCATION hdfs_path] [WITH DBPROPERTIES (property_name=property_value, ...)]; 字段解释: 1). IF NOT EXISTS : 避免要创建的数据库已经存在 2). COMMENT : 给数据库添加一个备注 3). LOCATION : 如果不指定路径,默认的存储路径是HDFS的/user/hive/warehouse/*.db 4). WITH DBPROPERTIES : 给数据库添加一些自定的<key,value> create database if not exists hive_db comment 'my fisrt database' location '/first_database' with dbproperties ('createtime' = '20181218'); Hive默认不支持中文,但是可以改 1). 修改hive_site.xml中的参数 <property> <name>javax.jdo.option.ConnectionURL</name> <value>jdbc:mysql://hadoop102

1.分区 mysql数据库中的数据是以文件的形势存在磁盘上的，默认放在/mysql/data下面（可以通过my.cnf中的datadir来查看），一张表主要对应着三个文件，一个是frm存放表结构的，一个是myd存放表数据的， 一个是myi存表索引的。如果一张表的数据量太大的话，那么myd,myi就会变的很大，查找数据就会变的很慢，这个时候我们可以利用mysql的分区功能， 在物理上将这一张表对应的三个文件，分割成许多个小块，这样呢，我们查找一条数据时，就不用全部查找了，只要知道这条数据在哪一块，然后在那一块找就行了。 如果表的数据太大，可能一个磁盘放不下，这个时候，我们可以把数据分配到不同的磁盘里面去 分区的二种方式 a，横向分区 什么是横向分区呢？就是横着来分区了，举例来说明一下，假如有100W条数据，分成十份，前10W条数据放到第一个分区，第二个10W条数据放到第二个分区，依此类推。也就是把表分成了十分，根用merge来分表，有点像哦。取出一条数据的时候，这条数据包含了表结构中的所有字段，也就是说横向分区，并没有改变表的结构。 b，纵向分区 什么是纵向分区呢？就是竖来分区了，举例来说明，在设计用户表的时候，开始的时候没有考虑好，而把个人的所有信息都放到了一张表里面去，这样这个表里面就会有比较大的字段，如个人简介，而这些简介呢，也许不会有好多人去看，所以等到有人要看的时候