partition

1、自建yum仓库，分别为网络源和本地源 出于安全起见，有些企业内部服务器使用本地局域网而不连接外网，为了安装一些服务，就需要搭建本地的yum仓库； 在系统安装盘内，已经自带了大量必要的安装包，可以用做本地yum仓库的源； 作为yum仓库服务器的主机配置 ： 先把原来系统相关的配置文件归置存放 [root@mini71 ~]#mkdir /etc/yum.repos.d/bak [root@mini71 ~]#mv /etc/yum.repos.d/* /etc/yum.repos.d/bak/ 然后编辑以光盘路径为yum源的配置文件 [root@mini71 ~]#cat /etc/yum.repos.d/base.repo [base] name=cdrom baseurl=file:///mnt/cdrom/ gpgcheck=0 配置epel源（作为扩展，可以不配置） [root@mini71 ~]#cat /etc/yum.repos.d/epel.repo [aliyun.epel] name=aliyun epel baseurl=https://mirrors.aliyun.com/epel/7/x86_64/（这里选择里阿里云的epel源，也可以选择其他的） gpgcheck=0 enabled=1（通过修改此项为0，即可关闭epel源） 安装http服务，启动

一： Hadoop Streaming详解 1、Streaming的作用 Hadoop Streaming框架，最大的好处是， 让任何语言编写的 map, reduce 程序能够在hadoop 集群上运行 ；map/reduce程序只要遵循从标准输入stdin读，写出到标准输出stdout即可 其次，容易进行单机调试，通过管道前后相接的方式就可以模拟streaming, 在本地完成map/reduce程序的调试 # cat inputfile | mapper | sort | reducer > output 最后，streaming框架还 提供了作业提交时的丰富参数控制 ，直接通过streaming参数，而不需要使用java语言修改；很多mapreduce的高阶功能，都可以通过steaming参数的调整来完成 2、Streaming的局限 Streaming 默认只能处理文本数据Textfile ，对于二进制数据，比较好的方法是将二进制的key, value进行base64编码，转化为文本 Mapper和reducer的前后都要进行标准输入和标准输出的转化 ，涉及数据拷贝和解析，带来了一定的开销 3、Streaming命令的相关参数 (普通选项、streaming选项) Streaming命令的形式如下： # /usr/local/src/hadoop-1.2.1/bin

转载自 技术世界 ，原文链接 Kafka设计解析（七）- Kafka Stream 本文介绍了Kafka Stream的背景，如Kafka Stream是什么，什么是流式计算，以及为什么要有Kafka Stream。接着介绍了Kafka Stream的整体架构，并行模型，状态存储，以及主要的两种数据集KStream和KTable。并且分析了Kafka Stream如何解决流式系统中的关键问题，如时间定义，窗口操作，Join操作，聚合操作，以及如何处理乱序和提供容错能力。最后结合示例讲解了如何使用Kafka Stream。 目录 一、Kafka Stream背景 1. Kafka Stream是什么 2. 什么是流式计算 3. 为什么要有Kafka Stream 二、Kafka Stream架构 1. Kafka Stream整体架构 2. Processor Topology 3. Kafka Stream并行模型 4. KTable vs. KStream 5. State store 三、Kafka Stream如何解决流式系统中关键问题 1. 时间 2. 窗口 3. Join 4. 聚合与乱序处理 5. 容错 四、Kafka Stream应用示例 五、总结 一、Kafka Stream背景 1. Kafka Stream是什么 Kafka Stream是Apache

原创文章，转载请务必将下面这段话置于文章开头处。（已授权 InfoQ中文站发布 ） 　　本文转发自 Jason's Blog ， 原文链接 　 http://www.jasongj.com/2015/08/09/KafkaColumn4 摘要 本文主要介绍了Kafka High Level Consumer，Consumer Group，Consumer Rebalance，Low Level Consumer实现的语义，以及适用场景。以及未来版本中对High Level Consumer的重新设计--使用Consumer Coordinator解决Split Brain和Herd等问题。 High Level Consumer 很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被所有Consumer消费（广播）。因此，Kafka Hight Level Consumer提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节并提供丰富的语义。 Consumer Group High Level Consumer将从某个Partition读取的最后一条消息的offset存于Zookeeper中( Kafka从0.8.2版本

Kafka 是一个分布式流式处理平台。 三个关键功能： 消息队列：发布和订阅消息流，这个功能类似于消息队列，这也是 Kafka 也被归类为消息队列的原因。 容错的持久方式存储记录消息流： Kafka 会把消息持久化到磁盘，有效避免了消息丢失的风险·。 流式处理平台： 在消息发布的时候进行处理，Kafka 提供了一个完整的流式处理类库。 Kafka 主要有两大应用场景： 消息队列 ：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。 数据处理： 构建实时的流数据处理程序来转换或处理数据流。 和其他消息队列相比,Kafka的优势 我们现在经常提到 Kafka 的时候就已经默认它是一个非常优秀的消息队列了，我们也会经常拿它给 RocketMQ、RabbitMQ 对比。我觉得 Kafka 相比其他消息队列主要的优势如下： 极致的性能 ：基于 Scala 和 Java 语言开发，设计中大量使用了批量处理和异步的思想，最高可以每秒处理千万级别的消息。 生态系统兼容性无可匹敌 ：Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域。 队列模型与Kafka 的消息模型 队列模型：早期的消息模型 使用队列（Queue）作为消息通信载体，满足生产者与消费者模式，一条消息只能被一个消费者使用，未被消费的消息在队列中保留直到被消费或超时。 比如：我们生产者发送 100

