適用対象:
Azure Data Factory
Azure Synapse Analytics
Tip
Microsoft Fabric の Data Factory (企業向けのオールインワン分析ソリューション) を試してみてください。 Microsoft Fabric では、データ移動からデータ サイエンス、リアルタイム分析、ビジネス インテリジェンス、レポートまで、あらゆるものをカバーしています。 無料で新しい試用版を開始する方法については、こちらを参照してください。
Azure Data Lake Storage Gen2 (ADLS Gen2) は、ビッグ データ分析専用の機能セットであり、Azure Blob Storage に組み込まれています。 ファイル システムとオブジェクト ストレージの両方のパラダイムを使用して、データと連携させることができます。
この記事では、コピー アクティビティを使用して、Azure Data Lake Storage Gen2 との間でデータをコピーし、Data Flow を使用して Azure Data Lake Storage Gen2 でデータを変換する方法について説明します。 詳細については、Azure Data Factory または Azure Synapse Analytics の概要記事を参照してください。
Tip
データ レイクまたはデータ ウェアハウスの移行シナリオの詳細については、データ レイクまたはデータ ウェアハウスから Azure にデータを移行する方法に関する記事を参照してください。
サポートされる機能
この Azure Data Lake Storage Gen2 コネクタは、次の機能でサポートされます。
| サポートされる機能 | IR | マネージド プライベート エンドポイント |
|---|---|---|
| Copy アクティビティ (ソース/シンク) | (1) (2) | ✓ |
| マッピング データ フロー (ソース/シンク) | ① | ✓ |
| 検索アクティビティ | (1) (2) | ✓ |
| GetMetadata アクティビティ | (1) (2) | ✓ |
| アクティビティを削除する | (1) (2) | ✓ |
① Azure 統合ランタイム ② セルフホステッド統合ランタイム
コピー アクティビティの場合、このコネクタを使用して次のことができます。
- アカウント キー認証、サービス プリンシパル認証、または Azure リソースのマネージド ID 認証を使用して Azure Data Lake Storage Gen2 との間でデータをコピーする。
- ファイルをそのままコピーするか、サポートされているファイル形式と圧縮コーデックを使用してファイルを解析または生成する。
- コピー中にファイルのメタデータを保持する。
- Azure Data Lake Storage Gen1/Gen2 からコピーするときに ACL を保持する。
概要
Tip
Data Lake Storage Gen2 コネクタの使用方法のチュートリアルについては、Azure Data Lake Storage Gen2 へのデータの読み込みに関する記事をご覧ください。
パイプラインでコピー アクティビティを実行するには、次のいずれかのツールまたは SDK を使用できます。
- データのコピー ツール
- Azure Portal
- .NET SDK
- Python SDK
- Azure PowerShell
- REST API
- Azure Resource Manager テンプレート
UI を使用して Azure Data Lake Storage Gen2 のリンク サービスを作成する
次の手順を使用して、Azure portal UI で Azure Data Lake Storage Gen2 のリンク サービスを作成します。
Azure Data Factory または Synapse ワークスペースの [管理] タブに移動し、[リンク サービス] を選択して、[新規] を選択します。
- Azureデータファクトリー
- Azure Synapse
Azure Data Lake Storage Gen2 を検索し、Azure Data Lake Storage Gen2 コネクタを選択します。
サービスの詳細を構成し、接続をテストして、新しいリンク サービスを作成します。
コネクタの構成の詳細
以下のセクションでは、Data Lake Storage Gen2 に固有の Data Factory および Synapse パイプライン エンティティの定義に使用されるプロパティについて説明します。
リンクされたサービスのプロパティ
Azure Data Lake Storage Gen2 コネクタでは、次の認証の種類がサポートされています。 詳細については、対応するセクションをご覧ください。
Note
- グローバル Azure 統合ランタイムを使用して、Azure Storage ファイアウォールで有効になっている [ 信頼された Microsoft サービスによるこのストレージ アカウントへのアクセスを許可 する] オプションを適用して Data Lake Storage Gen2 に接続する場合は、 マネージド ID 認証を使用する必要があります。 Azure Storage ファイアウォール設定の詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。
- PolyBase または COPY ステートメントを使用して Azure Synapse Analytics にデータを読み込むときに、ソースまたはステージング Data Lake Storage Gen2 が Azure Virtual Network エンドポイントで構成されている場合は、Azure Synapse の要求に従ってマネージド ID 認証を使用する必要があります。 構成の前提条件の詳細については、マネージド ID 認証セクションを参照してください。
アカウント キー認証
ストレージ アカウント キー認証の使用には、次のプロパティがサポートされています。
| Property | Description | Required |
|---|---|---|
| 型 | type プロパティは AzureBlobFS に設定する必要があります。 | Yes |
| url | Data Lake Storage Gen2 のエンドポイントのパターンは https://<accountname>.dfs.core.windows.net です。 |
Yes |
| accountKey | Data Lake Storage Gen2 のアカウント キー。 このフィールドを SecureString とマークして安全に保存するか、Azure Key Vault に保存されているシークレットを参照します。 | Yes |
| connectVia | データ ストアに接続するために使用される統合ランタイム。 データ ストアがプライベート ネットワーク内にある場合、Azure Integration Runtime またはセルフホステッド統合ランタイムを使用できます。 このプロパティが指定されていない場合は、既定の Azure Integration Runtime が使用されます。 | No |
Note
アカウント キー認証を使用する場合、セカンダリ ADLS ファイル システム エンドポイントはサポートされません。 ほかの認証の種類を使用できます。
Example:
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"url": "https://<accountname>.dfs.core.windows.net",
"accountkey": {
"type": "SecureString",
"value": "<accountkey>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Shared Access Signature 認証
Shared Access Signature を使用すると、ストレージ アカウント内のリソースへの委任アクセスが可能になります。 Shared Access Signature を使用して、ストレージ アカウントのオブジェクトへの制限付きアクセス許可を、期間を指定してクライアントに付与できます。
アカウントのアクセス キーを共有する必要はありません。 Shared Access Signature とは、ストレージ リソースへの認証アクセスに必要なすべての情報をクエリ パラメーター内に含む URI です。 クライアントは、Shared Access Signature 内で適切なコンストラクターまたはメソッドに渡すだけで、Shared Access Signature でストレージ リソースにアクセスできます。
Shared Access Signature の詳細については、Shared Access Signature モデルの概要に関するページを参照してください。
Note
- サービスでは、サービスの Shared Access Signature とアカウントの Shared Access Signature がサポートされるようになりました。 Shared Access Signature の詳細については、「Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。
- 後のデータセットの構成では、フォルダーのパスはコンテナー レベルから始まる絶対パスです。 SAS URI のパスに揃えて構成する必要があります。
Shared Access Signature 認証を使用する場合には、以下のプロパティがサポートされます。
| Property | Description | Required |
|---|---|---|
| 型 |
type プロパティを AzureBlobFS に設定する必要があります (推奨) |
Yes |
| sasUri | BLOB、コンテナーなどの Storage リソースへの Shared Access Signature URI を指定します。 安全に格納するため、このフィールドを SecureString としてマークします。 自動ローテーションを使用してトークン部分を削除するために、SAS トークンを Azure Key Vault に配置することもできます。 詳細については、下記の例と、「Azure Key Vault への資格情報の格納」を参照してください。 |
Yes |
| connectVia | データ ストアに接続するために使用される統合ランタイム。 データ ストアがプライベート ネットワーク内にある場合、Azure Integration Runtime またはセルフホステッド統合ランタイムを使用できます。 このプロパティが指定されていない場合は、サービスでは、既定の Azure Integration Runtime が使用されます。 | No |
Note
AzureStorage タイプのリンクされたサービスを使用している場合、そのままでも引き続きサポートされます。 ただし今後は、新しい AzureDataLakeStorageGen2 タイプのリンクされたサービスを使用することをお勧めします。
Example:
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"sasUri": {
"type": "SecureString",
"value": "<SAS URI of the Azure Storage resource e.g. https://<accountname>.blob.core.windows.net/?sv=<storage version>&st=<start time>&se=<expire time>&sr=<resource>&sp=<permissions>&sip=<ip range>&spr=<protocol>&sig=<signature>>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
例: アカウント キーを Azure Key Vault に格納する
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"sasUri": {
"type": "SecureString",
"value": "<SAS URI of the Azure Storage resource without token e.g. https://<accountname>.blob.core.windows.net/>"
},
"sasToken": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "<Azure Key Vault linked service name>",
"type": "LinkedServiceReference"
},
"secretName": "<secretName with value of SAS token e.g. ?sv=<storage version>&st=<start time>&se=<expire time>&sr=<resource>&sp=<permissions>&sip=<ip range>&spr=<protocol>&sig=<signature>>"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Shared Access Signature の URI を作成する際は、次の点に注意してください。
- リンク サービス (読み取り、書き込み、読み取り/書き込み) がどのように使用されているかに応じて、オブジェクトに対する適切な読み取り/書き込みアクセス許可を設定します。
- 有効期限を適切に設定します。 Storage オブジェクトへのアクセスがパイプラインのアクティブな期間内に期限切れにならないことを確認します。
- URI は、必要に応じて、適切なコンテナーまたは BLOB で作成する必要があります。 BLOB への Shared Access Signature URI を使用して、データ ファクトリまたは Synapse パイプラインから、その特定の BLOB へのアクセスを許可します。 BLOB ストレージ コンテナーへの Shared Access Signature URI を使用して、データ ファクトリまたは Synapse パイプラインで、そのコンテナー内の BLOB を反復処理できるようにします。 アクセスするオブジェクトの数を後で変更する場合、または Shared Access Signature URI を更新する場合は必ず、リンクされたサービスを新しい URI で更新してください。
サービス プリンシパルの認証
サービス プリンシパル認証を使用するには、次の手順に従います。
Microsoft ID プラットフォームにアプリケーションを登録します。 方法については、「クイック スタート: Microsoft ID プラットフォームにアプリケーションを登録する」を参照してください。 これらの値を記録しておきます。リンクされたサービスを定義するときに使います。
- アプリケーション識別子
- アプリケーション キー
- テナント ID
サービス プリンシパルに適切なアクセス許可を付与します。 Data Lake Storage Gen2 におけるアクセス許可の動作例については、「ファイルとディレクトリのアクセス制御リスト」を参照してください。
- ソースとして: Storage Explorer で、すべての上位フォルダーとファイル システムについて、少なくとも実行アクセス許可を与えると共に、コピーするファイルの読み取りアクセス許可を与えます。 または、[アクセス制御 (IAM)] で、少なくともストレージ BLOB データ閲覧者ロールを付与します。
- シンクとして: Storage Explorer で、すべての上位フォルダーとファイル システムについて、少なくとも実行アクセス許可を与えると共に、シンク フォルダーに対する書き込みアクセス許可を与えます。 または、[アクセス制御 (IAM)] で、少なくともストレージ BLOB データ共同作成者ロールを付与します。
Note
UI を使用して作成し、サービス プリンシパルが IAM で "ストレージ BLOB データ閲覧者/共同作成者" ロールで設定されていない場合は、テスト接続またはフォルダーの参照/移動を行うときに、[Test connection to file path]\(ファイル パスへのテスト接続\) または [Browse from specified path]\(指定されたパスからの参照\) を選択し、 読み取りと実行 のアクセス許可を持つパスを指定して続行します。
リンクされたサービスでは、次のプロパティがサポートされています。
| Property | Description | Required |
|---|---|---|
| 型 | type プロパティは AzureBlobFS に設定する必要があります。 | Yes |
| url | Data Lake Storage Gen2 のエンドポイントのパターンは https://<accountname>.dfs.core.windows.net です。 |
Yes |
| servicePrincipalId | アプリケーションのクライアント ID を取得します。 | Yes |
| servicePrincipalCredentialType | サービス プリンシパル認証に使用する資格情報の種類。 使用できる値は ServicePrincipalKey と ServicePrincipalCert です。 | Yes |
| servicePrincipalCredential | サービス プリンシパルの資格情報。 資格情報の種類として ServicePrincipalKey を使用する場合は、アプリケーションのキーを指定します。 このフィールドを SecureString とマークして安全に保存するか、Azure Key Vault に保存されているシークレットを参照します。 資格情報として ServicePrincipalCert を使用する場合は、Azure Key Vault 内の証明書を参照し、証明書のコンテンツ タイプが PKCS #12 であることを確認します。 |
Yes |
| servicePrincipalKey | アプリケーションのキーを取得します。 このフィールドを SecureString とマークして安全に保存するか、Azure Key Vault に保存されているシークレットを参照します。 このプロパティは servicePrincipalId + servicePrincipalKey でもそのままサポートされています。 ADF により、新しいサービス プリンシパル証明書認証が追加されると、サービス プリンシパル認証の新しいモデルは servicePrincipalId + servicePrincipalCredentialType + servicePrincipalCredential になります。 |
No |
| テナント | アプリケーションが存在するテナントの情報 (ドメイン名またはテナント ID) を指定します。 これは、Azure portal の右上隅をマウスでポイントすることで取得できます。 | Yes |
| azureCloudType | サービス プリンシパル認証用に、Microsoft Entra アプリケーションが登録されている Azure クラウド環境の種類を指定します。 指定できる値は、AzurePublic、AzureChina、AzureUsGovernment、および AzureGermany です。 既定では、データ ファクトリまたは Synapse パイプラインのクラウド環境が使用されます。 |
No |
| connectVia | データ ストアに接続するために使用される統合ランタイム。 データ ストアがプライベート ネットワーク内にある場合、Azure Integration Runtime またはセルフホステッド統合ランタイムを使用できます。 指定されていない場合は、既定の Azure Integration Runtime が使用されます。 | No |
例: サービス プリンシパル キー認証の使用
サービス プリンシパル キーを Azure Key Vault に格納することもできます。
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"url": "https://<accountname>.dfs.core.windows.net",
"servicePrincipalId": "<service principal id>",
"servicePrincipalCredentialType": "ServicePrincipalKey",
"servicePrincipalCredential": {
"type": "SecureString",
"value": "<service principal key>"
},
"tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
例: サービス プリンシパル認証の使用
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"url": "https://<accountname>.dfs.core.windows.net",
"servicePrincipalId": "<service principal id>",
"servicePrincipalCredentialType": "ServicePrincipalCert",
"servicePrincipalCredential": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "<AKV reference>",
"type": "LinkedServiceReference"
},
"secretName": "<certificate name in AKV>"
},
"tenant": "<tenant info, e.g. microsoft.onmicrosoft.com>"
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
システム割り当てマネージド ID 認証
データ ファクトリまたは Synapse ワークスペースは、システム割り当てマネージド ID に関連付けることができます。 独自のサービス プリンシパルを使用する場合と同様に、Data Lake Storage Gen2 の認証にこのシステム割り当てマネージド ID を直接使用できます。 これにより、この指定されたファクトリまたはワークスペースは、Data Lake Storage Gen2 にアクセスしてデータをコピーできます。
システム割り当てマネージド ID 認証を使用するには、次の手順に従います。
データ ファクトリまたは Synapse ワークスペースと共に生成されたマネージド ID オブジェクト ID の値をコピーして、システム割り当てマネージド ID 情報を取得します。
システム割り当てマネージド ID に適切なアクセス許可を付与します。 Data Lake Storage Gen2 におけるアクセス許可の動作例については、「ファイルとディレクトリのアクセス制御リスト」を参照してください。
- ソースとして: Storage Explorer で、すべての上位フォルダーとファイル システムについて、少なくとも実行アクセス許可を与えると共に、コピーするファイルの読み取りアクセス許可を与えます。 または、[アクセス制御 (IAM)] で、少なくともストレージ BLOB データ閲覧者ロールを付与します。
- シンクとして: Storage Explorer で、すべての上位フォルダーとファイル システムについて、少なくとも実行アクセス許可を与えると共に、シンク フォルダーに対する書き込みアクセス許可を与えます。 または、[アクセス制御 (IAM)] で、少なくともストレージ BLOB データ共同作成者ロールを付与します。
リンクされたサービスでは、次のプロパティがサポートされています。
| Property | Description | Required |
|---|---|---|
| 型 | type プロパティは AzureBlobFS に設定する必要があります。 | Yes |
| url | Data Lake Storage Gen2 のエンドポイントのパターンは https://<accountname>.dfs.core.windows.net です。 |
Yes |
| connectVia | データ ストアに接続するために使用される統合ランタイム。 データ ストアがプライベート ネットワーク内にある場合、Azure Integration Runtime またはセルフホステッド統合ランタイムを使用できます。 指定されていない場合は、既定の Azure Integration Runtime が使用されます。 | No |
Example:
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"url": "https://<accountname>.dfs.core.windows.net",
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
ユーザー割り当てマネージド ID 認証
データ ファクトリは、1 つ以上のユーザー割り当てマネージド ID に割り当てることができます。 このユーザー割り当てマネージド ID を BLOB ストレージ認証に使用できます。これにより、Data Lake Storage Gen2 にアクセスしてデータをコピーできます。 Azure リソース用マネージド ID の詳細については、Azure リソース用マネージド ID に関するページを参照してください。
ユーザー割り当てマネージド ID 認証を使用するには、次の手順に従います。
1 つ以上のユーザー割り当てマネージド ID を作成して、Azure Data Lake Storage Gen2 に対するアクセスを許可します。 Data Lake Storage Gen2 におけるアクセス許可の動作例については、「ファイルとディレクトリのアクセス制御リスト」を参照してください。
- ソースとして: Storage Explorer で、すべての上位フォルダーとファイル システムについて、少なくとも実行アクセス許可を与えると共に、コピーするファイルの読み取りアクセス許可を与えます。 または、[アクセス制御 (IAM)] で、少なくともストレージ BLOB データ閲覧者ロールを付与します。
- シンクとして: Storage Explorer で、すべての上位フォルダーとファイル システムについて、少なくとも実行アクセス許可を与えると共に、シンク フォルダーに対する書き込みアクセス許可を与えます。 または、[アクセス制御 (IAM)] で、少なくともストレージ BLOB データ共同作成者ロールを付与します。
1 つ以上のユーザー割り当てマネージド ID をデータ ファクトリに割り当てて、ユーザー割り当てマネージド ID ごとに資格情報を作成します。
リンクされたサービスでは、次のプロパティがサポートされています。
| Property | Description | Required |
|---|---|---|
| 型 | type プロパティは AzureBlobFS に設定する必要があります。 | Yes |
| url | Data Lake Storage Gen2 のエンドポイントのパターンは https://<accountname>.dfs.core.windows.net です。 |
Yes |
| 認証情報 | ユーザー割り当てマネージド ID を資格情報オブジェクトとして指定します。 | Yes |
| connectVia | データ ストアに接続するために使用される統合ランタイム。 データ ストアがプライベート ネットワーク内にある場合、Azure Integration Runtime またはセルフホステッド統合ランタイムを使用できます。 指定されていない場合は、既定の Azure Integration Runtime が使用されます。 | No |
Example:
{
"name": "AzureDataLakeStorageGen2LinkedService",
"properties": {
"type": "AzureBlobFS",
"typeProperties": {
"url": "https://<accountname>.dfs.core.windows.net",
"credential": {
"referenceName": "credential1",
"type": "CredentialReference"
}
},
"connectVia": {
"referenceName": "<name of Integration Runtime>",
"type": "IntegrationRuntimeReference"
}
}
}
Note
Data Factory UI を使用して作成し、IAM でマネージド ID が "ストレージ BLOB データ閲覧者/共同作成者" ロールで設定されていない場合、テスト接続またはフォルダーの参照/移動を行うときに、[Test connection to file path]\(ファイル パスへのテスト接続\) または [Browse from specified path]\(指定されたパスからの参照\) を選択し、 読み取りと実行 のアクセス許可を持つパスを指定して続行します。
Important
PolyBase または COPY ステートメントを使用して Data Lake Storage Gen2 から Azure Synapse Analytics にデータを読み込む場合に、Data Lake Storage Gen2 に対してマネージド ID 認証を使用するときは、必ずこちらのガイダンスの手順 1 から 3 にも従ってください。 これらの手順により、サーバーが Microsoft Entra ID に登録され、Storage Blob データ共同作成者のロールがサーバーに割り当てられます。 残りの処理は Data Factory によって行われます。 Azure Virtual Network エンドポイントがある BLOB ストレージを構成する場合は、Azure Synapse の要件のとおり、Azure Storage アカウントの [ファイアウォールと仮想ネットワーク] 設定メニューで、[信頼された Microsoft サービスによるこのストレージ アカウントに対するアクセスを許可します] をオンにする必要もあります。
データセットのプロパティ
データセットの定義に使用できるセクションとプロパティの一覧については、データセットに関する記事をご覧ください。
Azure Data Factory では次のファイル形式がサポートされます。 形式ベースの設定については、各記事を参照してください。
Data Lake Storage Gen2 では、形式ベースのデータセットの location 設定で次のプロパティがサポートされています。
| Property | Description | Required |
|---|---|---|
| 型 | データセットの location の type プロパティは、AzureBlobFSLocation に設定する必要があります。 |
Yes |
| fileSystem | Data Lake Storage Gen2 ファイル システム名。 | No |
| folderPath | 指定されたファイル システムの下のフォルダーのパス。 ワイルドカードを使用してフォルダーをフィルター処理する場合は、この設定をスキップし、アクティビティのソース設定で指定します。 | No |
| fileName | 指定された fileSystem + folderPath の下のファイル名。 ワイルドカードを使用してファイルをフィルター処理する場合は、この設定をスキップし、アクティビティのソース設定で指定します。 | No |
Example:
{
"name": "DelimitedTextDataset",
"properties": {
"type": "DelimitedText",
"linkedServiceName": {
"referenceName": "<Data Lake Storage Gen2 linked service name>",
"type": "LinkedServiceReference"
},
"schema": [ < physical schema, optional, auto retrieved during authoring > ],
"typeProperties": {
"location": {
"type": "AzureBlobFSLocation",
"fileSystem": "filesystemname",
"folderPath": "folder/subfolder"
},
"columnDelimiter": ",",
"quoteChar": "\"",
"firstRowAsHeader": true,
"compressionCodec": "gzip"
}
}
}
コピー アクティビティのプロパティ
アクティビティの定義に使用できるセクションとプロパティの一覧については、コピー アクティビティの構成およびパイプラインとアクティビティに関する記事をご覧ください。 このセクションでは、Data Lake Storage Gen2 のソースとシンクでサポートされるプロパティの一覧を示します。
ソースの種類としての Azure Data Lake Storage Gen2
Azure Data Factory では次のファイル形式がサポートされます。 形式ベースの設定については、各記事を参照してください。
ADLS Gen2 からデータをコピーするには、いくつかのオプションがあります。
- データセットに指定されている特定のパスからコピーします。
- フォルダー パスまたはファイル名に対するワイルドカード フィルターについては、
wildcardFolderPathおよびwildcardFileNameを確認してください。 - 特定のテキスト ファイルで定義されているファイルをファイル セットとしてコピーします。
fileListPathを確認してください。
Data Lake Storage Gen2 では、形式ベースのコピー ソースの storeSettings 設定で次のプロパティがサポートされています。
| Property | Description | Required |
|---|---|---|
| 型 |
storeSettings の type プロパティは AzureBlobFSReadSettings に設定する必要があります。 |
Yes |
| コピーするファイルを特定する: | ||
| オプション 1: 静的パス |
データセットに指定されている特定のファイル システムまたはフォルダーかファイル パスからコピーします。 ファイル システムまたはフォルダーからすべてのファイルをコピーする場合は、さらに wildcardFileName として * を指定します。 |
|
| オプション 2: ワイルドカード - ワイルドカードフォルダパス |
ソース フォルダーをフィルター処理するためにデータセットで構成されている、特定のファイル システムの下のワイルドカード文字を含むフォルダーのパス。 使用できるワイルドカーは、 * (ゼロ文字以上の文字に一致) と ? (ゼロ文字または 1 文字に一致) です。実際のフォルダー名にワイルドカードまたはこのエスケープ文字が含まれている場合は、^ を使用してエスケープします。 「フォルダーとファイル フィルターの例」の他の例をご覧ください。 |
No |
| オプション 2: ワイルドカード - ワイルドカードファイル名 |
ソース ファイルをフィルター処理するための、特定のファイル システム + folderPath/wildcardFolderPath の下のワイルドカード文字を含むファイル名。 使用できるワイルドカーは、 * (ゼロ文字以上の文字に一致) と ? (ゼロ文字または 1 文字に一致) です。実際のファイル名にワイルドカードまたはこのエスケープ文字が含まれている場合は、^ を使用してエスケープします。 「フォルダーとファイル フィルターの例」の他の例をご覧ください。 |
Yes |
| オプション 3: ファイルの一覧 - fileListPath |
指定されたファイル セットをコピーすることを示します。 コピーするファイルの一覧を含むテキスト ファイルをポイントします。データセットで構成されているパスへの相対パスであるファイルを 1 行につき 1 つずつ指定します。 このオプションを使用する場合は、データセットにファイル名を指定しないでください。 その他の例については、ファイル リストの例を参照してください。 |
No |
| 追加の設定: | ||
| recursive | データをサブフォルダーから再帰的に読み取るか、指定したフォルダーからのみ読み取るかを指定します。 recursive が true に設定されていて、シンクがファイル ベースのストアである場合、空のフォルダーまたはサブフォルダーはシンクでコピーも作成もされません。 使用可能な値: true (既定値) および false。 fileListPath を構成する場合、このプロパティは適用されません。 |
No |
| deleteFilesAfterCompletion | 宛先ストアに正常に移動した後、バイナリ ファイルをソース ストアから削除するかどうかを示します。 ファイルの削除はファイルごとに行われるためで、コピー アクティビティが失敗した場合、一部のファイルが既に宛先にコピーされソースからは削除されているが、他のファイルはまだソース ストアに残っているという状況が発生します。 このプロパティは、バイナリ ファイルのコピー シナリオでのみ有効です。 既定値: false。 |
No |
| modifiedDatetimeStart | 最終変更日時属性に基づくファイル フィルター。 ファイルは、最終変更日時が modifiedDatetimeStart と同じかそれよりも後であり、modifiedDatetimeEnd よりも前である場合に選択されます。 時刻は "2018-12-01T05:00:00Z" の形式で UTC タイム ゾーンに適用されます。 プロパティは、ファイル属性フィルターをデータセットに適用しないことを意味する NULL にすることができます。 modifiedDatetimeStart に datetime 値を設定し、modifiedDatetimeEnd を NULL にした場合は、最終更新時刻属性が datetime 値以上であるファイルが選択されることを意味します。
modifiedDatetimeEnd に datetime 値を設定し、modifiedDatetimeStart を NULL にした場合は、最終更新時刻属性が datetime 値以下であるファイルが選択されることを意味します。fileListPath を構成する場合、このプロパティは適用されません。 |
No |
| modifiedDatetimeEnd | 上記と同じです。 | No |
| enablePartitionDiscovery | パーティション分割されたファイルの場合は、ファイル パスからパーティションを解析し、他のソース列として追加するかどうかを指定します。 指定できる値は false (既定値) と true です。 |
No |
| partitionRootPath | パーティション検出が有効になっている場合は、パーティション分割されたフォルダーをデータ列として読み取るための絶対ルート パスを指定します。 指定しない場合の既定は、以下のようになります。 - ソース上のデータセットまたはファイルの一覧内のファイル パスを使用する場合、パーティションのルート パスはそのデータセットで構成されているパスです。 - ワイルドカード フォルダー フィルターを使用する場合、パーティションのルート パスは最初のワイルドカードの前のサブパスです。 たとえば、データセット内のパスを "root/folder/year=2020/month=08/day=27" として構成するとします。 - パーティションのルート パスを "root/folder/year=2020" として指定した場合は、コピー アクティビティによって、ファイル内の列とは別に、それぞれ "08" と "27" の値を持つ month と day という 2 つの追加の列が生成されます。- パーティションのルート パスが指定されない場合、追加の列は生成されません。 |
No |
| maxConcurrentConnections | アクティビティの実行中にデータ ストアに対して確立されるコンカレント接続数の上限。 コンカレント接続数を制限する場合にのみ、値を指定します。 | No |
Example:
"activities":[
{
"name": "CopyFromADLSGen2",
"type": "Copy",
"inputs": [
{
"referenceName": "<Delimited text input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "DelimitedTextSource",
"formatSettings":{
"type": "DelimitedTextReadSettings",
"skipLineCount": 10
},
"storeSettings":{
"type": "AzureBlobFSReadSettings",
"recursive": true,
"wildcardFolderPath": "myfolder*A",
"wildcardFileName": "*.csv"
}
},
"sink": {
"type": "<sink type>"
}
}
}
]
シンクの種類としての Azure Data Lake Storage Gen2
Azure Data Factory では次のファイル形式がサポートされます。 形式ベースの設定については、各記事を参照してください。
Data Lake Storage Gen2 では、形式ベースのコピー シンクの storeSettings 設定で次のプロパティがサポートされます。
| Property | Description | Required |
|---|---|---|
| 型 |
storeSettings の type プロパティは AzureBlobFSWriteSettings に設定する必要があります。 |
Yes |
| copyBehavior | ソースがファイル ベースのデータ ストアのファイルの場合は、コピー動作を定義します。 使用できる値は、以下のとおりです。 - PreserveHierarchy (既定値): ファイル階層をターゲット フォルダー内で保持します。 ソース フォルダーへのソース ファイルの相対パスはターゲット フォルダーへのターゲット ファイルの相対パスと同じになります。 - FlattenHierarchy: ソース フォルダーのすべてのファイルがターゲット フォルダーの第一レベルに配置されます。 ターゲット ファイルは、自動生成された名前になります。 - MergeFiles: ソース フォルダーのすべてのファイルを 1 つのファイルにマージします。 ファイル名を指定した場合、マージされたファイル名は指定した名前になります。 それ以外は自動生成されたファイル名になります。 |
No |
| blockSizeInMB | ADLS Gen2 にデータを書き込むために使用するブロック サイズを MB 単位で指定します。 詳細は、ブロック BLOB に関するページを参照してください。 指定できる値は、4 MB から 100 MB です。 既定では、ソース ストアの種類とデータに基づいて、ADF によってブロック サイズが自動的に決定されます。 ADLS Gen2 への非バイナリ コピーの場合、最大約 4.75 TB のデータに収まるように既定のブロック サイズは 100 MB になります。 データが大きくない場合、特にネットワークが不十分なセルフホステッド統合ランタイムを使用すると、操作のタイムアウトやパフォーマンスの問題が発生する場合は、最適ではない可能性があります。 ブロック サイズを明示的に指定できますが、blockSizeInMB*50000 がデータを格納するのに十分な大きさであることを確認します。そうしないと、コピー アクティビティの実行は失敗します。 |
No |
| maxConcurrentConnections | アクティビティの実行中にデータ ストアに対して確立されるコンカレント接続数の上限。 コンカレント接続数を制限する場合にのみ、値を指定します。 | No |
| メタデータ | シンクにコピーするときにカスタム メタデータを設定します。
metadata 配列の各オブジェクトは追加列を表します。
name ではメタデータ キー名を定義し、value では、そのキーのデータ値を指定します。
属性の保持機能が使用されている場合は、ソース ファイルのメタデータを使用して、指定されたメタデータの和集合の作成や上書きが行われます。使用できるデータ値: - $$LASTMODIFIED: 予約済みの変数によって、ソース ファイルの最終更新時刻を格納することを指定します。 バイナリ形式のファイルベースのソースにのみ適用されます。- 式 - 静的な値 |
No |
Example:
"activities":[
{
"name": "CopyToADLSGen2",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<Parquet output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "ParquetSink",
"storeSettings":{
"type": "AzureBlobFSWriteSettings",
"copyBehavior": "PreserveHierarchy",
"metadata": [
{
"name": "testKey1",
"value": "value1"
},
{
"name": "testKey2",
"value": "value2"
},
{
"name": "lastModifiedKey",
"value": "$$LASTMODIFIED"
}
]
}
}
}
}
]
フォルダーとファイル フィルターの例
このセクションでは、ワイルドカード フィルターを使用した結果のフォルダーのパスとファイル名の動作について説明します。
| folderPath | fileName | recursive | ソースのフォルダー構造とフィルターの結果 (太字のファイルが取得されます) |
|---|---|---|---|
Folder* |
(空、既定値を使用) | false | FolderA File1.csv File2.json Subfolder1 File3.csv File4.json File5.csv AnotherFolderB File6.csv |
Folder* |
(空、既定値を使用) | true | FolderA File1.csv File2.json Subfolder1 File3.csv File4.json File5.csv AnotherFolderB File6.csv |
Folder* |
*.csv |
false | FolderA File1.csv File2.json Subfolder1 File3.csv File4.json File5.csv AnotherFolderB File6.csv |
Folder* |
*.csv |
true | FolderA File1.csv File2.json Subfolder1 File3.csv File4.json File5.csv AnotherFolderB File6.csv |
ファイル リストの例
このセクションでは、コピー アクティビティのソースでファイル リスト パスを使用した結果の動作について説明します。
次のソース フォルダー構造があり、太字のファイルをコピーするとします。
| サンプルのソース構造 | FileListToCopy.txt のコンテンツ | ADF の構成 |
|---|---|---|
| filesystem FolderA File1.csv File2.json Subfolder1 File3.csv File4.json File5.csv Metadata FileListToCopy.txt |
File1.csv Subfolder1/File3.csv Subfolder1/File5.csv |
データセット内: - ファイル システム: filesystem- フォルダー パス: FolderAコピー アクティビティ ソース内: - ファイル リストのパス: filesystem/Metadata/FileListToCopy.txt ファイル リストのパスは、コピーするファイルの一覧を含む同じデータ ストア内のテキスト ファイルをポイントします。データセットで構成されているパスへの相対パスで 1 行につき 1 つのファイルを指定します。 |
recursive と copyBehavior の例
このセクションでは、recursive 値と copyBehavior 値のさまざまな組み合わせでのコピー操作の動作について説明します。
| recursive | copyBehavior | ソースのフォルダー構造 | ターゲットの結果 |
|---|---|---|---|
| true | preserveHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
ターゲット Folder1 は、ソースと同じ構造で作成されます。 Folder1 File1 File2 Subfolder1 File3 File4 File5 |
| true | flattenHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
ターゲットの Folder1 は、次の構造で作成されます。 Folder1 File1 の自動生成された名前 File2 の自動生成された名前 File3 の自動生成された名前 File4 の自動生成された名前 File5 の自動生成された名前 |
| true | mergeFiles | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
ターゲットの Folder1 は、次の構造で作成されます。 Folder1 File1、File2、File3、File4、File5 の内容は 1 つのファイルにマージされて、自動生成されたファイル名が付けられます。 |
| false | preserveHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
ターゲットの Folder1 は、次の構造で作成されます。 Folder1 File1 File2 File3、File4、File5 を含む Subfolder1 は取得されません。 |
| false | flattenHierarchy | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
ターゲットの Folder1 は、次の構造で作成されます。 Folder1 File1 の自動生成された名前 File2 の自動生成された名前 File3、File4、File5 を含む Subfolder1 は取得されません。 |
| false | mergeFiles | Folder1 File1 File2 Subfolder1 File3 File4 File5 |
ターゲットの Folder1 は、次の構造で作成されます。 Folder1 File1、File2 の内容は 1 つのファイルにマージされ、自動生成されたファイル名が付けられます。 File1 の自動生成された名前 File3、File4、File5 を含む Subfolder1 は取得されません。 |
コピー中にメタデータを保持する
Amazon S3、Azure Blob、Azure Data Lake Storage Gen2 から Azure Data Lake Storage Gen2、Azure Blob にファイルをコピーする場合、ファイルのメタデータをデータと共に保持することもできます。 詳細については、メタデータの保存に関する記事を参照してください。
Data Lake Storage Gen1/Gen2 の ACL を保持する
Azure Data Lake Storage Gen1/Gen2 から Gen2 にファイルをコピーするときに、データと共に POSIX アクセス制御リスト (ACL) を保持することもできます。 詳細については、Data Lake Storage Gen1/Gen2 から Gen2 への ACL の保持に関するページをご覧ください。
Tip
Azure Data Lake Storage Gen1 から Gen2 への一般的なデータ コピーに関するチュートリアルとベスト プラクティスについては、Azure Data Lake Storage Gen1 から Gen2 へのデータのコピーに関する記事を参照してください。
Mapping Data Flow のプロパティ
マッピング データ フローでデータを変換するときには、Azure Data Lake Storage Gen2 にある次の形式のファイルの読み取りと書き込みが可能です。
形式固有の設定は、各形式のドキュメントに記載されています。 詳細については、「マッピング データ フローのソース変換」および「マッピング データ フローでのシンク変換」を参照してください。
ソース変換
ソース変換では、Azure Data Lake Storage Gen2 内のコンテナー、フォルダー、または個々のファイルから読み取ることができます。 [Source options]\(ソース オプション\) タブで、ファイルの読み取り方法を管理できます。
[Wildcard path](ワイルドカード パス): ワイルドカード パターンを使用すると、ADF は単一のソース変換で一致するフォルダーとファイルを順に処理します。 これは、単一のフロー内の複数のファイルを処理するのに効果的な方法です。 既存のワイルドカード パターンをポイントしたときに表示される + 記号を使って複数のワイルドカード一致パターンを追加します。
ソース コンテナーから、パターンに一致する一連のファイルを選択します。 データセット内で指定できるのはコンテナーのみです。 そのため、ワイルドカード パスには、ルート フォルダーからのフォルダー パスも含める必要があります。
ワイルドカードの例:
*- 任意の文字セットを表します。**- ディレクトリの再帰的な入れ子を表します。?- 1 文字を置き換えます。[]- 角カッコ内の文字のいずれか 1 つと一致します。/data/sales/**/*.csv- /data/sales の下のすべての csv ファイルを取得します。/data/sales/20??/**/- 20 世紀のすべてのファイルを取得します。/data/sales/*/*/*.csv- /data/sales の 2 レベル下の csv ファイルを取得します。/data/sales/2004/*/12/[XY]1?.csv- 前に 2 桁の数字が付いた X または Y で始まる、2004 年 12 月のすべての csv ファイルを取得します。
Partition root path: ファイル ソース内のフォルダーを key=value 形式 (例えば year=2019) で分割している場合、その分割フォルダー ツリーの最上位をデータ フローのデータ ストリームの列名に割り当てることができます。
最初に、ワイルドカードを設定して、パーティション分割されたフォルダーと読み取るリーフ ファイルのすべてのパスを含めます。
パーティションのルート パス設定を使用して、フォルダー構造の最上位レベルを定義します。 データ プレビューを使用してデータの内容を表示すると、ADF によって、各フォルダー レベルで見つかった解決済みのパーティションが追加されることがわかります。
[List of files](ファイルの一覧): これはファイル セットです。 処理する相対パス ファイルの一覧を含むテキスト ファイルを作成します。 このテキスト ファイルをポイントします。
[Column to store file name](ファイル名を格納する列): ソース ファイルの名前をデータの列に格納します。 ファイル名文字列を格納するための新しい列名をここに入力します。
[After completion](完了後): データ フローの実行後に、ソース ファイルをそのままにするか、削除するか、移動するかを選択できます。 移動のパスは相対パスです。
後処理でソース ファイルを別の場所に移動するには、まず、ファイル操作の "移動" を選択します。 次に、"移動元" ディレクトリを設定します。 パスにワイルドカードを使用していない場合、"移動元" 設定はソース フォルダーと同じフォルダーになります。
ワイルドカードを含むソース パスがある場合、構文は次のようになります。
/data/sales/20??/**/*.csv
"移動元" は次のように指定できます。
/data/sales
"移動先" は次のように指定できます。
/backup/priorSales
この場合、ソースとして指定された /data/sales の下のすべてのファイルは /backup/priorSales に移動されます。
Note
ファイル操作は、パイプライン内のデータ フローの実行アクティビティを使用するパイプライン実行 (パイプラインのデバッグまたは実行) からデータ フローを開始する場合にのみ実行されます。 Data Flow デバッグ モードでは、ファイル操作は実行されません。
[Filter by last modified](最終更新日時でフィルター処理): 最終更新日時の範囲を指定することで、処理するファイルをフィルター処理できます。 日時はすべて UTC 形式です。
[Enable change data capture](変更データ キャプチャを有効にする): これが trueの場合、最後に実行したファイルからのみ新規または変更されたファイルを取得します。 最初の実行時には必ず完全なスナップショット データが読み込まれ、次の実行時には新規または変更されたファイルのみが読み込まれます。 詳細については、「変更データ キャプチャ」を参照してください。
シンクのプロパティ
シンク変換では、Azure Data Lake Storage Gen2 内のコンテナーまたはフォルダーに書き込むことができます。 [設定] タブで、ファイルへの書き込み方法を管理できます。
[Clear the folder](フォルダーのクリア): データが書き込まれる前に、書き込み先のフォルダーをクリアするかどうかを決定します。
[File name option](ファイル名のオプション): 書き込み先のフォルダー内の書き込み先ファイルの命名方法を決定します。 ファイル名のオプションを次に示します。
- [Default](既定値): Spark は PART の既定値に基づいて、ファイルに名前を付けることができます。
- [Pattern](パターン): パーティションごとに出力ファイルを列挙するパターンを入力します。 たとえば、loans[n].csv と入力すると、loans1.csv、loans2.csv のように作成されます。
- [Per partition](パーティションあたり):パーティションごとに 1 つのファイル名を入力します。
- [As data in column](列内のデータとして):出力ファイルを列の値に設定します。 パスは、書き込み先フォルダーではなく、データセット コンテナーからの相対パスです。 データセット内にフォルダー パスがある場合は、上書きされます。
- [Output to a single file](1 つのファイルに出力する): パーティション分割された出力ファイルを単一の名前付きファイルに結合します。 パスは、データセット フォルダーからの相対パスです。 マージ操作は、ノード サイズによっては失敗する可能性があることに注意してください。 このオプションは、大規模なデータセットに対しては推奨されません。
[Quote all](すべてを引用符で囲む): すべての値を引用符で囲むかどうかを決定します
umask
必要に応じて、POSIX の読み取り、書き込み、所有者、ユーザー、およびグループの実行フラグを使用して、ファイルの umask を設定できます。
前処理および後処理コマンド
必要に応じて、ADLS Gen2 シンクへの書き込み前または書き込み後に、Hadoop ファイルシステム コマンドを実行できます。 次のコマンドがサポートされています。
cpmvrmmkdir
Examples:
mkdir /folder1mkdir -p folder1mv /folder1/*.* /folder2/cp /folder1/file1.txt /folder2rm -r /folder1
式ビルダーを介して、パラメーターもサポートされています。次に例を示します。
mkdir -p {$tempPath}/commands/c1/c2
mv {$tempPath}/commands/*.* {$tempPath}/commands/c1/c2
既定では、フォルダーは user/root として作成されます。 "/" を使用して最上位のコンテナーを参照します。
Lookup アクティビティのプロパティ
プロパティの詳細については、Lookup アクティビティに関するページを参照してください。
GetMetadata アクティビティのプロパティ
プロパティの詳細については、GetMetadata アクティビティに関するページを参照してください。
Delete アクティビティのプロパティ
プロパティの詳細については、Delete アクティビティに関するページを参照してください。
レガシ モデル
Note
次のモデルは、下位互換性のために引き続きそのままサポートされます。 前のセクションで説明した新しいモデルを使用することをお勧めします。ADF オーサリング UI が新しいモデルの生成に切り替わりました。
レガシ データセット モデル
| Property | Description | Required |
|---|---|---|
| 型 | データセットの type プロパティは、AzureBlobFSFile に設定する必要があります。 | Yes |
| folderPath | Data Lake Storage Gen2 のフォルダーのパス。 指定しないと、ルートが参照されます。 ワイルドカード フィルターがサポートされています。 使用できるワイルドカードは、 * (ゼロ文字以上の文字に一致) と ? (ゼロ文字または 1 文字に一致) です。 実際のフォルダー名にワイルドカードまたはこのエスケープ文字が含まれている場合は、^ を使用してエスケープします。 例: filesystem/folder/. 「フォルダーとファイル フィルターの例」の他の例をご覧ください。 |
No |
| fileName | 指定された "folderPath" の下にあるファイルの名前またはワイルドカード フィルター。 このプロパティの値を指定しない場合、データセットはフォルダー内のすべてのファイルをポイントします。 フィルターに使用できるワイルドカードは、 * (ゼロ文字以上の文字に一致) と ? (ゼロ文字または 1 文字に一致) です。- 例 1: "fileName": "*.csv"- 例 2: "fileName": "???20180427.txt"実際のファイル名にワイルドカードまたはこのエスケープ文字が含まれている場合は、 ^ を使用してエスケープします。出力データセットに fileName の指定がなく、アクティビティ シンクに preserveHierarchy の指定がない場合、コピー アクティビティは、"Data.[activity run ID GUID].[GUID if FlattenHierarchy].[format if configured].[compression if configured] " というパターンでファイル名が自動的に生成されます (例: "Data.0a405f8a-93ff-4c6f-b3be-f69616f1df7a.txt.gz")。 クエリの代わりにテーブル名を使用して表形式のソースからコピーする場合、名前のパターンは "[table name].[format].[compression if configured]" になります (例: "MyTable.csv")。 |
No |
| modifiedDatetimeStart | 最終変更日時属性に基づくファイル フィルター。 ファイルは、最終変更日時が modifiedDatetimeStart と同じかそれよりも後であり、modifiedDatetimeEnd よりも前である場合に選択されます。 時刻は "2018-12-01T05:00:00Z" の形式で UTC タイム ゾーンに適用されます。 大量のファイルでファイル フィルターを実行する場合、この設定を有効にすることで、データ移動の全体的なパフォーマンスが影響を受けます。 各プロパティには NULL を指定できます。これは、ファイル属性フィルターをデータセットに適用しないことを意味します。 modifiedDatetimeStart に datetime 値が設定されており、modifiedDatetimeEnd が NULL の場合は、最終変更日時属性が datetime 値以上であるファイルが選択されます。
modifiedDatetimeEnd に datetime 値が設定されており、modifiedDatetimeStart が NULL の場合は、最終変更日時属性が datetime 値以下であるファイルが選択されます。 |
No |
| modifiedDatetimeEnd | 最終変更日時属性に基づくファイル フィルター。 ファイルは、最終変更日時が modifiedDatetimeStart と同じかそれよりも後であり、modifiedDatetimeEnd よりも前である場合に選択されます。 時刻は "2018-12-01T05:00:00Z" の形式で UTC タイム ゾーンに適用されます。 大量のファイルでファイル フィルターを実行する場合、この設定を有効にすることで、データ移動の全体的なパフォーマンスが影響を受けます。 各プロパティには NULL を指定できます。これは、ファイル属性フィルターをデータセットに適用しないことを意味します。 modifiedDatetimeStart に datetime 値が設定されており、modifiedDatetimeEnd が NULL の場合は、最終変更日時属性が datetime 値以上であるファイルが選択されます。
modifiedDatetimeEnd に datetime 値が設定されており、modifiedDatetimeStart が NULL の場合は、最終変更日時属性が datetime 値以下であるファイルが選択されます。 |
No |
| format | ファイルベースのストア間でファイルをそのままコピー (バイナリ コピー) する場合は、入力と出力の両方のデータセット定義で format セクションをスキップします。 ファイルを特定の形式で解析するか生成する場合、次のファイル形式がサポートされます。TextFormat、JsonFormat、AvroFormat、OrcFormat、ParquetFormat。 format の type プロパティをいずれかの値に設定します。 詳細については、「テキスト形式」、「JSON 形式」、「AVRO 形式」、「ORC 形式」、Parquet 形式」の各セクションをご覧ください。 |
いいえ (バイナリ コピー シナリオのみ) |
| 圧縮 | データの圧縮の種類とレベルを指定します。 詳細については、サポートされるファイル形式と圧縮コーデックに関する記事を参照してください。 サポートされる種類は、 **GZip**, **Deflate**, **BZip2**, and **ZipDeflate** です。サポートされるレベルは、Optimal と Fastest です。 |
No |
Tip
フォルダーの下のすべてのファイルをコピーするには、folderPath のみを指定します。
特定の名前の単一のファイルをコピーするには、フォルダー部分で folderPath、ファイル名で fileName を指定します。
フォルダーの下のファイルのサブセットをコピーするには、フォルダー部分で folderPath、ワイルドカード フィルターで fileName を指定します。
Example:
{
"name": "ADLSGen2Dataset",
"properties": {
"type": "AzureBlobFSFile",
"linkedServiceName": {
"referenceName": "<Azure Data Lake Storage Gen2 linked service name>",
"type": "LinkedServiceReference"
},
"typeProperties": {
"folderPath": "myfilesystem/myfolder",
"fileName": "*",
"modifiedDatetimeStart": "2018-12-01T05:00:00Z",
"modifiedDatetimeEnd": "2018-12-01T06:00:00Z",
"format": {
"type": "TextFormat",
"columnDelimiter": ",",
"rowDelimiter": "\n"
},
"compression": {
"type": "GZip",
"level": "Optimal"
}
}
}
}
レガシ コピー アクティビティ ソース モデル
| Property | Description | Required |
|---|---|---|
| 型 | コピー アクティビティのソースの type プロパティは AzureBlobFSSource に設定する必要があります。 | Yes |
| recursive | データをサブフォルダーから再帰的に読み取るか、指定したフォルダーからのみ読み取るかを指定します。 recursive が true に設定されていて、シンクがファイル ベースのストアである場合、空のフォルダーまたはサブフォルダーはシンクでコピーも作成もされません。 使用可能な値: true (既定値) および false。 |
No |
| maxConcurrentConnections | アクティビティの実行中にデータ ストアに対して確立されるコンカレント接続数の上限。 コンカレント接続数を制限する場合にのみ、値を指定します。 | No |
Example:
"activities":[
{
"name": "CopyFromADLSGen2",
"type": "Copy",
"inputs": [
{
"referenceName": "<ADLS Gen2 input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "AzureBlobFSSource",
"recursive": true
},
"sink": {
"type": "<sink type>"
}
}
}
]
レガシ コピー アクティビティ シンク モデル
| Property | Description | Required |
|---|---|---|
| 型 | コピー アクティビティのシンクの type プロパティは AzureBlobFSSink に設定する必要があります。 | Yes |
| copyBehavior | ソースがファイル ベースのデータ ストアのファイルの場合は、コピー動作を定義します。 使用できる値は、以下のとおりです。 - PreserveHierarchy (既定値): ファイル階層をターゲット フォルダー内で保持します。 ソース フォルダーへのソース ファイルの相対パスはターゲット フォルダーへのターゲット ファイルの相対パスと同じになります。 - FlattenHierarchy: ソース フォルダーのすべてのファイルがターゲット フォルダーの第一レベルに配置されます。 ターゲット ファイルは、自動生成された名前になります。 - MergeFiles: ソース フォルダーのすべてのファイルを 1 つのファイルにマージします。 ファイル名を指定した場合、マージされたファイル名は指定した名前になります。 それ以外は自動生成されたファイル名になります。 |
No |
| maxConcurrentConnections | アクティビティの実行中にデータ ストアに対して確立されるコンカレント接続数の上限。 コンカレント接続数を制限する場合にのみ、値を指定します。 | No |
Example:
"activities":[
{
"name": "CopyToADLSGen2",
"type": "Copy",
"inputs": [
{
"referenceName": "<input dataset name>",
"type": "DatasetReference"
}
],
"outputs": [
{
"referenceName": "<ADLS Gen2 output dataset name>",
"type": "DatasetReference"
}
],
"typeProperties": {
"source": {
"type": "<source type>"
},
"sink": {
"type": "AzureBlobFSSink",
"copyBehavior": "PreserveHierarchy"
}
}
}
]
変更データ キャプチャ
Azure Data Factory は、マッピング データ フローのソース変換で変更データ キャプチャを有効にする を有効にすることで、Azure Data Lake Storage Gen2 からのみ新規または変更されたファイルを取得できます。 このコネクタ オプションを使用すると、変換されたデータを選択した変換先データセットに読み込む前に、新しいファイルまたは更新されたファイルのみを読み取り、変換を適用できます。
最後の実行からチェックポイントを常に記録して、そこから変更を取得できるよう、パイプラインとアクティビティ名は変更しないでください。 パイプライン名またはアクティビティ名を変更すると、チェックポイントがリセットされ、次の実行は最初から開始されます。
パイプラインをデバッグする場合は、変更データ キャプチャを有効にする も同様に機能します。 デバッグ実行中にブラウザーを更新すると、チェックポイントがリセットされます。 デバッグ実行の結果に問題がなければ、パイプラインを発行してトリガーできます。 デバッグ実行によって記録された以前のチェックポイントに関係なく、常に先頭から開始されます。
[モニター] セクションでは、常にパイプラインを再実行できます。 そうすると、選択したパイプライン実行のチェックポイント レコードから常に変更点が取得されます。
関連コンテンツ
コピー アクティビティによってソースおよびシンクとしてサポートされるデータ ストアの一覧については、サポートされるデータ ストアに関するセクションを参照してください。