Category: AI


Apple Core ML 和 Keras 支持现适用于 Apache MXNet

我们对于 Apache MXNet 版本 0.11 的可用性感到很兴奋。利用此版本,MXNet 在社区发展以及酝酿 Apache 项目方面都达到了重要里程碑。参与者 – 包括来自 Apple、Samsung 和 Microsoft 的开发人员 – 向此版本提交了代码。到目前为止,该项目已有 400 多名参与者。该项目现已将其代码库完全迁移至 Apache,并且已使其首个正式版本成为孵化项目。我们在上一篇博客中讨论了此版本的一些重要功能。本博客文章将简要回顾这些重点内容。

使用 MXNet 模型将机器学习构建到适用于 iOS、macOS、watchOS 和 tvOS 的应用程序中

利用 Apple 在 WWDC 2017 上发布的 Core ML 版本,开发人员现在可以轻松地将机器学习模型集成到其应用程序中,这使得他们只需编写几行代码即可为用户带来智能的新功能。我们已开始了解这些功能 (如增强实境) 将如何改变我们体验周围环境的方式。随着快速发展的 AI 空间中的功能的扩展,开发人员将有权访问新的机器学习模型,这些模型能够开启用于增强体验的新功能。

Apple 已将代码提交至 Apache MXNet 项目,以方便应用程序开发人员使用一流的模型。MXNet 现在与 Core ML 结合在一起,使开发人员能够利用 MXNet 在云中构建和训练机器学习模型,然后将这些模型导入 Xcode 中,以便您能够在应用程序中轻松构建智能的新功能。您可以从适用于各种应用程序的预训练模型的 MXNet Model Zoo 中选择,也可以构建您自己的模型。此版本为您提供一种用于将 MXNet 模型转换为 Core ML 格式的工具 (预览版)。要将 MXNet 模型导入 Apple 的 Core ML 格式中,您将需要安装转换器并运行 Python 命令以转换训练的模型。安装转换器只是执行一条简单命令:

pip install mxnet-to-coreml

按照本教程,了解如何构建由机器学习支持的用于确定图片中地点的地理位置的简单 iOS 应用程序。有关说明以及端到端示例,请访问此 GitHub 存储库

(more…)

使用 AWS EC2 上的 Apache MXNet 和 Multimedia Commons 数据集来估计图像位置

作者:Jaeyoung Choi 和 Kevin Li | 原文链接

这是由国际计算机科学研究院的 Jaeyoung Choi 和加州大学伯克利分校的 Kevin Li 所著的一篇访客文章。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。

当您拍摄照片时,现代移动设备可以自动向图像分配地理坐标。不过,网络上的大多数图像仍缺少该位置元数据。图像定位是估计图像位置并应用位置标签的过程。根据您的数据集大小以及提出问题的方式,分配的位置标签可以是建筑物或地标名称或实际地理坐标 (纬度、经度)。

在本文中,我们会展示如何使用通过 Apache MXNet 创建的预训练模型对图像进行地理分类。我们使用的数据集包含拍摄于全球各地的数百万张 Flickr 图像。我们还会展示如何将结果制成地图以直观地显示结果。

我们的方法

图像定位方法可以分为两类:图像检索搜索法和分类法。(该博文将对这两个类别中最先进的方法进行比较。)

Weyand 等人近期的作品提出图像定位是一个分类问题。在这种方法中,作者将地球表面细分为数千个地理单元格,并利用带地理标记的图像训练了深层神经网路。有关他们的试验更通俗的描述,请参阅该文章

由于作者没有公开他们的训练数据或训练模型 (即 PlaNet),因此我们决定训练我们自己的图像定位器。我们训练模型的场景灵感来自于 Weyand 等人描述的方法,但是我们对几个设置作了改动。

我们在单个 p2.16xlarge 实例上使用 MXNet 来训练我们的模型 LocationNet,该实例包含来自 AWS Multimedia Commons 数据集的带有地理标记的图像。

我们将训练、验证和测试图像分离,以便同一人上传的图像不会出现在多个集合中。我们使用 Google 的 S2 Geometry Library 通过训练数据创建类。该模型经过 12 个训练周期后收敛,完成 p2.16xlarge 实例训练大约花了 9 天时间。GitHub 上提供了采用 Jupyter Notebook 的完整教程

