Lansonli（蓝深李）的博客

利用框架的力量，看懂游戏规则，才是入行的前提大多数人不懂，不会，不做，才是你的机会，你得行动，不能畏首畏尾选择才是拉差距关键，风向，比你流的汗水重要一万倍，逆风划船要累死人的为什么选择学习大数据开发，不选择Java开发？借棋弈做比喻，智商高的不要选择五子琪，要选择围棋，它能长久地吸引你。不都是在棋盘上一颗黑子一颗白子地下吗?因为围棋更复杂，能够掌握如此复杂的技艺、产生稳定输出的棋手、让我们更佩服。选择学习大数据开发也如此，能让你的职业生涯走得更远，少走弯路。

推荐其关注的用户喜欢的音乐名称，主要是考察表之间的关联，并考察行转列及去重相关操作。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的最大值作为活动结束日期，得到最终结果。

以上体系架构图就是滴滴整体业务架构图，底层是数据源，中间也做了数据仓库分层，包括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（地区）等，这些维度表就组成了每个订单发生时所处的环境，即何人、何时、在何地下单了何种产品。这种建模方法的出发点是整合数据，其目的是将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。：业务过程可以概括为一个个不可拆分的行为事件，例如电商交易中的下单，取消订单，付款，退单等，都是业务过程。事实通常对应业务过程，而维度通常对应业务过程发生时所处的环境。

本场景中订单和婴儿信息存储在MySQL中，对于订单表，为了方便进行分析，我们让它关联上其对应的婴儿信息，构成一张宽表。在这个例子中，我们将创建三张数据表，其中一张orders_dataset_tmp是导入数据的临时表，其他两张作为源表，体验淘宝母婴订单实时查询。导入完成之后，在SQLConsole页签中，输入如下SQL，然后单击执行，将订单数据导入到订单源表orders_dataset 中。选中代码，点击左上角运行，完成表的创建。点击提交申请后，等待审批完成，点击执行变更，返回如下结果，数据导入完成。

由于商品名称及商品价格数据存储在另一张维度表 dimension_table中，我们需要将结果视图和 dimension_table进行JOIN操作，并将「商品销售量」、「商品价格」相乘计算出「商品销售额」，并提取结果中的商品可读名称信息作为结果表。本场景将以阿里云实时计算Flink版为基础，使用Flink自带的MySQL Connector连接RDS云数据库实例，并以一个实时商品销售数据统计的例子尝试上手Connector的数据捕获、数据写入等功能。选中代码，点击调试，观察控制台的输出结果。

MySQL CDC源表在正则匹配表名时，会将您填写的 database-name，table-name 通过字符串 \\.（VVR 8.0.1前使用字符.）连接成为一个全路径的正则表达式，然后使用该正则表达式和MySQL数据库中表的全限定名进行正则匹配。MySQL的CDC源表，即MySQL的流式源表，会先读取数据库的历史全量数据，并平滑切换到Binlog读取上，保证不多读一条也不少读一条数据。在读完chunk的数据之前，chunk的数据会先缓存在内存中，因此chunk 太大，可能导致内存OOM。

Flink CDC 基于数据库日志的 Change Data Caputre 技术，实现了全量和增量的一体化读取能力，并借助 Flink 优秀的管道能力和丰富的上下游生态，支持捕获多种数据库的变更，并将这些变更实时同步到下游存储。目前，Flink CDC 的上游已经支持了 MySQL、MariaDB、PG、Oracle、MongoDB 等丰富的数据源，对 Oceanbase、TiDB、SQLServer 等数据库的支持也已经在社区的规划中。的技术，我们都可以称之为 CDC。

点击确定后，Flink开发控制台会解析UDF文件中是否使用了Flink UDF、UDAF和UDTF接口的类，并自动提取类名，填充到Function Name字段中。进入阿里云Flink开发平台，点击左侧导航栏SQL开发，点击左侧的函数页签，单击注册UDF，将udx.zip上传，如下图所示。其中udfs.py udafs.py udtfs.py分别对应了UDSF、UDAF、UDTF三个函数的示例。点击创建函数，可以看到函数页签下出现了udx目录，下面有三个自定义函数，此时自定义函数创建完成。

在目前1.15版本的 Flink 体系中，内置的系统函数没有像 Hive 内置的函数那么丰富，比如 Hive 中常见的 get_json_object 之类的，Flink 都是没有的，但是 Flink 提供了插件化 Module 的能力，能扩充一些 UDF，下一篇文章会进行介绍。由于精确函数应用一定会带上 Catalog 或者数据库名称，所以 Flink 中的精确函数引用一定是指向临时性 Catalog 函数或 Catalog 函数的。系统内置函数可以直接在 Flink 官网进行查询，这里就不多进行介绍。

4.后面几个以此类推，直到Event Time为：1648197590000的数据进来的时候，前一条数据的WaterMark为1648197589000，于是更新当前的WaterMark为1648197590000，Flink认为1648197590000之前的数据都已经到达，且达到了窗口的触发条件，开始进行计算。但是由于网络、分布式等原因，会导致数据乱序的情况。通过watermark来解决，简单来说就是延迟窗口关闭的时间，等一会迟到的数据，窗口关闭不在依据数据的时间，而是到达的watermark的时间。

