大数据面试题库

分区是将数据 根据数据的某个字段进行一个数据路径分区 主要思想就是分而治之 将大文件拆分多个小文件 减少查找数据的扫描量 底层是HDFS存储 文件太大存到一半 集群崩了 白存了

分桶是解决分区的一种优化方案 因为分区根据某个字段分 容易出现数据倾斜而分桶是根据数据的hash值对桶数取余 数据倾斜较小

开启分桶：INTO 分桶数 BUCKETS

hive底层是MR计算引擎 所以当reduce阶段 shuflle的时候呢 存储数据不均匀造成数据倾斜 

定位原因 如果是压缩引发的采用分割的压缩算法   null值不需要的情况先过滤   需要的话就+随机盐   join产生的问题就预先聚合  增加桶数

两个都是hive的存储方式 只是分别应用的场景不同  ORC是Hadoop生态系统面向列的 与Hadoop环境中大多数框架兼容  性能高  读和写速度快  Parquet适合嵌套数据结构 兼容性更强

ER模型和维度建模 ER模型遵循三范式  维度建模遵循以分析决策设计表

星形模型

雪花模型

星座模型

空间换时间 复杂问题简单化  一般分五层 ODS数据原始层-->将数据进行Json数据的预处理  DWD数据明细层--> 将ODS经过ETL清洗过滤 装载到此层  DWS数据设计层-->将DIM层的维度表跟DWD事实表Join所形成的宽表   ADS数据服务层--> 这一层的数据一般可以视图展示了

设计好的模型事半功倍  合理的分区分桶减少数据倾斜 设置合理的MR的task数 优化存储数据块  挑选合适的数据存储方式

谓词下推 投影下推 常量折叠 分区裁剪

小表join大表   小表join小表 

大表join大表  

Skew Join

利用更多的资源换取时间  空间换时间

当Stage之间没有依赖关系时 我们可以进行并行执行

滑动窗口

取值型窗口

分析型窗口

小文件过多会造成HDFS的namenode元数据特别多  占用太多内存 影响性能  对于MR来说消耗资源 一个文件一个map任务

Sequence File

concatenate

CombinerFileInputFormat

archive

union

orderBy

sortBy

distinctBy

clusterBy

压缩技术能够有效减少存储系统的读写字节数，提高网络带宽和磁盘空间的效率 运用得当能提高性能，但运用不当也可能降低性能

数据来源：bzip LZO  （用压缩并且选择支持分片的压缩方式）

数据计算：LZO LZ4 Snappy（压缩/解压速度快 支持Hadoop Native库）

UDF

UDAF

UDTF

元数据库（Mysql）

通过元数据、Hive可以将SQL查询转化为底层存储引擎可以理解的任务，并提供了查询性能优化的关键信息

数据位于本地系统

使用外部表

使用ETL工具

提供数据库的事务的支持

配置

共同点

不同点

原因是Job产生的任务会并行在 Executor去执行（算子内）但有些操作会在 Driver端执行（算子外）  算子内可能会用到算子外的数据

cache

persist

checkpoint

RDD之间的依赖关系 避免重复计算 提高容错效率，如果有一个分区数据丢失，只需要从父 RDD 的对应 1 个分区重新计算即可

宽依赖

窄依赖

任务划分就是靠宽窄依赖来划分的任务stage用的  遇到宽依赖就切割stage就是产生Shuffle Stage里面的Task的数量 是由 Stage中最后一个RDD的Partition数量决定的 最后一个Stage任务类型时 ResultTask  其它都是ShuffleMapStageTask

一个Application有多个Job 遇到行动算子 就触发一个Job  一个Job有多个Stage阶段  是由DAG有向无环图划分的   一个Stage阶段 有很多Task 数量是否分区决定 由TaskScheduler分配Task到对应阶段

Driver端声明了一个变量   所有Task需要修改这个变量 但是修改的只是Task自己内部的 修改不了Driver端  累加器作用就是修改Task变量 能影响到 Driver端的全局变量

Driver端声明的变量 序列化传输到 Excutor中Task中 每一个Task都有这么一个变量   数据量太大 就会占用大量的Excutor的内存空间 广播变量作用就是Excutor端只会存储一份该数据提供多个Task使用 防止数据被修改  所以是只读变量