下表对用于训练和测试 LocationNet 和 PlaNet 的设置进行了比较。

LocationNet PlaNet
数据集来源 Multimedia Commons 从网络抓取的图像
训练集 3390 万 9100 万
验证 180 万 3400 万
S2 单元分区 t1=5000, t2=500
→ 15,527 个单元格
t1=10,000, t2=50
→ 26,263 个单元格
模型 ResNet-101 GoogleNet
优化 使用动量和 LR 计划的 SGD Adagrad
训练时间 采用 16 个 NVIDIA K80 GPU (p2.16xlarge EC2 实例) 时为 9 天
12 个训练周期
采用 200 个 CPU 内核时为两个半月
框架 MXNet DistBelief
测试集 Placing Task 2016 测试集 (150 万张 Flickr 图像) 230 万张有地理标记的 Flickr 图像

在推理时,LocationNet 会输出地理单元格间的概率分布。单元格中概率最高的图像的质心地理坐标会被分配为查询图像的地理坐标。

LocationNet 会在 MXNet Model Zoo 中公开分享。

下载 LocationNet

现在下载 LocationNet 预训练模型。LocationNet 已使用 AWS Multimedia Commons 数据集中带地理标记的图像子集进行了训练。Multimedia Commons 数据集包含 3900 多万张图像和 15000 个地理单元格 (类)。

LocationNet 包括两部分:一个包含模型定义的 JSON 文件和一个包含参数的二进制文件。我们从 S3 加载必要的软件包并下载文件。

import os

import urllib

import mxnet as mx

import logging

import numpy as np

from skimage import io, transform

from collections import namedtuple

from math import radians, sin, cos, sqrt, asin

path = 'https://s3.amazonaws.com/mmcommons-tutorial/models/'

model_path = 'models/'

if not os.path.exists(model_path):

os.mkdir(model_path)

urllib.urlretrieve(path+'RN101-5k500-symbol.json', model_path+'RN101-5k500-symbol.json')

urllib.urlretrieve(path+'RN101-5k500-0012.params', model_path+'RN101-5k500-0012.params')

然后,加载下载的模型。如果您没有可用 GPU,请将 mx.gpu() 替换为 mx.cpu():

# Load the pre-trained model

prefix = "models/RN101-5k500"

load_epoch = 12

sym, arg_params, aux_params = mx.model.load_checkpoint(prefix, load_epoch)

mod = mx.mod.Module(symbol=sym, context=mx.gpu())

mod.bind([('data', (1,3,224,224))], for_training=False)
mod.set_params(arg_params, aux_params, allow_missing=True)

grids.txt 文件包含用于训练模型的地理单元格。

第 i 行是第 i 个类,列分别代表:S2 单元格标记、纬度和经度。我们将标签加载到名为 grids 的列表中。

# Download and load grids file

urllib.urlretrieve('https://raw.githubusercontent.com/multimedia-berkeley/tutorials/master/grids.txt','grids.txt')

# Load labels.

grids = []

with open('grids.txt', 'r') as f:

for line in f:

line = line.strip().split('\t')

lat = float(line[1])

lng = float(line[2])

grids.append((lat, lng))

该模型使用半径公式来测量点 p1 和 p2 之间的大圆弧距离,以千米为单位:

def distance(p1, p2):

R = 6371 # Earth radius in km

lat1, lng1, lat2, lng2 = map(radians, (p1[0], p1[1], p2[0], p2[1]))

dlat = lat2 - lat1

dlng = lng2 - lng1

a = sin(dlat * 0.5) ** 2 + cos(lat1) * cos(lat2) * (sin(dlng * 0.5) ** 2)
return 2 * R * asin(sqrt(a))

在将图像提供给深度学习网络之前,该模型会通过裁剪以及减去均值来预处理图像:

# mean image for preprocessing

mean_rgb = np.array([123.68, 116.779, 103.939])

mean_rgb = mean_rgb.reshape((3, 1, 1))


def PreprocessImage(path, show_img=False):

# load image.

img = io.imread(path)

# We crop image from center to get size 224x224.

short_side = min(img.shape[:2])

yy = int((img.shape[0] - short_side) / 2)

xx = int((img.shape[1] - short_side) / 2)

crop_img = img[yy : yy + short_side, xx : xx + short_side]

