时间 | 内容 |
---|---|
2020年4月10日 | 第一次发布 |
2020年4月16日 | 添加MaxCompute SQL部分 |
2020年9月14日 | 新增数仓部分笔记 |
集群:多个人做同样的事
分布式:多个人协作,干不同的事情。
Hadoop:Hadoop是一个分布式存储和计算框架,具有高可靠, 高扩展, 高容错的特点(数据副本和集群);由底层HDFS分布式文件系统负责存储,和MapReduce负责分布式计算,以及后续增加的yarn负责资源协调管理。
Yarn:yarn是hadoop2.0为了分离资源管理和计算组件而引入的,yarn的诞生源于存储在HDFS的数据需要更多的交互模式,能提供更多的处理框架,而不单单是MR模式。
ZooKeeper:是一个分布式的,开放源码的,用于分布式应用程序的协调服务(service),基于观察者模式,接受观察者的注册,然后监听数据变化。
Hive:是由FaceBook开源的一个数据仓库工具,主要用于解决海量结构化日志的数据统计,可以将结构化的数据文件映射成一张表,并提供类似于SQL的查询方式来统计分析海量数据(主要离线分析),本质上是将HSQL转化成MapReduce程序。
参考文章:
《hadoop之hadoop用途方向》:https://blog.csdn.net/zhang123456456/article/details/77657807
《大数据基本概念》:https://www.sohu.com/a/259640251_741445
简述的过程是:
安装CentOS7虚拟机 --> 配置IP、hosts文件和时间同步 --> 设置免秘钥登录 --> 安装hadoop --> 格式化hadoop --> 启动hadoop和运行mr程序。
hdfs namenode -format 格式化的时候失败过,一开始是ssh免秘钥登录的问题,后面又是yarn-site.xml配置文件的格式问题,最好从其它地方粘贴的配置代码先用工具格式化一下,并检查里面是否有中文符号。
另一个坑是虚拟机联网问题,我这里是用自定义网络然后选的vm-ware8,集群的IP一定要在同一网段,并且网关要和物理机上vm-ware8的IP地址相关联。
Hadoop由三部分组成:HDFS、分布式计算MapReduce和资源调度引擎Yarn。
HDFS 是一个分布式文件系统,负责文件存储。它的文件系统和平时看到的Linux很像,有目录结构,顶层目录是/,存放着文件,以及可以对文件进行增删,修改,移动等功能,不同的是它具有分布式的特点,hdfs的文件系统可以横跨多个机器,文件可能是存储在不同机器上的,但用户在使用时会被当作是存储在一台机器上。
HDFS具有高可用、容错率高、可扩展的特点。
在HDFS中有一个核心概念-block块。
HDFS上的文件,是按照128M为单位,切分成一个个block的,分散的存储在集群的不同数据节点上。128M是指上限,实际可能block文件的大小不到128M。
而为了保证数据的可用及容错,每一个block都可以设置副本数,默认是3,在集群搭建中,在hdfs-site.xml文件就可以设置默认副本数。每一个block的副本并不会存放在同一个服务器上面,而是分开存储在不同服务器,假如第一个block块暂时奔溃了,HDFS的主节点就会为了维持设置的block副本数,会重新在其它服务器上创建一模一样的block1。
HDFS的体系架构是典型的主从架构Master/Slave,有客户端和服务端,客服端通过NameNode主节点来访问存放在各个DataNode上的文件信息,NameNode负责管理每个子节点,同时还有secondaryNameNode做备份主节点。
在NameNode管理每个DataNode过程中,有心跳机制能让namenade周期性地从集群中的每个datanode接受心跳信号和块状态报告,以便得知各集群节点是否正常运行,同时在hadoop集群刚启动时也会用到心跳机制,此时会先进入一个安全模式,等心跳确认99.9%的节点都正常后才进行正常工作,允许外界写入文件到HDFS。
HDFS有一个重要特性,那就是高可用,实现高可用最关键的是消除单点故障,会用到刚才体系架构中提到的SecondaryNamenode,概括来说就是当处于active状态的Namenode节点出问题后,他们之间有zookeeperFC会通知另一个暂时处于Standby状态的SecondaryNamenode准备替换工作,zookeeperFC是用来协调监控NameNode的,通知后原来的NameNode变成Standby状态,而SecondaryNamenode进行运行工作。
HDFS的联邦对应于HDFS的可拓展的特点,可以解决内存受限的问题,提高吞吐量和隔离不同类型的应用,但一般集群规模达到几千台的情况下才可能用到联邦(联邦,即支持多个NameNode主节点,每个Namenode分管一部分的元数据目录,并共享所有datanode存储资源)。
至此HDFS概括性介绍完毕,对于HDFS的读写流程请翻看其它回答。
HDFS的机制是指它的心跳机制,我们知道HDFS是典型的Master/Slave主从架构,由一个Namenode管理多个Datanode过程中HDFS会用到它的心跳机制,其工作原理如下:
心跳机制的作用有三点:
(1)Namenode通过心跳机制全权管理数据,它周期性地从集群中的每个namenode接受心跳信号和块状态报告,有心跳意味着从节点工作正常,块状态报告中也会有该datanode上所有数据的列表。
(2)Datanode启动后向Namenode注册,并通过心跳上报数据块列表,3秒发送一次心跳,返回并执行Namenodede命令,如果10分钟都没有发送,代表这个Datanode出问题不可用。
(3)hadoop集群刚启动时会进入一个安全模式,这个安全模式也会用到心跳机制,只有Namenode得到99.9%datanode的反馈后安全模式才会解除。
HDFS读流程
HDFS写流程
客户端要向HDFS写数据,首先要跟namenode通信以确认可以写文件并获得接收文件block的datanode,然后,客户端按顺序将文件逐个block传递给相应datanode,并由接收到block的datanode负责向其他datanode复制block的副本。
在写入数据的过程中,底层会有一个data queue队列和ack queue队列,写入数据时,block块是按一个一个字节来将数据写入到一个名为chunk的小块(chunk中包含4byte的校验值),写满chunk后再放到一个package中,后续每个package要加入到data queue队列。
data queue中的package会逐步被发送到对应的datanode及其副本,同时还会复制一份写到ack queue队列中。待package写入完成后会重新生成校验值,这时拿新的校验值和ack queue中的package的校验值一一比对,如果比对成功,ack queue就删除对应package,如果比对不成功那么ack就把package发送回data queue再传输写入一次。
首先Namenode存储着文件系统的元数据,元数据记录了文件、块、目录,大约占150字节大小。如果hdfs的小文件过多,那么会占用元数据中记录文件的内存,给Namenode造成压力,影响hadoop存储和访问的效率。
通常可以通过两种方法处理:
HAR文件方案:启动mr程序,通过hadoop archive命令将小文件压缩成一个har文件,适用于文件归档。
Sequence Files方案:还不太会用,暂不说明。
block的大小是由磁盘传输速度决定的,比如磁盘传输速度是200MB/S,那么block一般设定256MB。
如果block太大,那么从磁盘传输数据的时间会明显变慢,另一方面,mapreduce中的map任务一般一次处理一个block块,如果块过大,mr的处理速度也会变慢。
如果block太小,那么就会跟hdfs存储大量小文件的问题一样,会给namenode造成内存的压力。
MapReduce的shuffle过程实际上包含在map阶段和reduce阶段,也就是Map Shuffle和Reduce Shuffle;
Combiner为了避免map task和reduce task之间的数据传输压力而设置的,它允许用户针对map task的输出指定一个合并函数,这个函数可以压缩具有同一key值的键值对,从而减少传输到reduce的数据量,减少网络带宽和reduce的负载。
但实际上combiner是作为可选项,有没有设置或者设置多少次都不会影响最终结果,在shuffle过程中会判断是否设置而进行压缩。
数据倾斜有两种原因:(1)某一个key对应的键值对数量要远远大于其它键的键值对数量;(2)部分数据记录的大小远超过平均值。
可以在MR程序的reduce方法中追踪每个键的最大值,并且设置阈值,当超过该阈值时就可以认为发生了数据倾斜,可以输出到日志文件进行分析。
第二种是很对编写MR程序时,从业务层面去考虑自定义的分区键是否合理。就跟ADS库建表时可以默认指定哪个字段作为分区键。
MR程序中改用TotalOrderPartitioner替换HashPartitioner,它可以通过对原始数据进行抽样得到的结果集来预设分区边界值,也就是能找出导致数据倾斜的key值,再分散处理。
MR程序中使用Combiner。
MapReduce是采用一种分而治之的思想设计出来的分布式计算框架,它由两个阶段组成:map阶段和reduce阶段。
在map阶段中:
在reduce阶段中:
Yarn的框架也是经典的主从结构,和HDFS的一样,大体上yarn由一个ResourceManager和多个NodeManager构成,RM为主节点,NM为从节点。
ResourceManager是一个全局的资源管理器,负责整个系统的资源调度管理和分配,包括处理客户端请求、启动并监控ApplicationMaster,监控NodeManager,以及分配和调度资源。
在ResourceManager中由两个组件构成: Schedule调度器和ApplicationManager应用程序管理器
ApplicationMaster负责管理yarn内运行的应用程序的每个实例,负责协调来自ResourceManager的资源,并通过NodeManager监控容器的执行和资源使用情况。
NodeManager在集群上有多个,它负责每个节点上的资源使用,处理ApplicationManager的请求,以及负责接受ResourceManager的资源分配命令,分配具体的Container给应用,同时还将Container的使用情况报告给ResourceManager。
这里的Container实际上是一个资源抽象概念,代表系统上分配的资源,包括内存、磁盘、IO等。
具体过程如下:
当客户端应用程序向ResourceManager提交应用需要的资源请求后,ResourceManager中的ApplicationManager接受到请求,并返回一个Container给NodeManger,告诉NodeManager启动一个ApplicationMaster实例。
ApplicationMaster启动后向ResourceManager注册,此时客户端可以和ApplicationMaster直接交互,并告诉它需要的资源请求;后续ApplicationMaster继续发送资源请求给ResourceManager,待ResourceManager的Schedule处理后返回具体的Container信息,ApplicationMaster接收到资源信息后会分配给各个NodeManager来启动运行job任务(比如mr程序,内部是多个map task、reduce task)。
在运行过程中,客户端和ApplicationMaster保持交互,可以得知程序的运行情况。ApplicationMaster此时主要监控和管理任务运行,而NodeManager会定时向ResourceManager汇报自身的运行状况和Container的使用信息,待程序运行完毕后,ApplicationMaster关闭,并向ResourceManager归还所有Container。
概括来说其过程如下:
应用程序提交 --> 申请资源 --> 启动ApplicationMaster --> 申请运行任务的Container --> 分
发Container --> 运行task任务 --> task任务结束 --> 回收Container。
另外还有JobHistoryServer(作业历史服务,记录在yarn中调度的作业历史运行情况) 和 Timeline Server(写日志数据),需要手动开启。
是指多个应用程序的ApplicationMaster动态地和ResourceManager进行沟通,不断地申请资源,释放,再申请,再释放资源的过程。
yarn中有三种调度器选择:FIFO Scheduler(先进先出调度器),Capacity Scheduler(容量调度器),Fair Scheduler(均分调度器)
ZooKeeper是一个分布式的,开放源码的,用于分布式应用程序的协调服务。
Zookeeper有攘其外,安其内的特点,也就只指它内部和谐统一,外部一致对外。
攘其外是指Zookeeper服务端有两种模式:单机的独立模式和集群的仲裁模式,所谓仲裁是指一切事件只要满足多数派同意就执行,不需要等到集群中的每个节点反馈才执行。Zookeeper本身也是服从主从架构的,在仲裁模式下会有一个主要的节点作为Leader(领导者),而其余集群中的节点作为Follower(公民),对某一事件是否执行,leader都会先征询各个follower的反馈信息再做决定,如果多数派同意,leader就将命令下发到所有的follower去执行。
安其内是指Zookeeper的leader选举,leader的选举会发生在集群启动时和运行中leader挂了,概括选举过程也是少数服从多数选出新leader。
在Zookeeper中的数据结构也是个重要概念,因为Zookeeper所提供的服务主要是通过它以下三部分组成:
Zookeeper = Znode(数据节点,也是简约版文件系统)+ 原语(可以理解成Zookeeper的命令) + Watcher(通知机制,类似监听器)
Znode可以分为持久节点和临时节点,在用Zookeeper的命令create创建文件时默认时一个持久节点,而临时节点是会随着会话关闭而删除。另外也可以创建为有序节点,在创建时追加一个自增数字的标识。
Watcher通知机制类似于监听器的过程,即有注册 + 监听事件+ 回调函数,客户端在znode上注册一个Watcher监视器,当znode上数据出现变化,watcher监测到此变化就会通知客户端。在HDFS的HA高可用上也用到了Zookeeper的这种机制。
这会启动Zookeeper的状态同步过程。具体来说如下:
在完成leader选举后,各Follower和leader进行连接通信,并在每一次事务执行时,Follower都会把自己的最大事务ID发送给leader,当某个Follower出故障后,leader就根据原先该Follower发送的zxid确定同步点,向它同步记录最大zxid之后的内容。
当完成同步后,会通知Follower已成为为update状态,Follower受到update消息后,就可以重新接受客户端的请求继续工作。
Hive主要解决海量结构化日志的数据统计分析,它是hadoop上的一种数据仓库工具,可以将结构化的数据文件映射成一张表,并提供类似于SQL的查询方式,本质上来说是将Hive转化成MR程序。
Hive与其它数据库的区别:
Hive数据是存储在HDFS,本质上是转换成mr程序执行,因此查询效率比较慢,涉及mr程序的资源调度和任务计算;HDFS的数据操作是支持覆盖追加,它不支持update和事务;扩展性好,可以在多个集群上做应用开发;Hive的读时速度快,因为在加载数据时并不会做数据校验,在读取数据时才会校验数据;处理数据规模大,适合于海量数据查询。
Hive的优缺点:
Hive的架构原理
用户接口(shell、JDBC、Web UI) --> Driver(解析、编译、优化、执行)–> MR程序 --> hadoop集群
Hive的交互方式有三种:Hive交互Shell,Hive JDBC服务和Hive的命令
Hive交互Shell:直接输入在hive中/bin目录下的hive命令,进行sql查询
JDBC服务:
启动hiveServer2服务:bin/hive --service hiveserver2
然后 beeline命令连接hiveserver2:
bin/beeline
beeline> !connect jdbc:hive2://node1:10000
Hive命令:在hive命令后面加 -e 选项后,接sql查询语句即可。
bin/hive -e "show databases;"
Hive的数据类型和mysql的类似,常用的int、bigint、double、string、date、boolean,还有smallint、tinyint、float、varchar、timestamp,另外还有三种复合数据类型:array(数组),map(键值对),struct(一组命名的字段),复合类型在建表时需要特别指定。
Hive的建表操作
Hive数据的导入和导出
Hive数据导入:
第一种,用load data导入数据:
load data [local] inpath 'dataPath' override | into table student [partition 分区值];
第二种,创建表时指定location数据路径,后面如果该路径本身有数据会导入到表中,如果是空文件可以用手动上传数据文件到hdfs中:
hdfs fs -put /opt/bigdata/student.txt /user/hive/warehouse/student1
第三种,可以在建表时as select * from 某张表,也可以insert into|override table时select * from某张表。
最后一种是直接import table,导入某个数据文件,前提是数据文件要先export准备好。
Hive数据导出
第一种是insert导出:可以insert导出到本地或者hdfs,还可以指定导出文件后的分隔符
#加local导出到本地路径,默认文件分隔符时“\001”,之后本地会生成一个日志型的文件。
insert override local directory '/opt/bigdata/student';
#格式化导出文件
insert override local directory '/opt/bigdata/student' row format delimited fields terminated by ',';
#这里没有local
insert override directory '/export/student' row format delimited fields terminated by ',';
第二种是Hadoop命令直接下载,由于表和数据有映射关系,每张表在hdfs上都能找到对应数据存储位置,所以我们可以直接下载下来的,后期要检查下数据和分隔符是否有问题。
hdfs fs -get /usr/hive/warehouse/student/student.txt /opt/bigdata/data
第三种是Hive shell命令导出,hive命令后面加-e或-f选项,再加sql查询语句指定到某个目录下,比如:
#1.hive -e “sql语句” >> file; 这种是直接执行sql语句,把结果导出到文件中。
#2.hive -f "sql文件" > file; 这种是执行完sql文件后,将查询结果写入到file中
bin/hive -e 'select * from default.student;' >> /opt/bigdata/student.txt
最后一种是export导出到hdfs
hive>export table student to '/usr/hive/warehouse/student';
Hive的文件存储格式和压缩方式:这里不做介绍,因为了解不深,只知道hive的压缩可以发生在map shuffle阶段中向磁盘写数据时压缩,以及reduce输出结果时作压缩。企业有效方式文件存储压缩是采用orc + snappy方式。
Hive的SerDe 序列化和反序列化,是使用Serde对行对象序列化和反序列化,方便数据加载到表中,最后实现把文件内容映射到hive表。如下所示:
HDFS file -> InputFileFormat -> key,value -> Deserializer(反序列化) -> Row object
Row object -> Serializer(序列化) -> key,value -> OutputFileFormat -> HDFS file
建表时可以指定row format来使用SerDe。常用于企业解决多字符分割场景
最后Hive重要的一点是Hive的调优,参考下面另一个问题的答案:8. 数据倾斜现象和解决办法?(重要)
因为上传到hdfs后,hive没有对应元数据信息所以无法查询到对应数据。可以上传数据后给分区表添加该目录的分区
dfs -mkdir -p 分区目录
dfs -put 分区数据
hive>alter table 表明 add partition(分区);
不可以,因为load数据的话hdfs下只会有一个文件无法完成分桶的效果,需要通过中间表导入数据
不是越多越好
所以分区数要合理设计,一般在3个以内。
select * from order_partition where month = '2019-03';
set hive.exec.mode.local.auto = true;
Order by会对所给的全部数据进行全局排序,只启动一个reduce来处理。
Sort by是局部排序,它可以根据数据量的大小启动一到多个reducer来工作,并且在每个reduce中单独排序。
Distribute by 类似于mr中的partition,采用hash算法,在map端将查询结果中hash值相同的结果分发到对应的reduce中,结合sort by使用
Cluster by 可以看作是distribute by 和sort by的结合,当两者后面所跟的字段列名相同时,效果就等同于使用cluster by,但是cluster by最终的结果只能是降序,无法指定升序和降序。
1.首先创建对应分区表和一张普通表
2.然后将数据加载到普通表
load data local inpath '/opt/bigdata/order_partition' into table tt_order;
#先设置使用动态分区的参数和使用非严格模式
set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;
#然后通过普通表导入分区表
insert into table order_partition partition(year,month) select order_number,order_price,substring(order_time,0,4) as year,substring(order_time,6,12) as month from tt_order;
#注意导入的字段顺序,分区键一定要放在最后,否则会报错。
1.什么是数据倾斜?
大量相同特征的key出现在同一个reduce任务中,或者某个key对应的数据量远超过其它key的数据量,这种导致数据分布不均匀的现象就叫做数据倾斜。
2.数据倾斜的现象
在执行任务的时候,任务进度长时间卡在99%左右,查看任务监控页面或者详细日志信息,发现只有少量,一个或者几个reduce子任务没有跑完,主要因为这几个reduce任务处理的数据量和其它reduce任务差异过大。这种单一reduce任务的记录数与平均记录数差异过大,就会极大拖长计算时间。
现实工作中可能会遇到这样的情况比较多:比如大表join小表,其中小表有特别的key值比较集中,这样分发到某一个reduce上的数据就会高于平均值;或者是大表join大表中,作为连接判断的字段0值或者空值较多的,这些0值和空值后续都会由一个reduce处理,导致这个reduce处理量过多;再有的情况就是group by、**count( distinct )**某个字段值数据多而导致reduce处理耗时的情况。
3.数据倾斜的原因
4.数据倾斜的解决方案,有三个层面可以思考处理:
第一,SQL语句调优
查询语句加上具体需要的列和分区键,有些复杂表的字段会存储json格式的文本,这些字段不一定是需要查询的就可以过滤掉,减轻reduce计算负担
大表join小表时用map jion,让小表先进内存,然后大表与小表在map端完成join操作,避免reduce端处理。
大表join大表中,可以把空值的key变成一个字符串然后加上rand()随机数,后续mr的分区操作会把倾斜的数据重新分发到不同的reduce上,从而避免数据倾斜。或者在join 的on条件中先让key为空的值 不参与关联,等key不为空的数据相互合并连接后再union all加回key为空的数据。
select * from a left outer join b
on case where id is null then concat('任意字符串',rand()) else id end = b.id;
select * from log a join users b on a.id is not null and a.id = b.id
union all
selct * from log a where a.id is null;
查询语句中count(distinct) 改成group by + sum(),比如
select count(distinct id) from test; ==> select sum(id) from (select id from test group by id); 这种可能会多开一个reduce来完成group by的操作,但会明显提高查询速度。
针对不同数据类型产生的数据倾斜,存在这样的情况,A表中的id字段的数据类型是int,但join的B表中id字段存在脏数据,有一些是int类型但也有string类型的,那么再join操作时,默认的hash操作就会对int类型的key进行分配,而对于string类型的key会被统一分配到一个reduce中,这种情况就需要先进行类型转换,如 a join b on a.id = cast(b.id as int);
还有一些时候可以把数据倾斜的数据单独拿出来处理,然后再union all回去。
第二,通过设置hive参数配置解决,这种主要是优化计算速度,避免数据倾斜发生
开启map端聚合
并不是所有的聚合操作都需要在reducec端完成,很多聚合操作都可以现在map端先进行部分聚合,最后在reduce端得出最终结果(类似于mr过程中的combiner,预先合并压缩数据,再提供给reduce统计计算)
再hive开启map端聚合后,一旦发现数据倾斜,系统就能自动负载均衡,把相同特征的key分发到不同的reduce中,主要通过hive.groupby.skewindata参数完成。
#开启map端聚合的设置
#是否在map段進行聚合,默认是true
set hive.map.aggr = true
#在map端进行聚合操作的条目数目
set hive.groupby.mapaggr.checkinterval = 100000;
#有数据倾斜的时候进行负载均衡,比如把相同特征的key分发到不同的reduce中(默认是false)
set hive.groupby.skewindata = true;
设置并行执行
和oracle一样也可以利用并行执行提高查询速度,不同的是hive是靠参数来空值的
#开启并行执行
set hive.exec.parallel = true;
#设置同一个sql允许的最大并行度,默认是8
set hive.exec.parallel.thread.number = 16;
设置压缩
压缩可以在map端要进行shuffle时压缩和在完成reduce输出时压缩
#设置为true为激活中间数据压缩功能,默认是false,没有开启
set hive.exec.compress.intermediate = true;
#设置中间数据的压缩算法
set mapred map.output.compression = codec = org.apache.hadoop.io.compress.SnappyCodec;
set hive.exec.compress.output = true;
set mapred map.output.compression = codec = org.apache.hadoop.io.compress.SnappyCodec;
推测执行
说简单点就是Hadoop用了一个备份任务来同时执行,跟原来的任务相比较,谁先执行完成就用谁的计算结果作为最终的计算结果。具体定义如下:
Hadoop采用了推测执行机制,它根据一定的法则推测出”拖后腿“的任务,并为这样的任务启动一个备份任务,让备份任务和原始任务同时处理一份数据,并最后选择优先执行完成的任务计算结果作为最终结果。
#开启推测执行机制
set hive.mapred.reduce.tasks.speculative.exection = true;
JVM重用
JVM重用可以使得JVM实例在同一个job中重新使用多次,减少进程的启动和销毁时间
#设置jvm重用个数
set mapred.job.reuse.jvm.num.tasks = 5;
合理设置map数和reduce数
#系统默认的格式,可以不用设置。
set hive.input.format = org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
增加map方法有一个公式:
compute(SliteSize(Math.max(minSize,Math.min(maxSize,blocksizs))))公式
- 调整maxSize最大值,让maxSize小于blocksize就可以增加map数
- minSize默认等于1,maxSize默认等于blockSize大小。
#比如这样设置就可以达到增加map数的效果
#设置每个map处理的文件maxSize大小为10M,这样小于一个block128M的话,系统就会分配更多10M的map来处理复杂任务。
set mapreduce.input.fileinputformat.split.maxsize = 10485760;
set mapreduce.job.reduces = 3;
第三,修改MR程序去避免数据倾斜
可以在MR程序的reduce方法中追踪每个键的最大值,并且设置阈值,当超过该阈值时就可以认为发生了数据倾斜,然后输出到日志文件进行分析。
第二种是在编写MR程序时,从业务层面去考虑自定义的分区键是否合理。就跟ADS库建表时可以默认指定哪个字段作为分区键。
MR程序中改用TotalOrderPartitioner替换HashPartitioner,它可以通过对原始数据进行抽样得到的结果集来预设分区边界值,也就是能找出导致数据倾斜的key值,再分散处理。
MR程序中使用Combiner。
数据仓库是面向业务主题,为分析数据而设计的。
通俗来讲,数据仓库就像生活中的普通仓库一样,能对物品集中管理、分类摆放、按需取用,最终目的都是为了更方便和更快速地查询到想要的数据结果,提供数据支持和决策支持。
打比方:对多来源的数据做元数据管理就像对物品打标签一样,而ETL抽取的过程和数据分层建模的过程则类比物品分类摆放的过程,期间有些需要抽样研究的就作为数据挖掘和机器学习的数据,有些使用频率非常高的就单独拿来做实时查询,对于不怎么改动的历史数据就按主题抽取另外分析查询,而市面上像阿里云这类的平台工具就好比放物品的货架。
总结来说,它的特点有:
第一,面向主题:面向主题是指数仓中的数据是按照一定的业务主题划分组织的,能帮助用户做决策和分析探索。
第二,集成性:数仓的数据来源于其他源系统,可以使用各种ETL工具集成汇总到数仓。
第三,稳定性:数仓主要是为了决策分析,它存储大量的历史数据,一般只有新增,没有更新操作;
第四,时变性:时变性是指它具有时间属性,可以不断生成主题的新数据,比如按年月日的增量数据。
首先优化SQL的过程,实际上就是要尽可能减少IO读取,尽可能减少计算资源的使用,尽可能减少SQL复杂度,尽可能提升运行速度。
MaxCompute SQL适用于海量数据,实时性要求不高的场合,MaxCompute 作业提交后会有几十秒到数分钟不等的排队调度;采用的是类似与SQL的语法,可以看作是标准SQL的子集,但也有不同点,比如没有事务,主键约束,索引等。
有Bigint,double,String,datetime,Boolean,decimal类型。
可以设置分区表,还可以给表指定生命周期LifeCycle。
具体区别如下:
其它细微的区别用法详见官方文档。
首先优化SQL的过程,实际上就是要尽可能减少IO读取,尽可能减少计算资源的使用,尽可能减少SQL复杂度,尽可能提升运行速度。
工作中还用到的:
- 数据量达到千万级别的,尽量固化分区,不在查询sql里面进行动态分区,减少资源使用
- sql行数较长的,尽量拆分成工作流任务,可以优化性能和排查问题的难易度。
- 维度表要放到mapjoin里,加大资源利用率
- 数据倾斜较高的表,先落地成临时表
- 每日全量推送任务的,如果表级数据量较高的,分析是否可以改成增量模式。
MaxCompute SQL适用于海量数据,实时性要求不高的场合,MaxCompute 作业提交后会有几十秒到数分钟不等的排队调度;采用的是类似与SQL的语法,可以看作是标准SQL的子集,但也有不同点,比如没有事务,主键约束,索引等。
有Bigint,double,String,datetime,Boolean,decimal类型。
可以设置分区表,还可以给表指定生命周期LifeCycle。
具体区别如下:
其它细微的区别用法详见官方文档。
MaxCompute不支持删除列的。
参与Union All运算的所有列的数据类型和列个数、名称必须完全一致。
数据类型只能是bigint、double、boolean、datetime和string;
lifecycle建表时指明此表的生命周期,但create table like时并不会复制源表的生命周期;
create table … as select …语句创建的表不会复制分区属性,而是把源表的分区键作为目标表的一般列处理;如果希望和源表有相同表结构,建议使用create table … like …,然后再手动插入数据。
对于设置了生命周期的表,如果是非分区表,那么会从最后一次被修改的时间开始计算周期,周期时间到将会被MaxCompute自动回收,如果有数据更新,那么周期会重新刷新时间;如果是分区表,则细分到某个分区是否有被改动过,回收也只是针对某一个长时间为改动过的分区数据。
删除分区:ALTER TABLE … DROP [IF NOT EXISTS] PARTITION …;
添加列:ALTER TABLE … ADD COLUMNS();
修改列名:ALTER TABLE … CHANGE COLUMN…RENAME TO …
修改分区值:ALTER TABLE … PARTITION(分区=分区值) RENAME TO PARTITION(分区=分区值);
修改表的注释:ALTER TABLE…SET COMMENT ‘’;
修改表的生命周期:ALTER TABLE …SET LIFECYCLE = ‘’;
清空非分区表的数据:TRUNCATE TABLE ;如果是分区表,需要ALTER TABLE … DROP PARTITION先删除分区数据再TRUNCATE
修改列、分区的注释:ALTER TABLE … CHANGE COLUMN 列名 COMMENT ‘’;
MaxCompute中支持显示转换cast和隐式转换。
对于显示转换过程中,会发生如下问题:
String类型和Datetime类型之间的转换
由于double存在精度差,所以不能直接对两个double类型的数值用=号判断相等,可以在相减后取绝对值的方式判断,当绝对值足够小时可以说明两数相等。
abs(0.9999999999 - 1.0000000000) < 0.000000001
String类型在参与运算前会进行隐式类型转换到double类型
bigint和double类型在计算时,bigint会隐式转换为double再计算,返回结果也是double
位运算符不支持隐式转换,同时只允许bigint类型。逻辑运算符也不支持隐式转换,只允许boolean类型。
《开课吧-大数据开发高级工程师一期》课程