Apache HBase

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 高并发，几乎是每个程序员都想拥有的经验。原因很简单：随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。 在过往的面试中，如果候选人做过高并发的项目，我通常会让对方谈谈对于高并发的理解，但是能系统性地回答好此问题的人并不多，大概分成这样几类： 1、对数据化的指标没有概念：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的QPS和TPS等关键数据。 2、设计了一些方案，但是细节掌握不透彻：讲不出该方案要关注的技术点和可能带来的副作用。比如读性能有瓶颈会引入缓存，但是忽视了缓存命中率、热点key、数据一致性等问题。 3、理解片面，把高并发设计等同于性能优化：大谈并发编程、多级缓存、异步化、水平扩容，却忽视高可用设计、服务治理和运维保障。 4、掌握大方案，却忽视最基本的东西：能讲清楚垂直分层、水平分区、缓存等大思路，却没意识去分析数据结构是否合理，算法是否高效，没想过从最根本的IO和计算两个维度去做细节优化。 这篇文章，我想结合自己的高并发项目经验，系统性地总结下高并发需要掌握的知识和实践思路，希望对你有所帮助

Flink精准去重 概述 为啥需要去重 在某些情况下，由于上游的作业不是端到端的exactly-once，在上游出现问题自动failover的时候，该任务的sink端很大可能出现重复数据；这些重复数据又会影响下游的聚合作业（如SUM，COUNT）。所以，我们的作业需要去重完再进行计算 去重方法 TopN（Flink官网推荐的方式） Group By UDTF（维表去重） 各自优缺点 前两者纯内存去重，效率高，速度快，使用简单；但是一旦任务KILL再启动就会有状态丢失，那么下游计算过的数据又会计算一次；同样，因为使用到STATE，那么就要配置合理的STATE TTL，不然STATE会越来越大，对checkPoint会有影响 第三个的问题在于需要用户手写UDTF，难度较高（写UDTF可以参考 Flink UDF ）；其次状态保存在存储中间件中，查询和插入都是同步操作，效率较低，受网络和中间件的影响比较大；最后，如果上游发生撤回流，无法撤回中间件中的数据，会导致数据被错误过滤；也有优点：任务重启之后，不会影响下游数据的准确性。 下面我们开始依次看看怎么用的 TopN 语法： SELECT [ column_list ] FROM ( SELECT [ column_list ] , ROW_NUMBER ( ) OVER ( [ PARTITION BY col1 [ , col2 .

文章目录 1 Facebook Spark 的使用情况 2 扩展 Spark Driver 2.1 动态资源分配 2.2 多线程事件处理 2.3 更好的 Fetch 失败处理 2.4 RPC 服务线程调优 3 扩展 Spark Executor 3.1 启用堆外内存 3.2 垃圾收集调优 3.3 Shuffle 调优 3.3.1 Shuffle file buffer 调优 4 扩展 External Shuffle Service 4.1 在 Shuffle Server 上缓存索引文件 4.2 shuffle service 工作线程和 backlog 调优 4.3 Configurable shuffle registration timeout and retry 5 应用程序调优 Facebook Spark 的使用情况 在介绍下面文章之前我们来看看 Facebook 的 Spark 使用情况： 如果想及时了解 Spark 、Hadoop或者HBase相关的文章，欢迎关注微信公众号： iteblog_hadoop 如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号： iteblog_hadoop Spark 是 Facebook 内部最大的 SQL 查询引擎（按 CPU 使用率计算） 在存储计算分离的集群上使用 Spark

JanusGraph批量导入数据优化 批量导入工具： https://github.com/dengziming/janusgraph-util 批量导入配置项 storage.batch-loading =true 导入的数据必须具有一致性并且和已存在的数据必须具有一致性。（比如：name数据是具有唯一索引（a unique composite index），那么导入的数据在name属性上上和已有的数据不能重复） 下面是优化配置，优化的目的，就是减少批量导入时间。 ID 分配优化 ID Block Size ids.block-size 配置项，JanusGraph实例通过id池管理对象从id blocks中获取ids值为新加入的vertex、edge分配唯一id，为了保证库唯一性，所以获取id block（id块）是昂贵的（因为存在多个实例竞争），所以增加block-size可以减少获取block的次数，但是值过大会导致多余的id被浪费掉。 一般情况下事务的负载，ids.block-size的默认值是满足要求的。但是对于批量导入时，需要调节值为每个JanusGraph实例需要添加节点和边数的10倍。 该配置项在集群中所有实例上值必须唯一。 ID Acquisition Process 1) ids.authority.wait-time 配置毫秒：id池管理器允许id

HBase在大数据量并发写入时，写一段时间后HBase监控界面出现告警，写入程序日志里频繁出现异常java.util.concurrent.RejectedExecutionException： 从异常堆栈信息可以看出是flush请求时被拒绝引起的，核对一下flush的代码。 我们单位办公电脑在内网里，不便粘贴代码和异常信息，这里手动写几行代码大体说明情况。 1 Configuration conf = HBaseConfiguration.create(); 2 Connection connection = ConnectionFactory.createConnection(conf); 3 Table table = null ; 4 try (Admin admin = connection.getAdmin()) { 5 TableName tableName = TableName.valueOf("test:table" ); 6 table = connection.getTable(tableName); 7 table.put(puts); // List<Put> puts 8 admin.flush(tableName); 9 } finally { 10 if (table != null ) { 11 table.close(); 12 } 13 }

​ 如何用形象的比喻描述大数据的技术生态？Hadoop、Hive、Spark 之间是什么关系？对于大部分人来说都是傻傻分不清楚。 今年来大数据、人工智能获得了IT界大量的关注。如果一个企业不玩大数据，都不好意思说自己是在IT圈混的。我敢打赌，你在中关村西二旗地铁站溜一圈，保准你会听到如下名词：Hadoop、Spark、MapReduce、NoSQL、离线计算、实时计算、实时推送等等一大串名称。 程序猿们就是有这么实在，坐在地铁上还能那么投入的讨论技术问题。那么，这些听起来高大上的技术，究竟都是干什么用的呢？他们之间的有什么区别和联系？ 通常，一个技术的兴起，都是由现实需求驱动的。了解了我们面临的问题，就能更好的理解各个大数据技术的使用场景，各类大数据技术的区别也就显而易见了。 今天这一份书单，我们就将从Hadoop生态圈开始入手，推荐几本关于Hadoop生态圈的优质书籍！ Hadoop技术栈系列书单 ​ Hadoop权威指南：大数据的存储与分析(第4版) 本书结合理论和实践，由浅入深，全方位介绍了Hadoop这一高性能的海量数据处理和分析平台。 全书5部分24章，第Ⅰ部分介绍Hadoop基础知识，主题涉及Hadoop、MapReduce、Hadoop分布式文件系统、YARN、Hadoop的I/O操作。第Ⅱ部分介绍MapReduce,主题包括MapReduce应用开发

使用阿里云rds for MySQL数据库（就是MySQL5.6版本），有个用户上网记录表6个月的数据量近2000万，保留最近一年的数据量达到4000万，查询速度极慢，日常卡死。严重影响业务。 问题前提：老系统，当时设计系统的人大概是大学没毕业，表设计和sql语句写的不仅仅是垃圾，简直无法直视。原开发人员都已离职，到我来维护，这就是传说中的维护不了就跑路，然后我就是掉坑的那个！！！ 我尝试解决该问题，so，有个这个日志。 方案概述 方案一：优化现有mysql数据库。优点：不影响现有业务，源程序不需要修改代码，成本最低。缺点：有优化瓶颈，数据量过亿就玩完了。 方案二：升级数据库类型，换一种100%兼容mysql的数据库。优点：不影响现有业务，源程序不需要修改代码，你几乎不需要做任何操作就能提升数据库性能，缺点：多花钱 方案三：一步到位，大数据解决方案，更换newsql/nosql数据库。优点：扩展性强，成本低，没有数据容量瓶颈，缺点：需要修改源程序代码 以上三种方案，按顺序使用即可，数据量在亿级别一下的没必要换nosql，开发成本太高。三种方案我都试了一遍，而且都形成了落地解决方案。该过程心中慰问跑路的那几个开发者一万遍 :) 方案一详细说明：优化现有mysql数据库 跟阿里云数据库大佬电话沟通 and Google解决方案 and 问群里大佬，总结如下（都是精华）： 1

今日在portianer后台，查询应用模板时，偶尔看到一个名为CrateDB的数据，顺手查了一下。其中就一一篇标题名为“比Postgre快10倍的开源数据库CrateDB”的文章，第一个感觉，就是口气好大哈。在不了解的情况下，也不敢妄自菲薄哈。先了解下这个东西吧。 我们还是先上图，下图摘自网络，这算是对CrateDB的优点进行了描述。 摘自《比Postgre快10倍的开源数据库CrateDB》文章中的某段内容： 一张拥有20多个字段的表，记录大约有3亿条，需要查询某个时间范围内的数据，并做分组，排序，聚合统计操作，并需要即时响应结果，大家看到这个需求，一定深有体会，传统的关系型数据库不能满足需求，肯定能想到的方案是hbase，ElasticSearch了，hbase方案稍微有点重，ElasticSearch又对sql支持不太好，那有没有既对sql支持，响应速度又快的开源产品呢，CrateDB就满足上述的需求 看完这段描述后，感觉单表超3亿的数据库，做分组、排序、聚合等操作，算是逆天了。CrateDB是基于 ElasticSearch的，再次基础上，提供了sql的支持，也算是其点亮的一部分。这里我们和快会想到，这种数据库必然在ACID方面存在某种缺陷。果不其然， CrateDB不适合强事物的场景。 CrateDB官网地址 ： https://crate.io/

CAP理论的理解 CAP理论作为分布式系统的基础理论,它描述的是一个分布式系统在以下三个特性中： 一致性（ C onsistency） 可用性（ A vailability） 分区容错性（ P artition tolerance） 最多满足其中的两个特性。也就是下图所描述的。分布式系统要么满足CA,要么CP，要么AP。无法同时满足CAP。 　　　　　　　　 I. 什么是 一致性、可用性和分区容错性 分区容错性 ：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。 事实上我们在设计分布式系统是都会考虑到bug,硬件，网络等各种原因造成的故障，所以即使部分节点或者网络出现故障，我们要求整个系统还是要继续使用的 (不继续使用,相当于只有一个分区,那么也就没有后续的一致性和可用性了) 可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。 一致性 ：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。 II. 该怎么理解 如果我们 事先保证了分区容错性 ，也意味着若某个节点故障了，用户还是可以继续访问

在做流式计算过程中，最复杂最难做的莫过于数据幂等性修改操作的设计。先解释一下概念【幂等性操作】，幂等性概念来源于数学专业表示对一个表达式做多次相同的操作，表达式不会改变。例如：逻辑回归中的Sigmod函数，n次求导之后依然坚挺。在流式计算中容错设计也要求工程设计有数据幂等性设计，特别针对流式计算中对第三方存储平台的修改操作。以及更加逆天的场景：在一个业务线有多个点有批量的数值修改操作，只要有一个点没有修改完成，而此时流式计算崩溃，下次重启都要做所有点的数据恢复操作。 说到幂等性，不得不说一下spark中的一个优化操作---推测执行。推测执行设计的初衷是提高作业的执行效率，避免某一个任务因为硬件问题卡死而拖慢整个计算任务。大致设计思想时，在任务完成达到某个百分比，开始检查任务完成情况，如果发现某任务执行时间超过其他任务耗时均值的阈值倍数，就在其他节点重启相同的计算任务，这样可以有效避免因硬件问题造成的卡死现象。但是在流式计算中对于修改数值的操作或者在mappartion/foreachPartition中自定义数据持久化到非主键约束的平台时，就会出现灾难性后果。一旦出现数据倾斜，启动备用线程执行当前任务，就会出现数据加倍等脏数据。所以在以上场景，无法保证操作幂等性的前提下，不要开启推测执行。 今天着重分享对于hbase的幂等性修改的设计