Apache HBase

otter自定义扩展 otter支持数据处理自定义过程。 Extract模块： EventProcessor : 自定义数据处理，可以改变一条变更数据的任意内容 FileResolver : 解决数据和文件的关联关系 目前两者都只支持java语言编写，但都支持运行时动态编译&lib包载入的功能。 通过Otter Manager直接发布source文件代码，然后推送到node节点上即时生效，不需要重启任何java进程，有点动态语言的味道 可以将class文件放置到extend目录或者打成jar包，放置在node启动classpath中，也可以通过Otter Manager指定类名的方式进行加载，这样允许业务完全自定义。(但有个缺点，如果使用了一些外部包加入到node classpath中，比如远程接口调用，目前EventProcessor的调用是串行处理，针对串行进行远程调用执行，效率会比较差. ) 数据处理扩展的示例代码 场景一：根据业务逻辑判断是否同步该条数据 package com.alibaba.otter.node.extend.processor; import com.alibaba.otter.shared.etl.model.EventColumn; import com.alibaba.otter.shared.etl.model.EventData;

LSM Tree（Log-structured merge-tree）广泛应用在HBase，TiDB等诸多数据库和存储引擎上，我们先来看一下它的一些应用： 这么牛X的名单，你不想了解下LSM Tree吗？装X之前，我们先来了解一些基本概念。 设计数据存储系统可能需要考虑的一些问题有：ACID，RUM（Read,Write,Memory）。 ACID ACID 相信小伙伴都被面试官问过，我想简单讨论的一点是：如何 持久化数据 才能保证数据写入的 事务性 和 读写性能？ 事务性可简单理解为：1.数据必须持久化。2.一次数据的写入返回给用户 写入成功就一定成功，失败就一定失败。 读写性能可简单理解为：一次读 或 一次写 需要的IO次数，因为访问速率：CPU>>内存>>SSD/磁盘。 对于单机存储，最简单的方式当然是：写一条就持久化一条，读一条就遍历一遍所有数据，然后返回。当然没人这么干，在内存中我们都还知道用个HashMap呢。 拿Mysql InnoDB举例子：读性能体现在数据的索引在磁盘上主要用B+树来保证。写性能体现在运用 WAL机制 来避免每次写都去更新B+树上的全量索引和数据内容，而是通过redo log记录下来每次写的增量内容，顺序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，然后在一定条件下触发脏页的刷盘。 redo

公众号检索挺麻烦的，HBase相关前面01-08的内容可以到我的github看 https://github.com/saigu/JavaKnowledgeGraph 在之前学习MySQL的时候，我们知道存储引擎常用的索引结构有B+树索引和哈希索引。 而对HBase的学习，也离不开索引结构的学习，它使用了一种LSM树（(Log-Structured Merge-Tree)）的索引结构。 下面，我们就结合HBase的实现，来深入了解HBase的核心数据结构与算法，包括索引结构LSM树，内存数据结构跳表、文件多路归并、读优化的布隆过滤器等。 1.LSM树 LSM树和B+树、哈希索引一样，是一种索引结构，那它们有什么区别呢？ 哈希存储引擎是哈希表的持久化实现，支持增、删、改以及随机读，但不支持顺序扫描，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操作快。 B+树不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间是链表的结构），对应的存储系统就是关系数据库（Mysql等）。 LSM树存储引擎和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。