resized_img = transform.resize(crop_img, (224,224))

if show_img:

io.imshow(resized_img)

# convert to numpy.ndarray

sample = np.asarray(resized_img) * 256

# swap axes to make image from (224, 224, 3) to (3, 224, 224)

sample = np.swapaxes(sample, 0, 2)

sample = np.swapaxes(sample, 1, 2)

# sub mean

normed_img = sample - mean_rgb

normed_img = normed_img.reshape((1, 3, 224, 224))
return [mx.nd.array(normed_img)]

评估并比较模型

为了进行评估,我们使用两个数据集:IM2GPS 数据集和 Flickr 图像测试数据集,后者用于 MediaEval Placing 2016 基准测试

IM2GPS 测试集结果

以下值表示 IM2GPS 测试集中正确位于与实际位置的每个距离内的图像的百分比。


Flickr 图像结果

由于 PlaNet 中使用的测试集图像尚未公开发布,因此不能直接比较这些结果。这些值表示测试集中正确位于与实际位置的每个距离内的图像的百分比。


通过目测检查定位图像,我们可以看到该模型不仅在地标位置方面表现出色,而且也能准确定位非标志性场景。

使用 URL 估算图像的地理位置

现在我们试着用 URL 对网页上的图像进行定位。

Batch = namedtuple('Batch', ['data'])

def predict(imgurl, prefix='images/'):

download_url(imgurl, prefix)

imgname = imgurl.split('/')[-1]

batch = PreprocessImage(prefix + imgname, True)

#predict and show top 5 results

mod.forward(Batch(batch), is_train=False)

prob = mod.get_outputs()[0].asnumpy()[0]

pred = np.argsort(prob)[::-1]

result = list()

for i in range(5):

pred_loc = grids[int(pred[i])]

res = (i+1, prob[pred[i]], pred_loc)

print('rank=%d, prob=%f, lat=%s, lng=%s' \

% (i+1, prob[pred[i]], pred_loc[0], pred_loc[1]))

result.append(res[2])

return result


def download_url(imgurl, img_directory):

if not os.path.exists(img_directory):

os.mkdir(img_directory)

imgname = imgurl.split('/')[-1]

filepath = os.path.join(img_directory, imgname)

if not os.path.exists(filepath):

filepath, _ = urllib.urlretrieve(imgurl, filepath)

statinfo = os.stat(filepath)

print('Succesfully downloaded', imgname, statinfo.st_size, 'bytes.')
return filepath

来看看我们的模型如何处理东京塔图片。以下代码从 URL 下载图像,并输出模型的位置预测。

#download and predict geo-location of an image of Tokyo Tower

url = 'https://farm5.staticflickr.com/4275/34103081894_f7c9bfa86c_k_d.jpg'
result = predict(url)

结果列出了置信度分数 (概率) 排在前五位的输出以及地理坐标:

rank=1, prob=0.139923, lat=35.6599344486, lng=139.728919109

rank=2, prob=0.095210, lat=35.6546613641, lng=139.745685815

rank=3, prob=0.042224, lat=35.7098435803, lng=139.810458528

rank=4, prob=0.032602, lat=35.6641725688, lng=139.746648114

rank=5, prob=0.023119, lat=35.6901996892, lng=139.692857396

仅通过原始纬度和经度值,很难判断地理位置输出的质量。我们可以通过将输出制成地图来直观地显示结果。

在 Jupyter Notebook 上使用 Google Maps 直观显示结果

为了直观地显示预测结果,我们可以在 Jupyter Notebook 中使用 Google Maps。它让您能够看到预测是否有意义。我们使用一个名为 gmaps 的插件,它允许我们在 Jupyter Notebook 中使用 Google Maps。要安装 gmaps,请按照 gmaps GitHub 页面上的安装说明操作。

使用 gmaps 直观显示结果只需几行代码。请在您的 Notebook 输入以下内容:

import gmaps


gmaps.configure(api_key="") # Fill in with your API key


fig = gmaps.figure()


for i in range(len(result)):

marker = gmaps.marker_layer([result[i]], label=str(i+1))

fig.add_layer(marker)

fig

事实上,排在第一位的定位估算结果就是东京塔所在的位置。

现在,试着对您选择的图像进行定位吧!

鸣谢

