数据中台
文章平均质量分 68
食得落
此刻我仰望星空 寻找生命中最灿烂的亮点
展开
-
Doris 实时数仓建设实践
Drois 从早期的百度项目,到开源Apache Doris,到商业化的StarRocks,到各大云服务商,陆续上线,作为新一代的OLAP解决方案,在应用场景上表现得非常好整理对近期对Doris实时数仓建设的一些思考建立外表 - 实现跨库连表分析数据导入 - 减少业务库性能压力对数据导入的表进行表结构优化 - 增加查询性能对数据导入的表建立物化视图 - 增加查询性能维度模型规划维度表与事实表 - 增加查询性能对通过建模生成的事实表做物化视图 - 增加查询性能。原创 2023-01-13 17:55:05 · 3144 阅读 · 0 评论 -
判断一个时间段是否经过了另一个时间段
判断一个时间段是否经过了另一个时间段如查询2022-10-10 15:00:00 - 2022-10-10 23:00:00 之间存在离线的记录,需要命中id=1的数据。IOT设备存在离线与恢复时间记录,每一次离线和恢复记为一个周期即一条数据, 现在需要统计出在某个时段存在离线记录的数据,如果目前未恢复,没有恢复时间,恢复时间置为9999-01-01 00:00:00。在时间区间2022-10-10 15:00:00 至 2022-10-10 23:00:00之间的上班时段8点-20之间经历过离线的数据。原创 2022-11-25 18:53:47 · 725 阅读 · 0 评论 -
Kimball 维度建模理论
雪花模型指的是在星型模型的基础上,维度表再关联维度表,这种结构应该在OLTP场景下会用这样的结构,在数仓下基本没人使用。如果业务数据存储为这样的结构,常常将数据打平,即合并成一张维度表,这样它将会上级为星型模型。kimball 维度建模,星型和星座 模型核心在于将事实表(过程数据通常不变的数据)与主体信息表(常更新的数据,有维度信息)逻辑进行拆分。在实际业务中,星座模型才是数仓建设的最终归属,它也是建立在星型模式下,不同的是只是和其他事实表共享了维度表,即存在多张事实表,共享一张维度表的情况。转载 2022-11-15 18:54:34 · 1502 阅读 · 0 评论 -
第几次行为数据清洗
产品需求:显示用户的行为记录上第几次访问: 比如:『张三第3次访问了这篇文章』想法1:实现:首先想到的是去数据库『明细』表中查询一下历史数量,然后本次入库+1问题:很明显,性能差到爆想法2:实现: 在数据库中维护字典,描述为『最后的次数』问题:性能好是好点了,但抗不住并发,抗不住高峰(不用高,低的并发也抗不住)想法3:实现: 将字典缓存在Redis中,使用inc自增,进行缓存问题:redis字典数据的生命周期,时间越久,数据越大,总有一天能占满,或者更换redis时次数字原创 2021-11-17 19:09:18 · 1291 阅读 · 0 评论 -
Doris 画像标签存储实践
根据画像标签的需求场景,我们常常将画像存储分为两部份,分别是:画像基本信息的存储用户画像人群的筛选需求的存储常见画像标签存储方式:根据类目创建宽表,或者根据更新的频率创建宽表创建竖表-每个用户+每个标签=一条记录竖表+横表=》分开计算,定时聚合ES 标签对象存储,rowKey为user_id,HBASE存储用户明细,通过user_id关联倒排表,标签-》多个用户Id,bitmap方案一、根据类目创建宽表,或者根据更新的频率创建宽表1. 这是最容易想到的方式,同时也是最直观的方式,原创 2021-09-23 11:15:29 · 4058 阅读 · 12 评论 -
数据开放平台
数据开放平台介绍数仓,数据湖,数据中台,都是对于数据资产的管理,而对于管理起来的数据如何对业务系统快速赋能,一直是数据团队需要深入考虑的问题对业务系统赋能,一般有两种方式,一是提供API供业务系统调用,二是将数据推送给业务系统。这里描述的是第一种API形式供业务系统访问的平台 『数据开放平台』在以往,要以API形式提供给业务方,需要数据团队独立开发以周为版本的迭代使用过BI的同学知道,一些报表,和统计结果,只需要几条Sql就能完成大部份的业务需求,很快捷。那么如果我为这些SQL配一个API访问地址原创 2021-09-22 13:52:50 · 927 阅读 · 0 评论