百亿级存储架构： ElasticSearch+HBase 海量存储架构与实现

原创 已于 2024-10-22 08:59:43 修改 · 4.8k 阅读 · 25 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#架构 #elasticsearch #hbase

于 2024-06-30 21:03:25 首次发布

百亿级存储架构： ElasticSearch+HBase 海量存储架构与实现

尼恩：百亿级数据存储架构起源

在40岁老架构师 尼恩的读者交流群(50+)中，经常性的指导小伙伴们改造简历。

经过尼恩的改造之后，很多小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试机会，拿到了大厂机会。

这些机会的来源，主要是尼恩给小伙伴 改造了简历，植入了亮点项目、黄金项目。

尼恩的 亮点项目、黄金项目 需要持续迭代。下一个亮点项目、黄金项目是：百亿级数据存储架构。

同时，小伙伴在面试时，经常遇到这个面试难题。比如，前几天一个小伙伴面试字节，就遇到了这道题

阿里面试：百亿级数据存储，怎么设计？

字节面试：百亿级数据存储，只是分库分表吗？

于是，尼恩组织小伙伴开始研究和 设计 《百亿级数据存储架构》，帮助大家打造一个新的黄金项目，实现大厂的梦想。

已经发布的文章包括：

字节面试：百亿级存储，怎么设计？只是分库分表？

100亿级任务调度篇：从0到1, 从入门到 XXLJOB 工业级使用

高并发搜索ES圣经：从0到1, 从入门到 ElasticSearch 工业级使用

超级底层：10WQPS/PB级海量存储HBase/RocksDB，底层LSM结构是什么？

一：百亿级 海量存储数据服务的业务背景

很多公司的业务数据规模庞大，在百亿级以上， 而且通过多年的业务积累和业务迭代，各个业务线错综复杂，接口调用杂乱无章，如同密密麻麻的蛛网，形成了难以理清的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)服务 的出现，将从根本上改变我们的统一数据存储和数据访问的工作方式，实现资源整合和效率提升。最终实现了： 稳如泰山，快如闪电，大气磅礴，节约成本，清晰明了。

二：架构设计与模块介绍

先看一下整体架构，整个数智枢纽(Data Intelligence Hub)服务 核心主要分为：

  • 数据统一接入层

  • 数据统一查询层

  • 元数据管理

  • 索引建立

  • 平台监控

  • 在线与离线数据存储层

先看一下整体架构图，如下图：
在这里插入图片描述

下面将分别对其进行介绍。

尼恩提示： 以上内容比较复杂， 如果需要深入了解， 请参见尼恩后续的《百亿级海量数据存储架构和实操》配套视频。

三：数据统一查询层的业务梳理

一般来说，数据统一查询层，大同小异，可以总结出以下几大常见的数据查询类型：

  • Key-Value查询，最简单的kv查询，并发量可能很高，速度要求快。比如风控。

  • Key-Map查询，定向输出，比如常见的通过文章id获取文章详情数据，kv查询升级版。

  • MultiKey-Map批量查询，比如常见的推荐Feed流展示，Key-Map查询升级版。

  • C-List多维查询查询，指定多个条件进行数据过滤，条件可能很灵活，分页输出满足条件的数据。这是非常常见的，比如筛选指定标签或打分的商品进行推荐、获取指定用户过去某段时间买过的商品等等。

  • G-Count统计分析查询，数仓统计分析型需求。如数据分组后的数据统计。

  • G-Top统计排行查询，根据某些维度分组，展示排行。如数据分组后的最高Top10帖子。