在 AWS 上训练 LocationNet 的工作得到了 AWS 研究与教育计划的大力支持。我们还要感谢 AWS 公共数据集计划托管 Multimedia Commons 数据集以供公众使用。我们的工作也得到了劳伦斯·利弗莫尔国家实验室领导的合作 LDRD 的部分支持 (美国能源部合同 DE-AC52-07NA27344)。

 

使用 Apache MXNet 对基于 CNN 的检测器的训练时间进行基准测试

作者:Iris Fu 和 Cambron Carter

这是一篇由工程总监 Cambron Carter 和 GumGum 的计算机视觉科学家 Iris Fu 联合发布的访客文章。用他们自己的话说,“GumGum 是一家在计算机视觉领域具有深厚专业知识的人工智能公司,能帮助客户充分发挥网络、社交媒体及广播电视每天生产的图像和视频的价值。”

目标物检测的最新技术 

检测是许多经典计算机视觉问题之一,已随着卷积神经网络 (CNN) 的采用而得到显著改善。随着 CNN 越来越多地用于图像分类,许多人都依靠粗糙和昂贵的预处理程序来生成候选区域 (region proposal)。通过诸如“选择性搜索”之类的算法根据区域的“客体性”(它们包含目标物的可能性) 生成候选区域,这些区域随后被馈送到训练用于分类的 CNN。虽然这种方法能得到准确结果,但需要很高的运行成本。Faster R-CNN,You Only Look Once (YOLO) 和 Single Shot MultiBox Detector (SSD) 等 CNN 架构通过将定位任务嵌入到网络中来折中解决该问题。

除了预测等级和置信度,这些 CNN 还尝试预测包含某些目标物的区域极值。在本文中,这些极值只是矩形的四个角点,通常称为边界框。先前提到的检测架构需要已经用边界框注释的训练数据,即,该图像包含一个人,而且此人在该矩形区域内。以下是分类训练数据和检测训练数据:

超级帅气又非常能干的工程师

我们开始对使用 Apache MXNet 和 Caffe 来训练 SSD 的体验进行比较。明显动机是以分布式方式训练这些新架构,而不降低准确性。有关架构的更多信息,请参阅“SSD: Single Shot MultiBox Detector”

训练工具 

对于这组实验,我们尝试了几款 NVIDIA GPU:Titan X、1080、K80 和 K520。我们使用 Titan X 和 1080 在内部进行了几次实验,但也使用了基于 AWS GPU 的 EC2 实例。此帖子仅限于 g2.2x 和 p2.8x 实例类型。幸运的是,我们已经有一些使用 MXNet 的可用 SSD 实施方案,例如这个,在此次讨论的实验中我们就使用了这个实施方案。值得注意的是,为了使实验更详尽,您应该将其他常见框架 (如 TensorFlow) 的基准测试数据也包含在内。

速度:使用 MXNet 调整批处理大小和 GPU 计数的影响

首先,我们来看看使用 MXNet 的多 GPU 训练会话的性能影响。前几个实验侧重于在 EC2 实例上使用 MXNet 对 SSD 进行训练。我们使用 PASCAL VOC 2012 数据集。这第一个练习的目的是了解 GPU 计数和批处理大小对特定 GPU 速度的影响。我们使用了几种不同的 GPU 来说明它们的绝对性能差异。如果您想进一步探索,还可了解有关不同 GPU 的价格和性能的许多信息。让我们从 g2.2x 实例附带的 K520 开始:


请注意,在批处理大小不变的情况下,添加额外的 g2.2x 实例 (每个实例一个 K520) 会使每台机器有大致恒定的速度。因此,每小时的训练周期数几乎呈线性增加。添加机器应该能继续缩短运行时间,但在某一点上可能会影响准确性。我们不在此处探讨这种情况,但需要提一下。

然后,我们想看看在本地 1080 上是否观察到这一趋势:

如预期的一样,一个 1080 轻松胜过五个 K520。除了发现的这个情况外,该实验也引起了一些人的质疑。我们发现在组合中再加入一个 1080 时,每个 GPU 的速度会大大降低。由于本实验中的进程间通信通过以太网进行,因此一开始我们认为自己受到了办公网络的限制。但根据 Iperf 数据,该假设并不成立:

我们的测试表明,我们办公网络中的带宽和传输量都高于两个 EC2 实例之间的这两个值。这就引出了我们的下一个问题:如果批处理大小是导致效率低下的原因怎么办?

