没错，虽然大型机向来更擅长处理指定的事务型任务，但其同样可以支撑大数据与机器学习等负载类型。事实上，将二者加以结合能够带来相当积极的实际意义。
纽约市的众多历史、商业乃至人文建筑过去几年来可谓饱受摧残。最新的受害者之一正是历史悠久的华尔道夫酒店，其在重新装修后不到一周即告停业，且可能未来三年都不会重新开放。报道称，其中将保留300到500个客房，但建筑本身的大部分面积都将转换为豪华公寓。难道我们没有办法在进行公寓建设的同时，继续保留华尔道夫的传统酒店功能?
答案是肯定的，至少从数据与分析角度来看完全可行。就在上周华尔道夫酒店宣布倒闭的同时，IBM公司恰好在那里举办了一项活动——讽刺的是，蓝色巨人的宣传结论正是新旧工作负载能够有效共存。
正如很多现代客户仍然喜欢下榻华尔道夫酒店，不少企业也在继续将关键性工作负载运行在大型机之上。这主要是考虑到对这些系统进行迁移将带来企业无法承担的风险性与业务中断后果。然而随着新型工作负载的重要性不断提升，大型机供应商应如何解决此类难题?IBM公司给出了自己的解决方案：宣布在Z系列大型机上支持机器学习型工作负载。
Spark入驻大型机
这一举措的意义无需赘言，特别是对于IBM这样一家仍然能够从大型机的销售出阵维护中获得可观营收的企业。不过蓝色巨人提出的观点也同样具有说服力：既然大型机仍然处理着如此众多的事务，那么以此为基础建立数据预测模型无疑将成为任何数字化或者数字化业务转型的必要条件。虽然可以将其中的数据导出至其它更为现代的系统中以进行特征工程、模型构建、测试以及评分，但可以肯定的是数据移动会带来高昂的资金与时间成本，且很有可能与数据安全策略相冲突。
有鉴于此，IBM公司给出了一套混合型方案。首先，其建立一套Linux集群以对来自外部源的数据进行提取、转换、通道性处理并负责支持Jupyter记要工具。在此之后，向其中添加IBM Machine Learning——一套基于大型机的高针对性联合平台，专门用于实现机器学习功能且无需进行数据移动。其采用大型机的zIIP(即System z集成化信息处理器)以实现大型机平台上的商务智能与分析工作负载处理，且不会产生任何MIPS费用。
全部执行操作皆由大型机负责进行，以避免将数据引入其它流程。为了实现这一目标，IBM公司基本上将Apache Spark 1.6移植到了其Z系列平台之上，具体包括Spark MLLib、Spark SQL、Spark Streaming以及GraphX。IBM后续还将引入更多机器学习库，并计划引入TensorFlow等来自开源社区的更多模型与框架。
数据集规模不足
不过需要注意的是，大型机上的数据量往往为GB级别而非TB或者PB级别，这意味着其可能不足以训练出足够精确的分析模型。不过考虑到机器学习技术正快速发展成熟，这应该并不是什么致命的问题——特别是考虑到“数据挖掘”技术原本就是面向较小数据量而设计产生。
事实上，目前我们常用的模型往往采用来自物联网设备的大规模实时活动或者事件驱动型数据作为支持。这些模型拥有相当理想的精度表现，且目前的数据流技术已经能够将其实现。相比之下，大型机机器学习的思路在于立足事务数据建立模型，而事务本身天然存在规模较小这一属性，意味着相关事件由底层活动数据负责支持。客户需要的正是这种基于事务的数据构建模型，因此IBM公司完全有可能让大型机机器学习方案成为现实。另外，由于不需要对数据的粒度细化水平提出过高要求，因此建模、测试与评分等相关流程的计算需求也将有所下降。这意味着此类计算将能够在同一主机上以更短、复杂度更低的方式更轻松地得到实现。
调整、结果与工作强度
当然，IBM公司在数据转换功能方面还需要做出具体调整，从而确保更合理地处理大型机当中密度较低的数据排布状况。另外，Jupyter亦支持R与Python等除Scala之外的语言。数据转换能力将由Rocket Software负责提供，这样的处理方式应该要比IBM全球服务团队自行构建更为科学。随着记事编码支持能力的提升，相信未来蓝色巨人将为用户提供更多可用编程语言选项。
是的，这正是新旧负载的和谐共存之道。对于IBM这样的巨头级供应商，其涵盖市场跨越了多个技术世代，而此次提出的新旧融合无疑极具现实意义。既然微软能够将R语言引入SQL Server，那么IBM公司同样能够将Spark引入大型机。
原文发布时间为：2017年2月27日
本文作者：孙斌
本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。
