如何解决摄取时的 Azure 数据资源管理器逻辑
我有数据从事件中心流向 Azure 数据资源管理器。我们配置了一个包含所有数据的主表。在摄取到该主表后，我们创建了几个包含主表部分数据的子表。例如。
我们收到以下 JSON 数据的事件中心
{
TIME:'T'
data: [
{
"ABC" : 1234,"DEF" : 1235,"GHI" : 1236
},{
"ABC" : 1223,"DEF" : 1236,"GHI" : 12
},{
"ABC" : 2213,"GHI" : 1236
}]
}
将这些数据摄取到主原始表后，我们几乎没有摄取时间策略可以扩展此 JSON 并摄取到下表格式的子表中。
| TIMEINUTC | ABC |
|---|---|
| T | 1234 |
| T | 1223 |
| T | 2213 |
其他表格类似，如下。
| TIMEINUTC | DEF |
|---|---|
| T | 1235 |
| T | 1236 |
| T | 2213 |
| TIMEINUTC | GHI |
|---|---|
| T | 1236 |
| T | 12 |
| T | 1236 |
现在我可以基于这个小表运行我的分析作业/Kusto 查询。
问题是， 我想对另一个表进行一些有条件的插入。例如。 说ABC的值为1234并插入到ABC子表中。如果一段时间后我再次收到 ABC 值 1234，我不想插入到子表中。
- 在摄取时间策略中编写这样的逻辑是否是一种好方法？
- 如果这样的摄取时间政策需要一些时间来执行，它会 影响从事件中心到主原始表的 RawData 摄取？
- 我是否应该在 ADF/逻辑应用程序中定期使用一些调度程序方法？
解决方法
我假设“摄取时间政策”指的是 update policy。对于您所描述的场景（删除重复记录），更好的方法是 materialized-view，（查看“重复数据删除”示例）。
关于Q.2，这取决于更新策略是否是事务性的，如果是，它会影响对原始表的摄取，因为在所有更新策略成功结束之前摄取不会提交，如果不是事务性的，则不会有太大影响。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。