啊哈!虽然仍比使用一个 1080 慢得多,但在增加一个 1080 (在单独的机器上) 的同时增加批处理大小可提高速度。我们来看一下训练对具有多个互连 GPU 的机器的影响:


我们使用了自己的内部 NVIDIA DevBox,其中包含四个 Titan X。保持批处理大小不变,但增加 GPU 数量 (技术上减少每个 GPU 的单个批处理大小),可将速度提高大约 2.5 倍!这就引出了一个显而易见的问题:如果我们增加每个 GPU 的批处理大小会怎样?

我们观察到,当我们保持批处理大小恒定 (16),并增加同一机器上的 GPU 数量时,最终速度也会提高大约 2 倍。我们本想进一步探索,但 DevBox 风扇嗡嗡作响,让我们无法再增加批处理大小。我们 1080 实验的奇案仍然无解,作为一个悬而未决的问题而为人所知。AWS 的潜在解决方案可能是使用放置组,在本文中我们不探讨此方案。

准确性:使用 MXNet 调整批处理大小的影响

由于我们花那么精力来调整批处理大小,因此值得探讨一下调整批处理大小如何影响准确性。目标很简单:我们希望在保持准确性的同时尽可能地缩短训练时间。我们在用于徽标检测的内部数据集中进行了这组实验。我们使用 MXNet 在一个 p2.8x large 实例上开展这些实验。如果检测区域和地面实测区域之间的交并比为 20% 或更高,则我们认为检测是正确的。首先,我们尝试了批处理大小 8:

训练的三个不同阶段的查准率查全率曲线。SSD 使用 300×300 像素的输入尺寸,批处理大小为 8。

如果我们同等地对查准率和查全率进行加权,就会得到大约 65% 的查准率和查全率。让我们看看使用 MXNet 调整 SSD 中的输入尺寸时会发生什么:

SSD 使用的输入尺寸为 512×512 像素,其他所有数据均与上一个实验相同。

此时,我们实际上看到性能有所改善,查准率和查全率均为 70% 左右。输入尺寸仍为 512×512 像素,我们来研究一下调整批处理大小对准确性有何影响。同样,我们的目标是保持准确性,同时尽可能缩短运行时间。

SSD 使用的输入尺寸为 512×512 像素,批处理大小为 64。准确性与之前的实验不差上下。

再试一次!准确性保持一致,我们可以通过更大的批处理大小来缩短训练时间,从而从中获益。本着科学的精神,让我们进一步深入实验…

SSD 使用的输入尺寸为 512×512 像素,批处理大小为 192。准确性与之前的实验不差上下。

基本相同,虽然我们的操作准确性与上一曲线相比有所下降。尽管如此,我们成功地保持了准确性,同时将批处理大小增加了 24 倍。重申一下,每个实验都是使用 MXNet 在实施了 SSD 的 p2.8x large 实例上进行的。下面是批处理大小实验的总结,显示了各个实验不差上下的准确性:

MXNet 的 SSD 与使用 Caffe 训练的 SSD 一样准确。

要点是准确性不差上下。言归正传,我们来研究一下训练时间:

使用多种批处理大小的 Caffe 和 MXNet 的训练时间汇总。

当批处理大小增加时,预计减少的训练时间是显而易见的。不过,为什么我们在 Caffe 中增加批处理大小时,训练时间会大幅增加?我们来看看这两个 Caffe 实验的 nvidia-smi:

使用 Caffe 训练时 nvidia-smi 的输出,使用的批处理大小 8。请注意 GPU 使用率的波动。

GPU 要处理反向传播的巨大计算开销,这通过使用率峰值反应出来。为什么使用率会波动?可能是因为需要将训练数据从 CPU 批量传输到 GPU。在这种情况下,当 GPU 等待下一个批处理加载时,使用率将下降为 0%。我们来看看将批处理大小增加为 16 后的使用率:

使用 Caffe 训练时 nvidia-smi 的输出,使用的批处理大小 16。

