云Hbase数据库在亿方云实践之路

简介: 2017云栖大会HBase专场,亿方云科技CTO 王成军带来HBase在亿方云客户端同步系统中的应用实践的演讲。本文主要先介绍了亿方云,进而谈及了数据架构,着重分析了HBase实践,最后对亿方云HBase演进和应用作了分享。

2017云栖大会HBase专场,亿方云科技CTO 王成军带来HBase在亿方云客户端同步系统中的应用实践的演讲。本文主要先介绍了亿方云,进而谈及了数据架构,着重分析了HBase实践,最后对亿方云HBase演进和应用作了分享。
以下是精彩内容整理;

亿方云

1


亿方云做的主要是文件管理,目前主要面向企业客户,大家可以理解成为企业版的网盘,除了个人网盘所具备的功能以外,还有基于企业的内部组织架构的信息管理需要,所以它会涉及到更多的企业内部办公协作场景。平时你自己一个人手机上需要看一个文件,PC端上需要看一个文件,你在多终端同步使用的时候,当协作跨了很多人,我们有一个小的工作组,大家做一个项目,大家希望互相之间能够很快地拿到其他人更新的文档,比如说共同去写一份文档的时候,希望能够及时地看到对方作出的修改内容。

2


我们已经逐步把自己的工作做了一些云端化的处理,企业也会考虑这些场景,于是就有一系列的厂商来提供这样的服务,所以我们需要基础上的架构、平台来提供技术上的能力。我们首先要解决文件得有地方存,其次文件能够被搜索,文件能够被察看、预览、编辑,还有权限的设置。

3


说到具体产品的功能,其实我们在日常生活当中对文件的使用是一个比较随意的行为,比如创建一个文件不会对创建文件的动作谨慎,当你去做文件管理工具的时候,特别是云端文件管理工具的时候,文件处理的量级从一开始就会变得非常大。目前来看,我们的处理量级每天日增文件量大概在一百万左右,这还不包括去修改的一些文件和增量上的补充,只是净增长。同时,由于这些文件的操作,就会产生对于文件状态上的变化,哪怕你只改了一个字,这个文件也不一样了。意味着你对文件的状态和它的变更信息处理的信息量级一定会非常大。
适合我们的技术选型有什么呢?如果一个产品一开始量级不是很多,你的用户也不是很多的时候,那你所有东西直接丢给关系型数据库也是可以的。但是当数据快速地积累到了亿、十亿,那么关系型数据库吃不消了,就需要想各种各样的办法,在早期没有很好的分布式系统之前,我们采取把数据做一些水平拆分,自己建一些分库分表的规则。那个时候游戏数据比较多,直接分区,区与区之间是天然分离的,把很多复杂的部分留给了业务处理。
做文件管理与很多其他的系统不太一样,我们从第一天设计的时候就必须要按照数量级很高的标准来要求,只要做文件,数据只有增,没有减,哪怕存在那里,可能十年没有访问,但是不能删除,所以数据的量级永远在那里。的确,热点是存在的,数据不断向前递进,其实文件只有新的热度才会很高,伴随着现在很多数据挖掘的工具,很多人开始把历史数据利用起来。当我们为客户提供这类特殊的场景化服务以后,会发现数据热度会产生一些变化,意味着你在设计系统的时候会面临新的问题,有很多数据热点的分布可能不能按照你所想象的那样,我们会想一些办法,当你去提供对应的一些业务场景的时候要基于这个业务场景再设计一个热点分布的一套规则。

数据平台架构

4


数据平台架构是我们在做数据整理和分析的时候通用的场景。智能计算数据量级比较多,需要很多规则进行计算,这些规则不太可能自己人工地去维护所有规则,需要通过一些方式来不断完善数据。

实现场景

跨区域间文件外部协作

5


6


