大数据时代数据库-云HBase架构&生态&实践

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介:

2018第九届中国数据库技术大会,阿里云高级技术专家、架构师封神(曹龙)带来题为大数据时代数据库-云HBase架构&生态&实践的演讲。主要内容有三个方面:首先介绍了业务挑战带来的架构演进,其次分析了ApsaraDB HBase及生态,最后分享了大数据数据库的实际案例。

讲师介绍:

大数据时代数据库-云HBase架构&生态&实践

  封神,真名曹龙,09年加入阿里,现任阿里云高级技术专家、架构师,专注于大数据分布式计算、数据库、存储领域,先后研发上万台Hadoop、ODPS集群,负责阿里YARN、Spark及自主研发内存计算引擎,目前为广大公共云用户提供专业的云HBase数据库及计算服务。

  正文演讲:

 业务的挑战

  存储量量/并发计算增大

大数据时代数据库-云HBase架构&生态&实践

  现如今大量的中小型公司并没有大规模的数据,如果一家公司的数据量超过100T,且能通过数据产生新的价值,基本可以说是大数据公司了 。起初,一个创业公司的基本思路就是首先架构一个或者几个ECS,后面加入MySQL,如果有图片需求还可加入磁盘,该架构的基本能力包括事务、存储、索引和计算力。随着公司的慢慢发展,数据量在不断地增大,其通过MySQL及磁盘基本无法满足需求,只有分布式化。 这个时候MySQL变成了HBase,检索变成了Solr/ES,再ECS提供的计算力变成了Spark。但这也会面临存储量大且存储成本高等问题。

非结构化业务增多

大数据时代数据库-云HBase架构&生态&实践

  另外一个趋势就是非结构化的数据越来越多,数据结构的模式不仅仅是SQL,时序、时空、graph模式也越来越多,需要一些新的存储结构或新的算法去解决这类问题,也意味着所需要做的工程量就会相对较高。

引入更多的数据

  对于数据处理大致可归类为四个方面,分别是复杂性、灵活性、延迟<读,写>和分布式,其中分布式肯定是不可少的,一旦缺少分布式就无法解决大规模问题 。灵活性的意思是业务可以任意改变的;复杂性就是运行一条SQL能够访问多少数据或者说SQL是否复杂;延迟也可分为读与写的延迟。Hadoop & Spark可以解决计算复杂性和灵活性,但是解决不了延迟的问题;HBase&分布式索引、分布式数据库可以解决灵活性与延迟的问题,但由于它没有很多计算节点,所以解决不了计算复杂性的问题。Kylin(满足读延迟)在计算复杂性与延迟之间找了一个平衡点,这个平衡点就是怎样快速出报表,但对于这个结果的输入时间我们并不关心,对于大部分的报表类的需求就是这样的。每个引擎都有一定的侧重,没有银弹!

ApsaraDB HBase产品架构及改进

  应对的办法

  我们也不能解决所有的问题,我们只是解决其中大部分的问题。如何找到一个在工程上能够解决大部分问题的方案至关重要,应对办法:

  分布式:提供扩展性

  计算?延伸:算?+SQL,从ECS到Spark其本质其实就是一种计算力的延伸

  分层设计:降低复杂性,提供多模式的存储模型

  云化:复用资源&弹性,降低成本

基本构架

