大数据架构师之路

1、同时拥有实时和离线处理的架构，既保证低延迟，又保障正确性。这个方法被称作 Lambda 架构，它通过批量 MapReduce作业提供了虽有些延迟但是结果准确的计算，同时通过flink/Storm将最新数据的计算结果初步展示出来。
双路生产会存在一些问题，比如加工逻辑double，开发运维也会double，资源同样会变成两个资源链路。因为存在以上问题，所以又演进了一个Kappa架构。
Kappa架构从架构设计来讲比较简单，生产统一，一套逻辑同时生产离线和实时。但是在实际应用场景有比较大的局限性，在业内直接用Kappa架构生产落地的案例不多见，且场景比较单一
2、Doris也是一种OLAP框架，主要用于实时数据仓库，自带存储的实时计算引擎。
MPP架构的SQL查询引擎，如Impala,presto等能够高效地支持SQL查询，但是仍然需要依赖Kudu, HDFS, Hive Metastore等组件, 运维成本依然比较高，同时，由于计算存储分离，查询引擎不能很好地及时感知存储层的数据变化，就无法做更细致的查询优化，如想在SQL层做缓存就无法保证查询的结果是最新的。因此，我们的目标是寻求一款【计算存储一体】的MPP数据库来替代我们目前的存储计算层的组件。
Doris是百度开源到Apache社区的基于 MPP 的交互式 SQL 数据仓库， 主要用于解决报表和多维分析，像flink，storm就是只有计算没有存储的。
3、大数据架构分为数据源层、数据加工层、数据服务层、数据应用层。

数据源层：包含接入的原始数据，包括客户端日志、服务端日志、业务库、集团数据、外部数据等。
数据加工层：使用Spark、Hive 构建离线数仓、使用Storm、 Flink实时数仓。在数仓之上针对服务对象建设各种数据集市
数据服务层：主要包括存储介质的使用和数据服务的方式。存储：主要使用开源组件，如 Mysql, HDFS, HBase, Kylin, Doris, Druid, ES等。数据服务：对外数据查询、接口以及报表服务
数据应用层：主要包括主题报表、自助取数工具、增值产品、数据分析等支撑业务开展，同时依赖公司平台提供的一些工具建设整体数据应用。

4、MPP是一种实时海量数据分析架构。MapReduce是一种离线海量数据分析架构。其实MPP架构的关系型数据库与Hadoop的理论基础是很相似的，都是将运算分布到节点中独立运算后进行结果合并。只不过MPP底层跑的是SQL,而Hadoop底层执行的是MR。
ES也是一种MPP架构的数据库，Presto、Impala等都是MPP engine，各节点不共享资源，每个executor可以独自完成数据的读取和计算，缺点在于怕stragglers，即所谓木桶的短板。与hadoop相比，MPP更加强调的实时计算。
5、MPP架构和批处理架构（MR,SPARK）区别：mpp架构每次计算是所有节点都参与计算。批处理架构并不需要所有的节点都参与运算，它在一个任务事件下发以后，控制节点会分配给一些集群中的节点，而这些节点各自完成自己的计算，然后把计算结果写到磁盘里，再交给下一个计算的节点去写入，每次不需要所有的节点去参与运算。
批处理架构需要节点和任务去进行解耦，解耦的代价是，需要共享资源，势必会带来写磁盘，不管是读磁盘还是写磁盘，相比MPP的通信方式来说显然会更慢。
可以将两者进行互补：MPP on Hadoop就不得不提一下，如Impala，presto，在这里就把他们归类为MPP on Hadoop技术。这些技术大部分没有自己的存储，是一个类MPP的架构，需要控制节点把任务下发到对应的MPP的任务节点上，而在MPP节点的底层是HDFS，等于是这两者的一个结合，实际运用起来查询会比Hive更快一些。
总结：MPP会将任务下发到每个节点，每个节点完成所有计算。而MR/spark是将任务下发到某些节点，由于资源共享涉及shuffle，所以较慢
6、市面上的OLAP分为两种：
通过加并发的方式来解决问题：MPP架构和批处理架构
通过预计算来解决问题，如麒麟，druid
10、分类学习之召回率和准确率
假设我们手上有60个正样本，40个负样本，我们要找出所有的正样本，系统查找出50个，其中只有40个是真正的正样本，计算上述各指标。
TP: 将正类预测为正类数 40
FN: 将正类预测为负类数 20
FP: 将负类预测为正类数 10
TN: 将负类预测为负类数 30
精确率(precision) = 40/50 = 80% 精确率是针对我们预测结果而言的，它表示的是预测为正的样本中有多少是真正的正样本
召回率(recall) = 40/60 = 2/3 召回率是针对我们原来的样本而言的，它表示的是样本中的正例有多少被预测正确了
预测正确了就称为召回