大家想象一下,网游的服务器是分区的,我们在不同区上的玩家可以PK,意味着他们之间是需要有数据交互的。如果你一开始就做了分区,意味着他们有数据交互的时候就需要建立一些数据联系,但是数据联系从理论上来说没有办法预计得到多少,有可能A区和D区所有玩家都因为搞一次活动全部建立了联系,这种联系需要数据访问的可能性。
网游有一个地方对于延时是很敏感的,所以导致它在分区上做了处理。我们这个场景下能见的处理对延时不是很敏感,但是对于流量和带宽非常敏感。比如说下一个订单的请求,所有流量传递,订单请求总共三到五次,全部流量消耗也就3到5兆,还包括中间的图片传输流量,如果用文件,一个文件就是三到五兆的流量。当文件要考虑它的流量和带宽场景的时候,就必须得做一些分区化的处理,比如说北京的用户,希望他能够就近地访问北京相应的存储。如果有一家企业自己需要在不同的地方去办公,同时还需要跟不同区域上的企业去协作,那么就需要建立这种联系,当他们需要使用文件的时候,我们希望能够在最近的位置上去使用,如果不是就近就需要建立一些联系。
这个关联关系怎么来存放?相当于构建了一个非常大的文件指针索引,指向真实的物理位置,这个物理文件的指针如果用关系型数据库来做不是特别合适,它的查询场景很单一,不太可能会有太多的关联性,更多的场景下都是以单点的查询为主。如果从演进的角度来说,开始也不是放在HBase里,也是放在数据库里,因为数据很少,当数据有几亿的时候根本没有办法处理,逼迫我们采取策略,把这部分数据梳理下。

文件实时消息推送

7


8


比如有一个群,这个群里面有很多人,消息其实就推送给很多人,而不是单个点发送一次,我直接只发到服务器,服务器会把这个消息推送给群内其他成员。
文件的使用为什么会出现这种情况?举一个例子,自己在多终端使用,你在电脑上编辑了文件,对文件做了一些修改,手机上同时也在查看这个文件,查看的过程当中这个文件变更了,很多人觉得这没有关系,重新刷新一下,但是这是你主动的行为,主动刷新才行。当然也可以搞一个定时器,一分钟刷新一次,这种情况对于我们某些特定情况来说是不成立的,比如说有限的时间内正在审查一些特定的文件,在审一份合同稿几百页,整体审查一次就疯了,你不告诉我哪儿有变更不可能把这份文件审阅完。很多情况下,我们是一个协作的过程,一定会有修改,需求往往会有变更。既然有这样的场景,我们就要面临这样的问题,把变更的消息能够快速地通知到你。

亿方云Hbase演进之路

9


我们当初是没有一个完整的数据处理架构,当初设计这部分内容时候甚至不觉得这个信息需要做长久化,因为时效性非常短,文件最终状态才是大家关心的,过程当中的消息似乎没有太大的保存价值。但是大家想象一个场景,创建一个空文件,文件名字叫“新建文档”,我马上得重命名一下,假如我们不做持久化,也不把时序做处理,信息丢过去终端先收到了文件的改名,然后才收到了创建文件,这个时候这两个操作还能够成功吗?改名的时候这个文件还没有创建,改名字的操作不见了,原来这个文件的操作是需要有时序的。
这就引出问题,一方面要对信息做持久化,另一方面要对后一个任务处理。我们有很多的文件处理是需要有上门的情况,就必须要对时序做特定的标注,然后做特定处理。新建、编辑、修改、删除以及分享,或者我发起了希望你来上传的操作,把我的权限给到你,让你来上传,那么这些操作其实都需要先有一个消息给到对方,让对方把对应的消息做处理,这个消息对写起到的主要作用就是把前面抛过来的不管是数据变更也好、文件操作也好,处理掉以后丢给后面的推送消息任务,让这个消息推送到某客户端上面,这还涉及到端上有订阅机制,订阅的信息也要分设备、分终端、分用户。有的时候大家会遇到这样的情况,除了普通的客户端以外,还会建立web上的推送消息。
我们用云端HBase最大的好处是,以前我们所做的事情有人帮我们做了,特别是运维上的工作,我们现在基本上不太关注HBase够不够用问题。现在很多的基础性工作由阿里云帮我们做。

Hbase应用