大数据分而治之  多个节点都跑着任务  任务中间可能会进行一些 汇聚 数据打散重组等操作  中间过程是Shuffle  一个节点任务之间产生Shuffle只会产生磁盘I/O 多个节点任务之间之间产生Shuffle会产生网络 I/O和磁盘I/O  Shuffle可能会产生数据倾斜

Hash Shuffle

 Sort Shuffle

Tungsten Sort Shuffle

key分布不均匀 导致shuffle的时候 一个节点负载过重  一旦数据倾斜就会就可能产生 网路I/O  磁盘I/O  硬件故障  内存过度

使用HiveETL预处理  过滤少数导致倾斜的key  提高shuffle操作的并行度    双重聚合    将reducejoin 转为 mapjoin   采样倾斜key并分析join操作   使用随机盐和扩容RDD进行join

资源调优

代码调优

内存调优

并行度调优

用于处理结构化数据的模块  无论使用哪种方式 或 语言  执行引擎都是相同的 开发人员可以轻松地在不同的 API 之间来回切换 使数据处理更加地灵活

RDD

DataFrame（弱类型）

DateSet（强类型）

Driver的核心数3~5   以及内存数量512M  Executor的数量2   内存1G   核心数1

分区列表  分区计算函数 血缘  RDD存储结构  计算向数据靠拢

适当增加spark standby master 

编写脚本 定期检查master状态 出现宕机后对master 进行重启操作

都会产生shuffle reduceBykey的话他会分组+聚合 并且每个区内预聚合 减少shuffle的落盘量   groupBykey只能分组要聚合的话你得配合sum使用 数据量不会减少

conslidate

90％

预留10％  防止OOM溢出

1.生产者：将产生的消息存放到对应的Topic消息根据分区规则存放到不同的Partiton，然后同步到Replication
2.offest：唯一的标识一条消息 一个消息只能被一个组消费一次 一个组记录当前Topic消息消费的进度
3.topic：生产者发送的消息类别称为主题
4.partition：主题中的数据会被切分为至少一个或多个Partiton   每个分区中数据插入有序，新增的数据都会分配到队列尾部
5.replication：每一个分区都拥有副本保证数据的安全 Partiton为了数据的读写 Replication为了数据的备份，没有读取功能
6.consumer：消费者就是从Topic读取数据 消费者组一组共享一个Topic的偏移量 一个消费者组内包含一个或者多个消费者 不同的组可以同时消费相同的Topic
7.zookeeper：存储KafaKa的元数据信息 帮助进行Leader的选举
8.broker：Kafaka集群的每一个服务器都叫Broker

幂等性

事务性

RangeAssignor（默认）：以一个主题为单位 均匀分配 多的 前面的往下多分一个区 一个组分配的区时连续的   缺点-->如果每个主题刚好都多一个 那么每次都是第一个消费者都会多分配一个 主题越多就会出现部分消费者过载的情况

RoundRobinASSignor：将所有消费者 以及 订阅的所有消费主题 按照字典序排序 然后轮询分配 相对均匀 差值不超过1 订阅多个主题相对数据比较混乱 适合单个主题

Sticky粘性的:均匀 不变 订阅哪些主题 消费哪些 进可能保持均匀

当数据到Partition后 Partition返回ACK给Producer  Producer接收到ACK确定后发送下一条 否则返回重新发送

0-->最多一条：producer无需等待Partiton返回ACK结果 直接发送第二条 Broker故障丢失数据  1-->只有一条：Partition分区接收到数据 写到本地log 返回ACK结果 Follower同步的时候 leader故障 丢失数据  -1-->最少一条：Partition分区接收数据 写到本地log 广播 所有Follower都同步了 才返回ACK结果  安全 效率低

使用最少一次+幂等性+事务+架构 = 保证数据精准一次消费

文件存储设计特点

顺序写入

pageCache

零拷贝

pageCache

零拷贝

会把消息持久到磁盘 有效避免消息丢失的风险 

对生产者和消费者的一个解耦   并且中间做了一个缓冲解决了生产者与消费者处理速度不一致的问题

影响

如果是处理速度及时  必须 消费者数=分区数

如果是处理速度不及时 提高每批次拉取的数量

