（1）资源浪费
通常在企业内部存在多个不同的技术团队与业务团队。若每个团队搭建各自的大数据集群，服务器资源便会被分割成若干小块而不能发挥合力，服务器资源的整体利用率也无法得到保障，这无疑会造成企业资源的浪费。
其次大数据集群涉及的技术繁杂，搭建和运维需学习和运营成本。这种重复的建设既费力又毫无意义，导致资源无谓浪费。

（2）数据孤岛
若企业内部存在多个分散的小集群，那么业务数据从物理上便被孤立地存储于各小集群中，无法对数据全量的整合使用，数据失去关联的能力，同时也丧失大数据技术使用全量数据进行分析的优势。
其次，在这种情况下也很难实现对业务数据进行统一的模型定义与存储，相同的数据被不同的部门赋予不同的含义，同一份数据以不同的模型定义重复地存储多个集群中，不仅造成存储资源浪费，还增加不同部门间的沟通成本。

（3）服务孤岛
企业内部各小集群的首要任务是支撑团队或项目组的业务场景来满足自身的需求，所以在实现功能时不会以面向服务的思维来抽象提炼服务，很可能都没有暴露供小集群外部使用的服务。就算小集群有提供服务，也缺乏统一的顶层设计，提供的服务参差不齐，其访问入口也不统一。这些服务被分散在不同的集群中，应用程序不能跨多个集群使用所有服务。

（4）安全存疑
企业内部各项目组或团队自身维护的小集群通常都只为支撑自身业务而实现的，不会同时面对多个用户。企业通过一些行政管理手段保障集群的安全。但当团队人员扩充、集群规模扩大或大数据集群的服务同时面向多个技术团队和业务部门时，会显露诸多问题。首当其冲的便是需要面对多用户的问题，集群不再只有一个用户，而是需要面对多个不同的用户，会引出如用户的管理、用户的访问控制、服务的安全控制和数据的授权等问题。

（5）缺乏可维护性和可扩展性
大数据领域的技术发展日新月异，正处于高速发展时期。集群服务有时需更新以获得新的能力，或需要安装补丁以修复Bug。在这种情况下对多个小集群进行维护就会变得非常麻烦。同时当某个小集群性能达到瓶颈时，无法容易地做到横向扩容。

（6）缺乏可复制性
小集群缺乏统一的技术路线，导致大数据集群的运维工作缺乏可复制性。因一个部门或团队与其他部门使用的技术组件不一致，这样一个集群的安装、维护和调试等经验就无法快速复制和推广到其他团队或部门。同时在大数据应用研发方面也会存在同样的问题，从以往的项目中提炼、抽象和总结一些经验、规则或是开发框架来帮助应用研发，但是技术路线的不统一将导致经验丧失指导意义。