# bigdata

**Repository Path**: Jerrysbest/bigdata

## Basic Information

- **Project Name**: bigdata
- **Description**: 大数据知识体系
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 2
- **Forks**: 1
- **Created**: 2021-04-05
- **Last Updated**: 2024-03-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

= bigdata

== *1.hadoop*

=== *1.1 HDFS体系架构*
[qanda]
yarn的设计思路是什么?

[qanda]
secondarynamenode的作用？
Secondary NameNode的职责是合并NameNode的edit logs到fsimage文件中.类似于checkpoint
[qanda]
HDFS如何实现高可用？
[qanda]
namenode主从复制原理？

=== *1.2 mapreduce知识体系*
[qanda]
mapreduce处理数据的流程？举例说明，比如如何计算圆周率。
[qanda]
mapreduce源码角度来看分为几个模块？每个模块作用是什么？


== *2.yarn-spark 任务提交流程*

[qanda]
yarn原理/作用::
一个container对应一个JVM进程（也就是一个executor）

Spark On YARN内存分配

image::https://gitee.com/Jerrysbest/bigdata/raw/main/memory.png[]

堆外内存::
由spark.yarn.executor.memoryOverhead参数设置。主要用于JVM自身的开销。默认：MAX(executorMemory*0.10,384MB)
Excutor内存::
* 由spark.executor.memory参数设置，分为两部分。
.. Execution:shuffle、排序、聚合等用于计算的内存
.. Storage：用于集群中缓冲和传播内部数据的内存（cache、广播变量）
* 堆外内存，利用 JDK Unsafe API（从 Spark 2.0 开始，在管理堆外的存储内存时不再基于 Tachyon，而是与堆外的执行内存一样，基于 JDK Unsafe API 实现[3]），Spark 可以直接操作系统堆外内存，减少了不必要的内存开销，以及频繁的 GC 扫描和回收，提升了处理性能。堆外内存可以被精确地申请和释放，而且序列化的数据占用的空间可以被精确计算，所以相比堆内内存来说降低了管理的难度，也降低了误差。
规整化因子::
设置的executor-memory 大小为6g，executorMemoryOverhead为默认值，即max(6g*0.1,384MB)=612MB
那总得大小应该为6144MB+612MB=6756MB
然而实际的开销为 7168 MB为什么？::
公式为ceil(a/b)*b，其中a是应用程序申请的资源，b为规整化因子。
Client 和  Cluster 内存分配的差异
在使用Clietn 和 Cluster 两种方式提交时，资源开销占用也是不同的。
不管CLient或CLuster模式下，ApplicationMaster都会占用一个Container来运行；而Client模式下的Container默认有1G内存，1个cpu核，Cluster模式下则使用driver-memory和driver-cpu来指定；

spark2.x 内存分配

== *3.spark*

3.1 spark shuffle原理 +
[qanda]
spark job， stage ，tasks ::
https://blog.csdn.net/hellojoy/article/details/81079598 +
因此spark划分stage的整体思路是：从后往前推，遇到宽依赖就断开，划分为一个stage；遇到窄依赖就将这个RDD加入该stage中。
你所理解的Spark的shuffle过程？::
Spark源码解读之Shuffle原理剖析与源码分析 +
https://blog.csdn.net/qq_37142346/article/details/81875249
spark rdd 分区数的确定::
https://blog.csdn.net/dkl12/article/details/81663018 +
总结，不同数据源分区数量计算公式不同，同一数据源文件大小不同计算公式也不同 +
参数有: blcok数量，block大小，默认并行度，cpu核心数等等 +
blocks-merge-inputsplit-task-rddpartion

3.2 spark on hive如何动态解决小文件过多的问题？ +
https://blog.csdn.net/longyangaaoo/article/details/78645839 +
#在Map-only的任务结束时合并小文件 +
set hive.merge.mapfiles = true +
#在Map-Reduce的任务结束时合并小文件 +
set hive.merge.mapredfiles= true +
#合并后文件的大小为1GB左右 +
set hive.merge.size.per.task = 1024000000 +
#当输出文件的平均大小小于1GB时，启动一个独立的map-reduce任务进行文件merge +
set zhive.merge.smallfiles.avgsize=1024000000 +
以上设置对spark on hive不起作用； +
但是可以使用spark重分区，dataset.repartion +

小文件问题原因：::
spark.sql.shuffle.partitions=200  spark sql默认shuffle分区是200个，如果数据量比较小时，写hdfs时会产生200个小文件。可通过如下调整，使其自适应的合并小文件(本人测试环境从原来的200个小文件合并成一个文件)
解决方法：::
spark-sql> set spark.sql.adaptive.enabled=true;     启用 Adaptive Execution ，从而启用自动设置 Shuffle Reducer 特性
spark-sql> set spark.sql.adaptive.shuffle.targetPostShuffleInputSize=128000000;    设置每个 Reducer 读取的目标数据量，其单位是字节。默认64M，一般改成集群块大小

