主题域与应用程序之间的亲和度映射及其实践

要确定应该将哪些应用程序及其相关主题域纳入哪些波次，我们需要在应用程序与主题域之间做出详细映射。下表所示，为此类映射的相关示例。

图一：应用程序（分析）与主题域之初是的亲和度映射。

这种映射的基础，在于查询执行元数据——元数据通常存储在传统数据仓库的系统表当中。这种映射关系也将成为各个波次（即应用程序对象与相关主题域的单步迁移）的创建基础。您可以通过相同的方式得出下一步迁移操作，以更详尽的方式（下探至表层级）建立数据源与主题域间的映射，并据此制定出更详尽的迁移项目规划。

上表中使用的排序方法非常重要。最右侧的列，为主题域在应用程序中出现的总次数（自上而下，为最常见的主题域到出现频率最低的主题域）。最下行则为应用程序中出现的主题域数量（从左至右，为包含主题域最多的应用程序到包含主题域最少的应用程序）。

在其他条件完全相同的情况下，我们的第一波迁移应该从哪些应用程序与分析开始？最佳实践是选择其中的某个中间位置（例如上表中的 Analytic 8 或者 9 位置）。如果从最左侧的列（Analytic 1）开始，那么该波次中会包含大量对象（源与表、视图、ETL 脚本、数据格式、清理以及公开例程等），这将导致操作强度过大且完成周期过长。或者，如果您从最右侧的列（Analytic 19）开始，则涵盖的主题域过少，并导致完成整体迁移所需要的波次更多、总体迁移周期更长。另外，从最右侧开始也无法帮助我们了解整体项目的复杂度水平。

下表所示，为以上亲和度图的分波次迁移方案（阶梯步进）。在每个波次中（可能包含一个或者多个应用程序或分析）总是存在新的主题域（绿色框体）以及在先前波次中已经迁移完成的主题域（蓝色框体）。基于波次的最佳迁移方法，在于将迁移波次的设计中保证每个后续波次中包含的新build越来越少。在以下示例中，随着最初几个波次的完成，我们需要集成至后续波次中的新主题域越来越少——也正因为如此，我们才建议从亲和度表的中间位置向左移动。最终，这种方式能够加快迁移项目的整体执行速度。

图二：阶梯步进模式与对象域集成。

第0波通常包含各应用程序使用的共享或基础维度数据或表（例如 Time 以及 Organization）。每一波至少应该包含一个锚应用，且该锚应用需要包含新的主题域或数据源。那么，我们在各波次中选择锚应用时，又该考虑哪些具体因素？首先，该波次内的锚应用与其他波次中的锚应用应尽可能保持较低的依赖度，而且从业务角度来看，锚应用本身应该具有较高的重要性。所有波次中的锚应用组合还应该涵盖所有主题域。

在以上示例中，我们设置了六个不同的迁移波次。下表总结了其中使用的对应锚应用：

其他所有应用程序（分析）将进行自动处理，因为它们所依赖的主题域已经在上述各波次中构建完成。

要确定总迁移波次数量，以及每个波次中应包含哪些应用程序，请考虑以下因素：

• 业务优先级——即应用程序在客户数据驱动型企业（D2E）旅程中的具体价值。
• 工作负载概况——工作负载主要属于 ETL（写入密集型）还是查询（只读取）。
• 数据共享要求——不同应用程序可能使用同一表中的数据。
• 应用程序 SLA ——各应用程序为最终用户做出的性能承诺指标。
• 依赖关系——不同应用程序之间的功能依赖关系。
  

最佳波次数量将根据以上标准核算得出，最佳实践建议在单一迁移项目当中最多包含 10 个波次，保证您能够有效对迁移进行规划、执行与监控。

返回上一级 云数据库文章 >>