##SalesforceにBULK APIの概要について、以下の紹介があります。
Bulk API は、REST 規則に基づいており、大規模データセットの読み込みまたは削除用に最適化されています。Bulk API を使用して複数のバッチを送信することにより、多数のレコードを非同期でクエリ、queryAll、挿入、更新、更新/挿入または削除できます。バッチはバックグラウンドで処理されます。
ただし、パラレルで複数のバッチを組込む場合、データにより、レコードロックが発生する場合があります。またはデータロードとsalesforce内のその他の自動化処理と合せてレコードロックが発生する場合もありますので、
今回、レコードロックが発生しやすいパターンとその場合の解決案を検討します。
####◆主従関係Master-Detail Relationships
・Salesforce仕組：Detailレコードを登録する時、Salesforce上そのDetailに対応するMasterレコードが自動的にロックされる。
・ロックエラー発生例：パラレルで異なるバッチに同一Master IDを持っているDetailレコードを同時に登録する場合、ロックエラー発生のリスクが高いです。
・回避方法：①同一Master IDを持っているDetailレコードが同一バッチ内に実行するようにする。
②MasterレコードのIDでデータロードの実行順をソートする。
####◆積み上げ集計項目Roll-up Summary Fields
・Salesforce仕組：Master-Detailの中、Masterレコードに積み上げ集計項目ある場合、Detailレコードが更新する度に、積み上げ集計項目をリフレッシュして更新するために、Salesforce上そのDetailに対応するMasterレコードが自動的にロックされる。
・ロックエラー発生例：パラレルで異なるバッチに同一Master IDを持っているDetailレコードを同時に登録する場合、ロックエラー発生のリスクが高いです。
・回避方法：①同一Master IDを持っているDetailレコードが同一バッチ内に実行するようにする。
②MasterレコードのIDでデータロードの実行順をソートする。
③積み上げ集計項目をレポートに抽出する。
####◆参照関係Lookup Relationships
・Salesforce仕組：参照関係を持っている子レコードを登録する時、Salesforce上その子に対応する親レコードが自動的にロックされる。
・ロックエラー発生例：パラレルで異なるバッチに同一親IDを持っている子レコードを同時に登録する場合、ロックエラー発生のリスクが高いです。
・回避方法：①同一親IDを持っている子レコードが同一バッチ内に実行するようにする。
②参照項目が必須ではない場合、
「参照レコードが削除される場合の対処方法」について、
「参照関係に含まれる参照レコードは削除できません」を設定しなくて、
「この項目をクリアします」を設定する。この方法はバッチの実行時間が短縮できる。
####◆トリガーTriggers
・Salesforce仕組：レコードをロードする時、トリガーがある場合、トリガーを発火できる。
・ロックエラー発生例：バッチを実行して、更新処理があるトリガーを発火させて、ロックエラー発生のリスクが高いです。
・回避方法：①データロードするユーザに対し、トリガーを発火させないように設定する。
②データロードする場合、トリガーを実行しないように処理を追加する。
####◆ワークフローWorkflow Rules
・Salesforce仕組：トリガーと同様
・ロックエラー発生例：トリガーと同様
・回避方法：データロードする間、ワークフローを実施しないように設定する。
####◆グループメンバーGroup Membership Locks
①グループメンバー（ユーザオブジェクトとか）は、ロックエラーの発生確率を次の方法で下げることができます。
・各グループメンテナンスプロセスが重ならないように慎重にスケジュールする
・インテグレーションやその他の自動化されたグループメンテナンスプロセスに再試行ロジックを実装して、エラーから回復してロックを取得できるようにする
②データロードで以下の場合、シリアルプロセスでデータロードする必要があります。
・ユーザを登録し、そのユーザをロールに割り当てる場合
・ユーザのロールを変更する場合
・ロールの階層、又はテリトリー階層を変更する場合
・ロール階層の構成、又はテリトリー階層の構成を変更する場合
・public／personalグループ、ロール、テリトリー、キューにメンバを追加／削除する場合
・Accountの所有者を変更する、その所有者が１つ以上のコミュニティロール、又はポータルロールが関連している場合
####◆バッチの重複実行Overlapping Runs
・回避方法：データロードバーチの実行は他のバッチと重複にならないようにスケジュールする。
####◆SURPRISE
Degree of Parallelism
Degree of Parallelismについて、以下の計算式となります。
・Work Completed:（シリアルで１つのバッチの実行時間 * バッチ数）時間
・Run Time:業務上にデータロードバッチの実行必要な最大時間、又はパラレルで実際のバッチ実施時間
※実行時間に対し制限がある場合
・Degree of Parallelism:パラレルで設定する必要なバッチ数
『Degree of Parallelism』の使用用途は以下の考えがあります：
業務上にデータロードバッチの実行時間について、制限がある場合、
制限の時間内にパラレルで一回どれぐらいのバッチ数を取組む必要かは上記の計算式で推測できて、
されに、一回に処理する必要なデータ量もシミュレーションできて、サーバにより、処理可能であるかどうかもシミュレーションできると思います。
Throughput
Throughputについて、以下の計算式となります。
・Records Loaded:処理必要なデータ量
・Run Time:業務上にデータロードバッチの実行必要な最大時間、又はパラレルで実際のバッチ実施時間
バッチ実行結果分析は以下のイメージ
参考リンク：
・グループメンバーシップのロック
・Maximizing Parallelism and Throughput Performance