内容
带走：
开发人员和工程师需要不断努力，以加速和改善已远远超过其1990年代经典原型的平台上的服务。
关于巨大的NSA数据中心拥有数十亿个有关我们的私人生活的数据比特的嗡嗡声，至少在CNN上还没有被谈论很多。它涉及一个工程问题，该问题随着云技术，大数据和令人印象深刻的物理数据存储中心一起出现，这些中心现在正在全世界范围内建立。那是什么嗯，无论是谁管理运行这些功能的庞大IT系统之一，都需要一种软件系统来帮助所有这些数据快速进出管道。这种需求是当今专业人员面临的最有趣的IT问题或难题之一。
正如许多专家指出的那样，当今对数据处理的极端需求已经远远超出了传统方法。简而言之，使用简单的数据库结构和工具（例如SQL查询接口）不会为过去几年开发的专有系统提供足够的处理能力或功能。当今大型科技公司的档案需要高度可扩展的技术。他们需要可以输入和输出结果的数据处理工具，其数量要比单个服务器所能支持的要大得多。他们需要可以快速增长的解决方案，包括复杂级别的人工智能的解决方案以及旨在由IT部门轻松管理的解决方案。
问题是，公司和政府机构如何克服传统数据处理途径的局限性？这里很好地看一下一个非常有前途的选项：处理大数据和管理多个数据中心的软件。
Google文件系统：大案例研究
Google用于访问其数据中心的专有技术是大数据处理和多数据中心管理的通用模型的最佳示例之一。 Google文件系统（GFS）于2003年开发，旨在支持对数据系统的大量高速修改，这是随着数百万用户点击而将大量新信息传入和传出一个平台的一部分。同一时间。专家将此称为分布式文件系统，并使用术语“数据对象存储”来描述这些高度复杂的技术。但是，实际上，这些术语甚至都无法描述工作原理。
单独来说，组成GFS之类的系统的功能部件可能不再具有突破性，但它们很复杂。在本站点上，其中许多都是相对较新的创新，它们是建立新的，始终在线，始终保持联系的全球IT系统的基础。总的来说，像GFS这样的系统不仅仅是其各个部分的总和：它是一个基本上看不见但非常复杂的网络，充满了以这种方式抛出的单个数据，并且在此过程中，如果在视觉上进行完全建模，则看起来会很混乱。了解这些数据的去向需要大量的精力和精力，因为配备这些系统的战场人员将很容易接受。
“太多细节对可用性领域产生了深远影响，包括外部和内部碎片，基于日志的更新与就地更新以及事务一致性级别，以致于它只能用一个简洁的句子来概括其工作方式”，Sanbolic首席执行官兼联合创始人Momchil Michailov说。
他说：“分布式文件系统要么是参与节点的本地名称空间和可用空间的分布式聚合器，要么是在多个节点上运行的本地文件系统，这些节点借助分布式锁管理器组件访问共享存储。”
Kerry Lebel是Automic的高级产品经理，该公司以其可扩展的自动化平台而闻名。 Lebel表示，虽然将DFS描述为仅将工作负载分配给连接到低成本硬件的服务器的系统是准确的，但这并不能说明全部问题。
没有错误，没有压力-在不破坏生活的情况下创建可改变生活的软件的分步指南
当没有人关心软件质量时，您就无法提高编程技能。
“您最终错过的是 怎么样 他们会做自己想做的事。”勒贝尔说。
当您脱离技术细节而仅考虑分布式文件系统背后的基本思想时，Lebel谈论的“酷因素”显而易见。这些大数据处理系统用不仅涉及多个交付系统，而且涉及“面向对象”方法的结构代替了旧文件/文件夹系统，在该方法中，为了避免瓶颈，四处乱窜大量单元。
例如，想想一个最先进的高速公路系统，成千上万的汽车不仅沿着多车道直奔而下，而且铲成整齐的小三叶草叶或牛弓支流，它们被旋转并发送出去。绕道绕向目的地。从空中看，一切都像瑞士表一样精心编排。这就是工程师在梦想通过将信息“踢”到多层数据包含架构的不同级别来绕过限制路由信息的新方法时所考虑的视觉模型。抛开规范，这是处理系统的顶级目标：将那些包含有嵌入式元数据的独立对象以最快的速度移动到需要的位置，以达到一致性目标，满足最终用户或甚至可以告知高层观察或分析。
核心技术一瞥
肖恩·加拉格尔（Sean Gallagher）的文章发表在Ars Technica上，将GFS设计分解为更易于管理的部分，并暗示了Google工作表的内容。
GFS从用于数据读写的冗余和容错模型开始。这里的想法是，新系统不是将特定的更新写入单个驱动器，而是将数据块写入多个目标。这样，如果一次写入失败，其他的将保留。为了适应这种情况，一个主要的网络组件将数据处理移交给其他从属单元，并在客户端“呼叫”它时重新汇总数据。元数据协议使所有这些成为可能，该元数据协议有助于识别某些更新和传输结果在较大系统中的位置。
另一个非常重要的方面是这些繁重的系统如何执行数据一致性。正如Gallagher指出的那样，GFS设计在保持“原子性”的同时牺牲了一些一致性，或者保护了跨多个存储单元更新数据以随着时间推移进行匹配的原理。 Google的“宽松一致性模型”似乎遵循BASE模型的基本理论，该模型提供了更大的灵活性，以换取更长的时间来实施一致性。
其他大系统如何实现这一目标？
Michailov说：“当达到足够大的规模时，数据的不一致或损坏就变得不可避免。” “因此，分布式文件系统的主要目标应该是能够在存在损坏的情况下执行尽可能多的操作，同时提供有效的方法来同时处理损坏。” Michailov还提到需要通过仔细实施冗余来保持性能。
Michailov说：“例如，在每个磁盘上创建元数据（有关数据的数据）可使该磁盘在镜像副本损坏时重建其正确的数据结构。” “此外，RAID级别可用于解决文件系统聚合器级别或共享卷管理器级别的存储故障。”
在讨论另一个一致性模型时，Lebel着重研究了一个称为Hadoop分布式文件系统（HDFS）的系统，他将其称为“行业实际标准”。
Lebel说，在HDFS中，每个数据块在不同的节点和两个不同的机架上复制了3次。端到端检查数据。失败会报告给NameNode，NameNode是一个数据处理程序，它消除了损坏的块并创建了新的块。
所有这些都支持对这些海量数据系统之一的完整性至关重要的“干净数据”。
维护DFS
关于GFS的另一种截然不同的看法来自有线作家Steven Levy在2012年10月发表的一篇文章。在描述用于Google集体自上而下的网络处理的软件方法时，要简短得多。
Levy写道：“多年来，Google还建立了一个软件系统，使其可以像管理大型实体一样管理无数的服务器。其内部开发人员可以像木偶大师一样行事，分派数千台计算机来执行就像运行一台机器一样容易。”
这样做还涉及大量基于网络的环境维护，从试图“破坏”服务器系统的专用测试团队，到整个数据加密室中受到严格控制的温度。
Levy还提到了GFS的补充技术，例如云应用程序工具MapReduce和与GFS共享一些设计原则的分析引擎Hadoop。这些工具对大数据中心处理系统的设计以及未来可能出现的情况都有自己的影响。 （在“大数据的演变”中了解有关这些技术的更多信息。）
Michailov认为MapReduce有潜力支持更大的数据中心系统，并谈到共享和聚合文件系统的“单一实现”，它可以“将共享文件系统的名称节点保留在带有SSD的共享集群中进行存储” ”。
对于Lebel而言，他看到了从批处理（Hadoop支持的方法）向流处理的转变，这将使这些数据操作更接近实时。
Lebel说：“我们能够更快地处理数据并将其提供给业务决策者或我们的客户，这将带来更大的竞争优势。”勒贝尔还建议将上述处理术语替换为以最终用户。通过考虑“同步”活动，或与最终用户操作同步的活动，以及在实施方面更加灵活的“异步”活动，Lebel说，公司可以使用SLA和其他资源来定义给定服务系统的工作方式。
从某种意义上讲，所有这些归结为，开发人员和工程师需要不断努力，以加速和改善基于远远超出其1990年代经典原型的平台的服务。这意味着必须认真地看待数据机制并突破瓶颈，以不仅支持不断增长的人口，而且以惊人的速度发生的指数变化被专家称为“下一次工业革命”。那些在这些方面发挥最大作用的人最终可能会在未来的市场和经济中占据主导地位。