大数据时代数据库-云HBase架构&生态&实践

  首先包含了两个分离

  ·分别是HDFS与分布式Region\分布式检索分离

  ·SQL\时空\图\时序\Cube与分布式Region\检索分离

  大致的分层机构如下:

  · 第一层:介质层,热SSD介质、温SSD&SATA 混合、冷纯SATA(做EC)

  · 第二层:分布式文件系统,也就是盘古。事实上越是底层越容易做封装优化。

  · 第三层:分布式安全隔离保障层QOS,如果我们做存储计算分离,就意味着底层的三个集群需要布三套,这样每个集群就会有几十台甚至几百台的节点,此时存储力是由大家来均摊的,这就意味着分布式安全隔离保障层要做好隔离性,引入QOS就意味着会增加延迟,此时会引入一些新的硬件(比如RDMA)去尽可能的减小延迟。

  · 第四层:分布式?文件接?:HDFS & API(此层看情况可有可无)

  · 第五层:我们提供了两个组件,分布式Region-HBase与分布式检索-Solr,在研究分布索引的时候发现单机索引是相对简单的,我们提供针对二级索引采取内置的分布式Region的分布式架构,针对全文索引采取外置Solr分布式索引方案

  · 第六层:建设在分布式KV之上,有NewSQL套件、时空套件、时序套件、图套件及Cube套件

  另外,可以引入spark来分析,这个也是社区目前通用的方案

解决成本的方案

  对于解决成本的方案简单介绍如下:

  · 分级存储:SSD与SATA的价格相差很多,在冷数据上,我们建议直接采取冷存储的方式 ,可以节约500%的成本

  · 高压缩比:在分级存储上有一个较好的压缩,尤其是在冷数据,我们可以提高压缩比例,另外分布式文件系统可以采取EC进一步降低存储成本,节约100%的成本

  · 基础设施共享:库存压力分担,云平台可以释放红利给客户

  · 存储与计算分离:按需计费

  · 优化性能:再把性能提升1倍左右

云数据库基本部署结构

大数据时代数据库-云HBase架构&生态&实践

  假设在北京有三个机房可用区A、B和C,我们会在可用区A中部署一个热的存储集群,在北京整体区域部一个冷的存储集群,实际上有几个可用区就可以有几个热集群,主要是保障延迟的;冷集群对延迟相对不敏感,可以地域单独部署,只要交换机满足冷集群所需的带宽即可。这样的好处是三个区共享一个冷集群,就意味着可以共享库存。

ApsaraDB HBase产品能力

  我们提供两个版本,一是单节点版,其特点是给开发测试用或者可用性不?,数据量不大的场景。二是集群版本其特点是高至5000w QPS,多达10P存储与高可靠低延迟等。

  · 数据可靠性:99.99999999%:之所以可靠性可以达到如此之高,其核心的原因就是存储集群是单独部署的,其会根据机架等进行副本放置优化

  · 服务可用性:单集群99.9% 双集群99.99%。

  · 服务保障:服务未满足SLA赔付。

  · 数据备份及恢复。

  · 数据热冷分离\分级存储。

  · 企业级安全:认证授权及加密。

  · 提供检索及二级索引及NewSQL能?。

  · 提供时序/图/时空/Cube相关能?。

  · 与Spark无缝集成,提供AP能?。

数据备份及恢复

大数据时代数据库-云HBase架构&生态&实践

  备份分为全量备份HFile与 增量量备份HLog;恢复分为HLog转化为HFile和BulkLoad加载。阿里云集团迄今为止已经有一万两千多台的HBase,大部分都是主备集群的,在云上由于客户成本的原因,大部分不选择主备,所以需要对数据进行备份。其难点在于备份需要引入计算资源,我们需要引入弹性的计算资源来处理备份的相关计算任务

Compaction 离线Compaction(研究中)

大数据时代数据库-云HBase架构&生态&实践

  我们在内部研究如何通FPGA对Compaction进行加速,这会使得集群运行比较平缓,特别是对计算资源少,存储量大的情况下,可以通过离线的作业处理Compaction。

 组件层

  我们有5中组件,NewSQL(Phoenix)、时序OpenTSDB、时空GeoMesa、图JanusGraph及Cube的Kylin,及提供HTAP能力的Spark。这里简单描述几个,如下:

 NewSQL - Phoenix

  客户还是比较喜欢用SQL的,Phoenix会支持SQL及二级索引,在超过1T的数据量的情况下,对事务的需求就很少(所以我们并没有支持事务);二级索引是通过再新建一张HBase表来实现的。在命中索引的情况下,万亿级别的访问基本在毫秒级别,但由于Phoenix聚合点在一个节点,所以不能做Shuffle类似的事情,同时也就不能处理复杂的计算,所以任何说我是HTAP架构的,如果不能做Shuffle,就基本不能做复杂的计算。

