wuhahaq的博客

他们都是用utf-8的编码方式,对于get请求，他的编码格式默认是按照浏览器的编码格式进行编码的，我们可以设置浏览器的编码格式，但是每个用户的浏览器的编码格式不可能都是一致的，这样我们的get请求的参数有时候就会出现乱码问题，但是如果我们自己在前端对get请求利用encodeURI()或者encodeURIComponent ()来统一设置成utf-8编码，这样我们在后台在用utf-8来解码，就不会出现乱码问题。不安全字符：还有一些字符，当他们直接放在Url中的时候，可能会引起解析程序的歧义。

DataHub支持那些工具

把XXL-Job中的lohback.xml导入到Spring Cloud 项目中。整合pom文件，在Spring Cloud中添加XXL-Job的依赖。向Spring Cloud中导入XxlJobConfig.class。application.properties整合。这个两个路径需要修改。

第一步：服务注册，首先Nacos Client会通过发送Rest请求的方式向Nacos Server注册自己的服务，提供自己的元数据，元数据有ip地址，端口等信息。Nacos接收到注册请求后,就会把这些元数据信息存储在一个双层的内存Map中。第二步：服务心跳，在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。心跳机制默认是5S一次。第三步：服务同步，Nacos Server集群之间会互相同步服务实列，用来保证服务信息的一致性。第

Seata的设计目标是对这个业务无侵入，因此从业务无侵入的2PC方案开始的，在传统的2PC的基础上演进的。它把一个分布式事务拆分理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致性，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个关系数据库的本地事务。

事务就是一个操作单元，在这个操作单元中的所有操作最终要保持一致的行为，要么所有操作都成功，要么所有操作都被撤销。也就是说，事务提供了一种“要么什么都不做，要么全做”的机制。

半事务消息：暂不能投递的消息，发送方已经成功地将消息发送到 RocketMQ服务，但是服务端 未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息 为半事务消息。RocketMQ服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或者 Rollback）,该询问过程 消息回查。2.RocketMQ服务端将消息持久化之后，向发送方返回Ack确认消息已经发送成功，此时消息为半事务消息。

松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，列如：京东、淘宝。简单方便，高度耦合，扩展性差，适合小型项目。列如：学生管理系统。优点：拆分颗粒度更小、服务更独立、耦合度更低。缺点：架构非常复杂，运维、监控、部署难度提高。

默认100M,可以改为200默认0.8，可以改为0.9（不影响业务逻辑的前提下，只能加减，不能做乘除等复杂聚合）

第九步：合并成大文件后，Shuffle的过程就结束了，后面就要进行ReduceTask的逻辑运算过程（从文件中取出一个一个的键值对Group,调用用户自定义的reduce()方法）第八步：ReduceTask取到用一个分区的来自不同MapTask的结果文件，ReduceTask会将这些文件再进行合并（归并排序）第四步：在环形内存缓冲区在达到默认80%的时候就会开始往本地磁盘中不断溢出，可能会溢出多个文件。第六步：在溢出过程及合并的过程中，都要调用Partition进行分区和针对key进行排序。

Hive外部表：外部表的数据不是Hive拥有或者管理的，只管理元数据的声明周期。删除外部表是只会删除元数据，而不会删除实际数据（源数据）。hive完全管理表（元数据和数据）的声明周期，类似于RDBMS的表。当删除表时，他会删除源数据以及表的元数据。所以我们在选择建表时，当需要通过hive完全管理控制表的整个生命周期时，请使用内部表。当文件已经存在或者位于远程位置的时候，请使用外部表，因为即使删除表，文件也会被保留。内部表删除会删除HDFS存储的源数据以及元数据也被删除。表区内部表和外表的区别。

雪花模型与星座模型的区别主要在于维度的层级，标准的星型模型只有一层，而雪花模型可能会涉及多级。

Linux crontab是采用定期执行程序的命令，当安装完成操作 系统后，默认便会启动此任务调度命令，crond命令每分钟都会定期检查是否要执行任务的工作，如果要执行的工作便会自动执行该任务。（定期执行某个命令，相当于java中的timer）

大数据高频面试题-项目中常见问题_大数据开发针对项目一般问的问题_Mr.光铭的博客-CSDN博客

⾸先Kafka从架构上说分为⽣产者Broker和消费者,每⼀块都进⾏了单独的优化,⽐如⽣产者快是因为数据的批量发送，Broker快是因为分区,分区解决了并发度的问题,⽽且⽂件是采取的顺序写的形式。顺序写就可以有效的减少磁盘寻址的时间其次它还采⽤了分段的概念，就是所谓的Segment，每⼀个Segment⼜包含⼀个索引⽂件和⼀个数据⽂件，通过这样的机制就保证写⼊速度是⾮常的快的。

如果消费者设置的过多的话是没有效果的，因为他们之间的关系是⼀⼀对应的,多余的消费者线程就会产⽣空 转，如果消费者设置的过少就会导致⼀个消费者线程消费多个分区的数据，同时这里还有⼀个动态分区的机制存在,如果⼀个消费者消费的分区过多就会触发这个机制,每当新的消费者上线或者增加了新的分区就会重新的负载均衡此时消费者分区数就会产生变化,这⼀块如果对接SparkStreaming还需要⾃⼰来维护Offset,已达到精准⼀次消费的⽬的。在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。

这种情况是不会丢失数据的，因为Broker包含Topic,Topic又包含Partition，而Partition里边还有副本，这里就会有Leader和Follower的概念，此时生产者发送消息后，但是会有数据重复的问题，这个问题可以在下游消费数据的时候进行处理一般都是采用去重的操作；

消息队列的产品有很多中比如：React MQ 、Kafka等。为什么选择Kafka作为消息队列来处理数据，当时我们组也是做了大量的调研；我们当时调研考虑的主要是指标吞吐量这一块，因为大数据流式处理对数据的吞吐量要求是非常高的，在这快React MQ是比较厉害的。吞吐量可以达到1万多每秒，通过后来的调研发现kafka的吞吐量比React MQ更高，如果使用恰当的话吞吐量甚至可以达到10万+没秒。

下游数据传输使⽤的是Kafka作为消息队列来传输消息，使⽤Kafka的主要原因是因为Kafka的⾼吞吐量以及可以对数据进⾏分类也就是不同的topic，⽅便下⼀层的使⽤，整体的架构是采⽤Lamda架构设计的，实时和离线都会从Kafka中获取数据来进⾏处理,⽽且还有其他的业务线也是从Kafka中获取数据的,这样做以后可以有效的提⾼数据的复⽤减少数据的冗余。主要是为了对接Kafka，使⽤这个可以节省Sink组件也可以提升效率的，我们项⽬中使⽤的就是这个Channel，因为下⼀层是使⽤Kafka来传递消息的。

7.数据存储方面，离线数仓一般将数据存储在HDFS、Hive中，实时数仓一般将数据存储在kafak、Hbase.Redis、Clickhouse中。1.架构选择方面，离线数仓采用传统大数据框架模式搭建，而实时数仓采用Kappa架构方式搭建。4.实时性方面：离线数仓统计数据结果一般是T+1,实时数仓统计结果一般是分钟级别、秒级别。6.数据吞吐量方面，离线数仓吞吐量都很高，实时数仓随着实时技术发展吞吐较高。3.准确性方面，离线数仓准确性高，实时数仓随着技术发展，准确度也比较高。