数据散落在各个业务部门,单一业务使用起来方便,但跨业务、跨部门应用就会存在诸多问题:
① 数据来源多样化,数据管理非常分散;
② 业务数据缺乏统一标准,难以整合应用;
③ 业务数据口径不一,无法保证准确度;
④ 各自维护数据一亩三分地,缺乏数据管控体系,数据质量难以保证。
面向分析主题的、集合的、相对稳定的、反映历史变化的数据集合,主要支持管理人员分析决策。
与数仓“集合的”特性对应,主要为了解决各系统的异构问题(数据的表示协议),比如:
为了解决上面提到的差异性,数仓需要把从各个系统中的数据转换成相同的格式,例如 csv、orc 等等。
与数仓“相对稳定的”特性对应,如果数据整合 - 将各国外语翻译为中文,那么统一口径 - 统一讲普通话。
诸如问题1:播放开始中的歌曲类型:1、2;下载开始中的播放类型:音频、视频。
诸如问题2:数据中的缺失值处理、无效数据处理
针对这种问题,全面梳理核心业务的核心字段,制定统一的数据标准,在数仓建设过程中将此类问题规整。
业务流程、参与角色、操作场景,需要数据解决什么问题,这就对应着要监控哪些数据。
比如,快递业务流程:下单--派单--收件--网点接驳--运输--片区中转场--中转运输--片区中转场--网点接驳--派件--签收,参与角色:客户、调度员、小哥、司机、运作员、分拣员
业务主体之间的关系,就是小说人物之间的关系
维度好比小说人物的属性:技能、长相、性格等
指标好比小说人物对整个小说的输出量化
更新频率:实时、小时、日、周、月、年.....
Talend:有 GUI 图形界面但是以 Eclipse 的插件方式提供。
Kettle:有非常容易使用的 GUI,出现问题可以到社区咨询。
Informatica:有非常容易使用的 GUI,但是要专门的训练。
Inaplex Inaport:没有GUI
操作型数据:时间范围短、细节、当前状态;
分析型数据:时间范围长、细节&汇总
presto:facebook开源的一个java写的分布式数据查询框架,原生集成了Hive、Hbase和关系型数据库,Presto背后所使用的执行模式与Hive有根本的不同,它没有使用MapReduce,大部分场景下比hive快一个数量级,其中的关键是所有的处理都在内存中完成。
Druid:是一个实时处理时序数据的Olap数据库,因为它的索引首先按照时间分片,查询的时候也是按照时间线去路由索引。
spark SQL:基于spark平台上的一个olap框架,本质上也是基于DAG的MPP, 基本思路是增加机器来并行计算,从而提高查询速度。
kylin:核心是Cube,cube是一种预计算技术,基本思路是预先对数据作多维索引,查询时只扫描索引而不访问原始数据从而提速。
此版块另开专题讲
本文发布于:2024-01-28 01:23:40,感谢您对本站的认可!
本文链接:https://www.4u4v.net/it/17063762283814.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
留言与评论(共有 0 条评论) |