使用率停滞的情况更为夸张,揭示出显而易见的低效率。这解释了为什么增加批处理大小后训练时间反而增加的现象。这并不新鲜或出乎意料。事实上,我们使用 Keras (和 TensorFlow 后端) 训练 Siamese-VGG 网络时,也遇到过这个问题。关于这个话题的讨论通常倾向于“您的模型越复杂,您能感知到的 CPU 到 GPU 的瓶颈就越少。”虽然这是事实,但并没有多大帮助。是的,如果您通过增加计算梯度的方式让 GPU 承担更多工作,一定会看到平均 GPU 利用率的增加。我们不想增加模型的复杂性,即使我们这样做了,也不是为了帮助我们实现总体目标。在这里,我们关注的是绝对运行时间,而不是相对运行时间。

如果对我们的实验加以总结,那就是使用 Caffe 的 SSD 训练时间远远多于使用 MXNet 的训练时间。使用 MXNet,我们观察到训练时间稳步减少,直至我们达到 192 这一批处理大小临界规模。仅通过采用 MXNet,我们就将训练时间从 21.5 小时缩短为 4.6 小时。与此同时我们没有发现准确性有所降低。这么说绝不是在攻击 Caffe – 它是我们非常看重的一个框架 – 而只是为了庆祝 MXNet 取得的成功。我们可以通过多种方式批评数据加载问题。也许 Caffe2 已经解决了这个问题。在这里我想说明的是我们并不需要这么做,如果有任何东西能够让机器学习开发人员感到暖心,那就是编写尽可能少的代码。虽然我们还有一些问题尚未得到解答,但这是采用新工具时的正常现象。我们很乐意被当做“实验豚鼠”,并且对 MXNet 的未来充满希望。

 

通过机器学习自动优化 DBMS

本客座文章由卡内基梅隆大学的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 发布。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。点击:原文链接

数据库管理系统 (DBMS) 是所有数据密集型应用程序最重要的组成部分。它们可以处理大量数据和复杂工作负载。但它们拥有成百上千的配置“开关”,控制了诸如用于缓存的内存量以及将数据写入存储的频率等诸多因素,因此管理起来很困难。组织通常会聘请专家来帮助完成优化活动,但对许多组织来说专家的费用过于高昂。

卡内基梅隆大学数据库研究组的学生和研究人员开发了一款新工具 OtterTune,它可以针对 DBMS 配置开关自动查找较佳的设置。其目标是让每个人都可以轻松部署 DBMS,即使是毫无数据库管理专业知识的人。

与其他 DBMS 配置工具不同,OtterTune 利用在优化之前的 DBMS 部署期间获得的知识来优化新的部署。这可以显著缩短优化新 DBMS 部署所需的时间以及减少所需的资源。为此,OtterTune 维护了一个存储库,用于存储在之前的优化会话中收集的优化数据。它利用此类数据来构建机器学习 (ML) 模型,以捕获 DBMS 对不同配置的响应方式。OtterTune 使用这些模型来指导新应用程序的试验,进而推荐可改善最终目标 (例如,减少延迟或提高吞吐量) 的设置。

在本文中,我们将讨论 OtterTune ML 管道中的每一个组件,并演示这些组件如何彼此交互以优化 DBMS 配置。然后,我们将通过比较 OtterTune 推荐的最佳配置与数据库管理员 (DBA) 及其他自动优化工具选择的配置的性能,评估 OtterTune 对 MySQL 和 Postgres 的优化效力。

OtterTune 是一款开源工具,由卡内基梅隆大学数据库研究组的学生和研究人员开发。GitHub 上提供了所有代码,并且代码已获得 Apache 2.0 许可。

OtterTune 工作原理

下图显示了 OtterTune 的组件和工作流。

在新的优化会话开始时,用户须告知 OtterTune 要优化的最终目标 (例如,延迟或吞吐量)。客户端控制器连接到目标 DBMS,并收集其 Amazon EC2 实例类型和当前配置。

然后,控制器开始第一个观察期,观察 DBMS 并记录最终目标。该观察期结束后,控制器收集 DBMS 中的内部指标,例如,MySQL 从磁盘读取的页数以及写入磁盘的页数。控制器向优化管理器返回最终目标和内部指标。

OtterTune 的优化管理器收到指标时,将指标存储在存储库中。OtterTune 根据结果计算控制器应在目标 DBMS 上安装的下一个配置。优化管理器向控制器返回此配置,并估计优化此配置能够获得的预期改进。用户可以决定是继续还是终止优化会话。

备注