HTAP – Spark

大数据时代数据库-云HBase架构&生态&实践

  在HTAP-Spark这部分主要介绍一下RDD API、 SQL、直接访问HFile的特点。

  · RDD API具有简单?便,默认支持的特点,但高并发scan大表会影响稳定性;

  · SQL支持算?子下推、schema映射、各种参数调优,高并发scan大表会影响稳定性;

  · 直接访问HFile,直接访问存储不经过计算,大批量量访问性能最好,需要snapshot对齐数据。

 时序 – OpenTSDB & HiTSDB

  TSD没有状态,可以动态加减节点,并按照时序数据的特点设计表结构,其内置针对浮点的高压缩比的算法,我们云上专业版的HiTSDB增加倒排等能?,并能够针对时序增加插值、降精度等优化。

大数据数据库的实际案例

  以下简单介绍几个客户的案例,目前已经在云上ApsaraDB HBase运行,数据量基本在10T以上:

某车联网公司

大数据时代数据库-云HBase架构&生态&实践

  这是一个车联网的客户,有100万车,每辆车每10秒上传一次,每次1KB,这样一年就有300T数据,六个月以上是数据低频访问,所以他要做分级存储,把冷数据放到低介质上

某大数据控公司

大数据时代数据库-云HBase架构&生态&实践

  这是一个大数据控公司,它大约有200T+的数据量,将HBase数据 (在线实时大数据存储)作为主数据库,先用HBase做算法训练,再用HBase SQL出报表,另外做了一套ECS进行实时查以便与客户之间进行数据交换。

某社交公司

大数据时代数据库-云HBase架构&生态&实践

  社交会有大量的推荐,所以SLA要求高达99.99,并采用双集群保障,单集群读写高峰QPS 可以达到1000w+,数据量在30T左右。

 某基金公司

大数据时代数据库-云HBase架构&生态&实践

  这是一个金融公司,它有10000亿以上的交易数据,目前用多个二级索引支持毫秒级别的查询,数据量在100T左右

某公司报表系统

大数据时代数据库-云HBase架构&生态&实践

  先离线建好Cube再把数据同步到HBase中,实时数据通过Blink对接进行更新,数据量在可达20T左右


原文发布时间为:2018-06-4

本文作者:曹龙