硬件故障

软件故障

资源耗尽

数据损坏

监控系统

当batch大小达到了闻值(batch.size) 或batch积累消息的时间超过了linger.ms时batch被视为“已完成或"准备就绪”。batch.size和inger.ms都是Producer端的参数。batch.size默认值是16KB，而linger.ms默认值是0毫秒。一旦达到了batch.size值或越过了linger.ms时间，系统就会立即发送batch。

允许您在Kafka中建立一个灵活的消息管道，将数据从一个主题传递到另一个主题，并进行任何必要的数据转换和处理

单表单主题

多表单主题

是度量事件时间的 解决分布式环境下网络延迟 背压造成数据乱序的

周期型

定点型

延迟数据处理

source端

转换

sink端

1.首先是否分组  分组每个组达到要求才能显示 不分组只有一条主流 主流达到要求进行显示
2.windowAssigner：分配器类型-->定义如何将数据流分配到一个或多个窗口  基于时间的滑动 滚动 会话  基于计数的滚动 滑动
3.Trigger：指定触发器类型-->满足什么样的条件触发计算 触发时机  每一个窗口分配器都有一个默认的触发器
4.Evictor：数据剔除器 在触发器触发之后 窗口函数使用之前或之后 从窗口中清除元素
5.Lateness：时延设定-->是否处理迟到数据,当迟到数据达到窗口是否触发计算
6.OutPut：输出标签-->通过getSideOutput将窗口中的数据根据标签输出
7.window Funtion：窗口上处理逻辑 增量 全量聚合

将数据进行分割 拍快照的  定期生成 会跟随数据一起流动 广播给下游的所有算子  当算子收到barrier 说明上一批数据已经走完 开始拍摄快照 存储到HDFS持久化 下一批数据继续传输 保证实时性

barrier对齐

barrier对不齐

原因是反压

解决办法

join

CoGroup

Interval Join

类似于有点Spark的RDD的血缘 程序出错 我们如果从头开始计算 效率低 没有时效了  有这个状态之后  Flink只需要获取到上一步的状态 重新计算即可  状态分有状态无状态 无状态就是算子用不到状态 有状态就是需要用到历史数据做计算的  状态一般都是Flink运行时帮我们管理 序列化 故障恢复等都实现好了  也可以自己管理 自己开闭一个内存空间 但是太麻烦了  状态又分为算子状态 和 键分区状态  算子状态是可以用于所有算子 一个并行度一个状态对应一个槽  就是说当前并行度的算子共享一个状态 键分区状态 只能用于分区算子 相同的key共享一个状态  但是一个槽里面可能有多个key 状态可以存在内存 文件 RockDB 或者 远端持久化到HDFS 状态存太久了 也太浪费资源 所以状态的TTL就是来管理它过期如何处理 怎么过期 等等

生产数据的速率比Task消费速率快  反压传播是从下游到上游传播  反压是流处理系统中用来保障应用可靠性的一个重要机制 上游处理单元降低数据发送的速率，以缓解下游处理单元的压力 反压会造成检查点时长拉长 变大 反压可以静态反压 动态反压 静态反压就是自己调参数 缺点就是调大还是会有压力  调小有效利用资源 基本都是动态反压 消费者动态告诉生产者处理能力  处理的条数Spark 缓冲区剩余空间  反压流程是1.5以前是将你的资源全部堵塞  资源耗尽才会停止发送数据  问题就是Socket阻塞的问题 导致其它的任务也无法发送任务 1.5以后呢就是上游会给下游发送一个消息 告诉下游这次要发送多少条 下游会根据条数申请足够的资源 如果下游资源不够 就会发送一个消息返回0   上游就会停止发送任务 不会堵塞每个阶层 提高了socket的复用性

通过WebUI界面点开算子右边 backPressure看反压

解决

也可以通过WebUI定位到第一个黑色节点的位置 但是由于可能该节点的瓶颈可能不会高反压 但是导致上游节点反压 如果不是第一个 就是紧接的下游节点   系统资源问题CPU 网络 磁盘I/O-->优化代码 增加并发和机器  GC垃圾回收问题-->性能问题常常源自过长的GC时长 可以通过打印日志 或者 使用分析GC的工具    CPU瓶颈或者线程争用-->使用代码分析工具来定位热点线程 CPU分析工具对于探查这类问题也很有用  负载不均-->瓶颈是数据倾斜造成的，可以尝试删除倾斜数据 改变数据分区策略将造成数据的key值拆分 也可以进行本地聚合/预聚合

