Lansonli（蓝深李）的博客

一、大数据入门核心技术大数据入门核心技术栏目里集合等大数据必学的核心技术。初学者选择这个栏目，可以快速了解大数据知识体系，为后面的扩展性的深度学习大数据打下坚实的基础。二、数据湖基础+湖仓一体电商项目数据湖是一个集中式的存储库，允许你以任意规模存储多个来源、所有结构化和非结构化数据，可以按照原样存储数据，无需对数据进行结构化处理，并运行不同类型的分析对数据进行加工，例如：大数据处理、实时分析、机器学习，以指导做出更好地决策。在大数据中属于很火的技术，学会它让你大数据项目里游刃有余。

Azkaban官方并没有提供Linux系统的编译安装包，需要读者根据需求在官网选择指定版本的Azkaban源文件，然后进行编译打包。

Azkaban工作流管理器由三个核心部分组成，分别是Relational Database（关系型数据库MySQL）、AzkabanWebServer（Web服务器）、AzkabanExecutorServer（执行服务器）。

无论是在业务开发还是在大数据开发中，工作流管理是必不可少的，在初期可以使用Linux自带的crontab工具来定时调度任务，但是当业务规模变大并且需要可视化监控任务执行的时候，crontab显然已经满足不了需求。各任务单元之间存在时间先后及依赖关系，为了将这复杂的执行计划组织起来，需要一个工作流调度系统来调度执行。Azkaban是对job调度管理，而每个job任务都编写在一个后缀名为.job的文本文件中，在该文件中可定义job任务类型、将运行的任务、依赖的其他job及job运行的相关参数。

HBase是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式 NOSQL 数据库。当你需要随机、实时读/写访问大数据时，请使用 Apache HBase。

在Flink开发平台，新建名为DWD的SQL流作业，并将如下代码拷贝到SQL编辑器后，部署并启动作业。创建Catalog时可以设置默认的源表、维表和结果表的WITH参数，也可以设置创建Hologres物理表的默认属性，例如上方table_property开头的参数。a) 在Flink开发平台，新建名为ODS的SQL流作业（步骤与test作业相同，引擎一致），并将如下代码拷贝到SQL编辑器。创建作业后，将如下代码拷贝到test作业的SQL编辑器上，修改目标参数取值后，选中代码片段后单击左侧代码行上的运行。

行存表设置了Primary Key（PK）的场景，系统会自动生成一个Row Identifier（RID），RID用于定位整行数据，同时系统也会将PK设置为Distribution Key和Clustering Key，这样就能快速定位到数据所在的Shard和文件，在基于主键查询的场景上，只需要扫描一个主键就能快速拿到所有列的全行数据，提升查询效率。数据在底层存储时会存储两份，一份按照行存格式存储，一份按照列存格式存储，因此会带来更多的存储开销。

外部表在Hologres中不存储数据，只进行字段映射。通过外部表可以使用Hologres直接调用存储于MaxCompute公共空间MAXCOMPUTE_PUBLIC_DATA的数据。以下SQL语句用来创建名称分别为LINEITEM、ORDERS、PARTSUPP、PART、CUSTOMER、SUPPLIER、NATION和REGION的表，用于后续存储数据。

Hologres是阿里巴巴自主研发的一站式实时数仓引擎（Real-Time Data Warehouse），支持海量数据实时写入、实时更新、实时加工、实时分析，支持标准SQL（兼容PostgreSQL协议和语法，支持大部分PostgreSQL函数），支持PB级数据多维分析（OLAP）与即席分析（Ad Hoc），支持高并发低延迟的在线数据服务（Serving），支持多种负载的细粒度隔离与企业级安全能力，与MaxCompute、Flink、DataWorks深度融合，提供企业级离在线一体化全栈数仓解决方案。

以上体系架构图就是滴滴整体业务架构图，底层是数据源，中间也做了数据仓库分层，包括ODS层，DWD明细层是将ODS层数据库binlog、Public Log、Topic、消息队列同步过来，DWD包含三类数据：业务数据（订单交易），流量数据（主要是埋点获取用户行为数据，用作用户分析），维度数据（用户数据、司机数据、车辆行驶数据、拍照数据等维度数据），DWM层就是指标汇总层，对一些核心的指标做一些汇总，包括：冒泡、呼单、完单、PV、UV、财务、安全等。数据写入Redis和ES的主要作用是做实时数据缓存。

