weixin_47158466的博客

据公开资料显示，Apache Doris在美团、小米、京东、百度、网易、字节跳动、快手、腾讯、华为、新浪、知乎、360等大型互联网企业有深入的应用和稳定的生产运行，全球范围内的企业用户规模已超过1000家。这是一本从基本操作、架构设计、进阶使用、运维管理、拓展应用、项目实战等多个维度全面讲解Doris的著作，得到了Apache Doris PMC主席、Select DB创始人兼CEO以及多位Apache Doris PMC的强烈推荐。Doris依赖FE节点管理元数据，可用性高，不依赖外部组件；

小米大数据运维管理体的建设与实践

分享给还在因为生活、职场迷茫焦虑的你，一个人能走多远，取决于与谁同行

​各位，今年 ClickHouse 最王炸的功能来啦，没错，就是期待已久的 Projection (投影)功能。ClickHouse 现在的功能已经非常丰富强大了，但是社区用现实告诉我们，还可以进一步做的更好：）不知道你有没有碰到过这些情况: MergeTree 只支持一种排序规则 建表的时候，Order By 同时决定了主键稀疏索引和数据的排序，假设 :Order BY A,B,C那么通常过滤查询 Where A 会很快，但是 Where C 会慢一些。 物化视.

本文从全局出发，详细讲解了HBase的Replication和Replication Endpoint的用法及实践。Replication：复制，指的是持续的将同一份数据拷贝到多个地方进行存储，是各种存储系统中常见而又重要的一个概念，可以指数据库中主库和从库的复制，也可以指分布式集群中多个集群之间的复制，还可以指分布式系统中多个副本之间的复制。它的难点在于数据通常是不断变化的，需要持续的将变化也反映到多个数据拷贝上，并保证这些拷贝是完全一致的。通常来说，数据复制到多个拷贝上有如下好处：..

意外发现前两天打算迁移一份数据，自然而想到了Apache Sqoop，遂打开Apache官网寻找下载链接，但是竟然没有找到他的踪影。这不科学啊，前几个月还看到过来着，有点不死心，直接尝试登陆直接https://sqoop.apache.org/Aapche Sqoop官网Project Sqoop has retired. For details please refer to its Attic page.Apache基金会里竟然还有项目退役一说，仔细看了下，原来Apach

前言不知不觉距离上一篇的更新已经有几个月了，后台也有很多小伙伴催更，奈何事情比较多，期望我能坚持下去～书接上话，前两篇我们聊了CAP的最佳打开方式，也讲透了分布式系统一致性的问题。最近几篇我们聊一聊分布式事务。文章结尾附小米大数据平台运维工程师JD，有意者请与我联系～二将军问题我们先来看个故事，相信会有助于你对分布式事务的理解。二将军问题是一个计算机领域一个经典的问题。「故事背景」黑白两军交战之际，两股白军将黑军被围困在山谷之中；山谷两侧任意一股白军都比山谷中的黑军人数少，因此单独一

之前一直拖更了好久，也有好多小伙伴催更。想不到续更的第一篇不是技术文，竟然是个人复盘(小道消息21年会文章正式续更)。前言 我先说说我为什么选择今年写复盘吧！首先还是想留下一些记录，希望...

​一、前言纠结了很久要不要写这一篇，作为分布式系统的核心理论简单说说容易，聊透却很难，转念一想，如果不写这篇，算什么想通透大数据呢！并且这本身就违背了我写作的初衷；加之正好前几天和同事以ZooKeeper的用户行为反推了CAP理论，回过头来细琢磨了下，还蛮有意思的！闲话少絮，我们进入正题！本文宗旨：深入浅出！聊透！二、“纸面”上的CAP相信很多同学都听过CAP这个理论，为了避免我们认知不同，我们先来统一下知识起点。 CAP理论在1999年一经提出就成为了分布式系统领域的顶级教义。并表明

一、前言纠结了很久要不要写这一篇，作为分布式系统的核心理论简单说说容易，聊透却很难，转念一想，如果不写这篇，算什么想通透大数据呢！并且这本身就违背了我写作的初衷；加之正好前几天和同事以Z...

​一、前言上周和朋友聊天感觉之前的文章起的题目太中二了，虽然目标是不做标题党，但本次决定使用“震惊体”！！试试效果～～前几篇文章中,我们讲述了哈希分片的路由分片方式模型, 通过对基础(加权)轮询、虚拟桶、一致性hash模型进行分析后，不难发现哈希分片的路由分片模型，将客户端的读写请求尽可能均匀的分散到不同的后端节点中，并且使用不同的方法缓解节点上线和下线过程中分片迁移的问题(主要指后两种方案)。那么是否意味着hash分片并没有缺点呢？除了hash分片还有没有其他分片方式呢？我们带着这些问题，来开始本

从实践中检验“真理”​通过上一篇《大数据基础-求锤得锤，你要的一致性hash来了(上）[附代码]》的讲解，我们已经掌握了一致性hash的基本原理，其路由分片策略在类p2p模型架构中是非常典型的(之前提到的redis cluster也是p2p协议的一种实现)，在节点宕机时的影响很小，只影响到一个分片。只看原理的话确实也就这么多了，那么其实际效果究竟是否和原理中完全一致？是否还存在一些问题呢？我们来逐一验证下。写这个系列文章以后，从后台看到收藏次数很多，我本身也是很开心，说明很多小伙伴还是有所收获的，.

​前言最近总有人问我一致性hash的事情，求锤得锤，我们今天就来聊聊看。前两篇我们分别介绍了两类哈希分片的方法:《基础轮询》和《虚拟桶》。 基础轮询法导致架构缺乏灵活性，需要扩、缩容一倍的节点才能保证50%的映射关系不变，否则查询命中率会更低，当有一台节点异常时，简直是灾难。 虚拟桶的分片方法在hash取模的基础上做了优化，符合通用的3层路由分片模型，此外将分片数量固定，避免了取模敏感度高的问题，节点变动后每台老节点会有部分分片迁移到新节点上。 虽然虚拟桶比hash取模好上很多，但总

前言最近总有人问我一致性hash的事情，求锤得锤，我们今天就来聊聊看。前两篇我们分别介绍了两类哈希分片的方法:hash取模和虚拟桶。hash取模法导致架构缺乏灵活性，需要扩、缩容一倍的节...

01 前言我们先回忆在上文《大数据基础-3行代码实现最基本的路由分片(附代码)》的主要内容，我们介绍了哈希分片的第一类常见套路，hash取模法（即基础轮询），并在一定程度上进行延伸，引出加权轮询的概念。最后我们对基础轮训和加权轮询的优缺点进行考量，其虽然逻辑清晰、复杂度低，但是灵活性较差。当节点发生变化时，会导致映射关系全部打乱，已经分配的数据也需要根据新的映射关系重新分配。那怎么样能改进基础轮询的痛点问题呢？本篇我们就带着这个问题一步一步来深入到本篇的主题，哈希分片的第二类方法：虚拟桶。.

01 前言在上文《大数据基础-原来这就是路由分片》中，我们简单介绍了什么是路由和分片、讲述了通用的路由分片模型，并介绍了路由分片的常用方法，包括哈希分片和范围分片。在哈希分片这类路由分片的解决方案中，有几种被广泛熟知和应用的实现方式： hash 取模法 虚拟桶 一致性hash 从本篇开始我们就详细的原理和实现方法来一一讲述。02 哈希取模大法—真香！我们首先详细说下第一种最为常见的方法hash取模法，这个名字可能有些同学比较陌生，我相信轮询（...