计算任务的结果不仅仅依赖于输入，还依赖于它的当前状态，其实大多数的计算都是有状态的计算。比如wordcount,给一些word,其计算它的count,这是一个很常见的业务场景。count做为输出，在计算的过程中要不断的把输入累加到count上去，那么count就是一个state。
Cassandra HBase 一致性 Quorum NRW策略 通过Gossip协议同步Merkle Tree，维护集群节点间的数据一致性 单节点，无复制，强一致性 可用性 1，基于Consistent Hash相邻节点复制数据，数据存在于多个节点，无单点故障。 2，某节点宕机，hash到该节点的新数据自动路由到下一节点做 h
最近有用到Hbase，整理了下Hbase的架构，整体思路可以看之前的NoSQL概述NoSQL概述-从Mongo和Cassandra谈谈NoSQL。
Hadoop 目前是数据处理的标准工具，其核心组件包含了HDFS（分布式文件系统）、YARN(资源调度平台)、
有赞是提供商家 SAAS 服务，随着越来越多的商家使用有赞，搜索或详情的需求也日益增长，针对需求及场景，之前提到过的订单管理架构演变及 AKF 架构等在这两篇文章里已经有所体现，而这些数据的查询来自于不同的 NoSQL，怎么同步这些非实时存储系统将是一个很有趣的事情。
内容来源：2018 年 09 月 15 日，平安科技数据平台部大数据高级工程师邓杰在“中国HBase技术社区第五届MeetUp ——HBase应用与发展”进行《HBase应用与实践》的演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
http://qing.blog.sina.com.cn/1765738567/693f0847330008ii.html
出现这种异常，基本可以确定是HDFS不可读写了，一般情况下是IO被打满，或者HDFS存储被打满。
大多数互联网应用场景都是读多写少，业务逻辑更多分布在写上。对读的要求大概就是要快。那么都有什么原因会导致我们完成一次出色的慢查询呢？
运营商关注光网的发展与客户的使用体验，客户的互联网使用体验提质一般采用两种方式进行处理。一是观注在OLT上每个用户的光衰进行主动处理，二是通过客服热线或用户测试网站进行被动处理。但这种方式仍存在问题，通过OLT主动查看用户的光衰只关注了最后一公里，而客户是观注端到端的使用体验，该方式仍存在弊端。今天我们来探讨，有什么办法可以做到端到端的互联网业务主动改善？
“大数据” 三个字其实是个marketing语言，从技术角度看，包含范围很广，计算、存储、网络都涉及，知识点广、学习难度高。
HBase的原型是Google的BigTable论文，受到了该论文思想的启发，目前作为Hadoop的子项目来开发维护，用于支持结构化的数据存储。 官方网站：http://hbase.apache.org – 2006年Google发表BigTable白皮书 – 2006年开始开发HBase – 2008年北京成功开奥运会，程序员默默地将HBase弄成了Hadoop的子项目 – 2010年HBase成为Apache顶级项目 – 现在很多公司二次开发出了很多发行版本，你也开始使用了。 HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBASE技术可在廉价PC Server上搭建起大规模结构化存储集群。 HBase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。 HBase是Google Bigtable的开源实现，但是也有很多不同之处。比如：Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MAPREDUCE来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。
最近公司一个系统发生线上故障，系统架构为C/S的，客户端是APP；系统的功能有：联系人、短信、通话记录等，每个业务都有备份、恢复的功能，即用户可以在APP内备份自己的联系人、短信、通话记录至服务端，然后可以后续某个时间段恢复数据。
HDFS是一种开源的分布式文件系统，基于常见商用硬件构建海量大规模存储集群，提供极低的存储成本，极大的存储容量支持。 HDFS提供高可靠性的数据保障，通常采用三副本冗余存储数据到不同的机器来实现容灾备份能力。 HBase基于HDFS实现存储计算分离架构的分布式表格存储服务
最近朋友公司在做一些数据的迁移，主要是将一些Hive处理之后的热数据导入到HBase中，但是遇到了一个很奇怪的问题：同样的数据到了HBase中，所占空间竟增长了好几倍！详谈中，笔者建议朋友至少从几点原因入手分析：
接着上一篇介绍协处理器的文章http://qindongliang.iteye.com/blog/2277145，本篇我们来实战一个例子，看下如何使用协处理来给Hbase建立二级索引。 github地址：https://github.com/qindongliang/hbase-increment-index 业务需求： 现有一张Hbase的表，数据量千万级+，而且不断有新的数据插入，或者无效数据删除，每日新增大概几百万数据，现在已经有离线的hive映射hbase 提供离线查询，但是由于性能
HBase是一个很流行kv数据库，特点是集群化，可水平扩容，基于lsm tree，写入非常快，集群化之后查询性能也不错，成本低，非常适合QPS要求不是特别高，但写入量很大的场景。
今年有个现象，实时数仓建设突然就被大家所关注。我个人在公众号也写过和转载过几篇关于实时数据仓库的文章和方案。
HBase的原型是Google的BigTable论文，受到了该论文思想的启发，目前作为Hadoop的顶级项目来开发维护，用于支持结构化的数据存储。
机票业务看起来简单，实际上整个流程的处理链条很长，调用关系也非常复杂，上下游涉及的各类日志种类约60个，每种日志都有独立格式和请求/响应报文，日生产的日志数据量约50-100亿，如果时间范围再扩大到15天，数据量轻松的达到千亿级以上。
在regionserver日志搜索关键字 "TooLarge",若存在则需要业务侧优化表结构，优化大KV
场景描述：今年有个现象，实时数仓的建设突然就被大家所关注。我个人在公众号也写过和转载过几篇关于实时数据仓库建设的文章和方案。
HBase： NoSQL数据库，基于HDFS的分布式数据库，理论上支持无限横向扩展， HBase由HMaster与RegionServer组成，HMaster负责协调调度RegionServer进行数据处理，RegionServer负责数据的增删改查操作，RegionServer由多台分布在DataNode的组成，可以有多个。由HMaster负责RegionServer的调度情况，当RegionServer出现异常情况，HMaster进行对MetaRegionServer中的元数据进行更新管理。 当HBase中表的数据不断变大时，表中数据会进行Region分区，分为Region1，Region2...等,RegionServer1负责Region1,RegionServer2负责Region2等；每个RegionServer负责哪个Region的数据区由MetaRegionServer管理，MetaRegionServer运行在多个RegionServer中的任意一个。 HBase数据存储在HDFS上的存储也是按照层级来管理的，不同的库对应不同的目录，库下不同的表亦对应不同的目录，表下不同的Region对应不同的目录，Region下存放这HBase上的数据，HBase的数据是经过特殊处理的，所以直接看不到数据内容 HMaster支持HA高可用，所以在HBase集群对应的HMaster和RegionServer都启动后，在其他的RegonServer上启动HMaster，则该HMaster为StandBy，第一次启动的为Active。 HBase底层接口处理起来会比较吃力，一般处理方式是应用其他工具进行处理，如Flume,Sqoop MySQL与Hive的区别 MySQL：数据存储会受到限制，可以增删改查数据 Hive：1. 只能进行查询数据，不能进行该数据，可以根据查询结果进行建表存储数据 2. 基于HDFS，支持分布式存储，可以无限扩容 3. 基于MapReduce，支持大数据运算 HBase与MySQL的区别 MySQL：行式存储，适合处理联机事务 HBase：列式存储，适合处理对单列数据(列族归类的数据)进行快缩索引查询 HBase与Hive的区别 HBase：数据库，数据分布式存储在HDFS上的DataNode节点上，根据对数据进行增删改查等。 Hive:数据仓库，数据存储在HDFS上，与DataNodata 关系不大，管理历史数据，数据量会非常庞大，每天都会进来大量数据，不能进行更新删除操作， HBase概念 HMaster: 协调管理RegionServer服务状态及元数据管理 RegionServer: 负责对数据表的增删改差操作，主要负责单个Region的数据管理 RegionData:数据块 MetaRegionServer: 对RegionSever上对应的Region数据块进行索引管理 database 数据库 table: 数据表,定义表时需要指定列族，也可以再表建立后进行列族的管理 RowKey：行键,表示一行数据，一行数据中包含列族定义的东西， ColumnFamily: 列族，对业务进行分类后，可以根据业务对数据进行分类，把业务类似的一类数据分为一个列族，不同的业务可以分为不同的列族。分列族的主要目的是方便后期对数据的高速索引. CELL: 数据单元,保存单个KV字段. 运行逻辑： HMaster协调管理RegionServe，RegionServer主要负责处理Region数据块的处理，MetaRegionServer管理RegionServer对应Region数据的元数据信息。RegionServer服务异常时，HMaster进行元数据迁移，保证对Region数据的管理由对应的RegionServer来管理。 MetaRegionServer管理的元数据信息保存在HDFS上。 Client进行数据处
目前业务在使用Kylin的时候反馈查询很慢，直接超时了（超时时间设置的为5min），在日志中获取了相应的SQL以及Cube之后发现：
Hadoop是Apache Lucene创始人 Doug Cutting 创建的。最早起源于Nutch，它是Lucene的子项目。Nutch的设计目标是构建一个大型的全网搜索引擎，包括网页抓取、索引、查询等功能，但随着抓取网页数量的增加，遇到了严重的可扩展性问题：如何解决数十亿网页的存储和索引问题。
作者 | 王小波 编辑 | 李忠良 降本增效一直是研发团队追求的目标之一，面对不断上涨的数据量，研发侧开始思考如何在不降低用户体验的情况下进行成本压减，冷热数据分离的架构思想引起了我们的注意。 背 景 定制家具业务是酷家乐最早的业务之一，定制家具的方案数据也同样沉淀了多年的数据；数据库从早期的 MongoDB 到切换到现在的 HBase；存储逻辑也从原来的全量保存演进到现在的分片增量保存。 随着数据量不断增大，带来的是巨大的成本压力与运维难度，目前定制 HBase 集群仅单副本数据量接近 15
Elastic MapReduce（EMR）是腾讯云提供的云上 Hadoop 托管服务，提供了便捷的 Hadoop 集群部署、软件安装、配置修改、监控告警、弹性伸缩等功能，EMR部署在腾讯云平台（CVM）上，配合消息中间件、CDB等产品为企业提供了一套较为完善的大数据处理方案。如下图所示为EMR系统架构图：
Hadoop 是一个提供分布式存储和计算的开源软件框架，它具有无共享、高可用（HA）、弹性可扩展的特点，非常适合处理海量数量。
作者 | ShardingSphere官微 来源 | https://mp.weixin.qq.com/s/Rzr-aKFwmm71QNUs68WQNA 京东白条使用 Apache ShardingSphere 解决了千亿数据存储和扩容的问题，为大促活动奠定了基础。 2014 年初，“京东白条”作为业内互联网信用支付产品，数据量爆发式的增长，每一次大促备战都是对技术人员的考验，每一次的战略转型驱动着数据架构的成长。 --张栋芳，京东白条研发负责人 京东白条数据架构演进史 自 2014 年 2 月京东白条业务
本人3年开发经验、18年年底开始跑路找工作，在互联网寒冬下成功拿到阿里巴巴、今日头条、滴滴等公司offer，岗位是Java后端开发，最终选择去了阿里巴巴。
与Phoenix带来的SQL on HBase易用性相比，它带来的负面影响也是巨大的， 大表Join大表，或者全表OrderBy等消耗的资源随数据量呈至少线性增长， 并发直线下降，甚至低到只有百级别，扩容带来的收益下降很快。 另外，Phoenix表查询通过多个独立协调器（Query Server），互相不管对方， 玩命占用HBase资源，在高并发的大查询下就会容易造成HBase整个集群过载。 而像Presto系统所有的请求都是走同一个协调器，可以总控资源使用，优雅的处理过载。 让现有HBase集群聚焦在线KV Store，聚焦作为在线业务的温存储层。
Fluid是CNCF基金会旗下云原生环境中数据密集型应用的高效支撑平台，项目自开源发布以来吸引了众多相关方向领域专家和工程师的关注，在大家的积极反馈下社区不断演进。近期 Fluid 0.6 版本正式发布，在该版本中，Fluid 主要新增改善以下三个方面内容：
通过前面几天的学习，我们在面对高并发流量时，为了应对大量读写请求，特此将我们的普通存储系统开发成了一套分布式存储系统。主要基于读写分离主从复制以及数据分库分表实现的。不清楚的可以再回去看看啊数据库读写分离方案，实现高性能数据库集群，数据库分库分表后，我们生产环境怎么实现不停机数据迁移
CPU 缓存、浏览器缓存、CDN 缓存、DNS 缓存、内存缓存、 Redis 缓存等，它们都是将数据缓存在离使用者更近的地方，或者读取速度更快的存储介质中，通过空间换时间的方式实现性能优化的。
作者颜卫，腾讯高级后台开发工程师，专注于Kubernetes大规模集群管理和资源调度，有过万级集群的管理运维经验。目前负责腾讯云TKE大规模Kubernetes集群的大数据应用托管服务。
hbase是bigtable的开源java版本。是建立在hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写nosql的数据库系统。
作者颜卫，腾讯高级后台开发工程师，专注于Kubernetes大规模集群管理和资源调度，有过万级集群的管理运维经验。目前负责腾讯云TKE大规模Kubernetes集群的大数据应用托管服务。 大数据的发展历史 大数据技术起源于Google在2004年前后发表的三篇论文，分布式文件系统GFS、分布式计算框架MapReduce和NoSQL数据库系统BigTable，俗称"三驾马车"。在论文发表后，Lucene开源项目的创始人Doug Cutting根据论文原理初步实现了类似GFS和MapReduce的功能。并在20
目前，对于互联网海量数据的存储以及处理，按使用场景，分为OLTP（联机事务处理，比如即时交易，强调快速响应与处理）与OLAP（联机分析处理，比如BI，强调多维数据分析）。对于这些数据的存储，主要有两种解决方案，即基于SQL的关系型数据库，和NoSQL的非关系型数据库。 非关系型数据库在某些特定场景下有奇效，比如键值存储（redis,ROMA,Memcached）数据库应用在排行更新，会话保存，面向文档的数据库（mongoDB、couchDB）应用在日志记录，面向列的数据库（Cassandra、HBase）在博客中的应用。关系型数据库最大的问题在于速度与可扩展性上，而这些NoSQL数据库一般部署简单，支持扩展，而且速度极高。 但是，NoSQL目前还是只能做为关系型数据库在某些特定应用场景的补充，不能完全替代严谨规范的关系型数据库。
提起分布式，不少人能很清晰的阐述paxos、CAP等理论，但我们在遇到一个具体的分布式问题时，很少有人能知道如何做出一个“好”的设计。对于当前的很多分布式数据系统，包括开源的HBase、ElasticSearch等，我们一般只知其然，很少能够知其所以然。因为几乎所有的分布式数据系统，都会根据自身情况，对实际场景做一些假设，有所舍取，这种多样性也增加了我们的理解难度。
点赞之后，上一篇传送门： https://blog.csdn.net/weixin_39032019/article/details/89340739
提起大数据，不得不提由IBM提出的关于大数据的5V特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性），而对于大数据领域的从业人员的日常工作也与这5V密切相关。大数据技术在过去的几十年中取得非常迅速的发展，尤以Hadoop和Spark最为突出，已构建起庞大的技术生态体系圈。 首先通过一张图来了解一下目前大数据领域常用的一些技术，当然大数据发展至今所涉及技术远不止这些。
据报告显示到2025年，全球将产生180ZB的数据。这些海量的数据正是企业进行数字化转型的核心生产因素，然而真正被有效存储、使用和分析的数据不到百分之十。如何从ZB级的数据中寻找分析有价值的信息并回馈到业务发展才是关键。11月30日UCan技术沙龙大数据专场（北京站）邀请了5位资深大数据技术专家分享他们对大数据的探索和应用实践。
大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。
随着大数据时代的发展，诞生了一大批大数据时代下的新数据库产品，如今MongoDB、Redis、HBase这些NoSQL数据库已经成为了互联网开发的新标配，SQL一统江湖的时代不复存在了。
在使用 HBase 时，如果你的数据量达到了数十亿行或数百万列，此时能否在查询中返回大量数据将受制于网络的带宽，即便网络状况允许，但是客户端的计算处理也未必能够满足要求。在这种情况下，协处理器（Coprocessors）应运而生。它允许你将业务计算代码放入在 RegionServer 的协处理器中，将处理好的数据再返回给客户端，这可以极大地降低需要传输的数据量，从而获得性能上的提升。同时协处理器也允许用户扩展实现 HBase 目前所不具备的功能，如权限校验、二级索引、完整性约束等。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