往hive分区表中插入数据时，如果需要创建的分区很多，比如以表中某个字段进行分区存储，则需要复制粘贴修改很多sql去执行，效率低。因为hive是批处理系统， 所以hive提供了一个动态分区功能，其可以基于查询参数的位置去推断分区的名称，从而建立分区。 1.创建一个单一字段分区表 1 hive> 2 create table dpartition(id int ,name string ) 3 partitioned by(ct string ); 2.往表里装载数据，并且动态建立分区，以city建立动态分区 1 hive> 2 hive.exec.dynamici.partition=true; #开启动态分区，默认是false 3 set hive.exec.dynamic.partition.mode=nonstrict; #开启允许所有分区都是动态的，否则必须要有静态分区才能使用。 4 insert overwrite table dpartition 5 partition(ct) 6 select id ,name,city from mytest_tmp2_p; 7 8 要点：因为dpartition表中只有两个字段，所以当我们查询了三个字段时（多了city字段），所以系统默认以最后一个字段city为分区名，因为分区表的 9 分区字段默认也是该表中的字段

mr spark storm 都是分布式计算框架，他们之间不是谁替换谁的问题，是谁适合做什么的问题。 mr特点，移动计算，而不移动数据。 把我们的计算程序下发到不同的机器上面运行，但是不移动数据。 每一个split 是由一个map线程，还是map进程进行处理？ 肯定的是，他们之间是并发的。 mr的shuffle阶段，是比较难于理解的，不太便于我们去控制他，我们只能通过程序，控制其中的一部分。shuffle阶段，大多数都是有MR框架自动完成的。 溢写到磁盘中：map执行完成，结果肯定是放在内存中的。 所以达到一定数量之后，就需要溢写到磁盘中。在这之前，需要进行分区（partition）和把当前这个map的输出数据进行排序(sotred) 所以说，写到磁盘中的数据已经分好区了，并且已经排好序了。这都是在map任务所在节点的本地执行的。 其中partition暂时没有体现出作用。而是在fetch的过程中提现出来的。是按照什么 进行分区的呢？是看partition是怎么写的。partition可以由程序员自己写。按照程序员自己的规则实现。也可以不写，有默认的分区规则。默认分区规则是hash模运算（1,获取hash值 ，是一个int。2，把这个int值对reduce的个数取模），默认的partition是有可能产生数据倾斜的。比如有两个reduce，没所有map产生的所有结果取模的时候

1.创建测试表： SQL> create table test (id int,name varchar(20)); SQL> begin for i in 1..10000 loop insert into test values (i,'aa'||i); commit; end loop; end; / 2.导出数据： [dmdba@localhost ~]$ dexp sysdba/SYSDBA file=/dm7/test.dmp tables=test 3.删除非分区表： SQL> drop table test; 4.创建分区表： create table test ( id int, name varchar(20) ) partition by range (id)( partition p1 values less than (200), partition p2 values less than (400), partition p3 values less than (600), partition p4 values less than (maxvalue) ) ; 5.导入数据： [dmdba@localhost ~]$ dimp sysdba/SYSDBA file=/dm7/test.dmp tables=test ignore=y 来源： 51CTO

在谈论分区表这个话题之前，先和大家分享一个案例： 2008 年秋天的某天，我的团队接到成都市 XX 局一个 SQL 调优的 ESS 单子。客户反映查询统计一次各地市局上报的数据汇总，需要 6 到 15 秒才能获得真正想要的数据，当我和销售人员赶到客户数据中心现场后，发现里面布置了很多柜式服务器，每台服务器都是 8 核 16G 内存。和相关技术负责人沟通以及演示业务系统之后，可以肯定不是服务器性能的问题，我详细分析了他们的数据库，统计慢的几张表往往一周的上报数据便会增加 1 百多万行，导致他们这个系统刚上线没多久，某些表产生的数据已经在 2000 万行以上，最终我提出了优化方案，业务逻辑层采用存储过程代替普通的 SQL 语句，并启用相关开发平台的缓存技术；数据库系统中采用增强索引和规划分区表进行优化，最终问题解决。 事实上数据库性能优化是每个优秀的数据库工程师必须具备的素质之一，而这一节讨论的分区表便是性能调优的一种技术。在企业级应用系统中，一个表存储 2 千万行的数据很常见，不可预期的数据也会在逐渐增长，所以数千万级别的表 DBA 会常常碰到，而 TB 级别的数据最终也在所难免，因此了解和掌握性能调优的 18 般兵器非常重要。 我计划用三篇博文介绍分区表这个主题，分别为： 1， 分区表理论解析 2， 实战分区表 3， 分区表前传 大凡在应用系统和数据库系统中行走江湖多年的朋友

动态分区插入可以基于查询语句分出出要插入的分区名称。比如，下面向分区表插入数据的SQL： insert into table chavin.emp_pat partition(dname,loc) select e.empno,e.ename,e.job,e.mgr,e.hiredate,e.sal,e.comm,e.deptno,d.dname,d.loc from dept d join emp e on d.deptno=e.deptno; hive会根据select字段的最后两个字段确定分区字段的值（上面sql中即根据d.dname,d.loc的值确定partition(dname,loc)中dname和loc的值），分区字段值的确定是根据位置而不是根据内容确定的，这点尤其需要注意。当然，对于多分区表的插入，可以混合使用静态分区和动态分区的方法，并且静态分区字段必须出现在动态分区字段之前，如下： insert into table chavin.emp_pat partition(dname=' NEW YORK',loc) select e.empno,e.ename,e.job,e.mgr,e.hiredate,e.sal,e.comm,e.deptno,d.dname,d.loc from dept d join emp e on d.deptno=e.deptno