海量数据存储方案 第1篇
一般来说，数据统一查询层，大同小异，可以总结出以下几大常见的数据查询类型：
Key-Value查询，最简单的kv查询，并发量可能很高，速度要求快。比如风控。
Key-Map查询，定向输出，比如常见的通过文章id获取文章详情数据，kv查询升级版。
MultiKey-Map批量查询，比如常见的推荐Feed流展示，Key-Map查询升级版。
C-List多维查询查询，指定多个条件进行数据过滤，条件可能很灵活，分页输出满足条件的数据。这是非常常见的，比如筛选指定标签或打分的商品进行推荐、获取指定用户过去某段时间买过的商品等等。
G-Count统计分析查询，数仓统计分析型需求。如数据分组后的数据统计。
G-Top统计排行查询，根据某些维度分组，展示排行。如数据分组后的最高Top10帖子。
海量数据存储方案 第2篇
数据统一接入服务，在springboot中，通过HBase-Client API进行了二次轻封装，支持在线RESTFUL服务接口和离线SDK包两种主要方式对外提供服务。
为了提升吞吐量，数据统一接入服务可以兼容HBase原生API和HBase BulkLoad大批量数据写入。
当然，数据统一接入服务需要做很多工作，比如
在数据统一接入服务中，为了适应不同的数据源和业务需求，主要涉及三种接入模式：
以下是对这三种模式的详细介绍：
定时拉取实现方式，大致如下：
REST实时推送的实现方式主要如下：
MQ异步推送的实现方式主要如下：
这三种接入模式各有优劣，选择合适的模式需要根据具体的业务需求和场景进行评估：
综合使用这三种模式，可以构建一个高效、灵活、可扩展的数据统一接入服务。
海量数据存储方案 第3篇
为打造更好用的存储系统，更便宜的存储系统，更可靠的存储系统，腾讯开展了一系列解决存储系统问题的思路，希望起到抛砖引玉的作用，有以下几种思路，与大家共同学习之：
1)采用单位存储容量便宜的存储介质；
2)增加有效数据的存储比例；
3)提高单位存储密度和性能，减少运营费用，
4)减少数据的存储量，例如压缩，去重等技术；
5)细化存储分层，冷热分离；
6)统一存储平台，提高存储资源利用率。
简单粗暴地采购大容量的HDD硬盘，减少单位采购成本和提高存储密度，看似简单，其实也不简单。随着HDD硬盘的容量不断的增加，但是HDD硬盘的性能却没有增加，依旧和以前小容量的硬盘一样。所以单位存储容量的性能是下降了，同时故障恢复的时间也变长了，这个就是简单粗暴的采购大容量的HDD硬盘所带来的负作用。这个时候就必须修改系统软件来规避这个负作用。使用块RAID技术，基本原理就是先把一个大的磁盘化成很多小块，这些小块与集群内的其它服务器的硬盘上的小块做备份和RAID，如下图所示：
这个时候，当业务访问数据时，可以从不同的磁盘上同时获取有效数据并组合在一起，充分发挥多磁盘的性能。同时当一个磁盘的块坏掉的时候，也不用恢复整个磁盘的数据。恢复时间大大缩短。
大家都知道GFS，一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。是以副本的方式来保证存储数据完整性的，副本由两份或者三份，导致有效数据的利用率只有或者.在一些低IPOS的存储系统，可以同通过采用类似RAID算法来提供数据完整性的保障，而不采用多副本的方式。BTFS就是这个采用类RAID算法的分布式文件系统。采用9+3的方式，9份有效数据，3份校验数据。在系统同时坏掉2台服务器的情况下也可以保证数据的完整性。整体的有效数据利用率就是9/12 = 。比2副本和3副本的系统提高50%和127%的利用率。
过去腾讯的游戏的数据库是采用应用服务器+磁盘柜来解决的，随着技术的发展，PCI-E SSD的存储设备出现，在性能方面是磁盘柜的4~6倍，且占用机柜位置少，功耗低，TCO(Total cost of ownership)急剧下降。
在IO密集型应用方面，大家知道LINUX的IO调度层效率不高，对于接SSD这样的设备，不能充分发挥其性能，通过对LINUX的IO调度层的打桩模拟测试，最高性能只有420K左右。而一个SATA接口的S3500的IO可以达到70K，6个左右的SATA SSD就超过了LINUX的理论上线。在腾讯，使用SSD的机型一般是12个SATA SSD，所以不能充分发挥SSD的性能。采用NVMe的SSD，优化了IO调度机制，从而充分的发挥了SSD的性能，利用SSD的性能，从单位性能TCO方面看，也是有效降低TCO的，腾讯计划在后续全面使用NVMe的接口SSD。
腾讯相册照片的上传数量爆发式增长，需要大量的计算资源来处理图片的压缩转码，同时需要大量的存储空间，对业务的成本压力增大。如上图所示，采用新的压缩算法，把图片从JPG格式转成WEBP格式可以减少存储空间，通过采用并行处理器来提高压缩转码效率。
有了高效的压缩转码缩放服务器，可以直接存储原图，不需要再存储套图了（为了适应各种移动终端不同分辨率的需求，需要一组尺寸大小不同的图片），当用户需要套图的时候，直接从原图通过压缩转码缩放服务器实时转换，如下图所示，把现有存储套图的方式改为只存储原图的方式，可近一步节省存储空间。
海量数据存储方案 第4篇
平台监控模块，主要包括基础平台的监控 ，应用平台监控。
基础平台的监控 包括 Hadoop集群、HBase集群的监控，外加K8S平台监控。
应用平台监控 包括数据 配置/ 数据统一接入 / 数据统一存储 /数据统一服务 的监控。
应用平台监控 主要基于Prometheus+Grafana+ Alertmananger 实现， 具体请参见尼恩的 《Prometheus 学习圣经》 pdf。
海量数据存储方案 第5篇
解决海量数据的存储，并且能够实现海量数据的秒级查询, 首先要进行海量数据存储层的技术选型.
一般来说，有两种：
Mongodb用于存储非结构化数据，尤其擅长存储json格式的数据或者是一些很难建索引的文本数据,。
Mongodb 存储的量大概在10亿级别，再往上性能就下降了，除非另外分库。
Hbase是架构在hdfs上的列式存储，擅长rowkey的快速查询，但不擅长模糊匹配查询（其实是前模糊或全模糊），
Hbase的优势是：存储的量可以达到百亿甚至以上，比mongodb的存储量大多了。
在于写入的速度上，hbase由于只维护一个主键，写入的速度要比mongodb这种要维护所有索引的数据库快多了。
在于服务器的数量上，hbase占用两台机器能完成的事情，mongodb要占用更多的机器，每台机器按一年20000的费用，几百台下来就是一笔很大的费用。
总之：
MongoDB更擅长存储需要在线访问的NOSQL文档，并且通过索引，更善于做查询，存储能力弱。
Hbase更偏向非关系型数据库，扩展储存能力强。
所以，现在很多公司都选用HBASE，而 不选用Mongodb，因为一旦数据量过大，再去改结构很复杂。
海量数据存储方案 第6篇
很多公司的业务数据规模庞大，在百亿级以上， 而且通过多年的业务积累和业务迭代，各个业务线错综复杂，接口调用杂乱无章，如同密密麻麻的蛛网，形成了难以理清的API Call蜘蛛网。
API 调用蜘蛛网 如图 所示：
这种API 调用蜘蛛网的特点是：
第一，各个业务线互相依赖。A向B要数据，B向C请求接口，C向A需求服务，循环往复，令人目不暇接。
第二，各自为政，独立发展。各业务线各有财产，各自为营，宛如诸侯割据，拥兵自重。各自一滩、烟囱化非常严重。
第三，无休止的跑腿成本、无休止的会议沟通成本，沟通和协调成本让人望而生畏。
如何降低成本，降本增效， 迫切需要进行各个业务线的资源的整合、数据的整合、形成统一的海量数据服务，这里成为为数智枢纽(Data Intelligence Hub)服务/ 或者百亿级 数据中心服务，通过 统一的 数智枢纽(Data Intelligence Hub)服务 将这错综复杂的蜘蛛网变成简明的直线班车。
数智枢纽(Data Intelligence Hub)服务 / 或者百亿级 数据中心服务 如下图 所示：
数智枢纽(Data Intelligence Hub)服务/ 或者百亿级 数据中心服务带来的几个优势：
第一，将省去不必要的接口调用。业务穿插不再混乱，减少无休止的会议沟通，解决数据难以获取、速度缓慢的问题。
第二，统一数据中心将大大节省产品和开发人员的时间，提升整体工作效率。各个业务线在新的系统下将协同作战，资源高效利用，真正实现事半功倍。
第三，进行统一的高可用优化、高并发优化，确保：稳如泰山，快如闪电。
总而言之，数智枢纽(Data Intelligence Hub)服务 的出现，将从根本上改变我们的统一数据存储和数据访问的工作方式，实现资源整合和效率提升。最终实现了： 稳如泰山，快如闪电，大气磅礴，节约成本，清晰明了。
海量数据存储方案 第7篇
Hbase是典型的nosql，是一种构建在HDFS之上的分布式、面向列的存储系统，在需要的时候可以进行实时的大规模数据集的读写操作；
前面讲到，Hbase是架构在hdfs上的列式存储，擅长rowkey的快速查询，但不擅长模糊匹配查询（其实是前模糊或全模糊），
注意：Hbase 不擅长模糊匹配查询。
如何实现 数据统一查询层？
这个时候，我们就是用elasticsearch架构在hbase之上；
数据统一查询层的架构，是elasticsearch + hbase结合：
最终，通过elasticsearch+hbase就可以做到海量数据的复杂查询；
尼恩提示： 以上内容比较复杂， 如果需要深入了解， 请参见尼恩后续的《百亿级海量数据存储架构和实操》配套视频。
很简单，将Elasticsearch的DOC ID和Hbase的rowkey相关联。
在数据接入的时候，通过构建统一的、全局唯一 ID， 既当做Elasticsearch的DOC ID， 也当做Hbase的rowkey。
在统一数据服务，构建ID，然后先写入 hbase，再发送kafka 消息， 异步写入ES。
将源数据根据业务特点划分为索引数据和原始数据：
索引数据：指需要被检索的字段，存储在Elasticsearch集群中；
原始数据：指不需要被ES检索的字段，包括某些超长的文本数据等，存储在Hbase集群中。
当然，在操作之前，我们还要考虑：
这个就需要根据元数据进行有效的控制。
实际查询的过程是：
将HBase的rowkey设定为ES的文档ID，搜索时根据业务条件先从ES里面全文检索出相对应的文档，从而获取出文档ID，即拿到了rowkey，再从HBase里面抽取数据。
好像ES天生跟HBase是一家人，HBase支持动态列，ES也支持动态列，这使得两者结合在一起很融洽。
而ES强大的索引功能正好是HBase所不具备的，如果只是将业务索引字段存入ES中，体量其实并不大；
甚至很多情况下，业务索引字段60%以上都是Term类型，根本不需要分词。
总之， ES天生 就是hbase 的外置索引：
尼恩提示： 以上内容比较复杂， 如果需要深入了解， 请参见尼恩后续的《百亿级海量数据存储架构和实操》配套视频。
1、两个组件之间存在时效不一致的问题
相对而言，Elasticsearch的入库速度肯定是要快于Hbase的，这是需要业务容忍一定的时效性，对业务的要求会比较高。
2、同时管理两个组件增加了管理成本
显而易见，同时维护两套组件的成本肯定是更大的。 当然，既然是百亿级数据，这点维护人员还是要有的。
海量数据存储方案 第8篇
先看一下整体架构图，咱们有两个hbase集群， 如下图：
一个是 在线计算，一个负责离线计算，两个集群之间，需要数据复制。
HBase 提供了内置的复制机制，可以在不同的 HBase 集群之间同步数据。这种机制称为 HBase Replication，它允许将数据从一个 HBase 集群复制到另一个 HBase 集群，通常用于数据备份、灾难恢复、多数据中心部署等场景。
Replication： 复制，指的是持续的将同一份数据拷贝到多个地方进行存储，是各种存储系统中常见而又重要的一个概念，
可以指数据库中主库和从库的复制，也可以指分布式集群中多个集群之间的复制，还可以指分布式系统中多个副本之间的复制。
它的难点在于数据通常是不断变化的，需要持续的将变化也反映到多个数据拷贝上，并保证这些拷贝是完全一致的。
HBase 的复制机制基于 WAL（Write-Ahead Log）。当数据写入到主集群（Master Cluster）时，写操作首先被记录到 WAL 中，然后这些 WAL 日志被传输到从集群（Slave Cluster），从集群再根据这些日志进行数据重放，从而实现数据同步。
通常来说，数据复制到多个拷贝上有如下好处：
HBase中的Replication指的是主备集群间的复制，用于将主集群的写入记录复制到备集群。HBase目前共支持3种Replication：
此篇文章介绍的是：第一种，异步Replication。
首先看下官方的一张图：
需要声明的是，HBase的replication是以Column Family为单位的，每个Column Family都可以设置是否进行replication。
上图中，一个Master对应了3个Slave，Master上每个RegionServer都有一份HLog，在开启Replication的情况下，
每个RegionServer都会开启一个线程用于读取该RegionServer上的HLog，并且发送到各个Slave，Zookeeper用于保存当前已经发送的HLog的位置。
Master与Slave之间采用异步通信的方式，保障Master上的性能不会受到Slave的影响。
用Zookeeper保存已经发送HLog的位置，主要考虑在Slave复制过程中如果出现问题后重新建立复制，可以找到上次复制的位置。
HBase Replication步骤：
注： 在进行replication时，Master与Slave的配置并不一定相同，比如Master上可以有3台RegionServer，Slave上并不一定是3台，Slave上的RegionServer数量可以不一样，数据如何分布这个HBase内部会处理。