数据大集中应该通过应用层实现还是通过基础架构底层技术实现？

数据大集中，应用层实现数据集中的优势是灵活，从实用角度来说，你可以在传输数据前，进行数据的分析，只传输有意义的数据，这样可以减轻网络带宽压力，同时，可以根据个人需求，在数据大集中平台和数据前置平台承担不同的工作任务，分散业务压力；

基础架构层技术的优势是稳定，技术相对成熟，但成本较高，一般采用异步方式。一般都是基于存储的卷来实现，没有自己应用控制那么灵活。

需求决定实现！

如果应用层面折腾来折腾去，最后传输的数据并没有得到精简和定制，只是简单的转发和重写，而且覆盖面很广，那就直接用基础架构的底层技术，进行同步或异步的复制就好了。一种是个性化，灵活度很高的方式，但代价是应用实现相对复杂，一种是底层实现，透明度高，但代价是依赖底层硬件，灵活度也没有那么高。

个人倾向往应用层面发展，毕竟以后数据不是简单的做复制备份，更多的时候还是要进行管理。在应用层面介入，是自主的开始。

如东软的朋友所说，这要看医院客户的实际现状和需求而定。

另外如果应用软件基本采用C/C++，或者JAVA等通用开发环境，是很容易实现统一的服务器环境的。 比如某些医疗软件厂商的应用，就可以将数据库一类服务集中部署在POWER AIX系统中，而前台应用部署在POWER AIX/Linux系统上。

另外从目前的Hadoop等分布式应用的角度来讲，分布式计算的最大系统开销实际上会是随着计算节点增多儿倍增的数据同步开销。也就是说分布节点越少，系统效率越高。这同样也要求计算节点的计算能力越高越好。
  因此，我个人认为，对于医院这类用户来说，计算资源能力越强越好，计算几点越少越好。 这也会同时解决医院IT维护管理资源不足的问题。这方面，PowerAIX + POWER Linux是很好的平台选择。

这个没有具体而严格的规定，主演看你的业务需求，系统现状和投资预算。一般来说，应该先建设低层基础架构，再通过应用层实现。但是如果已经建设好，就需要考虑改造成本。选择成本低又相对容易的方式实现，然后再逐步完善。注意，在改造前要先进行整体的最终的架构设计，然后再分布实施。

数据大集中的实现方案，个人认为应该是根据现有的及未来五年左右的数据量和业务特征进行架构规划设计，设计内容包含基础架构和应用，基础架构应给应用足够的支撑和空间，当然还有综合考虑实施的成本，找到适合自己的才是最重要的。

我认为基础架构是上层应用的支撑，一切底层技术都是为应用服务的。

架构设计还是要遵循由顶自下的设计方式比较好。

非结构化数据，推荐用gpfs，海量存储方案，提供统一命名空间，方便数据存储和查询。