delta-lake 系列(二)-delta lake

原创
2019/11/18 18:41
阅读数 653

#delta lake 简介 当我们的主流架构模型依托HATP的时候,我们的数据来源因为hadoop的存在而变得更加旷阔,例如在我们公司,目前的数据源有kafka、aws kinesis、 第三方数据api、aws s3文件、elasticsearch 各种数据、服务日志文件、前端snowplow数据买点、系统运维数据、数据metrics等,随着数据源的越来越多,我们同时也会面临行业内大家同时都会面对的一些问题:

  1. 数据湖的读写是不可靠的。我们的数据经常会出现脏写脏读等情况,比如在hive的event_log表中会存在数据事件id重复的情况,前端买点的数据因为网络延迟或者其他原因而出现数据重复提交等问题。为此我们必须提供一定的方法来保证我们的数据一致性,比如数据一致性监控、数据到达率监控、数据延迟性监控、数据重复性监控(即数据质量管理),有时候我们可能在做数据清洗的时候提供缓存数据来记录事件数据的重复性等。
  2. 数据湖中的数据质量很低。因为数据提交过程中存在的各种原因导致数据的质量无法保证(重复提交hive数据,执行数据清洗机器的时间分区为UTC时间而知道数据按照日期分期错误,倒是最终数据统计异常等。
  3. 随着数据的增加,处理的性能很差。因为我们的数据存入hdfs或者s3文件的时候,hive会维护分区数越来越大,当我们查询跨表或者非分区类字段进行数据统计的时候,会存在非常缓慢的分区扫描。当然现在有很多缓存查询工具可以解决这些问题(比如presto,通过讲需要查询的单表的数据加载到presto的内存中,在对多个查询queue中的数据进行join然后在进行数据merge操作。kylin也有类似的查询功能,可以做一些cache操作)

#设计架构 #主要api #使用demo #使用配置 #和hive、presto一起使用 #开发计划 #核心源码分析

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部