金沙城娱乐中心手机版:转发我合伙人的文章:
分类:通讯产品

金沙城娱乐中心手机版 1

原作者:Davies(来自豆瓣)

金沙城娱乐中心手机版,10月12日消息,存储技术服务商Juicedata宣布已完成来自华创资本领投、清源创投等跟投的数百万元天使轮融资。本轮融资将主要用于团队建设和产品研发。

原文发表于:https://www.douban.com/note/637760886/

Juicedata由刘洪清于2017年4月创立,是面向全球的新型分布式文件系统公司。其核心产品JuiceFS是专为公有云环境设计的分布式文件系统,创新性地使用对象存储作为底层的数据存储,在一个自主研发的高性能元数据服务的配合下实现了简单易用、按需伸缩、全局强一致、多地冗余、完全无运维等重要特性,同时将整体实施成本降低到传统解决方案的20%,是大数据时代理想的存储解决方案。

我和存储的故事要从 10 年前在豆瓣的工作开始。 2007 年的 8 月,那会豆瓣还只有 4 台机器,支撑每日三百多万的  PV ,存储也用的是单机的本地存储,条目的照片按照类别放在一个目录里,一百多万的小文件,即使用了对小文件支持很好的  reiserfs ,也已经没办法用 ls 或者 rsync 来访问或者备份了。 Web  服务器是  Lighttpd ,配置了合适的缓存策略,在没有任何 CDN 缓存的情况下勉强能撑。但很危险,如果那块硬盘挂了的话,很多条目图片就没了。后来我们将目录结构调整成两级,第二级最多 10000 个文件,这样就实现了正常访问和备份。

现在各行各业已经充分认识到大数据的价值,尤其快速增长AI和IoT领域,收集的数据以前所未有的速度疯狂增长,据IDC预测到2025年全球数据规模将增长至163ZB。传统的存储解决方案难以满足快速增长的数据存储需求,目前主流的存储方案仍然存在以下问题:第一,块存储有容量和单机限制,不便于共享和管理;第二,对象存储只提供被大大弱化的访问接口,很难支撑更广范围的应用场景;第三,自建的分布式文件系统成本高昂,难以维护。

一年后,豆瓣搬到了兆维工业园,服务器也更多了。我们发现服务器上的硬盘空间使用很不均衡,机器间的相互备份也很麻烦,想找一个分布式的存储方案来把所有硬盘空间统一成全局的存储系统。先尝试了 GlusterFS ,它优雅的设计以及跟单机文件系统的兼容性很吸引人,可以把单机的文件系统原封不动地加入到 GlusterFS 中提供对外访问。可惜那会的 GlusterFS  还不够成熟,弄不好就死机了,好在不会丢数据,得益于前面说的那个兼容性。后来有幸发现了 MooseFS (简称 MFS ),上手非常容易,也很稳定。当时也在调研 Hadoop 和 HDFS ,但 MooseFS 的 POSIX API 使得它更容易使用也能支撑更多的应用场景,就被大范围使用了,从一开始的数据备份,到跨机器数据共享,再到后来的大数据分析,基本上都是用它。最大的 MFS 集群是挂载在 /mfs,  由于使用太频繁,导致很长一段时间两只手都会下意识的输入  mfs 。

JuiceFS通过使用对象存储作为底层的数据存储从而获得无限的扩展能力,实现了类似于块存储上的单机文件系统接口,可以无需任何修改兼容所有应用场景,并且以服务的形式提供给客户,免去了运维复杂分布式文件系统的烦恼,帮助客户更快地从数据中从获取价值以助力业务发展。

为了能够掌控 MFS ,我在调研时就开始通过阅读它的源代码来了解运作机制,结合之前已经学习过多次的 Google  的那篇 GFS 论文,对分布式文件系统怎么运作算是有了比较清楚的认识,当使用 MFS 碰到问题时,就自己打补丁来解决,并同时提交给上游,不少被官方接受(接受代码或者他们自己重新实现一下)。我们从一开始的 1.5 ,一直跟着官方升级,并维护少量自己的补丁,在 Gentoo 上维护补丁也挺愉快的。绝大部分时候都表现很好,时常光顾它的 WebUI 也是我喜欢干的一件事。几年下来也碰到过一两次事故,其中一次是在做故障切换时操作不当,导致 mfsmaster 启动时使用了初始化状态,文件系统是空的, chunk server 连接上 mfsmaster 并汇报自己拥有的数据块,被 mfsmaster 认为那些块不应该存在,就命令 chunk server 把它们删掉。还好发现得及时,只被删了少部分数据,也都是我们收集的内部日志数据,而不是更重要的用户数据。事后给 MFS 打了补丁,延缓删除这种未知数据块。

