面向大数据的实用 DevOps/前言

大约在 2010 年，阿尔卡特-朗讯研发部门负责人向法国国家科研署（简称 ANR）的信息通信科技 (ICT) 科学委员会会议提出了“大数据”这个词。他告诉我们，网络正在以指数级速度传输数据，因此，信息通信科技领域的科学问题必须在持久存在的“大数据”现象的背景下进行完全的重新思考和解决。事实上，网络运营商在日常业务中受到了 IT 客户的困扰，这些客户要求使用新的方法来从数据中创造价值（如果可能的话，要尽早从网络中获取数据！）。如同金块一样，数据包含着“意义”，但是海量数据本身并不能促进理解，也不能在合理的时间尺度内进行智能操作。更糟糕的是，众所周知的存储、格式化、搜索、挖掘或任何其他数据技术都已不再适合“大数据”的需求！

我负责为法国公共和私营部门的资助研究项目定义相关研究方向，起初我对“大”这个形容词持怀疑态度，因为它让我联想到“原始”、“粗粒度”、“非结构化”等概念。例如，虽然每个人都使用“大数据”作为流行语，但很少有人说明“大数据”更恰当的用法：是“大数据”集，TB 级、PB 级、EB 级、ZB 级… 数据集吗？换句话说，哪种平均数据量才算得上是“大数据”？例如，EB 级 (10¹⁵) 或 ZB 级 (10¹⁸) 是“大数据++”集还是普通的“大数据”？

展望未来，并因此询问了使用大规模并行计算基础设施的高性能计算社区，我的感觉是，该社区的假设是所有数据都是可用的，是靠近的，是相当结构化的… 为了夸张地说，所有数据都可以在任何时候存储在高性能内存中！这种云计算的反概念让我失望…

相比之下，询问大规模数据集社区，他们提出了“数据方法”，在这种情况下，当然，数据量是“海量的”（“巨大的”？“大的”？还有什么？）。“海量”（他们选择的名称）和“大数据”中的“大”之间的差异/等价性造成了歧义。我很快明白，他们的方法并不适用，因为他们没有用高性能计算来解决问题：这证明了他们的数据量仍然“不够大”。与这个漏洞相关，关于“数据方法”的假设系统地将 SQL、XML 等作为格式化框架，这往往与“大数据”的现实情况相去甚远！

其他学科（电子商务、能源、健康、可持续性等）帮助我们摆脱了困惑。他们向信息通信科技领域的人员提出挑战，关于他们所在行业不可阻挡的数字化进程，这再次要求重新思考和解决每个行业中系统的设计方式。

通常，在能源领域，智能电网不是配备了硬件和软件进行智能监控和控制的能源分配系统。相反，智能电网是“大数据”处理基础设施，它与现实世界的紧密联系依赖于传感器和执行器。现实世界通过周围的物理基础设施来处理能量。那么，作为一个能源领域的创新系统，智能电网应该如何设计？整个系统的数字组件是核心，因此，它对剩余部分（周围的物理基础设施）的组成方式产生了约束！这种观点让能源工程师不悦，但完美地说明了“大数据”问题如何解决：进步的代价！

事实上，“大数据”作为一门新的科学学科，是商业系统在以前从未见过的规模上的数字化。科学问题既不是计算机科学问题，也不是其他学科中现有的科学问题。解决方案取决于可扩展性问题得到解决的方式：可扩展性是“大数据”问题核心的关键。换句话说，用于“较低”规模（即“可控”数据量）的数据方法或技术在规模增加时就会变得过时。必须发明新的解决方案，包括软件开发方法，这些方法可以有效地从软件（开发工程师、运维工程师）和行业（IT 客户、最终用户等）方面突出协作的跨学科行为。

本书“面向大数据的实用 DevOps”，旨在解决这一目标。作者从经过验证且相关的软件工程范式（即模型驱动工程和 DevOps）入手，展示了欧洲信息通信科技 DICE 项目 (http://www.dice-h2020.eu/) 的成果。DICE 专注于数据密集型应用程序的质量保证。由于“大数据”应用程序强调与 IT 客户/最终用户的紧密合作，采用更多跨学科的方法，因此 DICE 提出了诸如性能和信任之类的关键标准。这些标准驱动着软件的设计和生产发布方式。标准充当早期输入约束或质量合同。作为不可避免的约束，DICE 质疑运行中的应用程序如何处理数据并提供“意义”，同时满足端到端的约束。DICE 方法是基于回环的，包括对生产环境中的应用程序进行监控和控制，以便例如可以将性能异常注入维护周期以保持质量。当然，本书还解释了专用集成工具如何支持这种方法，以在成功的“大数据”世界中取得成功！