大数据时代：存储选择变幻莫测

现在我考虑，假设这些问题中一部分可以解决，这个假设有些托大，你就会发现云提供商会这样说，“我们为国家研究所处理所有关于癌症治疗的诊疗数据。我们已经正确地取出所有病人自身的参考，所有的原始数据都在这儿。”现在如果约翰霍普金斯大学想对他们正在做的新药试验进行大数据分析，这应该是可行的，即作为一种服务，插入数据集并把它包含在分析模型中。这样做是有意义的，因为你已经有了拥有需要这类数据的多个客户。　　

是否我会把自己的数据上传到云中?大概不会。现在不这样做，未来也不会这样做，因为云服务提供商受制于这样一个事实：对于连接到我工场的网络，他无所有权。那他怎么能义正言辞地说能保证我服务质量?对于我访问服务器的途径他有心无力。如果我的电话系统每个月重启上几回，是否拥有一个超稳定的云服务并不重要，我将无法访问它。所以我没法相信任何一个云服务提供商告诉我的。如果数据在云中，我很难相信我的信息是安全的。现在这样的话没啥大问题，如果我采用某种形式的单向散列(IBM的Jonas这样建议的)并去掉数据中的私人信息，我没有什么可担心的。但是对于我的业务流程，这是关键业务，对于我的商业交易、我的财务信息、信用卡信息，无论如何，我可以肯定地说我不打算把它们置于云端。底线：我觉得云有问题，我不确定它把一切都做好了。另外，关于云的使用情况——我最近读到一篇文章提到，投入使用的云增加了340%，不过仅调查了19人。　　

在大数据环境下备份和容灾发生了怎样的变化?　　

Toigo：如果你研究一下Hadoop的模型，会发现它基本上抛弃了你的共享存储，它部署于独立的节点和直连存储形式之上，于是面临一个巨大的问题就是如何对数据进行副本和保护。这是一个重要问题。我们遇到过已使用VMware的客户，因为VMware与传统共享存储无法很好的协作。VMware需要你做的就是，解除您的SAN配置，以直连方式将存储部署到集群中的每个VMware服务器。这就引入了一个问题，你必须依赖后端的副本策略和节点间镜像，而镜像的问题是在于没人做检查。将一个镜像关闭是一件痛苦的事情：使应用进入静默状态，将缓存中的数据刷到磁盘上，并将数据复制到二级镜像，然后关闭整个操作，进行文件级比对，然后交叉手指祈祷好运并进行重启，希望你不会遇到未正常同步的解决能力之外的问题。因此，没有人会去检查镜像。这便是构建在Hadoop架构之上的大数据方案的“阿喀琉斯之踵”。　

现在，我会这样说，使用大数据分析建立模型和监控存储基础设施，我有一大堆的“各种信息”，诸如磁盘的smart技术和各种管理存储组件的基本管理器——实时或主动的关联这些信息并定位问题，实际上我能够避免很多灾难的发生。一方面，我喜欢大数据，因为从更好的灾难恢复的角度来看，可以提供给我更优质的信息和更好的基础设施管理，这样我就可以规避这类风险。另一方面，我不喜欢Hadoop这样的基础设施，因为从数据保护的角度来看，它会把我的生活弄得复杂。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友