数据迁移

如何使用数据迁移门户进行数据迁移。

🤔 什么是数据迁移门户？

数据迁移门户帮助您完成想要迁移到 Fast Track CRM 的任何数据迁移。借助门户的帮助，您现在可以完全独立地进行数据迁移。无需依赖 Fast Track，您可以按照自己的节奏和时间安排工作。但是，如果您需要任何帮助，请联系您在 Fast Track 的集成经理。

🔎 在哪里找到数据迁移门户

为了找到并访问数据迁移门户，您的用户需要被分配集成管理管理员角色。

如何导航：

  1. 从 Fast Track CRM 侧边菜单，点击设置按钮
  2. 点击集成
  3. 选择数据迁移
导航到数据迁移门户
导航到数据迁移门户

⚙️ 如何进行数据迁移

步骤 1：规划

  1. 决定要迁移的表和列。
  2. 在这里您需要了解迁移将影响哪些段字段。
  3. 请注意，Fast Track CRM 中的段字段被称为 table_name-field_name。例如，名为 payment_activity-deposit_count 的段字段引用 payment_activity 表中的 deposit_count 列。
  4. 重要的是要注意，如果某个字段没有被迁移，那么在分段中使用它可能会由于玩家对于未迁移字段可能有空值而导致不期望的行为。
  5. 您必须指明是否应在数据迁移之前截断表。 ⚠‍ 选择此选项将在用迁移数据填充之前清除表。如果您只打算为您的一部分玩家迁移数据，则不应选择此选项。
  6. 一旦您选择了表，您应该为选定的表下载模板 CSV。您将在下一步上传文件时需要这些。
注意 👀‍​
  1. 在规划时，请记住您要迁移的表的粒度。如果您要迁移payment_events，您上传的 CSV 文件中的每一行都应对应支付交易中的状态更改。如果您要迁移 casino_activity，每一行将对应一个单独的玩家，因此数据应代表该玩家的聚合汇总。
  2. 注意何时应该截断表；
    1. 如果您要迁移完整的事件历史记录，截断表是安全的。
    2. 如果您要迁移聚合表，只有当您计划在迁移中包含所有玩家时才应截断。
    3. 如果您要从聚合表迁移选定的列，则不应截断。

步骤 2：上传

  1. 在继续上传测试数据之前，您需要保存迁移。
  2. 对于上一阶段选择的每个表，您应该在上传部分上传您的文件。您可以为同一个表上传多个文件。我们将负责为您将它们合并成一个文件。
  3. 文件需要具有与上一步下载的模板相同的结构。
  4. 继续进行映射；在这里您需要将上传的文件映射到为迁移选择的表。如果您映射的文件没有按照下载模板的正确结构，当尝试将其映射到表时您将收到错误。
注意 👀‍​
  1. 当为上传提取数据文件时，请特别注意时间戳/日期列。所有迁移的时间戳/日期列应采用 YYYY-MM-DD 格式并使用 UTC 时间。
  2. 当为预运行上传文件时，我们建议您使用大块（如果不是全部）玩家数据。这确保数据中的任何潜在问题在预运行中被发现，在开始完整数据迁移之前。

步骤 3：预运行

  1. 只需点击按钮。
  2. 等待迁移完成。
  3. 当您的迁移完成时，进入 QA 阶段。

步骤 4：QA

  1. 在这里您将获得迁移数据的摘要。
  2. 您还将看到执行的验证检查集以及这些验证是否通过。
  3. 按照 QA 中的每个步骤验证一切看起来都很好。
  4. 下载对账文件并检查迁移的数据看起来是否良好。
  5. 当您对结果满意时，签署预运行并继续执行完整运行。
注意 👀‍​
  1. 如果在预运行中出现任何问题，例如，您在 QA 过程中注意到数据不一致，中止迁移并开始新迁移是安全的。这是因为在预运行期间不会修改生产数据。
  2. 使用预运行的 QA 过程来检查和验证您的迁移数据是完美的。如果您不确信您的数据看起来正确，请联系您的 Fast Track 集成经理寻求帮助。

步骤 5：完整运行

迁移的完整运行遵循与预运行相同的流程。这里需要注意的重要一点是，为了执行完整运行，Fast Track 需要暂停实时事件的处理和 CRM 活动的触发。这样做是为了确保数据一致性，并确保没有基于陈旧分段数据触发活动。

步骤 5.1：暂停队列

  1. 执行迁移完整运行的第一步是暂停队列。
  2. 当您点击暂停队列按钮时，系统将要求您确认。确认后，系统将暂停处理队列中的消息。
  3. 您将获得队列暂停前最后处理消息的确切时间戳。记下此时间戳很重要。
  4. 在进行数据导出时，迁移中包含的所有字段都应按照提供的时间戳计算。当实时处理恢复时，Fast Track 系统将从该时间戳开始继续聚合实时事件，确保数据的一致性。

步骤 5.2：为完整运行上传文件

  1. 文件的结构与预运行中上传的文件保持相同。
  2. 您现在应该为每个迁移的表上传文件。我们提醒您，文件中的数据应在上一步提供的时间戳处聚合。
  3. 一旦您为所有表上传了文件，请继续下一步。

步骤 5.3：运行

  1. 通过点击运行按钮开始迁移过程。
  2. 等待迁移完成 - 这可能需要一些时间，取决于迁移的数据量。
  3. 当数据迁移完成后，继续质量保证步骤。

步骤 5.4：QA

  1. QA 过程类似于预运行中完成的验证过程。
  2. 此时，您应确保所有数据都是正确的。
  3. 如果您签署迁移，Fast Track 服务将恢复，消息处理将从之前提供的时间戳开始继续。
​ℹ‍迁移完整运行完成后，您应该看到以下横幅：
​
​

步骤 5.5：服务监控

  1. 数据迁移完成后，Fast Track 服务将恢复。此时，您应该前往服务门户并检查您的 Fast Track 系统看起来是否健康。
  2. 您应该注意队列中的消息将继续被处理 - 由于在整个迁移期间没有消息被处理，以下队列中的消息堆积是预期的：
    1. integration.api
    2. activitymanager.timeinstance
    3. activitymanager.lf-timeinstance
    4. activitymanager.sdtinstance
    5. singularity
    6. singularity-time
  3. 验证消息正在被处理，队列中的消息数量正在下降 - 您应该获得队列将完全处理完毕且系统恢复实时状态的预估时间。
  4. 如果消息没有被处理或某些东西看起来不对，请联系您的 Fast Track 集成经理寻求帮助。
注意 👀‍​
  1. 如果您已经开始数据迁移的完整运行，由于某种原因您想要停止迁移，您应该联系您的 Fast Track 集成经理寻求帮助。
  2. 如果您在 QA 过程中注意到数据有问题，您可以通过点击回滚来回滚迁移。这将把您的生产数据恢复到迁移开始前的状态。或者，您可以完成迁移并重新运行另一个。
  3. 在数据迁移后验证您的服务已恢复并运行很重要。如果您认为您的 Fast Track 服务有问题，请联系您的 Fast Track 集成经理寻求帮助。