资源调优

并行度调优

状态后端

多使用ParameterTool工具 是可以序列化的 可以读取外部配置 作为参数传递

看反压 资源利用率 关键指标  检查点时长  GC等等

堆上内存

堆外内存

内存分配策略

内存管理监控和调优

允许将外部文件或数据加载 到任务中 方便访问

通过getRumTimeContext.getCache放到每个taskManager中

通过getRumTimeContext.getDistributedCache().getFile()访问缓存中的数据

缓存数据不会自动清理 只能手动清理

数据要足够小

适用场景

性能影响

资源管理

测试和监控

不同的窗口内积攒的数据量不同 数据的产生速度导致的

解决

配置文件级别

执行环境级别

算子级别

代码运行时

通过webUI定位到多个task的subTask判断是否倾斜  如果某个subTask接收数据量大于其它的 基本数据倾斜了

解决

主要测：吞吐量、延迟、稳定性。

1.明确定义性能指标和目标

2.数据贴合真实数据

3.如果没有达到理想状态 开始调优

4.开始测试 然后测试出吞吐量、延迟、稳定性

5.持续监控

6.负载测试

7.文档和报告

是一种用于捕获和处理数据库变化的技术，将数据库变化以流的形式提供给Flink应用程序

列式存储数据库  快 线性扩展 高可靠性  简单方便  功能多  采用LSM Tree 的结构 定期合并 定期删除历史数据 数据导入时全部是顺序 append 写  数据压缩  磁盘存储数据 多核并处理 SQL支持 向量化引擎 实时数据更新 支持近似计算 数据复制和对数据完整性的支持

CPU瓶颈 不支持高并发 不适合Join操作 事务不全 缺少、仅批量删除或修改数据  聚合结果必须小于一台机器的内存大小 不适合Key-value存储，不支持Blob等文档型数据库 支持有限操作系统

接口类型

日志类型

内存类型

外部存储

repliacing

summing

aggregating

collasping

versionedCollasping

单条查询就能利用整机的CPU 竭尽所能榨干硬件能力，提升查询速度 

是列式存储数据库

CH是自底向上的、追求极致性能的设计思路

着眼硬件，先想后做-->group by 都是在内存进行 使用hashtable装载数据

算法选择是性能首要考量指标：对于常量使用 Volnitsky（字符串搜索算法）  对于非常量使用 CPU 的向量化执行 SIMD（一个控制器来控制多个处理器）暴力优化；正则匹配使用 re2（一切从简） 和hyperscan 算法（自动机理论为基础 分为编译器和运行期）  而且一有新算法 尝试性能不错 直接换

不断测试 不断的优化 实验得结果

ClickHouse具有智能的内存管理机制，可以有效地管理内存资源

因为CH单条查询就能利用整机的CPU 当单个查询比较短时，建议100QPS  不支持高并发

受到物理内存的限制，不能用作海量数据的高性能读写

RDB

AOF

优缺点

Map/Guava是本地缓存  每个实列各自保存一份缓存

Redis是分布式缓存 具有一致性  各实列共有一份缓存

完全基于内存

数据结构简单

单线程 没有多线程的CPU堵塞 上下切换 锁的烦恼

使用非阻塞I/O

写命令会返回错误的消息 读不影响  如果配置的淘汰机制  会冲刷掉旧的内容

使用散列表存储  使用的内存非常小

Redis事务不完全

带有隔离性、不保证原子性，且没有回滚

初始化Redis数据

击穿

穿透

雪崩

source

channel

sink

通过记录偏移量，允许在传输中断后恢复传输而不必重新开始

可以

不会，Channel 存储可以存储在 File 中，数据传输自身有事务

Atlas