最低0.47元/天 解锁文章
ES+HBase【案例】仿百度搜索02：项目架构设计
weixin_40612128的博客
03-17 1802
一、项目概览 二、项目整体架构流程 1：项目的数据来源可以是通过爬虫到互联网上采集的数据，也可以是企业数据库中的内部数据 2：根据数据的来源不同，使用不同的程序将数据入库到HBase，实现海量数据存储 3：针对HBase中的数据在ES中建立索引。 注意：并不是把HBase中数据的完整内容全部在ES中建立索引，只需要将检索用到的那些字段在ES中建立索引即可。例如：HBase存储的原始数据有20个字段，在ES可能只需要存储5个字段即可，具体的存储细节在后面会详细分析。 4：在数据展现模块中提供仿百度搜索功能
ES+HBase【案例】仿百度搜索01：企业中快速复杂查询痛点分析
weixin_40612128的博客
03-17 1070
ES+HBase【案例】仿百度搜索01：企业中快速复杂查询痛点分析
Elasticsearch+Hbase实现海量数据秒回查询
yshir
11-22 760
一、ElasticSearch和Hbase ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。Elasticsearch的性能是solr的50倍。 HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩.
【Elasticsearch】优秀实践-ES+Hbase的实现
热门推荐
wudingmei1023
01-09 1万+
前言 因为之前在项目上，需要用到ES+Hbase方案，最后经过各种测试和验证，最终项目完成上线。因为在实际的过程遇到不少的问题，和理论还是有一定的差距。 纸上得来终觉浅，绝知此事要躬行。----古人诚不欺我 基本原理 很简单，将Elasticsearch的DOC ID和Hbase的rowkey相关联： 将源数据根据业务特点划分为索引数据和原始数据： 索引数据：指需要被检索的字段，存储在El...
快速入门elasticsearch
2401_84526799的博客
10-26 1249
分词器的作用是什么？创建倒排索引时，对文档分词用户搜索时，对输入的内容分词IK分词器有几种模式？ik_smart：智能切分，粗粒度：最细切分，细粒度IK分词器如何拓展词条？如何停用词条？利用config目录的文件添加拓展词典和停用词典在词典中添加拓展词条或者停用词条索引库操作有哪些？创建索引库：PUT /索引库名查询索引库：GET /索引库名删除索引库：DELETE /索引库名修改索引库，添加字段：PUT /索引库名/_mapping。
海量数据存储
weixin_34308389的博客
06-17 260
怎样处理海量数据 在实际的工作环境下，很多人会遇到海量数据这个复杂而艰巨的问题，它的主要难点有下面几个方面： 一、数据量过大，数据中什么情况都可能存在。 假设说有10条数据，那么大不了每条去逐一检查，人为处理，假设有上百条数据，也能够考虑，假设数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可...
基于Nutch+Hadoop+Hbase+ElasticSearch的网络爬虫及搜索引擎
weixin_33967071的博客
08-30 489
2019独角兽企业重金招聘Python工程师标准>>> ...
ElasticSearch + HBase 海量存储架构与实现
安静的软件工程师
08-17 1228
ElasticSearch + HBase 海量存储架构与实现
大数据领域HBase与Elasticsearch的集成应用
Golang编程笔记的博客
09-05 721
随着企业数据量呈指数级增长，传统数据库难以满足高吞吐量存储和复杂查询分析的双重需求。HBase作为列式分布式数据库，擅长处理亿级以上结构化数据的随机读写，但在全文检索、聚合分析等场景存在性能瓶颈；Elasticsearch作为分布式搜索引擎，支持实时搜索、动态聚合和复杂查询，但存储成本较高且不适合海量明细数据长期存储。本文旨在通过深度技术解析，阐述如何通过HBase与Elasticsearch的集成，构建**“存储层+检索层”的异构数据处理架构**，实现数据的高效存储与灵活查询。
基于Spark的实时日志分析及异常检测系统 Flume + Kafka + Hbase + Spark-Streaming
03-14
总结来说，这个系统构建了一个完整的数据流处理链路，从数据采集（Flume）、中间缓存（Kafka）、实时处理（Spark-Streaming）到数据存储（HBase），实现了高效、实时的日志分析和异常检测。这样的架构在现代大数据...
Mysql海量数据存储和解决方案之一—分布式DB方案
summer85的博客
07-30 862
1)  分布式DB水平切分中用到的主要关键技术：分库，分表，M-S,集群，负载均衡   2) 需求分析：一个大型互联网应用每天几十亿的PV对DB造成了相当高的负载，对系统的稳定性的扩展性带来极大挑战。 3) 现有解决方式：通过数据切分提高网站性能，横向扩展数据层       水平切分DB，有效降低了单台机器的负载，也减小了宕机的可能性。       集群方案：解决DB宕机带来的...
Elasticsearch结合hbase的应用
10-16
Elasticsearch结合hbase的应用 是一个分布式nosql的非关系数据库. 基于HDFS适合海量数据存储 根据RowKey查询数据,效率高 模糊查询效率非常差 随意组合的多条件查询非常差
hbase to elasticsearch
01-19
Hbase本身只有一级索引rowkey，现在通过Hbase coprocessor协处理器把Hbase的数据索引存储到Elasticsearch，从而建立二级索引；ppt中讲述了一些注意事项，挺有用的，希望能有所帮忙！
基于Elasticsearch与Hbase组合框架的大数据搜索引擎
zhaicheng55的博客
06-16 2852
本项目为学校大数据工程实训项目，共开发4周，答辩成绩不错。代码仓库放文章尾，写的不好，代码仅供参考。
Hbase VS ElasticSearch
wuzd的专栏
08-29 1040
从关系数据库的视角观察ElasticSearch和Hbase的读写， 若ElasticSearch是AK47，那Hbase就是马克沁。 运行环境：同一台笔记本电脑，虚拟的3节点的Centos7 环境 数据：一百万条数据的高表测试。（电脑弱，就做个试验） 结论： 全件写入：Hbase快 全件遍历：ES快 单行读出：都在0.5秒内 详细： 一、Hbase 1.用Python操作Hbase 2.Python写入100万行耗时，37分 3...
海量数据存储方案
weixin_33753845的博客
03-14 1087
参考原文：http://blog.youkuaiyun.com/xlgen157387/article/details/53230138 一、网站应用背景 开发一个网站的应用程序，当用户规模比较小的时候，使用简单的：一台应用服务器+一台数据库服务器+一台文件服务器，这样的话完全可以解决一部分问题，也可以通过堆硬件的方式来提高网站应用的访问性能，当然，也要考虑成本的问题。 当问题的规模在经济条件下通过堆硬...
ElasticSearch+hbase
.
03-26 1007
HBase在滴滴主要存放了以下四种数据类型： 统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配合Phoenix进行SQL查询。数据量较小，对查询的灵活性要求高，延迟要求一般。 原始事实类数据：如订单、司机乘客的GPS轨迹、日志等，主要用作在线和离线的数据供给。数据量大，对一致性和可用性要求高，延迟敏感，实时写入，单点或批量查询。 中间结果数据：指模型训练...
TableStore: 海量结构化数据分层存储方案
weixin_34144450的博客
03-06 218
前言 表格存储是阿里云自研分布式存储系统，可以用来存储海量结构化、半结构化的数据。表格存储支持高性能和容量型两种实例类型。高性能使用SSD的存储介质，针对读多写多的场景都有较好的访问延时。容量型使用的是SSD和SATA混合的存储介质。对写多的场景，性能接近高性能，读方面，如果遇到冷数据产生读SATA盘的话，延时会比高性能上涨一个量级。在海量数据存储场景...
Elasticsearch + Logstash
最新发布
12-03
`Elasticsearch + Logstash` 是 **ELK 技术栈**（Elasticsearch、Logstash、Kibana）中的两个核心组件，广泛用于日志收集、处理、存储与搜索分析。它们结合使用可以实现对海量数据的高效采集、清洗转换和实时检索。 --- ## 🧩 一、Elasticsearch + Logstash 的基本角色 | 组件 | 角色 | 功能 | |------|------|------| | **Logstash** | 数据管道引擎 | 负责从多种来源（如文件、数据库、消息队列）读取数据，进行过滤、转换后输出到目标（如 Elasticsearch） | | **Elasticsearch** | 分布式搜索引擎 | 存储结构化或半结构化数据，支持全文检索、聚合分析、高并发查询 | > ✅ 典型架构： ```text 数据源 → Logstash（输入 → 过滤 → 输出） → Elasticsearch → Kibana（可视化） ``` --- ## 🔧 二、典型应用场景 ### 1. **日志集中管理** - 收集服务器日志（Nginx、Java 应用日志等） - 结构化解析错误堆栈、时间戳、IP 等字段 - 实现快速定位问题（如“某接口频繁报错”） ### 2. **业务数据同步** - 将 MySQL 数据通过 Canal + Kafka + Logstash 同步到 ES - 构建商品搜索、订单查询系统 ### 3. **安全审计与监控** - 收集登录日志、操作日志 - 设置告警规则（如“同一 IP 多次失败登录”） --- ## ⚙️ 三、工作流程详解：Logstash 如何将数据送入 Elasticsearch？ ### 步骤 1：配置 Logstash Pipeline（`pipeline.conf`） ```conf input { # 从文件读取日志 file { path => "/var/log/app/*.log" start_position => "beginning" tags => ["java-log"] } # 或从 Kafka 消费消息（常用于解耦） kafka { bootstrap_servers => "kafka:9092" topics => ["mysql-binlog", "app-logs"] group_id => "logstash-group" } } filter { # 使用 Grok 解析非结构化日志 if "java-log" in [tags] { grok { match => { "message" => "%{TIMESTAMP_ISO8601:log_time} %{LOGLEVEL:level} %{JAVACLASS:class} - %{GREEDYDATA:msg}" } } date { match => [ "log_time", "yyyy-MM-dd HH:mm:ss,S" ] target => "@timestamp" } } # 添加自定义字段 mutate { add_field => { "env" => "production" } } } output { # 输出到 Elasticsearch elasticsearch { hosts => ["http://elasticsearch:9200"] index => "app-logs-%{+YYYY.MM.dd}" # 按天创建索引 document_type => "_doc" user => "elastic" password => "password" } # 可选：同时输出到控制台调试 stdout { codec => rubydebug } } ``` --- ### 步骤 2：启动 Logstash ```bash bin/logstash -f pipeline.conf ``` Logstash 开始监听输入源，处理数据并写入 Elasticsearch。 --- ### 步骤 3：在 Elasticsearch 中查询数据 ```json GET /app-logs-2025.04.05/_search { "query": { "bool": { "must": [ { "match": { "level": "ERROR" } }, { "range": { "@timestamp": { "gte": "now-1h" } } } ] } } } ``` ✅ 结果：返回最近一小时内所有 ERROR 级别的日志。 --- ## 📈 四、性能优化建议 ### 1. **Elasticsearch 侧优化** - 设置合理的 `index.mapping.total_fields.limit`（默认 1000） - 使用 `keyword` 而非 `text` 字段做聚合 - 按时间滚动索引（Index Rollover），避免单索引过大 - 配置副本数为 0（写入时），完成后开启副本 ### 2. **Logstash 侧优化** - 使用批量写入（`batch_size` 和 `flush_size`） - 开启持久化队列（`queue.type: persisted`）防止宕机丢数据 - 多 worker 提升处理能力（`--pipeline.workers 4`） - 避免复杂 Grok 表达式（影响吞吐量） ### 3. **资源分配** | 场景 | 建议配置 | |------|--------| | 日均 10GB 日志 | 4C8G * 2 台 Logstash + 3 节点 ES 集群 | | 更大数据量 | 引入 Kafka 缓冲 + 多级 Pipeline | --- ## 🔄 五、常见替代方案对比 | 方案 | 特点 | 适用场景 | |------|------|----------| | **Filebeat + Logstash + ES** | Filebeat 轻量采集，Logstash 复杂处理 | 推荐标准架构 | | **Filebeat → Elasticsearch** | 无 Logstash，性能更高但处理能力弱 | 日志格式简单 | | **Fluentd + ES** | 类似 Logstash，更轻量，CNCF 项目 | Kubernetes 环境常用 | | **Canal + Kafka + Logstash + ES** | 同步 MySQL 到 ES 的经典链路 | 构建业务搜索引擎 | --- ## 🛠️ 六、运维注意事项 ### 1. **防止数据积压** - 监控 Logstash 的 `queue size` - 查看 Kafka 消费延迟（Lag） - 设置告警机制 ### 2. **索引生命周期管理（ILM）** 自动完成： - 写入 → 摇滚（rollover） - 热数据保留在 SSD - 冷数据迁移到低配节点 - 超过 30 天自动删除 ```json PUT _ilm/policy/logs-retention { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_size": "50GB" } } }, "delete": { "min_age": "30d", "actions": { "delete": {} } } } } } ``` ### 3. **权限控制** - 使用 X-Pack 安全功能限制访问 - 为不同团队分配角色和索引权限 --- ## ✅ 总结：Elasticsearch + Logstash 的价值 | 优势 | 说明 | |------|------| | ✅ 统一数据入口 | 支持 100+ 输入插件（JDBC、S3、Redis…） | | ✅ 强大的数据加工能力 | Grok、Mutate、Date、Ruby 脚本等 | | ✅ 实时可查 | 数据写入后秒级可见 | | ✅ 易于扩展 | 水平扩容 Logstash 和 ES 节点 | | ✅ 成熟生态 | 与 Kibana、Beats、APM 深度集成 | > 💡 **最佳实践组合**： > `Filebeat → Kafka → Logstash → Elasticsearch → Kibana` 既保证了高可用、可扩展，又能灵活处理复杂数据。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值