但是这里有两个问题，第一个问题是小文件很多，但这不是最关键的，第二个问题才是最致命的，就是上游每分钟提交了很多文件到HDFS上，下游消费的Flink是不知道哪些文件是最新提交的，因此下游Flink就不知道应该去消费处理哪些文件。所以实时数仓发展到现在的架构，一定程度上解决了数据报表时效性问题，但是这样的架构依然存在不少问题，随着技术的发展，相信基于Kafka+Flink的实时数仓架构也会进一步往前发展，那么到底往哪些方向发展，我们可以结合大公司中技术选型可以推测实时数仓的发展大致会走向“批流一体”。

实时数仓可采用离线数仓的数据模型进行分层处理，目前建议选择Kafka，实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据既可以写入HDFS用于批量分析，也可以实时处理，下游可以写入数据集市供业务使用。中首要考虑查询效率，其次是插入、更新等问题，这里说的存储时最终计算数据结果的存储，可选择ClickHouse、Hbase、apache Druid、Redis等，频繁更新的数据建议不要采用ClickHouse与Druid。准确度随着技术发展，准确度高。传统数仓主题建模理论。

但是很快，他们也发现自己陷入了某种困境：随着数据集市的不断增多，这种架构的缺陷也逐步显现，公司内部独立建设的数据集市由于遵循不同的标准和建设原则，以致多个数据集市的数据混乱和不一致，解决以上问题，还需回归到范式建模。在Lambda架构中，为了计算一些实时指标，就在原来的离线数仓基础之上增加了一个实时计算的链路，并对数据源做流式改造：把消息发送到消息队列中（大数据中常用Kafka），实时计算去消费消息队列中的数据，完成实时指标计算，推送到下游的数据服务中去，由数据服务层完成离线与实时结果的合并。

做完业务分析和需求分析之后，要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求，则需要和业务方进行沟通，例如某个页面需要新增某个行为的埋点。

另外，如果某些维度表的维度属性很少，例如只有一个XX名称，则可不创建该维度表，而把该表的维度属性直接增加到与之相关的事实表中，这个操作称为。例如业务系统中与商品相关的表有sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1等，其中sku_info就称为商品维度的主维表，其余表称为商品维度的相关维表。维表中的某个属性同时有多个值，称之为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。

第一步选择业务过程可以确定有哪些事务型事实表，第二步可以确定每张事务型事实表的每行数据是什么，第三步可以确定每张事务型事实表的维度外键，第四步可以确定每张事务型事实表的度量值字段。此处以电商中的虚拟货币为例，虚拟货币业务包含的业务过程主要包括获取货币和使用货币，两个业务过程各自对应一张事务型事实表，一张存储所有的获取货币的原子操作事件，另一张存储所有使用货币的原子操作事件。例如前文提到的用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

位于周围每张表都是维度表，包括Date（日期），Customer（顾客），Product（产品），Location（地区）等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品。这种建模方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。：业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。

推荐其关注的用户喜欢的音乐名称，主要是考察表之间的关联，并考察行转列及去重相关操作。1、根据用户关注表和用户喜欢的音乐表进行关联，查询出每个用户关注用户喜欢的音乐ID。1、根据用户关注表和用户喜欢的音乐表进行关联，查询出每个用户喜欢的音乐ID。1、用户关注表t1_follow记录用户及其关注的人。2、用户喜欢的音乐t1_music_likes。2、再关联音乐名字表，关联出对应的音乐名称。2、关联音乐名字表，关联出对应的音乐名称。3、音乐名字表t1_music。推荐他关注的用户喜欢的音乐名称。

1、首先计算可能认识的人，由于所有可能认识的条件必须发生在同一个网吧内，以bar_id进行自关联，然后id要求t1>t2来保证同一个用户和其他的用户只进行一次关联，限定上线时间或者下线时间在10分钟内。2、按照t1的user_id，t2的user_id 进行分组，统计可能认识的人（符合【规则一】条件的人）在同一网吧上网的次数。有某城市网吧上网记录表，包含字段：网吧，访客，上线时间，下线时间。请计算该城市中经常去同一家网吧的用户中两人一定认识的组合数。2、计算出可能认识的用户组中，出现的同个网吧的个数。

这里需要第一条和最后一条，因为无法提前预知每个用户的行数，所以使用两次row_number进行开窗，排序方式根据时间进行正向排序和逆向排序，分别取出行号为1的数据。现有一张订单表 t3_order 有订单ID、用户ID、商品ID、购买商品数量、购买时间，请查询出每个用户的第一条记录和最后一条记录。使用row_number()根据用户进行分组，根据时间分别进行正向排序和逆向排序，增加两个行号，分别为asc_rn和desc_rn。条件判断为asc_rn=1取第一条，desc_rn=1 取最后一条。