OtterTune 维护其支持的各 DBMS 版本的开关黑名单。该黑名单中包含无优化意义的开关 (例如,DBMS 存储文件的路径名称),或者可能导致严重或隐藏后果 (例如,可能导致 DBMS 丢失数据) 的开关。每个优化会话开始时,OtterTune 会向用户提供该黑名单,让用户添加他们不希望 OtterTune 优化的任何其他开关。

OtterTune 做出了一些假设,这些假设可能会限制其对某些用户的有用程度。例如,它假设用户拥有管理权限,允许控制器修改 DBMS 的配置。如果用户不具备该权限,则可以在其他硬件上部署另外一份数据库,用于进行 OtterTune 优化试验。这要求用户重播工作负载跟踪或转发来自生产 DBMS 的查询。有关假设和限制的完整讨论,请参阅我们的文章

机器学习管道

下图显示了在数据流过 OtterTune 的 ML 管道时如何得到处理。所有观察结果都保存在 OtterTune 的存储库中。

OtterTune 先将观察结果传入 Workload Characterization 组件。此组件确定能够最准确地捕获不同工作负载的性能差异和显著特点的一小部分 DBMS 指标。

接下来,Knob Identification 组件生成对 DBMS 性能影响最大的开关的排序列表。OtterTune 随后将所有此类信息馈送到 Automatic Tuner。此组件将目标 DBMS 工作负载映射到其数据存储库中最相似的工作负载,并再次使用此工作负载数据生成更好的配置。

我们来详细讨论一下 ML 管道中的每个组件。

Workload Characterization: OtterTune 使用 DBMS 的内部运行时指标来确定工作负载行为方式的特征。这些指标准确代表了工作负载,因为它们捕获了其运行时行为的许多方面。不过,许多指标都是多余的:一些指标其实是相同的,只是单位不同;还有一些指标表示 DBMS 的各独立组件,但它们的值高度相关。必须清除多余的指标,这可以降低使用这些指标的 ML 模型的复杂性。为此,我们基于 DBMS 指标的关联模式将它们集群化。然后,我们从每个集群中选择一个具有代表性的指标,具体而言就是最接近集群中心的指标。ML 管道中的后续组件会使用这些指标。

Knob Identification:DBMS 可能拥有数以百计的开关,但只有一小部分能够影响 DBMS 的性能。OtterTune 利用常用的功能选取技术 (称为 Lasso) 来确定严重影响系统整体性能的开关。通过向存储库中的数据应用此项技术,OtterTune 可以确定 DBMS 开关的重要性顺序。

然后,在提供配置建议时,OtterTune 必须决定使用多少个开关。使用过多开关会明显增加 OtterTune 的优化时间。使用过少开关则会导致 OtterTune 找不到最佳配置。为了自动完成此流程,OtterTune 使用一种增量方法。这种方法逐渐增加优化会话中使用的开关数。使用这种方法,OtterTune 可以先针对一小部分最重要的开关探究并优化配置,然后再扩展范围,考虑其他开关。

Automatic Tuner:Automated Tuning 组件在每个观察期后执行两步分析,确定 OtterTune 应该推荐的配置。

首先,系统使用在 Workload Characterization 组件中确定的指标的性能数据,来确定上一个优化会话中最能代表目标 DBMS 工作负载的工作负载。它将会话的指标与之前工作负载的指标进行比较,确定对不同开关设置做出相同反应的指标。

然后,OtterTune 选择另一个开关配置进行尝试。它会根据收集的数据以及存储库中最相似工作负载的数据,调整统计模型。使用此模型,OtterTune 可以预测 DBMS 在每个可能配置下的性能。OtterTune 优化下一个配置,换探索为利用,从收集信息以改善模型变为不断尝试在目标指标上做得更好。

实现

OtterTune 是用 Python 编写的。

对 Workload Characterization 和 Knob Identification 组件而言,运行时性能并不是主要考虑因素,因此我们使用 scikit-learn 来实现对应的 ML 算法。这些算法在后台进程中运行,从而在 OtterTune 存储库中有新数据可用时纳入这些数据。

而对于 Automatic Tuner,ML 算法是关键。它们在每个观察期之后运行,从而纳入新数据,以便 OtterTune 能够选取下一次尝试的开关配置。由于要考虑性能,我们使用 TensorFlow 来实现这些算法。