3.3 spark RDD-弹性分布式数据集
3.4 spark join原理 +
https://blog.csdn.net/qq_16633405/article/details/105279443 +
https://blog.csdn.net/u013411339/article/details/103107349?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromBaidu-1.control&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromBaidu-1.control +
broadcast hash join +
shuffle hash join +
sorted merge join +
3.5 spark checkpoint 时机 +
rdd生成完以后 +
checkpoint本身是个rdd，持久化到hdfs

== *4.hbase*
. 一图看懂 HBase 架构（全面详细）
  https://blog.csdn.net/BigData_Hobert/article/details/108362813
. hbase读取和写入的过程
. lsm相对于b+树优化了哪块？ 优化了写入
. lsm 设计内存部分的目的是什么
.. 主要是用来维护结构 而不是为了加速读取 加速读取有专门的缓存
. region
.. 层级关系
 * Table       (HBase table)
 ** Region       (Regions for the table)
 *** Store          (Store per ColumnFamily for each Region for the table)
 **** MemStore        (MemStore for each Store for each Region for the table)
 ***** StoreFile       (StoreFiles for each Store for each Region for the table)
 ****** Block     (Blocks within a StoreFile within a Store for each Region for the table)

.. Region 大小
... 考虑节点数量,总数据量大小,确定合适的region数量，使得资源可以被利用上
... region数量少了，资源利用不上，region数量太多性能差
... 设置region体积最大值，要考虑cell的大小来设置region体积
.. Region 拆分策略
... Region的分割操作是不可见的，因为Master不会参与其中。RegionServer拆分region的步骤是，先将该region下线，然后拆分，将其子region加入到META元信息中，再将他们加入到原本的RegionServer中，最后汇报Master。
... 执行split的线程是CompactSplitThread。
... 自定义拆分策略
.... RegionSplitPolicy的实现类
.... ConstantSizeRegionSplitPolicy
.... IncreasingToUpperBoundRegionSplitPolicy
.... DelimitedKeyPrefixRegionSplitPolicy
.... KeyPrefixRegionSplitPolicy
... 预拆分 -导入数据时冷拆分
... 自动拆分 -热拆分
... 手动拆分（命令行） -热拆分
. hfile为何要去合并
.. 小文件太多影响效率
.. 有些带删除标记的文件需要删除
.. 合并流程
... 获取不带锁的列表
... 由列表创建一个StoreFileScanner来读本次合并的所有storeFile上的数据
... 在临时目录创建一个新的HFile，使用scanner从旧的HFile中读取数据放到新HFile
... 用临时目录的HFile替换原来的HFile，这样没被读出数据就被清掉了
. lsm树的优势
. hbase列族
.. 需要一起查询的字段放到一个列族
... HBase目前对于两列族或三列族以上的任何项目都不太合适，因此请将模式中的列族数量保持在较低水平。目前，flushing 和 compactions 是按照每个区域进行的，所以如果一个列族承载大量数据带来的 flushing，即使所携带的数据量很小，也会 flushing 相邻的列族。当许多列族存在时，flushing 和 compactions 相互作用可能会导致一堆不必要的 I/O（要通过更改 flushing 和 compactions 来针对每个列族进行处理）。
.. 数量不要多
... 一般就2到3个
.. 列族基数
... 如果有两个列族A和B,A有100万行，B有10亿行


== *5.Apache Calcite*
Apache Calcite是一款开源SQL解析工具, 可以将各种SQL语句解析成抽象语法术AST(Abstract Syntax Tree), 之后通过操作AST就可以把SQL中所要表达的算法与关系体现在具体代码之中。+
calcite的原理 +
calcite如何做到sql语句转换为物理执行计划 +

== *6.b和b+树对比 innodb为何用b+树*

== *7.flink*
https://www.sohu.com/a/292738028_753508 +
7.1 组件：一个JobManager，一个ResourceManager，一个TaskManager，以及一个Dispatcher +
slotmanager +
7.2 调优 +
https://www.cnblogs.com/luxiaoxun/p/12114728.html +
https://www.jianshu.com/p/28c7722ae22f +
并行度 cpu的2到3倍数 kafka分区数 +
slot 等于cpu数 +
taskmanager数目=ceil(并行度/slot) +
7.3 flink checkpoint和savepoint的区别 +
https://blog.csdn.net/nazeniwaresakini/article/details/104649508?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=1328602.592.16148628600826349&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.control +
7.4 flink state +
operator state 和 keyed state +