题记 这是星球-静夜思模块里面一篇文章，有感于星球微信群的一次交流，连夜边思考边记录了下来。 静夜思模块完全是深夜里由感而发，大多包含但不限于：认知的梳理 、方法论的探讨、各种问题的暗时间思考…… 微信群机缘巧合，认识了很多领域的先行者、持续技术跟进者，统称或者俗称大佬。 比如：硅谷、腾讯云、阿里云、蚂蚁金服、小米、华为、Oracle一线大厂ES大佬。 比如：HBASE大佬 比如：SPring大佬 比如：Flink大佬 面对大佬，我们的表情通常是这样的？ 一方面：对大佬，我们要敬重，肯定某些领域比我们经验丰富，值得我们去学习！ 另一方面：我们要学习和反思。 大佬到底是如何炼成的？我认为这更重要。 相比大佬近况，我更喜欢看大佬的成长历程，如何一步步成长的！ 结合我的近十年的从业经历和大量观察，总结出以下十点认知。 第一：没有人一下就是大佬 著名骨灰级程序员左耳朵耗子 当年也是从小城市辗转反侧到上海、北京，从事业单位、私企、小外企、亚马逊、阿里、创业。 也经历过面试C语言基础一问三不知的情况。他的20几年的心路历程，能看得出一步步点滴积累的重要性。 早期的collshell文章深度没有那么深，甚至再早期05年之前都是在CSDN发文的，但是的的确确是有非常详尽、经历思考的干货总结。 第二：爷爷都是从孙子做起的 话糙理不糙。知名自媒体，财务自由的90后帅张。最早机房打杂，干过测试、开发

访问Hbase表时，遇到问题报错： Failed 2 actions: org.apache.hadoop.hbase.exceptions.FailedSanityCheckException: Requested row out of range for doMiniBatchMutation on HRegion C_VIP,7841550515151G61700013047NT,1554743634303.fa5125151452729737659ef06fc2bbeb., startKey = '7841550515151G61700013047NT' , getEndKey ( ) = '8006490844551PBM13686838900NT' , row = '8562248218851PBW13843166713NT' 问题原因： 由于在做暴力合并region的情况下，导致region顺序出现问题，最后一个region块的最大key值不是无穷大 例如： 正常情况下： 解决： 合并最后一个region和key值为无穷大的region merge_region ‘03d6ebdb5811899f32c2ad3ae9c0753b’,‘3a1ccea8df42a95bca3c5bbd6c73d5f6’,true 备注：合并完之后可以暂时解决问题

面试题 es 在数据量很大的情况下（数十亿级别）如何提高查询效率啊？ 面试官心理分析 这个问题是肯定要问的，说白了，就是看你有没有实际干过 es，因为啥？其实 es 性能并没有你想象中那么好的。很多时候数据量大了，特别是有几亿条数据的时候，可能你会懵逼的发现，跑个搜索怎么一下 5 10s，坑爹了。第一次搜索的时候，是5 10s，后面反而就快了，可能就几百毫秒。 你就很懵，每个用户第一次访问都会比较慢，比较卡么？所以你要是没玩儿过 es，或者就是自己玩玩儿 demo，被问到这个问题容易懵逼，显示出你对 es 确实玩儿的不怎么样？ 面试题剖析 说实话，es 性能优化是没有什么银弹的，啥意思呢？就是不要期待着随手调一个参数，就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数，或者调整一下语法，就可以搞定，但是绝对不是所有场景都可以这样。 性能优化的杀手锏——filesystem cache 你往 es 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。 es 的搜索引擎严重依赖于底层的 filesystem cache，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高

桔妹导读：滴滴HBase团队日前完成了0.98版本 -> 1.4.8版本滚动升级，用户无感知。新版本为我们带来了丰富的新特性，在性能、稳定性与易用性方便也均有很大提升。我们将整个升级过程中面临的挑战、进行的思考以及解决的问题总结成文，希望对大家有所帮助。 1. 背景 目前HBase服务在我司共有国内、海外共计11个集群，总吞吐超过1kw+/s，服务着地图、普惠、车服、引擎、金融等几乎全部部门与业务线。 然而有一个问题持续困扰着我们：版本较社区落后较多——HBase线上集群使用0.98版本，而社区目前最新的release版本为2.3。这为我们的工作带来了很多额外的掣肘与负担，主要包括以下几点： 新特性引入成本极高： 0.98版本可以算是HBase第一个稳定版本，但过于老旧，社区已经不再维护。想要backport新特性难度越来越大。 自研patch维护成本较高： 我们基于0.98版本有数十个大大小小的自研patch，涵盖了从label分组、ACL鉴权等大的feature到监控体系建设、审计日志优化等Improvement以及各种bug fix。这些patch或是新版本中已支持但和我们实现有差异，或是由于版本差异过大无法合入社区，而且随着时间线的拉长，这种问题只会进一步恶化。 上层组件对于HBase存在一定需求： 得益于活跃的HBase生态圈，目前我们的用户使用形态也比较丰富，OLAP

