也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集。...CAP 没有考虑不同的基础架构、不同的应用场景、不同的网络基础和用户需求，而 C、A、P 在这些不同场景中的含义可能完全不同，这种无视差异化的定义导致了非常大的概念模糊，同时也变成 CAP 被质疑的源头...而实际上，因为机器原因发生的分区情况更常见一些，如果“很多”机器都发生故障，系统会因为一个“多数派”的丢失而导致不可用（比如，因为多数不存在，最新的读可能无法读取到上一次的写）。...把 CAP 的研究推到一个更广阔的空间：网络存在同步、部分同步；一致性性的结果也从仅存在一个到存在 N 个（部分一致）；引入了通信周期 round，并引用了其他论文，给出了为了保证 N 个一致性结果，至少需要通信的...其实 Lynch 的论文主要就是两件事：缩小 CAP 适用的定义，消除质疑的场景；展示了 CAP 在非单一一致性结果下的广阔的研究结果！并顺便暗示 CAP 定理依旧正确！
此示例将有两个带有数据的分区,其他分区将没有数据。...分区过少：将无法充分利用群集中的所有可用的CPU core 分区过多：产生非常多的小任务，从而会产生过多的开销 在这两者之间，第一个对性能的影响相对比较大。...它不会随着不同的数据大小而变化。...上文提到：默认情况下，控制shuffle分区数的参数spark.sql.shuffle.partitions值为200，这将导致以下问题 对于较小的数据，200是一个过大的选择，由于调度开销，通常会导致处理速度变慢...总结 本文主要介绍了Spark是如何管理分区的，分别解释了Spark提供的两种分区方法，并给出了相应的使用示例和分析。最后对分区情况及其影响进行了讨论，并给出了一些实践的建议。希望本文对你有所帮助。
如果消费者数量是 5，则 partition 的数目也应该是 ≥ 5 的。同时，过多的分区会导致生产吞吐的降低和选举耗时的增加，因此也不建议过多分区。...batch.size 设太小会导致吞吐下降，设太大会导致内存使用过多。...如何避免不必要的Rebalance 第一类：因为未能及时发送心跳，导致 Consumer 被踢出Group 而引发的。...四、避免数据丢失 由于生产端的原因导致数据丢失 生产者将数据发送到消息队列 CKafka 时，数据可能因为网络抖动而丢失，此时消息队列 CKafka 未收到该数据。...监控消费者的情况，正确调整数据的保留时间。监控当前消费 offset 以及未消费的消息条数，并配置告警，防止由于消费速度过慢导致消息过期删除。
维护阶段是对运行中的数据库进行评价、调整和修改。 问题 4： 插入记录时可以不指定字段名称吗？ 答： 不管使用哪种 INSERT 语法，都必须给出 VALUES 的正确数目。...对于全局索引，可以选择是否分区，而且索引的分区可以不与表分区相对应。当对分区进行维 护操作时，通常会导致全局索引的 INVALDED，必须在执行完操作后 REBUILD。...如果有几台不同的服务器分别存储组织中不同地区的数据，而您需要将这些服务器上相似结构的数 据组合起来，这种方式就很有用。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很 少。...答： 合理的索引可以提高查询的速度，但不是索引越多越好。在执行插入语句的时候， 数据库要为新 插入的记录建立索引。所以过多的索引会导致插入操作变慢。原则上是只有查询用的字段才建立索引。...如果需求发生变化， 而触发器没有进行相应的改变或者删除，则触发器仍然会执行旧的语句，从而会影响新的数据的完整性。 因此，要将不再使用的触发器及时删除。 问题 24： 什么是唯一索引?
笔者是一名专注研究大数据基础，架构和原型实现的“终身学者”，最近在看了108份面经之后，想对大数据面试中高频的知识考点做一个汇总，巩固自己记忆的同时，也希望能给带给读者一些正确复习方向。...4、Hive内部表、外部表、分区表、分桶表的区别，以及各自的使用场景 内部表 如果Hive中没有特别指定，则默认创建的表都是管理表，也称内部表。...使用 limit n 后，传输到 reduce 端（单机）的数据记录数就减少到 n* （map个数）。否则由于数据过大可能出不了结果。...，不是单纯的看你有没有背过这道题，而是看你是否能够根据执行顺序，写出不被人喷的 SQL 根据执行顺序，我们平时编写时需要记住以下几点： 使用分区剪裁、列剪裁，分区一定要加 少用 COUNT...c ) 大表Join大表：把空值的Key变成一个字符串加上一个随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终的结果。
小文件过多产生的主要问题包括： (1) 元数据管理低效 由于小文件数据内容较少，因此元数据的访问性能对小文件访问性能影响巨大。...由于NameNode联邦并不会改变集群中对象或者块的数量，所以它并没有解决MapReduce的性能问题。相反，联邦会增加Hadoop集群安装和维护的复杂度。...下面通过一个例子，Spark SQL写数据时，导致产生分区数"剧增"的典型场景，通过分区数"剧增"，以及Spark中task数和分区数的关系等，来倒推小文件过多的可能原因（这里的分区数是指生成的DataSet...上述只是给出3种常见的解决办法，并且要结合实际用到的技术和场景去具体处理，比如对于HDFS小文件过多，也可以通过生成HAR 文件或者Sequence File来解决。...由于并行度设置、数据量大小、Checkpoint配置的不同、分区的选择，都有可能导致产生大量的小文件，这对hdfs产生很大影响。
前段时间总结了一篇关于HBase由于分区过多导致集群宕机的文章，感兴趣的同学可以点击原文《HBase案例 | 20000个分区导致HBase集群宕机事故处理》阅读参考。...本文重点参考HBase官网，从分区过多这个角度出发，进一步聊一聊HBase分区过多的影响以及单节点合理分区数量等。...如果Region数量过多，MSLAB总的空间占用就会比较大。比如当前节点有1000个包含1个列族的Region，MSLAB就会使用1.95GB的堆内存，即使没有数据写入也会消耗这么多内存。...影响MapReduce并发数 当使用MapReduce操作HBase时，通常Region数量就是MapReduce的任务数，Region数量过多会导致并发数过多，产生过多的任务。...具体计算HBase合理分区数量 关于每个regionserver节点分区数量大致合理的范围，HBase官网上也给出了定义： Generally less regions makes for a smoother
它说的一致性就是客户端是否能拿到最新数据，它说的可用性就是允许客户端拿不到最新数据。而这些东西被工程师们的过多脑补，导致了文章和文章说法不一样，解析不一样，阐述背景不一样。...A：可用性 奥维德曾经说过：“行动被人们遗忘，结果却将永存”。 这句话说明了结果的重要性，而可用性在 CAP 里就是对结果的要求。...如果我们以可用性作为标准的时候，在发生分区错误时，由于我们对读请求并没有强行要求返回完全准确的数据，所以，可能在本次读请求之前的最近一次写请求可能是部分失败的。...CAP 的不足 CAP 定理本身是没有考虑网络延迟的问题的，它认为一致性是立即生效的，但是，要保持一致性，是需要时间成本的，这就导致往往分布式系统多选择 AP 方式 由于时代的演变，CAP 定理在针对所有分布式系统的时候...而强调可用性的时候，也往往会采用一些技术手段，去保证数据最终是一致的。CAP 定理并没有给出这些情况的具体描述。
拓展：面试一般喜欢通过笔试题或者真实场景题，来让你给出SQL思路或者现场手写，所以了解常用的 Hive函数非常重要，这直接就反映了自己的基本功。...4、Hive内部表、外部表、分区表、分桶表的区别，以及各自的使用场景 内部表 如果Hive中没有特别指定，则默认创建的表都是管理表，也称内部表。...使用 limit n 后，传输到 reduce 端（单机）的数据记录数就减少到 n* （map个数）。否则由于数据过大可能出不了结果。...，不是单纯的看你有没有背过这道题，而是看你是否能够根据执行顺序，写出不被人喷的 SQL 根据执行顺序，我们平时编写时需要记住以下几点： 使用分区剪裁、列剪裁，分区一定要加 少用 COUNT DISTINCT...c ) 大表Join大表：把空值的Key变成一个字符串加上一个随机数，把倾斜的数据分到不同的reduce上，由于null值关联不上，处理后并不影响最终的结果。
在生产中，无论是通过SQL语句或者Scala/Java等代码的方式使用Spark SQL处理数据，在Spark SQL写数据时，往往会遇到生成的小文件过多的问题，而管理这些大量的小文件，是一件非常头疼的事情...下面通过一个例子，Spark SQL写数据时，导致产生分区数"剧增"的典型场景，通过分区数"剧增"，以及Spark中task数和分区数的关系等，来倒推小文件过多的可能原因（这里的分区数是指生成的DataSet...算子对union产生的新的RDD的分区数是如何受被union的多个RDD的影响的，做过详细介绍，这里直接给出结论： ?...在数仓建设中，产生小文件过多的原因有很多种，比如： 1.流式处理中，每个批次的处理执行保存操作也会产生很多小文件 2.为了解决数据更新问题，同一份数据保存了不同的几个状态，也容易导致文件数过多 那么如何解决这种小文件的问题呢...小文件定期合并 可以定时通过异步的方式针对Hive分区表的每一个分区中的小文件进行合并操作 上述只是给出3种常见的解决办法，并且要结合实际用到的技术和场景去具体处理，比如对于HDFS小文件过多，也可以通过生成
（比如tableA中保存的是应用相关的数据，其中有个字段type用于区分业务线，一般查询的情况下是查询某type的数据，并非是全量）分区标识： ymd是分区字段，visit_time是具体访问时间正确的...by id基数太大会消耗过多的io和内存。...不要使用OR做条件连接---在WHERE子句中使用OR来连接条件，将导致引擎放弃使用索引而进行全表扫描。...where num = 10 or num = 20避免再where子句中对字段进行表达式操作---使用后将导致引擎放弃使用索引而进行全表扫描。...使用后将导致引擎放弃使用索引而进行全表扫描。
local index的第一个分支就找到了结果，不再继续扫描下去；最差的情况是扫描到local index的最后一个分支才找到结果，或是没有找到结果。...一般情况下，local index索引的使用，需要配合分区字段一起做谓词条件，才能只扫描少数的索引分支。而这个SQL由于业务原因，不能增加分区字段作为谓词条件。...，其他数据转移到历史分区，正常情况只需要最多扫描2个分区，而不是原来的6030个分区。...3、通过plsql实现查询：当前分区没有查询到结果，再去查询历史分区。这样也能保证超过2个月的快递单也能正常查询。...避免过多的local index 扫描，影响SQL性能。
过程要看计算后对应多少分区： 若一个操作执行过程中，结果RDD的每个分区只依赖上一个RDD的同一个分区，即属于窄依赖，如map、filter、union等操作，这种情况是不需要进行shuffle的，同时还可以按照...pipeline的方式，把一个分区上的多个操作放在同一个Task中进行； 若结果RDD的每个分区需要依赖上一个RDD的全部分区，即属于宽依赖，如repartition相关操作（repartition，coalesce...hash分区，可直接join；如果要关联的RDD和当前RDD的分区不一致时，就要对RDD进行重新hash分区，分到正确的分区中，即存在ShuffleDependency，需要先进行shuffle操作再join...因此要解决这个问题需要修改Linux允许创建更多的进程，就需要修改Linux最大进程数 2、报错信息 由于Spark在计算的时候会将中间结果存储到/tmp目录，而目前linux又都支持tmpfs，其实就是将.../tmp目录挂载到内存当中, 那么这里就存在一个问题，中间结果过多导致/tmp目录写满而出现如下错误 No Space Left on the device（Shuffle临时文件过多） 解决方案： 修改配置文件
过程要看计算后对应多少分区： 若一个操作执行过程中，结果RDD的每个分区只依赖上一个RDD的同一个分区，即属于窄依赖，如map、filter、union等操作，这种情况是不需要进行shuffle的，同时还可以按照...pipeline的方式，把一个分区上的多个操作放在同一个Task中进行 若结果RDD的每个分区需要依赖上一个RDD的全部分区，即属于宽依赖，如repartition相关操作（repartition，coalesce...hash分区，可直接join；如果要关联的RDD和当前RDD的分区不一致时，就要对RDD进行重新hash分区，分到正确的分区中，即存在ShuffleDependency，需要先进行shuffle操作再join...因此要解决这个问题需要修改Linux允许创建更多的进程，就需要修改Linux最大进程数 （2）报错信息 由于Spark在计算的时候会将中间结果存储到/tmp目录，而目前linux又都支持tmpfs，其实就是将.../tmp目录挂载到内存当中, 那么这里就存在一个问题，中间结果过多导致/tmp目录写满而出现如下错误 No Space Left on the device（Shuffle临时文件过多） 解决方案： 修改配置文件
长期保存索引，按天创建会导致集群中索引数量膨胀，间接导致集群 shard 过多，元数据膨胀，影响集群稳定性，拖慢集群重启恢复速度。...1.3 不建议索引不分区 建议索引实际保存时按照业务时间进行分区，不建议不分区。不分区索引随着数据写入的增加，超过预估容量之后会导致写入变慢，索引扩容迁移恢复均有很多问题，影响业务使用。...，不建议对message 进行全文索引，由于 message 字段的不确定性，全文索引情况下会导致相应的 Terms 膨胀，会耗费大量内存、存储空间，以及写入性能的快速下降。...3.3 不建议查询命中过多的数据 ES 每次查询都会返回该次查询的全部命中结果，这会导致需要命中全部的数据，有些情况下还要对这些数据进行打分排序，造成整体性能缓慢。...在查询的返回结果中，timed_out 告知了用户是否超时，false表示没有超时。true表示超时，此时需要注意查询结果是否不完整。如下示例，timed_out=false，表示查询没有超时。
磁盘的0号扇区称为“主引导记录”（MBR），用来引导计算机，MBR的结尾是分区表，该表给出每个分区的起始和结束地址。...但是这种方案在随机存取时却是非常耗时的，同时由于指针占用了一个字节的空间，导致无法使用2的整数次幂来操作整个磁盘块，这样也会降低系统的运行效率。 2.3....文件分配表（FAT） 解决链表分配的两个问题的方法就是将指针域提取出来组成一个表格，被称为“文件分配表”（FAT），如下图所示： 但是由于大磁盘拥有过多的块，文件分配表会异常巨大，FAT方案就不太合适了...日志结构文件系统 — LFS 文件系统的瓶颈在于，CPU、内存的访问速度越来越快，而磁盘的访问速度却没有多大提升，为了解决这个问题，伯克利大学设计了一种全新的文件系统 — 日志结构文件系统（LFS） 由于磁盘主要的操作是写操作...日志文件系统 由于日志结构文件系统需要操作系统的支持而没有得到广泛应用，但是其思想却得到了很大的借鉴。
RETURNING结果可能不正确计算的问题 PG13.3 如果针对分区表的UPDATE导致行移动到具有物理上不同行类型的另一个分区（例如，包含不同一组已删除列的行），为该行计算的RETURNING结果可能会产生错误或错误的答案...表达式的匹配没有正确进行，因此一个可用的子索引可能被忽略，导致创建重复的索引。...PG13.10 修复并行哈希连接中的边缘案例数据损坏，如果一个大元组的最终块要写入临时文件的大小恰好为32760字节，由于一个错误，它将会被损坏。查询通常会在稍后由于数据损坏的症状而失败。...= off，则会在“恢复在...事务之前停止”日志消息中打印一个不正确的时间戳 PG13.10 改进一些缓冲文件读取失败的错误报告，正确报告短读取，给出期望读取的字节数和实际读取的字节数，而不是报告一个无关的错误代码...PG13.13 修复由于尝试根据伪造的 WAL 记录长度字段分配内存而可能导致的恢复失败 PG13.13 增加对 LLVM 16 和 17 的支持 PG13.14 版本号 BUG FIXED/功能更新
由于囊中羞涩，reizhi 一直在使用黑群晖作为家庭存储方案。不知何故，几天前突然提示存储空间已损毁。这种情况下白群晖是可以直接联系技术支持的，无奈我只好自己想办法解决。...而网络上搜索到的教程和案例都是使用 Ext4 作为文件系统，那么只需要用 UFS explorer 来修复就好了。偏偏我是用的是 Btrfs 文件系统，于是只好爬问研究。...虽然 Btrfs 相比于 Ext4 并没有任何稳定性上的优势，但经过多年的更新和改进文件系统已经比较完善，再加上 RAID 的数据保护，丢失文件的几率并不高。...如果文件名包含特殊符号可能导致导出中断，将目标分区格式化为 Ext3/4 即可。 如果导出正常进行，会看到类似上图的提示，此处没有进度提示，可以自行前往导出目录查看。...如果导出失败会给出其他提示，在确认导出分区是 Ext3/4 的情况下，则只能退回上一步尝试其他 值。
堆：用的最多的分区也是最容易出问题的一个分区，堆内存需要配合垃圾收集器一起进行工作，通常情况下堆溢出是由于老年代回收之后还是有很多对象（占满），导致对象无法再继续分配而产生OOM的异常。...分区溢出模拟： 方法区： 首先是方法区的空间溢出，这里不介绍过多的概念，上一节也提到了方法区多数情况下是由于动态生成类过多导致方法区产生了溢出，下面用一段代码来模拟： 建立项目的步骤这里省略，直接使用...在每一次的工作线程执行代码的时候，都会执行一次RPC的远程调用，而当RPC服务挂掉的时候，此时由于连接远程服务器迟迟得不到响应导致系统需要等待4秒才会释放线程，在等待的时候工作线程会占用这个请求的资源并且卡死在线程上等待结果...，如果在同一时间有很多的请求就会出现百来个工作线程挂在自己的线程卡死并且等待响应的结果，最终由于堆内存占用过多的数组对象，无法再分配新的对象导致OOM！...排查结果： 排查的结果就是「服务A改了Request而m没有通知服务B修改对应的对象」，导致反序列化失败并且新建了一个Byte[]数组来存放序列化的数据，而这个数组默认值刚刚好就设置了4G的大小！
表和索引的优化统计信息被删除，或者重新收集后统计信息不准确。重新收集统计信息通常是由于收集策略（方法）不正确引起。...比如对分区表使用analyze命令而不是用dbms_stats包、收集统计信息时采样比例过小等等。Oracle优化器严重依赖于统计信息，如果统计信息有问题，则很容易导致SQL不能使用正确的执行计划。...由于有area条件，因此会使用分区排除。...如果第1 次执行时应用传给b1变量的值正好落在P1分区上，很可能导致SQL采用全表扫描访问，如前面所描述的，导致SQL后续执行时全部使用了全表扫描。 3....当然也有维护人员操作不当引起的SQL性能突然变差，比如建了某个索引而没有收集统计信息，导致SQL使用了新建的索引，而该索引并不适合于那条SQL；维护人员意外删除了表个索引的统计信息。 ?
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