1.我们项目中做这种连续活跃使用的是维度设计原则的缓慢变化维 也就是拉链表 用它原因能方便查询任意一条在任意一天的数据 又能方便查询到整个表任意一天的全量状态  节省空间  设计思路的话就是将数据Schma增加两个字段开始时间和结束时间（结束时间设计9999） 当新数据进来的时候 我们进行一个连接 判断历史拉链表数据的结束日期为9999 并且 新增数据相同id不为空 表示该数据已经更新 就会封闭拉链表里面的数据 然后将新增的数据全部查询出来 设置开始日期 和 结束日期 在将两个查询的结果进行union 生成新的拉链表

2.当时我们也是为了尝试不同的嘛 所以我们当时也是用了BItMap位图来做连续活跃  BitMap数据结构就是0，1表示嘛 我们当时活跃了设置为1 没活跃设计为0  当时我们以一个月为周期定位的 对比拉链表的话 周期是未知的 使用拉链表合适  已知的话我们用BitMap合适点

1.我们项目中行为数据采集是用的FLume的级联采集 因为日志采集我们要存到hdfs和kafka里面  还要根据数据的事件时间 要写入不同的文件夹 用于后面入仓分区管理  还有就是nginx服务器所在的子网跟HDFS不在一个网段 需要中转传输  所以需要flume级联将数据传到不同的节点  更好的提高容错性 也提高了传输效率 避免单点故障 支持不同类型  当然我们当时用级联也产生了一些问题  比如数据积压  上游太快 下游接收速度太慢了  解决办法sink的主备复用

1.我们项目中用到拦截器 主要是提取数据里面的事件时间  写入不同文件夹 用于数仓分区方便管理 减少扫描量 提高查询效率   离线做太久了 具体的思路我记不太清了  大概的思路有一点印象  好像就是重写event的方法吧  因为他是Json数据嘛 根据k获取到他value值  设置到他的header里面 就是event的tag上面  通过正则根据header写到不同的文件夹

1.就是说本来今天该到的数据 由于数据的延迟导致第二天到达  经过ETL处理的时候可能数据就会被 过滤掉  但是我们项目是通过拦截器提取了数据的时间 就算晚到达也只会进入同一时间的文件夹 不会进入到第二天的文件夹 数据丢失性减少了 但是会出现处理不到的现象  我们准确性要求的不是很高 丢个几百条 也不是很大问题 而且我们flume做了级联  效率提高了  数据丢失减少可能会更小

1.里面有个参数是hadoopConfig 是可以配置HA 我们平时拉取数据的datax的文件配置的都是高可用    需要配置nameservice服务  根据服务配置高可用namenode的名称  分别配置namenode的地址   在根据nameservice服务配置高可用的一个类似于驱动的参数

3.0以后提供了并发同步  核心就是将一个job拆分多个task 然后将task组装成一个taskgroup  一个taskgroup默认5个并发  然后并发执行task 主要的做法就是配置datax文件参数 在文件的头部有个设置本次任务的配置job job.setting.speed.channel设置并发量

1.入仓方案还是比较多吧 数据的敏感度不是特别的强 可以用市面上的ETL工具 进行一个数仓 因为ETL工具本身就有数据清洗过滤的特性  当然敏感度强的话也可以手写API 我们项目行为数据设计的是JSon数据格式 离线的话方案有spark解析 通过spark解析json文件然后写入hive中  还有就是 将整个Json看作一个字段先存入Hive表中，再通过Hive自带的函数（getJsonObject）解析再写入另一张表  最后一种是我们常用的一种 也是开发效率最高的一种 就是通过Hive兼容的Json解析器直接将Json数据解析到一张表中(Hive3.0之后提供原生的JsonSerDe) 业务数据不是JSON数据  实时的话直接通过FLink将数据转为dataBean 然后通过连接器JDBC入仓

1.首先过滤不需要的字段 脏数据  然后将数据转为dataBean方便操作  添加几个字段 新老用户的标识  该数据的唯一ID 省市区   临时会话字符串 用于后面的使用

2.首先切分会话 按照事件时间且切割  半个小时算一个会话  根据sessionID分组 组内进行一个排序 放到集合里面 通过UUID生成一个随机时间戳 遍历集合 赋值给临时会话字符串字段 然后前面两个元素的时间戳相差大于三十 就重新生成一个UUID赋值

