背景群友字节面试让写出3种方法，但只写出2种最后面试没过，相互关注是常见一道SQL题，但这次我们加一下挑战难度，通过不同sql方法去解（不考虑时效），且之前用过的方法后续不会再用，比较考察SQL的基本功。题目现在有一张表为fans(粉丝表) 里面有两个字段from_user,to_user ,如果两者一致代表from_user关注了to_user数据 with fans as ( SELECT '001' as from_user,'002' as to_user union all SELECT '002' as from_user,'001' as to_user union all SE...

我猜各位数仓同学可能会经常收到下游抱怨，例如：数据表难用、想要的指标都不知道存放在哪个数据表、数据表命名缺少规范不易读等，由于设计数据表是一个“经验活”（包括业务了解、设计中的经验沉淀等），因此对于数仓同学来说有时候想做好一个完美的数据表其实颇有挑战，也从另外角度证实线上数据表大多数来说都不够合规，需要持续治理。本期语兴从数据表治理角度出发，探讨数据表合规治理的最佳实践及相关挑战。数据表合规治理的背景随着业务的快速迭代，同时数仓也在扩张期高速支持，产生的数据量越来越大，划分的数据域也愈来越多，但很多数仓在初步搭建时都没有确定好数据标准、模型设计规范、没有一套完整数据的生命周期管理体系、同时组内...

问题背景有同学咨询语兴说全量改增量在企业中都是怎么去做的，拉链表又是怎么做的。全量：分区下所有数据2024-10-07 1000w增量：分区只记录当天的数据，下所有数据2024-10-07 10w 2022-2024 总计1000w随着企业快速增长数据量也不段变多，可能一天有10w增量，但过了10年后，数据量过亿，如果直接同步数据库会很慢（如果是只读库还好，如果是生产库直接拖挂了），同步任务一般跑半小时附近，所以我们要对全量数据改造成增量。数据导入建表语句 CREATE TABLE mammut_user.ods_trade_trade_order_di ( id BIGINT COMMENT...

今天有同学问语兴，颗粒度和维度到底是什么关系，有些分不清，这里用一篇文章和小案例，来详细给大家讲清楚维度与颗粒度。颗粒度颗粒度描述的是一个业务流程的主体，反映了数据记录的细节程度。在一个业务流程中，通常会有一些核心实体或者事件作为数据的主要标识，例如订单表中的订单ID，员工离职表中的员工ID，这些都可以视为颗粒度，换句话说，颗粒度是数据的粒度，决定了每条数据记录的唯一性和独特性。例如：在订单表流程中，订单ID是主体，代表每个独立的订单。因此，订单ID就是颗粒度。在员工离职表中，员工ID是主体，代表每个独立的员工。因此，员工ID就是颗粒度。由此可见，颗粒度可以是维度，也可以是业务流程自有的ID。...

群友提问：1.如何衡量项目的好坏？2.项目的数据建设为整个数仓带来了什么变化？问题1回答从怎样衡量项目的好坏从层面来说（1）业务侧项目价值：很多同学无法判断业务提供的内容是否是有价值的项目，比如取数这个无法被称作是一个项目，更像是简单的需求，项目的价值是通过周期性建设数据资产对业务方提供分析帮助或通过数据服务/组件帮助业务提效，结合数分建设版图工作来说具备价值内容包括专题分析、经营分析这些能够给予业务方直观数据。（2）项目目标是否明确  ：结合第一点我们继续评估，项目目标清晰做到最后数分和数仓都没有项目成果，甚至数分对于到底从什么角度去分析专题内容都没思路，导致最终项目结束草草了事，对于这样的...

有同学问语兴，目前最新设计的数仓是几层都在做什么？目前语兴对数仓分层采用ods Dwd dwm Dws ads（大宽表 小宽表）可以说5层也可以说6层。ODS（接入层）接入层，可拆解为ori 板块和ods板块，都可以叫ods，也可以分开起名，ori主要做json等消息存储，ods则是存放解析json成各类字段后的数据，如从mysql等数据库抽取的数据则字段与数据源保持一致，数据类型整型使用bigint string double/decimal等。命名：ods_库名_表名_df/ods_topic_df。DWD（明细层）明细层，主要做数据清洗（test、异常等数据），转换（将code值转化成n...

前言最近很多同学都已快到转正时期了，这里语兴给大家提供一些试用期通过，能landing建议，帮助大家顺利通过试用期。新人挑战刚入职的新人，对于新业务理解及技术框架变更（例如hdp到数据平台）都有挑战，这些其实也都不算什么，更大挑战而是接受一堆看不懂的历史项目及几十上百的“老”任务，同时需要快速熟悉这些老业务，并在新业务场景做出价值。另一种挑战则是上手变慢做不出业务价值，更多干历史dirty work去排查bug、帮业务取数等，最后发现啥也做了但啥也没做，导致试用期没啥量点从而不一定通过。刚入职的新人，对于新业务理解及技术框架变更（例如hdp到数据平台）都有挑战，这些其实也都不算什么，更大挑战而...

一、前言大家常听到一个词叫大数据杀熟，甚至很多同学会发现查询了某个商品后，后面各平台都会推荐这个商品，甚至大家在线下聊完一个信息后，系统也会给你推相似内容信息，为什么大数据会杀熟，本质在于企业形成了用户标签画像体系，也就是大家经常提的千人千面，但千人千面所有源头都是来源于一个个用户标签画像体系的形成，本期我们从用户标签角度出发带大家看清标签加工到画像生成整个过程。画像标签的初衷是没问题的，是帮助企业快速筛选更优质的用户，从而减少无效广告的推送，推送偏好信息，但如果用户标签画像被多平台共享，你会感觉到整个生活都被数据所支配，所以在今天大家都在强调用户隐私，但语兴想说在数据爆发的今天用户一言一行都...

基础解释ID-MAPPING：是基于操作ID进行打通映射，找到唯一标识ID的一种手段。简单说，就是把不同来源（不同设备，不同APP，不同应用等）的数据，通过一系列技术手段或者方法映射成同一个对象的过程。ONE-ID：ONE-ID主要解决孤岛数据的链接问题，将实际实体的行为关系通过顶层的ONE-ID进行孤岛串联，就能打通不同用户，不同实体之间的所有跨端、跨APP、跨平台之间的孤立状态，ONE-ID本质是一种桥梁关系，核心基础就是ID-MAPPING。主账号:一般在公司核心产品中或者一个对应的应用APP中，一个用户可能有多个账户，其中用户主要通过该账号进行的平台活动视为该用户的主账号，主账号的识别...

这两天有同学咨询语兴，指标异常分析或者归因，目前有啥好的自动化解决方案吗首先明确一下这个问题如果要定位到最根本细节的原因是解决不了的，依赖算法模型召回是可以的，如果让数据去做，则无法落地。举个例子🌰，语兴做了一家类似小某书的公司，现在做的是社区业务，目前语兴01想看一下社区业务中为什么昨天举报量对比前天量级要激增了，于是把这个抛送给语兴02去排查，经过语兴02排查发现昨天是1300，前天是1000，作为数分兼岗数据仓库的语兴02通过数据分析思维去向下排查，发现社区中评论场景举报占比85%+，再按照举报理由去排查发现三级举报类目下引战谩骂占比最高，但对于语兴02同学来说排查到到这里基本就结束了...

群友提问：离线小时看板数据和实时看板数据对不上该怎么排查。首先定位问题中架构为HSAP OR LAMBDA。指标口径先看指标口径是否准确，保障实时和离线指标口径一致，以及线上版本，同时看代码版本改动记录如指标口径及数据源，如果都没问题则继续向下排查。消费情况看dwd清洗加工代码中是否有加filter处理，以及多表明细join情况是否有空，如果未做处理同时未有空值，则看 flink ui 查看dwd/ods数据消费情况，如数据反压则按照反压排查思路，如数据质量还是有问题（例如正常指标每日gmv在100w附近，今日变20w），则去回查mysql/kafka源头情况，同时保障数据来源一致。重新拉取消...

群友分享字节一面面经虚拟内存域名访问过程深挖项目 细节 困难 收获算法 二叉树镜像 股票买卖还问了ab test

数据25秋招各类内推码1在我主页

数据25秋招各类内推码，