已知有购买记录表t2_order,包含自增id:id，用户ID:user_id，商品ID:goods_id，订单时间：order_time，商品类别：goods_type。2、两个表进行全外联，获得全量的数据行。

本题难点在解决交叉问题，但是题目给出的是开始日期和结束日期，我们根据开始和结束日期，使用生成函数，生成活动期间每天的记录，然后根据品牌分组，对日期进行去重即可。2、苹果第二行数据的营销结束日期和第三行的开始日期不连续，2024-09-07以及2024-09-08不统计到营销天数中。有营销活动记录表，记录了每个品牌每次营销活动的开始日期和营销活动的结束日期，现需要统计出每个品牌的总营销天数。1、苹果第一行数据的营销结束日期比第二行数据的营销开始日期要晚，这部分有重叠的日期的要去重计算。

根据diff进行判断，如果差值为1代表连续赋值为0，否则代表不连续赋值为1,然后使用sum()进行累积计算，获得分组依据字段。3、根据重新分组标签进行分组，使用聚合函数max()，count()计算出每组的最后一个数和每组的个数。1、本题还是对重新分组的考察，首先使用lag函数，计算与上一ID的差值，为1则代表连续，否则存在断点。有一张表t3_id记录了id，id不重复，但是会存在间断，求出连续段的最后一个数及每个连续段的个数。3、分组聚合，过滤count()大于1才是连续的数据得出结果。

根据diff进行判断，如果差值为1代表连续赋值为0，否则代表不连续赋值为1,然后使用sum()进行累积计算，获得分组依据字段。3、根据重新分组标签进行分组，使用聚合函数min(),max()计算出每组的起始位置和结束位置。有一张表t2_id记录了id，id不重复，但是会存在间断，求出连续段的起始位置和结束位置。1、本题对重新分组的考察，此类题目真的比较常见的。1、lag()函数进行开窗计算与上一行的差值。2、使用累积求和方式对数据进行重新分组。3、得出连续分区结果。

使用sum()开窗计算每个城市的gdp总额，以及使用sum()over(order by )计算累积占比。现有各省地级市的gdp数据,求从高到底累加刚好超过各省GDP40%的地市名称，临界地市也需要。由于要求包含临界值，直接求取十分不方便，所以我们改变策略，gdp从低到高累加求和，求取累加求和。1、考察的是聚合函数开窗、聚合函数开窗时使用order by 进行累积求和。2、要求包含临界地市，这里属于技巧的考察，这种使用补集的方式计算。使用各省市全量数据，计算出不在上述结果的数据，即目标结果。

现有用户登录日志表，记录了每个用户登录的IP地址，请查询共同使用过3个及以上IP的用户对。1、将所有用户登录记录按照用户ID和登录IP去重。2、通过IP地址进行自关联，去重，剔除相同用户。4、查询共同使用过3个以上IP的用户对。3、根据用户组计算使用共同IP的个数。5、合并过滤去重用户，得到最终结果。

3、使用row_number，原始订单记录表中的user_name、ord_id进行分组，按照有效订单表的时间排序，增加分组排序。2、原始的明细数据与新的有效订单表按照用户进行关联，有效订单表的订单时间大于等于原始订单表。现有订单表t5_order，包含订单ID，订单时间，下单用户，当前订单是否有效。请查询出每笔订单的上一笔有效订单，注意不是每笔订单都是有效的。1、先查询出有效订单，然后计算出每笔有效订单的上一单有效订单。我们可以看出，最终我们需要的就是rn=1 的记录。

需要比较当天价格与前一天、后一天的价格进行比较，常规想法为进行关联，股票ID相等、日期为当天日期减1，为前一天价格，日期为当天价格加1，为后一天价格，然后进行计算；参数1为列名，参数2为往下第n行（可选，默认为1），参数3为默认值（当往下第n行为NULL时候，取默认值，如不指定，则为NULL）参数1为列名，参数2为往上第n行（可选，默认为1），参数3为默认值（当往上第n行为NULL时候，取默认值，如不指定，则为NULL）有如下数据，记录每天每只股票的收盘价格，请查出每只股票的波峰和波谷的日期和价格。

