不知不觉中，大家已经陪伴DataPipeline走过了3年时间。在这期间，得益于客户们的积极反馈和沟通，我们总结了一些日常工作中比较常见的问题，并基于这些问题进行了总结。
为避免突兀，我们会先从比较基础且通用的问题开始，进而陆续放出一些稍加复杂的问答，希望大家在接下来的日子里持续关注我们的更新~
Q1: DataPipeline支持的读取方式
A：DataPipeline在成立之初只有一种模式，只支持实时流同步，在我们看来这是未来的一种趋势。
但在后来发现，很多客户实际上有批量同步的需求。比如，银行在每天晚上可能会有一些月结、日结，证券公司也有类似的结算服务。基于一些历史原因，或出于对性能、数据库配置的考虑，可能有的数据库本身不能开change log。所以实际上并不是所有情况下都能从源端获取实时的流数据。
考虑到上述问题，我们认为一个产品在支撑数据融合过程中，必须能同时支撑批量和流式两种处理模式，且在产品里面出于性能和稳定性考虑提供不同的处理策略，这才是一个相对来说比较合理的基础架构。
详情参见：DataPipeline CTO陈肃：构建批流一体数据融合平台的一致性语义保证
Q2：目标端的连接方式是什么
A：对于关系型数据库，写入方式为JDBC，未来版本将通过文件加载的方式提高吞吐率。其它类型的目的地，根据具体类型各不相同。例如FTP目的地用的是FTP Client，Kafka目的地用的是Kafka Producer。
Q3：采集和写入能否对数据进行加密
A：如果是要对数据内容加密可以使用高级清洗。
Q4：DataPipeline安装部署模式
A：DataPipeline 产品是采用Docker容器的部署方式，支持Docker集群；支持虚拟环境（VMW）部署，但不推荐，DataPipeline正在研发支持非Docker部署。
Q5：DataPipeline是否支持图形化监控
A：DataPipeline支持读写速率、数据量、任务进度、错误队列、操作记录、表结构等图形化监控。
Q6：数据库日志保留策略多久合适
A：如，MySQL Binlog保留策略，建议保留日志策略>=3天。
Q7: 后续增量导入数据如何保证一致性
A：DataPipeline默认支持at least once同步机制，保证数据不会在同步过程中丢失。这适合源端有主键、目的地有主键去重能力的场景，例如关系型数据库到关系型数据库的同步。
如果类似Hive这样没有主键去重能力的目的地，DataPipeline支持开启任务级别的端到端一致性选项，通过多阶段提交协议来保证数据一致性。
Q8：监控报警一般在项目上如何使用
A：DataPipeline的数据任务有监控看板和报警两种方式，报警会发送到指定的邮箱，根据错误类型，可以选择重启或通知技术支持，DataPipeline会有工程师协助客户排查错误。
Q9：是否方便扩容
A：DataPipeline支持动态扩容，当集群资源紧张时，无需暂停现有任务，增加新节点后，即可以实现集群的扩容。
Q10：如果一条数据多次、频繁变化，DataPipeline如何保证数据的并行和顺序？
A：DataPipeline源端会将任务按照一定原则拆分为多个互不干扰的子任务进行并行执行。例如：在JDBC源读取场景下，如果任务包括多张表，每个表是由一个独立线程进行顺序读取的，线程并行度可以在任务属性中进行设置。
为了保证顺序写入和读取，默认每个单独子任务会创建一个独立的topic，设置一个分区，这样目标端消费的时候，同一个topic只有一个consumer在进行消费，从而保证消费的顺序性。如果可以接受非顺序消费，也可以为一个topic创建多个分区，这样目的端可以更好地利用Kafka的并行能力提高吞吐量。
本篇集中介绍了10种问题答疑，如果你在工作中遇到了类似的问题，或者对一些答疑心存疑惑，欢迎与我们交流。
