hadoop.apache.org
spark.apache.org
flink.apache.org
hadoop :HDFS/YARN/MAPREDUCE
HDFS读写流程
NameNode
DataNode
SecondaryNameNode
写流程
1. 客户端请求NameNode (几副本，block大小和个数)
2 NameNode返回可以存的datanode,存储元数据信息
3. 数据按最近原则存储，DN->DN-->DN
读流程
client 请求NameNode， 将元数据信息返回给客户端，客户端到最近的DataNode数据地址获取数据。
NameNode HA高可用
1. 两个NameNode ，一个active状态，一个standby 状态
2. 同一时间节点只有active提供服务
3. standy 负责同步备份active的状态。
4. 有监控器监控active，active 挂了后，standy 变成active状态。
5. 过程中用到zk
小文件
引起小文件的原因：
1. spark 任务产生大量小文件
2. reduce, task是数据设置分区太多等
3.源数据本身就有大量小文件，上传到hdfs
小文件给hadoop带来的瓶颈
1. 磁盘io问题
2. 性能问题：任务开启和销毁开销大
3. 导致NameNode大量元数据信息，消耗大量的内存
如何解决小文件问题
SQL on hadoop 业界常用框架
hive : sql => 对应的执行引擎的作业：MapRedduce/Spark/Tez
imala: 很吃内存
Presto:JD 用的多
Drill:
Phoenix:HBase(基于rowkey 查询)，可以提供2级索引
Spark SQL:Spark 社区
MetaStore：存储元数据信息
sql on hadoop 调优策略
调优：在资源不变的前提下，让作业的执行性能有提升，调两大类：CPU负载，IO负载
1.架构层面调优
分表
分区表 partition
充分利用中间结果集
压缩：
使用压缩算法“减少数据的过程”， 减少磁盘IO ，网路IO
gzip
压缩在大数据中使用场景：
1.输入数据
2.中间数据
3.输出数据
前提：
1. 行式存储
2.每分钟2亿条数据
业务架构：
Flume => HDFS=> Spark ETL => Spark SQL => SQL => Spark SQL/NoSQL
分区表，多分区（d/h） 分区表，多分区（d/h）
大宽表 统计分析结果表供可视化结果展示
用户日志：
分区表：单级分区，多级分区，静态分区，动态分区
2. 语法层面调优
排序 order by/sort by/distribute by/cluster by
控制输出的数量（reduce/partition/task）
join:普通join/mapjoin
执行计划
3. 执行层面调优
推测执行
并行执行
JVM重用
储存方式
行式存储
列式存储:
1.相较于行式存储，列式存储的查询速度非常快。
2.数据易维护，当我们更新数据时，历史数据会有版本号，不会被改变或者消失。
3.非常适合大数据分析和高并发。
但是，缺点也很明显。列式存储在表关联上确实让人“头痛”不已。
总结下来，我突然觉得列式存储适合做数据分析，在业务繁杂的生产系统方面可能有所欠缺。