- 博客(21)
- 收藏
- 关注
RSS订阅原创 商品销售状态明细计算
商品销售状态明细交付的维度：dt+poi+sku现有的维度：dt+poi+sku+hour**背景：**需求方要求在一条数据中将该商品一天内该商品状态变化的时间点以及变化后的状态显示出来**难点：**商品一天可能变化多次（hour），如何将商品变化的时间和变换后的状态一一对应的显示在一条数据中**解决方案：**通过map的形式将数据显示在后面具体思路：1：运用concat_ws对每条数据的utime（变化时间）和sale_status（商品状态）进行拼接2：按dt+poi+sku进行grou
2021-12-24 19:15:58
563
原创 复杂指标计算
缺货影响门店背景：缺货主题表中涉及到该字段的指标不明确，需要重新计算缺货主题表主键：dt+poi_id+sku_id+hour方案：1：从缺货主题表里取出oos_effect_poi_id字段（如果该门店缺货，则该字段为门店ID，否则为null）2：先按dt+poi+sku进行聚合，对oos_effect_poi_id进行sum。累加如果为null代表sku全天不缺货，否则为缺货3：然后对oos_effect_poi_id字段进行判断，若不为null为1，否则为04：最后按dt+sku粒度对
2021-12-23 17:27:44
340
原创 Spark - shuffle运行机制
SortShuffleManager 运行原理如何确定分区规则？map()：输出record，并计算其partitionIdpartitionId = hash(key)%partitionNum，一个partitionId 就是一个分区SortShuffleManager 运行机制有两种，一种是普通运行机制，另一种是 bypass 运行机制。当 shuffle read task 的数量小于等于 spark.shuffle.sort.bypassMergeThreshold 参数值时 (默认是 2
2021-12-17 15:35:13
1857
原创 合并时间轴
源表:商品缺货状态变更表:select * from mart_forecast.sku_oos_log_test1商品上下架状态变更表:select * from mart_forecast.sku_status_log_test1最终想要结果:解决方案：第一步（d表）：合并时间轴（1）：将两个时间（缺货，上架）轴进行去重合并（union）（2）：然后再分别关联两张表（缺货，上架）取出对应时间的两个状态 （缺货状态和上架状态）（3）：最后每条数据取变更时间得后一条数据作为结束时
2021-12-11 19:40:51
520
原创 数据仓库与数据集市
数仓建模：关系建模，维度建模，范式建模关系建模有点像维度建模里的雪花模型：关系模型主要应用与OLTP 系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。维度建模分为星形模型，雪花模型，星座模型：主要应用于OLAP 系统中，通常以某一个或多个事实表为中心进行维表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。维度模型建模，把相关各种表整理成两种：事实表和维度表两种（维度表围绕着事实表）。数据分层：数据模型分为三层：数据操作层（ODS）、数据仓库层
2021-12-04 16:41:47
1458
原创 读书笔记八 ---大数据之路（实时任务优化）
如何进行实时任务优化大促前的优化工作在实时计算中显得尤为重要,如果存吐量跟不上的话,也就失去了实时的特性。吞吐量不佳原因非常多,有些跟系统资源有关,有些跟实现方式有关,以下几点是实时任务优化中经常需要考虑的要素。(1)独占资源和共享资源的策略在一台机器中,共享资源池可以被多个实时任务抢占,如果一个任务在运行时80%以上的时间都需要去抢资源,这时候就需要考虑给它分配更多的独占资源,避免抢不到CPU资源导致吞吐量急剧下降。(2)合理选择缓存机制,尽量降低读写库次数内存读写性能是最好的,根据业务的特性选
2021-11-06 18:41:45
906
原创 读书笔记七 ---大数据之路（实时维表的使用）
维表的使用在离线系统中,一般是根据业务分区来关联事实表和维表的,因为在关联之前维表的数据就已经就绪了。而在实时计算中,关联维表一般会使用当前的实时数据(T)去关联T-2的维表数据,相当于在T的数据到达之前需要把维表数据准备好,并且一般是一份静态的数据。为什么维表是T-2天：1：数据无法及时准备好当到达零点时,实时流数据必须去关联维表(因为不能等待,如果等就失去了实时的特性),而这个时候T-1的维表数据一般不能在零点马上准备就绪(因为T-1的数据需要在T这一天加工生成),因此去关联T-2维表,相当于在
2021-11-06 18:37:09
288
原创 读书笔记六 ---大数据之路
多流关联在流式计算中常常需要把两个实时流进行主键关联,以得到对应的实时明细表。在离线系统中两个表关联是非常简单的,因为离线计算在任务启动时已经可以获得两张表的全量数据,只要根据关联键进行分桶关联就可以了。但流式计算不一样,数据的到达是一个增量的过程,并且数据到达的时间是不确定的和无序的,因此在数据处理过程中会涉及中间状态的保存和恢复机制等细节问题。比如A表和B表使用ID进行实时关联,由于无法知道两个表的到达顺序,因此在两个数据流的每条新数据到来时,都需要到另外一张表中进行查找。如A表的某条数据到达,到B
2021-11-06 18:15:58
1003
原创 读书笔记五 ---大数据之路--数仓分层
数据分层在流式数据模型中,数据模型整体上分为五层。ODS层跟离线系统的定义一样, ODS层属于操作数据层,是直接从业务系统采集过来的最原始数据（进行了数据清洗）,包含了所有业务的变更过程,数据粒度也是最细的。在这一层,实时和离线在源头上是统一的,这样的好处是用同一份数据加工出来的指标,口径基本是统一的,可以更方便进行实时和离线问数据比对。例如:原始的订单变更记录数据、服务器引擎的访同日志。（原始数据）DWD层DWD层是在ODS层基础上,根据业务过程建模出来的实时事实明细层,对于访问日志这种
2021-11-06 17:57:02
699
原创 读书笔记四 ---大数据之路
流式技术架构：在流式计算技术中,需要各个子系统之 相互依赖形成一条数据处理链路,才能产出结果最终对外提供实时数据服务。在实际技术选型时,可选的开源技术方案非常多,但是各个方案的整体架构是类似的,只是各个子系统的实现原理不太一样。另外,流式技术架构中的系统跟离线处理是有交叉的,两套技术方案并不是完全独立的,并且在业界中有合并的趋势.各个子系统按功能划分的话,主要分为以下几部分。1,数据采集数据的源头,一般来自于各个业务的日志服务器(例如网站的浏览行为日志、订单的修改日志等),这些数据被实时采集到数据中
2021-11-06 16:21:46
639
原创 读书笔记三--- 大数据之路
整体来看,流式数据处理一般具有以下特征。1.时效性高数据实时采集、实时处理,延时粒度在秒级甚至毫秒级,业务方能够在第一时间拿到经过加工处理后的数据。2．常驻任务区别于离线任务的周期调度,流式任务属于常驻进程任务,一旦启动后就会一直运行,直到人为地终止,因此计算成本会相对比较高。这一特点也预示着流式任务的数据源是无界的,而离线任务的数据源是有界的。这也是实时处理和离线处理最主要的差别,这个特性会导致实时任务在数据处理上有一定的局限性。3,性能要求高实时计算对数据处理的性能要求非常严格,如果处理吞吐
2021-11-06 16:18:12
541
原创 FDC和RDC
名词解释RDC:Regional Distribution Center，区域分发中心。我们这边可以理解为大仓库，目前有华北和华东两个。FDC:Front Distribution Center，传统意义上是转运中心，即二级仓库，但我们这边是与门店平级，与门店的区别是不支持线下直接交易，必须通过线上下单。PC:Produce Center, 加工中心。逻辑上与RDC平级，物理上目前在RDC内部。门店：小象生鲜门店，提供线上线下交易支持。菜店：专注卖菜，实际上就是FDC。VZ: 唯智仓储物流系统，
2021-11-05 14:27:14
8948
原创 以不同的方向来处理数据倾斜
一：程序层面：比如说在Hive中，经常遇到count(distinct)操作，这样会导致最终只有一个Reduce任务。我们可以先group by，再在外面包一层count，就可以了。比如计算按用户名去重后的总用户量：// 优化前 只有一个reduce，先去重再count负担比较大：select name,count(distinct name)from user;//优化后// 设置该任务的每个job的reducer个数为3个。Hive默认-1，自动推断。set mapred.reduce.t
2021-11-05 14:08:13
131
原创 如何判断是笛卡尔积
1:结果的数据量远大于主表的数据量（表没做聚合时可以用这个进行判断）2:join后面是否忘记了使用on做关联条件3:查询长时间没有出结果(例如，明明结果只有几千条数据，但是却查了六七百秒)4:做表关联的时候没有使用主键关联，导致中间结果产生的数据特别多...
2021-11-05 10:42:03
310
原创 读书笔记二 ---大数据之路
开发平台：SQLSCAN:代码检测SQLSCAN根据所配置的规则执行相应的规则校验。SQLSCAN将检查成功或者失败的信息传回D2.D2的IDE显示OK (成功) 、WARNNING (警告) 、FAILED(失败,禁止用户提交)等消息。SQLSCAN主要有如下三类规则校验:代码规范类规则,如表命名规范、生命周期设置、表注释等。代码质量类规则,如调度参数使用检查、分母为0提醒、NULL值参与计算影响结果提醒、插入字段顺序错误等。代码性能类规则,如分区裁剪失效、扫描大表提醒、重复计算检测等.
2021-10-30 20:12:17
173
原创 读书笔记一 大数据之路
计算平台：逻辑层又称作控制层,是MaxCompute的核心部分,实现用户空间和对象的管理、命令的解析与执行逻辑、数据对象的访问控制与授权等功能。在逻辑层有Worker. Scheduler和Executor三个角色:1:Worker处理所有的RESTful请求,包括用户空间(Project)管理操作、资源(Resource)管理操作、作业管理等,对于SQL DML.MR等需要启动MapReduce的作业,会生成MaxCompute Instance(类似于Hive中的Job) ,提交给Schedule
2021-10-30 20:10:52
131
原创 标准差的使用
STDDEVSQLselecttodaycompactasdt,STDDEV(bizsaleqty)asstdev30daystotalsalenumfrommartmallpa.topicscarssaleforecastpoiskucommonfeaturedta1innerjoin(selecta1.datekeyfrommartmall.dimdatea1wheredaynumbetween(selectdaynum−30asstartdaynumfrommartmall.dimdatewhe
2021-10-30 17:46:11
142
原创 零售的哲学前三章读后感
零售的哲学前三章读后感 **共同配送** 由于生产厂商和一系列的批发商各自为营，每天来1号店送货的货车高达70辆。牛奶就是一个经典的例子。当时的牛奶有全农、森永、明治等品牌，虽然对消费者而言都属于同类产品，但却必须由不同公司分别发送货品。作者发现这种配送方式非常没有效率，因此建议把同一地区同类厂家的产品混装在一起实行共同配送。 厂家出于对品牌的自尊心，不愿运送其他竞争对手的产品，并斥责作者的做法不懂得其为建立品牌所付出的心血。这种说辞表明他们依然停留在卖方市场时代的思维模式，以为只要把产品放上货架，
2021-09-04 14:01:56
276
原创 关于 left join on where的优化方法
这里写自定义目录标题欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题，有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能，丰富你的文章UML 图表FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Mar
2021-07-25 22:27:27
2049
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人