如何处理或体系结构，Azure数据湖存储中的增量数据提取？(How to Handle or Architecture, incremental data ingestion in Azure dat

如何处理或体系结构，Azure数据湖存储中的增量数据提取？(How to Handle or Architecture, incremental data ingestion in Azure data lake Store?)

我有两个自定义代码dll，用于与IP摄像头相关的图像。

dll-One ：从IP摄像头中提取图像，并将其存储到Azure数据湖存储中。

喜欢 ：

/ ADL的/ clinic1 / patientimages / ADL的/ clinic2 / patientimages

dll-two ：使用这些映像并从中提取信息并将数据加载到RDBMS表中。

因此，例如在RDBMS中，比如有实体不耐烦，dimclinic和factpatientVisit。

首先，可以将一次性数据导出到Azure数据湖存储中的已定义位置。

喜欢：

/ ADL的/ dimpatient / ADL的/ dimclinic / ADL的/ factpatientVisit

问题：如何在同一文件中推送增量数据或如何在Azure数据分析中处理此增量负载？

这就像在Azure Data Analytics中实现Warehouse一样。

注意 ：Azure SQL数据库或Azure提供的任何其他存储都不希望这样。 我的意思是，如果一种类型的存储具有容纳所有类型数据的能力，为什么要花费在其他Azure服务中。

adls是我的ADLS存储的名称。

I've Two Custom code dll, for Image related to IP Cams.

dll-One : Extract image from IP cams and can be stored it to Azure data lake Store.

Like :

/adls/clinic1/patientimages /adls/clinic2/patientimages

dll-two : Use those image and extract information from it and load data into RDBMS tables.

So for instance in RDBMS ,say there are entities dimpatient, dimclinic and factpatientVisit.

For start, a one time data can be exported to defined location in Azure data lake store.

Like:

/adls/dimpatient /adls/dimclinic /adls/factpatientVisit

Question : How to push incremental data in same file or how we can handle this incremental load in Azure data Analytics?

This like implementing Warehouse in Azure Data Analytics.

Note: Azure SQL db or any other storage offered by Azure is not want to. I mean why to spend in other Azure Services if one type of storage has capabilities to hold all types of data.

adls is name of my ADLS storage.

最满意答案

我不确定我是否完全理解您的问题，但您可以按时间维度组织Azure Data Lake Store中的数据文件或分区U-SQL表中的行，以便为每个增量添加新的分区/文件。 一般而言，我们建议这种增量具有相当大的尺寸，但要保持扩展能力。

I am not sure I completely understand your question, but you can organize your data files in Azure Data Lake Store or your rows in partitioned U-SQL tables along a time dimension, so you can add new partitions/files for each increment. In general, we recommend that such increments are of substantial sizes though to preserve the ability to scale.