发表于 2019-07-15 | 分类于 大数据 | 0 | 本文总阅读量 165次 Flink异步IO源码简析。 使用Redisson框架封装的异步请求API。 对key进行异步累计递增计数和计算业务值并保存在Redis中。 Lua脚本和事务API。 FLINK v2-异步IO的设计与实现 Flink使用异步IO访问外部数据 AsyncRedisJob代码 AsyncFunction  AsyncFunction是一个异步算子接口，本身继承Function和Serializable。  asyncInvoke()方法会对每一个上游任务下发的流数据进行异步操作，操作完了将结果输出到ResultFuture，回调方式是把ResultFuture传入回调API，Future方式是要调用resultFuture.complete才算异步调用完成【回调和Future看外部系统客户端的封装】。  timeout()方法用来处理异步调用超时的问题，有default修饰，有默认实现，可以不做处理，但通常要做进一步处理。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 @PublicEvolving public interface AsyncFunction<IN, OUT> extends

文章目录 1 摘要 2 1 简介 3 2 ZooKeeper服务 3.1 2.1 服务概述 3.2 2.2 客户端API 3.3 2.3 ZooKeeper保证 3.4 2.4 原语的例子 4 3 ZooKeeper应用 5 4 ZooKeeper 实现 5.1 4.1 请求处理器 5.2 4.2 原子广播 5.3 4.3 副本数据库 5.4 4.4 C/S交互 6 5 测评 6.1 5.1 吞吐量 6.2 5.2 请求延迟 6.3 5.3 屏障的性能 7 6 相关工作 8 7 结论 9 致谢 10 参考文献 摘要 本文描述分布式应用的协调服务：ZooKeeper。ZooKeeper是关键基础设施的一部分，其目标是给客户端提供简洁高性能内核用于构建复杂协调原语。在一个多副本、中心化服务中，结合了消息群发、共享注册和分布式锁等内容。ZooKeeper提供的接口有共享注册无等待的特点，与事件驱动的分布式系统缓存失效类似，还提供了强大的协调服务。 ZooKeeper接口提供了高性能服务实现。除了无等待特性，还提供了对于客户端请求消息FIFO执行顺序保证，以及改变ZooKeeper状态的所有请求的线性化保证。这样的设计保证了对于本地服务的读请求，可以用高性能处理管道实现。论文中给出了目标负载，2:1到100:1的读写比例，可以处理每秒1万到10万的事务。由于其高性能

目录 AnalyticDB介绍与背景 AnalyticDB详细解析 架构设计 数据分区 读写分离和读写流程 其他特性介绍 混合（列-行）存储引擎 索引 小结 本篇主要是根据AnalyticDB的论文，来讨论AnalyticDB出现的背景，各个模块的设计，一些特性的解析。可能还会在一些点上还会穿插一些与当前业界开源实现的比对，希望能够有一个更加深入的探讨。OK，那我们开始吧。 AnalyticDB介绍与背景 要说AnalyticDB，那起码得知道它是干什么的。这里直接贴下百度百科的介绍： AnalyticDB是阿里云自主研发的一款实时分析数据库，可以毫秒级针对千亿级数据进行即时的多维分析透视。 简单地说，就是实时OLAP型数据库，它的对标产品是Apache Kylin，Apache Druid，Clickhouse这些。然后AnalyticDB的特点， 包括高并发实时摄入数据，兼容Mysql协议，无需预计算即可有的极快响应时间，多种数据源接入，大规模集群管理等 。好吧，这几个特点都很官方，不急，接下来会逐渐讨论各个点。 然后介绍下AnalyticDB的背景。 首先先说说传统的OLAP型数据仓库，以往构建OLAP型数据仓库通常都是采用离线模式， 即在晚上设置定时任务将前一天的数据同步到数据仓库中，第二天数据分析师或报表工具就可以根据数据产出分析结果 。但这样的问题是数据延迟太高了