2017云栖大会HBase专场，亿方云科技CTO 王成军带来HBase在亿方云客户端同步系统中的应用实践的演讲。本文主要先介绍了亿方云，进而谈及了数据架构，着重分析了HBase实践，最后对亿方云HBase演进和应用作了分享。
以下是精彩内容整理;
亿方云
亿方云做的主要是文件管理，目前主要面向企业客户，大家可以理解成为企业版的网盘，除了个人网盘所具备的功能以外，还有基于企业的内部组织架构的信息管理需要，所以它会涉及到更多的企业内部办公协作场景。平时你自己一个人手机上需要看一个文件，PC端上需要看一个文件，你在多终端同步使用的时候，当协作跨了很多人，我们有一个小的工作组，大家做一个项目，大家希望互相之间能够很快地拿到其他人更新的文档，比如说共同去写一份文档的时候，希望能够及时地看到对方作出的修改内容。
我们已经逐步把自己的工作做了一些云端化的处理，企业也会考虑这些场景，于是就有一系列的厂商来提供这样的服务，所以我们需要基础上的架构、平台来提供技术上的能力。我们首先要解决文件得有地方存，其次文件能够被搜索，文件能够被察看、预览、编辑，还有权限的设置。
说到具体产品的功能，其实我们在日常生活当中对文件的使用是一个比较随意的行为，比如创建一个文件不会对创建文件的动作谨慎，当你去做文件管理工具的时候，特别是云端文件管理工具的时候，文件处理的量级从一开始就会变得非常大。目前来看，我们的处理量级每天日增文件量大概在一百万左右，这还不包括去修改的一些文件和增量上的补充，只是净增长。同时，由于这些文件的操作，就会产生对于文件状态上的变化，哪怕你只改了一个字，这个文件也不一样了。意味着你对文件的状态和它的变更信息处理的信息量级一定会非常大。
适合我们的技术选型有什么呢？如果一个产品一开始量级不是很多，你的用户也不是很多的时候，那你所有东西直接丢给关系型数据库也是可以的。但是当数据快速地积累到了亿、十亿，那么关系型数据库吃不消了，就需要想各种各样的办法，在早期没有很好的分布式系统之前，我们采取把数据做一些水平拆分，自己建一些分库分表的规则。那个时候游戏数据比较多，直接分区，区与区之间是天然分离的，把很多复杂的部分留给了业务处理。
做文件管理与很多其他的系统不太一样，我们从第一天设计的时候就必须要按照数量级很高的标准来要求，只要做文件，数据只有增，没有减，哪怕存在那里，可能十年没有访问，但是不能删除，所以数据的量级永远在那里。的确，热点是存在的，数据不断向前递进，其实文件只有新的热度才会很高，伴随着现在很多数据挖掘的工具，很多人开始把历史数据利用起来。当我们为客户提供这类特殊的场景化服务以后，会发现数据热度会产生一些变化，意味着你在设计系统的时候会面临新的问题，有很多数据热点的分布可能不能按照你所想象的那样，我们会想一些办法，当你去提供对应的一些业务场景的时候要基于这个业务场景再设计一个热点分布的一套规则。
数据平台架构
数据平台架构是我们在做数据整理和分析的时候通用的场景。智能计算数据量级比较多，需要很多规则进行计算，这些规则不太可能自己人工地去维护所有规则，需要通过一些方式来不断完善数据。
实现场景
跨区域间文件外部协作
大家想象一下，网游的服务器是分区的，我们在不同区上的玩家可以PK，意味着他们之间是需要有数据交互的。如果你一开始就做了分区，意味着他们有数据交互的时候就需要建立一些数据联系，但是数据联系从理论上来说没有办法预计得到多少，有可能A区和D区所有玩家都因为搞一次活动全部建立了联系，这种联系需要数据访问的可能性。
网游有一个地方对于延时是很敏感的，所以导致它在分区上做了处理。我们这个场景下能见的处理对延时不是很敏感，但是对于流量和带宽非常敏感。比如说下一个订单的请求，所有流量传递，订单请求总共三到五次，全部流量消耗也就3到5兆，还包括中间的图片传输流量，如果用文件，一个文件就是三到五兆的流量。当文件要考虑它的流量和带宽场景的时候，就必须得做一些分区化的处理，比如说北京的用户，希望他能够就近地访问北京相应的存储。如果有一家企业自己需要在不同的地方去办公，同时还需要跟不同区域上的企业去协作，那么就需要建立这种联系，当他们需要使用文件的时候，我们希望能够在最近的位置上去使用，如果不是就近就需要建立一些联系。
这个关联关系怎么来存放？相当于构建了一个非常大的文件指针索引，指向真实的物理位置，这个物理文件的指针如果用关系型数据库来做不是特别合适，它的查询场景很单一，不太可能会有太多的关联性，更多的场景下都是以单点的查询为主。如果从演进的角度来说，开始也不是放在HBase里，也是放在数据库里，因为数据很少，当数据有几亿的时候根本没有办法处理，逼迫我们采取策略，把这部分数据梳理下。
文件实时消息推送
比如有一个群，这个群里面有很多人，消息其实就推送给很多人，而不是单个点发送一次，我直接只发到服务器，服务器会把这个消息推送给群内其他成员。
文件的使用为什么会出现这种情况？举一个例子，自己在多终端使用，你在电脑上编辑了文件，对文件做了一些修改，手机上同时也在查看这个文件，查看的过程当中这个文件变更了，很多人觉得这没有关系，重新刷新一下，但是这是你主动的行为，主动刷新才行。当然也可以搞一个定时器，一分钟刷新一次，这种情况对于我们某些特定情况来说是不成立的，比如说有限的时间内正在审查一些特定的文件，在审一份合同稿几百页，整体审查一次就疯了，你不告诉我哪儿有变更不可能把这份文件审阅完。很多情况下，我们是一个协作的过程，一定会有修改，需求往往会有变更。既然有这样的场景，我们就要面临这样的问题，把变更的消息能够快速地通知到你。
亿方云Hbase演进之路
我们当初是没有一个完整的数据处理架构，当初设计这部分内容时候甚至不觉得这个信息需要做长久化，因为时效性非常短，文件最终状态才是大家关心的，过程当中的消息似乎没有太大的保存价值。但是大家想象一个场景，创建一个空文件，文件名字叫“新建文档”，我马上得重命名一下，假如我们不做持久化，也不把时序做处理，信息丢过去终端先收到了文件的改名，然后才收到了创建文件，这个时候这两个操作还能够成功吗？改名的时候这个文件还没有创建，改名字的操作不见了，原来这个文件的操作是需要有时序的。
这就引出问题，一方面要对信息做持久化，另一方面要对后一个任务处理。我们有很多的文件处理是需要有上门的情况，就必须要对时序做特定的标注，然后做特定处理。新建、编辑、修改、删除以及分享，或者我发起了希望你来上传的操作，把我的权限给到你，让你来上传，那么这些操作其实都需要先有一个消息给到对方，让对方把对应的消息做处理，这个消息对写起到的主要作用就是把前面抛过来的不管是数据变更也好、文件操作也好，处理掉以后丢给后面的推送消息任务，让这个消息推送到某客户端上面，这还涉及到端上有订阅机制，订阅的信息也要分设备、分终端、分用户。有的时候大家会遇到这样的情况，除了普通的客户端以外，还会建立web上的推送消息。
我们用云端HBase最大的好处是，以前我们所做的事情有人帮我们做了，特别是运维上的工作，我们现在基本上不太关注HBase够不够用问题。现在很多的基础性工作由阿里云帮我们做。
Hbase应用
对于文件操作的信息其实是一项非常好的风控信息来源，当行为是一系列集合，当这个集合符合一定模型的时候就会找到它的操作背后所做的初衷。举个例子来说，公司里某位程序员因为各种不满意，走之前把公司的代码带走了，文档都删了，企业里现在的信息资产都是文件的形式，这些东西如果突然没有代价很大。即使这个操作是可逆的，但是一样会造成损失，在恢复的时间就要付出更大的代价。我们需要有一个非常好的技术信息体系来支撑，操作必须得有上下文的关联关系，是能够从中间截断的，需要把原来很多操作剥成上下文可以隔离的，同时，推送一条消息给老板，说这个行为有一些什么倾向。
现在已经开始提供一些基于文件内容的分析，当你看视频的时候，会发现优库有一些打点的关键节点，比如说《速度与激情》，就是希望看到翻车的那一段视频，直接找到那个点。以前更多的是通过人肉编辑方式，如果我们能够具备对内容做一些分析基础就可以慢慢地把这件事情做起来。
文件的元数据是对文件做一些分类标签，它属于人文社科，还是属于化学等等，这些元数据的存放是非常符合Key value方式的。
