推荐最新

为什么安装 cuda_12.2.2_535.104.05_linux.run 之后，还是没有 nvcc 命令？

我的机器是 nvidia T4 GPU + ubuntu22.04 我先通过下面的命令安装驱动 sudo apt install -y nvidia-driver-535-server 等电脑重启好了，输入 "nvidia-smi" 查看显卡信息 ╰─➤ nvidia-smi 130 ↵ Mon Sep 18 14:30:16 2023 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 535.54.03 Driver Version: 535.54.03 CUDA Version: 12.2 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 Tesla T4 Off | 00000000:AF:00.0 Off | 0 | | N/A 47C P0 27W / 70W | 2MiB / 15360MiB | 6% Default | | | | N/A | +-----------------------------------------+----------------------+----------------------+ 然后在 "https://developer.nvidia.com/cuda-downloads?target_os=Linux&t..." (https://link.segmentfault.com/?enc=3lX4HpTDwbVmYUepMwiEig%3D%3D.hVEvpxzxrZ5nbln27HtjYX%2FZgdAL9yh2fVEKf%2BzBsut2FoxAl2GIprcrELn%2BXB3k4tuTTUNgH4yajNzLt5aX7MPvOenGOadnQHI0WBRAFLmmG6vebB5O0RH%2BJQ6JGCmbZ8nOl2AYWSzYeYL1qUJqUZfS29AFy55ZR5t1WOE1DY7jLNViJlaGZUKzxbx8L4omQCX1vFuTS5EcMlgK8i5cwQ%3D%3D) 下面 CUDA Toolkit 12.2 "图片.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/images/20241227/df6ec5e1bab5f00a3335f3e1a32d40fb.png) ╭─pon@T4GPU ~/Downloads ╰─➤ sudo sh cuda_12.2.2_535.104.05_linux.run [sudo] password for pon: 安装之后，还是没有 nvcc ╭─pon@T4GPU ~/Downloads ╰─➤ nvcc --version 127 ↵ zsh: command not found: nvcc ╭─pon@T4GPU ~/Downloads ╰─➤ cd / 127 ↵ ╭─pon@T4GPU / ╰─➤ fd -a -u nvcc /usr/share/cmake-3.22/Modules/FindCUDA/run_nvcc.cmake 我的期望是，安装这个 CUDA Toolkit 之后，就有 nvcc 命令

浏览量420

秋叶无缘

Python数据可视化大杀器之天阶技法：Seaborn（学完可实现90%数据分析绘图）

Python数据可视化python数据可视化大杀器之Seaborn详解一张好的图胜过一千个字，一个好的数据分析师必须学会用图说话。python作为数据分析最常用的工具之一，它的可视化功能也很强大，matplotlib和seaborn库使得绘图变得更加简单。本章主要介绍一下Searborn绘图。学过matplotlib的小伙伴们一定被各种参数弄得迷糊，而seaborn则避免了这些问题，废话少说，我们来看看seaborn具体是怎样使用的。Seaborn中概况起来可以分为五大类图1.关系类绘图2.分类型绘图3.分布图4.回归图5.矩阵图接下来我们一一讲解这些图形的应用，首先我们要导入一下基本的库%matplotlib inline # 如果不添加这句，是无法直接在jupyter里看到图的 import seaborn as sns import numpy as np import pandas as pd import matplotlib.pyplot as plt如果上面报错的话需要安装相应的包pip install seaborn pip install numpy pip install pandas pip install matplotlib我们可以使用set()设置一下seaborn的主题，一共有:darkgrid,whitegrid,dark,white，ticks，大家可以根据自己的喜好设置相应的主题，默认是darkgrid。我这里就设置darkgrid风格sns.set(style="darkgrid")接下来导入我们需要的数据集，seaborn和R语言ggplot2（感兴趣欢迎阅读我的R语言ggplot2专栏）一样有许多自带的样例数据集# 导入anscombe数据集 df = sns.load_dataset('anscombe') # 观察一下数据集形式 df.head().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } datasetxy0I10.08.041I8.06.952I13.07.583I9.08.814I11.08.331.关系图1.1 lineplot绘制线段seaborn里的lineplot函数所传数据必须为一个pandas数组，这一点跟matplotlib里有较大区别，并且一开始使用较为复杂，sns.lineplot里有几个参数值得注意。x: plot图的x轴labely: plot图的y轴labelci: 置信区间data: 所传入的pandas数组绘制时间序列图# 导入数据集 fmri = sns.load_dataset("fmri") # 绘制不同地区不同时间 x和y的线性关系图 sns.lineplot(x="timepoint", y="signal", hue="region", style="event", data=fmri)<AxesSubplot:xlabel='timepoint', ylabel='signal'>rs = np.random.RandomState(365) values = rs.randn(365, 4).cumsum(axis=0) dates = pd.date_range("1 1 2016", periods=365, freq="D") data = pd.DataFrame(values, dates, columns=["A", "B", "C", "D"]) data = data.rolling(7).mean() sns.lineplot(data=data, palette="tab10", linewidth=2.5)<AxesSubplot:>1.2 relplot这是一个图形级别的函数，它用散点图和线图两种常用的手段来表现统计关系。# 导入数据集 dots = sns.load_dataset("dots") sns.relplot(x="time", y="firing_rate", hue="coherence", size="choice", col="align", size_order=["T1", "T2"], height=5, aspect=.75, facet_kws=dict(sharex=False), kind="line", legend="full", data=dots)<seaborn.axisgrid.FacetGrid at 0x1d7d3634e50>1.3 scatterplot(散点图)diamonds.head().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } caratcutcolorclaritydepthtablepricexyz00.23IdealESI261.555.0326.03.953.982.4310.21PremiumESI159.861.0326.03.893.842.3120.23GoodEVS156.965.0327.04.054.072.3130.29PremiumIVS262.458.0334.04.204.232.6340.31GoodJSI263.358.0335.04.344.352.75sns.set(style="whitegrid") # Load the example iris dataset diamonds = sns.load_dataset("diamonds") # Draw a scatter plot while assigning point colors and sizes to different # variables in the dataset f, ax = plt.subplots(figsize=(6.5, 6.5)) sns.despine(f, left=True, bottom=True) sns.scatterplot(x="depth", y="table", data=diamonds, ax=ax)<AxesSubplot:xlabel='depth', ylabel='table'>1.4 气泡图气泡图是在散点图的基础上，指定size参数，根据size参数的大小来绘制点的大小1.4.1 普通气泡图# 导入鸢尾花数据集 planets = sns.load_dataset("planets") cmap = sns.cubehelix_palette(rot=-.2, as_cmap=True) ax = sns.scatterplot(x="distance", y="orbital_period", hue="year", size="mass", palette=cmap, sizes=(10, 200), data=planets)1.4.2 彩色气泡图sns.set(style="white") #加载示例mpg数据集 mpg = sns.load_dataset("mpg") # 绘制气泡图 sns.relplot(x="horsepower", y="mpg", hue="origin", size="weight", sizes=(40, 400), alpha=.5, palette="muted", height=6, data=mpg)2. 分类型图表2.1 boxplot(箱线图)箱形图（Box-plot）又称为盒须图、盒式图或箱线图，是一种用作显示一组数据分散情况资料的统计图。它能显示出一组数据的最大值、最小值、中位数及上下四分位数。绘制分组箱线图# 导入数据集 tips = sns.load_dataset("tips") # 绘制嵌套的箱线图，按日期和时间显示账单 sns.boxplot(x="day", y="total_bill", hue="smoker", palette=["m", "g"], data=tips) sns.despine(offset=10, trim=True)2.2 violinplot(小提琴图)violinplot与boxplot扮演类似的角色，它显示了定量数据在一个（或多个）分类变量的多个层次上的分布，这些分布可以进行比较。不像箱形图中所有绘图组件都对应于实际数据点，小提琴绘图以基础分布的核密度估计为特征。绘制简单的小提琴图# 生成模拟数据集 rs = np.random.RandomState(0) n, p = 40, 8 d = rs.normal(0, 2, (n, p)) d += np.log(np.arange(1, p + 1)) * -5 + 10 # 使用cubehelix获得自定义的顺序调色板 pal = sns.cubehelix_palette(p, rot=-.5, dark=.3) # 如何使用小提琴和圆点进行每种分布 sns.violinplot(data=d, palette=pal, inner="point")<AxesSubplot:>绘制分组小提琴图tips = sns.load_dataset("tips") # 绘制一个嵌套的小提琴图，并拆分小提琴以便于比较 sns.violinplot(x="day", y="total_bill", hue="smoker", split=True, inner="quart", palette={"Yes": "y", "No": "b"}, data=tips) sns.despine(left=True)2.3 barplot(条形图)条形图表示数值变量与每个矩形高度的中心趋势的估计值，并使用误差线提供关于该估计值附近的不确定性的一些指示。绘制水平的条形图crashes = sns.load_dataset("car_crashes").sort_values("total", ascending=False) # 初始化画布大小 f, ax = plt.subplots(figsize=(6, 15)) # 绘出总的交通事故 sns.set_color_codes("pastel") sns.barplot(x="total", y="abbrev", data=crashes, label="Total", color="b") # 绘制涉及酒精的车祸 sns.set_color_codes("muted") sns.barplot(x="alcohol", y="abbrev", data=crashes, label="Alcohol-involved", color="b") # 添加图例和轴标签 ax.legend(ncol=2, loc="lower right", frameon=True) ax.set(xlim=(0, 24), ylabel="", xlabel="Automobile collisions per billion miles") sns.despine(left=True, bottom=True)绘制分组条形图titanic = sns.load_dataset("titanic") # 绘制分组条形图 g = sns.barplot(x="class", y="survived", hue="sex", data=titanic, palette="muted")2.4 pointplot(点图)点图代表散点图位置的数值变量的中心趋势估计，并使用误差线提供关于该估计的不确定性的一些指示。点图可能比条形图更有用于聚焦一个或多个分类变量的不同级别之间的比较。他们尤其善于表现交互作用：一个分类变量的层次之间的关系如何在第二个分类变量的层次之间变化。连接来自相同色调等级的每个点的线允许交互作用通过斜率的差异进行判断，这比对几组点或条的高度比较容易。sns.set(style="whitegrid") iris = sns.load_dataset("iris") # 将数据格式调整 iris = pd.melt(iris, "species", var_name="measurement") # 初始化图形 f, ax = plt.subplots() sns.despine(bottom=True, left=True) sns.stripplot(x="value", y="measurement", hue="species", data=iris, dodge=True, jitter=True, alpha=.25, zorder=1) # 显示条件平均数 sns.pointplot(x="value", y="measurement", hue="species", data=iris, dodge=.532, join=False, palette="dark", markers="d", scale=.75, ci=None) # 图例设置 handles, labels = ax.get_legend_handles_labels() ax.legend(handles[3:], labels[3:], title="species", handletextpad=0, columnspacing=1, loc="lower right", ncol=3, frameon=True)可以看出各种鸢尾花四个特征的分布情况，以setosa为例，发现其petal_width值集中分布在0.2左右2.5 swarmplot能够显示分布密度的分类散点图sns.set(style="whitegrid", palette="muted") # 加载数据集 iris = sns.load_dataset("iris") # 处理数据集 iris = pd.melt(iris, "species", var_name="measurement") # 绘制分类散点图 sns.swarmplot(x="measurement", y="value", hue="species", palette=["r", "c", "y"], data=iris)2.6 catplot（分类型图表的接口）可以通过指定kind参数分别绘制下列图形：stripplot() 分类散点图swarmplot() 能够显示分布密度的分类散点图boxplot() 箱图violinplot() 小提琴图boxenplot() 增强箱图pointplot() 点图barplot() 条形图countplot() 计数图3.分布图3.1 displot(单变量分布图)在seaborn中想要对单变量分布进行快速了解最方便的就是使用distplot()函数，默认情况下它将绘制一个直方图，并且可以同时画出核密度估计(KDE)图。具体用法如下：# 设置并排绘图，讲一个画布分为2*2，大小为7*7，X轴固定，通过ax参数指定绘图位置，可以看第六章具体怎么绘制多个图在一个画布中 f, axes = plt.subplots(2, 2, figsize=(7, 7), sharex=True) sns.despine(left=True) rs = np.random.RandomState(10) # 生成随机数 d = rs.normal(size=100) # 绘制简单的直方图，kde=False不绘制核密度估计图，下列其他图类似 sns.distplot(d, kde=False, color="b", ax=axes[0, 0]) # 绘制核密度估计图和地毯图 sns.distplot(d, hist=False, rug=True, color="r", ax=axes[0, 1]) # 绘制填充核密度估计图 sns.distplot(d, hist=False, color="g", kde_kws={"shade": True}, ax=axes[1, 0]) # 绘制直方图和核密度估计 sns.distplot(d, color="m", ax=axes[1, 1]) plt.setp(axes, yticks=[]) plt.tight_layout()3.2kdeplot(核密度估计图）核密度估计(kernel density estimation)是在统计学中用来估计未知分布的密度函数，属于非参数检验方法之一。通过核密度估计图可以比较直观的看出数据样本本身的分布特征。具体用法如下：简单的二维核密度估计图sns.set(style="dark") rs = np.random.RandomState(50) x, y = rs.randn(2, 50) sns.kdeplot(x, y) f.tight_layout()多个核密度估计图sns.set(style="darkgrid") iris = sns.load_dataset("iris") # 按物种对iris数据集进行子集划分 setosa = iris.query("species == 'setosa'") virginica = iris.query("species == 'virginica'") f, ax = plt.subplots(figsize=(8, 8)) ax.set_aspect("equal") # 画两个密度图 ax = sns.kdeplot(setosa.sepal_width, setosa.sepal_length, cmap="Reds", shade=True, shade_lowest=False) ax = sns.kdeplot(virginica.sepal_width, virginica.sepal_length, cmap="Blues", shade=True, shade_lowest=False) # 将标签添加到绘图中 red = sns.color_palette("Reds")[-2] blue = sns.color_palette("Blues")[-2] ax.text(2.5, 8.2, "virginica", size=16, color=blue) ax.text(3.8, 4.5, "setosa", size=16, color=red)3.3绘制山脊图rs = np.random.RandomState(1979) x = rs.randn(500) g = np.tile(list("ABCDEFGHIJ"), 50) df = pd.DataFrame(dict(x=x, g=g)) m = df.g.map(ord) df["x"] += m # 初始化FacetGrid对象 pal = sns.cubehelix_palette(10, rot=-.25, light=.7) g = sns.FacetGrid(df, row="g", hue="g", aspect=15, height=.5, palette=pal) # 画出密度 g.map(sns.kdeplot, "x", clip_on=Fals "?e, shade=True, alpha=1, lw=1.5, bw=.2) g.map(sns.kdeplot, "x", clip_on=False, color="w", lw=2, bw=.2) g.map(plt.axhline, y=0, lw=2, clip_on=False) # 定义并使用一个简单的函数在坐标轴中标记绘图 def label(x, color, label): ax = plt.gca() ax.text(0, .2, label, fontweight="bold", color=color, ha="left", va="center", transform=ax.transAxes) g.map(label, "x") # 将子地块设置为重叠 g.fig.subplots_adjust(hspace=-.25) # 删除与重叠不协调的轴 g.set_titles("") g.set(yticks=[]) g.despine(bottom=True, left=True)<seaborn.axisgrid.FacetGrid at 0x1d7da3567c0>3.4 joinplot(双变量关系分布图)用于绘制两个变量间分布图sns.set(style="white") # 创建模拟数据集 rs = np.random.RandomState(5) mean = [0, 0] cov = [(1, .5), (.5, 1)] x1, x2 = rs.multivariate_normal(mean, cov, 500).T x1 = pd.Series(x1, name="$X_1$") x2 = pd.Series(x2, name="$X_2$") # 使用核密度估计显示联合分布 g = sns.jointplot(x1, x2, kind="kde", height=7, space=0)rs = np.random.RandomState(11) x = rs.gamma(2, size=1000) y = -.5 * x + rs.normal(size=1000) sns.jointplot(x, y, kind="hex", color="#4CB391")tips = sns.load_dataset("tips") g = sns.jointplot("total_bill", "tip", data=tips, kind="reg", xlim=(0, 60), ylim=(0, 12), color="m", height=7)3.5 pairplot(变量关系图)变量关系组图，绘制各变量之间散点图df = sns.load_dataset("iris") sns.pairplot(df)4. 回归图4.1 lmplotlmplot是用来绘制回归图的，通过lmplot我们可以直观地总览数据的内在关系，lmplot可以简单通过指定x,y,data绘制# 绘制整体数据的回归图 sns.lmplot(x='x',y='y',data=df)<seaborn.axisgrid.FacetGrid at 0x1d7cdfbec10># 使用分面绘图，根据dataset分面 sns.lmplot(x="x", y="y", col="dataset", hue="dataset", data=df, col_wrap=2, ci=None)上面显示了每一张图内画一个回归线，下面我们来看如何在一张图中画多个回归线# 加载鸢尾花数据集 iris = sns.load_dataset("iris") g = sns.lmplot(x="sepal_length", y="sepal_width", hue="species", truncate=True, height=5, data=iris) # 使用truncate参数 # 设置坐标轴标签 g.set_axis_labels("Sepal length (mm)", "Sepal width (mm)")<seaborn.axisgrid.FacetGrid at 0x1d7d16cea60>可以看出setosa类型的鸢尾花主要集中在左侧，下面我们再来看一下怎么绘制logistic回归曲线# 加载 titanic dataset df = sns.load_dataset("titanic") # 显示不同性别年龄和是否存活的关系 g = sns.lmplot(x="age", y="survived", col="sex", hue="sex", data=df, y_jitter=.02, logistic=True) g.set(xlim=(0, 80), ylim=(-.05, 1.05))虽然仅仅使用一个变量来拟合logistic回归效果不好，但是为了方便演示，我们暂且这样做，从logistic回归曲线来看，男性随着年龄增长，存活率下降，而女性随着年龄上升，存活率上升4.2 residplot（残差图）线性回归残差图绘制现象回归得到的残差回归图sns.set(style="whitegrid") # 模拟y对x的回归数据集 rs = np.random.RandomState(7) x = rs.normal(2, 1, 75) y = 2 + 1.5 * x + rs.normal(0, 2, 75) # 绘制残差数据集，并拟合曲线 sns.residplot(x, y, lowess=True, color="g")从结果来看，回归结果较好，这是因为我们的数据就是通过回归的形式生成的5.矩阵图5.1 heatmap(热力图)常见的我们使用热力图可以看数据表中多个变量间的相似度# 加载数据 flights_long = sns.load_dataset("flights") # 绘制不同年份不同月份的乘客数量 flights = flights_long.pivot("month", "year", "passengers") # 绘制热力图，并且在每个单元中添加一个数字 f, ax = plt.subplots(figsize=(9, 6)) sns.heatmap(flights, annot=True, fmt="d", linewidths=.5, ax=ax)绘制相关系数矩阵，绘制26个英文字母之间的相关系数矩阵from string import ascii_letters sns.set(style="white") # 随机数据集 rs = np.random.RandomState(33) d = pd.DataFrame(data=rs.normal(size=(100, 26)), columns=list(ascii_letters[26:])) # 计算相关系数 corr = d.corr() mask = np.zeros_like(corr, dtype=np.bool) mask[np.triu_indices_from(mask)] = True # 设置图形大小 f, ax = plt.subplots(figsize=(11, 9)) # 生成自定义颜色 cmap = sns.diverging_palette(220, 10, as_cmap=True) # 绘制热力图 sns.heatmap(corr, mask=mask, cmap=cmap, vmax=.3, center=0, square=True, linewidths=.5, cbar_kws={"shrink": .5})🌐5.2 clustermap聚类图sns.set() # 加载大脑网络示例数据集 df = sns.load_dataset("brain_networks", header=[0, 1, 2], index_col=0) # 选择网络的子集 used_networks = [1, 5, 6, 7, 8, 12, 13, 17] used_columns = (df.columns.get_level_values("network") .astype(int) .isin(used_networks)) df = df.loc[:, used_columns] # 创建一个分类调色板来识别网络 network_pal = sns.husl_palette(8, s=.45) network_lut = dict(zip(map(str, used_networks), network_pal)) # 将调色板转换为将在矩阵侧面绘制的向量 networks = df.columns.get_level_values("network") network_colors = pd.Series(networks, index=df.columns).map(network_lut) # 画出完整的聚类图 sns.clustermap(df.corr(), center=0, cmap="vlag", row_colors=network_colors, col_colors=network_colors, linewidths=.75, figsize=(13, 13))6.FacetGrid绘制多个图表是一个绘制多个图表（以网格形式显示）的接口。步骤：1、实例化对象2、map，映射到具体的 seaborn 图表类型3、添加图例6.1 绘制多个直方图sns.set(style="darkgrid") tips = sns.load_dataset("tips") g = sns.FacetGrid(tips, row="sex", col="time", margin_titles=True) bins = np.linspace(0, 60, 13) g.map(plt.hist, "total_bill", color="steelblue", bins=bins)6.2 绘制多个折线图sns.set(style="ticks") # 创建一个包含许多短随机游动的数据集 rs = np.random.RandomState(4) pos = rs.randint(-1, 2, (20, 5)).cumsum(axis=1) pos -= pos[:, 0, np.newaxis] step = np.tile(range(5), 20) walk = np.repeat(range(20), 5) df = pd.DataFrame(np.c_[pos.flat, step, walk], columns=["position", "step", "walk"]) # 为每一次行走初始化一个带有轴的网格 grid = sns.FacetGrid(df, col="walk", hue="walk", palette="tab20c", col_wrap=4, height=1.5) # 画一条水平线以显示起点 grid.map(plt.axhline, y=0, ls=":", c=".5") # 画一个直线图来显示每个随机行走的轨迹 grid.map(plt.plot, "step", "position", marker="o") # 调整刻度位置和标签 grid.set(xticks=np.arange(5), yticks=[-3, 3], xlim=(-.5, 4.5), ylim=(-3.5, 3.5)) # 调整图形的布局 grid.fig.tight_layout(w_pad=1)

浏览量2032

攻城狮无远

第一章：现代化您的数据平台：入门概览

数据是一项宝贵的资产，可以帮助您的公司做出更明智的决策，发现新的机会，并改进业务运营。谷歌在2013年启动了一项战略项目，旨在通过提高管理质量来提高员工留任率。即使像管理技能这样宽泛的概念也可以以数据驱动的方式进行研究。通过分析1万份绩效评价，识别高绩效经理的共同行为，并创建培训计划，谷歌成功将管理青睐度从83%提高到88%。亚马逊也进行了一项战略性的数据项目。这家电商巨头实施了一个基于客户行为的推荐系统，该系统在2017年推动了35%的购买。旧金山的篮球队勇士队是另一个例子；他们实施了一个分析计划，帮助他们一举成为联赛的佼佼者。这些例子——员工留任、产品推荐、提高胜率——都是通过现代数据分析实现的业务目标。要成为一家数据驱动型公司，您需要构建一个用于数据分析、处理和洞察的生态系统。这是因为有许多不同类型的应用程序（网站、仪表板、移动应用程序、机器学习模型、分布式设备等）创建和使用数据。公司内部还有许多不同的部门（财务、销售、营销、运营、物流等）需要数据驱动的洞察。由于整个公司都是您的客户群体，构建数据平台不仅仅是一个IT项目。本章介绍了数据平台及其要求，以及为什么传统数据架构不足以满足需求。它还讨论了数据分析和人工智能的技术趋势，以及如何利用公共云构建未来的数据平台。本章是对本书其余部分更详细涵盖的核心主题的概括。数据生命周期数据平台的目的是支持组织从原始数据到见解信息的过程。了解数据生命周期的步骤（收集、存储、处理、可视化、激活）是有帮助的，因为它们几乎可以直接映射到数据架构，从而创建一个统一的分析平台。通往智慧的旅程数据帮助公司开发更智能的产品，触达更多客户，并提高投资回报（ROI）。数据还可以用于衡量客户满意度、盈利能力和成本。但是单独的数据是不够的。数据是一种原材料，需要经过一系列阶段才能用于生成见解和知识。这一系列阶段就是我们所说的数据生命周期。尽管文献中有许多定义，但从一个一般的角度来看，我们可以确定现代数据平台架构中的五个主要阶段：收集数据必须被获取并注入到目标系统中（例如，手动数据录入、批量加载、流式摄取等）。存储数据需要以可持续的方式存储，并且能够在未来轻松访问（例如，文件存储系统、数据库）。处理/转换数据必须被操纵以使其对后续步骤有用（例如，清理、整理、转换）。分析/可视化数据需要被研究，通过手动加工（例如，查询、切片和切块）或自动处理（例如，使用ML应用程序编程接口进行丰富）来得出业务见解。激活在形式和位置上展示数据洞察，使决策能够被做出（例如，作为特定手动操作的触发器的通知，当满足特定条件时自动执行的作业，向设备发送反馈的ML模型）。这些阶段中的每一个都向下一个阶段提供输入，类似于水通过一组管道流动。水管类比为了更好地理解数据生命周期，可以将其想象成一个简化的水管系统。水源始于一个引水渠，然后通过一系列管道进行传输和转化，最终到达一组房屋。数据生命周期类似，数据在被收集、存储、处理/转换和分析之前会经过一系列步骤，最终用于做出决策（见图1-1）。你可以看到管道世界和数据世界之间存在一些相似之处。给水工程师就像数据工程师，他们设计和构建能够使数据可用的系统。分析水样本的人类似于数据分析师和数据科学家，他们分析数据以发现见解。当然，这只是一个简化。公司中还有许多其他角色使用数据，如高管、开发人员、业务用户和安全管理员。但这个类比可以帮助你记住主要的概念。在图1-2中展示的经典数据生命周期中，数据工程师收集并将数据存储在一个分析存储中。然后使用各种工具处理存储的数据。如果工具涉及编程，处理通常由数据工程师完成。如果工具是声明性的，处理通常由数据分析师完成。处理后的数据然后由业务用户和数据科学家进行分析。业务用户利用这些见解做出决策，例如启动营销活动或发起退款。数据科学家使用数据训练ML模型，这些模型可以用于自动化任务或进行预测。现实世界可能与前述对现代数据平台架构和角色如何运作的理想化描述有所不同。阶段可能被合并（例如，存储和处理）或重新排序（例如，在ETL [抽取-转换-加载]中处理在存储之前，而不是在ELT [抽取-加载-转换]中存储在处理之前）。然而，这些变化存在一些权衡。例如，将存储和处理合并为一个阶段会导致耦合，从而导致资源浪费（如果数据量增长，您将需要扩展存储和计算）和可扩展性问题（如果您的基础设施无法处理额外的负载，您将陷入困境）。既然我们已经定义了数据生命周期并总结了数据从原始数据收集到激活的旅程的各个阶段，让我们逐个深入了解数据生命周期的五个阶段。采集设计过程中的第一步是摄取。摄取是将数据从源传输到目标系统的过程，源可以是任何地方（本地、设备上、另一个云中等），以便将其存储以供进一步分析。这是考虑大数据的3V的第一个机会：Volume（容量）数据的大小是多少？通常在处理大数据时，这意味着以TB（千兆字节）或PB（拍字节）为单位的数据。Velocity（速度）数据输入的速度是多少？通常以MB/s（兆字节/秒）或TB/day（千兆字节/天）为单位。这通常被称为吞吐量。Variety（多样性）数据的格式是什么？表格、平面文件、图像、声音、文本等。识别要收集的数据的数据类型（结构化、半结构化、非结构化）、格式和生成频率（连续或在特定间隔）等。根据数据的速度以及数据平台处理所需的体积和多样性的能力，选择批处理摄取、流摄取或两者的混合。由于组织的不同部分可能对不同的数据源感兴趣，因此设计此阶段时要尽量灵活。有几种商业和开源解决方案可供使用，每种都专门针对先前提到的特定数据类型/方法。您的数据平台将需要全面支持所有需要摄取到平台的数据所需的容量、速度和多样性的整个范围。您可以使用简单的工具定期在文件传输协议（FTP）服务器之间传输文件，也可以使用复杂的系统，甚至是地理分布的系统，实时从物联网（IoT）设备收集数据。存储在这一步骤中，存储您在前一步中收集的原始数据。您不对数据进行任何更改，只是存储它。这很重要，因为您可能希望以不同的方式重新处理数据，而为此您需要有原始数据。数据有很多不同的形式和大小。您存储数据的方式将取决于您的技术和商业需求。一些常见的选择包括对象存储系统、关系数据库管理系统（RDBMS）、数据仓库（DWH）和数据湖。您的选择在某种程度上将受到底层硬件、软件和工件是否能够满足您所期望的用例所施加的可扩展性、成本、可用性、耐久性和开放性要求的影响。可扩展性可扩展性是以一种有能力的方式增长并管理增加的需求。实现可扩展性有两种主要方法：纵向扩展这涉及向同一节点添加额外的扩展单元，以增加存储系统的容量。横向扩展这涉及添加一个或多个额外的节点，而不是向单个节点添加新的扩展单元。这种类型的分布式存储更加复杂，但它可以实现更好的性能和效率。极其重要的是，底层系统能够处理现代解决方案所需的体积和速度，这些解决方案必须在数据爆炸的环境中工作，其性质正在从批处理过渡到实时：我们生活在一个大多数人持续生成并要求通过智能设备访问信息的世界中；组织需要能够为他们的用户（内部和外部）提供能够对各种请求进行实时响应的解决方案。性能与成本识别您需要管理的不同类型的数据，并根据数据的业务重要性、访问频率以及数据使用者对延迟的期望创建一个层次结构。将最重要且访问频率最高的数据（热数据）存储在高性能存储系统中，例如数据仓库的本地存储。将不太重要的数据（冷数据）存储在成本较低的存储系统中，例如云存储（它本身有多个层次）。如果您需要更高的性能，比如用于交互式用例，您可以使用缓存技术将热数据的有意义部分加载到一个易失性存储层中。高可用性高可用性意味着在请求时具有运行和提供对数据的访问的能力。通常通过硬件冗余来实现，以应对可能的物理故障/中断。在云中，通过将数据存储在至少三个可用性区域来实现这一目标。这些区域可能并非物理上分开（即它们可能在同一个“园区”），但往往会有不同的电源等。硬件冗余通常被称为系统正常运行时间，现代系统通常具有四个9或更多的正常运行时间。耐久性耐久性是在长期内存储数据而不会遭受数据退化、损坏或彻底丢失的能力。通常通过在物理上分开的位置存储数据的多个副本来实现。在云中，通过将数据存储在至少两个区域（例如在伦敦和法兰克福）来实现这一目标。在面对自然灾害时，这在处理数据恢复操作时变得极为重要：如果底层存储系统具有很高的耐久性（现代系统通常具有11个9），那么除非发生灾难性事件使得即使是物理上分开的数据中心也宕机，否则所有数据都可以恢复而不会出现问题。开放性尽量使用非专有且不会造成封锁效应的格式。理想情况下，应该能够使用多种处理引擎查询数据，而无需生成数据的副本或将其从一个系统移动到另一个系统。也就是说，可以使用使用专有或本地存储格式的系统，只要它们提供方便的导出功能。与大多数技术决策一样，开放性是一种权衡，专有技术的回报率可能足够高，以至于您愿意承担封锁的代价。毕竟，转向云的原因之一是为了降低运营成本，这些成本优势在完全托管/无服务器系统中往往比在托管的开源系统中更高。例如，如果您的数据用例需要事务，Databricks（使用基于Parquet的准开放存储格式Delta Lake）的运营成本可能比Amazon EMR或Google Dataproc低（后两者将数据分别存储在S3或Google Cloud Storage [GCS]中的标准Parquet中）- Databricks在Delta Lake中提供的ACID（原子性、一致性、隔离性、耐久性）事务在EMR或Dataproc上实施和维护将是昂贵的。如果以后需要迁出Databricks，可以将数据导出为标准Parquet格式。开放性本身并不是拒绝更适合的技术的理由。处理/转换这是魔术发生的地方：原始数据被转化为可供进一步分析的有用信息。这是数据工程师构建数据管道的阶段，以使数据以有意义的方式对更广泛的非技术用户可访问。该阶段包括为分析和使用准备数据的活动。数据集成涉及将来自多个来源的数据合并为单一视图。可能需要进行数据清理，以从数据中删除重复项和错误。更一般地说，进行数据整理、处理和转换以将数据组织成标准格式。有几个框架可以使用，每个框架都具有依赖于前一步中选择的存储方法的功能。一般来说，允许您使用纯SQL命令查询和转换数据的引擎（例如AWS Athena、Google BigQuery、Azure DWH和Snowflake）是效率最高、成本最低且易于使用的。然而，与基于现代编程语言（通常是Java、Scala或Python）的引擎相比，它们提供的功能有限（例如，在Amazon EMR、Google Cloud Dataproc/Dataflow、Azure HDInsight和Databricks上运行的Apache Spark、Apache Flink或Apache Beam）。基于代码的数据处理引擎不仅可以实现更复杂的批处理和实时转换以及机器学习，还可以利用其他重要功能，如适当的单元测试和集成测试。在选择适当的引擎时，另一个考虑因素是SQL技能在组织中通常比编程技能更为普遍。您想要在组织内建立更多的数据文化，就越应该倾向于使用SQL进行数据处理。如果处理步骤（例如数据清理或转换）需要领域知识，这一点尤为重要。在这个阶段，还可以使用数据虚拟化解决方案，该解决方案抽象了多个数据源以及管理它们的相关逻辑，使信息直接对最终用户进行分析。在本书中，我们将不再讨论虚拟化，因为它往往是在构建一个完全灵活的平台的路上的一种权宜之计。有关数据虚拟化的更多信息，建议参阅Sandeep Uttamchandani（O'Reilly）的《自助数据路线图》一书的第10章。分析/可视化一旦进入这个阶段，数据最终开始具有独立的价值——您可以将其视为信息。用户可以利用多种工具深入挖掘数据的内容，提取有用的见解，识别当前趋势，并预测新的结果。在这个阶段，可视化工具和技术（例如图表、图形、地图、热力图等）发挥着重要作用，因为它们提供了一种简单的方式来发现和评估趋势、异常值、模式和行为。数据的可视化和分析可以由多种类型的用户执行。一方面，有人对理解业务数据感兴趣，希望利用图形工具执行常见的分析，如切片和切块汇总和假设分析。另一方面，可能有更高级的用户（“高级用户”），他们希望利用类似SQL的查询语言的强大功能进行更精细和定制的分析。此外，可能还有数据科学家，他们可以利用机器学习技术从数据中提取有意义的见解，发现模式和相关性，提高对客户的理解和定位，从而提高企业的收入、增长和市场地位。激活这是最终用户能够根据数据分析和机器学习预测做出决策的步骤，从而实现数据决策过程。从提取或预测的见解中，现在是采取一些行动的时候。可以执行的行动分为三类：自动操作自动化系统可以使用推荐系统的结果向客户提供定制推荐，从而通过增加销售额帮助业务的顶线。SaaS集成通过与第三方服务集成可以执行操作。例如，一家公司可能会实施一项营销活动，试图降低客户流失率。他们可以分析数据并实施倾向模型，以识别可能对新商业报价做出积极响应的客户。然后，客户电子邮件地址列表可以自动发送到营销工具，以启动活动。警报您可以创建实时监视数据的应用程序，并在满足某些条件时发送个性化消息。例如，定价团队可能在访问某个商品列表页面的流量超过某个阈值时接收到主动通知，从而使他们可以检查商品是否定价正确。这三种场景的技术堆栈是不同的。对于自动操作，ML模型的“训练”通常定期进行，通常通过安排端到端的ML管道来完成（这将在第11章中介绍）。预测本身是通过调用部署为Web服务的ML模型实现的，使用类似AWS SageMaker、Google Cloud Vertex AI或Azure Machine Learning的工具。 SaaS集成通常在特定功能的工作流工具的上下文中进行，该工具允许人类控制检索的信息、转换的方式以及激活的方式。此外，使用大型语言模型（LLM）及其生成能力（我们将在第10章更深入地探讨这些概念）可以通过与核心系统紧密集成来帮助自动化重复性任务。警报是通过编排工具（例如Apache Airflow）、事件系统（例如Google Eventarc）或无服务器函数（例如AWS Lambda）来实现的。在本节中，我们已经了解了现代数据平台需要支持的活动。接下来，让我们查看在实现分析和AI平台方面的传统方法，以更好地理解技术的演变以及为什么云方法可能产生重大差异。传统方法的局限性传统上，组织的数据生态系统包括用于提供不同数据服务的独立解决方案。不幸的是，这些专用的数据存储解决方案有时可能规模庞大，可能导致组织内部形成信息孤岛。由此产生的信息孤岛系统是独立的解决方案，它们无法以高效的方式协同工作。信息孤岛中的数据是沉默的数据，从中难以获取洞察。为了拓宽和统一企业智能，跨业务部门安全共享数据至关重要。如果大部分解决方案都是定制构建的，那么处理可伸缩性、业务连续性和灾难恢复（DR）就变得困难。如果组织的每个部分都选择在不同的环境中构建其解决方案，复杂性将变得令人不堪重负。在这种情况下，很难确保隐私或审计数据的更改。一种解决方案是开发一个统一的数据平台，更确切地说，是一个云数据平台（请注意，统一并不一定意味着集中，稍后将讨论）。数据平台的目的是允许在整个组织的所有数据上以一致、可扩展和可靠的方式进行分析和机器学习。在这样做时，您应该尽可能地利用托管服务，以便组织可以专注于业务需求而不是操作基础架构。基础设施的运营和维护应完全委托给底层的云平台。在本书中，我们将介绍在开发一个可扩展和可靠的平台来整合跨业务部门的数据时，您需要做出的核心决策。反模式：通过ETL打破信息孤岛组织很难对其数据实现统一视图，因为它们往往使用多种解决方案来管理数据。组织通常通过使用数据移动工具来解决这个问题。ETL（抽取、转换、加载）应用程序允许在不同系统之间转换和传输数据，以创建一个单一的真相源。然而，依赖ETL存在问题，现代平台中有更好的解决方案可用。通常，会定期使用ETL工具从事务性数据库中提取最新的交易并将其存储在分析存储中，以供仪表板访问。然后进行标准化。为了进行分析而对每个数据库表创建ETL工具，这样就可以在不必每次都访问源系统的情况下执行分析（见图1-3）。跨组织捕获所有数据的中央分析存储，根据使用的技术而定，被称为DWH或数据湖。这两种方法之间的高级区别基于系统内部存储数据的方式：如果分析存储支持SQL并包含经过管控的、经过质量控制的数据，则被称为DWH。相反，如果它支持Apache生态系统中的工具（如Apache Spark）并包含原始数据，则被称为数据湖。有关称为介于两者之间的分析存储（例如经管控的原始数据或未管控的质量受控数据）的术语因组织而异，有些组织称其为数据湖，而其他组织则称其为DWH。正如您将在本书后面看到的，这种混乱的词汇不是问题，因为数据湖（第5章）和DWH（第6章）方法正在汇聚成为被称为数据湖仓（第7章）的东西。依赖数据移动工具来尝试构建数据的一致视图存在一些缺点：数据质量：ETL工具通常由数据的使用者编写，这些使用者往往对数据的了解程度不及数据的所有者。这意味着很多时候提取的数据不是正确的数据。延迟：ETL工具引入了延迟。例如，如果用于提取最近交易的ETL工具每小时运行一次，并且运行需要15分钟，那么分析存储中的数据可能在75分钟内变得陈旧。通过流式ETL可以解决这个问题，其中事件在发生时即时处理。瓶颈：ETL工具通常涉及编程技能。因此，组织建立了专门的数据工程团队来为ETL编写代码。随着组织内数据的多样性增加，需要编写越来越多的ETL工具。数据工程团队成为组织利用数据能力的瓶颈。维护：ETL工具需要由系统管理员定期运行和进行故障排除。底层基础设施系统需要持续更新，以应对增加的计算和存储容量，并确保可靠性。变更管理：输入表模式的更改要求更改ETL工具的提取代码。这使得变更变得困难，或者导致ETL工具被上游更改破坏。数据缺失：很可能必须将许多错误升级到数据的所有者、ETL工具的创建者或数据的使用者。这增加了维护开销，并且很多时候工具停机时间较长。由于这个原因，数据记录中通常存在很大的缺陷。管理：随着ETL流程的增多，越来越有可能由不同的流程执行相同的处理，从而导致相同信息的多个源。随着时间的推移，这些流程通常会发散，以满足不同的需求，导致为不同的决策使用不一致的数据。效率和环境影响：支持这些类型转换的基础设施是一个问题，因为它通常是全天候运行的，产生了显着的成本，并增加了碳足迹的影响。前面列表中的第一点（数据质量）经常被忽视，但随着时间的推移，它往往是最重要的。通常需要在数据“可信”可用于生产之前对数据进行预处理。来自上游系统的数据通常被认为是原始的，如果没有得到适当的清理和转换，它可能包含噪音甚至是错误的信息。必须专门为手头的任务构建数据处理工具。在考虑一个数据源时，这种情况是合理的，但总的收集（见图1-4）导致了混乱。存储系统的泛滥，加上为满足不同下游应用程序的需求而开发的定制数据管理解决方案，导致分析主管和首席信息官（CIO）面临以下挑战：他们的DWH/数据湖无法满足不断增长的业务需求。日益增长的数字化计划（以及与数字原生企业的竞争）已经将业务转变为系统中涌入大量数据的业务。为不同的数据科学任务创建单独的数据湖、DWH和特殊存储最终会创建多个数据孤岛。由于性能、安全性和治理方面的挑战，数据访问需要受到限制或受到限制。由于需要更新许可证并支付昂贵的支持资源，因此变得具有挑战性。很明显，这种方法无法满足新的业务需求，不仅因为技术复杂性，还因为这种模型涉及的安全性和治理要求。反模式：集中控制为了解决数据分散、分散并通过特定任务的数据处理解决方案进行管理的问题，一些组织尝试将一切都集中到由IT部门控制的单一的、单片的平台中。如图1-5所示，底层技术解决方案并没有改变，而是通过将问题交给一个组织来解决，使问题更容易解决。由一个独特部门实施的这种集中控制方式带来了自己的挑战和权衡。所有业务单元（BUs）— IT 本身、数据分析和业务用户在 IT 控制所有数据系统时都会遇到困难：IT IT 部门面临的挑战是这些数据孤岛涉及的各种技术。IT 部门很少拥有管理所有这些系统所需的所有技能。数据存储在本地和云端的多个存储系统中，管理 DWH、数据湖和数据集市的成本较高。跨不同来源定义安全性、治理、审计等内容也并不总是清晰。此外，这引入了一个获取数据访问权限的可伸缩性问题：IT 需要执行的工作量随着将作为一部分图像的源系统和目标系统的数量的增加而线性增加，因为这肯定会增加所有相关利益相关者/业务用户的数据访问请求。分析阻碍有效分析流程的主要问题之一是无法访问正确的数据。当存在多个系统时，将数据移动到/从单片数据系统变得昂贵，导致不必要的 ETL 任务等。此外，预先准备好并随时可用的数据可能没有最新的源，或者可能存在提供更深度和更广泛信息的其他版本的数据，例如拥有更多列或更精细的记录。由于数据治理和运营问题，不可能让您的分析团队自由发挥，每个人都可以访问所有数据。组织通常最终会通过限制数据访问来换取分析灵活性。业务获取业务可以信任的数据和分析结果是困难的。围绕限制您向业务提供的数据存在问题，以便确保最高质量。替代方法是开放访问业务用户所需的所有数据，即使这意味着牺牲质量。然后，挑战就变成了在数据质量和可信赖数据量之间取得平衡。往往情况是 IT 没有足够的合格的业务代表来推动优先事项和要求。这很快可能成为组织创新过程中的一个拖慢速度的瓶颈。尽管存在这么多的挑战，一些组织在多年来采用了这种方法，导致了在获取他们需要履行任务的数据方面受到延迟的业务用户的挫败和紧张。受挫的业务单元通常通过另一种反模式来应对，即影子 IT——整个部门开发和部署有用的解决方案以绕过这些限制，但最终使数据孤立问题变得更糟。有时会采用一种称为数据布局的技术方法。这仍然依赖于集中化，但数据布局是一个虚拟层，提供统一的数据访问。问题在于这样的标准化可能是一个沉重的负担，并且对于组织范围内对数据的访问来说可能会引入延迟。然而，数据布局对于试图访问客户专有数据的 SaaS 产品是一种可行的方法——集成专家提供了从客户模式到 SaaS 工具期望的模式的必要翻译。反模式：数据集市和 Hadoop由于围绕一个独立管理的系统存在问题，为了解决这个问题，一些企业采用了另外两种反模式：数据集市和无治理的数据湖。在第一种方法中，数据被提取到本地关系型和分析数据库中。然而，尽管被称为数据仓库，但由于可伸缩性约束，这些产品实际上是数据集市（适用于特定工作负载的企业数据子集）。数据集市允许业务用户设计和部署自己的业务数据到结构化的数据模型中（例如，零售、医疗保健、银行、保险等领域）。这使得他们能够轻松获取关于当前和历史业务的信息（例如，上个季度收入金额、上周玩过你上次发布的游戏的用户数量、网站帮助中心停留时间与过去六个月收到的工单数量之间的相关性等）。几十年来，组织一直在使用各种技术（例如 Oracle、Teradata、Vertica）开发数据集市解决方案，并在其上实施多个应用程序。然而，这些本地技术在容量方面受到严重限制。IT 团队和数据利益相关者面临着扩展基础设施（纵向）的挑战，寻找关键人才，降低成本，最终满足提供有价值的见解的预期增长。此外，由于数据规模增长，这些解决方案往往成本高昂，因为您需要获得更多计算能力来处理它。由于可伸缩性和成本问题，基于 Apache Hadoop 生态系统的大数据解决方案应运而生。Hadoop 引入了使用低成本通用服务器进行分布式数据处理（横向扩展）的概念，使以前只能通过高端（非常昂贵）专用硬件实现的用例成为可能。在 Hadoop 顶部运行的每个应用程序都被设计为容忍节点故障，使其成为某些传统 DWH 工作负载的经济有效替代方案。这导致了一个称为数据湖的新概念的发展，迅速成为数据管理的核心支柱，与 DWH 一起。其思想是，在核心运营技术部门继续执行日常任务的同时，所有数据都被导出到一个集中的数据湖中进行分析。数据湖旨在成为分析工作负载和业务用户的中央存储库。数据湖已经从仅用于原始数据的存储设施发展为支持大量数据上进行高级分析和数据科学的平台。这使得整个组织能够进行自助式分析，但需要对高级 Hadoop 和工程流程有广泛的工作知识才能访问数据。与组织数据使用者无法理解的无治理数据混乱相结合，技能差距和数据质量问题意味着企业很难从本地数据湖中获得良好的投资回报。现在您已经了解了几种反模式，让我们专注于如何设计一个数据平台，以提供对整个生命周期内的数据的统一视图。创建一个统一的分析平台数据集市和数据湖技术使IT能够构建第一代数据平台，打破数据孤岛，使组织能够从其所有数据资产中获取洞见。数据平台使数据分析师、数据工程师、数据科学家、业务用户、架构师和安全工程师能够更好地实时洞察数据，并预测业务随时间的发展。选择云而非本地部署DWH（数据仓库）和数据湖是现代数据平台的核心。DWH支持结构化数据和SQL，而数据湖支持原始数据和Apache生态系统中的编程框架。然而，在本地环境中运行DWH和数据湖存在一些固有的挑战，例如扩展和运营成本。这促使组织重新考虑其方法，并开始将云（特别是公共云）视为首选环境。为什么呢？因为它允许它们：通过利用新的定价模型（按使用量付费模型）降低成本通过利用最先进的技术加快创新速度使用“突发”方法扩展本地资源通过在多个区域和地区存储数据来规划业务连续性和灾难恢复利用完全托管的服务自动管理灾难恢复当用户不再受到基础设施容量的限制时，组织能够在其整个组织中实现数据的民主化并解锁洞察。云支持组织进行现代化改造，因为它通过卸载行政、低价值任务来最小化琐碎和摩擦。云数据平台承诺提供一个环境，在这里，您不再需要妥协，可以构建一个涵盖从数据收集到服务的端到端数据管理和处理阶段的全面数据生态系统。您可以使用云数据平台以多种格式存储大量数据，而无需妥协延迟。云数据平台承诺：集中的治理和访问管理增加生产力和降低运营成本在整个组织中更大范围的数据共享不同角色的扩展访问访问数据时延迟减少在公共云环境中，DWH和数据湖技术之间的界限变得模糊，因为云基础设施（具体而言，计算和存储的分离）实现了在本地环境中不可能的融合。今天可以将SQL应用于存储在数据湖中的数据，并且可以在DWH中存储的数据上运行传统的Hadoop技术（例如Spark）。在本节中，我们将为您介绍这种融合的基本原理，以及它如何成为可以彻底改变组织对数据看法的全新方法的基础；在第5到7章中，您将获得更多详细信息。数据集市和数据湖的缺点在过去的40年中，IT部门已经意识到数据仓库（实际上是数据集市）很难管理，并且可能变得非常昂贵。在过去运作良好的传统系统（例如本地的 Teradata 和 Netezza 设备）已经被证明很难扩展，非常昂贵，并且涉及与数据新鲜度相关的一系列挑战。此外，它们无法轻松提供现代功能，如访问 AI/ML 或实时特性，而不是在事后添加该功能。数据仓库的用户通常是嵌入在特定业务部门的分析师。他们可能对附加数据集、分析、数据处理和商业智能功能有一些想法，这些功能对他们的工作非常有益。然而，在传统公司中，他们通常无法直接访问数据所有者，也无法轻松影响决定数据集和工具的技术决策者。此外，因为他们无法访问原始数据，所以无法测试假设或更深入地了解底层数据。数据湖并不像它们看起来那么简单和经济实惠。虽然它们理论上可以轻松扩展，但组织在规划和提供足够存储空间方面通常面临挑战，特别是如果它们产生高度变化的数据量。此外，在高峰期为计算能力进行规划可能很昂贵，导致不同业务部门之间争夺有限资源。本地数据湖可能很脆弱，并需要耗时的维护。本应该开发新功能的工程师通常被降级为维护数据集群和为业务部门调度作业。对于许多企业来说，总体拥有成本通常高于预期。简而言之，数据湖并不创造价值，许多企业发现其投资回报率为负。对于数据湖，治理并不容易解决，尤其是当组织的不同部分使用不同的安全模型时。然后，数据湖变得孤立和分段，使得难以在团队之间共享数据和模型。数据湖的用户通常更接近原始数据源，并且需要使用数据湖工具和功能的编程技能，即使只是为了探索数据。在传统组织中，这些用户倾向于专注于数据本身，并经常与业务的其他方面保持距离。另一方面，业务用户没有编程技能，无法从数据湖中获取洞见。这种脱节意味着业务部门错过了获取洞见的机会，从而推动其实现更高收入、降低成本、降低风险和开发新机会的业务目标。数据仓库（DWH）和数据湖的融合鉴于这些权衡，许多公司最终采用混合方法，其中设置了一个数据湖以将一些数据升级到数据仓库，或者数据仓库有一个附加的数据湖用于额外的测试和分析。然而，由于多个团队正在构建适应其个别需求的数据架构，对于中央 IT 团队来说，数据共享和保真度变得更加复杂。与其拥有各自目标的独立团队——一个探索业务，另一个了解业务——不如将这些功能及其数据系统统一起来，创造一个良性循环，其中对业务的深入理解推动探索，而探索又推动对业务的更深理解。基于这一原则，数据行业开始转向一种新方法，即“lakehouse” 和“数据网格”（data mesh），它们能够很好地协同工作，因为它们有助于解决组织内的两个不同挑战：Lakehouse 允许具有不同技能集（数据分析师和数据工程师）的用户使用不同的技术访问数据。数据网格允许企业创建一个统一的数据平台，而不是将所有数据都集中在 IT 部门——这样，不同的业务部门可以拥有自己的数据，但允许其他业务部门以高效、可扩展的方式访问它。作为额外的好处，这种架构组合还带来了更严格的数据治理，这是数据湖通常缺乏的。数据网格赋予人们避免被一个团队拖慢的权力，从而启用整个数据堆栈。它将隔间打破成一个个较小的组织单元，在提供以联邦方式访问数据的架构中。数据湖仓数据湖仓架构是数据湖和数据仓库关键优势的结合（见图1-6）。它提供了一种低成本的存储格式，可被各种处理引擎访问，例如数据仓库的 SQL 引擎，同时还提供了强大的管理和优化功能。Databricks支持湖仓架构，因为它是基于Spark创建的，需要支持不是程序员的业务用户。因此，Databricks中的数据存储在数据湖中，但业务用户可以使用SQL进行访问。然而，湖仓架构并不局限于Databricks。在像Google Cloud BigQuery、Snowflake或Azure Synapse等云解决方案中运行的数据仓库允许您创建基于列存储的湖仓架构，该架构针对SQL分析进行了优化：它允许您将数据仓库视为数据湖，同时还允许在并行Hadoop环境中运行的Spark作业利用存储系统上存储的数据，而无需单独的ETL过程或存储层。湖仓模式相对于传统方法提供了几个优势：存储和计算的解耦，实现了：廉价、几乎无限且无缝可扩展的存储无状态、具有弹性的计算支持ACID的存储操作逻辑数据库存储模型，而非物理存储数据治理（例如，数据访问限制和模式演变）通过与商业智能工具的本地集成支持数据分析支持数据湖方法的典型多版本方法（即，青铜、白银和黄金）使用Apache Parquet和Iceberg等开放格式的数据存储和管理支持结构化或非结构化格式的不同数据类型具有处理数据实时分析的流式功能实现从商业智能到机器学习等各种工作负载的多样化应用然而，湖仓不可避免地是一种技术上的妥协。在云存储中使用标准格式限制了数据仓库多年来一直在完善的存储优化和查询并发性。因此，湖仓技术支持的SQL不如本机数据仓库的效率高（即，它需要更多的资源并且成本更高）。此外，SQL支持通常有限，不支持或效率极低的功能，例如地理空间查询、机器学习和数据操作。类似地，数据仓库提供的Spark支持有限，通常不如数据湖供应商提供的本机Spark支持高效。湖仓方法使组织能够实施一个支持任何类型工作负载的非常多样化数据平台的核心支柱。但是对于位于其之上的组织来说呢？用户如何充分利用平台的优势来执行他们的任务呢？在这种情况下，有一个新的运营模型正在形成，那就是数据网格。数据网格数据网格是一个技术、人员和流程的分散型运营模型，旨在解决分析中最常见的挑战之一——即在数据所有权必然分散的环境中对控制权进行集中的愿望，如图1-7所示。看待数据网格的另一种方式是，它引入了一种将数据视为自包含产品而非ETL流水线产品的方式。在这种方法中，分布式团队拥有数据生成并通过明确定义的数据模式为内部/外部消费者提供服务。总体而言，数据网格建立在数据仓库和数据湖领域的创新基础之上，结合了与公共云中数据仓库技术相关的可扩展性、按消费付费模型、自助API和紧密集成。通过这种方法，您可以有效地创建按需数据解决方案。数据网格将数据所有权分散给领域数据所有者，每个领域数据所有者都负责以标准方式提供其数据作为产品（见图1-8）。数据网格还支持组织内各个部分之间的通信，以在不同位置分发数据集。在数据网格中，从数据中提取价值的责任被委托给最了解该数据的人；换句话说，创建数据或将其引入组织的人必须负责从他们创建的数据中创建可消耗的数据资产，将其作为数据产品。在许多组织中，由于在整个组织中反复提取和转换数据而没有对新创建的数据明确的所有权责任，建立“单一真相”或“权威数据源”变得棘手。在数据网格中，权威数据源是源领域发布的数据产品，有明确定义的数据所有者和数据监护人负责该数据。从技术角度（lakehouse）和组织角度（数据网格）都能够访问这一统一视图意味着人们和系统能够以最适合其需求的方式获取数据。在某些情况下，这种体系结构必须跨越多个环境，从而产生了非常复杂的体系结构。让我们看看公司如何管理这一挑战。混合云在设计云数据平台时，可能一个单一的环境无法完全管理工作负载。这可能是由于法规约束（即，您无法将数据移动到组织边界之外的环境），或者由于成本（例如，组织在基础设施上进行了一些未达到寿命周期的投资），或者因为您需要的某种技术在云中不可用。在这种情况下，采用混合模式可能是一种可能的方法。混合模式是一种应用程序在各种环境中运行的模式。混合模式的最常见示例是将私有计算环境（如本地数据中心）与公共云计算环境结合在一起。在本节中，我们将解释这种方法在企业中的运作方式。混合云是必要的原因混合云方法被广泛采用，因为几乎没有大型企业完全依赖公共云。在过去几十年里，许多组织已经投资了数百万美元和数千小时用于本地基础设施。几乎所有组织都在运行一些传统的架构和业务关键的应用程序，它们可能无法迁移到公共云。由于法规或组织约束，它们可能还有无法在公共云中存储敏感数据的情况。允许工作负载在公共云和私有云环境之间迁移提供了更高级别的灵活性和数据部署的额外选择。有几个原因推动混合（即跨越本地、公共云和边缘的体系结构）和多云（即跨越多个公共云供应商，如AWS、Microsoft Azure和Google Cloud Platform [GCP]等）的采用。以下是选择混合和/或多云的一些关键业务原因：数据驻地法规：由于一些行业或地区对数据存储位置有严格的法规要求，一些组织可能永远不会完全迁移到公共云。这也适用于那些在没有公共云存在和数据驻地要求的国家进行工作负载的情况。遗留投资：一些客户希望保护他们的遗留工作负载，如SAP、Oracle或Informatica在本地的情况，但又希望利用公共云创新，比如Databricks和Snowflake等。过渡：大型企业通常需要多年的过渡过程，将其现代化为云原生应用程序和架构。他们将不得不在多年的时间里采用混合架构作为中间状态。云突发：有些客户主要在本地，不想迁移到公共云。然而，由于临时大批量作业、繁忙时段的突发流量或大规模机器学习训练作业，他们在满足业务服务水平协议（SLA）方面面临挑战。他们希望利用公共云中可扩展的容量或自定义硬件，避免在本地基础设施上进行规模扩大的成本。采用“本地优先”计算方法的解决方案，比如MotherDuck，正在变得流行。最佳选择：一些组织选择在不同的公共云提供商中执行不同的任务，这是一种有意的策略，选择最能满足其需求的技术。例如，Uber使用AWS为其Web应用提供服务，但在Google Cloud上使用Cloud Spanner来运行其履行平台。Twitter在AWS上运行其新闻提要，但在Google Cloud上运行其数据平台。既然你了解了选择混合解决方案的原因，让我们看看在使用这种模式时可能面临的主要挑战；这些挑战是混合应该被视为一种例外的原因，目标应该是云原生。混合云的挑战企业在实施混合或多云架构时面临一些挑战：治理在多个环境中应用一致的治理政策很难。例如，在本地环境和公共云之间通常以不同方式处理合规性安全策略。通常，在本地和云中数据的部分重复。想象一下，如果组织正在运行财务报告，如果数据存在于多个平台上，如何保证使用的数据是最新更新的副本呢？访问控制用户访问控制和策略在本地和公共云环境之间有所不同。云服务提供商为其提供的服务有自己的用户访问控制（称为身份和访问管理，IAM），而本地使用诸如本地目录访问协议（LDAP）或Kerberos等技术。如何保持它们同步或在不同环境之间拥有单一的控制平面呢？工作负载互操作性在跨越多个系统时，不可避免地会有需要管理的不一致的运行时环境。数据移动如果本地和云应用程序都需要访问某些数据，那么这两个数据集必须保持同步。在多个系统之间移动数据成本高昂——需要人力成本来创建和管理管道，可能由于使用的软件而产生许可成本，最后但同样重要的是，它会消耗计算、网络和存储等系统资源。组织如何处理来自多个环境的成本？如何连接在各种环境中孤立的异构数据？在连接过程的结果中，数据最终存储在何处？技能集拥有两个云（或本地和云）意味着团队必须了解并建立在两个环境中的专业知识。由于公共云是一个快速发展的环境，因此在一个云中提升员工的技能，更不用说在两个云中了，都会产生显著的开销。技能集对于招聘系统集成商（SIs）也可能是一个挑战——尽管大多数大型SIs都有每个主要云的实践，但很少有团队了解两个或更多的云。随着时间的推移，我们预计雇佣愿意学习定制本地技术的人将变得越来越困难。经济学数据分布在两个环境之间可能带来意想不到的成本：也许您在一个云中有数据，想要将其提供给另一个云，从而产生出站费用。尽管存在这些挑战，混合设置仍然是可行的。我们将在下一小节中看看如何解决这些问题。为什么混合云可以奏效云服务提供商意识到这些需求和挑战。因此，他们为混合环境提供了一些支持，主要分为三个方面：选择云服务提供商通常对开源技术做出重大贡献。例如，尽管 Kubernetes 和 TensorFlow 是在 Google 开发的，但它们是开源的，因此在所有主要云平台上都存在用于托管执行环境的版本，甚至可以在本地环境中使用。灵活性诸如 Databricks 和 Snowflake 的框架允许您在任何主要公共云平台上运行相同的软件。因此，团队可以学习一套在任何地方都适用的技能。需要注意的是，在多云环境中工作的工具所提供的灵活性并不意味着您已经摆脱了锁定。您将需要在（1）框架级别锁定和云级别灵活性之间进行选择（由 Databricks 或 Snowflake 等技术提供），以及（2）云级别锁定和框架级别灵活性之间进行选择（由云原生工具提供）。开放性即使工具是专有的，由于采用了开放标准和导入/导出机制，其代码也以可移植的方式编写。因此，例如，即使 Redshift 只在 AWS 上运行，但查询是用标准 SQL 编写的，并且存在多个导入和导出机制。综合考虑，这些功能使得 Redshift、BigQuery 和 Synapse 成为开放平台。这种开放性允许使用 Teads 等用例，其中数据使用 AWS 上的 Kafka 进行收集，使用 Google Cloud 上的 Dataflow 和 BigQuery 进行聚合，然后写回到 AWS Redshift（见图1-9）。云服务提供商正在通过大力投资于开源项目，致力于提供选择、灵活性和开放性，以帮助客户在多个云中使用。因此，多云数据仓库或混合数据处理框架正在变为现实。因此，您可以构建更好的云软件生产、发布和管理，以实现您期望的混合和多云部署，而不是按照供应商的规定。边缘计算混合模式的另一种体现是当您希望计算能力跨越通常的数据平台边界，可能直接与某些连接设备进行交互。在这种情况下，我们谈论的是边缘计算。边缘计算将计算和数据存储更靠近生成数据并需要处理数据的系统。边缘计算的目标是提高响应时间并节省带宽。边缘计算可以解锁许多用例，并加速数字转型。它在许多应用领域都有广泛的应用，例如安全、机器人技术、预测性维护、智能车辆等。随着边缘计算的采用和走向主流，对于各行业来说有许多潜在的优势：更快的响应时间在边缘计算中，数据存储和计算的能力被分布并在需要做出决策的地方提供。不需要往返到云端可以降低延迟，实现更快的响应。在预防性维护中，它有助于阻止关键机器操作的故障或危险事件的发生。在活动游戏中，边缘计算可以提供所需的毫秒级响应时间。在欺诈防范和安全场景中，它可以防范隐私泄漏和拒绝服务攻击。间歇性连接在偏远资产（如油井、农田泵、太阳能场或风车）存在不可靠的互联网连接可能使监测这些资产变得困难。边缘设备在本地存储和处理数据的能力确保在互联网连接有限的情况下不会发生数据丢失或操作失败。安全性和合规性边缘计算可以消除设备和云端之间的大量数据传输。可以在本地筛选敏感信息，只将关键的数据模型构建信息传输到云端。例如，在智能设备中，监听诸如“OK Google”或“Alexa”的语音处理可以在设备本身上进行。潜在的私人数据无需收集或发送到云端。这使用户能够构建适用于企业安全性和审计的适当安全和合规框架。经济实惠的解决方案围绕物联网采用的一个实际关切是由于网络带宽、数据存储和计算能力而导致的前期成本。边缘计算可以在本地执行大量数据计算，使企业能够决定哪些服务在本地运行，哪些发送到云端，从而降低整体物联网解决方案的最终成本。这就是在类似 Rust 或 Go 等现代编译语言构建的 Open Neural Network Exchange（ONNX）格式中进行嵌入模型的低内存二进制部署可以发挥作用的地方。互操作性边缘设备可以充当传统和现代机器之间的通信联络点。这使得传统工业机器能够连接到现代机器或物联网解决方案，并立即从传统或现代机器中获得洞察力。所有这些概念使得架构师在定义其数据平台时具有极大的灵活性。在第9章中，我们将更深入地探讨这些概念，并看到这种模式正在成为标准。应用人工智能许多组织因需要采用人工智能技术而被迫设计云数据平台——在设计数据平台时，确保其具备支持人工智能用例的未来性是非常重要的。考虑到人工智能对社会的巨大影响以及其在企业环境中的传播，让我们迅速深入了解如何在企业环境中实施人工智能。您将在第10章和第11章中找到更深入的讨论。机器学习如今，一种被称为监督机器学习的人工智能分支取得了巨大的成功，以至于人们更经常将术语“人工智能”用作该分支的总称。监督机器学习的工作原理是向计算机程序展示许多例子，其中正确答案（称为标签）是已知的。机器学习模型是一个标准算法（即完全相同的代码），具有可调参数，可以“学习”如何从提供的输入到标签。然后，这样一个学到的模型被部署用于对那些正确答案未知的输入进行决策。与专家系统不同，不需要通过编程显式地将规则传递给人工智能模型以做出决策。由于许多现实领域涉及到专家难以表达其逻辑的人类判断，让专家简单地为输入示例打标签比捕捉其逻辑更为可行。现代的国际象棋算法和医学诊断工具使用机器学习。国际象棋算法从人类过去玩过的游戏记录中学习，而医学诊断系统则通过专业医生为诊断数据打标签而学习。生成式人工智能是最近变得非常强大的人工智能/机器学习分支，它不仅能理解图像和文本，还能生成逼真的图像和文本。除了能够在营销等应用中创建新内容外，生成式人工智能还简化了机器与用户之间的交互。用户能够用自然语言提出问题并使用英语或其他语言自动执行许多操作，而无需了解编程语言。为了使这些机器学习方法运作，它们需要大量的训练数据和现成的定制硬件。因此，采用人工智能的组织通常从构建云数据/机器学习平台开始。机器学习的用途机器学习在工业界取得惊人的普及有几个关键原因：数据更容易获取。获取标记数据比捕捉逻辑更容易。每一种人类推理都有难以编码的例外情况，这些例外情况会随着时间的推移而被编码。让一组眼科医生标记一千张图像比让他们描述如何识别血管出血更容易。重新训练更容易。当机器学习用于推荐物品给用户或运行营销活动等系统时，用户行为会迅速适应变化。持续训练模型变得很重要。这在机器学习中是可能的，但使用代码要困难得多。更好的用户界面。一类被称为深度学习的机器学习已被证明能够在非结构化数据（如图像、视频和自然语言文本）上进行训练。这些类型的输入通常很难进行编程。这使得您可以将真实世界的数据用作输入，比如考虑一下，当您只需拍摄支票的照片而无需在网页表单中键入所有信息时，存款检查的用户界面会变得更好。自动化。机器学习模型理解非结构化数据的能力使得许多业务流程可以自动化。表单可以轻松数字化，仪表盘可以更容易读取，工厂车间可以更容易监控，因为可以自动处理自然语言文本、图像或视频。成本效益。赋予机器理解和创建文本、图像、音乐和视频的机器学习API每次调用成本仅为几分之一，而雇佣人类执行这些任务的成本则高得多。这使得在推荐等情况下使用技术成为可能，而个人购物助手的成本则无法承受。协助。生成式人工智能可以使开发人员、营销人员和其他白领工作者更加高效。编码助手和工作流合作伙伴能够简化许多企业职能的部分，比如发送定制的销售电子邮件。考虑到这些优势，不难理解哈佛商业评论的一篇文章发现，人工智能通常支持三个主要的业务需求：自动化业务流程，通常是自动化后勤行政和财务任务。通过数据分析获取洞察。与客户和员工互动。机器学习通过使用数据示例解决这些问题，无需为每件事都编写自定义代码，从而增加了可扩展性。然后，诸如深度学习等机器学习解决方案允许解决这些问题，即使数据包含非结构化信息，如图像、语音、视频、自然语言文本等。为什么选择云进行人工智能？设计云数据平台的一个关键动机可能是组织迅速采用深度学习等人工智能技术。为了使这些方法运作，它们需要大量的训练数据。因此，计划构建机器学习模型的组织将需要建立一个数据平台，以组织和向其数据科学团队提供数据。机器学习模型本身非常复杂，训练这些模型需要大量称为图形处理单元（GPU）的专用硬件。此外，人工智能技术，如语音转录、机器翻译和视频智能，往往作为云上的软件即服务（SaaS）提供。此外，云平台提供了民主化、更容易操作和跟上技术最新进展的关键能力。云基础设施要点是高质量的人工智能需要大量的数据。一篇著名的论文标题为“深度学习的规模是可以预测的，经验证明”发现，对于自然语言模型的5%改进，需要训练的数据量是用于获得第一个结果的两倍。最好的机器学习模型不一定是最先进的，而是那些在足够高质量的数据上进行训练的模型。原因在于越来越复杂的模型需要更多的数据，而即使是简单的模型如果在足够大的数据集上进行训练，性能也会提高。为了让您了解完成现代机器学习模型训练所需的数据量，图像分类模型通常在一百万张图像上进行训练，而主要的语言模型则在多个 terabyte 的数据上进行训练。正如图1-10所示，这种数据量需要大量高效的定制计算——由加速器（如GPU）和称为张量处理单元（TPU）的定制应用特定集成电路（ASICs）提供——以利用这些数据并理解它。许多最近的人工智能进步都可以归因于数据规模和计算能力的增加。云中大型数据集与支持它的众多计算机之间的协同作用已经促使机器学习取得了巨大的突破。这些突破包括将语音识别中的词错误率降低了30%，是传统方法中20年来取得的最大增益。民主化建模机器学习模型，特别是在复杂领域，如时间序列处理或自然语言处理（NLP），需要对机器学习理论有所了解。使用诸如PyTorch、Keras或TensorFlow等框架编写用于训练机器学习模型的代码需要了解Python编程和线性代数。此外，机器学习的数据准备通常需要数据工程专业知识，评估机器学习模型需要高级统计知识。部署机器学习模型和监控它们需要了解DevOps和软件工程（通常称为MLOps）。毫无疑问，很少有组织具备所有这些技能。鉴于此，对于传统企业来说，利用机器学习解决业务问题可能会很困难。云技术提供了几种选项来使机器学习的使用民主化：机器学习APIs：云提供商提供可通过API调用的预构建机器学习模型。此时，开发人员可以像使用任何其他Web服务一样使用机器学习模型。他们只需具备针对表述状态转移（REST）Web服务进行编程的能力。此类机器学习API的示例包括Google Translate、Azure Text Analytics和Amazon Lex，这些API可以在不了解NLP的情况下使用。云提供商还提供用于文本和图像生成的生成模型作为API，其中输入只是文本提示。可定制的机器学习模型：一些公共云提供“AutoML”，即端到端的机器学习管道，只需点击鼠标即可进行训练和部署。AutoML模型执行“神经架构搜索”，通过搜索机制实质上自动进行机器学习模型的架构设计。虽然与人类专家选择有效模型相比，训练时间较长，但对于没有能力设计自己模型的业务线来说，AutoML系统足够使用。请注意，并非所有的AutoML都相同，有时所谓的AutoML只是参数调整。确保您获得的是定制的架构，而不仅仅是在预构建模型之间进行选择，并仔细检查哪些步骤可以自动化（例如，特征工程、特征提取、特征选择、模型选择、参数调整、问题检查等）。简化的机器学习：一些数据仓库（例如BigQuery和Redshift）提供了仅使用SQL对结构化数据进行机器学习模型训练的能力。Redshift和BigQuery通过分别委托给Vertex AI和SageMaker来支持复杂模型。诸如DataRobot和Dataiku之类的工具提供了用于训练机器学习模型的点对点界面。云平台使生成模型的微调比以前更容易。机器学习解决方案：一些应用非常常见，可以购买和部署端到端的机器学习解决方案。Google Cloud上的Product Discovery为零售商提供了端到端的搜索和排名体验。Amazon Connect提供了一个由机器学习驱动的可立即部署的联系中心。Azure Knowledge Mining提供了一种挖掘各种内容类型的方式。此外，Quantum Metric和C3 AI等公司为几个行业的常见问题提供了基于云的解决方案。机器学习构建块：即使整个机器学习工作流没有现成的解决方案，其中的部分工作可能仍然可以利用构建块。例如，推荐系统需要匹配项目和产品的能力。Google Cloud提供了一种称为“两塔编码器”的通用匹配算法。虽然没有端到端的后勤自动化机器学习模型，但您可以利用表单解析器更快地实现该工作流程。这些功能使企业能够在没有深度专业知识的情况下采用人工智能，从而使人工智能更广泛地可用。即使企业具有人工智能方面的专业知识，这些功能也非常有用，因为您仍然需要决定是购买还是构建机器学习系统。通常情况下，机器学习的机会比解决这些问题的人更多。鉴于此，允许使用预构建工具和解决方案执行非核心功能具有优势。这些即插即用的解决方案可以立即提供大量价值，而无需编写定制应用程序。例如，可以通过API调用将自然语言文本的数据传递给预构建模型，将文本从一种语言翻译为另一种语言。这不仅减少了构建应用程序的工作量，还使非机器学习专家能够使用人工智能。在谱的另一端，问题可能需要自定义解决方案。例如，零售商通常会构建机器学习模型来预测需求，以便了解需要备货多少产品。这些模型通过公司的历史销售数据学习购买模式，结合内部专业直觉。另一个常见的模式是使用预构建的即插即用模型进行快速实验，一旦证明了ML解决方案的价值，数据科学团队就可以以定制的方式构建它，以获得更高的准确性，希望能够在竞争中脱颖而出。实时ML基础设施必须与现代数据平台集成，因为实时、个性化的机器学习是产生价值的地方。因此，分析速度变得非常重要，因为数据平台必须能够实时摄取、处理和提供数据，否则就会失去机会。这还需要与行动的速度相辅相成。机器学习推动基于客户上下文的个性化服务，但必须在客户上下文切换之前提供推断——在大多数商业交易中，机器学习模型需要在关闭窗口内为客户提供行动选择。为了实现这一点，您需要使机器学习模型的结果能够实时到达行动点。能够实时为机器学习模型提供数据并在实时获取机器学习预测是防范欺诈和发现欺诈之间的区别。为了防范欺诈，需要实时摄取所有支付和客户信息，运行机器学习预测，并将机器学习模型的结果实时提供回支付站点，以便在怀疑欺诈时拒绝付款。实时处理可以在其他情况下节省成本，例如客户服务和购物车放弃。在呼叫中心捕捉客户的不满并立即升级情况对于提供有效服务至关重要——一旦失去客户，重新获取他们将花费更多的钱，而在当下提供良好服务的成本较低。同样，如果购物车有被放弃的风险，提供5%的折扣或免费运输等诱因的成本可能会低于需要让客户回到网站所需的更大力度的促销。在其他情况下，批处理根本不是一个有效的选择。为了使Google Maps允许驾驶员避开交通拥堵，需要实时交通数据和实时导航模型。正如您将在第8章中看到的那样，云服务的弹性和自动扩展能力在本地很难实现。因此，最好在云中进行实时机器学习。MLOPSML在公共云中更好的另一个原因是，使ML运营化是困难的。有效和成功的ML项目需要对数据和代码进行运营化。观察、编排和执行ML生命周期被称为MLOps。在生产中构建、部署和运行ML应用程序涉及多个阶段，如图1-11所示。所有这些步骤都需要进行编排和监视；例如，如果检测到数据漂移，可能需要自动重新训练模型。必须持续对模型进行重新训练并进行部署，确保它们可以安全地部署。对于传入的数据，您必须执行数据预处理和验证，以确保没有数据质量问题，然后进行特征工程，接着进行模型训练，最后进行超参数调整。除了讨论的与数据相关的监控方面之外，您还需要对任何运行中的服务进行监控和运营化。生产应用程序通常是24/7/365持续运行的，定期会有新的数据进入。因此，您需要具备工具，使得轻松编排和管理这些多阶段的机器学习工作流程，并能够可靠地重复运行它们。像Google的Vertex AI、Microsoft的Azure Machine Learning和Amazon的SageMaker这样的云AI平台提供了整个机器学习工作流的托管服务。在本地进行这项工作需要您自己组合底层技术并自行管理集成。在编写本书时，MLOps功能正在以极快的速度添加到各种云平台上。这引出了一个附带的观点，即随着机器学习领域的快速变化，将构建和维护机器学习基础设施和工具的任务委托给第三方，并专注于与核心业务相关的数据和见解，会更为明智。总而言之，基于云的数据和人工智能平台可以帮助解决与数据隔离、治理和容量相关的传统挑战，同时使组织能够为未来更加重要的人工智能能力做好准备。核心原则设计数据平台时，制定关键设计原则并确定希望分配给每个原则的权重可能会有所帮助。您可能需要在这些原则之间进行权衡，拥有一个所有利益相关者都同意的预定评分卡可以帮助您在不必返回第一原则或受到最强烈抗议声响影响的情况下做出决策。以下是我们建议的数据分析堆栈的五个关键设计原则，尽管相对权重会因组织而异：提供无服务器分析，而不是基础设施。为完全托管的环境设计分析解决方案，尽量避免搬移和转移的方法。专注于现代无服务器架构，使数据科学家（我们广义上使用此术语来指数据工程师、数据分析师和ML工程师）能够将注意力完全集中在分析上，远离基础设施考虑。例如，使用自动化数据传输从系统中提取数据并提供用于跨任何服务进行联合查询的环境。这消除了维护自定义框架和数据管道的需要。嵌入端到端ML。允许组织将端到端的ML操作化。不可能构建组织需要的每个ML模型，因此确保您正在构建的平台能够嵌入民主化的ML选项，如预建的ML模型、ML构建模块和更易于使用的框架。确保在需要自定义训练时，可以访问强大的加速器和可定制的模型。确保支持MLOps，以便部署的ML模型不会漂移并且不再适用。简化整个堆栈上的ML生命周期，以便组织可以更快地从其ML倡议中获取价值。推动整个数据生命周期的分析。数据分析平台应提供一套全面的核心数据分析工作负载。确保您的数据平台提供数据存储、数据仓库、流数据分析、数据准备、大数据处理、数据共享和变现、商业智能（BI）和ML等服务。避免购买需要集成和管理的临时解决方案。更全面地看待分析堆栈将允许您打破数据隔离，使用实时数据为应用程序提供动力，添加只读数据集，并使查询结果对任何人都可访问。启用开源软件（OSS）技术。在可能的情况下，确保开源是您平台的核心。您希望确保您编写的任何代码都使用开源标准，如标准SQL、Apache Spark、TensorFlow等。通过启用最佳的开源技术，您将能够在数据分析项目中提供灵活性和选择性。为增长而构建。确保您构建的数据平台能够满足组织预期面临的数据大小、吞吐量和同时用户数量的规模。有时，这将涉及选择不同的技术（例如，对于某些用例使用SQL，对于其他用例使用NoSQL）。如果这样做，请确保您选择的两种技术能够互操作。利用已被世界上最具创新性的公司证明并用于运行其关键任务的解决方案和框架。总体而言，这些因素按照我们通常建议的顺序列出。由于企业选择进行云迁移的两个主要动机是成本和创新，我们建议您优先考虑无服务器（用于节省成本和使员工摆脱例行工作）和端到端ML（用于启用的广泛创新）。在某些情况下，您可能希望优先考虑某些因素而不是其他因素。对于初创公司，我们通常建议最重要的因素是无服务器、增长和端到端ML。为了加快速度，可以牺牲综合性和开放性。高度受监管的企业可能会优先考虑综合性、开放性和增长，而不是无服务器和ML（即监管机构可能要求在本地进行）。对于数字原生企业，我们建议按照端到端ML、无服务器、增长、开放性和综合性的顺序。总结这是关于数据平台现代化的高层介绍。从数据生命周期的定义开始，我们看了数据处理的演变，传统方法的局限性，以及如何在云上创建统一的分析平台。我们还研究了如何将云数据平台扩展为混合平台，并支持AI/ML。本章的主要要点如下：数据生命周期有五个阶段：收集、存储、处理、分析/可视化和激活。这些需要由数据和ML平台支持。传统上，组织的数据生态系统由独立的解决方案组成，导致组织内部产生数据孤岛。数据移动工具可以打破数据孤岛，但它们会带来一些缺点：延迟、数据工程资源瓶颈、维护开销、变更管理和数据缺失。在IT内部集中控制数据会导致组织面临一些挑战。IT部门没有必要的技能，分析团队得到质量较差的数据，业务团队不信任结果。组织需要构建云数据平台，以获取最佳架构、处理业务单元的整合、扩展本地资源并规划业务连续性。云数据平台利用现代方法，旨在通过重新构建数据、打破数据孤岛、使数据民主化、强制数据治理、实时决策和使用位置信息进行数据驱动创新，以及从描述性分析无缝过渡到预测性和规范性分析。所有数据可以从操作系统导出到一个集中的数据湖进行分析。数据湖充当分析工作负载和业务用户的中央存储库。然而，缺点是业务用户没有编写代码对抗数据湖的技能。数据仓库是支持SQL的集中式分析存储，业务用户熟悉这一点。数据湖仓库基于这样一个观念，即所有用户，无论其技术技能如何，都可以并且应该能够使用数据。通过提供一个使数据可访问的集中和基础框架，可以在湖仓库顶部使用不同的工具来满足每个用户的需求。数据网格引入了将数据视为独立产品的一种方式。在这种方法中，分布式团队拥有数据生成，并通过明确定义的数据模式为内部/外部消费者提供服务。混合云环境是满足企业现实情况的务实方法，如收购、当地法律和延迟要求。公共云提供管理大型数据集和按需提供GPU的方式，使其成为所有形式的ML，特别是深度学习和生成AI不可或缺的工具。此外，云平台提供了民主化、更容易操作和跟上技术进展的关键能力。云数据平台的五个核心原则是优先考虑无服务器分析、端到端ML、全面性、开放性和增长。相对权重将因组织而异。现在您知道自己想要的方向，在下一章中，我们将探讨达到目标的策略。

浏览量2099

攻城狮无远

第二章：创新数据的战略步骤

您的领导之所以为您建立数据平台提供资金，很可能是因为他们希望组织进行创新。他们希望组织能够发现经营的新领域，创造更好的业务运作方式，或为更多客户提供更高质量的产品。这种形式的创新通常通过更好地了解客户、产品或市场来实现。无论您的组织是想要减少用户流失、获取新用户、预测产品的维修周期，还是确定低成本替代品是否会受欢迎，任务始于数据收集和分析。数据是分析业务当前状态、识别缺陷或机会、实施改进现状的方式以及衡量这些变化影响的必需品。通常，必须将业务单元特定的数据与其他数据（来自整个组织以及来自供应商和市场的数据）一起进行分析。在构建数据平台时，重要的是要有意识地将最终的“为什么”（促进创新）牢记在心。在本章中，您将了解构建促进创新的平台时应采取的七个战略步骤，为什么这些步骤是必不可少的，以及如何使用现代云技术实现它们。将这些步骤视为构建金字塔的基石（如图2-1所示），其中每个步骤都作为随后步骤的基础。在本章中，我们将明晰说明所有步骤背后的概念，但将其实现的详细信息推迟到后续章节。例如，虽然我们将在本章描述打破信息孤岛的概念，但我们将在第5、6和7章中描述实现这一目标的分析中心或数据网格方法的架构。步骤1：战略规划为了使最后的六个步骤成功，首先需要制定一项战略计划，其中需要识别三个主要组成部分：目标组织在充分利用数据方面的雄心是什么？重要的是要深入挖掘，确定超越成本节约的目标。具体而言，重要的是要确定将使用数据做出的决策以及可以通过哪些指标了解转变是否成功。利益相关方在组织中，谁有权力赞助和推动更深层次的变革？确保将所有这些利益相关方聚集在一起——根据我们的经验，IT 项目往往资源不足，常常面临失败的风险，而业务驱动的项目则有更长期的高层支持和资金支持。业务项目还具有更高的投资回报率。变革管理流程如何有效地将方法层层传递并传达给整个组织，以获取最终用户的支持？这种战略规划需要定期审视。目标是否仍然相同？是否有新的利益相关方需要了解情况？是否在队伍中酝酿着不满？让我们逐一看看这三个组成部分。战略目标在构建数据和AI/ML平台时，您应该明确自己的目标。很多时候，利益相关者会以当前平台的局限性为目标，例如，如果您当前最令人头痛的问题是报告工作负载导致级联宕机，目标可能会表述为“我们希望能够在三小时内为我们的三百万客户创建月度对账单”。然而，在构建平台的目标不应该被一个单一的用例狭隘地定义。相反，您希望从对您想要实现的战略目标的清晰理解开始。基于业务的战略方向来设计系统。对于新购买提供信息的期望周转时间是多少？客户数量的预期增长是多少？通过手机还是通过经纪人到达的客户比例会随时间而变化吗？IT团队的预期人数是多少？业务是否希望让现场人员做出更多决策？您是希望发送月度对账单，还是希望根据需求动态生成历史活动报告？我们计划通过这些报告赚取钱？我们是否会根据这些结果改变业务做法？报告需要提供什么样的支持来支持我们当前的业务？当前平台无法支持这些需求将自然从这些战略关注中产生，但这使您能够全面地构建系统的要求，而不是被单一用例和老旧思维所束缚。这还有助于您向非技术高管传达对系统的需求。如果可能的话，获取未来两三年内这些战略业务目标的数值估算，以帮助您做出具有成本效益的决策。例如，简单地说“查询应尽可能快地运行”可能很诱人，但这是建造一个过度工程化和昂贵系统的方法。相反，如果您知道在高峰时期会有1,500个并发查询，每个查询处理100GB的数据，需要在10秒内运行，您可以选择实现目标而不破坏银行的技术。这也可以反向运作。了解业务以60%的年同比速度获取客户，可能清楚地显示点击流数据集有望达到每天1TB的量级。这将阻止您做出短视的决策，需要撤销。这通常受到您可以预见业务增长的时间范围的限制。它还受到现实世界事件的影响。例如，2020年的COVID-19大流行颠覆了许多企业的计划，加速了转向数字和全渠道体验的步伐。有时，您构建的系统必须被废弃并重新构建，但通过全面考虑应急情况，可以最大限度地减少这种情况发生的频率。尽管细节可能有所不同，但我们发现大多数组织确定的战略目标最终需要他们的数据平台具备以下特点：降低运营数据和AI平台的成本。尤其是随着数据集大小的增长，线性增长的IT成本可能难以持续。加速新项目产生价值的时间，从而增加创新速度。对新想法进行实验不应该面临几个月的延迟，如采购机器、安装软件、获取数据集访问权限等。民主化从数据中获得的见解。使领域专家和现场人员能够直接与数据交互并获得见解。在决策中纳入预测分析，而不仅仅是描绘性分析。例如，不仅要测量上周使用的材料量，还要基于最近过去的使用量来预测下周所需的材料量。这些因素的相对优先级在企业之间会有所不同（这也是应该的）。许多初创公司和数字原生公司强调创新速度和灵活性的增长，而许多成熟企业强调成本而不是灵活性。例如，初创公司可能会使用PB级的DWH，即使其数据规模较小，因为它预计将看到10倍的年度增长。与此相反，更成熟的企业可能选择使用批处理，因为它比流处理更便宜。这些不同的起点影响可能的创新和增长类型 - PB级的DWH可能使初创公司能够基于每次交易的每次付款推荐，而更成熟的企业可能仅每天发送一次推荐电子邮件，而且只向进行大额订单的客户发送。确定利益相关者确立战略的基础是正确的需求收集。为了成功做到这一点，非常重要的是要确定组织内能够理解需求并在所有不同业务单元之间有效协作的正确人员，以降低选择错误方法和解决方案的风险。但是，谁是正确的人呢？我们是指来自业务方面的人（例如，首席执行官或首席财务官[CFO]），还是更好地依赖于IT团队（例如，首席信息官[CIO]、首席技术官[CTO]、首席数据官[CDO]等）？嗯，这实际上取决于组织。我们见过许多不同的方法，但一个共同的主题是，当直接由业务支持时，这种转型过程通常具有最高的成功率。为什么呢？很多时候，IT组织可能只被授权保持运营并在年复一年中降低成本。如果您的利益相关者仅在IT中，他们的激励与如果您的利益相关者包括需要开发新产品、触及更多客户或从根本上改变业务的BU中的人是非常不同的。通过使新数据平台的定义不仅仅是纯粹的IT活动，您可以提高转型的可见性，并确保新平台允许组织解决以前无法解决的许多业务问题（例如，实时分析）。即使在支持该倡议的公司领域内，也要确保所有参与其中的人都全力以赴是至关重要的。但是，这些人可能非常忙碌，没有足够的时间和专业知识来投入到这个转型项目中。因此，另一个关键问题是：公司是否有足够的内部人员（具有正确的技能和经验）来支持该倡议？或者您是否需要在公司外找到某人来引导项目朝着正确的方向发展？这不仅仅涉及技术知识，还涉及领导和管理，以确保数据平台的设计和实施成功，并且业务结果是积极的。变更管理一旦确定了目标和应该引导实现目标的人员，接下来必须为变更管理定义一个策略。组织可能拥有最雄心勃勃的目标，由最有影响力的人支持，但如果没有明确的任务来有效地将信息传达到组织内部，实施项目将变得非常困难。在接受像以数据为驱动的变革这样的项目时，我们看到很多公司忽视了将变革的文化方面放在重要位置，将其视为一项纯粹的技术项目。业务用户和一般将利用数据平台的员工应准备好接受变革，而这只能通过适当的流程和正确的技能来实现。如图2-2所示，变更管理是人、技术和流程之间的交集：人和技术开发全面的培训计划是至关重要的，以使员工能够利用组织内为他们提供的新资源。这可以由公司自己（内部提供）或由合作伙伴（外部提供）完成。组织越强调提升员工技能，就越能成功地实现其整体业务目标。人和流程这总是领导层的问题。公司内部的领导必须促使整体信息传达；当人们受到领导层的激励时（这也是利益相关者非常重要的另一个方面！），采用水平就会提高。我们看到很多项目因为缺乏来自发起倡议的同一人员的适当支持而失败。领导者有必要通过几次内部宣传活动，适当地在公司内传播信息，帮助人们拥抱变革。一些建议的问题是：团队结构如何？它们是否得到了高管的支持？云项目的预算、治理和评估是如何进行的？流程和技术这与组织利用云原生服务进行扩展的能力有关。一些建议的问题包括：组织在多大程度上使用托管和无服务器云服务抽象基础设施？自动化流程和运行通过其的可编程基础架构的实施水平如何？自动化是成功的关键因素，因为它一方面减少了人力投入，另一方面有助于进行低风险和频繁的变更，这是创新的关键要素。成功需要这三个元素协同工作。许多组织通过建立一个名为卓越中心（CoE）的专门小组来实现这一点，其目标是确定方向并推动公司朝着人-流程-技术的和谐方向发展。我们将在第12章中通过一个具体的示例重新审视这一概念。步骤2：通过采用云方法降低总体拥有成本（TCO）对于大多数企业来说，在制定战略之后的第一步是制定（并找到）预算。将企业数据仓库（DWH）和数据湖迁移到云端可以大大节省传统实施的成本。让我们看看为什么会这样以及如何为实现最大节省做好准备。云端为何成本更低将数据迁移到云端可以因为多种因素为您节省资金：运营成本降低在本地，贵公司需承担整个系统的运营成本，并且很多维护工作都是手动进行的。云服务提供商（我们将其称为超大规模提供商）则通过构建非常高效的方式来管理大型机群。例如，亚马逊通过在低利润业务中运行世界上最大、最可靠的网站之一，将这方面的专业知识带到云基础设施中，并提供非常低的成本。同样，谷歌运行着九个服务，必须以非常高效的方式运行，因为每个服务（如搜索、Gmail 和 YouTube）有超过十亿的免费用户使用。公共云的用户由于云服务运营中内置的高度自动化而受益，绝大多数云服务不需要维护，因为大多数活动（如硬件维护、安全检查、软件包更新等）在幕后自动管理。计算和存储的适度规模与购买与预期峰值使用量相匹配的设备不同，云提供商允许您根据需求和使用情况调整计算资源的规模。例如，您可以从小规模开始，随着需要创建的报告数量随时间增长而增加机器的数量。这个好处既适用于云提供商的服务（如Amazon EMR、Google Cloud Dataproc 和Azure HDInsight），也适用于在云基础设施上运行的第三方工具，如Databricks 或Teradata Vantage。工作负载的自动缩放许多云服务（例如Azure Cosmos DB、AWS Aurora、Google Cloud Composer、Snowflake 和Actian Avalanche）允许您在高峰时段分配更多机器，在低峰时段分配更少机器。请注意，我们说的是更少的机器，而不是零机器。尽管在非工作时间完全关闭服务可能很诱人，但请考虑是否真的希望保留那种实体店的模式。您公司的网站希望在晚上不关闭。您的后端系统也不应该关闭。在晚上保留服务紧急请求的能力通常会取得戏剧性的效果。无服务器工作负载一些现代云服务（例如Google Cloud Platform 上的BigQuery、AWS 上的Athena、Azure Functions）是无服务器的 - 您可以提交代码，系统会帮您执行。将无服务器系统视为在所有超大规模提供商的客户之间共享的自动缩放集群。因此，无服务器系统将云基础设施操作的成本优势提升到整个堆栈。由于劳动力往往是IT预算中最昂贵的项目，无服务器云服务将带来成本效益最高的解决方案。请注意，许多供应商将其自动缩放服务定位为“无服务器”，因此您应验证所涉服务是否真正是无服务器 - 只有在是多租户的情况下，您才能获得无服务器解决方案的劳动力成本优势。如果群集属于您，您将需要管理该群集（例如，找出谁在群集上运行什么作业以及何时运行），因此您将无法获得无服务器解决方案的劳动力成本优势。既然您对为何云可能成本较低有了更好的理解，那么让我们来看看如何估算您可能实现的节省金额。节省多少成本呢？在图2-3中，我们展示了我们在一个真实的数据湖上进行的概念验证（PoC）的结果。我们首先将工作负载不加修改地转移到了云上，然后将其放到了可伸缩的基础设施上，最后进行了现代化改造。我们测量了云成本会是多少。由于这是一个PoC，系统在这些配置下运行的时间不足以测量运行这些系统的人员成本。实际节省的金额当然会根据您平台和工作负载的具体细节而异。作为一个粗略的估计，将工作负载不加修改地转移到云上通常会提供约10%的节省。添加合适大小通常会额外增加5%。自动伸缩通常会增加40%的节省，而无服务器通常会额外增加30%。如果您充分利用所有这些节省，例如通过将在本地使用Hive的工作负载更改为在云上使用无服务器解决方案，成本节省可高达95%。在将工作负载迁移到云上之前，分析源工作负载是至关重要的。在某些情况下，纯粹的搬迁可能不会有益，因为工作负载是为利用本地环境的特定硬件功能而开发的。在这些情况下，评估更新代码（如果可能）以使工作负载现代化，并使其能够利用自动伸缩和无服务器功能是很重要的。云计算何时有助于？在所有这些背后的是基本的云经济学。忽略价格折扣的影响，用 10 台机器运行一个任务 10 小时的成本与用 100 台机器运行一个小时的任务的成本相同，或者与在 1,000 台机器上运行任务 6 分钟的成本相同。能够在多租户集群中为您提供 1,000 个“热”实例的能力是使无服务器成本效益如此高效的原因。当然，这不仅仅是成本问题——如果一个操作在今天需要花费 10 小时，而现在可以在 6 分钟内得到结果，这样更及时的决策可能带来的业务价值远远超过了计算成本的增加。有哪些工作负载不适合完全迁移到云？从一般的角度来看，任何类型的工作负载都可能成为云环境获取前述所有好处的潜在目标。可能有一些情况，混合方法（例如，在本地环境中的工作负载的一部分以及云中的其余部分），我们将在第 9 章深入探讨，可能更适合一些情况：比如一个稳定的工作负载（即，不需要增长且没有峰值），规模大，非常特定，比如全球尺度的数值天气预报模型。在这种情况下，有一部分工作负载需要专业硬件（例如，共享内存，高速互连），这消除了云的即时硬件成本优势，以及需要了解天气模型的专业运维人员，并且它几乎每天都经历相同的负载。这一部分可以保留在本地，同时拥有其他可以立即从云采纳中受益的相关元素（例如，数据备份）。短暂且峰值的工作负载往往最能从云迁移中受益，主要是通过减少花费宝贵时间进行资源配置的需要。短暂和峰值工作负载还将受益于自动缩放和按使用量付费的云经济学。因此，在基于成本的优先考虑云迁移时，请从短暂和峰值工作负载开始。此外，与云计算相比，与员工流失相关的风险降低了，因为技术栈是众所周知的，企业支持是可用的。另一方面，使用定制数据中心，你的 IT 部门可能会受到许多限制！第3步：打破信息孤岛在将所有数据迁移到云端后，您可以开始思考如何更好地从中获取价值。开始从数据中获取价值的最佳方法之一是打破数据孤岛。换句话说，避免拥有多个不相关、分离且有时不可见的数据集。我们现在处于图2-1金字塔的第三层。打破数据孤岛涉及在分散和价值之间找到合适的平衡。分散是好的，因为数据距离领域专家越远，数据质量就降低。因此，您必须让领域专家对数据负责。不要将数据集中在IT中。同时，请记住，通过结合组织内的数据甚至是合作伙伴共享的数据，您可以获得最大的AI/ML价值。打破组织不同部分之间的隔离是关键。如何解决这个问题？如何让组织的不同部分保持对其数据的控制，同时为任何有权访问数据的人提供访问权限？我们将在以下部分探讨如何做到这一点。统一数据访问在云上实现数据的统一存储位置并不意味着要采用中央所有权结构。例如，数据可以存储在Azure Blob Storage上，但每个部门都可以将“他们的”数据放在“他们的”存储桶中。对数据的访问应该通过云服务提供商的身份和访问管理（IAM）进行管理。避免将本地身份验证机制（如LDAP或Kerberos）带到云上。如果需要维护混合基础架构，在本地的Kerberos角色可以映射到云上的IAM。如果使用需要自己的身份验证机制（例如MySQL）的软件，请使用身份验证代理以避免登录机制的多样化。避免使用既不提供IAM也不提供IAM代理的软件。将数据和见解锁定将在长期内给你带来很多困扰，无论该软件在近期有什么好处。如果使用多云，请确保在SaaS单点登录（SSO）身份验证机制上进行标准化，例如Okta，然后将Okta身份验证映射到各个云的IAM。另一种方法是，如果您有一个“主”云，可以将该云的IAM与其他云进行联合：例如，如果Azure是您的主云，但您希望在Google Cloud上执行一些数据工作负载，则可以将Google Cloud Identity与Azure Active Directory进行联合。确保基于实际发出请求的用户对数据进行审计，而不是通过破坏与个人用户的关联的服务账户。由于有关数据访问的隐私和政府法规继续变得更为严格，避免陷入任何以其自己的云项目中运行或以不透明方式读取数据的软件。这意味着每个部门都将管理其数据并对其进行分类。例如，他们可以将数据仓库中的某些列标记为包含财务数据。数据治理政策可能是只有会计和副总裁以上级别的人员被允许查看财务数据。此政策由IT部门（而不是数据所有者）使用云IAM来强制执行。不要陷入中央控制数据以打破数据隔离的诱惑。数据质量会随着距离领域专家的距离而降低。您希望确保领域专家创建数据集并拥有存储桶。这允许本地控制，但对这些数据集的访问将通过云IAM角色和权限进行控制。使用加密、访问透明性和遮蔽/动态技术可以帮助确保即使数据准确性的责任属于领域团队，也能实现全组织的安全性。选择存储存储数据的选择取决于数据的类型：结构化和半结构化数据应存储在专为SQL分析进行优化的位置。Google BigQuery、AWS Redshift、Azure Synapse、Actian Avalanche、Snowflake 等是不错的选择。这些工具允许您集中数据，同时由不同团队管理不同的数据集，但作为同一大型数据仓库的一部分。另一种选择是将结构化或半结构化数据存储在开放格式中，比如使用分布式表格格式（如Apache Iceberg或Databricks Delta Lake）在云块存储（如AWS S3）之上，例如Parquet。虽然在使用这些开放格式（而不是BigQuery中的原生存储机制，比如Capacitor）存储数据时可能在SQL分析中稍微降低性能，但存储成本更低并且支持非SQL分析（如机器学习）的灵活性可能是值得权衡的。无结构数据应存储在为从各种计算引擎读取进行优化的格式和位置。使用标准的云友好格式，如Parquet、Avro、TensorFlow Records 和 Zarr，并将文件存储在Google Cloud Storage、Azure Blob Storage 或 AWS S3上。逗号分隔值（CSV）和JavaScript对象表示法（JSON）是人类可读且相对易于处理的格式，因此也有其用武之地。通常，每个分析数据集或存储桶将位于单个云区域（或多个区域，如欧盟或美国）。我们将这样的存储层称为分布式数据层，以避免陷入数据湖与数据仓库的争论。鼓励团队提供对其数据集的广泛访问（"默认开放"）。数据所有者控制访问权限，并负责对受组织范围数据治理政策约束的数据进行分类。专业团队还可能有能力标记数据集（用于隐私等）。对其数据集的权限由数据所有者管理。培养您的团队，使他们能够发现和标记数据集，并构建集成流水线，不断增加分布式数据层的广度和覆盖范围。语义层在构建民主化数据文化时可能出现的一个附带效应是可能会看到分析孤立。同一变量可能在组织的不同部分以不同的列名被称为。每次计算关键绩效指标（KPI）都是计算它的一次机会，有可能以错误或不一致的方式计算。因此，鼓励数据分析团队构建一个语义层（以便可以标准化词汇表并可以在其他所有地方计算一次并重复使用KPI），并通过它应用治理——见图 2-4。类似 Looker、Informatica、Collibra、AtScale 和 Cube 的工具可以帮助定义和标准化语义层。使用这些工具的优势是它们是多云的，并且可以跨足在场地和云之间。因此，您可以在所有环境中标准化数据治理。在云上，实际的查询是由底层的数据仓库执行的，因此在使用这些工具创建仪表板时不会发生数据复制。不要制作数据副本。提取和复制会增加安全风险，使数据依赖关系难以追踪，并降低分析的及时性。建立一个轻量级的语义层，并将计算带到单一数据源。还有一种趋势是在不同环境中提供一致的控制界面。例如，Google 的 BigQuery Omni 允许您在 BigQuery 界面中处理 AWS S3 存储桶、Azure Blob 存储和 MySQL 中的数据。Informatica、Collibra、Looker 等工具提供了对不同云和本地环境中数据的一致界面。正如您所见，消除数据孤岛是释放数据潜力的关键步骤，因为它实现了团队之间更好的可见性和更好的协作。现在让我们看看如何进入下一步，以更快地利用您手头的这些数据。第四步：更快地在上下文中做决策商业决策的价值随着延迟和距离的增加而降低。例如，假设你能够在一分钟内或一天内批准一笔贷款。一分钟的批准时间比一天的批准时间要更有价值得多。同样，如果你能够做出一个考虑到空间上下文（无论是基于用户当前居住地还是当前访问地点）的决策，那么这个决策就比不考虑空间上下文的决策更有价值。因此，你的平台现代化的一个重要目标应该是，在不复制数据的情况下，可以在数据上执行地理信息系统（GIS）、流处理和机器学习（ML）操作。前一节的原则，即将计算带到数据所在地，也应适用于GIS、流处理和ML。批处理到流处理在我们与许多组织合作的情况下，数据规模每年增长在30%到100%之间。由于复利的力量，这意味着在未来五年需要为数据增长规划4倍到32倍的容量。大规模增加数据量的一个反直觉方面是，随着数据量的增加，更频繁地处理数据变得更有意义。例如，假设一个业务根据其网站流量创建每日报告，而这份报告需要两个小时才能生成。如果网站流量增长了4倍，报告生成时间将增加到八个小时，除非业务投入四倍数量的机器来完成工作。与此不同的方法是，通过每天计算四次六小时的数据统计信息，并将这些报告汇总，以创建每天更新四次的每日报告，如图2-5所示。这两种方法的计算成本几乎相同，然而第二种方法可以带来相当大的业务利益。将这种方法推广开来，将批处理数据处理更改为流处理变得有意义，尤其是随着数据量的增加，许多企业开始进行这种转变。上下文信息另一个加快决策的关键因素是自动化。随着数据质量的提高，或者企业将焦点转向其长尾客户，有必要减少用户体验中的摩擦。对于你产品的频繁、熟练的用户来说，他们能够忍受的问题要比偶尔、不那么复杂的用户多得多。能够捕捉到沮丧的用户并为他们提供上下文的帮助变得至关重要。实时的、基于位置的可视化越来越成为决策的方式。在许多情况下，这些可视化是内嵌到用户使用的应用程序中的。例如，Shopify为商家提供了图形和图表，展示他们的店铺表现如何。为了以规模做到这一点，这些图形实际上被嵌入到网站中，而不是作为独立的仪表板产品。确保位置信息是你的数据模式的一部分是最佳实践，无论是店铺的位置还是交货卡车的位置。因此，如果你的模式包括地址，请确保该模式要求对地址进行地理编码并使其成为规范形式。事后向数据集添加干净的地理信息是非常困难的。成本管理尽管很少有技术高管会对前述观点提出异议，但流处理有着在实施、监控和长期维护方面成本高昂的声誉。2 如何在不超出预算的情况下实现实时决策呢？首先，不要构建两个系统，一个用于批处理，另一个用于流处理。相反，将批处理视为流处理的一种特殊情况。诸如Apache Flink和Apache Beam（甚至Spark结构化流）之类的软件工具使这成为可能。其次，不要自定义构建监控、可观测性、延迟到达、扩展等功能。Flink和Beam是开源技术，但为了执行它们，利用完全托管的服务，如AWS上的Kinesis Data Analytics或GCP上的Cloud Dataflow——这是因为管理和排除故障流处理基础架构的技能相当罕见。另一种方法是将流处理视为批处理的一种特殊情况（或者根据Flink的理念相反）。采用这种方法的人尝试进行微批处理，通过尽可能快地处理小量数据。当需要非常新鲜但不一定是实时的数据时，这种方法可以奏效。这意味着等待一小时或一天才能运行批处理是不可接受的，但与此同时，了解过去几秒发生了什么并不重要。接下来，将流式数据落入提供最新信息给读取者（并且能够大规模处理它们）的DWH或存储层。换句话说，只要您能够实时落地数据，对数据的所有分析都将反映最新信息，而无需采取进一步的努力。既然您已经了解了如何利用最新和与上下文相关的信息，让我们看看如何注入AI/ML以更好地理解数据。步骤5：利用打包的人工智能解决方案实现飞跃2010年代技术领域最令人振奋的发展之一是深度学习的崛起，这是人工智能（AI）的一个分支。AI涵盖了计算机作为决策工具的问题类别。通常情况下，AI系统是通过编写计算机以思考或行动像人类一样来构建的。为了做到这一点，专家的思考过程必须被精心编码成计算机可以遵循的规则。由于人类通常无法精确解释他们的判断，这种专家系统很少表现得很好。机器学习（ML）是一类AI技术，与其捕获人类逻辑不同，ML“模型”显示大量正确的决策，预期该模型将来能够推断如何做出正确的决策。由于收集数据比捕获逻辑更容易，ML能够解决各种问题。然而，数据通常必须是结构化数据，类似于关系数据库中保存的数据。在2010年代中期，一组称为深度学习的技术开始崭露头角。这些技术使用“深度神经网络”，能够理解图像、语音、视频、自然语言文本等非结构化数据。这反过来导致了像Google Photos（即使用自然语言查询搜索图片的能力）或Alexa（即通过自然语言处理进行交互）这样的技术的发展。在企业中，深度学习也使组织能够从非结构化数据（如产品目录和用户评论）中提取信息。为企业用例提供了预构建的生成式AI解决方案，例如内容创作、客户体验、编码协助以及其他工作流助手。由于AI变得越来越成熟，不再需要在组织中投入大量工程时间来构建AI能力。相反，您可以通过许多可购买或定制的AI解决方案来利用AI的好处。这些解决方案可以分为几类：预测性分析、理解和生成数据、个性化和打包解决方案。预测分析机器学习模型是通过正确决策的示例进行训练的。企业数据仓库（DWH）通常是这类训练示例的重要来源。例如，假设你的业务是购买二手车、维修并销售。你想要创建一个系统来估计在拍卖会上购买的车辆的维修成本。很明显，你企业的历史数据是你购买和整修车辆的实际维修成本的良好来源。换句话说，历史数据中的正确答案存在于你的数据仓库中（见图2-6），可以用来训练机器学习模型。然后，训练好的机器学习模型可以用于预测随后在拍卖会上出现的车辆的维修成本。检测欺诈交易、估计机器故障时间、广告是否会被点击、销售多少商品、客户是否会购买等问题都是预测性分析问题的示例。通过教模型根据已捕获的其他因素预测历史记录中的一个值，可以解决这些问题。了解影响维修成本等事物的因素，将组织中与此估算有关的所有数据纳入数据仓库是成功进行预测性分析的先决条件。构建企业数据仓库后，有许多预建的预测性解决方案可用于创建必要的模型。事实上，像AWS Redshift和Google BigQuery这样的数据仓库提供了在不移出数据仓库的情况下连接到AWS SageMaker和Google Cloud Vertex AI等服务，从而能够训练自定义机器学习模型。理解和生成非结构化数据ML模型也可以经过训练以理解和生成非结构化数据。例如，自眼底图像中识别眼病、从交通摄像头检测非法左转、从视频中转录文本以及在评论中识别辱骂性语言的问题，都是使用ML模型来解释非结构化数据（图像、视频或自然语言）的例子。深度学习已经彻底改变了对非结构化数据的理解，每一代模型都将错误率降低到产品如Google Home中的问答系统、Gmail中的智能回复以及Google Photos中的图像检索极其准确的程度。与预测性分析不同，很少需要创建和训练模型来理解非结构化数据。相反，可以直接使用像Azure Vision API、Google Video Intelligence API和AWS Comprehend这样的预构建模型。使用这些API来丰富您的数据。例如，即使没有ML知识，开发人员也可以使用Google的NLP API提取评论的情感，并将情感作为附加列添加到您的DWH中。如果这些预构建模型提供的标签不足以满足您的用例怎么办？也许图像识别API返回一个响应，指示图像包含一个螺丝，但您希望API返回一个值，即它是您目录中的Item #BD-342-AC。即使在这种情况下，也无需从头开始训练模型。AutoML模型（即用于问题领域（如图像识别）的标准ML模型，可以使用自定义数据进行训练）如来自Google Cloud、Azure、H2O.ai、DataRobot等的模型可以通过简单地在自己的数据上进行微调来定制。通常，每种类型的示例可能只需十几个。AutoML模型适用于图像、视频和自然语言。使用它们来获取适用于您问题的高质量定制API。除了解释非结构化数据外，AI技术还存在用于生成此类数据的技术。被称为生成式AI（我们将在第10章进一步讨论）的技术可用于生成文本、图像、语音、音乐和视频。在这方面，也存在预构建（“基础”）模型，它们已经能够解决各种各样的问题（称为零样本学习）。这些模型可通过云供应商（Azure OpenAI、Vertex AI）和独立供应商（如OpenAI、Anthropic、Midjourney、Cohere等）的API获得。在许多企业用例中，有必要将数据和ML平台与生成式AI模型集成以将模型“植根”于现实中。例如，可以通过传递一些示例（称为少样本学习）和制定适当的输入（称为提示）来自定义基础生成式AI模型的行为。这些示例可以从数据平台获取。像Hugging Face和LangChain这样的框架提供了特定问题的开源解决方案，比如基于企业文档的问答。这涉及从数据平台通过矢量相似性搜索检索适当的文档，并在ML平台上运行链。有时，这些解决方案在云上以全托管方式提供（例如Google Enterprise Search）。最后，可以针对特定任务微调这些基础模型（称为监督微调），云提供商通过其ML平台提供此功能。个性化与为所有用户提供完全相同的产品相比，机器学习提供了提供更为个性化体验的机会。客户分割、定向和产品推荐等问题属于个性化的范畴。个性化是由客户的历史行为驱动的。例如，如果您是零售商，您可以基于其他人的行为（“购买此商品的用户还购买了...”）、基于用户自己的购买历史或基于商品相似性向用户推荐产品。所有这些信息都存在于您的企业数据仓库中（或至少可以存在）。因此，您可以使用存储引擎来支持推荐引擎。事实上，Google BigQuery ML具有一个推荐模块，Google的推荐 AI 是基于 BigQuery 数据运行的。同样，Azure Machine Learning 中的推荐模块是基于 Azure Synapse 运行的。在本节考虑的这三类 AI 中，很容易在几小时到几天内建立一个快速原型。这些模型都已存在；数据需求不繁重，您可以通过单击或单个 SQL 查询训练机器学习模型。打包解决方案除了在前面讨论的个别机器学习模型和技术之外，始终密切关注解决特定领域问题的打包解决方案，这些解决方案以即插即用的方式提供。例如，通过自然语言进行交互的对话型人工智能能够准确处理常见的例行问题，比如了解商店的营业时间或请求餐厅预订。现在，对话式人工智能能够将建议的答案填充到呼叫中心支持代理的屏幕上，以回答客户的问题。这些解决方案可以轻松集成到企业的电话系统中。像订单到现金、库存管理、货架缺货识别等解决方案已经准备好集成到您的业务中。毫无疑问，在您阅读本文时，将会有更多的打包和即插即用解决方案可用。我们鼓励您通过采用这些打包解决方案，跨越您当前技术堆栈实际可实现的局限性。步骤 6：将以人工智能为驱动的工作流程投入运营您数据平台战略的最后阶段是超越简单的预测和决策，实现端到端工作流程的自动化。您希望能够以完全自动和自治的方式解决业务问题。例如，您不仅希望预测机器何时会下次故障；您还希望在机器故障之前安排维护。实际上，您希望以最佳方式执行此操作，以降低运营成本、延长机器寿命并避免您的维修设施不堪重负。要实现所有这些，首先必须了解您在组织内希望实现的自动化水平（例如，完全自动还是仅提供协助？），然后需要专注于建立数据文化，为实现期望目标构建路径。最后但同样重要的是，需要强化数据科学团队，他们是实现您人工智能愿望的推动力。确定自动化根据我们的经验，许多组织在决策方面采用一次性的方式。如果它们采用数据驱动的方法并投资于使这些数据驱动的决策更加系统化，将会获得可观的回报。这种系统化的自动化是打破信息孤岛、获取数据的综合视图和提供建议的逻辑终点，如图2-7所示。随着企业数据成熟度的提高，领导层需要鼓励企业从一个阶段迈向下一个阶段。为了实现这种日益成熟，高管和员工都需要明确最终目标是什么。是决策的全自动化吗？是AI引导的决策制定吗？换句话说，人类是否完全不参与其中？还是他们在“掌握”整个过程？例如，考虑一下谷歌地图和贵国空中交通管制系统生成导航指令的方式的差异。前者是人类不参与其中的例子，完全是自动化的。在空中交通管制的情况下，系统提供指导，但是是人类最终给予降落飞机最终的导航指令。当然，在这两种情况下，人类都会接收并执行导航指令。自动化与协助的合适平衡通常是组织经过相当多的实验后确定的。它因行业而异，因组织而异。相对混合通常是同一行业中不同企业竞争的方式之一。因此，这通常是由产品管理主导的，而不是工程。建立数据文化组织将需要构建应用程序和系统，以实现最终目标，无论这个目标是全自动化还是为专家提供帮助。构建这样的系统将需要组织灌输一种数据文化。仅仅建立一个分析型数据平台是不够的。同样需要改变组织的文化，使其变成一个以数据驱动的实验为常态，并且成功的实验能够被操作化和扩展的组织。建立数据文化是解锁创新的关键，因为这将增强组织内的数据素养，传播读取和处理数据所需知识。仅仅因为你建立了一个能够打破数据孤岛的平台并不意味着它们就会消失。仅仅因为决策可以以数据驱动的方式进行并不意味着旧的启发式方法会轻易被抛弃。成功的组织会进行一个转型计划，涉及向整个创意工作人员提供有关数据工具（如商业智能仪表板和嵌入式分析）的培训。他们试图改变员工被奖励的方式，以鼓励承担风险和创业精神。他们试图建立一种衡量业务中所有重要指标的方式。最后，他们致力于为他们的员工提供数据工具，以便他们能够推动变革。填充你的数据科学团队为了使你的组织从数据和人工智能投资中获得价值，你的数据平台需要启用几个角色：数据工程师、数据科学家、机器学习工程师、开发人员和领域专家。除非所有这些群体都在你的数据平台上积极合作，否则你不能说你已经建立了一个未来准备好的数据平台。数据工程师：负责摄取、准备和转换数据。他们使用ETL工具将数据加载到数据仓库(DWH)中。他们监控数据管道，确保管道正常运行且不损坏数据源。数据科学家：进行数据分析，帮助决策者了解业务的运行情况，回答假设问题，建模结果并创建创新模型。产品管理团队是此处的关键决策者。数据科学团队进行分析，帮助产品经理了解产品路线图上不同项目的投资回报率。例如，农业技术公司的数据科学家可能回答有关不同种子每英亩产量及其与土壤类型的关系的问题。他们可能回答假设问题，例如如果商店的产品组合更改为更多的某一种子而不是另一种子，预期的利润是多少。他们还可能对业务策略进行建模，例如创建个性化的收获计划，并将其分解为组件模型并构建它们。机器学习工程师：将整个工作流封装到机器学习(Machine Learning, ML)管道中，并确保以可监视的方式执行。对模型进行常规运行监视，包括对韧性（模型是否正在运行？是否处理所有请求预测的用户？）和准确性（结果是否正确？）的监控。模型随时间漂移。这有时是因为环境本身发生变化（某种新型害虫开始影响某种类型的种子，因此其产量估计不再有效），有时是因为用户适应模型（农民开始根据相应种子品种的价格变化多种大豆而不是玉米，这改变了对某些类型的肥料的需求）。机器学习工程师寻找这种漂移并使用新数据对模型进行重新训练。这被称为MLOps。已部署的模型可作为API提供。开发人员调用模型，并在最终用户使用的应用程序中呈现其结果。领域专家：也被称为业务分析师，利用预测性分析实现数据驱动的决策。数据科学家观察专家的决策，并探讨通过打破阻止这些数据被定期访问的数据孤岛来加速决策的方法。他们使用打包的人工智能解决方案来丰富数据，从而继续数据驱动的创新循环。第7步：数据的产品管理为了最大程度地发挥数据的作用，请应用产品管理原则。几年前，许多高管所说的“将数据视为产品”实际上意味着他们想要直接从数据中获利，比如在数据市场上出售数据。然而，如今这样的市场大多数包含由专门从多个来源聚合数据的公司创建的数据（例如，零售流量、信用卡交易记录、产品评论）。很少有公司成功地从他们的第一方数据中获利。那么，当今一家典型企业希望将数据视为产品时，这意味着什么呢？将产品管理原则应用于数据我们更倾向于将期望的结果与实现这一目标的过程结合起来。期望的结果是，通过将数据视为产品，您的组织将最大限度地发挥数据的作用，而以上定义中突出的特征（有用性、标准化、治理）对此至关重要。我们对数据产品有一个广义的看法，数据集当然属于其中，但数据管道、仪表板、依赖数据的应用程序和机器学习模型也同样在范围之内。期望的结果只有在有达到这一目标的路径时才有价值。为了将数据视为产品，在构思和构建数据产品时应用产品管理原则。什么是产品管理原则呢？（1）制定产品战略，（2）以客户为中心，（3）进行轻量级的产品发现，以及（4）专注于找到市场适应性。我们建议采用与这些原则一致的10个数据实践（参见图2-8）。1.了解并维护企业数据流的映射产品经理的一个关键职责是简化。将数据视为产品意味着数据产品团队维护着业务中数据流的高层模型，以便轻松进行可发现性的沟通。您需要在多个粒度级别维护这个映射。以电商网站为例，最高级别可能是：网站流量产品目录网站内容订单库存客户在更详细的粒度级别，网站流量可能被细分为会话数据、页面数据等。捕捉每个数据集的收集方式、处理方式、哪些角色可以访问以及如何访问、是否包含个人身份信息（PII）或其他属性、所做的质量保证等信息。还要捕捉每个数据集的生产用例。随着粒度从较高级别逐渐降低，映射开始包含数据平台实现的细节，逐渐成为数据目录。2.确定关键指标一个数据目录仅仅是当前存在的记录。它并没有说明数据的重要性，或者数据是否符合目标（除非您利用临时标签来完成）。它不告诉您需要改进的内容。您的数据产品战略的重要部分是在企业内就关键指标达成一致——您将测量什么，如何测量以及指标的目标数值是多少（目标会随时间而变化）。您跟踪的指标范围应包括：业务关键绩效指标数据需要支持哪些业务结果？SLA（服务水平协议）数据的可用性如何？数据质量如何？刷新频率如何？使用情况数据在公司内部被广泛使用的频率是多少？满意度客户（可能是内部客户）对可用数据及其易用性的满意程度如何？对于前面介绍的假想的电商网站，业务结果可能涉及增加客户生命周期价值，提高免费套餐的转化率等。对于显示给内部采购人员（用于补货）的库存，SLA可能是它在99.99%的时间内可用，每小时刷新一次，并且保持在下周预测销售量的上方。您可能希望库存预测不仅被内部采购使用，还被物流团队使用，并被整合到仪表板中。您可能还有一个衡量预测库存量被多少次覆盖的指标。3.同意的标准、承诺的路线图和有远见的待办事项数据目录是当前存在的记录。度量标准捕捉你的目标是什么。然而，这两者都没有解释接下来的发展方向。根据客户反馈、利益相关方意见和市场状况，随时间调整产品愿景是重要的。在此过程中，利益相关方会要求你提供功能和时间表，并期望你信守承诺。为了应对变化和用户反馈，你需要三样东西：优先级标准：利益相关方事先同意的优先级标准，这有助于在产品路线图上实现透明度和全组织的认同。产品路线图：由产品发现过程提供支持的产品路线图，以便团队能够在没有信息和原型的情况下同意时间表。待办事项清单：认为重要但尚未在路线图上的事项将被记录在产品待办事项清单中。通常，产品待办事项清单包括需要解决的客户问题（而不是需要构建的功能）。在很多方面，待办事项清单（而不是路线图）构成了你的长期产品愿景。组织待办事项清单以讲述一个清晰的故事。路线图需要具有高度的承诺度，你应该能够对路线图上的时间表和功能做出承诺。一个很好的方法是就优先级标准达成共识，进行产品发现，并维护一个产品待办事项清单。回顾我们的一个假设性数据产品（参见前一步）是未来一周的库存预测，我们需要达成一致意见，以衡量预测的好坏。是很少出现缺货吗？是最小化采购和存储物品的成本吗？是在仓库级别发生缺货？还是在公司级别？这些形成了优先级标准。如果有人要求你定制易腐食品的库存模型，是否值得做？你最初会将其添加到产品待办事项清单中。然后，你将进行产品发现，以确定执行这个项目的投资回报率 - 这将包括增加/减少仓库冷藏的成本，例如。只有在了解价值后，你才会将其添加到产品路线图上。4.面向你拥有的客户构建产品往往，数据团队会陷入技术口号的泥淖：他们只提供API，或坚持让每个人将数据发布到他们的企业数据仓库，或期望符合一个统一的词典。向产品管理学习，深入了解你的客户是谁。他们在构建什么？一个移动应用程序还是一个月度报告？他们了解什么？SQL 还是 Java？他们使用什么工具？仪表板还是 TensorFlow？他们是否需要在数据更改时收到警报？他们是否需要实时数据的移动平均值？他们是否关心测试覆盖率？然后，以目标客户能够使用的方式提供数据。例如，你可以将数据提供给数据仓库（供数据分析师使用），通过API使其可访问（供开发人员使用），将其发布到特征存储中（供数据科学家使用），或在仪表板中可用的语义层（供业务用户使用）。例如，我们作为示例使用的假设性库存预测数据产品，如果将被内部采购员（业务用户）利用，那么预测结果将需要在用于订购补给的应用程序中提供。因此，这些预测结果可能需要通过API提供给应用程序开发人员使用。5.不要转嫁变更管理的负担变化和冲突是不可避免的。数据的供应商会更改格式；数据的使用者会有新的需求；数据的速度会发生变化；相同的数据可能会通过多个渠道提供；由于成本原因，您的客户可能会转向另一家供应商。这些问题不仅仅是进行更改的团队或使用数据的团队的问题。将数据视为产品的重要部分是确保数据的用户不必负担变更管理的责任。尽量确保演进模式和服务，使变更对下游用户透明。当不可向后兼容的更改不可避免地发生时，对更改进行版本化，并与利益相关方合作，将它们从旧版本的数据移动到新版本。这可能涉及创建一个迁移团队，其任务是将企业从一个版本迁移到下一个版本。变更管理的原则也适用于安全性。确保为个人身份信息（PII）和合规性建立保护措施，而不是将负担转嫁给数据产品的用户。假设我们的假设性库存预测数据产品被定制以包括易腐食品的预测。如果这涉及请求有关所售物品的额外信息，则必须负责确保所有现有物品的物品目录得到增强。这项数据工程工作是项目范围的一部分，它影响是否值得进行这项工作的投资回报率。6.面试客户以发现他们的数据需求你如何发展产品待办事项、确定需求的优先级并添加到路线图上？一个重要的纪律是确保你不断地与客户交流，发现他们在解决遇到的问题时需要什么样的数据。他们是如何绕过当前数据产品的不足之处的？这些问题会进入你的产品待办事项清单，供你优先考虑和解决。在任何新的数据产品想法进入产品路线图之前，重要的是已经通过潜在的（内部或外部）客户对产品的需求进行了验证。按照规格构建（"构建它，他们会来"）是非常危险的。更安全的做法是构建已经通过与客户验证的想法的实现。你如何做到这一点呢？7.广泛使用白板和原型制作与需要该数据产品的客户一起使用白板设计。这确保了在数据平台上实现的内容能够满足他们在质量、完整性、延迟等方面的需求。在构建任何数据流或转换之前，与他们一起讨论数据的潜在用途。在这里，其中一个最好的工具是原型。通过构建一个最小可行原型，可以验证数据的许多用例。我们是什么意思呢？如果销售团队认为构建一个客户数据平台将帮助他们实现产品交叉销售，可以通过手动匹配个别产品销售渠道的一组记录，尝试交叉销售生成的客户来验证这一点。我们建议使用原型以及与最终产品的潜在用户进行的面试来界定问题，包括：需要构建什么：确定项目成功所需的一切，从数据流到用户界面预期的业务关键绩效指标（KPI）方面的预期投资回报率在编写任何代码之前执行此操作。只有当你清楚知道需要构建什么以及预期的投资回报率时，你才应该将项目添加到路线图上。在那之前，将问题保留在待办事项清单中。对于我们假设的库存预测数据产品的情况，您将与主要产品用户一起验证输入模式以及如何使用预测，并检查仓库可以容纳多少更多的冷藏设施等等。在编写任何代码之前，您将执行此操作，可能通过在电子表格中进行预测并对各种产品的整套情景进行游戏化。8.只构建立即使用的内容优先快速投产而不是构建所有必要的功能。这意味着你应该使用敏捷、迭代的过程，仅构建当前需要的数据集、数据管道、分析等。不要专注于开发太多没有显著影响的功能：你付出的努力可能得不偿失。使用产品待办事项清单记录未来需求。只有在确定将使用这些功能的客户并能在白板/原型会话中给出反馈后，才构建这些功能。9.规范化常见实体和关键绩效指标（KPIs）为业务中的常见实体和关键绩效指标（KPIs）提供规范化、丰富的数据集。通常，这些丰富的实体支持大量高回报投资的用例（例如，客户数据平台、内容管理平台），或者是出于监管/合规目的所需的（例如，计算税收的方式）。通常，你只会有少数几个这样的标准化数据集和指标，因为这样的丰富需要跨业务单位的广泛协作，并降低了它们的发布速度。10.在你的数据平台中提供自助服务功能在组织中找到适合的方式来平衡灵活性和标准化。不要过分追求前一步（标准化）。不要构建拥有任何人可能需要的所有内容的中心化数据集。相反，要使团队能够自给自足。这是将微服务原则应用于数据的方法。实现这种平衡的一种方式是提供小型的、自包含的数据集，客户可以通过与其他数据集以特定领域的方式连接来进行定制。通常，这被实现为数据网格，每个业务单元负责其发布到共享分析中心的数据集的质量。总结在本章中，您了解了组织应该采取的创新数据过程的更多信息。本章的主要要点如下：通过确定关键业务目标、聚集合适的利益相关方并在整个企业中建立变革管理，创建战略计划。确保您的利益相关方集合中包括那些如果采用数据平台将最受益的业务单元。通过转向云来降低总体拥有成本。在这样做时，不要试图复制您在本地所做的技术选择。相反，选择能够自动缩放、分离计算和存储、支持 NoOps 并允许您支持各种应用程序而无需数据移动的技术。打破数据孤岛，以便将整个组织的数据连接在一起。确保每个部门都控制其数据并对其质量负责是很重要的。然而，所有数据都应该在统一平台上可用，以实现跨组织访问。通过将数据实时流入数据仓库并确保数据访问始终反映最新数据，以更快地在上下文中做出决策。在相关的情况下，数据表应该包括上下文元数据，如位置信息。利用可定制和适应性的 AI 模型，这样您就不必构建定制的 AI 模型。这些模型有助于无论您的需求是预测分析、理解非结构化数据还是个性化，都可以从您的数据平台推动。预测分析和个性化可以由数据平台驱动。非结构化数据可以通过使用预建的 AI 模型处理它并将其添加到数据平台中。将重点从一次性 ML 模型扩展到自动化整个工作流。这一步通常由产品管理领导，此处的分析通常会为产品路线图提供信息。通过聘用和配备由数据工程师、数据科学家、ML 工程师、开发人员和业务分析师组成的团队，建立创新文化。使用产品管理原则制定您的数据产品战略：以客户为中心，通过白板和原型发现产品，并在标准化和灵活性之间找到正确的平衡。在本章中，我们讨论了如何构建创新的数据组织的策略。在下一章中，我们将关注设计数据分析平台时必须考虑的关键方面：现有员工目前具备或将需要掌握的技能。

浏览量2063

攻城狮无远

第九章：通过混合和边缘扩展数据平台

到目前为止，在本书中，我们已经讨论了如何利用公共云的能力规划、设计和实施数据平台。然而，有许多情况下，单一的公共云是不够的，因为根据数据用例的特性，数据可能在其他位置产生、处理或存储，这可能是在本地、在多个超大规模云提供商处，或者在连接的智能设备（如智能手机或传感器）中。在这些情况下，需要解决一个新的挑战：如何提供对平台的全面视图，以便用户能够有效地混合和连接分布在不同地方的数据？在本章中，您将了解组织在处理这种分布式架构时可以采取的方法、技术和架构模式。此外，还有其他情况需要在部分连接或断开连接的环境中使数据发挥作用。在本章中，您将学习如何利用一种称为边缘计算的新方法来处理这种情况，该方法可以将存储和计算资源的一部分移到云外，更靠近生成或使用数据的主体。为什么选择多云？作为数据领导者，您的组织希望您不断寻找提高业务结果并最小化技术成本的方法。在数据平台方面，您被期望通过采用市场上最佳的解决方案，或至少是最适合业务需求的解决方案，来管理整个数据生命周期。单一云更简单且成本效益高将整个软件架构集中在单一云提供商上有很多吸引人的原因：简单在使用单一云提供商时，由此产生的技术堆栈更简单、更流畅。通常情况下，云内的服务是本地集成的。例如，在Google Cloud上，DWH工具（BigQuery）可以本地读取托管关系数据库（Cloud SQL）中的数据，无需数据移动。在AWS上的Redshift和Aurora之间以及Azure SQL Data Warehouse和Azure SQL Database之间（通过Azure Synapse Link）也有类似的零ETL集成。学习曲线当您只有一个云时，员工在组织内部移动变得更容易。新员工入职变得更容易，员工使用组织其他部分构建的工具也更容易。成本使用单一云提供商使从安全性到合同签订等方面都变得更简单。仅IT和法律服务上的成本节约就足以使单一云成为最佳选择。由于云提供商基于使用量提供折扣，通过将所有技术支出集中在一个提供商上，可以获得更大的折扣。因此，我们建议小型和中型企业选择单一云提供商，并使用该超大规模云上提供的完全托管服务设计其架构。多云是不可避免的我们发现许多组织可能希望使用单一云，但最终采用了混合或多云环境。为什么呢？收购即使您的组织最初使用单一云，您可能收购了一家在另一云上运行其整个技术堆栈的公司。现在，您是一个多云商店。这是最常见的情况，因为重新平台化的成本可能非常高，而且不值得对业务产生拖累。最佳云在不同超大规模云提供商上可用的能力存在差异。如果您真的喜欢BigQuery、DynamoDB或Azure OpenAI，并认为它们是最优秀的，并且已经根据这些能力设计了应用程序，那么您将希望该应用程序在Google Cloud、AWS或Azure上运行，即使您的其他技术基础设施位于其他地方。最好/最熟悉的工具可用性的差异、只需信用卡即可开始阴影IT项目的能力以及不愿重写已经运作的部分，意味着许多组织逐渐演变成一种事实上的多云系统。支持客户如果您正在构建在客户环境中运行的软件，您将需要支持所有主要云，因为您将有来自所有三个云的客户。这就是为什么，例如，SAP或Teradata在AWS、Azure和Google Cloud上都可用的原因。面对这些不可避免的情况，重要的是要认识到没有理由成为障碍。不再需要与单一供应商绑定并围绕单一技术构建整个数据堆栈。云技术比传统的本地技术更加开放，企业现在可以创建依赖于来自多个供应商的多个互连环境的复杂架构，或完全使用开源软件（例如，有些公司正在一个云提供商上实现其主站点，而在另一个上实现灾难恢复站点，以减少对单一超大规模云提供商的依赖风险）。当然，这种自由度的层次会带来不同的成本（在技术和人员方面），并需要额外的治理和管理。但正如您将在后面看到的那样，这种方法由于它可以提供的优势而变得越来越受欢迎。多云可能是战略性的与大型企业的IT高管交流时，我们经常听到他们正在进行包括多云战略在内的数字化转型之旅。已经有一些大型组织采用了多云方法的例子：例如，为其iCloud服务利用所有三个主要的公共超大规模云提供商的苹果；或者Twitter，在最近被收购之前，将Google Cloud Platform用于其数据平台，但使用AWS提供其新闻推送；或者汇丰银行，将工作负载分配给Google Cloud和AWS，并将一些传统服务迁移到Azure。正确使用时，多云使您能够通过在不同环境上部署最佳解决方案来为业务增加价值。实际上，这是一个全新的相互连接的服务生态系统的发展，成为公司所有解决方案的着陆区域。采用多云环境的主要驱动因素是什么？最相关的是：避免被锁定这是组织最担心的问题之一，因为他们不想受制于单一提供商的"暴政"。这不是技术问题（因为无论是云还是多云软件供应商，都无法逃避锁定），而更多是业务战略问题。退出策略在失败的情况下离开提供商的能力（甚至可能是合同违约）。利用您的管理层可能希望通过维持两个或更多云提供商来保留与超大规模云提供商的谈判筹码。商业可能是您的组织使用Microsoft的企业软件，在Amazon上销售，并在Google上进行广告宣传。在一个公共云上留下足迹可能具有更大的商业迫切性。法规要求也许某个提供商在某些地区或在该地区提供的服务集中没有适当的服务（例如，灾难恢复）。可持续性公司希望选择最佳的可持续云，因为这对于满足未来环境、社会和企业治理战略的趋势至关重要。创新采用没有成本、商业方面或功能方面障碍的解决方案。知识提供一个无障碍的环境，让员工成功，并且人们可以利用他们在职业生涯中已经获得的技能，或者可以获得新的技能。可移植性超大规模云的专有解决方案在运行位置方面往往受到限制，而在多个云上运行的开源解决方案通常也可以在本地和边缘上使用。现在，您对为什么应该考虑为您的业务采用多云战略有了更好的理解，让我们看一些您可以使用的架构模式，以使其成为现实。多云架构模式多云架构可以使用不同的模式连接数据，使用户能够与进行分析所需的所有解决方案进行交互。在本节中，您将了解在使用这些范例时可能遇到的最常见模式。一面玻璃面临的最大挑战之一是开发一种解决方案，使得能够跨越由不同供应商管理的各种位置中的多个数据孤岛进行数据分析。为了实现这一目标，必须利用从根本上具有云不可知性的开放解决方案，并具备与多个和不同的数据源连接的能力，以在需要时混合数据。在这里主要有两种不同的方法可以利用：基于 BI 工具的方法，如图9-1所示。基于处理引擎的方法，如图9-2所示在第一种方法中，您将任务委托给BI工具（例如Looker或Power BI），以连接多个稀疏的数据源，检索相关信息，远程执行查询，并最终聚合结果。在第二种方法中，您相反地赋予处理引擎（例如PrestoSQL、BigQuery Omni）与不同环境中的各种数据源连接的能力。在这种情况下，可能有两种不同的方法：利用跨越多个超大规模云提供商的分布式环境（例如BigQuery Omni），为最终用户提供与解决方案交互的一面玻璃。利用连接器（例如Java数据库连接[JDBC]）查询和混合跨多个系统的数据。一次编写，到处运行获得云选择性的常见方法是使用可以在不同超大规模平台上原样运行的软件。有几种可能的方法来实现这种模式：托管开源软件您可以使用Apache Airflow（一种开源工具）进行工作流编排，但通过使用Amazon Managed Workflows for Apache Airflow（MWAA）、Google Cloud上的Cloud Composer或Azure上的Azure Data Factory来避免管理的开销。这样，开发人员编写的代码在不同云之间是可移植的，但您仍然可以获得托管服务的好处，除了初始设置上的小差异。这种在不同超大规模云上使用不同托管服务的开源的模式在其他情况下也适用，包括Presto、Spark、PyTorch和TensorFlow等。多云产品 Snowflake、Confluent Kafka和Databricks等工具作为主要超大规模云提供商上的完全托管服务可用。因此，可以将在AWS上运行的Snowflake工作负载（包括Snowflake SQL、Snowpark等）几乎原样运行在Azure或GCP上。请注意，不同超大规模云上的软件版本之间通常存在一些滞后。多个运行程序 Google Cloud将用于编写Cloud Dataflow管道的软件API开源为Apache Beam。由于Apache Flink和Apache Spark现在为Apache Beam提供了运行时实现，因此您可以在托管Flink服务（例如Amazon Kinesis Data Analytics）上运行几乎没有更改的Apache Beam管道。OSS抽象层与通过Azure OpenAI或Google Cloud Vertex AI提供的提示API调用LLM不同，您可以选择通过提供一致的接口访问LangChain来访问模型。这允许在不同LLM提供商之间保持软件工作负载的可移植性（尽管您将不得不验证所使用的提示是否可以互换使用）。IaaS上的OSS 开源软件，如Dask、Modin、RAPIDS等，可以在从超大规模云提供商租用的虚拟机或集群上运行。除非您具有管理IaaS上软件的成本效益的规模，否则请尽量避免这种情况。从本地扩展到云的突发模式这是一种旨在支持拥有大型数据湖的组织的模式，他们希望将其影响扩展到云中，但尚未准备好进行完整的迁移。混合工作负载可以帮助解决他们的紧急问题，并作为额外的奖励，它们实际上还可以为未来的迁移铺平道路，显示采用和使用云技术的简便性。开始采用云方法的最简单方式是突发本地Hadoop工作负载。对于那些在硬件和与Hadoop相关的堆栈上都有重大投资且容量受限的组织来说，突发是一种很好的选择。突发对于那些可以针对上传到blob存储服务（例如AWS S3、Google Cloud Storage、Azure Blob Storage）的数据运行多个作业的情况以及可以增量更新用于处理的数据的情况非常有效。这种解决方案的主要优势之一是相同的Spark或Hive作业可以在本地运行，并且可以在PaaS集群上运行（例如Amazon EMR、Google Cloud Dataproc、Azure HDInsight）。它与那些重视开源解决方案并希望避免供应商锁定的组织相一致。在这里重要的是，将数据导入数据湖的所有上游流程保持不变。所有这些显著降低了重新执行和重新测试现有流程的风险，并缩短了第一次部署的时间。它实际上是如何工作的呢？这种方法使用Hadoop的分布式复制工具，也称为DistCp，将数据从您的本地HDFS移动到目标云blob存储中。一旦数据传输完成，就会创建一个PaaS集群，并可以在此集群上运行Spark作业。作业完成后，集群被销毁，作业结果被保存，如果您不计划运行其他作业，则blob存储桶也可以被销毁。突发工作负载的编排可以利用诸如Airflow之类的开源解决方案进行，这些解决方案既可以在本地工作也可以在云中工作（例如，通过Google Cloud Composer等以PaaS模式提供的解决方案），如图9-3。该模式涵盖的其他用例包括：组织测试版本升级的能力。在云中启动具有特定Spark版本的PaaS集群，并验证作业在本地数据的子集上是否正常运行，通常风险较小，成本较低。实验和测试新技术（例如，直接在Spark作业中集成第三方服务）。突发是我们在许多组织中经常看到的一种常见模式；让我们看看如何扩展它。从本地到云的直通模式这个模式可以看作是对前一个模式的补充。在前一个场景中，我们展示了如何使用Hadoop本地工具DistCp将本地数据湖的一部分移动到云blob存储桶中。一旦数据到位，组织可以利用其他处理引擎的工具（例如AWS Redshift、Google BigQuery、Azure Synapse），如图9-4所述，来处理数据，除了使用Hadoop本地工具。通过利用云处理引擎，可以实现多种工作负载：处理ORC、Parquet或Avro文件，包括利用联邦查询的Hive分区数据。将本地发起的数据与云中的数据进行连接：一个很好的例子是将组织的本地事务数据与从营销工具（如Adobe或Google Analytics）加载的数据进行连接。利用人工智能/机器学习工具基于本地数据构建模型。在本地数据上批量运行预测。采用这种方法时，需要注意一些关键点：与完全迁移相比，无需更改任何向本地数据湖提供数据或使用本地数据湖的系统。可以通过云处理引擎进行数据分析，除了使用Hadoop工具。一旦数据传输到云存储桶，通过所选的处理引擎访问联邦数据无需额外的延迟或处理。传输到云桶的相同数据可以由在本地运行的相同Spark作业处理。集成平台即服务（iPaaS）解决方案，如Informatica、Talend、TIBCO或MuleSoft，可用于简化数据源集成并保持同步。通过流式数据集成组织之间存在数据库和应用程序、本地和云之间的障碍。处理过程通常是批处理的，因此不支持业务要求的快速运营决策。服务通常是自管理的、传统的，并且不是为云构建的，运行和维护成本高昂。这导致了昂贵、缓慢和分散的系统架构。变更流是将数据更改（通常是数据库）实时从源移动到目标的过程。由变更数据捕获（CDC）技术驱动，变更流已经成为关键的数据架构构建块。全球公司要求CDC提供对不同数据源的复制功能，并为实时分析和业务运营提供实时流数据源。那么什么是CDC呢？CDC是一种数据集成方法，使组织能够使用更少的系统资源更快地集成和分析数据。它是一种仅从数据源中提取最新更改（更新、插入或删除）的方法，通常是通过读取源保留用于自身内部事务完整性的更改日志。CDC是限制将新数据加载到操作性数据存储和数据仓库时对源的影响的一种高效机制，它通过支持数据变更的增量加载或实时流式传输到数据目标，消除了批量加载更新和不便的批处理窗口的需求。CDC可以在许多从数据变更中获取价值的用例中使用；最常见的用例按常见程度排序如下：分析通过集成CDC将数据加载到数据仓库，组织可以获得源数据的实时物化视图。组织可以使用这个持续更新的数据构建实时仪表板。这可以用于监控系统并获取有关业务状态的最新见解，如图9-5所述。在考虑数据新鲜度的业务影响和收集处理成本之间始终存在权衡。数据库复制和同步场景通过集成CDC将数据加载到SQL数据库，组织可以获得这些数据库中源数据的实时物化视图。组织可以在目标数据库中使用这个持续更新的数据，用于从源到目标的低停机时间数据库迁移，或用于多/混合云配置，其中源和目标位于不同的托管环境中，如图9-6所示。事件驱动架构基于现代微服务的架构依赖于从组织各部门不断更新的数据的中心数据集，以实现事件驱动。通过持续写入目的地，比如云blob存储，组织可以构建基于从这些目的地消费事件数据的事件驱动架构，如图9-7所述。既然您对允许构建多云数据能力的可能模式有了更好的了解，让我们看看如何采用一种整体的多云策略。采用多云战略采用多云范式是战略的一部分，随后应将其转化为IT架构。框架为了将多云战略转化为多云IT架构，企业架构师利用一些常见的框架，如TOGAF（The Open Group Architecture Framework），来识别业务需求，定义支持流程所需的数据，以及定义应用程序如何处理这些数据（Architecture Development Model [ADM]过程），如图9-8所示。一旦完成，就可以确定为整合架构提供愿景的技术需求，而多云范式在这里为组织提供了高度的灵活性和自由度。拥有广泛的服务选择无疑是一种机会，但重要的是要谨慎管理，以避免失去关注。识别能够根据您的战略和组织规则（特别是在合规性方面）帮助实现业务目标的服务至关重要。这在今天尤为重要，因为组织越来越多地（重新）内部化IT功能，以拥有和控制其软件和解决方案。以金融服务行业为例。我们可以看到大量的投资用于将传统环境（主要基于主机解决方案）转变为现代环境，特别是在数据方面。实时分析支持着欺诈检测系统，先进的机器学习算法使得客户了解流程得以实现，反洗钱则需要处理海量数据的能力。如果仅依赖于单一提供商，获得这样一个特定解决方案/工作负载可能会很困难；因此，组织正在考虑采用多云方法，以获取最适合满足其需求的解决方案。时间尺度确定采用多云的时间尺度至关重要。具体来说：一些组织可能永远不会完全迁移到公共云，可能是因为它们属于金融或医疗行业，需要遵守关于数据存储方式的严格行业法规。对于它们而言，“数据驻留”非常重要。一些企业可能希望保护其遗留的本地工作负载，如SAP、Oracle或Informatica，但同时也希望利用公共云创新，比如完全托管的数据仓库。而其他大型企业则致力于用多年的时间进行与原生公共云的现代化，他们将不得不多年来采用多云架构作为最终状态。最后，有些组织可能还没有准备好迁移，但由于临时大批处理作业的挑战而难以满足业务SLA：他们希望利用公共云的可扩展容量，避免扩展本地基础设施的成本。考虑到前述概念，您如何最终获得多云架构？让我们深入了解一下。定义目标多云架构您可以采用与之前处理单一（公共或私有）云提供商时相同的方法，但需要（1）针对每个涉及的供应商重复该方法，（2）在整体目标架构的上下文中执行。以下步骤将帮助您定义和采用目标云架构：定义战略。在采用多云策略之前，您需要清楚了解您的目标。这些目标可能与业务、战略或技术相关。一旦了解了您的目标，您需要确定推动您采用多云策略的驱动因素。这些驱动因素可能是成本、功能缺失、开放性或法规合规性。例如，如果您采用多云策略是为了利用，您可能希望将最容易迁移的工作负载（例如Hadoop或Kafka）放在辅助云上。一旦明确了您的目标和驱动因素，您就可以继续进行多云之旅的下一步。组建团队。总体而言，谈论云时所需的技能可能会非常庞大。身份、安全、网络、编码等只是云工程师应该能够掌握的一些主题。当涉及到多云架构时，这套技能因为即使从高层次上来看这些主题是可以互换的，但仍然需要深入和具体的知识，相关于工程师需要操作的平台。通常情况下，您通常需要建立一个云卓越中心，如“第1步：战略和规划”中所述，以便所有所需的技能都聚集在“一个帽子”下，成为整个项目的参考。评估。为了确定候选目标解决方案，有必要更好地了解当前的操作情况。这一部分非常关键，因为它可以完全改变后续步骤的方法。您是要执行搬迁和迁移以保持组织现有解决方案，还是最好采用基于重新平台化/重新开发的方法，以从云提供商中获得最大的好处？通常，在这一步中有一些工具可以简化发现，并收集可以用于定义迁移计划的多个数据片段。向完全无服务器架构过渡并使用云原生工具通常是最佳解决方案，但在您手头资源短缺的情况下，这可能在短期内是不可行的。设计架构。一旦业务目标明确，您有足够的知识将所有事务变为现实，就开始将要求转化为技术架构。定义组件如何相互通信，它们如何交换信息，以及它们如何共同执行定义的任务。架构师的目标是确定最佳解决方案，为最终用户提供更大的灵活性，确保最高级别的安全性和性能，同时注意整体成本。准备迁移计划。一旦您收集到关于何处开始和何处想要前进的所有信息，您必须确定如何到达那里的方式：方式、时间表、所需的工作量和里程碑。了解不同活动/环境之间的关系以及可能的依赖关系，如果有的话，也很重要。构建着陆区。一切都从着陆区的定义开始（正如您在第4章中所读到的那样），那里是工作负载将被部署的基础环境：身份和访问管理、网络连接、安全性、监控和成本管理只是需要在这个阶段考虑的一些元素。这个阶段对于准备接收根据前一步中定义的模型传输数据的目标环境至关重要。迁移和转换。基于前面步骤中定义的所有内容，现在是时候将解决方案迁移到新的架构中了。在这个最后一步中，我们将应用新服务，或者完全重建应用程序，利用本地服务。既然您对如何处理多云架构有了更好的了解，让我们深入了解另一个混合范例：边缘计算。为什么要采用边缘计算？边缘计算简而言之是一种架构模式，促使数据处理在数据产生的地方进行，即使它位于架构的边缘。边缘计算是云计算范式的补充。尽管云计算使组织能够以集中的方式访问可无限扩展的计算和存储资源，边缘计算旨在解决不同的挑战。边缘计算帮助组织处理需要在原地处理数据（或延迟非常低）或在断开网络连接的情况下需要运行活动的工作负载。云计算更倾向于将业务带到全球范围，而边缘计算更专注于将功能带到决策点附近（例如，工厂、销售点等）。带宽、延迟和断断续续的连接来自工厂部署的机器的数据已经使制造公司能够分析其仪器的使用方式，并预测维护需求，限制潜在的损坏。电信公司已能够更好地了解其网络的拥塞情况并采取适当措施来缓解可能的问题。问题在于你不能在云中进行这样的分析。为什么呢？想象一下你是一家制造公司的首席信息官。首席执行官要求你找到一种方法，以加快目前通过手动进行的生产总装线上产品质量检查的速度。你的团队已经开发了一种基于机器学习的图像识别解决方案，通过比较总装线上的物品与完美产品，快速识别缺陷。你决定进行概念验证以展示解决方案的强大之处——它以自动方式识别98%的缺陷，现在你准备投入生产。你该如何做呢？最好的方式是如何进行？概念验证过程非常简单：收集代表完美物品的图片。收集代表有损坏/缺陷物品的图片。为每张图片分配一个特定的标签（良好物品，有缺陷物品）。开发和训练一个图像识别模型，以识别两组对象。部署模型并通过API提供。针对每个总装线上的物品执行以下步骤： a. 使用摄像机拍摄物品的照片。 b. 将照片作为API调用所需的输入有效负载上传到云环境。 c. 根据模型输出决定是否继续（物品良好）或停止流程（有缺陷物品）。这种方法适用于测试目的，但有一些缺点使其难以在生产场景中部署：带宽：系统需要拍摄高分辨率的照片才能发挥效果；需要上传到云的每张照片都是相当大的。考虑到每天需要检查每个总装线上的每个物品的数量，需要传输的数据量非常大，需要大量的带宽。延迟：为了使其快速并可扩展，您需要在拍摄照片后的几毫秒内获得结果（物品良好与有缺陷物品）。即使使用高速连接，要使其足够快以跟上总装线也是困难的。脱机：工厂通常位于偏远地方，很难保持稳定的网络连接。因此，即使脱机，这些解决方案也至关重要。所有这些缺点都与单一故障点相关：与云环境的连接需求。但如果您能够使更多的智能接近物理设备/传感器并赋予它们在不可察觉的延迟或甚至脱机的情况下运行和智能决策的能力，会怎么样呢？边缘计算的目标正是实现这一点：将存储和计算资源的一部分从云中带到生成/使用数据的主体附近。用例有几种情况下，集中式云环境无法工作，边缘部署可能会有益。这不是详尽无遗的清单，但应该给您提供可能性的想法：自动光学检查：利用基于深度学习模型的图像分析来识别与期望状态不符的某些内容，例如在总装线上验证项目质量的自动检查或加速车辆组件检查的解决方案，以发现其磨损程度。提高安全性：利用摄像机和其他传感器监视特定位置（如工厂、工作场所或危险场所）的人员安全的用例。这可能包括使用热感摄像机在危险地方或接近危险机器的地方识别人员，或使用传感器检查某人是否摔倒并需要帮助。农业：使用传感器监视植物的健康、生长和吸收的营养水平。实时分析收集的数据，以验证是否缺失或超量。医疗保健：分析实时患者数据以提取更多见解，例如磁共振图像、超声图像、葡萄糖监测仪、健康工具和其他传感器。内容交付网络（CDN）：为了改善浏览体验，通过互联网提供其数据的内容提供商（例如音乐、视频流、网页等）通常在边缘缓存信息，以减少检索时的延迟。实时算法可以极大提高缓存选择的效果。沉浸式互动：实时、迅速的反馈对于改善VR头戴设备（例如增强现实、游戏等）提供的沉浸体验至关重要。智能城市：旨在使城市更智能化并避免能源和资源浪费的应用，例如通过监控和控制单个灯具或一组灯具的传感器来实现的自动照明系统。交通管理系统：利用摄像机和传感器，可以实时调整交通信号，或管理交通车道的开启和关闭，以避免拥堵。当自动驾驶汽车变得更加普遍时，这一案例的重要性将更加突出。现在您对可能采用该模式的用例有了了解，让我们现在关注您可能获得的好处。好处边缘计算的作用是扩展集中式基础设施，并将更多计算能力带到架构边界附近。这使连接（或断开连接）的设备能够执行需要极低延迟和本地计算能力的任务（例如，机器学习推断）。这种模式解决了一些基础设施挑战，如带宽限制和网络拥塞。其他好处包括以下几点：可靠性大多数物联网（IoT）架构包含在不完全连接的环境中的元素，例如您的办公室或家庭。有一些相当常见的情况，实际上是无法在规定的低延迟的情况下保持与世界的持续可靠连接。想象一下农村工业站点，电信公司没有投资于高速有线连接，或者位于海中的风力涡轮机，利用老式的连接方式（2G/3G），或者自动驾驶汽车需要微秒级的延迟来做出决策（如果您的汽车必须刹车以避免事故，您不希望等待来自云的响应）。所有这些用例为了有效运作，需要能够在本地存储和处理数据的设备，并能够处理暂时的连接中断而不对其功能产生影响。法律/合规性在某些行业（例如金融服务和保险）中，某些国家有关存储、处理和暴露数据的规定非常严格（想想GDPR法规）。在本地转换和使用数据，并可能将修改后的数据发送回云端（例如，去标识化、加密等），将增加组织采用现代架构并仍保持合规性的能力。安全性数据外泄、分布式拒绝服务（DDoS）攻击防范和数据保护是边缘计算可以显著降低风险的一些场景，因为设备可以完全脱机工作，甚至可以被强制通过强化的网关与外部世界连接，该网关可以实施额外的数据保护层，如临时加密。现在让我们将注意力转向处理边缘计算范式时可能面临的挑战。挑战除了这种新范式可能为组织带来的好处之外，还存在一些您可能需要解决的缺点，例如：计算和存储能力的限制部署在边缘的设备通常配备执行定义良好的操作的有限硬件（例如，收集温度数据的传感器等）。因此，这些设备往往是超专业化的，不适合于通用性任务。即使设备能够执行一些通用任务，比如在本地运行ML模型，安装的设备版本可能没有必要的功能。设备管理/远程控制正如我们之前所概述的，由于连接性或严格的访问政策，云与这些设备之间的连接可能会很棘手。您可能需要物理访问每个设备以检查状态，并最终应用可能需要的更新/补丁。如果某些位置条件恶劣或设备部署在难以访问的位置，则这可能不是一项简单的任务。备份和恢复由于这些设备大多数时间都处于脱机状态，您可能需要实施额外的本地物理基础设施（例如，智能网关加上网络区域存储）来进行备份和恢复，这将提高总体成本。如果这些挑战中的任何一个适用于您的用例，您将需要评估它们是否构成阻碍，或者是否存在有效的解决方案来缓解这些问题。边缘计算架构模式与云计算一样，在定义边缘计算架构时，有一个清晰的策略是很重要的：可能存在所有设备由中央进行管理的情况（可能是由云应用程序管理），而也可能存在节点完全断开连接或只与本地网络部分连接的情况（以相互通信或与本地网关通信）。总体而言，有两种类型的边缘计算架构：一种是设备智能的情况，另一种是在边缘添加了智能网关的情况。无论是智能设备还是智能网关，ML激活的工作原理都类似。让我们看看这两种模式。智能设备智能设备是实施边缘计算架构的一种直截了当（尽管昂贵）的方式。在我们的示例场景中，用于生产必须经过质量检查的物品的机器将都需要具有执行能够识别图片中缺陷的ML算法的硬件。进行逻辑处理的设备可以简单地称为“节点”，它们的硬件根据它们需要解决的用例而变化很大：它们可以配备通用CPU或专用硬件来执行特定任务。具有可以直接执行复杂逻辑的非平凡硬件的智能设备（例如，Raspberry Pi、Coral传感器等），如图9-9所示，提供了很高的灵活性，但需要大量的管理工作（例如，软件更新、安全补丁等）和更高的硬件成本。智能网关通过有线或无线连接到智能网关的“哑”设备/传感器，智能网关可以代表它们执行逻辑，如图9-10所示，是处理同一位置（例如，工厂内）大量传感器的首选方法，因为它可以减少管理工作（一个智能设备而不是n个）及相关成本。然而，这引入了架构中的一些安全挑战，因为它可能成为单点故障（SPOF）。ML激活我们之前讨论过一个PoC场景，其中机器与云环境完全连接，不断地发送和接收数据，以决定如何处理流水线上的物品（接受或拒绝）。您已经看到，要使这种架构能够在生产环境中部署，唯一的方法就是扩展它，使设备能够在边缘直接执行该逻辑。在边缘执行的设备代码可能因情况而异，但可以概括为一个ML模型，该模型通过处理一些输入（在这种情况下是图片）来获取所需的输出（我们示例中物品的最终决定）。在前面的章节中，当讨论现代数据云架构时，您已经了解到云的主要优势之一是其能够大规模收集和处理数据，使开发人员能够轻松实现最先进的ML算法。让我们看看开发ML算法的过程的不同步骤（如图9-11所示），为此，让我们利用先前的示例：数据收集一切都始于将用作流程输入的数据。在我们的场景中，我们需要开发一个能够从图片中识别物品的信息和特征的模型，因此重要的是能够访问大量正常物品和有缺陷物品的图片。（请注意，您可以创建尽您所愿的状态，但为简单起见，我们将仅考虑两个状态：正常物品和有通用缺陷的物品。）数据分析需要对在先前步骤收集的数据进行精炼（例如，清理、转换、丰富）以供利用。在这个具体的示例中，我们需要验证所有拍摄的照片的质量（例如，焦点、对齐、噪声等），然后，对于每个图像，我们需要应用一个标签，指示图片中报告了什么，以生成两个分离的集合：正常物品和有缺陷的物品。ML模型开发、训练和测试是时候开发算法了；有许多工具和技术可供使用（例如，scikit-learn、TensorFlow、PyTorch），甚至还有使生活更轻松的自动化解决方案（例如，在特征工程、模型选择和参数调整方面提供支持）。在我们的示例中，我们可以使用迁移学习技术来开发一个深度学习模型来识别图像。ML模型部署该模型已准备好用于预测。它可以作为云中的API服务部署，也可以直接部署在边缘节点上。反馈数据收集为了提高模型的质量，可以收集来自边缘的数据，然后重新开始整个过程，进行交互式过程，旨在使预测变得更好。在我们的案例中，边缘节点将通过批处理过程发送回（例如，分析过的图像以及预测结果）。很明显，这些ML建模步骤对边缘架构提出了一定的要求：数据收集需要具备存储收集的图像的能力，以便在足够长的时间内可以交换磁盘并将数据上传到云端，同时可以将磁盘移到具有更好连接性的位置。数据分析可以在云中进行。ML模型开发也可以在云中进行。然而，测试需要在云上模拟边缘环境的能力。部署要求在开发ML模型时牢记边缘硬件的特征。将ML模型部署到边缘可能需要升级硬件组件，包括ML推理芯片，如Google Coral Edge TPU或NVIDIA Jetson Nano。反馈数据收集需要实施一个应用程序来跟踪人工操作员覆盖ML算法建议的决策的情况。现在您对边缘计算范式的理论有了更多了解，让我们看看如何采用它。采用边缘计算让我们看看采用这种范例可能如何为一个模范组织提供更大的可见性和更高的效率。最初的背景MagiCan是一家（虚构的）专门生产用于为全球最具标志性品牌提供服务的饮料罐的制造公司。该公司在世界各地拥有多个生产厂，每个工厂都有多台机器全天候工作。该公司的战略一直是在城市外地区建厂，而在一些地方，本地电信公司为该公司提供了基于老式无线技术（例如3G载波）的互联网连接。该公司的核心价值之一是“高质量产品是必须的，不惜一切代价”，并且该组织一直投入大量资金以确保端到端生产周期的质量（例如，维护机械和对生产物品进行质量检查）。MagiCan发现存在一些问题需要解决：多个站点的机器故障引起了生产的多次暂停，生产物品存在缺陷导致罚款，并且难以获得对其生产厂状态的一致性视图。因此，董事会决定启动一个新项目，以改善其收集和处理工厂数据的方式，以解决所有这些问题。项目该组织已经在多个工作负载（例如DWH、网站、SAP等）中利用云计算解决方案，并决定扩展其当前的体系结构，投资于直接连接到其机械设备的设备：目标不仅是直接从工厂收集数据以实时查看机器的工作方式，还允许用户对一些参数/组件（例如执行器、装配线等）进行操作，以修复问题、纠正不准确之处并改善生产过程的整体质量。该组织在IoT项目专业化的第三方合作伙伴的帮助下，定义了一个三步旅程：通过开发所需的体系结构来改善整体系统的可观察性，以从工厂收集数据并构建近实时监控系统。开发用于调整执行器运行的自动化。通过开发预测模型来优化机械设备的维护。让我们深入探讨这三个步骤的旅程。改善整体系统的可观察性考虑到MagiCan在全球各地有几个位置分布，并且其中大多数位置与云世界没有可靠的连接，无法基于流式处理模式开发实时体系结构。该公司决定将问题分为两个不同的部分：本地体系结构（在工厂级别），在该级别，所有机器都实时连接，所有信息立即被中央但本地应用程序可见。利用云系统的集中体系结构，从工厂收集的信息每天多次以批处理模式收集。目标是开发一种标准方法，以监控每个工厂的机器，并在工厂离线时仍使数据可用。中央云智能脑必须收集来自不同工厂的所有数据，然后使数据科学家能够研究这些数据，以便他们可以提取更多见解并利用云的强大功能，如图 9-12所示。在每个工厂中，部署了带有传感器的设备，用于收集来自不同执行器的数据（例如速度、旋转、温度等）。这些设备与能够实时收集所有数据并通过自定义开发的可视化工具提供给用户的智能网关进行本地连接，该工具为用户提供了对工厂状态的一种连续快照。每隔x分钟，数据会被压缩并发送到云进行进一步分析，然后与来自其他工厂的数据一起进行汇总。如果网络存在问题，则批处理将被排队并在下一批次中发送数据。发展自动化一旦来自所有工厂的数据在云中可用，就是时候开始玩耍了！可用的信息量使团队能够对以下几个方面获得可见性，例如：工人如何与机械设备进行交互执行器配置与罐头缺陷之间的相关性由于机械问题导致的平均闲置时间在使用特定原材料时的理想机器配置考虑到设备和云之间通过智能网关的连接是双向的，可以发送反馈并使机器接收更新的信息以调整它们的操作方式。公司开发了一个近实时的过程，用于处理来自工厂的所有数据，了解与理想目标操作模式的差异，并发送更新的配置以立即调整执行器的行为。通过这个在中心管理的过程，可以根据机器所处的当前场景提供基于定制配置的能力。优化维护最后一步是解决一个相当难以处理的问题：机器的维护。在能够全面了解机器运行状况之前，维护是以两种不同的方式进行的：计划维护通过定期干预根据机器型号、历史记录以及其运行方式，按照明确定义的日历安排，定期检查机器。非计划维护通过临时干预由于某些事件（如部件损坏或由操作员错误引起的故障），故意检查机器。考虑到维护操作可能会使机器暂停数小时甚至数天，有必要尽量减少非计划停机时间。利用来自工厂的数据（分析是在最初投入使用后的几个月后进行的，因为需要足够的历史数据量），开发了一个预测ML模型算法来计算机器故障的概率：当百分比超过一定阈值时，会向工厂经理发送警报，后者必须决定如何处理（即安排非计划维护操作或等待下一次计划维护）。最终结果和下一步骤整个端到端项目耗时超过一年，但最重要部分（即在各工厂实现统一视图的开发）的第一个版本相对较快（不到六个月）就完成了。借助这种分布式架构，公司能够提高在工厂和公司层面的可观察性，利用了一个共同的、标准化的、统一的过程。同时，它能够提高整个生产链的效率。MagiCan现在正在专注于一个全新的项目，旨在降低质检成本，尽可能自动化整个流程。与本节开头介绍的类似，该组织希望扩展已经建立的架构，实施一个在生产线上直接识别缺陷的流程：为实现这一目标，它将利用新的摄像设备，这些设备具有基于机器学习模型处理图像的能力。其目标是将当前执行质检的大部分人员重新分配到其他活动中。总结本章向您提供了处理混合和多云架构的高层次理解，当单一云提供商无法满足所有业务分析需求时。它向您介绍了在处理这种架构时需要考虑的各种因素，以及一些常见的实施模式。最后，它向您介绍了边缘计算以及如何使用它。主要要点如下：在单一云提供商上 consol，是非常有吸引力的，因为它简化了整体架构，易于学习/采用，以及总体成本较低。中小型企业应选择单一云提供商，并使用该超大规模提供商提供的全托管服务设计其架构。由于收购或希望使用在其中一个云上可用的服务，多云架构可能变得不可避免。当组织担心锁定、需要实施退出策略、有一些严格的监管要求，或想要提高工作负载的可移植性、创新、知识和可持续性时，必须考虑多云战略。采用多云战略是一个需要明确定义所需战略并扩展团队技能的过程。在处理多云架构时，有各种各样的架构模式可供利用，如开发单一玻璃窗口、在本地工作负载上爆炸Hadoop、使用Hadoop直通以在云中进行数据处理，以及使用变更流进行数据集成。边缘计算是一种旨在将存储和计算资源的一部分从云中带到生成/使用数据的主体附近的范例。带宽限制、网络拥塞、可靠性、法律合规性和安全性仅仅是边缘计算范例可以带来的一些好处。边缘计算的主要挑战包括计算和存储能力的限制、管理/远程控制以及备份和还原。利用边缘计算范例的主要用例包括自动光学检测、改进的安全性、农业、医疗保健、CDN、沉浸式交互、智能城市和交通管理系统。在选择边缘架构时，智能设备比使用智能网关更简单但更昂贵。无论哪种情况，ML 激活都涉及添加诸如设备存储和 ML 推断芯片等功能。在下一章中，您将了解在人工智能和机器学习中对架构和框架做出的高层次决策。

浏览量2016

攻城狮无远

第四章：迁移框架

除非你在一家初创公司，否则你很少会从零开始构建一个数据平台。相反，你将通过从传统系统中迁移数据构建一个新的数据平台。在这一章中，让我们审视迁移过程——在迁移到新数据平台时应该做的所有事情。我们将首先提出一个概念模型和可能的框架，供你在现代化数据平台时遵循。然后，我们将讨论一个组织如何估算解决方案的总体成本。我们将探讨如何确保在迁移进行的同时安全性和数据治理得到落实。最后，我们将讨论模式、数据和管道迁移。你还将了解有关区域容量、网络和数据传输约束的选项。现代化数据工作流在开始制定迁移计划之前，您应该全面了解为何进行迁移以及您要迁移到何处的愿景。整体视角数据现代化转型应该被全面考虑。从俯瞰的角度看，我们可以确定三个主要支柱：业务成果关注正在现代化的工作流，并确定这些工作流驱动的业务成果。这对于确定差距和机会所在至关重要。在做出任何技术决策之前，将迁移限制在与领导层确定的业务目标一致的用例中（通常在两到三年的时间范围内）。利益相关方确定可能访问数据的个人或角色（其中一些团队可能尚不存在）。数据现代化的目标是使数据访问民主化。因此，这些团队将需要在数据现代化的最终状态技术中使用的任何工具（SQL、Python、仪表板）上变得数据有素，并能熟练运用。技术您将不得不根据业务战略和团队能力来定义、实施和部署数据架构、建模、存储、安全、集成、可操作性、文档、参考数据、质量和治理。确保您不将迁移视为纯粹的IT或数据科学项目，而是作为技术方面只是更大范围的组织变革的子集。现代化工作流当你考虑进行现代化项目时，你的思维自然会偏向于你目前使用的工具所带来的困扰。你决定要升级你的数据库，并使其在全球范围内保持一致和可伸缩，所以你将其现代化为Spanner或CockroachDB。你决定要升级你的流处理引擎，并使其更具弹性和更易于运行，所以你选择了Flink或Dataflow。你决定不再调整数据仓库中的集群和查询，所以你将其现代化为BigQuery或Snowflake。这些都是不错的举措。在可能的情况下，无论何时你都应该升级到更易于使用、更易于运行、更具可伸缩性和更具弹性的工具。然而，如果你只是进行一对一的工具更改，你最终只会取得渐进式的改进。你将无法从这些升级中获得变革性的改变。为了避免这种陷阱，在你开始数据现代化之旅时，强迫自己思考工作流程，而不是技术。现代化数据工作流程意味着什么？考虑最终用户想要完成的整体任务。也许他们想要识别高价值客户。也许他们想要运行一项营销活动。也许他们想要识别欺诈行为。现在，从整体上考虑这个工作流程以及如何以尽可能便宜和简单的方式实现它。接下来，从第一原则出发，以你现代化的工具集实现这样的工作流程。在这样做时，大量依赖自动化：自动化数据摄取不要编写定制的ELT流水线。使用现成的ELT工具，如Datastream或Fivetran，将数据导入数据仓库。实时转换数据并在物化视图中捕获常见的转换要比为每个可能的下游任务编写ETL流水线要容易得多。此外，许多SaaS系统将自动导出到S3、Snowflake、BigQuery等。默认使用流处理将数据存储在一个结合了批处理和流处理存储的系统中，以便所有SQL查询都反映最新的数据（受一些延迟的影响）。任何分析工具都应该使用相同的框架处理流处理和批处理。在我们的示例中，生命周期价值计算可以是一个SQL查询。出于重用的目的，将其作为物化视图。这样，所有计算都是自动的，数据始终是最新的。自动扩展任何期望你预先指定机器数量、仓库大小等的系统都将要求你关注系统而不是要完成的工作。你希望扩展是自动的，这样你就可以关注工作流程而不是工具。查询重写、融合阶段等你希望能够专注于要完成的工作并将其分解为可理解的步骤。你不想调整查询、重写查询、融合转换等。让内置于数据堆栈中的现代优化器处理这些事务。评估你不想为评估ML模型的性能编写定制的数据处理流水线。你只想能够指定采样率和评估查询，并收到有关特征漂移、数据漂移和模型漂移的通知。所有这些功能都应该内置到已部署的端点中。重新训练如果遇到模型漂移，你应该重新训练模型的可能性为10次中有9次。这也应该是自动的。现代ML流水线将提供一个可调用的挂接，你可以直接将其与你的自动评估流水线相关联，以便你也可以自动进行重新训练。持续培训模型漂移不是需要重新训练的唯一原因。当你有更多的数据时，可能需要重新训练。也许是当新数据着陆在存储桶中时。或者是在代码检入时。同样，这也可以自动化。一旦你确认需要一个完全自动化的数据工作流，你将看到一个相当模板化的设置，包括连接器、数据仓库和ML流水线。所有这些都可以是无服务器的，因此你基本上只需要配置，而不是集群管理。当然，你还将编写一些具体的代码：SQL中的数据准备TensorFlow或PyTorch等框架中的ML模型用于连续评估的评估查询我们能够将每个工作流程简化到这样一个简单的设置，这就解释了为什么一个集成的数据和AI平台是如此重要。改变工作流本身你可以通过使用现代数据堆栈使工作流程本身更加高效，使其更加自动化。但在这样做之前，你应该问自己一个关键问题：“这个工作流程是否有必要由数据工程师预先计算？”因为每当你构建一个数据流水线时，你都在进行预计算。这只是一种优化，不再多。在许多情况下，如果你可以使工作流程成为自助式和自发的，你就不必使用数据工程资源构建它。由于许多工作都是自动化的，你可以提供在完整历史交易记录上运行任何聚合（不仅仅是生命周期价值）的能力。将生命周期价值计算移到声明性语义层，用户可以在其中添加自己的计算。例如，Looker这样的工具就可以做到这一点。一旦这样做，你将获得整个组织中一致的关键绩效指标（KPIs）和用户有权构建常见度量库的好处。创建新指标的能力现在掌握在业务团队手中，这本来就是其所属的地方。四步迁移框架可以对构建数据平台的过程中可能遇到的许多情况应用一种标准化的方法。这种方法在很大程度上独立于数据平台的规模和深度——我们既用于现代化小公司的数据仓库，也用于为跨国企业开发全新的数据架构。该方法基于图4-1中显示的四个主要步骤：准备和发现：所有利益相关方都应进行初步分析，以确定需要迁移的工作负载列表和当前的痛点（例如，无法扩展、处理引擎无法更新、不需要的依赖关系等）。评估和规划：评估在前一阶段收集的信息，定义成功的关键指标，并计划每个组件的迁移。执行：对于每个确定的用例，决定是停用、完全迁移（数据、模式、下游和上游应用程序）还是卸载它（通过将下游应用程序迁移到不同的源）。然后，测试和验证所做的任何迁移。优化：一旦过程开始，可以通过持续迭代来扩展和改进它。首次现代化的步骤可以仅关注核心功能。准备与发现第一步是准备与发现。这涉及定义迁移的范围，并收集与将要迁移的工作负载/用例相关的所有信息。这包括分析来自企业各个利益相关方的广泛输入，如业务、财务和IT。请这些利益相关方：列出所有与迁移相关的用例和工作负载，附有它们的相关优先级，确保其中包括合规要求、延迟敏感性等相关信息。解释他们可以通过新系统获得的预期好处（例如查询性能、能够处理的数据量、流处理能力等）。提出市场上可能满足业务需求的解决方案。进行初步的总体成本拥有分析，以估算迁移的价值。辨认培训和招聘方面的需求，以建立一支有能力的团队。您可以使用问卷调查从应用程序所有者、数据所有者和选定的最终用户那里收集这些见解。评估与规划评估与规划包括以下活动：1. 当前状态的评估：分析每个应用程序、工作流或工具的当前技术架构，通过收集和分析服务器配置、日志、作业活动、数据流映射、容量统计、查询和集群等信息。随着旧系统规模的增加，这项工作可能会变得耗时且容易出错。因此，请寻找可以自动化整个过程的工具（例如SnowConvert、CompilerWorks、AWS Schema Conversion Tool、Azure Database Migration Service、Datametica Raven等）。这些工具可以提供工作负载拆分、依赖关系映射、复杂性分析、资源利用率、容量分析、SLA分析、端到端数据血统以及各种优化建议。2. 工作负载分类：利用在“准备与发现”步骤中使用的问卷收集的信息，结合评估阶段的深入见解，将所有已识别的工作负载分类并选择一种适当的迁移方法：Retire（退役）：工作负载最初将保留在本地，最终将被停用。Retain（保留）：由于技术限制（例如运行在专用硬件上）或出于业务原因，工作负载将保留在本地。这可能是暂时的，直到工作负载可以进行重构，或者可能被移到协作设施，其中数据中心需要关闭，而服务不能被移动。Rehost（重新托管）：工作负载将迁移到云环境中，利用其基础设施即服务（IaaS）功能。这通常被称为“搬迁和提升”。Replatform（重新平台化）：工作负载（或其中的一部分）将进行部分更改，以提高性能或降低成本，然后迁移到IaaS。这通常被称为“搬迁和改进”。在进行搬迁和提升后进行优化，通常从容器化开始。Refactor（重构）：工作负载（或其中的一部分）将迁移到一个或多个云完全托管的平台即服务（PaaS）解决方案（例如BigQuery、Redshift、Synapse）。Replace（替换）：工作负载将被第三方现成的或SaaS解决方案完全替代。Rebuild（重建）：工作负载将被完全重新设计，使用云完全托管的解决方案，并从头开始实施。这是重新思考应用程序并计划如何充分利用云原生服务的阶段。3. 工作负载群集化：将那些不会被退役/重建的工作负载分组成一系列基于其相对业务价值和迁移所需工作的群组。这有助于在迁移过程中确定可以遵循的优先级。例如：Group 1（第一组）：高业务价值，低迁移工作量（优先级0—快速成功）Group 2（第二组）：高业务价值，高迁移工作量（优先级1）Group 3（第三组）：低业务价值，低迁移工作量（优先级2）Group 4（第四组）：低业务价值，高迁移工作量（优先级3）在图4-2中，您可以看到一个群集化示例，其中工作负载根据所描述的优先级标准被划分为各个组。在每个组中，工作负载可能有不同的迁移方法。在整个过程中，我们建议您遵循以下实践：使过程可衡量。确保利益相关方同意并能够使用一些业务关键绩效指标（KPI）评估现代化的结果。从最小可行产品（MVP）或概念验证（PoC）开始。将大型任务分解为较小的任务，并确保存在任何即将进行的工作的标准模板。如果没有，请进行概念验证，并将其用作以后的模板。寻找可以作为其他转换示例的快速成功案例（优先级0工作负载），同时也可以向领导层展示这种现代化可能引入的影响。估算完成所有活动所需的总时间。创建一个整体项目计划（在必要时与供应商或顾问合作），以定义工作负载转换所需的时间、成本和人员。在关键阶段进行过度沟通。确保利益相关方了解计划、需要多长时间以及关键组件是什么。确保在完成云项目的过程中提供价值，并通过组织中实际可用的项目建立信心。尽量确定关键时刻，并发送即时通信，总结已完成的工作的详细信息。既然您对准备进行下一次迁移的任务有了很好的了解，让我们看看您应该如何着手进行。执行对于每个工作负载，您现在都有一个计划。具体而言，您知道将迁移什么（整个工作负载还是其中的一部分），将在何处迁移（IaaS、PaaS或SaaS），您将如何迁移（rehost、replatform、rebuild等），您将如何衡量成功，您将遵循什么模板，需要多长时间，以及将在哪些里程碑上进行沟通。为了将计划变为现实，我们建议您建立一个着陆区（landing zone），迁移到该区域，并验证已迁移的任务。着陆区（Landing Zone）首先，您需要构建所谓的着陆区（landing zone）- 所有工作负载将驻留的目标环境。这个活动根据您当前的配置可以具有不同的复杂性，但至少您将需要：定义目标项目及相关组织（例如，Google Cloud组织层次结构）设置新的身份管理解决方案或与传统或第三方解决方案集成（例如，Azure Active Directory或Okta）配置授权（例如，AWS IAM）和审计系统（例如，Azure安全日志记录和审计）定义并设置网络拓扑及相关配置一旦着陆区准备好，就是开始迁移的时候了。迁移通常建议将迁移分为多个阶段或迭代，除非您要迁移的工作负载数量非常小。这将使您能够在一次迁移一部分工作负载的情况下，积累经验和信心，处理挑战和错误。对于每个工作负载，您可能需要考虑以下事项：模式和数据迁移：根据用例，您可能需要翻译数据模型或仅传输数据。查询转译：在某些情况下，您可能需要将查询从源系统翻译到目标系统。如果目标系统不支持所有扩展，您可能需要重构查询。您可以利用诸如Datametica Raven或生成式人工智能等工具来减少手动工作的量。数据流水线迁移：数据流水线是准备数据进行分析的数据工作负载的核心部分。我们将在“模式、流水线和数据迁移”中看到处理此类迁移的可能方法。业务应用程序迁移：一旦迁移了数据，您需要迁移使用户能够与数据交互的应用程序。性能调优：如果迁移的工作负载性能不如预期，您必须进行故障排除和修复。也许目标解决方案没有正确配置，您定义的数据模型不允许利用目标平台的所有功能，或者在转译过程中存在问题。使用基础设施即代码工具如Ansible或Terraform是至关重要的，因为它们可以自动化尽可能多的部署基础设施管理，加快每个迭代的测试和执行。验证一旦工作负载完成迁移，您需要仔细检查是否一切都已成功完成。验证工作负载的性能、运行成本、访问数据的时间等是否都符合您确定的关键绩效指标（KPI）。验证您获得的所有结果是否符合期望（例如，查询结果是否与传统环境中的相同）。一旦确保结果符合您的需求，就可以转移到第二个用例，然后是第三个，直到您将所有内容都迁移完毕。如果可能的话，尽量并行处理后续迭代，以加快整个过程。在每个工作负载结束时，记录可能遇到的问题、完成所有活动所需的时间以及相关的经验教训，以改进后续工作负载的过程是一个不错的主意。优化框架的最后一步是优化。在这里，您不会专注于每个单独迁移组件的性能。相反，您将把新系统作为一个整体来考虑，并确定引入潜在新用例以使其更加灵活和强大。您应该反思迁移所获得的成果（例如，无限的可扩展性、增强的安全性、增加的可见性等）以及作为下一步潜在的操作（例如，扩展数据收集的边界，与供应商建立更好的协同关系，开始将数据变现等）。您可以从“准备和发现”阶段收集的信息开始，了解自己在理想旅程中的位置，并考虑额外的下一步。这是一个永无止境的故事，因为创新，如商业一样，永远不会停歇，它将帮助组织在理解和利用其数据方面变得越来越好。现在您对如何利用四步迁移框架来处理迁移有了更好的理解，让我们深入了解如何估算解决方案的总体成本。估算解决方案的总体成本你刚刚看到了一个通用的迁移框架，可以帮助组织定义现代化数据平台所需执行的一系列活动。CTO、CEO或CFO可能会问的第一个问题是：“我们需要为此预算多少总成本？”在本节中，我们将审查组织通常如何应对这一挑战以及它们如何构建工作结构，以从供应商和第三方供应商那里获取报价。始终牢记，这不仅涉及技术成本，总是需要考虑人员和流程成本。现有基础设施的审计正如您所见，一切都始于对现有环境的评估。如果您对当前的基础设施状况没有清晰的了解，那么在正确评估下一代现代数据平台的定价方面肯定会面临挑战。这项工作可以通过以下三种方式之一进行：由内部IT/基础设施团队手动进行：许多组织维护配置管理数据库（CMDB），它可以是一个文件或包含组织内使用的所有关键硬件和软件组件信息的标准数据库。这是组织内当前运行情况的一种快照，涵盖了甚至是组件之间的关系。CMDB可以更好地了解所有应用程序的运行成本，并帮助关闭不必要或多余的资源。由内部IT/基础设施团队自动进行：目标与前一点中描述的完全相同，但旨在利用能够以自动方式收集信息的软件（与硬件相关的数据、在服务器上运行的应用程序、系统之间的关系等）。这些类型的工具（例如 StratoZone、Cloudamize、CloudPhysics 等）通常会生成与最常见的云超大规模供应商（例如 AWS、Google Cloud 和 Azure）相关的建议，例如机器的大小以及优化选项（例如每天应该运行多少小时才能执行其任务）。利用第三方参与者：咨询公司和云供应商拥有经验丰富的人员和自动化工具，可以执行生成CMDB和前两个选项中描述的详细报告的所有活动。如果您的组织通常将IT项目外包给咨询公司，我们建议选择这种方式。接收信息/提案和报虽然这可能是您进行的唯一一次迁移，因此您必须边学边做，但咨询公司专门从事此类工作，通常更擅长处理迁移项目。当然，要验证分配给您的团队是否具有必要的经验。一些服务提供商甚至可能会执行评估并提供成本估算，如果他们看到未来的机会。确定在现代化过程中合作的最佳合作伙伴或供应商可能是一项艰巨的任务。有许多变量需要考虑（知识、能力、成本、经验），如果不以严格的方式执行，可能会变得非常复杂。这就是为什么组织通常利用三种类型的问卷调查从潜在的服务提供商那里收集信息的原因：信息请求（RFI）：用于收集有关供应商/潜在合作伙伴解决方案和服务的详细信息的问卷。它具有教育目的。提案请求（RFP）：用于收集关于供应商/合作伙伴将如何利用其产品和服务解决特定组织问题的详细信息的问卷（在这种情况下，是现代数据平台的实施）。它用于比较结果。报价请求（RFQ）：用于根据特定要求收集有关不同供应商/潜在合作伙伴定价的详细信息的问卷。它用于定量和标准化定价，以便未来进行比较。您的组织可能有关于如何执行此操作的政策和模板。与您的法务或采购部门进行沟通。否则，要求供应商向您展示他们通常使用的工具。一旦您收到所有供应商/潜在合作伙伴的回复，您应该获得选择最佳路径前进的所有信息。在某些情况下，特别是在要解决的问题可能非常模糊（例如，实时分析可能在一天内甚至一天内有多个峰值），即使对于供应商/潜在合作伙伴来说，提供有关成本的清晰详细信息也是具有挑战性的。这就是为什么有时供应商会要求进行概念验证（PoC）或最小可行产品（MVP），以更好地了解解决方案在实际用例场景中的工作方式并促使最终定价的定义。概念验证（PoC）/最小可行产品（MVP）新数据平台的设计和开发可能具有挑战性，因为大多数组织希望利用数据平台迁移的机会，不仅仅是进行简单的搬迁，而是要添加在旧世界中不可用的新功能和能力。由于这对他们来说是新的，组织（因此也包括供应商）可能无法完全理解最终行为，尤其是平台将产生的最终成本。为了解决这一挑战，组织通常要求精选的供应商或潜在合作伙伴在分析了RFP响应之后，实施最终解决方案的初始模拟（或具有有限功能的实际工作解决方案）作为第一步。这个模拟允许利益相关者体验最终解决方案的行为，以便他们可以确定是否需要任何范围的更改。模拟还使成本估算变得更加容易，尽管重要的是要注意，我们总是在谈论估算，而不是具体的定价。在采用云模型时，尤其是如果您想利用弹性，几乎不可能有清晰和最终定义的定价。弹性是云的主要优势之一，只有在生产中才能体验到。有三种方法来处理模拟的想法：概念验证（Proof of Concept，PoC）：构建解决方案的一小部分，以验证可行性、可集成性、可用性和潜在弱点。这有助于估算最终价格。目标不是触及平台的每个功能，而是验证可能需要重新设计的事物。例如，在处理流水线时，通过随机变化要处理的数据量，创建一个PoC是一个良好的实践。这将让您看到系统如何扩展，并为您提供更好的数据，以估算最终生产成本。最小可行产品（Minimum Viable Product，MVP）： MVP的目标是开发一个具有非常明确定义的范围的产品，所有功能都已实施并且像一个真正的、完整的产品一样在生产环境中部署（例如，在新的DWH上实施的数据集市，连接到新的业务智能工具，以解决一个非常具体的用例）。MVP的主要优势是能够迅速从实际用户那里获得反馈，这有助于团队改进产品并产生更好的估算。混合方法：最初，团队将以更广泛的范围开发一个通用的PoC，但深度有限（例如，端到端的数据流水线，以收集训练图像分类ML算法所需的数据），然后，基于第一轮结果和成本评估，焦点将转向开发MVP，可以看作是实施完整解决方案的第一步。现在您了解了如何估算成本，让我们深入研究迁移的第一部分——设置安全性和数据治理。建立安全性和数据治理即使数据的所有权和控制权移交给业务部门，安全性和治理仍然是大多数组织中的中心关注点。这是因为在角色定义、数据安全和活动日志记录方面需要保持一致性。在缺乏这种一致性的情况下，要遵守《被遗忘权》等法规是非常困难的，根据这些法规，客户可以要求删除与他们有关的所有记录。在本节中，我们将讨论这种中心化数据治理框架中需要具备哪些能力。然后，我们将讨论中心团队需要维护的工件以及它们在数据生命周期中如何结合在一起。框架安全性和治理试图解决的三个风险因素是：未经授权的数据访问在将数据存储在公共云基础设施中时，有必要防止对敏感数据的未经授权访问，无论是公司机密信息还是法律保护的个人身份信息（PII）。法规合规诸如《通用数据保护条例》（GDPR）和法律实体标识符（LEI）等法律限制了数据分析的地点、类型和方法。可见性了解组织中存在哪些类型的数据，目前谁在使用这些数据，以及他们如何使用可能是供应组织数据的人所需的。这需要及时的数据和一个功能齐全的目录。鉴于这些风险因素，有必要建立一个全面的数据治理框架，涵盖数据的整个生命周期：数据摄取、编目、存储、保留、共享、归档、备份、恢复、防丢失和删除。这样的框架需要具备以下能力：数据血缘组织需要能够识别数据资产并记录应用于创建每个数据资产的转换。数据分类我们需要能够对敏感数据进行概要和分类，以确定每个数据资产或其部分需要应用哪些治理政策和程序。数据目录我们需要维护一个包含结构元数据、血缘和分类的数据目录，并允许搜索和发现。数据质量管理需要有一个过程来记录、监测和报告数据质量，以便为分析提供可信赖的数据。访问管理这通常将与云 IAM 一起工作，以定义角色、指定访问权限并管理访问密钥。审计组织和其他组织的授权个人（如监管机构）需要能够监控、审计和跟踪法律或行业规定所要求的细粒度活动。数据保护需要能够加密数据、对其进行掩码或永久删除。要使数据治理实现运营化，您将需要建立一个允许进行这些活动的框架。云工具（如Google Cloud上的Dataplex和Azure上的Purview）提供了统一的数据治理解决方案，以管理数据资产，无论数据位于何处（即单一云、混合云或多云）。Collibra和Informatica是云不可知的解决方案，提供记录血缘、进行数据分类等功能。根据我们的经验，这些工具中的任何一个都可以使用，但数据治理的艰苦工作并不在于工具本身，而是在于其运营化。建立一个运营模型——数据治理的流程和程序，以及一个负责确保业务团队遵守这些流程的委员会是非常重要的。该委员会还需要负责制定分类法和本体论，以确保组织内部的一致性。理想情况下，您的组织应参与并与行业标准机构保持一致。最好的组织还会定期进行持续的教育和培训活动，以确保遵守数据治理实践。既然我们已经讨论了集中化数据治理框架中需要具备哪些能力，让我们列举中央团队需要维护的工件。Artifacts为了向组织提供上述功能，中央数据治理团队需要维护以下工件：企业词典（Enterprise Dictionary）：这可以是一个简单的纸质文档，也可以是一个自动化（并执行）某些政策的工具。企业词典是组织使用的信息类型的存储库。例如，与各种医疗程序相关的代码或有关任何财务交易必须收集的必要信息都是企业词典的一部分。中央团队可以提供验证服务，以确保满足这些条件。许多读者熟悉的一个简单示例是由美国邮政服务提供的地址验证和标准化 API。企业经常使用这些 API 来确保组织内任何数据库中存储的地址都是标准的。数据类别（Data Classes）：企业词典中的各种信息类型可以分组为数据类别，并可以以一致的方式定义与每个数据类别相关的政策。例如，与客户地址相关的数据政策可能是邮政编码对一类员工可见，但对于仅在处理该客户的工单时主动参与的客户支持人员可见的更详细信息可能是可见的。政策手册（Policy Book）：政策手册列出了组织中使用的数据类别，每个数据类别的处理方式，数据的保留期限，可以存储数据的位置，需要控制对数据的访问方式等。用例政策（Use Case Policies）：通常，围绕数据类别的政策取决于用例。一个简单的例子是，客户的地址可能由履行客户订单的发货部门使用，但不会被销售部门使用。用例可能更加微妙：例如，客户的地址可能用于确定特定商店驾驶距离内的客户数量，但不用于确定特定客户是否在驾驶距离内的特定商店。数据目录（Data Catalog）：这是一个管理与数据相关的结构元数据、血缘、数据质量等的工具。数据目录充当高效的搜索和发现工具。除了上述与数据相关的工件外，中央组织还需要维护单一身份验证 (SSO) 能力，以在整个组织中提供唯一的身份验证机制。由于许多自动化服务和 API 通过密钥访问，并且这些密钥不应以明文形式存储，因此密钥管理服务通常也是中央团队的额外职责。作为现代化过程的一部分，重要的是要启动这些工件并将其放置在适当的位置，以便随着数据转移到云中，它成为强大数据治理框架的一部分。不要将数据治理推迟到云迁移之后，因为这样做的组织往往会迅速失去对其数据的控制。现在，让我们看看框架的能力和工件如何在数据的生命周期内相互关联。数据的生命周期内的治理数据治理涉及整合人员、流程和技术，贯穿数据的整个生命周期。数据的生命周期包括以下阶段：数据创建：这是创建/捕获数据的阶段。在此阶段，应确保同时捕获元数据。例如，在捕获图像时，同时记录照片的时间和位置是很重要的。同样，在捕获点击流时，需要注意用户的会话ID、他们所在的页面、页面的布局（如果是根据用户个性化的），等等。数据处理：在捕获数据后，通常需要对其进行清理、丰富，并将其加载到数据仓库中。作为数据血缘的一部分，捕获这些步骤是重要的。除了血缘关系，还需要记录数据的质量属性。数据存储：通常将数据和元数据存储在持久存储中，如对象存储（S3、GCS等），数据库（Postgres、Aurora、AlloyDB等），文档数据库（DynamoDB、Spanner、Cosmos DB等），或数据仓库（BigQuery、Redshift、Snowflake等）。在这一阶段，需要确定行和列的安全性要求，以及是否需要在保存之前对任何字段进行加密。在数据治理团队的思考中，数据保护是至关重要的。数据目录：需要将持久化的数据输入到企业数据目录中，并启用发现 API 以进行搜索。必须记录数据及其用法的详细信息。数据归档：可以从生产环境中归档较旧的数据。如果是这样，请记得更新目录。必须注意是否法律要求进行此类归档。理想情况下，应根据适用于整个数据类别的策略自动执行归档方法。数据销毁：可以删除已经超过法定保留期的所有数据。这也需要包含在企业的策略手册中。对于这些阶段，您必须制定数据治理政策。执行这些阶段的人员需要具备一定的访问权限。同一人在数据生命周期的不同阶段可能会有不同的职责和关注点，因此以“角色”而非“职责”来思考会更有帮助：法务：确保数据使用符合合同要求和政府/行业法规。数据监管员：数据的所有者，为特定数据项设置政策的人。数据管理者：为数据类别制定政策，并确定特定数据项属于哪个类别的人。隐私专员：确保用例不会泄露个人身份信息。数据用户：通常是使用数据进行业务决策的数据分析师或数据科学家。既然我们已经了解了可能的迁移、安全和治理框架，让我们深入研究如何开始执行迁移。架构、流水线和数据迁移在本节中，我们将更详细地探讨可用于架构和流水线迁移的模式以及在数据传输过程中可能面临的挑战。架构迁移在将旧有应用程序迁移到新的目标系统时，你可能需要演进你的模式，以利用目标系统提供的所有功能。首先将模型按原样迁移到目标系统，连接上游（数据源和传输数据的流水线）和下游（用于处理、查询和可视化数据的脚本、过程和业务应用程序）流程，然后利用目标环境的处理引擎执行所有更改，是最佳实践。这种方法有助于确保您的解决方案在新环境中正常工作，最小化停机风险，并允许您在第二阶段进行更改。在这里，通常可以应用外观模式——一种设计方法，通过一组视图向下游流程公开隐藏底层表的视图，以隐藏最终所需更改的复杂性。然后，这些视图可以描述一个新的模式，有助于利用临时目标系统功能，而不干扰由此抽象层“保护”的上游和下游流程。如果无法采用这种方法，数据必须在进入新系统之前进行转换和转换。这些活动通常由迁移范围内的数据转换流水线执行。流水线迁移在将传统系统迁移到云中时，有两种不同的策略可以采用：卸载工作负载：在这种情况下，保留供给源系统的上游数据流水线，并将数据的增量副本放入目标系统。最后，更新下游流程以从目标系统读取数据。然后，您可以继续卸载下一个工作负载，直到完成。完成后，可以开始完全迁移数据流水线。完全迁移工作负载：在这种情况下，必须将所有内容都迁移到新系统（与数据流水线一起），然后淘汰相应的传统表。供给工作负载的数据需要进行迁移。它可以来自各种数据源，并且可能需要特定的转换或连接操作以使其可用。一般来说，有四种不同的数据流水线模式：ETL（抽取-转换-加载）：所有转换活动，以及数据收集和数据摄入，将由一个特定的系统执行，该系统具有适当的基础设施和适当的编程语言（该工具通常可以使用标准编程语言进行编程）。ELT（抽取-加载-转换）：与ETL类似，但有一个区别，所有转换将由数据将被摄入的处理引擎执行（正如我们在前面的章节中看到的，这是处理现代云解决方案时的首选方法）。提取和加载（EL）：这是最简单的情况，数据已经准备好，不需要进一步的转换。变更数据捕获（CDC）：这是一种用于跟踪源系统中数据更改并在目标系统中反映这些更改的模式。它通常与ETL解决方案一起工作，因为它在对下游流程进行任何更改之前存储原始记录。正如您在前一节中看到的，您可以为不同的工作负载迁移识别不同的方法。相同的方法论可以应用于数据流水线：退役（Retire）：数据流水线解决方案不再使用，因为它与旧用例相关或已被新解决方案取代。保留（Retain）：数据流水线解决方案仍然留在传统系统中，因为它可能很快就可以退役，因此启动迁移项目不是经济上可行的。也可能存在一些法规要求，禁止在公司边界之外移动数据。重托（Rehost）：数据流水线解决方案被提升并移到云环境中，利用IaaS范式。在这种情况下，除了在连接级别进行一些修改之外，您不会引入任何大的修改，其中可能需要设置专用网络配置（通常是虚拟专用网络或VPN）以启用云环境和本地环境之间的通信。如果上游流程在公司边界之外（例如，第三方提供商、其他云环境等），可能不需要VPN，因为可以使用其他技术（例如经过身份验证的REST API）以安全的方式建立通信。在继续之前，有必要向云供应商验证底层系统中是否存在任何技术限制，以防止解决方案的正确执行，并仔细检查可能的许可证限制。重平台（Replatform）：在此情况下，数据流水线解决方案的一部分在迁移之前进行了转换，以便利用云的功能，例如PaaS数据库或容器化技术。在“重托”描述中突出显示的连接方面的考虑仍然有效。重构（Refactor）：流水线解决方案将迁移到一个或多个云完全托管的PaaS解决方案（例如，Amazon EMR、Azure HDInsight、Google Cloud Dataproc、Databricks）。在采用此方法时，最好采用与整个迁移相同的迭代方法：准备并发现要迁移的作业，可能按复杂性组织它们。计划和评估可能要迁移的MVP。执行迁移并根据定义的KPI评估结果。对所有其他作业进行迭代，直到结束。在“重托”部分突出显示的连接方面的注意事项仍然有效。替代（Replace）：流水线解决方案将被第三方现成或SaaS解决方案（例如，Fivetran、Xplenty、Informatica等）完全替换。在“重托”部分突出显示的连接方面的注意事项仍然有效。重建（Rebuild）：流水线解决方案将使用云完全托管的解决方案（例如，AWS Glue、Azure Data Factory、Google Cloud Dataflow）进行完全重建。在“重托”部分突出显示的连接方面的注意事项仍然有效。在迁移阶段，特别是与目标系统集成时，您可能会发现您的数据流水线解决方案与确定的目标云解决方案并不完全兼容。您可能需要一个连接器（通常称为接收器），它能够在数据流水线解决方案（例如ETL系统）与目标环境之间进行通信。如果该解决方案的接收器不存在，您可能能够生成一个文件作为过程的输出，然后在以下步骤中摄入数据。虽然这种方法会引入额外的复杂性，但在紧急情况下（等待供应商提供连接器时）是一种可行的临时解决方案。数据迁移现在您已经准备好新的模式和流水线，您可以开始迁移所有数据了。您应该着重考虑如何处理数据传输。您可能希望将所有本地数据迁移到云中，甚至是陈旧的老磁带（也许将来某天会有人要求这些数据）。您可能会面临一个事实，即在周末通过单个FTP连接完成任务可能是不够的。计划数据迁移需要计划。您需要确定并牵涉到：技术负责人能够提供执行迁移所需资源访问权限的人员（例如存储、IT、网络等）。批准者能够为您提供所需批准以获取数据访问权限并启动迁移的人员（例如数据所有者、法律顾问、安全管理员等）。交付迁移团队。如果可用，可以是组织内部的人员，或者是属于第三方系统集成商的人员。然后，您需要收集尽可能多的信息，以充分了解您需要做什么，以及以什么顺序进行（例如，也许您的迁移团队需要获准访问包含要迁移的数据的特定网络存储区域），以及可能会遇到的阻碍。以下是一些问题（不是详尽无遗的），在继续之前您应该能够回答这些问题：您需要迁移哪些数据集？基础数据在组织中的位置在哪里？您被允许迁移哪些数据集？是否有任何特定的法规要求您必须遵守？数据将落地在哪里（例如对象存储与DWH存储）？目的地区域是什么（例如欧洲、中东和非洲、英国、美国等）？是否需要在传输之前执行任何转换？您想要应用哪些数据访问策略？这是否是一次性的传输，还是您需要定期迁移数据？数据传输的资源有哪些？分配的预算是多少？您是否有足够的带宽来完成传输，以及是否足够的时间？您是否需要利用脱机解决方案（例如Amazon Snowball、Azure Data Box、Google Transfer Appliance）？完成整个数据迁移需要多长时间？一旦了解了正在迁移的数据的属性，您需要考虑影响迁移的可靠性和性能的两个关键因素：容量和网络。区域性容量和连接到云的网络在处理云数据迁移时，通常需要仔细考虑两个元素：区域性容量和连接到云的网络质量。区域性容量：云环境并非无限可扩展。事实上，硬件需要由云提供商在区域位置购买、准备和配置。一旦确定了目标架构和处理数据平台所需的资源，你还应该向选定的超大规模提供商提交一个区域容量计划，以确保数据平台将拥有满足平台使用和未来增长需求的所有所需硬件。通常，他们希望了解迁移数据的数量，以及在云中生成的数据量，您需要用来处理数据的计算量，以及与其他系统进行交互的次数。所有这些组成部分将作为输入提供给超大规模，以确保底层基础设施将从第一天开始准备好为所有工作负载提供服务。在出现缺货的情况下（如果您的用例涉及GPU，则这种情况很常见），您可能需要在其他地区选择相同的服务（如果没有合规性/技术影响），或者利用其他计算类型服务（例如，IaaS与PaaS相比）。连接到云的网络：即使网络现在被视为大宗商品，在每个云基础设施中仍起着至关重要的作用：如果网络速度慢或无法访问，组织的某些部分可能会完全与其业务数据断开连接（即使在利用本地环境时也是如此）。在设计云平台时，你需要首先考虑以下一些问题：我的组织将如何连接到云？我将利用哪个合作伙伴来建立连接？我是利用标准互联网连接（可能在其上使用VPN），还是想要支付额外的专用连接费用以确保更好的可靠性？所有这些主题通常都在RFI/RFP问卷中讨论，但它们也应该是与你选择设计和实施平台的供应商/合作伙伴进行的最初的研讨会之一的一部分。连接到云的主要方式有三种：公共互联网连接：利用公共互联网网络。在这种情况下，组织通常在公共互联网协议之上利用VPN来保护其数据，并确保适当的可靠性水平。性能与组织能否靠近所选云超大规模的最近点有关。合作伙伴互联：这是组织可能用于其生产工作负载的典型连接之一，特别是当他们需要具有高吞吐量的性能保证时。这种连接是组织与选定合作伙伴之间的连接，然后该合作伙伴负责与选定的超大规模建立连接。通过利用电信服务提供商的普遍性，组织可以建立高性能的连接，而价格又适中。直接互联：这是可能的最佳连接，其中组织直接（物理上）与云提供商的网络连接。（当双方都在同一物理位置拥有路由器时，这是可能的。）可靠性、吞吐量和一般性能是最佳的，并且定价可以直接与所选的超大规模进行讨论。有关如何配置这三种连接选项的更多详细信息，请参阅Azure、AWS和Google Cloud的文档。通常在PoC/MVP阶段，选择公共互联网连接选项，因为设置速度更快。在生产中，合作伙伴互联是最常见的，特别是当组织希望利用多云方法时。转移选项选择将数据传输到云端的方式时，请考虑以下因素：成本考虑数据传输可能涉及的以下潜在成本：网络在进行数据传输之前，您可能需要提升网络连接性。也许您的带宽不足以支持迁移，您需要与供应商协商以增加额外的线路。云服务提供商向云服务提供商上传数据通常是免费的，但如果您不仅从本地环境导出数据，还从另一个超级规模云提供商导出数据，可能会收取出口费用（通常每导出1GB收费），还可能收取读取费用。产品您可能需要购买或租赁存储设备以加速数据传输。人员执行迁移的团队。时间了解您需要传输的数据量和您可用的带宽是重要的。一旦了解了这些，您将能够确定传输数据所需的时间。例如，如果您需要传输200TB的数据，而您只有10Gbps的带宽可用，您将需要大约两天的时间来完成传输。这假定带宽完全可用于数据传输，这可能并非总是如此。如果在分析过程中发现需要更多带宽，您可能需要与互联网服务提供商（ISP）合作，请求增加带宽或确定一天中带宽可用的时间。这也可能是与云供应商合作实施直连的正确时机。这可以防止您的数据通过公共互联网传输，并且可以为大规模数据传输提供更一致的吞吐量（例如，AWS Direct Connect，Azure ExpressRoute，Google Cloud Direct Interconnect）。离线与在线传输在某些情况下，在线传输可能不可行，因为它会花费太长时间。在这种情况下，选择使用离线处理并利用存储硬件。云供应商提供这种服务（例如，Amazon Snowball数据传输，Azure Data Box，Google Transfer Appliance），特别适用于数百TB到PB级别的数据传输。您可以从云供应商那里订购一个物理设备，必须连接到您的网络。然后，您将复制数据，数据将默认加密，然后请求发货到最近可用的供应商设施。一旦交付，数据将被复制到云中的适当服务（例如，AWS S3，Azure Blob Storage，Google Cloud Storage），并且可以随时使用。可用工具一旦清理了所有网络动态，您应该决定如何处理数据上传。根据您可能要定位的系统（例如，blob存储，DWH解决方案，数据库，第三方应用程序等），通常您可以选择以下选项：命令行工具工具（例如，AWS CLI，Azure Cloud Shell或Google Cloud SDK）允许您与云提供商的所有服务进行交互。您可以自动化和编排上传数据到所需目的地所需的所有流程。根据最终的工具，您可能需要在上传数据到最终目的地之前通过中间系统（例如，首先通过blob存储再将数据传入DWH），但由于各种工具的灵活性，您应该能够轻松实施工作流程，例如利用bash或PowerShell脚本。REST API 这将允许您将服务与您可能想要开发的任何应用程序集成，例如，您已经实施和利用的内部迁移工具或您可能想要为特定目的开发的全新应用程序。物理解决方案如前述离线与在线传输的描述中所讨论的，用于离线迁移的工具。第三方商业现成解决方案这些解决方案可能提供更多功能，如网络节流，自定义高级数据传输协议，高级编排和管理功能以及数据完整性检查。迁移步骤您的迁移将包括六个阶段（参见图4-3）：上游过程被修改以供应当前的遗留数据解决方案，以满足目标环境的需求。下游过程从遗留环境中读取的方式被修改为从目标环境中读取。历史数据以批量方式迁移到目标环境。在这一阶段，上游过程也被迁移到写入目标环境。下游过程现在连接到目标环境。利用CDC（Change Data Capture）管道，在遗留环境完全被废弃之前，可以在遗留和目标环境之间保持数据同步。下游过程变得完全操作，利用目标环境。有一些最终检查你应该执行，以确保不会遇到瓶颈或数据传输问题：执行功能测试。您需要执行一个测试来验证整个数据传输迁移是否正常工作。理想情况下，在执行MVP期间执行此测试，选择大量数据，充分利用可能在整个迁移过程中使用的所有工具。这一步的目标主要是验证您可以正确操作数据传输，同时发现潜在的可能导致项目停滞的问题，例如无法使用工具（例如，您的工作人员未经培训，或者您没有系统集成商的充分支持）或网络问题（例如，网络路由）。执行性能测试。您需要验证当前基础架构是否能够处理大规模迁移。为此，您应该选择一个数据的大样本（通常在3%到5%之间）进行迁移，以确认您的迁移基础设施和解决方案是否正确根据迁移需求进行扩展，并且不会出现特定的瓶颈（例如，源存储系统速度慢）。执行数据完整性检查。在数据迁移过程中可能遇到的最关键问题之一是，由于错误而删除了迁移到目标系统的数据，或者数据损坏且无法使用。有一些方法可以保护数据免受这种风险：在目标位置启用版本控制和备份，以减轻意外删除的影响。在删除源数据之前验证您的数据。如果您使用标准工具执行迁移（例如，命令行界面或REST API），则必须自己管理所有这些活动。但是，如果您采用第三方应用程序，如Signiant Media Shuttle或IBM Aspera on Cloud，很可能已经默认实施了多种检查。（我们建议在选择解决方案之前仔细阅读应用程序说明中的可用功能。）总结在本章中，您已经看到了数据现代化旅程的实际方法，并审查了一个通用的技术迁移框架，可应用于从传统环境到现代云架构的任何迁移。主要要点如下：着重于现代化数据工作流，而不仅仅是升级单个工具。选择适合特定工作的正确工具将帮助您降低成本，充分发挥工具的潜力，并提高效率。可以在四个步骤中实施可能的数据迁移框架：准备和发现、评估和规划、执行和优化。准备和发现是一个关键的步骤，您在其中专注于定义迁移的范围，然后收集与已确定要迁移的各种工作负载/用例相关的所有信息。评估和规划是一个步骤，您在其中定义和计划完成已确定目标所需的所有活动（例如，对要迁移的工作负载进行分类和聚类，定义关键绩效指标，定义可能的MVP，以及定义与相关里程碑有关的迁移计划）。执行是一个步骤，在该步骤中，您迭代执行迁移，每次迭代都改善整个过程。优化是一个步骤，在该步骤中，您将整个新系统视为一个整体，并确定引入的可能新用例，使其更加灵活和强大。了解当前情况以及最终解决方案的总成本是一个复杂的步骤，可能涉及多个参与者。组织通常利用RFI、RFP和RFQ从供应商/潜在合作伙伴那里获取更多信息。治理和安全问题仍然是大多数组织的集中关注。这是因为在角色定义、数据安全和活动记录方面需要一致性。迁移框架必须与一个非常明确定义的治理框架相一致，这对数据的整个生命周期至关重要。在迁移数据架构时，可能有助于利用类似外观模式的模式，使目标解决方案功能的采用变得更容易。当使用云解决方案时，连接性和保障区域容量是至关重要的。网络配置、带宽可用性、成本、人员、工具、性能和数据完整性是必须为每个工作负载澄清的主要要点。在前面的四章中，您已经了解了为什么要构建数据平台，达到目标的策略，如何提升员工技能，以及如何进行迁移。在接下来的几章中，我们将深入探讨架构细节，首先从如何构建现代数据湖开始。

浏览量2033

秋叶无缘

Python数据分析从入门到进阶：模型评估和选择（含详细代码）

引言之前我们介绍了机器学习的一些基础性工作，介绍了如何对数据进行预处理，接下来我们可以根据这些数据以及我们的研究目标建立模型。那么如何选择合适的模型呢？首先需要对这些模型的效果进行评估。本文介绍如何使用sklearn代码进行模型评估模型评估对模型评估的基本步骤如下：首先将要将数据集分为训练集和测试集对训练集进行模型拟合确定合适的评估指标计算在测试集上的评估指标1 数据集划分在机器学习问题中，从理论上我们需要对数据集划分为训练集、验证集、测试集。训练集：拟合模型（平常的作业和测试）验证集：计算验证集误差，选择模型（模拟考）测试集：评估模型（最终考试）但是在实际应用中，一般分为训练集和测试集两个。其中训练集：70%，测试集：30%.这个比例在深度学习中可以进行相应的调整。我们可以使用sklearn中的train_test_split划分数据集# 导入相关库 from sklearn.model_selection import train_test_split from sklearn import datasets from sklearn import metrics from sklearn.model_selection import KFold, cross_val_score from sklearn.pipeline import make_pipeline from sklearn.linear_model import LogisticRegression from sklearn.preprocessing import StandardScaler import pandas as pd# 导入数据 df = pd.read_csv(r'C:\Users\DELL\data-science-learning\seaborn-data\iris.csv') df.shape(150, 5)# 划分数据集和测试集 train_set, test_set = train_test_split(df, test_size=0.3, random_state=12345)train_set.shape, test_set.shape((105, 5), (45, 5))可以看出此时训练集只有105个数据，测试集有45个数据。2.交叉验证模型评估模型时，我们最常用的方法之一就是==交叉验证==，下面以一个具体案例来看如何实现，代码如下# 加载数据 digits = datasets.load_digits()# 创建特征矩阵 features = digits.data target = digits.target# 进行标准化 stand = StandardScaler()# 创建logistic回归器 logistic = LogisticRegression()# 创建一个包含数据标准化和逻辑回归的流水线 pipline = make_pipeline(stand, logistic)# 先对数据进行标准化，再用logistic回归拟合# 创建k折交叉验证对象 kf = KFold(n_splits=10, shuffle=True, random_state=1)使用shuffle打乱数据，保证我们验证集和训练集是独立同分布的(IID)的# 进行k折交叉验证 cv_results = cross_val_score(pipline, features, target, cv=kf, scoring='accuracy',#评估的指标 n_jobs=-1)#调用所有的cpucv_results.mean()0.9693916821849783使用pipeline方法可以使得我们这个过程很方便，上述我们是直接对数据集进行了交叉验证，在实际应用中，建议先对数据集进行划分，再对训练集使用交叉验证。from sklearn.model_selection import train_test_split# 划分数据集 features_train, features_test, target_train, target_test = train_test_split(features, target, test_size=0.1,random_state=1)# 使用训练集来计算标准化参数 stand.fit(features_train)StandardScaler()# 然后在训练集和测试集上运用 features_train_std = stand.transform(features_train) features_test_std = stand.transform(features_test)这里之所以这样处理是因为我们的测试集是未知数据，如果使用测试集和训练集一起训练预处理器的话，测试集的信息有一部分就会泄露，因此是不科学的。在这里我认为更general的做法是先将训练集训练模型，用验证集评估选择模型，最后再用训练集和验证集一起来训练选择好的模型，再来在测试集上进行测试。pipeline = make_pipeline(stand, logistic)cv_results = cross_val_score(pipline, features_train_std, target_train, cv=kf, scoring='accuracy', n_jobs=-1)cv_results.mean()0.96351123380108893.回归模型评估指标评估回归模型的主要指标有以下几个 # 导入相关库 from sklearn.datasets import make_regression from sklearn.model_selection import cross_val_score from sklearn.linear_model import LinearRegression from sklearn import metrics# 建立模拟数据集 features, target = make_regression(n_samples=100, n_features=3, n_informative=3, n_targets=1, noise=50, coef=False, random_state=1)# 创建LinerRegression回归器 ols = LinearRegression()metrics.SCORERS.keys()dict_keys(['explained_variance', 'r2', 'max_error', 'neg_median_absolute_error', 'neg_mean_absolute_error', 'neg_mean_absolute_percentage_error', 'neg_mean_squared_error', 'neg_mean_squared_log_error', 'neg_root_mean_squared_error', 'neg_mean_poisson_deviance', 'neg_mean_gamma_deviance', 'accuracy', 'top_k_accuracy', 'roc_auc', 'roc_auc_ovr', 'roc_auc_ovo', 'roc_auc_ovr_weighted', 'roc_auc_ovo_weighted', 'balanced_accuracy', 'average_precision', 'neg_log_loss', 'neg_brier_score', 'adjusted_rand_score', 'rand_score', 'homogeneity_score', 'completeness_score', 'v_measure_score', 'mutual_info_score', 'adjusted_mutual_info_score', 'normalized_mutual_info_score', 'fowlkes_mallows_score', 'precision', 'precision_macro', 'precision_micro', 'precision_samples', 'precision_weighted', 'recall', 'recall_macro', 'recall_micro', 'recall_samples', 'recall_weighted', 'f1', 'f1_macro', 'f1_micro', 'f1_samples', 'f1_weighted', 'jaccard', 'jaccard_macro', 'jaccard_micro', 'jaccard_samples', 'jaccard_weighted'])# 使用MSE对线性回归做交叉验证 cross_val_score(ols, features, target, scoring='neg_mean_squared_error', cv=5)array([-1974.65337976, -2004.54137625, -3935.19355723, -1060.04361386, -1598.74104702])cross_val_score(ols, features, target, scoring='r2')array([0.8622399 , 0.85838075, 0.74723548, 0.91354743, 0.84469331])4.创建一个基准回归模型from sklearn.datasets import load_boston from sklearn.dummy import DummyRegressor from sklearn.model_selection import train_test_split# 加载数据 boston = load_boston()features, target = boston.data, boston.target# 将数据分为测试集和训练集 features_train, features_test, target_train, target_test = train_test_split(features, target, random_state=0)# 创建dummyregression对象 dummy = DummyRegressor(strategy='mean')# 训练模型 dummy.fit(features_train, target_train)DummyRegressor()dummy.score(features_test, target_test)-0.001119359203955339# 下面我们训练自己的模型进行对比 from sklearn.linear_model import LinearRegression ols = LinearRegression() ols.fit(features_train, target_train)LinearRegression()ols.score(features_test, target_test)0.6354638433202129通过与基准模型的对比，我们可以发现我们线性回归模型的优势5.混淆矩阵评估分类器性能一个重要方法是查看混淆矩阵。一般的想法是计算A类实例被分类为B类的次数，以及B类被预测为A类的个数。要计算混淆矩阵，首先需要有一组预测，以便与实际目标进行比较。==混淆矩阵==如下图所示：其中：TP：正确预测正类的个数FP：错误预测正类的个数TN：正确预测负类的个数FN：错误预测负类的个数下面我们来看如何使用具体的代码得到混淆矩阵# 导入相关库 import matplotlib.pyplot as plt import seaborn as sns from sklearn import datasets from sklearn.linear_model import LogisticRegression from sklearn.model_selection import train_test_split from sklearn.metrics import confusion_matrix import pandas as pd# 加载数据 iris = load_iris()features = iris.datatarget = iris.targetclass_names = iris.target_namesfeatures_train, features_test, target_train, target_test = train_test_split( features, target, random_state = 1)classfier = LogisticRegression()target_predicted = classfier.fit(features_train, target_train).predict(features_test)# 创建一个混淆矩阵 matrix = confusion_matrix(target_test, target_predicted)df = pd.DataFrame(matrix, index = class_names, columns=class_names)sns.heatmap(df, annot=True, cbar=None, cmap='Blues') plt.ylabel('True Class') plt.xlabel('Predict Class') plt.title('Confusion matrix')Text(0.5, 1.0, 'Confusion matrix')6.分类评估指标对于分类问题的评估指标主要包含以下几个：其中，对于非均衡数据，使用F1-score比较合理。下面我们来看具体如何得到这些评估指标from sklearn.model_selection import cross_val_score from sklearn.linear_model import LogisticRegression from sklearn.datasets import make_classification# 创建模拟数据集 X, y = make_classification(random_state=1, n_samples=1000, n_features=3, n_informative=3, n_redundant=0, n_classes=2)# 创建逻辑回归器 logit = LogisticRegression()# 使用准确率对模型进行交叉验证 cross_val_score(logit, X, y, scoring='accuracy')array([0.87, 0.88, 0.85, 0.93, 0.9 ])cross_val_score(logit, X, y, scoring='f1')array([0.87735849, 0.88235294, 0.85849057, 0.92708333, 0.90384615])cross_val_score(logit,X,y,scoring='precision')array([0.83035714, 0.86538462, 0.8125 , 0.9673913 , 0.86238532])其中，我们可以看出，==召回率==和==精确率==两个往往不会同时增加(增加样本量可能可以让两个指标同时增加)，这里有点像我们假设检验中的第一类错误和第二类错误。因此，我们要保证这两个指标都不能太小。下面我们介绍ROC和AUC7.ROC和AUC7.1 ROC曲线RUC曲线是用于二分类器的另一个常用工具。它与精密度/召回率非常相似，但不是绘制精密度与召回率的关系，而是绘制真阳性率（召回率的另一个名称）与假阳性率（FPR）的关系。FPR是未正确归类为正的负实例的比率。通过ROC曲线来进行评估，计算出每个阈值下的真阳性率和假阳性率# 导入相关库 import matplotlib.pyplot as plt from sklearn.datasets import make_classification from sklearn.linear_model import LogisticRegression from sklearn.metrics import roc_curve, roc_auc_score from sklearn.model_selection import train_test_splitfeatures, target = make_classification(n_samples=1000, n_features=10, n_classes=2, n_informative=3, random_state=3)features_train, features_test, target_train, target_test = train_test_split(features, target, test_size=.1, random_state=1)logit.fit(features_train, target_train)LogisticRegression()# 预测为1的概率 target_probabilities = logit.predict_proba(features_test)[:,1]target_testarray([0, 0, 1, 0, 1, 1, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 0, 1, 1, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 1, 0, 1, 0, 1, 0, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1])这里我们选取所有第二列的概率的值，也就是所有为正类的值false_positive_rate, true_positive_rate, thresholds = roc_curve(target_test,target_probabilities)我们默认是将概率大于50%的判断为正类，但当我们实际应用时，可以对阈值进行相应的调整，例如我们可以增加阈值，保证正类的准确度更高，如下所示y_predict = target_probabilities>0.6 y_predictarray([False, False, True, False, True, True, False, True, False, False, False, True, False, False, False, True, False, False, False, False, True, True, True, False, True, True, True, False, True, False, True, False, True, True, False, False, True, True, True, True, True, False, False, True, False, True, True, False, False, False, False, True, False, False, True, True, True, False, True, False, True, False, False, True, True, False, True, True, True, True, True, True, False, True, False, False, True, False, False, False, False, True, True, False, True, False, True, False, True, False, False, True, False, False, True, False, True, False, False, True])# 绘制AUC曲线 plt.plot(false_positive_rate, true_positive_rate) plt.plot([0, 1], ls='--') plt.plot([0, 0], [1, 0], c='.7') plt.plot([1,1], c='.7')# 我们可以通过predict_proba 查看样本的预测概率 logit.predict_proba(features_test)[2]array([0.02210395, 0.97789605])logit.classes_array([0, 1])7.2 AUC值比较分类器的一种方法是测量曲线下面积（AUC）。完美分类器的AUC等于1，而适当的随机分类器的AUC等于0.5。Sklearn提供了一个计算AUC的函数roc_auc_score计算==AUC==值 roc_auc_score(target_test,target_probabilities)0.9747899159663865可以看出该分类器的AUC值为0.97，说明该模型的效果很好。由于ROC曲线与精度/召回（PR）曲线非常相似，您可能想知道如何决定使用哪一条曲线。根据经验，当阳性类别很少，或者当你更关心假阳性而不是假阴性时，你应该更喜欢PR曲线。否则，使用ROC曲线。8.创建一个基准分类模型from sklearn.datasets import load_iris from sklearn.dummy import DummyClassifier from sklearn.model_selection import train_test_splitiris = load_iris()features, target = iris.data, iris.target# 划分数据集 features_train, features_test, target_train, target_test = train_test_split(features, target, random_state=0)dummy = DummyClassifier(strategy='uniform', random_state=1)dummy.fit(features_train, target_train)DummyClassifier(random_state=1, strategy='uniform')dummy.score(features_test, target_test)0.42105263157894735# 接下来我们创建自己的模型from sklearn.ensemble import RandomForestClassifier#随机森林分类，考虑在后面分享classfier = RandomForestClassifier()classfier.fit(features_train, target_train)RandomForestClassifier()classfier.score(features_test, target_test)0.9736842105263158可以看出，随机森林模型效果更好9.可视化训练集规模的影响我们都知道，只要给我们足够多的数据集，那我们基本能训练一个效果很好的模型，接下来我们来看看如何绘制训练集大小对模型效果的影响(learning curve)import numpy as np import matplotlib.pyplot as plt from sklearn.ensemble import RandomForestClassifier from sklearn.datasets import load_digits from sklearn.model_selection import learning_curvedigits = load_digits()features, target = digits.data, digits.target# 使用交叉验证为不同规模的训练集计算训练和测试得分 train_sizes, train_scores, test_scores = learning_curve(RandomForestClassifier(), features, target, cv=10, scoring='accuracy', n_jobs=-1, train_sizes=np.linspace(0.01,1,50))# 计算训练集得分的平均值和标准差 train_mean = np.mean(train_scores, axis=1) train_std = np.std(train_scores, axis=1)test_mean = np.mean(test_scores, axis=1) test_std = np.std(test_scores, axis=1)plt.plot(train_sizes, train_mean, '--', color='black', label='Training score') plt.plot(train_sizes, test_mean, color='black', label='Cross-validation score') plt.fill_between(train_sizes, train_mean-train_std, train_mean + train_std, color='#DDDDDD') plt.fill_between(train_sizes, test_mean-test_std, test_mean + test_std, color='#DDDDDD') plt.title('learning_curve') plt.xlabel('Training Set Size') plt.ylabel('Accuracy Score') plt.legend(loc='best') plt.tight_layout() plt.show()10. 生成评估指标报告from sklearn.metrics import classification_reportiris = datasets.load_iris()features = iris.datatarget = iris.targetclass_names = iris.target_namesfeatures_train, features_test, target_train, target_test = train_test_split( features, target, random_state = 1)classfier = LogisticRegression()model = classfier.fit(features_train, target_train) target_predicted = model.predict(features_test)# 生成分类器的性能报告 print(classification_report(target_test, target_predicted, target_names=class_names)) precision recall f1-score support setosa 1.00 1.00 1.00 13 versicolor 1.00 0.94 0.97 16 virginica 0.90 1.00 0.95 9 accuracy 0.97 38 macro avg 0.97 0.98 0.97 38 weighted avg 0.98 0.97 0.97 38

浏览量2015

秋叶无缘

Python数据分析入门到进阶：数据清洗（含详细代码）

在上一篇文章中，介绍了如何使用python导入数据，导入数据后的第二步往往就是数据清洗，下面我们来看看如何使用pandas进行数据清洗工作导入相关库import pandas as pd dataframe = pd.read_csv(r'C:/Users/DELL/data-science-learning/python数据分析笔记/探索性数据分析/train.csv') dataframe.head(5)PassengerIdSurvivedPclassNameSexAgeSibSpParchTicketFareCabinEmbarked0103Braund, Mr. Owen Harrismale22.010A/5 211717.2500NaNS1211Cumings, Mrs. John Bradley (Florence Briggs Th...female38.010PC 1759971.2833C85C2313Heikkinen, Miss. Lainafemale26.000STON/O2. 31012827.9250NaNS3411Futrelle, Mrs. Jacques Heath (Lily May Peel)female35.01011380353.1000C123S4503Allen, Mr. William Henrymale35.0003734508.0500NaNS1.总览数据查看数据维度dataframe.shape(891, 12)描述性统计分析dataframe.describe().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } PassengerIdSurvivedPclassAgeSibSpParchFarecount891.000000891.000000891.000000714.000000891.000000891.000000891.000000mean446.0000000.3838382.30864229.6991180.5230080.38159432.204208std257.3538420.4865920.83607114.5264971.1027430.80605749.693429min1.0000000.0000001.0000000.4200000.0000000.0000000.00000025%223.5000000.0000002.00000020.1250000.0000000.0000007.91040050%446.0000000.0000003.00000028.0000000.0000000.00000014.45420075%668.5000001.0000003.00000038.0000001.0000000.00000031.000000max891.0000001.0000003.00000080.0000008.0000006.000000512.3292002.筛选数据过滤所有女性和年龄大于60岁的乘客dataframe[(dataframe['Sex'] == 'female') & (dataframe['Age']>=60)].dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } PassengerIdSurvivedPclassNameSexAgeSibSpParchTicketFareCabinEmbarked27527611Andrews, Miss. Kornelia Theodosiafemale63.0101350277.9583D7S36636711Warren, Mrs. Frank Manley (Anna Sophia Atkinson)female60.01011081375.2500D37C48348413Turkula, Mrs. (Hedwig)female63.00041349.5875NaNS82983011Stone, Mrs. George Nelson (Martha Evelyn)female62.00011357280.0000B28NaN可以看出，一共有四名年龄大于60岁的女性乘客3.替换数据将female换成woman，将male换成mandataframe['Sex'].replace(['female','male'],['woman','man']).head(5)0 man 1 woman 2 woman 3 woman 4 man Name: Sex, dtype: object4.更改列名查看所有列名dataframe.columnsIndex(['PassengerId', 'Survived', 'Pclass', 'Name', 'Sex', 'Age', 'SibSp', 'Parch', 'Ticket', 'Fare', 'Cabin', 'Embarked'], dtype='object')重命名列PassengerIdSurvivedPassenger ClassNameSexAgeSibSpParchTicketFareCabinEmbarked0103Braund, Mr. Owen Harrismale22.010A/5 211717.2500NaNS1211Cumings, Mrs. John Bradley (Florence Briggs Th...female38.010PC 1759971.2833C85C2313Heikkinen, Miss. Lainafemale26.000STON/O2. 31012827.9250NaNS3411Futrelle, Mrs. Jacques Heath (Lily May Peel)female35.01011380353.1000C123S4503Allen, Mr. William Henrymale35.0003734508.0500NaNSdataframe.rename(columns={'Pclass':'Passenger Class','Sex':'Gender'}).head().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } PassengerIdSurvivedPassenger ClassNameGenderAgeSibSpParchTicketFareCabinEmbarked0103Braund, Mr. Owen Harrismale22.010A/5 211717.2500NaNS1211Cumings, Mrs. John Bradley (Florence Briggs Th...female38.010PC 1759971.2833C85C2313Heikkinen, Miss. Lainafemale26.000STON/O2. 31012827.9250NaNS3411Futrelle, Mrs. Jacques Heath (Lily May Peel)female35.01011380353.1000C123S4503Allen, Mr. William Henrymale35.0003734508.0500NaNS5.查找唯一值在pandas中，我们可以使用unique()查找唯一值# 查找唯一值 dataframe['Sex'].unique()array(['male', 'female'], dtype=object)# 显示唯一值出现的个数 dataframe['Sex'].value_counts()male 577 female 314 Name: Sex, dtype: int64# 查找类型票的数量 dataframe['Pclass'].value_counts()3 491 1 216 2 184 Name: Pclass, dtype: int64# 查找唯一值的种类 dataframe['Pclass'].nunique()36.查找缺失值# 查找空数据dataframe[dataframe['Age'].isnull()].head().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } PassengerIdSurvivedPclassNameSexAgeSibSpParchTicketFareCabinEmbarked5603Moran, Mr. JamesmaleNaN003308778.4583NaNQ171812Williams, Mr. Charles EugenemaleNaN0024437313.0000NaNS192013Masselmani, Mrs. FatimafemaleNaN0026497.2250NaNC262703Emir, Mr. Farred ChehabmaleNaN0026317.2250NaNC282913O'Dwyer, Miss. Ellen "Nellie"femaleNaN003309597.8792NaNQpandas没有NaN 如果想要处理的话必须导入numpy包import numpy as np dataframe['Sex'].replace('male',np.nan).head()0 NaN 1 female 2 female 3 female 4 NaN Name: Sex, dtype: object7.删除列或行# 删除一列，采用drop方法，并传入参数axis dataframe.drop('Age',axis=1).head().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } PassengerIdSurvivedPclassNameSexSibSpParchTicketFareCabinEmbarked0103Braund, Mr. Owen Harrismale10A/5 211717.2500NaNS1211Cumings, Mrs. John Bradley (Florence Briggs Th...female10PC 1759971.2833C85C2313Heikkinen, Miss. Lainafemale00STON/O2. 31012827.9250NaNS3411Futrelle, Mrs. Jacques Heath (Lily May Peel)female1011380353.1000C123S4503Allen, Mr. William Henrymale003734508.0500NaNS#删除行 dataframe.drop(1)# 删除重复行使用subset参数指明要删除的列 dataframe.drop_duplicates(subset='Sex').head().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } NamePClassAgeSexSurvivedSexCode0Allen, Miss Elisabeth Walton1st29.0female112Allison, Mr Hudson Joshua Creighton1st30.0male008. groupby分组计算男性和女性的平均值==思路一==，将所有男性和女性的条件进行选取分别计算man = dataframe[dataframe['Sex']=='male'] woman = dataframe[dataframe['Sex']=='female'] print(man.mean()) print(woman.mean())Age 31.014338 Survived 0.166863 SexCode 0.000000 dtype: float64 Age 29.396424 Survived 0.666667 SexCode 1.000000 dtype: float64==思路二==，用groupby方法简化dataframe.groupby('Sex').mean().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } AgeSurvivedSexCodeSexfemale29.3964240.6666671.0male31.0143380.1668630.0# 按行分组，计算行数 dataframe.groupby('Sex')['Name'].count()Sex female 462 male 851 Name: Name, dtype: int64dataframe.groupby(['Sex','Survived']).mean().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } PassengerIdPclassAgeSibSpParchFareSexSurvivedfemale0434.8518522.85185225.0468751.2098771.03703723.0243851429.6995711.91845528.8477160.5150210.51502151.938573male0449.1217952.47649631.6180560.4401710.20726521.9609931475.7247712.01834927.2760220.3853210.35779840.8214849.按照时间段来进行分组使用resample参数来进行取样本# 创建时期范围 time_index = pd.date_range('06/06/2017', periods=100000, freq='30S') # periods表示有多少数据，freq表示步长dataframe = pd.DataFrame(index=time_index)# 创建一个随机变量 dataframe['Sale_Amout'] = np.random.randint(1, 10, 100000)# resample 参数，按周对行分组，计算每一周的总和 dataframe.resample('W').sum().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } Sale_Amout2017-06-11862922017-06-181003592017-06-251009072017-07-021008682017-07-091005222017-07-1610478# 使用resample可以按一组时间间隔来进行分组，然后计算每一个时间组的某个统计量 dataframe.resample('2W').mean().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } Sale_Amout2017-06-114.9937502017-06-254.9917162017-07-094.9947922017-07-235.037500dataframe.resample('M').count().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } Sale_Amout2017-06-30720002017-07-3128000# resample默认是以最后一个数据作使用label参数可以进行调整 dataframe.resample('M', label='left').count().dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } Sale_Amout2017-05-31720002017-06-302800010.遍历一个列的数据dataframe = pd.read_csv(url)# 以大写的形势打印前两行的名字 for name in dataframe['Name'][0:2]: print(name.upper())ALLEN, MISS ELISABETH WALTON ALLISON, MISS HELEN LORAINE11.对一列的所有元素应用某个函数def uppercase(x): return x.upper()dataframe['Name'].apply(uppercase)[0:2]0 ALLEN, MISS ELISABETH WALTON 1 ALLISON, MISS HELEN LORAINE Name: Name, dtype: object12. pandas高级函数dataframe.groupby('Sex').apply(lambda x:x.count()).dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } NamePClassAgeSexSurvivedSexCodeSexfemale462462288462462462male851851468851851851通过联合使用groupby 和apply，我们就能计算自定义的统计量例如上面我们发现age、cabin具有大量的缺失值13. 连接多个Dataframedata_a = {'id':['1', '2', '3'], 'first': ['Alex', 'Amy', 'Allen'], 'last': ['Anderson', 'Ackerman', 'Ali']} dataframe_a = pd.DataFrame(data_a, columns=['id','first', 'last'])data_b = {'id':['4', '5', '6'], 'first': ['Billy', 'Brian', 'Bran'], 'last': ['Bonder', 'Black', 'Balwner']} dataframe_b = pd.DataFrame(data_b, columns=['id','first', 'last'])pd.concat([dataframe_a, dataframe_b], axis=0)#在行的方向进行.dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } idfirstlast01AlexAnderson12AmyAckerman23AllenAli04BillyBonder15BrianBlack26BranBalwnerpd.concat([dataframe_a, dataframe_b], axis=1)#在列的方向进行.dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } idfirstlastidfirstlast01AlexAnderson4BillyBonder12AmyAckerman5BrianBlack23AllenAli6BranBalwner# 也可以用append方法进行添加 c = pd.Series([10, 'Chris', 'Chillon'], index=['id','first','last'])dataframe.append(c, ignore_index=True)#如果c原来有名字忽略.dataframe tbody tr th:only-of-type { vertical-align: middle; } .dataframe tbody tr th { vertical-align: top; } .dataframe thead th { text-align: right; } idfirstlast01AlexAnderson12AmyAckerman23AllenAli310ChrisChillon

浏览量2025

攻城狮无远

第三章：设计您的数据团队

在设计数据平台时，有几个技术方面需要考虑：性能、成本、运营开销、运营卓越、整合新的分析和机器学习方法等。然而，如果不解决公司文化的问题，这些技术方面将无法发挥作用——采用新技术需要员工愿意改变他们的思维模式和工作方式。另一个需要记住的关键方面是现有员工目前具备的技能以及他们需要掌握的技能。在某些情况下，学习新技能并改变工作方式的员工最终可能会进入与数据平台实施之前不同的角色。在本章中，我们探讨了组织如何规划和协调这些思维模式、工作流程、技术技能和角色的变化。每个组织都是独特的，因此构建数据平台将涉及为每个部门和其中的员工制定详细的计划。在本章中，我们描述了不同类型组织的这种详细计划会是什么样子。分类数据处理组织组织可以通过采用不同的策略基于其人才而取得成功。没有普遍适用的“最佳”方法。一支防守强大的体育队伍应该发挥他们的优势，专注于防守，而不是试图复制一支拥有技术出色进攻球员的球队的进攻。同样，如果你的组织拥有一支强大的数据分析团队，它应该专注于其人员，而不是试图转变为一个充满数据工程师的组织。根据你的员工技能和用例的复杂性，为你的组织决定最佳策略。你是否需要一小组数据工程师，他们能力强但成本高？还是应该利用大型且已经存在的数据分析员团队来丰富和转换可行动的数据？这些工作者需要多少领域知识？培训现有工作人员执行更高价值的工作是否切实可行？还是应该投资于生成式AI或无代码工具，并使这些基础技术的重要部分对更大范围的工作人员可用？最佳技术方法在组织内也会有所不同 - 销售团队和工厂车间之间的工作人员构成将有所不同。因此，详细的计划涉及为每个业务单元详细说明最佳的技术方法。从技术上讲，该计划还将在基于标准ETL的方法（需要ETL工具的硬技能）和基于ELT的现代方法之间做出选择（需要更通用的SQL技能）。考虑图3-1中勾画的传统用户画像价值链。你可以看到组织中的每个数据用户都拥有一组小而专业的技术技能。如果一个组织希望扩大其数据分析团队的范围，它还必须扩大其数据工程和数据科学团队的规模，以确保有足够的人具备正确的技术技能来支持数据分析员。公共云提供的新范式为数据处理、数据分析和算法开发提供了新的可能性。云技术现在使得新的工作方式成为可能 - 它们允许分析师执行曾由数据工程师管理的批处理或实时数据处理任务，同时还允许他们尝试使用现成的数据科学解决方案。此外，给定的任何用户画像的潜在范围 - 他们拥有的技能和他们负责的职责 - 已经增加。随着数据技术变得更加可访问，数据工作者能够承担新的任务，并在没有传统用户画像相关瓶颈的情况下处理数据价值链。这导致技能在角色之间的融合，使现有团队更容易扩展到其他职责。专注于使用SQL代码通过ELT方法解决问题的数据分析员和更倾向于使用ETL方法和通用代码（例如Python、Java、Scala等）的数据工程师/数据科学家之间的区别变得不那么明显。混合方法（如图3-2所示）变得越来越普遍，因为它们可以充分利用ETL和ELT模式的优势。我们今天看到的大多数组织都属于这种混合模型，尽管角色的平衡以及数据处理必须通过ETL或ELT的程度取决于组织的类型，存在一些变化。以数据分析为驱动的组织以数据分析为驱动的组织是在决策制定中数据分析师发挥核心作用的组织。值得注意的是，组织是否以分析师为主导不是一个非黑即白的问题，而是一系列重叠特征的谱系：成熟行业：这些组织是知名且经过时间验证的企业，拥有完善（也许是过时的）的系统。它们所处的行业通常是成熟且稳定的。主要工作涉及对各种产品或情况进行人工分析。数据分析为驱动的组织的典型例子包括零售商的商品单位（例如沃尔玛）和大型银行的商业贷款处理部门（例如摩根大通）。企业数据仓库（EDW）和批处理ETL：在技术层面上，中心信息枢纽是一个随时间建立起来的EDW，具有较高水平的技术债务和传统技术。在数据仓库内部的数据转换是通过定期的ETL过程进行的，比如夜间批处理。这种批处理过程增加了数据提供的延迟。商业智能：组织中的大多数数据专业人员习惯于通过对集中式数据仓库运行SQL查询、使用BI工具创建报告和仪表板，并使用电子表格来访问类似数据来回答业务问题。因此，内部人才储备最擅长于SQL、BI工具和电子表格。请注意，即使在零售和金融等成熟行业中，新兴的数字组织（电子商务和金融科技）可能会寻求捕捉增长最快的数字领域和具有最大潜力的客户细分市场。这样的数字原住民可能与传统大公司（例如Etsy与沃尔玛；Paytm与摩根大通）有不同的员工组成；我们不会将数字原住民与传统公司放在同一类别中。现在，您对我们所说的以分析为驱动的组织有了更清晰的了解，让我们讨论进行转型的主要手段。简单来说，数据工作者现在能够更高效地处理其拥有的数据，并能够以更高效的方式执行更多任务。这是因为技术变得更加易于访问，而且数据工作者能够将他们的技能与其他数据专业人员的技能相融合。这导致了一种更高效和有效的数据处理方式。组织可以广泛分为三种类型：以数据分析为驱动、以数据工程为驱动和以数据科学为驱动。在接下来的部分中，我们将介绍为每种类型构建数据处理组织的理想方式。在现实中，公司将包括属于这些类别的不同部门或业务单位，因此它们将发现自己应用所有这些策略。一些团队将是角色的组合，因此转型将涉及混合方法。在考虑将成为数据团队一部分的不同类型用户时，请记住在第二章学到的内容：“为了最大程度地发挥从数据中获得的优势，请应用产品管理原则。”您应始终使用产品管理原则来制定数据产品策略，以客户为中心，通过白板和原型发现产品，并在标准化和灵活性之间找到正确的平衡。愿景为在以分析驱动为特征的组织中普及云数据平台的使用，分析师应该能够通过熟悉的界面，如电子表格、SQL 和商业智能工具进行高级分析。这意味着提供易于使用的工具，将数据引入目标系统，并与分析和可视化工具实现无缝连接。这在传统企业数据仓库中曾是常见做法。使用 SQL 对数据进行丰富、转换和清理，使用 ETL 工具进行编排。同样，物化视图和用户定义函数可用于在现代数据仓库中丰富、转换和清理数据。然而，这假设分析师已经能够访问所有数据源。创建复杂的摄取管道曾经是昂贵且常常繁琐的。因此，由于资源和成本的限制，数据管道是在数据仓库之外管理的。这在使用新的云数据仓库时已不再成立。摄取的角色现在仅仅是将数据带到云附近，而转换和处理部分则移回了云数据仓库。这导致数据被暂存在存储桶或消息系统中，然后被摄取到云数据仓库中。所有这些不仅减少了使数据可用所需的时间，还使数据分析师能够专注于使用他们习惯的工具和界面寻找数据洞见。因此，在新世界中，ELT 应该取代 ETL 工具——数据分析师可以使用 SQL 编排工具，如 dbt 或 Dataform，串联 SQL 语句来进行 ELT。直接从源或暂存区摄取数据使分析师能够利用他们的关键 SQL 技能，并增加他们接收数据的及时性。他们无需等待繁忙的数据工程团队实施 ETL 管道。总之，扩展云数据平台的使用最佳方法是为分析师提供易于使用的工具（如 dbt）和界面（如 Excel 或 Tableau），以便他们可以轻松掌握。这将使他们能够进行高级分析，而无需等待数据工程团队实施复杂的 ETL 管道。一旦数据在云数据仓库中可用，就是开始分析的时候了。过去，许多数据分析是使用电子表格完成的，但电子表格通常难以处理新世界中需要分析的大量数据。尽管 Google Sheets 和 Excel 具有连接到数据仓库的实时功能，但仍然有些繁琐。我们建议为分析师提供使用现代商业智能工具创建可处理大型数据集的可视化和报告的权限（例如 Power BI、Tableau 或 Looker）。人物角色分析驱动型组织数据部门中的主要角色包括数据分析师、业务分析师和数据工程师。数据分析师数据分析师接收、理解并满足业务的请求，理解相关数据。数据分析师的目标是满足组织的信息需求。他们负责数据的逻辑设计和维护。他们的一些任务可能包括创建符合业务流程的表格布局和设计，以及重新组织和转换数据源。此外，他们负责生成能够有效传达业务请求的趋势、模式或预测的报告和见解。为了构建分析驱动型组织的任务，有必要通过两种方式扩展数据分析师社区的经验和技能集。首先，推动数据分析师学习业务的趋势是至关重要的。数据分析师需要深入了解业务领域。其次，数据分析师需要获得分析和呈现数据的技术技能，无论数据的量或大小。幸运的是，现在可以使用 SQL 和 BI 工具来实现这一点。数据分析师技能的扩展，既包括业务领域，也包括大数据，如图 3-3 所示。业务分析师业务分析师是领域专家，利用数据进行分析洞察。基于云的数据仓库和无服务器技术已经将业务分析师的责任扩展到传统领域专家的领域。这是因为分析师现在可以专注于通过分析数据为业务增值，而不是浪费时间在管理和技术管理任务上。此外，存储在数据仓库中的数据的数量和类型不再是限制因素，因此分析师现在可以更深入地了解业务以获取洞察。数据仓库可以同时充当数据的着陆区域和结构化及半结构化数据的记录系统。这意味着业务分析师可以在一个地方获得所有需要分析的数据。总体而言，基于云的数据仓库和无服务器技术使业务分析师能够更加高效，为业务增加更多价值。尽管业务分析师可以使用无代码和低代码的机器学习模型，但他们在涉及机器学习或自然语言文本的更复杂工作流方面可能会遇到困难。他们还没有实施复杂数据科学算法的技能，比如排名或推荐。因此，如果您的激活需求更为复杂，仍然需要一个数据科学团队。数据工程师数据工程师专注于下游数据管道和数据转换的前几阶段，如加载和集成新数据源。他们还负责管理数据治理和数据质量流程。在以分析为驱动的组织中，数据工程师的数量将较少，因为数据分析团队基本上可以自给自足，能够构建简单的数据管道和机器学习模型。分析驱动的组织倡导ELT的概念，而不是传统的ETL。主要区别在于常见的数据处理任务是在数据加载到数据仓库后处理的。ELT广泛使用SQL逻辑来增强、清理、规范化、精炼和集成数据，使其准备好进行分析。这种方法有几个好处：它减少了行动时间，数据立即加载，并且可以同时提供给多个用户。因此，这样的组织的变更管理策略必须专注于诸如SQL、视图、函数、调度等方面。即使在分析驱动的组织中，数据工程团队通常仍然掌控从源系统提取数据的过程。尽管可以通过使用基于SQL的工具简化此过程，使数据分析师能够执行其中的一些工作，但仍然需要一个强大的数据工程团队。仍然有一些批处理作业需要创建数据管道，更适合使用ETL。例如，从主机到数据仓库传输数据需要额外的处理步骤：数据类型需要映射，COBOL书籍需要转换等。此外，对于实时分析等用例，数据工程团队将配置流数据源，如Pub/Sub、Kafka主题或Kinesis数据流。处理通用任务的方式仍然相同——它们可以被编写为通用的ETL管道，然后由分析师重新配置。例如，将来自各种源数据集的数据质量验证检查应用于目标环境将遵循由数据工程师设置的模板。技术框架有关面向分析驱动组织的高层参考架构，有三个基本原则：SQL 作为标准技术应该根据当前的组织文化进行定制。应优先考虑提供 SQL 接口的组件，无论它们在数据处理流程的哪个阶段。从企业数据仓库（EDW）/数据湖到结构化数据湖信息系统基础设施及其数据应进行集成，以扩展对新的和多样化数据源进行分析处理的可能性。这可能涉及将传统的数据仓库与数据湖合并，以消除信息孤岛（有关 lakehouse 架构的详细信息，请参阅第 7 章）。先读取后模式的模式由于存储成本较低，组织在收到数据之前不再需要对数据结构施加严格的规则。从写入模式（schema-on-write）转向读取模式（schema-on-read）允许对数据进行实时访问。数据可以保留其原始形式，然后转换为最有用的模式。此外，数据平台可以管理保持这些副本同步的过程（例如，使用物化视图、变更数据捕获等）。因此，请不要害怕保留相同数据资产的多个副本。将这些原则结合起来，我们可以定义一个高层架构，如图 3-4 所示。这个信息架构满足上述三个原则，并支持一些关键的数据分析模式：“传统”商业智能工作负载，如创建仪表板或报告允许通过 SQL 进行数据管道管理的自发分析界面（ELT）使用机器学习技术实现数据科学用例将数据实时流入数据仓库并处理实时事件这两种模式与传统的 SQL 数据仓库世界相当相似，但后两种则以 SQL 抽象的形式呈现更高级的分析模式。在 ML 领域，Redshift ML 或 BigQuery ML 允许数据分析师使用标准 SQL 查询在存储在数据仓库中的数据上执行 ML 模型。SQL 流扩展，如 Dataflow 和 KSQL，使得能够聚合具有无限制、实时源（如 Pub/Sub 或 Kafka）的数据流成为可能。即使无需投资于新的配置文件和/或角色，这项技术也能开启许多可能性。在为面向分析驱动组织选择 ELT 和 ETL 时，数据准备和转换是关键考虑因素。应尽可能使用 ELT，因为它允许使用 SQL 在结构化数据湖中对数据进行转换。这种方法提供了与广泛的数据集成套件相同的功能，但无需牺牲数据质量或运营监控。诸如 dbt 之类的产品将软件工程方法引入数据建模和构建数据工作流程中；dbt 实际上允许构建类似于由代码构建的 ETL 工作流的 ELT 工作流，但是使用的是 SQL。这使得数据分析师（不是系统程序员）能够进行可靠而复杂的数据转换。简而言之，对于面向分析驱动组织，ELT是比ETL更好的选择，因为它允许更灵活和更可控的数据转换。此外，dbt提供了数据建模和构建数据工作流的软件工程方法，有助于提高数据转换的可靠性和复杂性。数据工程驱动型组织一个以工程为驱动的组织专注于数据集成。有些公司（例如金融科技公司Plaid）的业务是为整个行业构建集成管道。更常见的情况是这是一个大型企业中的一个团队。例如，一家投资公司可能有一个团队的工作是从许多供应商那里获取、重新格式化并摄取金融数据（例如股市数据、公司的SEC文件等）和另类数据（例如信用卡支出、电子收据、零售客流等）。愿景当您的数据转换需求变得复杂时，您需要数据工程师在公司的数据战略中发挥核心作用，以确保您可以成本效益地构建可靠的系统。数据工程师位于数据所有者和数据消费者之间的交叉点。业务数据所有者是业务团队与数据架构的联系人，了解业务并为数据架构提供数据。数据消费者专注于从架构中提取不同数据的洞察力。在这里，通常会找到数据科学团队、数据分析团队、商业智能团队等。这些团队有时会将来自不同业务单位的数据结合起来，并生成（机器学习模型、交互式仪表板、报告等）工件。在部署方面，他们需要数据工程团队的帮助，以确保数据是一致且可信的。数据工程师有以下责任：在构建分析系统和操作系统之间的集成时，传输数据并丰富数据（如在实时用例中）。解析和转换来自业务单位和外部供应商的混乱数据，使其成为有意义且干净的数据，并具有详细的元数据。应用数据运营（DataOps），即将业务的功能知识与应用于数据生命周期的软件工程方法相结合。这包括监视和维护数据源。部署机器学习模型和其他数据科学工件，以分析或使用数据。构建复杂的数据工程流水线是昂贵的，但可以提高能力：丰富数据工程师创建了从不同来源收集数据并将其合并以创建更有价值数据集的过程。然后可以使用这些数据做出更好的决策。训练数据集机器学习模型的质量很大程度上取决于用于训练这些模型的数据。通过从多个来源引入数据并统一它们以准备用于训练机器学习模型的数据集，数据工程师可以提高数据科学团队的生产力。非结构化数据当机器学习模型需要使用非结构化数据（例如评论文本或图像）时，存在特殊的挑战。这些数据通常不遵循传统DWH将使用的严格模式。此外，它需要清除个人身份信息（例如聊天记录中的电话号码）和不适当的内容（尤其是图像），并进行转换（例如使用嵌入）。产品化还需要数据工程工作来将临时数据科学工作产品化并从中获得价值。没有数据工程，数据科学家将被困在进行实验和为特定用例制作应用的困境中，但这些应用很少被产品化或概括。实时分析应用程序，如异常检测和欺诈预防，需要立即做出响应。在这种用例中，数据消费者需要在数据即时到达时即时处理信息。他们必须以低延迟进行操作。这种实时分析需要在目标DWH之外进行转换。通常所有这些都需要定制应用程序或最先进的工具。实际上，很少有组织的工程能力卓越到可以真正称之为工程组织。许多组织属于我们称之为混合组织的范畴（见图3-2）。人物角色数据工程师开发并优化所有获取数据所需的过程，以及执行相关分析和生成报告所需的解决方案。知识数据工程角色需要深入了解数据库和编程语言，同时具备在部门间合作所需的一定业务技能。无论他们在哪个规模的组织中工作，数据工程师都需要具备一些标准的技能才能取得成功。最有价值的知识包括：数据仓库和数据湖解决方案 Cloudera Data Platform、Oracle Exadata、Amazon RedShift、Azure Synapse、Google BigQuery、Snowflake、Databricks、Hadoop生态系统等，数据工程师可以处理海量数据。数据库系统 SQL 和 NoSQL 数据库系统。他们应该知道如何在关系数据库管理系统（RDBMS）中进行信息存储和检索。ETL 工具传统工具如 Informatica 和 Ab Initio 以及现代框架如 Apache Beam、Spark 和 Kafka。编程语言 Python、Java、Scala。数据结构和算法数据结构和算法允许组织和存储数据以便轻松访问和操作，这对于数据工程师是一项必不可少的技能。自动化和脚本编写数据工程师应该能够编写脚本以自动化重复性任务，因为他们必须处理大量数据（例如 bash、PowerShell、HashiCorp Terraform、Ansible 等）。容器技术将数据项目推向生产的事实标准。在本地机器上开发的项目可以“交付”到一个暂存和生产集群（通常）而无需问题。数据流水线和机器学习模型是可复制的，并且可以在任何地方以相同的方式运行。编排平台由于需要集成执行数据工程任务的各种解决方案和工具的增多，编排工具如 Apache Airflow 已成为必不可少的。认证衡量了数据工程师的知识和熟练程度，确认个体具备必要的专业知识以为企业的数据战略做出贡献。例如 AWS Certified Data Analytics、Cloudera Certified Professional (CCP) Data Engineer、Google Professional Data Engineer 和 Microsoft Certified: Azure Data Engineer Associate。责任数据工程师负责确保不同业务部门生成和需要的数据被摄入到架构中。这项工作需要两种不同的技能：业务功能知识和数据工程/软件开发技能。这种技能组合通常被称为 DataOps（它起源于过去几十年中在软件开发领域发展起来的 DevOps 方法，但应用于数据工程实践）。数据工程师还有另一个责任。他们必须帮助部署数据使用者生成的工件。通常，数据使用者没有足够的深度技术技能和知识来独自负责其工件的部署。对于非常复杂的数据科学团队也是如此。因此，数据工程师必须掌握其他技能：机器学习和商业智能平台知识。让我们澄清一下：我们不希望数据工程师变成机器学习工程师。机器学习工程是将数据科学家开发的机器学习模型部署到实时生产系统的过程。另一方面，数据工程师构建的基础设施是供他人用于处理数据的，比如数据存储和数据传输。数据工程师需要了解机器学习，以确保提供给模型的第一层数据（输入）是正确的。在推断路径中交付数据的第一层，数据工程技能在规模、高可用性等方面确实需要发挥作用。通过负责解析和转换来自各个业务部门的混乱数据，或者实时摄取，数据工程师使数据使用者能够专注于创造价值。数据科学家和其他类型的数据使用者可以抽象出数据编码、大文件、旧系统和复杂的消息队列配置（用于流处理）的细节。将这种知识集中在一个高技能的数据工程团队中的好处是显而易见的，尽管其他团队（业务部门和使用者）也可能有自己的数据工程师，作为与其他团队进行接口的角色。最近，我们甚至看到了由业务部门成员（数据产品负责人）、数据工程师、数据科学家和其他角色组成的小组。这实际上创建了完整的团队，他们在数据流上拥有自治权，并对从传入数据到影响业务的数据驱动决策的整个过程负有全部责任。技术框架数据工程团队已经需要广泛的技能。不要让他们的工作变得更加困难，期望他们还要维护运行数据管道的基础设施。数据工程师应该专注于如何清理、转换、丰富和准备数据，而不是关注他们的解决方案可能需要多少内存或多少核心。参考架构摄取层由 Kinesis、Event Hubs 或 Pub/Sub 用于实时数据，以及 S3、Azure Data Lake 或 Cloud Storage 用于批处理数据组成（参见图 3-5、3-6 和 3-7）。它不需要任何预分配的基础设施。所有这些解决方案都可用于各种情况，因为它们可以自动扩展以满足输入工作负载的需求。一旦数据被收集，我们提出的架构遵循传统的提取、转换和加载（ETL）的三步过程。对于某些类型的文件，直接加载到 Redshift、Synapse 或 BigQuery（使用 ELT 方法）也是可行的。在转换层，我们主要推荐使用 Apache Beam 作为数据处理组件，因为它具有统一的批处理和流处理模型。Apache Beam 的运行器包括 GCP 上的 Cloud Dataflow，以及其他超大规模云提供商上的任何托管 Flink 或 Spark 实现。在此架构中，Dataflow 的替代方案是使用基于 Spark 的解决方案，例如 Amazon EMR、Databricks、Azure HDInsight 或 Google Dataproc。然而，这些解决方案不是无服务器的，而且运行空闲的 Spark 集群是一项主要的成本。话虽如此，也有作为 AWS SageMaker/Glue 的一部分以及作为 GCP Serverless Spark 服务提供的无服务器 Spark 替代方案。主要用例是那些已经在 Spark 或 Hadoop 中拥有大量代码的团队。这些 Spark 解决方案使得可以直接将数据管道迁移到云端，而无需审核所有这些管道。数据处理的另一种选择是使用无代码环境来创建数据管道，使用拖放界面，例如由 AWS Glue、Azure Data Factory 或 GCP Data Fusion 提供的界面。传统的 ETL 工具，如 Informatica、Ab Initio 和 Talend，也可以在云中以无服务器模式运行，并在底层使用 Kubernetes 集群。其中一些工具使用 Hadoop/Spark 解决方案或类似的专有计算引擎，在这种情况下，我们之前提到的所有内容也适用于 ETL 工具的情况。如果您的团队更喜欢在不编写任何代码的情况下创建数据管道，则图形化 ETL 工具是正确的选择。参考架构的优势图3-5、3-6和3-7中呈现的参考架构基于对无服务器NoOps技术和流水线的偏好。通过使用无服务器技术，您可以将维护负担从数据工程团队中剔除，并为执行复杂和/或大型作业提供必要的灵活性和可伸缩性。例如，在零售商在黑色星期五期间规划交通高峰时，可伸缩性是至关重要的。使用无服务器解决方案使零售商能够查看他们在一天中的表现。他们不再需要担心在白天生成的大量数据的处理所需资源。参考架构为数据工程团队提供了编写用于数据流水线的完全定制代码的可能性。这可能是因为解析要求可能很复杂，而没有现成的解决方案可行。在流处理中，团队可能希望以低延迟实现复杂的业务逻辑。然而，团队应尽力通过创建可重用的库和使用诸如Dataflow模板等技术来重用代码。这将两者的优势结合在一起（重用和重写），同时节省宝贵的时间，可以用于高影响代码而不是常见的I/O任务。所呈现的参考架构还具有另一个重要特性：将现有的批处理流水线转换为流式处理的可能性。数据科学驱动型的组织以数据科学为驱动的组织是一种通过充分利用可用数据创造可持续竞争优势的实体。为此，该组织依赖自动化算法，通常（但并非总是！）采用机器学习（ML）。与以分析为驱动的组织依赖一次性报告和分析不同，以科学为驱动的组织试图以自动化方式做出决策。例如，一个以数据分析为驱动的银行可能会让数据分析师评估每个商业贷款机会，建立投资案例，并由高管签署。另一方面，以数据科学为驱动的金融科技公司可能会构建一个贷款批准系统，使用某种自动化算法对大多数贷款做出决策。愿景以科学为驱动的组织是一种从数据中提取最大价值，并利用机器学习和分析获得可持续竞争优势的实体。在构建这样一个数据科学团队时，应遵循一些原则：适应性：平台必须足够灵活，以适应所有类型的用户。例如，一些数据科学家/分析师更倾向于创建自己的模型，而其他人可能更喜欢使用无代码解决方案或在SQL中进行分析。这还包括提供各种ML和数据科学工具，如TensorFlow、R、PyTorch、Beam或Spark。该平台还应足够开放，能够在多云和本地环境中运行，同时在可能的情况下支持开源技术，以避免锁定效应。最后，资源不应成为瓶颈，因为平台必须能够迅速扩展以满足组织的需求。标准化：通过使平台更容易共享代码和技术工件，标准化提高了平台的效率。这提高了团队之间的沟通，并提升了他们的性能和创造力。标准化还使数据科学和ML团队能够以模块化的方式工作，这对于高效开发至关重要。标准化可以通过使用标准连接器连接到源/目标系统来实现。这避免了在ML和数据科学工作流中常见的“技术债务”。责任：数据科学和ML用例通常涉及诸如欺诈检测、医学成像或风险计算等敏感主题。因此，数据科学和ML平台帮助使这些工作流程尽可能透明、可解释和安全至关重要。透明度与运营卓越性相关。在数据科学和ML工作流的所有阶段收集和监控元数据是至关重要的，以创建一个“纸迹”，让您能够提出诸如：用于训练模型的哪些数据？使用了哪些超参数？模型在生产中的表现如何？在最近的时期内是否发生任何形式的数据漂移或模型偏移？此外，以科学为驱动的组织必须深入了解其模型。虽然对于传统的统计方法来说这不是问题，但是ML模型（如深度神经网络）更加不透明。平台必须提供简单的工具来分析这些模型，以便自信地使用它们。最后，成熟的数据科学平台必须提供所有的安全措施，以在精细的层次上保护数据和工件的使用情况。业务影响：根据麦肯锡的说法，许多数据科学项目未能超越试点或概念验证阶段。因此，更重要的是预期或测量新举措的业务影响并选择回报率，而不是追逐最新的炫酷解决方案。因此，要识别何时购买、构建或定制ML模型，并将它们连接到单一集成堆栈是至关重要的。例如，通过调用API使用现成的解决方案而不是经过数月开发后构建模型，有助于实现更高的回报率并展示更大的价值。激活：将模型嵌入到最终用户使用的工具中的操作化模型的能力对于实现向广泛用户提供服务的规模至关重要。将小批量数据发送到服务，并在响应中返回预测的能力，使具有较少数据科学专业知识的开发人员能够使用模型。此外，促使灵活API的边缘推断和自动化流程的无缝部署和监控也很重要。这使您能够在私有和公共云基础架构、本地数据中心和边缘设备之间分发AI。在构建以科学为驱动的组织时，会面临一些社会技术挑战。通常组织的基础设施不够灵活，无法适应快速变化的技术环境。平台还需要提供足够的标准化，以促进团队之间的沟通，并建立技术“通用语言”。这对于允许团队之间的模块化工作流程并建立运营卓越性至关重要。此外，安全地监控复杂的数据科学和ML工作流通常过于不透明。以科学为驱动的组织应建立在技术开放度极高的平台上。因此，使广泛的人物能够在灵活且无服务器的方式中提供技术资源至关重要。购买还是构建解决方案是实现组织回报率的关键驱动因素之一，这将定义任何AI解决方案将产生的业务影响。同时，使大量用户能够激活更多的用例。最后，平台需要提供工具和资源，使数据科学和ML工作流具有开放性、解释性和安全性，以提供最大形式的责任。人物角色以数据科学为驱动的组织中的团队由拥有不同技能和经验的各种人员组成。然而，大多数团队包括四个核心角色：数据工程师、ML工程师、数据科学家和分析师。值得注意的是，这些角色并不总是清晰定义的，可能在一定程度上存在重叠。有效的组织结构将允许团队成员之间的协作，并充分利用所有团队成员的技能：数据工程师：数据工程师负责开发数据管道，确保数据符合所有质量标准。这包括清理、合并和丰富来自多个来源的数据，将其转化为可用于下游分析的信息。ML工程师： ML工程师创建和监督完整的ML模型。虽然ML工程师是这四种角色中最稀缺的，但一旦组织打算在生产中运行关键业务工作流程时，它们就变得至关重要。数据科学家：数据科学家是数据和ML工程师之间的桥梁。与业务利益相关者一起，他们将业务需求转化为可测试的假设，确保从ML工作负载中获得价值，并创建报告以展示数据的价值。数据分析师：数据分析师提供业务洞察，并确保实施业务正在寻求的数据驱动解决方案。他们回答临时问题，并提供定期报告，分析历史和最新数据。关于公司是否应该建立集中式还是分散式的数据科学团队存在各种观点。还有一些混合模型，例如将数据科学家嵌入到集中式组织中的联邦组织。因此，更重要的是专注于如何使用前述原则来解决这些社会技术挑战。技术框架我们强烈建议在ML管道基础设施方面采用您的公有云提供商的标准化解决方案（即在Google Cloud上的Vertex AI，AWS上的SageMaker，或Azure上的Azure Machine Learning），而不是拼凑一些一次性的培训和部署解决方案。参考架构（参见图3-8）包括一个ML管道，用于自动化实验和训练。训练好的模型在一个管道中部署，其中通过容器化重复执行许多训练步骤。在特征需要按需计算成本过高或必须在服务器端注入时，请使用特征存储。将模型部署到端点。总结在本章中，您已经了解了设计数据团队以确保其在您所在的组织中取得成功的不同方式。最佳方法是找到一种合适的技能和经验组合，以补充您现有的团队并帮助您实现业务目标。主要要点如下：云技术有助于获取新的工作方式。任何给定角色的潜在面积已经扩大。数据工作者现在能够更高效地利用他们拥有的数据，做更多的事情。无论您的组织主要由数据分析师、数据工程师还是数据科学家组成，都可以建立数据文化。然而，通向数据文化的路径以及每种组织类型所需的技术是不同的。确定哪种组织分类对您来说是正确的，然后开始建立支持其愿景、相关技能和技术框架的人物角色。数据平台的愿景也因情况而异。在以分析为驱动的组织中，它应该使对数据的访问变得更加民主。在以工程为驱动的组织中，重点是以经济高效的方式确保可靠性。在以科学为驱动的组织中，它应该通过业务影响力提供竞争优势。以以分析为驱动的组织为例，应专注于SQL技能；以以工程为驱动的组织为例，应专注于ETL和DataOps能力；以以科学为驱动的组织为例，应专注于MLOps和AI能力。以以分析为驱动的组织为例，推荐的架构是基于数据仓库（或在数据仓库基础上建立的数据湖）；以以工程为驱动的组织为例，推荐的架构是基于数据湖（或在数据湖基础上建立的数据湖）；以以科学为驱动的组织为例，推荐的架构是与数据湖相连接的ML管道架构。这将在第5章至第7章中介绍。

浏览量2035

攻城狮无远

第六章：使用企业数据仓库进行创新

第3章中，您了解到在云数据平台的核心组件中选择数据湖还是数据仓库取决于您的组织是以工程/科学为先（选择数据湖）还是以分析为先（选择数据仓库）。在第5章中，我们专注于数据湖作为数据平台设计的中心元素的概念。在本章中，您将学习如何使用现代数据仓库作为中心元素来解决成本、民主化、灵活性和治理等相同的问题。我们将首先快速回顾构建数据平台时要解决的问题，并讨论使云数据仓库成为一个吸引人的解决方案的技术趋势。然后，我们将深入探讨现代数据仓库架构的特点，以及如何有效地为数据分析师和数据科学家提供支持。现代数据平台每当您开始进行大型技术项目时，首先应该问自己您想要实现什么业务目标，您当前的技术挑战是什么，以及您想要利用哪些技术趋势。在本节中，我们将重点帮助您了解在构建现代数据平台时如何回答这些问题，以及企业数据仓库方法如何引导您的数据平台设计焦点。许多这些概念在先前的章节中已经涉及到，但将它们在这里重新构架将有助于您将现代数据仓库的设计与架构解决的问题联系起来。组织目标在我们的客户访谈中，CTOs 反复提到以下组织目标的重要性：无隔阂数据必须在整个企业范围内得以激活，因为业务的一个部分需要访问其他部门创建的数据。例如，确定明年产品设计的产品经理可能需要访问由零售运营团队创建和管理的交易数据。民主化数据平台必须支持领域专家和其他非技术用户，他们可以在不经过技术中介的情况下访问数据，但应能够依赖数据的质量和一致性。可发现性数据平台必须支持数据工程师和其他技术用户，他们需要在不同处理阶段访问数据。例如，如果我们有一个数据集，其中已经调整了原始的传入交易数据，数据科学家需要能够获取已调整的数据集。如果他们无法发现它，他们将重新构建一个调整例程。因此，应该能够发现所有这些“中间”数据集，以便在整个组织中不重复处理步骤。管理数据集应该由了解它们的团队控制。例如，财务数据应由财务部门控制，而不是由 IT 部门控制。单一来源数据应该在原地读取。最小化数据的复制和提取。安全性和合规性 IT 应该作为数据的经纪人，确保只有具有适当权限的人可以访问它。必须实施法规要求的所有合规性检查（例如 GDPR、CCPA、格拉姆-利奇-布莱利法案）。确保实施将数据分类为敏感/受限数据与开放或行业特定数据的解决方案。易用性使报告更容易，因为有数百名分析师正在创建支持各种功能的报告。数据科学使数据科学团队更具生产力，因为这些角色往往既昂贵又难以招聘。灵活性使决策者更快地获得见解。虽然这些目标在组织之间的相对顺序有所不同，但所有这些目标在我们接触的每个组织中以某种方式出现。因此，现代数据平台应使CTOs能够实现这些目标。技术挑战在实现这些目标时，CTO们使用组织内已部署的技术时面临哪些障碍呢？CTO们通常提到以下技术挑战：规模和规模他们的组织收集的数据量随着时间的推移急剧增加，并预计将继续增加。他们目前的系统无法扩展，并无法保持在业务的速度和成本限制内，从而导致妥协，例如对传入数据进行抽样或严重优先考虑新数据项目。复杂的数据和用例越来越多的收集到的数据是非结构化数据，如图像、视频和自然语言文本。他们目前用于管理结构化和非结构化数据的系统没有交集。然而，需要在推荐等用例中将结构化数据（例如产品目录详情）和非结构化数据（例如目录图像、用户评论）一起使用。集成随着时间的推移，我们看到技术领域涌现了许多新的数据源和数据接收端，组织希望并应该利用这些资源。例如，他们希望在Salesforce中管理销售信息，在Adobe中管理广告活动，在Google Analytics中管理网页流量。有必要同时分析和决策所有这些数据。实时性许多新数据是实时收集的，能够在数据到达时处理并做出决策具有竞争优势。然而，组织没有一个无缝支持流式处理的数据平台。这当然只是传统大数据挑战的一个更具细化的版本：数据的规模、多样性（数据和系统）、速度。技术趋势和工具为实现组织的业务和技术目标，云架构师可以利用前几章描述的趋势和工具。为了方便起见，我们在这里对它们进行了总结：计算和存储的分离公共云提供商允许您将数据存储在Blob存储中，并从临时计算资源中访问它。这些计算资源包括Google BigQuery、AWS Redshift、Snowflake、Amazon EMR、Google Dataproc、Cloud Dataflow或Databricks等自定义构建或调整的软件，它们利用了计算与数据处理的分离，并在多个工作节点上分布数据处理。它们涵盖结构化和非结构化数据。多租户云计算资源被设计为允许多个租户。因此，不需要为组织中的每个部门创建独立的集群或存储阵列。因此，两个不同的部门可以将其数据存储在单个DWH中，并从它们各自支付的计算资源中访问彼此的数据，每个团队都可以在共享的通用数据集上启动自己的分析。同样，组织可以使用其计算资源访问来自多个组织的数据并对连接的数据集进行分析。与传统的Hadoop集群不同，不必在与数据共同运行计算工作负载。身份验证和授权的分离云IAM解决方案可以确保中央IT团队在数据所有者控制访问的同时确保身份的安全性。事实上，通过提供对组的访问，可以允许访问组织来管理成员资格，而数据所有者仅管理提供何种访问的业务逻辑。分析中心无服务器DWH（以及正如我们在上一章中看到的数据湖）使架构师能够打破组织边界之外的数据孤立。虽然数据所有者支付存储费用，但数据使用者支付查询费用。此外，虽然数据所有者决定了哪些组具有访问权限，但组的成员资格可以由数据使用者管理。因此，合作伙伴和供应商可以共享数据，而不必担心查询成本或组成员资格。跨云语义层诸如Informatica或Looker之类的工具可以创建一个跨超大规模云（例如AWS、GCP或Azure）、多云数据平台（例如Snowflake或Databricks）和本地环境的语义层。语义层可以实时重写查询，以提供一致和连贯的数据字典。（请注意，语义层将在本章后面更详细地讨论。）一致的管理界面数据fabric解决方案在公共云上提供一致的管理体验，无论数据存储在DWH中还是以Parquet文件的数据湖格式存储在Blob存储中。跨云控制面板诸如BigQuery Omni之类的工具提供了一个一致的控制面板和查询层，无论您的组织使用哪个超大规模云（AWS、GCP或Azure）来存储数据。如果关心确保可以使用相同的工具，而不管特定数据集存储在哪个超大规模云中，这些工具是有用的。这是与GCP控制面板的增加依赖性的权衡。多云平台 Snowflake、Confluent和Databricks提供了在任何超大规模云上运行相同软件的能力。然而，与前一个项目不同，不同云上的运行时仍然是不同的。如果关心确保可以从一个超大规模云转移到另一个超大规模云，这些工具是有用的。这是对单一来源软件供应商增加依赖性的权衡。数据湖和DWH的融合联邦和外部查询使得可以在DWH上运行Spark作业以及在数据湖上运行SQL查询。我们将在下一章对这个主题进行扩展。内建ML 像AWS Redshift和Google BigQuery这样的企业DWH提供了在不移动数据出DWH的情况下进行ML训练和运行ML的能力。Spark具有ML库（Spark MLlib），并且ML框架（如TensorFlow）在Hadoop系统中得到支持。因此，ML可以在数据平台上进行，而无需提取数据到单独的ML平台。流式摄取诸如Kafka、AWS Kinesis、Azure Event Hub和Google Cloud Pub/Sub之类的工具支持实时将数据着陆到超大规模云的数据平台。诸如AWS Lambda、Azure Functions、Google Cloud Run和Google Cloud Dataflow之类的工具还支持在数据到达时对数据进行转换，以进行质量控制、聚合或语义上的纠正，然后将数据写出。流式分析 DWH支持流式SQL，因此只要数据实时着陆在DWH中，查询就会反映最新的数据。变更数据捕获诸如Qlik、AWS Database Migration Service和Google Datastream之类的工具提供了捕获操作关系数据库（例如在AWS关系数据库服务[RDS]上运行的Postgres或在Google Cloud SQL上运行的MySQL）更改并实时流式传输到DWH的能力。嵌入式分析可以使用Power BI等现代可视化工具将分析嵌入到最终用户使用的工具（手机或网站）中，而无需让最终用户操作仪表板。枢纽和辐条体系结构提供了实现CTO期望目标并利用上述技术能力的经过验证的方法。枢纽和辐条架构在设计围绕数据仓库的现代云数据平台时，枢纽和辐条是理想的架构。在这种架构中，数据仓库充当一个集线器，收集所有用于业务分析的数据。辐条是自定义的应用程序、仪表板、ML 模型、推荐系统等，通过标准接口（即 API）与数据仓库进行交互。工具如 Sigma Computing、SourceTable 和 Connected Sheets 甚至提供了一种电子表格界面，模拟了在数据仓库顶部运行的 Excel。所有这些辐条都可以直接从数据仓库访问数据，而无需复制。我们建议这种方法适用于没有遗留技术需要适应的初创公司，希望进行全面改建以实现全面转型的组织，甚至大型企业，因为它具有可伸缩性、灵活性和弹性。它是可伸缩的，因为新的（现代的）数据仓库可以轻松集成新的数据源和用例到现有的基础设施，而无需重新配置整个系统。它是灵活的，因为您可以定制整体架构以满足企业的特定需求（例如，启用流处理）。而且它是弹性的，因为它可以承受比其他架构更多的故障。现代的云原生企业数据仓库形成了枢纽和辐条架构的中枢，而辐条是数据提供者和数据消费者，如图 6-1 所示。请在阅读以下段落时参考图中的组件。面向分析的数据和 ML 能力涉及将原始数据加载到数据仓库（企业数据仓库）中，然后根据需要进行转换以支持各种需求。由于计算和存储的分离，数据仅有一个唯一的副本。不同的计算工作负载，如查询（查询 API）、报告/交互式仪表板（商业和智能报告工具）和 ML（数据科学和 ML 工具），都可以在数据仓库中的这些数据上运行。由于可以利用 SQL 进行所有转换，因此可以使用视图和物化视图进行详细说明，从而无需进行 ETL 流水线。这些视图可以调用外部函数，从而允许使用 ML API 和模型对数据进行增强。在某些情况下，甚至可以仅使用 SQL 语法训练 ML 模型，并且可以通过简单的 SQL 命令调度复杂的批处理流水线。现代数据仓库甚至支持直接摄取（加载 API）流式数据（流式 API），因此只有在需要对数据执行低延迟、窗口聚合分析时，才必须利用流水线。始终记住评估解决方案的最终成本并将其与您将获得的收益进行比较。有时一种策略（批处理）可能比另一种策略（流处理）更好，反之亦然。枢纽和辐条架构的关键思想是尽可能高效地将所有数据引入企业数据仓库。当数据来自 SaaS 软件（如 Salesforce）时，可以通过计划的自动导出机制加载数据。而当数据来自操作性数据库（如 Postgres）时，可以通过 CDC 工具实时接收数据。同时，实时数据源预计在发生新事件时将新数据发布到数据仓库。某些数据源是联合的（联合数据集），这意味着您将动态查询并将其视为数据仓库的一部分。现在，所有企业数据都在逻辑上成为数据仓库的一部分，数据科学和报告工具可以对数据进行操作（存储 API/查询 API）。如果您没有需要迁移的现有 ETL 流水线或需要支持的现有终端用户工具选择，那么枢纽和辐条是简单、强大、快速和经济有效的。Google Cloud 上这种架构的一个示例呈现在图 6-2 中。其他超大规模云提供了更多选项（例如 AWS 上的 Athena、Redshift、Snowflake）；我们将在第 7 章中介绍这些变体。在其完全自动化的形式中，枢纽和辐条对于没有强大工程技能的企业以及进行影子 IT 的小部门来说是一个很好的选择，因为在数据摄取方面几乎没有代码需要维护。此外，您只需了解 SQL 就可以完成数据科学和报告活动。值得注意的是，支持面向分析的数据仓库的这些功能都是最近的发展。计算和存储的分离随着公共云的出现而产生：此前，大数据范式由 MapReduce 主导，该范式需要将数据分片到本地存储。分析工作负载需要构建业务特定的数据集市。由于性能限制，需要在将数据加载到这些数据集市之前进行转换（即 ETL）。存储过程是数据仓库，而不是外部函数，它们本身依赖于无状态微服务的自动缩放的发展。ML 部署需要捆绑和分发库，而不是无状态的 ML API。ML 工作流基于独立的训练代码，而不是由容器化组件组成的 ML 流水线。流处理涉及不同的代码库，而不是统一的批处理和流处理。现在您已经了解了枢纽和辐条架构的基本概念，让我们深入探讨其主要组成部分：摄取、商业智能、转换和 ML。数据摄取枢纽与辐条架构中的一个辐条（在图 6-1 中围绕企业数据仓库的方框）对应于将数据（或进行摄取）传送到数据仓库的各种方式。有三种摄取机制：预建连接器、实时数据捕获和联合查询。我们将在本节分别讨论每种机制。预建连接器将数据导入数据仓库可以变得非常简单，尤其是在利用流行的SaaS平台时，因为它们提供了自动导入数据的连接器，只需点击几下即可。每个云原生数据仓库（如Google BigQuery、AWS Redshift、Snowflake、Azure Synapse等）通常都支持SaaS软件，例如Salesforce、Google Marketing Platform和Marketo。如果您使用的软件不受您选择的数据仓库支持，可以查看软件供应商是否提供到您选择的数据仓库的连接器，例如Firebase（一个移动应用平台）可以直接将移动应用的崩溃报告导出到BigQuery进行分析（“crashlytics”）。您可以设置这些SaaS服务将数据推送到常见的数据仓库（例如Salesforce将自动将数据推送到Snowflake），或者使用BigQuery数据传输服务等服务将这些数据集导入数据仓库。这通常被称为Zero ETL——正如无服务器并不意味着没有服务器，只是服务器由其他人管理一样，Zero ETL意味着ETL过程由您的SaaS供应商或您的数据仓库供应商管理。第三个选择是使用提供连接器的第三方供应商，例如Fivetran。他们的预建连接器提供了一种轻松集成来自营销、产品、销售、财务等应用程序的能力（见图6-3）。通过云提供商的传输服务、支持云连接器的软件供应商以及第三方连接器供应商，您可以购买（而不是构建）定期从SaaS系统导出数据并将其加载到企业数据仓库的能力。实时数据如果您希望您的数据仓库能够实时反映变化，您需要利用一组较小的工具，称为CDC工具。操作性数据库（Oracle、MySQL、Postgres）通常是其中的一部分，企业资源规划（ERP）工具如SAP也是支持的。确保这些工具使用DWH的Streaming API以近实时的方式加载数据。在Google Cloud上，Datastream是推荐的CDC工具，在AWS上则是Database Migration Service（DMS）。如果您有实时数据源，例如点击流数据或来自物联网设备的数据，请寻找一种能够使用DWH的Streaming API将事件实时发布的能力。由于Streaming API可以通过HTTPS访问，所以您只需要一种在事件发生时调用HTTPS服务的方式。如果您的物联网设备提供商不支持推送通知，那么请寻找一种将事件发布到消息队列（例如使用消息队列遥测传输或MQTT），并使用流处理器（在GCP上使用Dataflow，在AWS上使用Kinesis）将这些事件写入DWH的方法（参见图6-4）。联邦数据你甚至可能无需将数据加载到数据仓库中即可使用它。现代云数据仓库能够在标准格式（如Avro、CSV、Parquet和JSONL（逐行JavaScript对象表示法））的数据集上运行查询，而无需将数据移到数据仓库中。这被称为联邦查询，通常要求数据格式是自描述的，或者模式被预先指定。例如，让Google BigQuery对Avro文件执行联邦查询包括以下三个步骤：使用bq mkdef --source_format=AVRO gs://filename创建一个表定义文件，并在必要时编辑默认值。例如，您可能会更改Avro中的整数字段，使其被视为实数。使用生成的表定义文件使用bq mk --external_table_definition mydataset.mytablename创建一个BigQuery数据集。像正常的SQL一样查询数据集。请注意，数据仍然以Avro格式保存在Cloud Storage中。这就是这被称为联邦查询的原因。如果数据格式不是自描述的，则mkdef命令允许您指定模式。甚至可以将这些步骤结合起来，采用按需读取的模式，以便模式定义仅在查询的持续时间内有效。例如，要使Azure Synapse查询Azure数据湖中的Parquet文件，您可以执行以下查询：SELECT ... FROM OPENROWSET( BULK 'https://....dfs.core.windows.net/mydata/*.parquet', FORMAT='PARQUET' ) AS Tbl在联邦查询的情况下，查询引擎是数据仓库。还可以使用外部查询引擎（如PostgreSQL关系数据库）执行查询。此类查询称为外部查询（见图6-5）。例如，要让Amazon Redshift查询Postgres数据库，请按照以下三个步骤操作：确保您的RDS PostgreSQL实例可以从Amazon Redshift集群接受连接。为此，您需要设置物理网络，并确保Redshift集群被分配了在PostgreSQL实例中授权的IAM角色。在Redshift中使用CREATE EXTERNAL SCHEMA FROM POSTGRES创建一个外部模式，传入数据库、模式、主机、IAM和密码。像正常一样查询模式。在所有这些情况中，关键要注意的是数据仍然保持在原地，并且从那里进行查询，而不是加载到数据仓库中。由于当数据保持原地时（无法进行分区、聚类等），进行联邦查询和外部查询的优化机会更有限，因此它们往往比本地查询慢一些。鉴于联邦查询和外部查询较慢，为什么要使用它们？为什么不简单地将数据加载到数据仓库中并将数据仓库视为真实数据的来源？有一些情况下，避免移动数据可能是有利的：在某些情况下，数据仓库内的存储费用可能高于其外部存储。对于很少查询的数据，将数据保留在联邦数据源中可能更具成本效益。当需要最佳性能时，请使用数据仓库解决方案提供的本机存储系统。如果相反，灵活性更为重要，则尝试利用联邦数据源。如果关系数据库中的数据经常更新，将关系数据库视为黄金来源可能是有利的。从操作性数据库到数据仓库进行CDC可能会引入不可接受的延迟。数据可能是由工作负载（如Spark）创建或需要的。因此，可能需要维护Parquet文件。使用联邦/外部查询限制了数据的移动。当您已经拥有数据湖时，这是最常见的用例。数据可能属于与查询它的组织不同的组织。联邦查询很好地解决了这个问题。但是，假设您正在使用完全无服务器的数据仓库，比如Google BigQuery，它不是基于集群的。在这种情况下，即使是对本机存储，也可以直接提供对合作伙伴和供应商的访问。最后一种情况是我们建议使用完全无服务器的数据仓库的原因之一，它不要求您将数据移动到集群、创建数据提取或提供特定应用程序（而不是特定用户）访问数据。现在您对数据摄入的可用选项有了更好的了解，让我们深入了解如何通过查看我们可以在BI方面开发的各种功能来使数据“说话”。商业智能数据分析师需要能够迅速从数据中获取洞见。他们用于此目的的工具需要是自助的，支持即席分析，并对使用的数据提供一定程度的信任（在中心枢轴结构中为业务和智能报告工具）。它需要提供几种功能：SQL分析、数据可视化、嵌入式分析和语义层，我们将在本节中详细介绍这些功能。SQL分析正如前面的部分所强调的，SQL是查询DWH时的主要语言。在组织内，SQL是数据分析师和业务分析师的通用语言。这些分析师通常会在DWH上执行即席查询，以帮助回答出现的问题（例如，“在罗马尼亚的最后一次热浪中卖出了多少升冰淇淋？”）。但在许多情况下，这些问题变得常规化，用户会利用诸如Power BI或Looker之类的即席工具将其操作化为报告的形式。这些报告工具，通常称为BI工具，旨在通过连接到DWH（图6-1中的中心枢轴结构中的业务和智能报告工具）提供对组织整个数据资产的视图，以便分析师能够做出基于数据的决策。考虑到不太实际指望分析师在需要数据的时候收集、清理和加载某个数据片段，数据需要事先存在。这就是为什么带有中央企业DWH的中心枢轴模型如此受欢迎的原因。然而，您应确保BI工具已经适应云环境，并能够处理大量快速到达的数据。早期的BI工具要求将数据提取到在线分析处理（OLAP）立方体中以提高性能（见图6-6）。这根本行不通——它会导致过时的、导出的数据大量增加，或者需要支持每种可能用例的单独OLAP立方体的巨大维护负担。您希望BI工具能够透明地将查询委托到DWH并检索结果。这是充分利用DWH规模和其流式接口的及时性的最佳方法。企业DWH中的SQL引擎已升级到一定水平，能够处理多个并行查询或在内存中维护大量数据，这使得组织能够摆脱OLAP方法。可视化您的SQL查询将生成表格。然而，仅仅从原始表格中获得理解和见解可能是困难的。相反，您通常会将结果绘制成图形、图表或地图。可视化SQL查询结果通常是引发洞察力的原因。在探索性数据分析中，可视化是临时的。然而，可视化必须帮助使用常见的图表元素回答常见问题。这是Tableau、Looker、Power BI和Looker Studio等仪表板工具的职责。优秀的仪表板考虑受众，并讲述故事。它们既可以作为当前状态的高层概述，也可以作为进一步交互式分析的起点。它们使用适当形式的图表显示上下文相关的重要指标。嵌入式分析通过传统的仪表板工具进行可视化足以与少数内部人员共享分析结果。这些用户会欣赏仪表板提供的丰富控件和互动性。但如果您是手工艺市场或电信运营商，并且希望每位艺术家或每个摊位都能够查看其自己商店性能的近实时图表呢？当您为数千用户提供定制报告时，您不希望向最终用户提供一个功能丰富的仪表板界面，因为这可能难以支持和维护。相反，您需要一个轻量级的图形可视层，可以嵌入到用户已经在使用的工具中。通常将分析嵌入到艺术家用于上架商品或摊位运营用于订购新商品的网站或移动应用程序中。为商店性能提供一致的实时指标可以显著提高艺术家和运营商在您的市场上赚钱的能力。还可以更好地连接工作流程，例如，使用分析，卖家可能能够轻松调整经常缺货商品的价格。提供诸如预测产品需求之类的机器学习功能还可能为市场带来新的收入来源。语义层自助分析和一致性之间存在紧张关系。赋予公司内每位业务分析师快速创建仪表板的能力是重要的，而不必等待中央IT团队。同时，保持仪表板在计算方面的一致性至关重要（例如，运输成本在各个仪表板中必须以相同的方式计算）。尽管业务分析师能够自己构建复杂的仪表板很重要，但他们尽可能地重复使用现有的可视化也同样重要。提供一致性和重复使用的传统方法是在IT内部集中计算和基础能力。然而，在数据驱动的环境中，这种集中式的以IT为中心的解决方案通常过于脆弱且速度太慢，无法满足业务用户的需求。现代BI工具如Looker或MicroStrategy提供了一个语义层（参见第2章）来解决这种紧张关系。语义层是一种额外的层，允许您通过常用的业务术语自主访问数据；它通过表创建者采用的术语与业务用户采用的名称之间的解耦来工作。LookML是Looker称之为语义模型层的一种基于SQL的数据语言（见示例6-1）。它为数据管理者提供了创建可重复使用的维度或度量，业务分析师可以重复使用和扩展的能力。这些定义在数据字典中提供，方便进行发现和管理。dimension: overall_health_score { view_label: "Daily Account Health Scores" description: "Weighted average of Usage, User, Support and CSAT Scores" Type: number Sql: (${usage_score}*2+${user_score}*2+${support_score}+${csat_score})/6 ;; Value_format_name: decimal_1 }这些语义层本身就充当了BI数据源。例如，Tableau可以连接到Looker的语义层，而不是直接连接到DWH。尽管业务用户通常不会直接看到或与类似LookML的工具进行交互，但他们可以构建使用定义的维度和度量的仪表板。这有助于促进重复使用，使每个分析师都无需为他们使用的每个维度或度量从基本表列中定义。集中定义度量还可以减少人为错误的可能性，并提供可以更新定义的单一点。在文本文件中存在这样一个集中的定义允许轻松进行版本控制。您已经了解了如何通过BI工具的帮助深入挖掘数据，并通过语义层帮助业务用户自主管理数据。有时，这种方法还不足以满足需求，您需要在开始将数据摄取到DWH之前对数据进行准备。在接下来的部分，我们将重点关注这个主题。转换假设您将来自ERP系统的原始数据摄取到DWH。如果ERP是SAP，列名很可能是德语的，并反映了应用程序状态，而不是我们认为有用于持久化的数据。我们不希望强迫所有用户每次需要数据时都必须将数据转换为可用形式。那么转换应该在哪里进行呢？一种选择是在语义层中定义列的转换方式，该语义层是您BI工具的一部分，正如前一节所讨论的那样。但是，这将定义限制为维度和度量，而从非BI工具访问这些定义将会很困难。更好的方法是在SQL中定义转换并创建视图、表或材料化视图。在本节中，我们将查看在DWH内处理转换的常见选项。这是“中心辐射”架构的另一个优势：当在DWH中实施数据转换时，结果立即对所有需要它们的用例可用。第三种方法是利用超大规模云提供商上可用的应用程序开发平台。使用事件机制（Eventarc、EventBridge、Event Grid）在创建新表分区时启动一个无服务器函数（Lambda、Cloud Functions）。然后，该函数可以通过调用其API将转换后的数据“推送”到后端系统，从而启动业务操作（例如发货通知）。这被称为反向ETL，因为数据流的方向是远离DWH。使用视图的ELT与ETL不同，可以将数据按原样加载到DWH中，并在通过视图读取时即时对其进行转换（见示例6-2）。由于视图在将数据加载到DWH后即时进行转换（在加载之前不进行转换），因此这通常被称为提取-加载-转换（ELT），与典型的ETL工作流形成对比。CREATE VIEW view1 AS SELECT fis.CustomerKey, fis.ProductKey, fis.OrderDateKey, fis.SalesTerritoryKey, dst.SalesTerritoryRegion FROM FactInternetSales AS fis LEFT OUTER JOIN DimSalesTerritory AS dst ON (fis.SalesTerritoryKey=dst.SalesTerritoryKey); 与查询原始表不同，用户查询视图。创建视图的SQL可以选择特定列，对列应用掩码等操作，并联接多个表。因此，ELT为业务用户提供了对原始数据的一致、受控的视图。因为最终查询在进一步聚合或选择之前运行视图查询，所以所有查询都反映了基于DWH中存在的任何数据的最新信息。然而，就计算资源、时间和/或金钱而言，视图可能会变得相当昂贵。例如，考虑示例6-2中显示的连接销售订单表和销售领域的视图。在此视图中，正在查询业务的整个历史期间所有领域的所有销售订单。即使查询视图的分析师只关注特定年份或地区（在这种情况下，过滤掉不相关的数据然后执行联接是有意义的），这也是如此。预定查询如果表的更新频率较低，定期将数据提取到表中可能更为高效。例如，在Google BigQuery中，如示例6-3中所述，我们指定目标表、查询运行频率和查询本身。bq query ... --destination_table=Orders_elt.lifetime_value \ --schedule='every 24 hours' \ --replace=true \ 'SELECT customer_id, COUNT(*) AS num_purchases, SUM(total_amount) AS lifetime_value FROM Orders.all_orders GROUP BY customer_id'在示例中，原始表每24小时只被查询一次。虽然与目标表相关的存储成本会增加，但存储成本通常比计算成本便宜几个数量级。因此，创建目标表的成本是相当可控的。定期查询的主要优势在于分析师查询的是目标表而不是原始数据。因此，分析师的查询相对较便宜。定期查询的缺点是返回给分析师的结果可能最多可以延迟24小时。通过更频繁地运行定期查询，可以减少查询的过时程度。当然，定期查询的频率越高，成本优势就越容易消失。定期查询的另一个缺点是，如果最终的目标表从未被查询，它们可能会是一种浪费。物化视图很明显，平衡过时数据和成本的最有效方法是在首次请求视图时将原始数据提取到目标表中。随后的查询可以很快，因为它们可以从目标表中检索数据而无需进行任何提取。与此同时，系统需要监视基础表，并在原始表更改时重新提取数据。您还可以通过使用新的原始数据行更新目标表而不是重新查询整个表来使系统更加高效。虽然您可以构建一个数据工程流水线来执行所有这些操作，但现代云DWH在开箱即用时就支持完全托管的物化视图。在这些系统中创建物化视图类似于创建实时视图（见示例 6-4），您可以像查询任何其他视图一样查询它。DWH会确保查询返回最新的数据。DWH供应商会对管理物化视图收取一些费用。create materialized view vulnerable_pipes (segment_id, installation_year, rated_pressure) as select segment_id, installation_year, rated_pressure from pipeline_segments where material = "cast iron" and installation_year < "1980"::date;然而，请注意一些DWH（例如Amazon Redshift，在撰写本文时）不会自动为您管理物化视图；您需要设置一个计划或触发器来刷新物化视图。从这个意义上说，他们所谓的物化视图实际上只是一个表提取。Google BigQuery、Snowflake、Databricks和Azure Synapse会透明地维护物化视图内容。随着数据被添加到底层表中，视图内容会自动更新。安全性和血统数据治理的最佳实践是确保组织从数据摄取到使用的所有数据转换都能被跟踪。一个需要考虑的重要方面与识别哪些资源（例如，整个数据集或表中的某些字段）需要被视为敏感并需要通过设计进行保护有关。不仅要防止访问公司内部应视为机密的信息，甚至要准备好根据一些在某些情况下变得越来越严格的政府法规正确地管理数据（例如，欧洲的GDPR，美国的《健康保险可移植性与责任法案》或HIPAA等）。需要注意的是，在谈论安全性和合规性时，焦点不应仅限于谁访问了什么（这可以通过精细的访问控制列表[ACL]策略管理方法和数据加密/伪装技术来解决）；它还应该集中在：数据的起源在其被使用之前应用的不同转换当前物理数据位置（例如，德国的数据湖或英国的DWH）追踪这类元数据被称为数据血统，它有助于确保正在使用准确、完整和可信的数据来推动业务决策。查看数据血统在需要保证数据局部性的情况下也很有帮助，因为由于某些本地法规（例如，在德国的电信元数据中），如果您可以追踪数据在其生命周期中的位置，那么您可以实施自动化来防止那些不符合最低要求的人访问、使用和移动该信息。正如您所见，元数据在帮助公司组织其数据并管理其访问方面起着中心作用。它对于以准确性、完整性、一致性和新鲜度为标准评估所收集数据的质量也至关重要：低质量的数据可能导致错误的业务决策和潜在的安全问题。有几种技术和相关工具可以支持数据质量活动，但最常见的是：标准化：将来自不同来源的数据放入一致的格式中的过程（例如，修复大小写不一致性、字符更新、错误字段的值、数据格式等）重复数据删除：识别重复记录（利用相似度得分）并随后删除重复的值的过程匹配：查找数据集之间的相似性或关联以发现潜在的依赖关系的过程个人资料和监控：识别一系列数据值（例如，最小值、最大值、平均值），揭示可能需要进行数据修复或模式演变的异常和异常如果您使用云供应商的本机托管服务执行数据转换，工具通常会管理并携带元数据。因此，如果您使用例如Google Cloud上的Data Fusion、视图、物化视图等，Data Catalog将得到更新并保持血统。如果使用Dataflow构建转换管道，则应更新Data Catalog。同样，爬虫将自动更新AWS上的Data Catalog，但是如果实施自己的转换，则需要调用Glue API以添加到目录中。您已经了解了DWH（我们体系结构中的中心）如何推动数据转换，使其对您想要实现的所有用例都可用，同时保持您需要维护强大的所有加工的血统的元数据。现在让我们看看如何构建组织结构的结构以匹配中心和辐射架构。组织结构在许多组织中，业务分析师的数量通常远多于工程师，通常的比例是100：1。对于希望构建主要服务业务分析师的数据和机器学习平台的组织来说，Hub-and-Spoke架构是理想的选择。由于Hub-and-Spoke架构假定业务分析师能够编写自定义的SQL查询和构建仪表板，因此可能需要一些培训。在以分析师为先的系统中，中央数据工程团队负责（参见图6-7中的填充形状）：将原始数据从各种来源加载到数据仓库（DWH）中。许多来源可以配置为直接发布到现代数据仓库。确保数据治理，包括语义层和个人身份信息（PII）的保护。处理涉及业务单元跨越的工作负载（例如激活），涉及业务单元间数据的工作负载（例如身份解析），或需要专业工程技能的工作负载（例如机器学习）。管理常见的工件存储库，如数据目录、源代码存储库、秘密存储、特征存储和模型注册表。业务单元负责（参见图6-7中的未填充形状）：从业务特定来源加载数据到数据仓库。将原始数据转换为可用于下游分析的形式。向治理目录和工件注册表中填充业务特定的工件。为业务决策制定报告、自定义分析和仪表板。图6-7显示了Google Analytics、财务和Salesforce作为数据源的示例。在我们的示例中，Google Analytics的数据可能需要跨多个业务单元使用，因此由中央数据工程团队进行摄取。财务和Salesforce数据仅由特定的业务单元使用，因此由该业务单元进行摄取。每个业务单元管理自己的部署。中央团队的责任是将数据加载到业务团队使用的数据仓库中。这通常意味着中央团队使用的软件需要在不同的云环境中具有可移植性，并且由管道生成的数据格式是可移植的格式。因此，Apache Spark和Parquet通常是构建ETL管道的常见选择。如果两个业务单元选择使用相同的数据仓库技术，那么在这两个业务单元之间共享数据就变得更简单了，因此，在可能的情况下，我们建议在整个组织中使用相同的数据仓库技术（如BigQuery、Snowflake、Redshift等）。然而，在通过收购进行业务扩展的企业中，这并不总是可能的。根据我们的经验，最好使用单一的云技术作为您的数据仓库，以充分发挥其在所有部门中的能力，即使您采用多云战略。我们曾与一些利用两种甚至更多技术的组织合作过，但他们在维护所有系统之间的一致性上所付出的努力并不值得其中的好处。在本节中，您已经了解了如何通过实施Hub-and-Spoke架构来现代化您的数据平台，将您的数据仓库置于中心位置。您了解了多个"辐条"是如何围绕中央枢纽，即现代数据仓库，以实现批处理和流处理的任何用例，利用纯SQL语言，并符合数据治理要求。在接下来的章节中，我们将讨论数据仓库如何使数据科学家能够进行其活动。数据仓库（DWH）以支持数据科学家数据分析师通过对数据进行临时分析以创建报告，然后通过商业智能（BI）将报告操作化，以支持数据驱动的决策。数据科学家旨在利用统计学、机器学习和人工智能自动化和扩展数据驱动的决策。现代云数据仓库（DWH）对数据科学家和数据科学工具有哪些需求呢？正如您在图6-1中所见，他们需要以各种方式与DWH进行交互，以执行查询或仅仅获取对低级数据的访问权限。在本节中，我们将研究他们可以利用的最常见工具，以实现这一目标。正如您在前一章中所看到的，数据科学家需要进行实验，尝试不同形式的自动化，并了解自动化如何在历史数据的各个切片上运作。正如我们之前所见，数据科学家用于实验的主要开发工具是笔记本。因此，他们需要以高效的方式访问DWH中的数据，无论是通过DWH的查询界面进行的探索性数据分析，还是通过DWH的存储界面进行的操作化（请参阅图6-1）。确保您的云DWH支持这两种机制非常重要。让我们看看这些机制是如何工作的。查询接口在自动化决策之前，数据科学家需要进行大量的探索性数据分析和实验。这需要以交互方式进行。因此，需要一种快速的方式从笔记本中调用SQL查询。Jupyter魔法（例如图6-8中单元格中的%%bigquery行）提供了一种无需样板代码即可从笔记本中调用SQL查询的方法。结果以一种称为DataFrame的本机Python对象返回，可以使用pandas（一种数据分析函数库）进行操作。重要的是要注意，这是在不创建数据的内存提取的情况下完成的。云数据仓库以分布式方式执行SQL查询。笔记本服务器不需要运行在与数据仓库相同的计算基础设施上。利用数据仓库后端进行大规模数据处理以及笔记本前端的编程和可视化能力的结合对于数据科学家的高效工作是强大且必要的。存储API虽然笔记本与数据仓库连接的交互能力对于探索和实验非常重要，但这并不是自动化所需的。对于自动化而言，数据访问速度至关重要。机器学习框架应该能够绕过查询API，直接访问数据仓库的存储层。存储访问应支持从多个后台线程并行读取数据，因为通常情况下，在ML加速器（GPU或TPU）对前一批数据进行繁重计算的同时，会读取下一批数据。因此，与其使用查询API，不如使用机器学习框架支持的存储API，以高效且并行的方式从数据仓库中读取数据。在示例6-5中展示了使用Spark和TensorFlow从Google BigQuery中使用Storage API读取数据的方法。df = spark.read \ .format("bigquery") \ .load("bigquery-public-data.samples.shakespeare") def read_bigquery(): tensorflow_io_bigquery_client = BigQueryClient() read_session = tensorflow_io_bigquery_client.read_session( "projects/" + PROJECT_ID, "bigquery-public-data", "samples", "shakespeare", ..., requested_streams=2) dataset = read_session.parallel_read_rows() transformed_ds = dataset.map(transform_row) return transformed_ds 查询界面和存储API是数据科学家用来访问数据仓库进行分析的两种方法。现在有一个新的趋势需要考虑——在不必提取数据的情况下，直接在数据仓库中实现、训练和使用机器学习算法的能力。在接下来的部分，我们将看看它是如何工作的。在不移动您的数据的情况下进行机器学习一些现代的云数据仓库（例如BigQuery和Redshift，截至撰写本文时）还支持在数据仓库中对数据进行机器学习模型训练，而无需首先提取数据。它们通过在SQL中训练简单模型，并通过分别将任务委托给Vertex AI和SageMaker来训练更复杂的模型来实现这一点。让我们看看如何直接从您的数据仓库利用训练和服务（称为激活）您的机器学习算法。训练ML模型假设您想要训练一个机器学习模型，以预测用户在给定账户特征和账户费用的情况下是否会流失：可以利用历史数据来完成所有操作，如示例6-6所示。训练的模型类型可以非常复杂。CREATE MODEL customer_churn_auto_model FROM (SELECT state, account_length, area_code, total_charge/account_length AS average_daily_spend, cust_serv_calls/account_length AS average_daily_cases, churn FROM customer_activity WHERE record_date < '2020-01-01' ) TARGET churn FUNCTION ml_fn_customer_churn_auto IAM_ROLE 'arn:aws:iam::XXXXXXXXXXXX:role/Redshift-ML'SETTINGS ( S3_BUCKET 'your-bucket' );您可以使用访问者实际购买的历史数据来训练推荐系统，如示例6-7所示。CREATE OR REPLACE MODEL bqml_tutorial.my_implicit_mf_model OPTIONS (model_type='matrix_factorization', feedback_type='implicit', user_col='visitorId', item_col='contentId', rating_col='rating', l2_reg=30, num_factors=15) AS SELECT visitorId, contentId, 0.3 * (1 + (session_duration - 57937) / 57937) AS rating FROM bqml_tutorial.analytics_session_data示例6-8展示了一个只使用两个SQL语句编写的异常检测系统。CREATE OR REPLACE MODEL ch09eu.bicycle_daily_trips OPTIONS( model_type='arima_plus', TIME_SERIES_DATA_COL='num_trips', TIME_SERIES_TIMESTAMP_COL='start_date', DECOMPOSE_TIME_SERIES=TRUE ) AS ( SELECT EXTRACT(date from start_date) AS start_date, COUNT(*) AS num_trips FROM `bigquery-public-data.london_bicycles.cycle_hire` GROUP BY start_date ); SELECT * FROM ML.DETECT_ANOMALIES( MODEL ch09eu.bicycle_daily_trips, STRUCT (0.95 AS anomaly_prob_threshold)) ORDER BY anomaly_probability DESC能够仅使用SQL进行机器学习而无需设置数据移动，使得更广泛的组织能够进行预测性分析。这使机器学习变得更加民主化，因为借助典型的商业智能工具，数据分析师现在可以实施预测。这还显著提高了生产力——如果只需要两行SQL而不是需要熟练掌握TensorFlow或PyTorch的数据科学家进行为期六个月的项目，那么组织更有可能能够识别异常活动。ML训练和服务训练机器学习模型并不是现代数据仓库支持的唯一机器学习活动。它们还支持以下功能：将经过训练的机器学习模型导出为标准机器学习格式，以在其他地方进行部署。将机器学习训练纳入数据仓库作为更大机器学习工作流的一部分。调用机器学习模型作为外部函数。直接加载机器学习模型到数据仓库，以便以分布式方式高效调用机器学习预测。让我们一起看看这四种活动，它们为何重要，以及现代数据仓库如何支持它们。导出经过训练的机器学习模型在数据仓库中训练的机器学习模型可以通过ML.PREDICT在批处理模式下直接对历史数据进行调用。然而，对于需要实时结果的现代应用程序（例如，基于连接的用户，决定在页面中显示哪些广告的电子商务应用程序），这样的能力是不够的。有必要能够在线调用模型，即作为对单个输入或一小组输入的同步请求的一部分。在Redshift中，您可以通过将模型部署到SageMaker端点来实现这一点，在Google Cloud中则通过以SavedModel格式导出模型。然后，您可以将其部署到支持此标准机器学习格式的任何环境中。当然，支持Vertex AI端点，还支持SageMaker、Kubeflow Pipelines、iOS和Android手机以及Coral Edge TPUs。Vertex AI和SageMaker支持部署为微服务，并且通常用于基于服务器的应用程序，包括网站。部署到流水线支持流数据处理、自动交易和监控等用例。部署到iOS和Android支持移动电话，而部署到Edge TPUs则支持定制设备，例如汽车仪表板和信息亭。在机器学习流水线中使用您训练的模型很少有数据科学家的实验仅包括训练一个机器学习模型。通常，一个实验将包括一些数据准备、训练多个机器学习模型、进行测试和评估、选择最佳模型、创建模型的新版本、在小部分流量上设置A/B测试以及监控结果。只有其中的一些操作是在数据仓库中完成的。因此，在数据仓库中完成的步骤必须成为更大的机器学习工作流的一部分。机器学习实验及其工作流程被捕捉在机器学习流水线中。这些流水线包含许多容器化步骤，其中少数涉及数据仓库。因此，当数据准备、模型训练、模型评估等成为机器学习流水线的一部分时，它们必须作为容器可调用。流水线框架提供了方便的函数，以在云数据仓库上调用操作。例如，要从Kubeflow Pipelines中将BigQuery作为容器化操作调用，您可以使用BigQuery运算符。调用外部机器学习模型如今，机器学习是理解非结构化数据（如图像、视频和自然语言文本）的常用方法。在许多情况下，已经存在许多种类非结构化内容和用例的预训练机器学习模型，例如，已有预训练的模型可用于检测某些评论文本是否包含有害言论。您无需训练自己的有害言论检测模型。因此，如果您的数据集包含非结构化数据，能够对其进行机器学习模型的调用非常重要。例如，在Snowflake中，可以使用EXTERNAL FUNCTION调用Google Cloud的Translate API。通过通过网关创建API集成，然后配置Snowflake，可以按照示例6-9中演示的步骤完成这一操作。create or replace api integration external_api_integration api_provider = google_api_gateway google_audience = '<google_audience_claim>' api_allowed_prefixes = ('<your-google-cloud-api-gateway-base-url>') enabled = true; create or replace external function translate_en_french(input string) returns variant api_integration = external_api_integration as 'https://<your-google-cloud-api-gateway-base-url>/<path-suffix>’; 鉴于这一点，可以在SELECT语句中调用Translate API的某一列：SELECT msg, translate_en_french(msg) FROM ...加载预训练的机器学习模型使用外部函数调用机器学习模型可能效率较低，因为计算没有充分利用数据仓库的分布式性质。更好的方法是加载已训练的机器学习模型，并使数据仓库在其自己的计算环境中调用该模型。在BigQuery中，您可以首先加载TensorFlow模型，然后通过在SELECT语句中使用ML.PREDICT来调用它，如示例6-10中所示。CREATE OR REPLACE MODEL example_dataset.imported_tf_model OPTIONS (MODEL_TYPE='TENSORFLOW', MODEL_PATH='gs://cloud-training-demos/txtclass/export/exporter/1549825580/*') SELECT * FROM ML.PREDICT( MODEL tensorflow_sample.imported_tf_model, (SELECT title AS input FROM `bigquery-public-data.hacker_news.stories`)) 由于ML.PREDICT无需从数据仓库进行到已部署模型服务的外部调用，通常速度要快得多。它也更加安全，因为模型已经加载，不容易被篡改。总结在本章中，我们重点描述了数据仓库如何成为现代数据平台的核心，分析了如何利用中心枢-辐射体系结构实现数据分析、机器学习训练和激活。主要要点如下：现代数据平台需要支持更快地向决策者提供洞察。中心枢-辐射体系结构是对于没有需要适应的传统技术的组织而言的理想架构。所有数据都以尽可能自动化的方式落入企业数据仓库。可以使用预构建连接器摄取来自大量SaaS软件的数据。可以使用CDC工具使数据仓库反映在OLTP数据库或ERP系统中所做的更改。可以联合数据源，例如Blob存储，确保某些数据不需要移动到数据仓库。可以在支持SQL的关系数据库上运行外部查询。为了协助业务分析，投资于将操作推送到数据库而不是依赖于提取OLAP立方体的SQL工具。当你有数千到数百万的客户时，提供一个轻量级的图形可视化层更具可扩展性，可以嵌入到用户已经使用的工具中。建立一个语义层来捕获关键业绩指标（KPIs）、度量和维度，以促进一致性和重用。视图提供了一种使落入数据仓库的原始数据更易用的方式。将查询调度到表中以提取视图内容可能更具成本效益。物化视图则兼具两者的优点。随着数据的爆炸，架构变得更加复杂，访问和利用数据的用户数量增加，立法者正在引入更严格的规则来处理数据，数据治理和安全性变得更加重要。数据科学家需要能够从笔记本交互式地访问数据仓库，在没有样板代码的情况下运行查询，并直接从数据仓库的存储中批量访问数据。能够在不进行任何数据移动的情况下进行机器学习，并使得到的机器学习模型能够在许多环境中使用，有助于在业务的许多部分推动AI的使用。在组织层面，一些数据工程和治理功能是集中的，但不同的业务部门以不同的方式转换数据，仅在需要时进行。在下一章中，我们将讨论数据湖和数据仓库世界的融合，看看现代平台如何利用这两种范式的优势，为最终用户提供最大的灵活性和性能。

浏览量2024