对于文件操作的信息其实是一项非常好的风控信息来源,当行为是一系列集合,当这个集合符合一定模型的时候就会找到它的操作背后所做的初衷。举个例子来说,公司里某位程序员因为各种不满意,走之前把公司的代码带走了,文档都删了,企业里现在的信息资产都是文件的形式,这些东西如果突然没有代价很大。即使这个操作是可逆的,但是一样会造成损失,在恢复的时间就要付出更大的代价。我们需要有一个非常好的技术信息体系来支撑,操作必须得有上下文的关联关系,是能够从中间截断的,需要把原来很多操作剥成上下文可以隔离的,同时,推送一条消息给老板,说这个行为有一些什么倾向。
现在已经开始提供一些基于文件内容的分析,当你看视频的时候,会发现优库有一些打点的关键节点,比如说《速度与激情》,就是希望看到翻车的那一段视频,直接找到那个点。以前更多的是通过人肉编辑方式,如果我们能够具备对内容做一些分析基础就可以慢慢地把这件事情做起来。
文件的元数据是对文件做一些分类标签,它属于人文社科,还是属于化学等等,这些元数据的存放是非常符合Key value方式的。

相关实践学习
云数据库HBase版使用教程
  相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情: https://cn.aliyun.com/product/hbase   ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2天前
|
缓存 监控 数据库
数据库优化实践
在应对电商平台数据库性能下降问题时,公司通过查询优化、硬件升级、索引调整、锁机制改进、数据库分区、读写分离及引入缓存等措施,显著提升了性能。实时监控和用户反馈显示,查询响应时间缩短,事务处理加快,用户体验和业务扩展能力均得到改善。这强调了数据库性能管理对数字化时代业务的重要性及持续优化的必要性。
|
2天前
|
SQL 关系型数据库 数据库
阿里云数据库 RDS SQL Server版实战【性能优化实践、优点探析】
本文探讨了Amazon RDS SQL Server版在云数据库中的优势,包括高可用性、可扩展性、管理便捷、安全性和成本效益。通过多可用区部署和自动备份,RDS确保数据安全和持久性,并支持自动扩展以适应流量波动。可视化管理界面简化了监控和操作,而数据加密和访问控制等功能保障了安全性。此外,弹性计费模式降低了运维成本。实战应用显示,RDS SQL Server版能有效助力企业在促销高峰期稳定系统并保障数据安全。阿里云的RDS SQL Server版还提供了弹性伸缩、自动备份恢复、安全性和高可用性功能,进一步优化性能和成本控制,并与AWS生态系统无缝集成,支持多种开发语言和框架。
22 2
|
4天前
|
Cloud Native 数据管理 关系型数据库
【阿里云云原生专栏】云原生数据管理:阿里云数据库服务的分布式实践
【5月更文挑战第21天】阿里云数据库服务在云原生时代展现优势,应对分布式数据管理挑战。PolarDB等服务保证高可用和弹性,通过多副本机制和分布式事务确保数据一致性和可靠性。示例代码展示了在阿里云数据库上进行分布式事务操作。此外,丰富的监控工具协助用户管理数据库性能,支持企业的数字化转型和业务增长。
173 1
|
5天前
|
存储 分布式计算 Java
大数据存储技术(3)—— HBase分布式数据库
大数据存储技术(3)—— HBase分布式数据库
85 0
|
5天前
|
存储 人工智能 数据库
【LangChain系列】第四篇:向量数据库与嵌入简介及实践
【5月更文挑战第18天】 本文介绍了构建聊天机器人和语义搜索的关键组件——向量存储和嵌入。首先,文章描述了工作流程,包括文档拆分、生成嵌入和存储在向量数据库中。接着,通过Python代码展示了如何设置环境并处理文档,以及如何创建和比较文本嵌入。向量存储部分,文章使用Chroma存储嵌入,并进行了相似性检索的演示。最后,讨论了故障模式,如重复文档和未捕获结构化信息的问题。整个博文中,作者强调了在实际应用中解决这些问题的重要性。
60 0
|
10天前
|
存储 Java 分布式数据库
【分布式计算框架】HBase数据库编程实践
【分布式计算框架】HBase数据库编程实践
17 1
|
10天前
|
SQL Java 数据库连接
Java数据库编程实践:连接与操作数据库
Java数据库编程实践:连接与操作数据库
14 0
|
8天前
|
关系型数据库 MySQL API
实时计算 Flink版产品使用合集之可以通过mysql-cdc动态监听MySQL数据库的数据变动吗
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
85 0
|
10天前
|
关系型数据库 MySQL 数据库
docker MySQL删除数据库时的错误(errno: 39)
docker MySQL删除数据库时的错误(errno: 39)
67 0
|
3天前
|
存储 SQL 关系型数据库
【MySQL】数据库基础 -- 详解
【MySQL】数据库基础 -- 详解