== *8.源码*
yarn源码解析 +
https://blog.csdn.net/weixin_42642341/article/details/81368607 +
https://blog.csdn.net/jjzhk/article/details/18787739?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_baidulandingword-7&spm=1001.2101.3001.4242 +
公平调度 +
https://www.cnblogs.com/lemonu/p/13566208.html +
cgroup +
https://blog.csdn.net/zhoudetiankong/article/details/76158696 +

== *9. kafka 结构原理  语义  分片  数据同步  位点*
保证exactly once， +
生产端 acks=all，可能会影响性能，可以批量提交 +
kafka数据要保留2份以上 +
消费端保持幂等性，显式提交offset +
kafka topic和partition关系 +
每个 Topic 可以划分多个分区（每个 Topic 至少有一个分区），同一 Topic下的不同分区包含的消息是不同的。每个消息在被添加到分区时，都会被分配一个 offset，它是消息在此分区中的唯一编号，Kafka 通过 offset 保证消息在分区内的顺序，offset 的顺序不跨分区，即 Kafka 只保证在同一个分区内的消息是有序的。 +
kafka group +
一个group下面很多分区，一个消费者接收一个分区的数据 +
partition能不能减少? +
rebalance +
rebalance本质上是一种协议，规定了一个consumer group下的所有consumer如何达成一致来分配 订阅topic的每个分区。比如某个group下有20个consumer，它订阅了一个具有100个分区的topic。正常情况下，Kafka平均会为每个consumer分配5个分区。这个分配的过程就叫rebalance。 +
调优： +
https://blog.csdn.net/qq32933432/article/details/96479411 +
操作系统：交换分区，文件系统（ext4，xfs，禁用mtime，atime） +
网络：万兆网卡，socket buffer设置,读写缓冲区 +
垃圾回收：G1 +
broker数量：根据需要存储的数据量 +
分区数量：根据消费者吞吐能力 +
使用独立的zookeeper，把偏移量写到kafka +
生产者：batchSize，linger.ms +
消费者；fetch.min.bytes,fetch.max.wait.ms +

== *10.大数据实际应用*

flink spark算子的共用 +
异步函数和缓存 +
flink遇到问题的解决，slot卡死 +
spark问题解决 性能，任务提交create table if not exists   select，第一个am没有响应，所以建立第二个am

数据采集

https://tech.youzan.com/datax-in-action/

druid使用
https://tech.youzan.com/realtime-olap-on-druid/

数据中台经常挂掉， +
ERROR JDBC exception: org.apache.thrift.transport.TTransportException: java.net.SocketTimeoutException: Read timed out
java.sql.SQLException: org.apache.hive.service.cli.HiveSQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.tez.TezTask

百亿数据上传部分错误，如何删除部分重传 +
分区+insert overwrite +
如何快速加载 10万个数据文件（命名有规律，数据格式一致） +
建立外表，location指定相应位置，把文件移动到相应位置，分区表要添加相应分区
加载慢的话：合理分区，小文件合并
hive 单值分区，范围分区 +
hive 多级分区 多分区字段，目录嵌套 +
spark程序慢，如何排查？ +
执行计划 +
cpu 内存 +
尝试增加并行度，cpu，内存 +
spark杀掉 +
调度平台可以，但是无法监控spark运行状态 +
linux yarn application -kill <applicationId> +
YarnClient API ：yarnClient.killApplication(getAppId(appIdStr)); +
如何etl去重， +
批量sql：建立一张和目标表完全一样的表，把数据导入到这个表，用join得出非重复数据导入 +
流式处理（es ,ecache做缓存） +
范式建模（数据库设计三范式），维度建模（事实表，维度表，星型模型），实体建模（根据应用建模）区别 +
https://blog.csdn.net/baidu_20183817/article/details/104991764 +
阿里onedata体系细节，指标细节 +
onemodel，oneservice，oneId +
智能监管系统指标：违规检出率，违规金额等 +

yarn资源调度 +
公平调度 +
https://blog.csdn.net/baiyangfu_love/article/details/14004331?utm_medium=distribute.pc_relevant.none-task-blog-OPENSEARCH-1.control&dist_request_id=fcbc0606-5cf5-46d5-a79b-5ad7b8898604&depth_1-utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-1.control +

fairScheduler详解 +
https://blog.csdn.net/sinat_29581293/article/details/58143159 +

实例 +
https://blog.csdn.net/T1DMzks/article/details/79211134 +