3.地理位置集成  通过Geohash编码 将经纬度信息转换成一个字符串  然后根据字符串去数据库里面查询对应的省市区  如果查询不到的话 就通过IP2Region工具包 将IP解析成省市  先拿到数据库的省市区 广播到excutor端 然后读取到HDFS上的Ip工具包 然后先将数据的经纬度通过GEOhash解析成字符串 去判断数据库里面是否包含 包含就获取到字符串对应的省市区 然后回补  如果没有的话 我们就是IP 通过搜索器去搜索对应ID 然后回填

4.唯一ID的话 主要就是给那些匿名登录的绑定一个id 对于后面的用户行为分析的准确性有非常大的影响 漏斗 留存等等   会先设计一张绑定评分表 评分权重的 用于给匿名用户回填哪个ID 每天来的数据就会根据评分表进行一个关联 如果今天该设备此用户登录了 我们给他百分比增加权重  没登陆百分比减少权重  将设备ID权重最大的临时账号回补给匿名用户  然后根据临时账号去reids查询对应的guid 如果存在就赋值 不存在就用设备ID查  都不在重新创建一个自增的guid

5.新老用户： 打个标记 统计当天数据之前 先获取redis里面前一天最大的guid 赋值给标记  如果今天的guid如果大于标记 说明是新用户 标记新用户

我们项目中活跃的定义就是连续登录超过7天 表示活跃用户  留存的话就是当天注册的新用户 7天内登录了第二次表示为留存用户  流失就是三十天内没有登录表示流失用户  回流就是注册开始三十天外再次登录第二次表示回流用户

1.我们项目用的就是Github上面的Ip2Region 是一个离线IP地址定位库和IP定位数据管理框架 通过Ip查找算法先将工具包里面的每个市的开始ip和结束ip转成整数 生成一个区间  然后将数据ip转换为一个整数 通过二分查找法找到对应的区间的索引 根据索引就找到省市区了

2.还有一种方法就是高德地图API的一个插件AMap.CitySearch 可以通过IP定位获取当前城市信息 这个我们还没嵌入到项目中

1.形如漏斗 定义一条业务线 比如我们项目中的浏览商品 加入购物车 结算购物车 支付 完成这条业务线的每一步的人数不增只会减 我们分析每一步的转化率  作用就是如果有一步转化率太低了 我们得考虑原因 是什么显示效果 提供得功能不友好等等

2.计算思路是我们根据用户ID分组 找到这条业务线的所有事件 根据每个事件的事件时间 进行一个排序  找到每个用户在这条业务线最大的步骤的事件名称 和 最大步骤步数 在根据最大的步骤事件名称和步数 进一个分组 sum人数（开窗 排序 使用滑动窗口函数 窗口最后一行到当前行统计人数 因为现在是每个用户的最大步骤 但是走到最后一步了 决定经过了前面几步 所有我们得滑动窗口统计） 最后每步的人数 / 最大人数求出转化率

1.一个业务目标事件的达成 究竟是由哪些原因引起的  原因也分线性归因 首次触发  末次触发 时间衰减  位置归因   能够计算出每一个用户在指定目标事件上的，各待归因事件的影响大小 我们项目中主要用于点击到商品页 通过什么方式 是广告 还是轮播图 还是通过搜索 还是因为 促销活动各个原因等

2.计算思路：根据全局的唯一ID分组 然后找到所有归因的事件 根据每个事件的事件时间排序  获取到数据的唯一标识 获取到数据的目标事件和所有归因事件  放到一个元组 然后遍历归因事件 因为我们考虑的是线性归因平分权重

1.多行业务 描述一个业务就可以行转列 灵活性更强 像我们的事件归因使用纵表就比较方便  因为我们只需要关注一个字段里面的某一个事件 过滤掉不需要的数据 就需要行转列 缺点就是数据库数据推积众多

2.列转行的思路 一条数据就可以描述一个用户记录 数据比较清晰 像我们项目中一般DWD的表都是横表 用于多维分析 分组效率都比较快  但是扩展性比较低 如果要增加一个字段 整个表都需要重构