14、G1回收器的缺点：需要用记忆集（卡表）来记录新生代和老年代之间的引用关系。这种数据结构需要占用大量的内存，带来高负载
15、对于文件存储而言，有两种主流的方式，即按行存储以及按列存储。所谓按行存储就是把每一行数据依次存储在一起，即先存储第一行的数据再存储第二行的数据，以此类推。按列存储就是把表中的数据按照列存储在一起，先存储第一列的数据，再存储第二列的数据。而在大数据场景之下，往往只需要获取部分列的数据，那么使用列存就可以只读取少量数据，这样可以节省大量磁盘和网络 I/O 的消耗。此外，因为相同列的数据属性非常相似，冗余度非常高，列式存储可以增大数据压缩率，进而大大节省磁盘空间
16、orc优化：https://www.infoq.cn/article/spRaKpgIGyNQAdUwmRiT

• 异步预读：传统读文件的方式一般是从底层文件系统先拿到原始数据，然后进行解压和解码。这两步操作分别是 I/O 密集型和 CPU密集型的任务，并且两者没有任何并行性，因此就加长了整体的端到端时间。AliORC这样就将所有的读盘操作变成了异步的操作，实现了从文件系统读数据和解压解码操作的并行处理
• 消除小IO：在 ORC 文件中，而每次读取都是以列为单位进行的。这样对于数据量比较小的列而言，读取时的网络 I/O 开销非常大。而 ORC文件中有许多这样数据量很小的列，从而造成了大量小 I/O 的产生。为了消除这些小 I/O 开销，AliORC 在 Writer写数据时，针对不同列的数据压缩后大小进行了排序，将数据量少的列放在一起写
• 内存管理：在开源版本的 ORC 实现中，Writer 的每列数据都使用了一个很大的 Buffer 去保存压缩后的数据，默认大小为1M。Buffer 设置得越大，压缩率越高。但是不同列的数据量不同，某些列根本用不到 1M 大小的Buffer，因此就会造成极大的内存浪费。避免内存浪费的简单方法就是在一开始的时候只给很小的数据块作为 Buffer，并且按需分配

17、orc和parquet对比：相同压缩算法下，Parquet 和 ORC 存储性能非常相近。orc压缩率更高点。
关于读表性能的对比，相同压缩算法的 ORC 文件读起来比 Parquet 要更快一些。
嵌套结构支持：Parquet 能够很完美的支持嵌套式结构，而在这一点上 ORC 支持的并不好，表达起来复杂且性能和空间都损耗较大。比如某个字段的数据嵌套了多层，那parquet可以很完美的存储这样的字段，orc存储起来就比较吃力
18、ORC基于数据类型的块模式压缩：

• integer类型的列用行程长度编码(run-length encoding);
• String类型的列用字典编码(dictionary encoding)；

19、ORC将整个表数据先划分为多个strip，每个strip包含多行数据。在strip内部是列式存储。但是从整个表的存储角度，orc并不是完整的列式存储。即orc并不是纯粹的列式存储，也是先基于行对数据表进行分组（行组），然后对行组进行列式存储。
20、Hive的ORC文件格式，它不但有着很高的压缩比，节省存储和计算资源之外，还通过一个内置的轻量级索引，提升查询的性能。这个内置的轻量级索引，就是下面所说的Row Group Index。
其实ORC支持的索引不止这一种，还有一种BloomFilter索引，两者结合起来，更加提升了Hive中基于ORC的查询性能。
在建立ORC格式表时，指定表参数’orc.create.index’=’true’之后，便会建立Row Group Index，需要注意的是，为了使Row Group Index有效利用，向表中加载数据时，必须对需要使用索引的字段进行排序，否则，min/max会失去意义。另外，这种索引通常用于数值型字段的查询过滤优化上。

21、hadoop archive 存档过程实际是一个MapReduce过程
/* 归档命令：
hadoop archive -archiveName 0825.har -p /test/in/ small mapjoin /test/in/har

• -archiveName 0825.har : 指定归档后的文件名
• -p /test/in/ : 被归档文件所在的父目录。这里也可以写多个需要归档的文件<