数据湖架构，为什么需要“湖加速”？

基于这些因素，我们进一步开发和推出JindoFS block模式，在OSS对象存储的基础上针对大数据计算进行深度定制，仍然提供标准的HCFS接口，因为我们坚信，即使同样走深度定制路线，遵循现有标准与使用习惯对用户和计算引擎来说更加容易推广和使用，也更加符合湖加速的定位和使命。JindoFS block模式对标HDFS，不同的是采取云原生的架构，依托云平台我们做了大量简化，使得整个系统具有弹性，轻量和易于运维的特点和优势。

如上图示，是JindoFS在block模式下的系统架构，整体上重用了JindoFS缓存系统。在这种模式下，文件数据是分块存放在OSS上，保证可靠和可用;同时借助于本地集群上的缓存备份，可以实现缓存加速。文件元数据异步写入到阿里云OTS数据库防止本地误操作，同时方便JindoFS集群重建恢复;元数据在正常读写时走本地RocksDB，内存做LRU缓存，因此支撑的文件数在亿级;结合元数据服务的文件/目录级别细粒度锁实现，JindoFS在大规模高并发作业高峰的时候表现比HDFS更稳定，吞吐也更高。我们用HDFS NNBench做并发测试，对于最关键的open和create操作，JindoFS的IOPS比HDFS高60%。在千万级超大目录测试上，文件listing操作比HDFS快130%;文件统计du/count操作比HDFS快1X。借助于分布式Raft协议，JindoFS支持HA和多namespaces，整体上部署和维护比HDFS简化太多。在IO吞吐上，因为除了本地磁盘，还可以同时使用OSS带宽来读，因此在同样的集群配置下用DFSIO实测下来，读吞吐JindoFS比HDFS快33%。

JindoFS在湖加速整体解决方案上进一步支持block模式，为我们拓宽数据湖使用场景和支持更多的引擎带来更大的想象空间。目前我们已经支持不少客户使用HBase，为了受益于这种存/算分离的架构同时借助于本地管理的存储设备进行缓存加速，我们也在探索将更多的开源引擎对接上来。比如像Kafka，Kudu甚至OLAP新贵ClickHouse，能不能让这些引擎专注在它们的场景上，将它们从坏盘处理和如何伸缩这类事情上彻底解放出来。原本一些坚持使用HDFS的客户也被block模式这种轻运维，有弹性，低成本和高性能的优势吸引，通过这种方式也转到数据湖架构上来。如同对OSS的适配支持和缓存模式，JindoFS这种新模式仍然提供完全兼容的HCFS和FUSE支持，大量的数据湖引擎在使用上并不需要增加额外的负担。

总结

行文至此，我们做个回顾和总结。基于数据湖对大数据平台进行架构升级是业界显著趋势，数据湖架构包括湖存储、湖加速和湖分析，在阿里云上我们通过 JindoFS 针对各种场景提供多种数据湖加速解决方案。阿里云推出的专门支持数据湖管理的Data Lake Formation，可全面支持数据湖。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!