为了收集有关 DBMS 硬件、开关配置和运行时性能指标的数据,我们将 OtterTune 的控制器与 OLTP-Bench 基准测试框架集成在了一起。

试验设计

为进行评估,我们比较了使用 OtterTune 选择的最佳配置与使用以下配置的 MySQL 和 Postgres 的性能:

  • 默认:DBMS 提供的配置
  • 优化脚本:开源优化顾问工具生成的配置
  • DBA:DBA 选择的配置
  • RDS:由 Amazon RD 管理并部署在相同 EC2 实例类型上的 DBMS 的自定义配置

我们在 Amazon EC2 竞价型实例上进行了所有试验。我们在两个实例上运行了每个试验:一个针对 OtterTune 控制器,另一个针对目标 DBMS 部署。我们分别使用了 m4.large 和 m3.xlarge 实例类型。我们在配备 20 个内核和 128 GB RAM 的本地计算机上部署了 OtterTune 的优化管理器和数据存储库。

我们使用了 TPC-C 工作负载,它是评估联机事务处理 (OLTP) 系统性能的行业标准。

评估

对于我们在试验中使用的每个数据库 (MySQL 和 Postgres),我们测量了延迟和吞吐量。下图显示了结果。第一张图显示 99% 的延迟,表示最坏情况下完成事务的时间。第二张图显示吞吐量结果,以每秒完成的平均事务数衡量。

MySQL 结果

比较 OtterTune 生成的最佳配置与优化脚本和 RDS 生成的配置后发现,使用 OtterTune 配置,MySQL 的延迟减少了大约 60%,吞吐量提高了 22%-35%。OtterTune 还生成了几乎与 DBA 选择的配置一样出色的配置。

只有少数几个 MySQL 开关显著影响 TPC-C 工作负载的性能。OtterTune 和 DBA 生成的配置为每个这些开关提供了理想的设置。RDS 的表现稍差一些,因为它为一个开关提供了次优的设置。优化脚本的配置效果最差,因为它只修改了一个开关。

Postgres 结果

在延迟方面,与 Postgres 的默认设置相比,优化工具 OtterTune、DBA 和 RDS 生成的配置全都获得了类似的改善。我们或许可以把这些改善归功于 OLTP-Bench 客户端与 DBMS 之间的网络往返行程所需的开销。在吞吐量方面,与 DBA 和优化脚本选择的配置相比,OtterTune 建议的配置使 Postgres 的吞吐量提高了大约 12%,与 RDS 相比,提高了大约 32%。

与 MySQL 类似,只有少数几个开关显著影响 Postgres 的性能。OtterTune、DBA、优化脚本以及 RDS 生成的配置全都修改了这些开关,并且大部分提供了非常理想的设置。

结论

OtterTune 可自动完成为 DBMS 的配置开关寻找理想设置的过程。为优化新的 DBMS 部署,它会再次使用之前优化会话中收集的训练数据。由于 OtterTune 不需要生成初始数据集即可训练其 ML 模型,因此优化时间明显缩短。

接下来做什么?为适应 DBaaS 部署 (无法远程访问 DBMS 主机计算机) 的日益普及,OtterTune 将很快能够在无需远程访问的情况下,自动检测目标 DBMS 的硬件功能。

有关 OtterTune 的更多详细信息,请参阅我们的文章或 GitHub 上的代码。请密切关注本网站,我们即将在网站中提供 OtterTune 作为联机优化服务。
作者简介

Dana Van Aken 是卡内基梅隆大学计算机科学系的博士生,由 Andrew Pavlo 博士指导。她的主要研究课题是数据库管理系统。她目前的工作重点是开发自动化技术以使用机器学习来优化数据库管理系统。

Andy Pavlo 博士是卡内基梅隆大学计算机科学系数据库学科的助理教授,也是卡内基梅隆大学数据库研究组和并行数据实验室的一名成员。他的工作还需要与英特尔大数据科技中心协作。

Geoff Gordon 博士是卡内基梅隆大学机器学习系的副教授兼副教导主任。他的研究课题包括人工智能、统计机器学习、教育数据、游戏理论、多机器人系统,以及概率域、对立域和常规求和域的规划。

 

本文首发于亚马逊AWS官方博客网站,原创文章如转载,请注明出处。