在公有云市场百花齐放的今天,同时使用多个云或者在不同云之间迁移将会是常态,JuiceFS通过提供标准的文件系统接口,帮客户避免对单个云绑定。JuiceFS同时提供跨云跨区的数据复制功能,帮助客户轻松实现不同公有云或者服务区的数据迁移。

2008  年豆瓣开始往社区方向发展,做了用户相册,这对在线存储提出了更高的要求。我们当时调研了 MogileFS ,经过一段时间的使用之后感觉性能不太好,一方面是 MySQL 容易成为瓶颈,小文件直接放本地文件系统上的性能也不好,数据迁移很慢。那会 Amazon 的 Dynamo  论文流传很广,简化的 KV 系统以及最终一致性给存储系统的实现打开了另一扇门。当时还没有成熟的开源系统可以用,我们就自己开始做 Beansdb ,经过了几次迭代,从一开始基于文件系统的 Merkle 树,到 TokyoDB ,再到 Bitcask,慢慢稳定和成熟,支撑了上百个节点和接近 PB 的数据量。过去两年豆瓣的同学们又对 Beansdb 做了大的升级,目前还没有开源,具体细节我就不知道了。

Juicedata创始人、CEO刘洪清表示:“Juicedata要让每个企业都拥有大数据存储和管理能力,不管有多少数据,使用起来都像使用单机一样简单。”

2009 年之后,豆瓣的存储架构算是比较稳定和成熟了, MFS 和 Beansdb 承载了豆瓣的绝大部分数据。 MFS 负责离线部分,用来管理几乎所有机器的剩余磁盘空间,存放各种日志、备份,甚至开发的代码以及相关的各种数据。 MFS 的 POSIX API 给工程师带来了很大便利,包括后来能够快速开发 DPark 并投入生产环境使用也是受益于 MFS 的 POSIX API 。 Beansdb 则负责了在线系统的绝大部分数据(图片和长文本等),结构化数据仍然是 MySQL ,一开始设想的用 KV 系统取代 MySQL 因为最终一致性带来的诸多问题未能实现。我有幸参与了这两套系统的很多工作,也对 POSIX API 的便利性和最终一致性系统的局限性有了很深的体会。

JuiceFS于2017年9月发布公测版本,刚一推出就获得多家客户试用。2018年初正式发布商用版,主要服务于高速成长中的企业,帮助他们快速、低门槛地实现可靠的大数据存储方案。主要使用场景包括Kubernetes持久卷、AI训练场景的数据共享、与Hadoop生态集成的大数据存储与分析、数据库冷备、日志收集与归档、数据异地备份容灾等。目前已有近20 家付费客户,主要分布在社区、生活服务、娱乐、金融、人工智能等行业。JuiceFS还提供1TB的永久免费服务,给个人和初创企业提供简单易用的低成本存储方案。

在 2013 年离开豆瓣前夕,我尝试改进 MFS 以满足豆瓣日益增长的性能和可用性需求。一方面是把它的网络层从 poll 改成 epoll ,大大降低 mfsmaster 的 CPU 占用,以支撑上千的节点;同时也尝试把部分元数据缓存到客户端来降低 mfsmaster 的请求数,提升可扩展能力;实现多 master (镜像)来解决它的单点问题。那段时间很开心地写了很多 C 代码,而且能很快看到改动上线后大大地提升系统性能,就更开心了。可惜因为时间关系,离职前未能把这三部分做到更完善,豆瓣在使用了一段时间后遇到了一些问题,不想继续维护这个分支,就又切换到官方版本上去了。这些改进都发布在 github 上,尤其是双 master 镜像方案,给 MFS 社区不少启发,官方把大部分重新实现了一下,在闭源的 Pro 版本里面实现了 HA ,另一个开源分支 LizardFS 也是实现了类似的机制(然后号称有 HA 支持)。用 epoll 和客户端缓存来提升 master 的支撑能力, MFS 和 LizardFS 到现在都没有实现,很可惜。

本文由金沙城娱乐中心手机版发布于通讯产品,转载请注明出处:金沙城娱乐中心手机版:转发我合伙人的文章:

上一篇:没有了 下一篇:没有了
猜你喜欢
热门排行
精彩图文