いくつかの製品の繰り返しを経て、昨年のDataPipelineで、一週間の時間より短い2020年。最新バージョン2.6が関係している上では、使用シナリオ、それが何をしている知っていますか？次へ次は、私たちは、これらのシナリオが発生する可能性があることを期待を暗唱としてあなたに懸念います。
シーンワン：シーン生産データ構造の頻繁な変更への対応
1.シーン記述
本番データを同期すると、ビジネス関係するので、ソーステーブルの削除、フィールド条件の変化があることが多いです。私たちは、あなたがこのケースでタスクを同期し続けることを願って。ソースフィールドに変更した場合や、宛先端末は、設定に応じてフィールドを増加または減少の相同性するかどうかを選択できます。
0002該当シーン
送信元/送信先：リレーショナルデータベース
モードを読む：いいえ制限
3.手順
-
DataPipelineバージョンを制限することなく
-
DataPipelineタスクの設定の下の[詳細オプション]の下で、データの送信先がデータソースの変更[セット]オプションが提供され、あなたが応じてヒントを選択することができます
シーン2：タスクはジェンキンスタスクのデータを呼び出した後、
1.シーン記述
データ同期タスクは、完了したタスクは、ジェンキンスさんがすぐに開始定義されています。実行、および依存関係の順序を保証します。
0002該当シーン
送信元/送信先：従来のデータベース（他のスクリプトが必要です）
読み出しモード：バルクの総量または増分識別フィールド
3.手順
- タスク・フロー・ストリーム内のタスクを作成しますDataPipeline
- タイミングデータ同期タスクを作成します
- サーバーIP、書き込みPythonスクリプトを追加し、指定したディレクトリ・サーバーに置かれ、リモートコマンドの実行を[追加]
- 詳細については、営業担当者と通信してくださいDataPipeline
シーン3：テスト用に生産データの同期
1.シーン記述
mysql-> MySQLのリアルタイム同期、同期中に、グループは、テストプロセスでテスト先のタスクでのいくつかのテーブルのための試験を実施し、宛先がINSERT / UPDATE / DELETE操作になりたいことがあります。テストはいくつかのテーブルが自動化された方法で同期されている一時停止するスクリプトを実行する前に、私たちは願っています。再同期するいくつかのテーブルにテストスクリプトの終了後に自動化された方法で実行され、先のデータは、オンラインデータ（必要性はすべてクリーンアップすることを実験により生成されたダーティ・データ）と一致している必要があります。
0002該当シーン
送信元/送信先：リレーショナルデータベース先
読み出しモード：制限なし（[クリア目標関数テーブルデータに許可、前バッチ同期を実行]総量/増分識別フィールドパターンはタイミングが毎回開く必要があります）
3.手順
-
要件DataPipelineバージョン> = 2.6.0
-
宛先表テストの前に、DataPipeline設けられたスクリプトを実行します
-
目的地结束测试后，再执行脚本添加测试表
-
启动脚本，对测试的几张表进行重新同步，保证测试后的数据可以和线上数据继续保持一致
-
参考DataPipeline swagger接口列表，目前已有脚本模板可供参考
场景四：Hive->GP列存储同步速率提高方案
1. 场景说明
Hive->GP，如果GP目的地表为手动创建的列存储表，那么在DataPipeline上同步时速率会非常慢。这是因为GP列存储本身存在的限制。而目的地若为DataPipeline创建的行表，再通过脚本将行表转换为列表，则效率提高几十倍。
2. 场景适用说明
源/目的地：Hive源/GP目的地
读取模式：增量/全量
3. 操作步骤
-
目的地表为DataPipeline自动创建的行表
-
编写脚本将行表转换为列表
-
数据任务同步完成后，通过DataPipeline任务流调用行转列脚本
-
再将列表数据提供给下游使用
场景五：对数据进行加密脱敏处理场景
1. 场景说明
因为涉及用户隐私或其它安全原因，需要对数据部分字段进行脱敏或加密处理。通过DataPipeline的高级清洗功能可以完全满足此类场景。
2. 场景适用说明
源/目的地：不限制
读取模式：不限制
3. 操作步骤
-
不限制DataPipeline版本
-
正常配置任务即可，只需开启高级清洗功能
-
将已写好的加密代码或脱敏代码打成jar包，上传到服务器执行目录下，直接调用即可
-
高级清洗代码可联系DataPipeline提供模板
注意事项：所写的jar包需要分别上传webservice、sink、manager所在容器的服务器的/root/datapipeline/code_engine_lib（一般默认）目录。
场景六：通过错误队列，明确上下游数据问题责任及原因
1. 场景说明
作为数据部门，需要接收上游数据，并根据下游部门需求将数据传输给对应部门。因此当存在脏数据或者数据问题时，有时很难定位问题原因，划分责任。
并且大多时候都是将脏数据直接丢弃，上游无法追踪脏数据产生的原因。通过DP的高级清洗功能可自定义将不符合的数据放入错误队列中。
2. 场景适用说明
源/目的地：不限制
读取模式：不限制
3. 操作步骤
- 不限制DataPipeline版本
- 正常配置任务即可，只需开启高级清洗功能
- 在高级清洗中对对应字段根据业务进行逻辑判断，将不想要的数据扔到DP错误队列中
- 高级清洗代码可联系DataPipeline提供模板
场景七：更便捷地支持目的地手动增加字段
1. 场景说明
由Oracle->SQLServer，想在目的地手动添加一列TIMESTAMP类型，自动赋予默认值，记录数据INSERT时间。
2. 场景适用说明
源/目的地：关系型数据库目的地
读取模式：不限制
3. 操作步骤
-
要求DataPipeline版本>=2.6.0
-
在DataPipeline映射页面配置时，添加一列，字段名称和目的地手动添加名称一致（标度类型任意给，无需一致）勾选该字段蓝色按钮（开启表示同步该字段数据，关闭表示该字段不传任何数据），点击保存。如下图所示
-
手动在目的地添加该列
本篇将集中介绍以上7种场景，其它应用场景将会在下周发布，如果你在工作中遇到了同样的问题，欢迎与我们交流。