1.根据阿里的分层思想来的  我们是分的五层 ODS数据原始层-->将数据进行Json数据的预处理  DWD数据明细层--> 将ODS经过ETL清洗过滤 装载到此层  DWS数据设计层-->将DIM层的维度表跟DWD事实表Join所形成的宽表   ADS数据服务层--> 这一层的数据一般可以视图展示 DIM维度层-->用于一些多维计算等等 分层主要目的还是空间换时间 复杂问题简单化

1.根据甲方爸爸分析需求  分析行为域 业务域数据  决定数仓的建设 需要用什么技术来建仓 自下而上的设计思想  开始划分各个主题  用户主题 流量主题等等  设计原子指标 统一口径  开始梳理指标体系 整个体系同样要以业务为核心进行梳理。同时梳理每个业务过程所需的维度。维度就是观察业务的角度，指标就是衡量业务结果好坏。  然后根据指标去收集需要的数据  业务的动作 我们构建ER建模 便于后面的维度建模 维度表设计就是维度 多层维度  开始分层 什么样的层放什么样的数据 然后自下而上设计 模型建立ETL  数仓建设必须从业务中来，到业务中去   无论哪种建模方式，其核心是业务实体； 按领域建设能快速交活，后遗症将会在2年之后爆发，且难以解决 数仓建设应该把75%的时间投入到设计阶段  数仓本身也可以迭代 传统数仓并没有一种叫做“宽表模型”的模型 大数据时代新诞生的名词 因为很多大数据组件join代价极高 实际上是范式退化

1.存储企业各种各样的元数据 结构化（表结构） 非结构化（txt，图片，音频） 半结构化（json，xml，有自己的格式）的都可以  很多人觉得数据湖就是hadoop集群 是一种存储的概念 hadoop是实现这个概念的技术  处理的好（数据洋） 处理的不好（数据洼）

主要处理历史的 结构化数据 数仓的指标都是产品经理提前规定好的

前台和后台  前台就是直接与用户交互的界面Web页面 还包括实时响应的请求 搜索 订单查询   后台就是与运营人员打交道的 就是订单状态的更改 已经上架商品 下架商品 一些控制功能  让企业员工和客户和伙伴能够方便应用数据  数据中台就是连接前台和后台的

小型数据仓库   多个数据集市组成数据仓库  每个部门的一个数据集合

业务系统之间各自为政 相互独立造成的数据孤岛  举个例子 就是一个小组写代码一样  写到后面集合的时候特别难集合 可能都写这个部分 导致冲突  长时间后面 重复的越多  如果我们用gitee或者github管理系统 不断的上传 提交 看到什么没写 沟通然后写 效率 成本提高

使用Redis进行一个不频繁变动表的缓存 减少外部表的一个交互

我们项目中kafka中消费数据的偏移量是记录在状态中与下游的的checkPoint存在一起的 是能够保证数据重复消费的  flink的转换是利用的状态保证恢复到未处理的状态  sink的话我们CH是事务性不强的  所以我们用的是CH中的mergetree的变种引擎replacing的去重特性  通过数据的处理时间来保留最新的时间数据  但是由于CH底层的原理 他是定期合并重复数据  所以需要无时无刻查询最新的 需要手动合并  获取使用fianl关键字 但是效率低 数据量大不建议

维度表

事实表

粒度

星型模式

1.像我们的任务的话 还是得看任务吧 任务一般比较大的 我们就是部署yarn模式中的application-mode这样任务独享一个空间 让任务不受影响跑完   像跑小任务比较多的话 我们一般用session模式 不用每次提交作业都去申请资源 使用开辟的资源即可

2.资源分配的话大任务我们一般自己yarn根据任务的大小去分配资源的   小任务的话可能分配jobmanager taskmanager 分配1~3g吧  槽数量看并行度的情况

我们项目中是通过高德的逆编码去实现这个经纬度转换的 主要还是通过去本地数据库里面去查询地理位置信息 如果数据库里面没有 我们在异步I/O去高德的API去查询  从高德获取地理位置信息 先存入本地数据库里面  通过本地数据库返回（因为高德有配额 生产环境数据量特别大的时候 放到本地 提高复用性 性能也有一定的提升）

都会产生shuffle reduceBykey的话他会分组+聚合 并且每个区内预聚合 减少shuffle的落盘量  groupBykey只能分组要聚合的话你得配合sum使用 数据量不会减少

