hdfs 文件服务器设计以及优化

问题遇到的现象和发生背景

背景：公司是工业领域，公司想要自己搭建一套公司的私有云服务器，目的是模仿OSS，本low逼，采用hadoop hdfs 作为公司文件存储服务器，后期将使用大量的工程算法计算，所以采用了这套大数据框架。
问题遇到的现象:
1.公司开发了一套系统，spring boot +java hdfs api，作为文件服务器上传文件和下载文件，可是针对于文件上传和下载，本low逼只能，通过hdfs client 不断的情况 hdfs 服务器，进行文件的读取操作。
思路图如下：

用代码块功能插入代码，请勿粘贴截图

img

运行结果及报错内容

现有情况是这么个样子，很恶心的事情就是文件的上传 或者工业文件3D文件动不动都是好几个G，在上传的方式我采用的是分片上传,最后通知后台合并，合并文件是非常消耗时间的，合并完成以后，还需要将合并完成的文件通过hdfs api 上传的hdfs 中，这个期间 非常恶心（前台的响应非常慢,体验不是很足）。
问题：

  1. 合并文件是非常消耗时间的，合并完成以后，还需要将合并完成的文件通过hdfs api 上传的hdfs 中
  2. 既然有上传，那么就有下载，下载的时候还是需要通过hdfs 不间断的 IO读取流HDFS里面的文件，是通过程序Api内置的 FsDataIputstream和outPut应用读取的
  3. 期间有想过将内置的web hdfs 开放映射出去，但是考虑到20年的漏洞事件，以及本low 技术有限，没有将hdfs做kerberos 权限控制 ，只做了简单的simple模式，一旦内行懂得 ，可以直接通过地址 做hdfs api操作，我的文件服务器就整个蹦掉。
    我想要达到的结果
    我想要解决合并以后的缓冲起，查过资料，期初通过多线程去写入文件，但是hdfs 的缺陷就是不允许多线程去读取文件，就很头皮发麻，如果可以做到跟oss一样 或者七牛云一样 上次文件以后，直接返回了文件访问的地址，不需要我后天应用程序去处理任何东西，那是真的节省开销
    我的解答思路和尝试过的方法

留言一下，关注一下你这问题。运维领域的我最多只能从系统层面上做优化，
但看你情况，涉及代码逻辑上的处理各种，
我也好奇你这情况。

第三条如果keberos可以解决，建议直接配置keberos，这个百度下，很多案例，没有任何操作难度

你们是才起步，还是正往这方面转