1、首先对原始数据进行处理，生成主播上下播的日志数据，同时增加人数变化字段，主播上播为1，主播下播-1。查询每分钟最大在线人数，这里处理逻辑基本和最高峰在线人数是一致的，但有一个问题，如果某一分钟内无任何操作记录，则不会出现该分钟的数据，我们就统计不到。3、根据以上SQL生成每分钟一条记录的心跳记录，心跳记录change_cnt= 0，代表没有主播上播，也没有主播下播。有如下数据记录直播平台主播上播及下播时间，根据该数据计算出平台每分钟的直播人数。2、生成0~24*60-1条记录数据。

1、首先对原始数据进行处理，生成主播上下播的日志数据，同时增加人数变化字段，主播上播为1，主播下播-1。新数据包含 user_name,action_time,day_time,change_cnt。有如下数据记录直播平台主播上播及下播时间，根据该数据计算出平台当天最高峰同时直播人数。查询每天同时最大人数，考察的是对拉链转化为日志的处理方式以及聚合函数的累积计算。这里用主播名称做统计，前提是主播名称唯一，不能出现重复，平台有名称重复验证。3、求取累计求和中的最大值，即为当天最高峰同时直播人数。

我们首先按照brand分组，根据start_date、end_date 升序排列，按照start_date 进行了升序排列，所以当前行的start_date一定晚于前一行的start_date，对当前行的start_date 和截止到上一行的最大end_date进行比较，如果当前行的start_date 小于等于截止到前一行最大end_date 代表有交叉，可以合并，否则代表不可合并。取每个组内的start_day 的最小值作为活动开始日期，end_day的最大值作为活动结束日期，得到最终结果。

Spark Core（实现了 Spark 的基本功能，包含RDD、任务调度、内存管理、错误恢复、与存储系统交互等模块。数据结构：RDD）Spark SQL（可以使用 SQL操作数据。数据结构：Dataset/DataFrame = RDD + Schema）（用来操作数据流的 API。数据结构：DStream = Seq[RDD]）（提供常见的机器学习(ML)功能的程序库。包括分类、回归、聚类、协同过滤等，还提供了模型评估、数据导入等额外的支持功能。数据结构：RDD或者DataFrame）

是一个Data Lakes的开源方案，Hudi是Hadoop Updates and Incrementals的简写，它是由Uber开发并开源的Data Lakes解决方案。Hudi能够基于HDFS之上管理大型分析数据集，可以对数据进行插入、更新、增量消费等操作，主要目的是高效减少摄取过程中的数据延迟。

基于 MPP 架构的高性能、实时的分析型数据库，以极速易用的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。

Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。

Apache Hadoop Yarn(Yet Another Reasource Negotiator，另一种资源协调者)是Hadoop2.x版本后使用的资源管理器，可以为上层应用提供统一的资源管理平台。

Reduce端每个Reduce task会从每个map task所在的节点上拉取落地的磁盘文件对应的分区数据，对于每个Reduce task来说，从各个节点上拉取到多个分区数据后，每个分区内的数据按照key分组有序，但是总体来看这些分区文件中key数据不是全局有序状态（分区数据内部有序，外部无序）。第一次排序发生在Map阶段的磁盘溢写时：当MapReduce的环形缓冲区达到溢写阈值时，在数据刷写到磁盘之前，会对数据按照key的字典序进行快速排序，以确保每个分区内的数据有序。

Hadoop Distributed File System - 分布式文件存储系统，解决海量数据存储问题。

比如最近七天的订单量，一个促销活动的购买转化率等。一个指标具体到计算实施，主要有以下几部分组成：指标加工逻辑，比如count ,sum, avg维度，比如按部门、地域进行指标统计，对应sql中的group by业务限定/修饰词，比如以不同的支付渠道来算对应的指标，微信支付的订单退款率，支付宝支付的订单退款率。对应sql中的where。

大多数人不懂，不会，不做，才是你的机会，你得行动，不能畏首畏尾大数据等于趋势，一个向上趋势的行业会让你赚得比其他行业多做减法，才是真本事。想知道一个人是菜鸟还是高手，就看他到底是做加法还是做减法。世界上没有白吃的午餐，无非是舍弃哪个换取哪个，想什么都揽到怀里，注定会一事无成。懂得舍弃才是大智慧，懂得放弃的，才是高手。你观察所有的新人，无一不是在做加法，生怕漏掉一点点。一个刚学做饭的厨师，恨不得把所有的调料都给你加进去；一个刚摸相机的摄影师，生怕漏掉任何一个细节；一个初学美工的新人，做出来的一定是花花绿绿一闪