9号彩票开户

关注微信  |  微博  |  腾讯微博  |  RSS订阅
读者QQ群③:168129342,投稿请发dashuju36@qq.com
我要投稿

剖析大数据平台的数据采集

36大数据

作者:张逸

我在一次社区活动中做过一次分享,演讲题目为《大数据平台架构技术选型与场景运用》。在演讲中,我主要分析了大数据平台架构的生态环境,并主要以数据源、数据采集、数据存储与数据处理四个方面展开分析与讲解,并结合具体的技术选型与需求场景,给出了我个人对大数据平台的理解。本文讲解数据采集部分。

数据采集的设计,几乎完全取决于数据源的特性,毕竟数据源是整个大数据平台蓄水的上游,数据采集不过是获取水源的管道罢了。

在数据仓库的语境下,ETL基本上就是数据采集的代表,包括数据的提取(Extract)、转换(Transform)和加载(Load)。在转换的过程中,需要针对具体的业务场景对数据进行治理,例如进行非法数据监测与过滤、格式转换与数据规范化、数据替换、保证数据完整性等。

但是在大数据平台下,由于数据源具有更复杂的多样性,数据采集的形式也变得更加复杂而多样,当然,业务场景也可能变得迥然不同。下图展现了大数据平台比较典型的数据采集架构:

36大数据

以下是几种比较典型的业务场景。

场景1:为了提升业务处理的性能,同时又希望保留历史数据以备数据挖掘与分析。

业务处理场景访问的数据库往往是RDB,可伸缩性较差,又需要满足查询与其他数据操作的实时性,这就需要定期将超过时间期限的历史数据执行清除。但是在大数据场景下,这些看似无用的历史数据又可能是能够炼成黄金的沙砾。因而需要实时将RDB的数据同步到HDFS中,让HDFS成为备份了完整数据的冗余存储。在这种场景下,数据采集就仅仅是一个简单的同步,无需执行转换。

场景2:数据源已经写入Kafka,需要实时采集数据

在考虑流处理的业务场景,数据采集会成为Kafka的消费者,就像一个水坝一般将上游源源不断的数据拦截住,然后根据业务场景做对应的处理(例如去重、去噪、中间计算等),之后再写入到对应的数据存储中。这个过程类似传统的ETL,但它是流式的处理方式,而非定时的批处理Job。

场景3:数据源为视频文件,需提取特征数据

针对视频文件的大数据处理,需要在Extract阶段加载图片后,然后根据某种识别算法,识别并提取图片的特征信息,并将其转换为业务场景需要的数据模型。在这个场景下,数据提取的耗时相对较长,也需要较多的内存资源。如果处理不当,可能会成为整个数据阶段的瓶颈。

在数据采集阶段,一个棘手问题是增量同步,尤其针对那种可变(即可删除、可修改)的数据源。在我们无法掌控数据源的情况下,通常我们会有三种选择:

  • 放弃同步,采用直连形式;
  • 放弃增量同步,选用全量同步;
  • 编写定期Job,扫描数据源以获得delta数据,然后针对delta数据进行增量同步

坦白说,这三种选择皆非最佳选择,但我也未尝发现有更好的方案。如果数据源端可以控制,我们当然也可以侦听数据源的变更,然后执行Job来更新采集后存储的数据。这些又可能牵涉到数据存储的选型,假设我们选择了Parquet格式作为数据存储,则Parquet是不允许变更的。若要应对这种场景,或许应该考虑ORC格式。

为了更高效地完成数据采集,通常我们需要将整个流程切分成多个阶段,在细分的阶段中可以采用并行执行的方式。在这个过程中,可能牵涉到Job的创建、提交与分发,采集流程的规划,数据格式的转换等。除此之外,在保证数据采集的高性能之外,还要考虑数据丢失的容错。

End.

转载请注明来自36大数据(36dsj.com):36大数据 » 剖析大数据平台的数据采集

36大数据   除非特别注明,本站所有文章均不代表本站观点。报道中出现的商标属于其合法持有人。请遵守理性,宽容,换位思考的原则。

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址
友情链接:澳彩网彩票  金凤凰彩票  北京赛车pk拾开奖时间  幸运农场开户  宏发彩票  

免责声明: 本站资料及图片来源互联网文章,本网不承担任何由内容信息所引起的争议和法律责任。所有作品版权归原创作者所有,与本站立场无关,如用户分享不慎侵犯了您的权益,请联系我们告知,我们将做删除处理!