我正在尝试使用Azure数据工厂替换我们目前拥有的其他一些数据加载解决方案，并且我正在努力寻找组织和参数化管道以提供我们所需的可伸缩性的最佳方法。
我们的典型模式是我们为特定平台构建集成。这种“集成”实质上是将字段从其数据文件（CSV）映射和转换到我们的Stage1 SQL数据库中，并且当数据到达该数据库时，应正确设置数据类型并设置索引。
在每个平台中，我们都有客户。每个客户都有自己的数据文件集，这些数据文件是在该客户上下文中处理的-在平台范围内，所有客户文件都遵循相同的模式（或与其相近），但是它们都分别发送给我们。如果您查看我们的传入文件存储，则可能看起来像这样（简化，每个客户有20-30个源数据集，具体取决于平台）：
每个客户都使用自己的SQL模式。因此，在处理完上述内容之后，我应该具有CustomerA.Employees和CustomerB.Employees表。 （这会使客户之间发生一些架构漂移，这在某些平台上确实发生。我们将在第二阶段的ETL过程中进行处理。）
我要弄清楚的是：
设置ADF的最佳方法是什么，以便我可以有效地管理每个平台的一组映射，并自动容纳我们添加到该平台的任何新客户，而无需更改管道/流程？
我目前的想法是每个平台有一个管道，每个平台每个文件有一个数据流。管道具有变量“ schemaname”，该变量使用触发它的文件路径（例如“ CustomerA”）进行设置。然后，根据文件名，有一个分支条件将触发正确的数据流。例如。如果是“ employees.csv”，它将运行一个数据流；如果是“ payperiods.csv”，它将加载另一个数据流。而且，他们都将使用相同的通用目标接收器数据源，对表名进行参数化，并使用模式变量和条件分支中的文件名在管道中设置这些参数。
以这种方式设置它有什么陷阱吗？我在正确考虑吗？
答案 0 :(得分：0)
听起来不错。请注意，如果您使用期望这些列存在的表达式定义特定于列的映射，那么如果客户源文件中不存在这些列，则可能会导致数据流执行失败。
防止ADF数据流中的方法是使用列模式。这将使您可以定义通用且更灵活的映射。