1.map将处理的数据逐条映射转换  将返回值构成新的 RDD 主要目的将数据源中的数据进行转换和改变 map算子是分区内一个数据一个数据的执行 性能低

2.mapPartiton是以分区为单位进行数据转换操作  会将整个内存的数据加载到内存  数据较大 会出现OOM内存溢出 是以分区单位进行批处理   性能高  会长时间占用内存 内存溢出

需求

在次需求

开发

测试

调度

处方药

非处方药

护具器械

患者信息表

地域维度表

医院信息表、医生信息表

处方表、处方详情表

订单表、订单详情表

患者行为

商城事件

医生行为

进程

线程

内核

逻辑处理器

QPS

多维数据建模  列式存储  多数据源

具有出色的性能和压缩功能

大规模数据分析和实时查询提供高性能和高可用性的解决方案

用于数据湖查询、数据探索、实时分析和交互式报表等各种数据分析任务

专门用于在Hadoop分布式文件系统上执行SQL查询

用于处理和查询存储在Hadoop HDFS（分布式文件系统）中的大规模数据

预计算，界面可视化

依赖较多，运维成本高  预计算量大，消耗资源  不适合即席查询

一个Cube由多个Cuboid组成

一次维度的组合计算的结果就是一个Cuboid

全量构建Cube只有一个Segment，增量构建一次就有一个Segment

Cube优化

1.读取数据

2.根据读取的数据和设置的维度构建维度表

3.创建HBase表

4.根据维度表构建字典表

5.构建Cuboid  0，1，2，3

6.将Cuboid组装Cube 生成HFile

7.将HFile加载到HBase

8.清理内存 清理垃圾 结束任务

要具有数据一致性，主键值必须是唯一的

维度表越小越好 因为会加载到内存中执行

改变频率低

维度表最好不要是 Hive 视图

Kylin

Druid

是一个分布式任务调度系统  将所有Task根据DAG流式方式组成起来

简单易用  丰富的使用场景  高扩展性

相对其它调用系统  高可用性、易用性、性能等

MasterServer

WorkerServer

ZooKeeper

Alert

Shell任务、Hive任务、Spark任务

kafka

1.日志收集

2.日志存储

3.日志展示和查询

4.监控指标采集

5.告警与通知

6.日志压缩和清理

7.权限控制

主从架构 主备切换

有错误日志

有告警

有重试机制

调度策略 可以跳过

最多得问题就是任务失败，挑战就是性能优化

是一个轻量级的工作流调度系统，适用于相对简单的任务调度和工作流管理

项目较小且需要快速部署

适用于复杂的数据处理流程   配置较为复杂

项目需要更丰富的任务类型和复杂的依赖关系

处理大数据任务时提供更高的性能和可用性

项目需要高可用性和大规模的任务调度

免费

灵活 支持多种数据源

SQL支持

扩展性强

可以将数据通过 仪表盘（ 饼状图 折线图 柱状图 ） 展示出来 更好看出数据的趋势

MySQL、PostgreSQL、Druid

1.确保数据源的性能优化。使用性能高效的数据库引擎

2.编写高效的SQL查询。避免不必要的JOIN操作和复杂的子查询

3.使用分页和分片来限制每次查询返回的数据量

4.查询结果缓存 提高性能

5.复杂和耗时的查询，可以将其设置为异步执行

提供了基于角色的控制  可以限制用户和角色对特定数据源、数据表、仪表盘和切片的访问权限

支持多种身份验证方式，包括基本身份验证、OAuth、LDAP

可以在仪表盘和报表中使用数据脱敏技术

可以生成审计日志，记录用户的操作和查询历史

数据库、队列、CPU、内存、磁盘、网络、Kafka、Redis

操作系统、云服务、自定义

Prometheus更适用于具有多维度数据模型、高级查询需求、动态环境以及云原生和容器化部署的场景

Ganglia更适用于传统的系统性能监控，特别是对历史数据绘图的需求较多的情况

Atlas是数据治理的一部分，它提供了管理、跟踪、保护和优化数据资产的关键能力

Altas

Ranger

可以相互集成在一起

确保Apache Atlas中的元数据得到适当的保护和访问控制可能是一个挑战

解决

优点

缺点

优点

缺点

优点

缺点