数据采集的设计，几乎完全取决于数据源的特性，毕竟数据源是整个大数据平台蓄水的上游，数据采集不过是获取水源的管道罢了。
在数据仓库的语境下，ETL基本上就是数据采集的代表，包括数据的提取（Extract)、转换(Transform)和加载(Load)。在转换的过程中，需要针对具体的业务场景对数据进行治理，例如进行非法数据监测与过滤、格式转换与数据规范化、数据替换、保证数据完整性等。
但是在大数据平台下，由于数据源具有更复杂的多样性，数据采集的形式也变得更加复杂而多样，当然，业务场景也可能变得迥然不同。下图展现了大数据平台比较典型的数据采集架构：
以下是几种比较典型的业务场景。
场景1：为了提升业务处理的性能，同时又希望保留历史数据以备数据挖掘与分析。
业务处理场景访问的数据库往往是RDB，可伸缩性较差，又需要满足查询与其他数据操作的实时性，这就需要定期将超过时间期限的历史数据执行清除。但是在大数据场景下，这些看似无用的历史数据又可能是能够炼成黄金的沙砾。因而需要实时将RDB的数据同步到HDFS中，让HDFS成为备份了完整数据的冗余存储。在这种场景下，数据采集就仅仅是一个简单的同步，无需执行转换。
场景2：数据源已经写入Kafka，需要实时采集数据。
在考虑流处理的业务场景，数据采集会成为Kafka的消费者，就像一个水坝一般将上游源源不断的数据拦截住，然后根据业务场景做对应的处理（例如去重、去噪、中间计算等），之后再写入到对应的数据存储中。这个过程类似传统的ETL，但它是流式的处理方式，而非定时的批处理Job。
场景3：数据源为视频文件，需提取特征数据。
针对视频文件的大数据处理，需要在Extract阶段加载图片后，然后根据某种识别算法，识别并提取图片的特征信息，并将其转换为业务场景需要的数据模型。在这个场景下，数据提取的耗时相对较长，也需要较多的内存资源。如果处理不当，可能会成为整个数据阶段的瓶颈。
在数据采集阶段，一个棘手问题是增量同步，尤其针对那种可变（即可删除、可修改）的数据源。在我们无法掌控数据源的情况下，通常我们会有三种选择：
放弃同步，采用直连形式；
放弃增量同步，选用全量同步；
编写定期Job，扫描数据源以获得delta数据，然后针对delta数据进行增量同步
坦白说，这三种选择皆非最佳选择，但我也未尝发现有更好的方案。如果数据源端可以控制，我们当然也可以侦听数据源的变更，然后执行Job来更新采集后存储的数据。这些又可能牵涉到数据存储的选型，假设我们选择了Parquet格式作为数据存储，则Parquet是不允许变更的。若要应对这种场景，或许应该考虑ORC格式。
为了更高效地完成数据采集，通常我们需要将整个流程切分成多个阶段，在细分的阶段中可以采用并行执行的方式。在这个过程中，可能牵涉到Job的创建、提交与分发，采集流程的规划，数据格式的转换等。除此之外，在保证数据采集的高性能之外，还要考虑数据丢失的容错。