本文来自云栖社区合作伙伴“IT168”,了解相关信息可以关注“IT168”。

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情:&nbsp;https://www.aliyun.com/product/ecs
相关文章
|
1天前
|
设计模式 API 持续交付
深入浅出:微服务架构的设计与实践
在软件开发的世界中,微服务架构如同一场革命,它改变了我们构建、部署和管理应用的方式。本文将带你一探微服务的奥秘,从基础概念到实际案例分析,再到设计模式和常见问题解答,我们一步步深入理解微服务架构的设计哲学和实践要点。无论你是初学者还是有经验的开发者,这篇文章都将为你打开一扇了解和应用微服务的大门。
|
2天前
|
监控 Cloud Native 持续交付
云原生时代的微服务架构实践
【9月更文挑战第5天】随着云计算技术的飞速发展,云原生已成为现代软件开发的重要趋势。本文将深入探讨在云原生环境下,如何有效实施微服务架构,包括服务拆分、容器化部署、持续集成与交付等关键环节。通过具体案例,我们将展示如何在云平台上构建弹性、可扩展的微服务应用,并讨论在此过程中可能遇到的挑战及解决策略。
|
3天前
|
前端开发 安全 JavaScript
构建高效Web应用:前后端分离架构的实践
【9月更文挑战第4天】在数字时代,Web应用已成为企业与用户互动的主要平台。本文将介绍如何通过前后端分离的架构设计来构建高效的Web应用,探讨该架构的优势,并分享实现过程中的关键步骤和注意事项。文章旨在为开发者提供一种清晰、高效的开发模式,帮助其在快速变化的市场环境中保持竞争力。
|
3天前
|
消息中间件 监控 API
深入浅出微服务架构:从理论到实践
在软件开发领域,“微服务”这一概念已如日中天,它改变了我们构建、部署和扩展应用的方式。本文将带你走进微服务的世界,不仅探讨其核心理念,还将通过实际案例,展示如何将一个传统单体应用拆分为微服务架构。我们将一步步分析微服务的优势与挑战,并讨论如何在现实世界中实现和维护微服务架构,让你对微服务有一个全面而深入的理解。
|
1天前
|
运维 Cloud Native 持续交付
云原生时代下的微服务架构实践
在数字化转型的浪潮中,云原生技术以其高效、灵活的特性成为企业IT架构升级的首选。本文将通过深入浅出的方式,探讨云原生环境下微服务架构的设计原则、关键技术及实施策略,旨在为读者提供一条清晰的技术路线图,帮助理解和掌握在云平台上构建和管理微服务的实用方法。
|
1天前
|
监控 Cloud Native 安全
云原生时代的微服务架构实践
【9月更文挑战第6天】在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性成为企业架构升级的首选。本文将通过浅显易懂的语言和生动的比喻,带你一探微服务架构的世界,从理论到实践,逐步揭示如何利用云原生技术构建高效、可靠的微服务系统,同时穿插代码示例,为有志于云原生领域发展的技术人员提供一份实操指南。
13 2
|
1天前
|
Java 数据库 微服务
深入浅出:微服务架构的设计与实践
在数字化时代的浪潮中,传统的单体应用逐渐显得笨重不堪。微服务架构以其灵活性、可扩展性成为现代软件开发的新宠。本文从基础概念出发,逐步深入探讨如何设计并实现一个高效的微服务系统,同时分享实战经验,帮助读者规避常见陷阱。
|
8天前
|
前端开发 大数据 数据库
🔥大数据洪流下的决战:JSF 表格组件如何做到毫秒级响应?揭秘背后的性能魔法!💪
【8月更文挑战第31天】在 Web 应用中,表格组件常用于展示和操作数据,但在大数据量下性能会成瓶颈。本文介绍在 JavaServer Faces(JSF)中优化表格组件的方法,包括数据处理、分页及懒加载等技术。通过后端分页或懒加载按需加载数据,减少不必要的数据加载和优化数据库查询,并利用缓存机制减少数据库访问次数,从而提高表格组件的响应速度和整体性能。掌握这些最佳实践对开发高性能 JSF 应用至关重要。
20 0
|
8天前
|
存储 设计模式 运维
Angular遇上Azure Functions:探索无服务器架构下的开发实践——从在线投票系统案例深入分析前端与后端的协同工作
【8月更文挑战第31天】在现代软件开发中,无服务器架构因可扩展性和成本效益而备受青睐。本文通过构建一个在线投票应用,介绍如何结合Angular前端框架与Azure Functions后端服务,快速搭建高效、可扩展的应用系统。Angular提供响应式编程和组件化能力,适合构建动态用户界面;Azure Functions则简化了后端逻辑处理与数据存储。通过具体示例代码,详细展示了从设置Azure Functions到整合Angular前端的全过程,帮助开发者轻松上手无服务器应用开发。
|
8天前
|
运维 Cloud Native Java
云原生时代的微服务架构实践
【8月更文挑战第31天】在这篇文章中,我们将一起探索云原生技术如何革新现代软件架构。通过深入浅出地讲解微服务的核心概念、优势及其在云平台上的实现方式,本文旨在为读者提供一个关于如何在云原生环境下设计、部署和管理微服务的全面指南。我们还将通过一个简易的代码示例来直观展示微服务的实践过程。无论你是软件开发者还是架构师,这篇文章都将为你打开一扇了解和进入云原生世界的大门。

热门文章

最新文章

下一篇
DDNS