----
<?xml version="1.0"?>
<allocations>
<queue name="root">
<aclSubmitApps></aclSubmitApps>
<aclAdministerApps></aclAdministerApps>
<queue name="production">
<minResources>8192mb,8vcores</minResources>
<maxResources>419840mb,125vcores</maxResources>
<maxRunningApps>60</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>7.5</weight>
<aclSubmitApps>*</aclSubmitApps>
<aclAdministerApps>production</aclAdministerApps>
</queue>
<queue name="spark">
<minResources>8192mb,8vcores</minResources>
<maxResources>376480mb,110vcores</maxResources>
<maxRunningApps>50</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1</weight>
<aclSubmitApps>*</aclSubmitApps>
<aclAdministerApps>spark</aclAdministerApps>
</queue>
<queue name="default">
<minResources>8192mb,8vcores</minResources>
<maxResources>202400mb,20vcores</maxResources>
<maxRunningApps>20</maxRunningApps>
<schedulingMode>FIFO</schedulingMode>
<weight>0.5</weight>
<aclSubmitApps>*</aclSubmitApps>
<aclAdministerApps>*</aclAdministerApps>
</queue>
<queue name="streaming">
<minResources>8192mb,8vcores</minResources>
<maxResources>69120mb,16vcores</maxResources>
<maxRunningApps>20</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<aclSubmitApps>*</aclSubmitApps>
<weight>1</weight>
<aclAdministerApps>streaming</aclAdministerApps>
</queue>
</queue>
<user name="production">
<!-- 对于特定用户的配置:production最多可以同时运行的任务 -->
<maxRunningApps>100</maxRunningApps>
</user>
<user name="default">
<!-- 对于默认用户配置最多可以同时运行的任务 -->
<maxRunningApps>10</maxRunningApps>
</user>

    <!-- users max running apps -->
    <userMaxAppsDefault>50</userMaxAppsDefault>
    <!--默认的用户最多可以同时运行的任务 -->
    <queuePlacementPolicy>
        <rule name="specified"/>
        <rule name="primaryGroup" create="false" />
        <rule name="secondaryGroupExistingQueue" create="false" />
        <rule name="default" queue="default"/>
    </queuePlacementPolicy>
</allocations>
----

大数据平台比较-CDH，HDP +
http://www.mamicode.com/info-detail-2375058.html

== *11.大数据集群调优*
hadoop集群调优 +
硬件；操作系统；平台参数；应用； +
https://blog.csdn.net/pansaky/article/details/83347357 +
京东大规模集群 +
https://www.yisu.com/zixun/283286.html +
通过Router层路由到指定的大数据集群，使得集团内各个大数据集群数据资源可以共享 +
hadoop大集群优化配置，datanode节点数量为100，namenode1g对应一个datanode节点 +
https://blog.csdn.net/maijiyouzou/article/details/23740225 +
扩容 +
https://www.aboutyun.com/blog-24-650.html +
decommission，格式化磁盘，再加回来 +
磁盘不要用lvm，要用物理卷 +

== *12.大数据平台安装*
hdp的安装 +
https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.5/installation.html

== *13.什么是数据中台*

https://segmentfault.com/a/1190000020342503?utm_source=tag-newest
狭意：从数据分层/治理和大数据平台两个维度 +
广义：ipaas数据资产 daas数据中台 ipaas数据研发平台 iaas数据存储平台

== *14，kudu*

kudu是一个介于hdfs和olap数据库之间的方案，它平衡了随机读写和批量分析的性能，希望达到简化大数据平台架构，节约数据存储空间/减少数据存储份数的目的 +
https://blog.csdn.net/wwwzydcom/article/details/108966222

== *15. 实时数仓场景-大屏指标*

image::https://gitee.com/Jerrysbest/bigdata/raw/main/monitor.png[]

== *16.时序数据库*
https://www.cnblogs.com/dhcn/p/12974931.html

== *17.scrum研发流程*
. 角色 产品负责人（Product Owner）流程管理员（Scrum Master）开发团队（Scrum Team）
. 计划，集成，story，Srpint Review Meeting（演示会议），Sprint Retrospective Meeting（回顾会议）
. 在开发团队进行评估时，建议摒弃传统的“人天”评估法，采用故事点的方式，用斐波那契数列的数字（1，2，3，5，8，13，21……）的形式去评估
. 版本管理：源码，sql升级脚本
. 灰度发布
.. 精确的流量分发控制：新功能小范围试用
.. 监控系统的支撑：帮助决策，发现问题
.. 灵活的发布系统：局部发布，新旧版本共存
. 项目化与敏捷开发的冲突
. 不能违背项目计划
. 对外的瀑布模型与对内的敏捷
. sprint 可以不严格按照2周来走，根据项目开发量来订sprint

== *18 面试题*
https://zhuanlan.zhihu.com/p/161772729

https://blog.csdn.net/scgh_fx/article/details/71123378

腾讯面试问题参考
https://www.aboutyun.com/forum.php?mod=viewthread&tid=21404&extra=page%3D1