在流处理应用中，数据是连续不断的，因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次，但是有时我们需要做一些聚合类的处理，例如：在过去的1分钟内有多少用户点击了我们的网页。在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行计算。Flink 认为 Batch 是 Streaming 的一个特例，所以 Flink 底层引擎是一个流式引擎，在上面实现了流处理和批处理。而窗口（window）就是从 Streaming 到 Batch 的一个桥梁。

以事件时间举个例子，如果只是数据携带了时间，Flink 也消费了这个数据，但是在 Flink 中没有使用数据的这个时间作为计算的触发条件，也不能把这个 Flink 任务叫做事件时间的任务。：举个例子，比如用户可以自定义每隔 10s 的本地时间，或者消费到的数据的时间戳每增大 10s，就把计算结果输出一次，时间在此类应用中也是一种标识任务进度的作用。事件时间：指的是数据本身携带的时间，这个时间是在事件产生时的时间，而且在 Flink SQL 触发计算时，也使用数据本身携带的时间。它是时间的最简单概念。

因为这个表的元数据没有被持久化。那么在这个 Flink session 中，你的任务访问到这个表时，访问到的永远是临时表（即相同名称的表，临时表会屏蔽永久表）。在这个作业中，订单表作为驱动源表输入，用户信息表作为静态维表，统计结果表作为作业最终输出。表可以是临时的，并与单个 Flink session（可以理解为 Flink 任务运行一次就是一个 session）的生命周期绑定。任务状态变成运行中后，点击任务进入任务详情，点击作业探查，点击运行日志下的Task Managers，点击Path，ID实例。

编写Flink程序，读取表中的数据，并根据表中的字段信息进行统计每个单词出现的数量。编写Flink程序，接收socket的单词数据，并以逗号进行单词拆分打印。注意：socketTextStream后的ip是云服务器ecs的公网ip。注意read_text_file后的地址要与实际地址对应。安装nc: yum install -y nc）（如果没有安装可以使用yum。开启netcat，监听。在ecs依次发送单词。

因此，Flink 是一个用于在无界和有界数据流上进行有状态计算的通用的处理框架，它既具有处理无界流的复杂功能，也具有专门的运算符来高效地处理有界流。在 Flink 中，认为所有的数据本质上都是随时间产生的流数据，把批数据看作是流数据的特例，只不过流数据是一个无界的数据流，而批数据是一个有界的数据流（例如固定大小的数据集）。（阿里云Flink全托管空间预装的是Python3.7版本，因此需要我们在Python3.7版本开发代码），如下：（需要提前安装python3.7，资料中有安装包）

在阿里云官网首页，点击右上角控制台，进入工作台。直接点击我的资源下的Flink，或者搜索Flink，进入Flink控制台。点击实例id，进入Flink项目空间。在左侧导航栏，单击SQL开发。在作业草稿下，新建文件夹：阿里云Flink。在此文件夹下，创建文件夹：快速入门。在快速入门文件夹下，单击新建作业草稿。单击空白的流作业草稿。单击下一步。在新建文件草稿对话框，填写作业信息。作业的名称。作业名称在当前项目中必须保持唯一。指定该作业的代码文件所属的文件夹。还可以在现有文件夹右侧，单击。

在实时计算控制台上，可以在Flink全托管页签，单击目标工作空间的更多>工作空间详情，查看空间名称、工作空间ID、OSS Bucket、SLB IP、专有网络名称和ID、虚拟交换机等信息。flink-savepoints：在Flink全托管开发控制台上单击Savepoint，会触发Savepoint操作，最终的Savepoint文件会被存储到该目录。在实时计算控制台上，可以在Flink全托管页签，单击目标工作空间的更多>释放资源，释放按量付费的资源，释放后将不再进行计费。

如果不小心删除了AliyunStreamAsiDefaultRole角色或者变更了授权策略导致Flink全托管服务不可用，可以按照以下操作步骤先删除资源编排服务ROS的资源栈、RAM角色和RAM权限策略后，登录实时计算控制台，重新授权。阿里云账号被正确授予AliyunStreamAsiDefaultRole角色后，Flink全托管服务才能正常地调用专有网络VPC、云服务器ECS、负载均衡SLB和应用实时监控服务ARMS等相关服务来启动Flink全托管的相关组件。3、在授权请求页面，单击前往RAM进行授权。

通过了解实时计算Flink版产品基本概念的层次结构，为后期作业开发、作业部署、作业运维和安全管理等操作提供思路。实时计算Flink版产品基本概念的层次结构如下图所示。工作空间（Workspace）工作空间是Flink全托管管理项目空间的基本单元，每个工作空间的计算资源隔离，开发控制台相互独立。创建成功后工作空间名称和OSS存储地址不可修改。项目空间（Namespace）项目空间是Flink全托管管理作业的基本单元，我们的所有配置、作业、权限均在单个项目空间下进行。

可以配置智能调优，无人值守自动监控并调整作业资源分配，并可以在指定时间段应用对应的资源计划，帮助我们平稳顺利地度过业务洪峰，同时最大程度的节省成本。更好的引擎性能和更细粒度资源配置使得整体TCO优于开源，且灵活的付费模式以及智能扩缩容，进一步提高了资源使用的精细程度。提供完整的系统检查点和作业快照生命周期管理，提供状态兼容性检查和状态数据迁移，以最大可能的复用原来的状态数据。精细化资源管理，大幅度降低成本。程序员、甚至是数据分析师都可以完成调试和上线的动作，大幅减少调试测试成本，提高作业上线速度和质量。