- 博客(532)
- 资源 (6)
- 收藏
- 关注
RSS订阅
原创 数据专题导航
目录一 维度模型系列二 FLink(1.16.0)源码系列Kimball维度模型之构建数据仓库先决条件-CSDN博客Kimball维度模型之数据仓库分层架构_kimball 企业级数仓架构-CSDN博客Kimball维度模型之构建数据仓库流程解析-CSDN博客Kimball维度模型之数据仓库迭代SOP-CSDN博客Kimball维度模型之数据仓库模型治理-CSDN博客Kimball维度模型之数据质量治理体系建设-CSDN博客Kimball维度模型之业务过程-CSDN博客Kimball维度模型之事务事实表-C
2024-04-29 18:54:50
376
5
原创 Kimball维度模型之构建数据仓库先决条件
成功的DW/BI项目通常共享上述一系列关键特征，而失败的项目则往往面临各种问题，其中一些问题可以总结自数据仓库专家Kimball的观点。失败的DW/BI项目因素：失败的项目往往出现在业务发起人缺乏深刻业务理解或技术发起人无法有效沟通业务需求的情况下。成功的项目通常建立在业务和技术团队紧密协作的基础上，而弱势的业务或技术发起人可能导致沟通障碍和项目目标的偏离。例子：在一个以技术为主导的项目中，业务发起人可能无法有效传达业务需求，导致最终交付的数据仓库无法满足真实业务场景。
2024-03-09 02:42:50
1113
原创 设计模式之中介者模式
中介者模式是一种行为型设计模式，它定义了一个中介对象，用于封装一组对象之间的交互。通过中介者，多个对象不再相互引用，而是通过中介者进行通信，从而达到降低耦合的目的。中介者模式的核心思想是将多个对象之间的复杂通信逻辑集中到一个中介者对象中，避免了对象之间的直接依赖关系，使对象的关系结构变得简单且可控。中介者设计模式通过引入一个中介者对象来简化对象之间的交互，降低了对象之间的耦合度。在复杂的系统中，它有效地减少了对象之间的依赖，使系统的扩展和维护更加容易。
2024-10-25 00:29:56
774
原创 设计模式之状态模式
状态设计模式（State Pattern）是一种行为型设计模式，它允许对象在其内部状态变化时改变其行为，对象看起来好像修改了它的类。换句话说，状态模式让一个对象在其状态改变时表现出不同的行为，这种模式通过将每个状态封装成一个类来实现。状态模式和策略模式很相似，也是将类的"状态"封装了起来，在执行动作时进行自动的转换，从而实现，类在不同状态下的同一动作显示出不同结果。它与策略模式的区别在于，这种转换是"自动"，"无意识"的。当一个对象的行为依赖于其状态，并且在运行时可以改变状态。
2024-10-23 19:19:48
383
原创 设计模式之过滤器模式
过滤器设计模式提供了一种方式来根据不同的条件标准对对象进行过滤处理。在该模式中，每一个条件（标准）被封装为一个单独的类，这些条件可以被单独使用，也可以组合使用（例如通过逻辑“与”、逻辑“或”等），从而灵活地筛选符合条件的对象集合。有大量对象集合，需要根据不同标准进行筛选。筛选条件是动态的或组合复杂度较高。希望筛选逻辑与对象本身的结构解耦，从而保持代码清晰、可扩展。过滤器设计模式通过将筛选条件封装成独立的标准类，解决了对象集合的多条件筛选问题。
2024-10-21 19:09:24
822
原创 设计模式之迭代器模式
迭代器模式为遍历集合中的元素提供了一种通用接口。其核心思想是，将集合的遍历逻辑与集合对象的实现分离。通过迭代器，客户端代码无需关心集合的底层实现方式（如数组、链表等），就能顺序地访问集合的每一个元素。迭代器设计模式提供了在不暴露对象内部结构的情况下，顺序访问对象集合的有效方法。通过分离集合的实现和遍历逻辑，迭代器模式不仅提高了代码的灵活性，还增强了代码的可维护性。在 Java 集合框架中，迭代器模式有着广泛的应用场景，它极大简化了集合的遍历操作，降低了代码复杂性。
2024-10-18 17:02:16
718
原创 设计模式之建造者模式
建造者模式（Builder Pattern）是一种创建型设计模式，旨在将对象的构造过程与其表示分离，使得同样的构建过程可以创建不同的对象。它通过分步构建复杂对象，允许对象的构建更加灵活且易于维护，特别是在需要创建具有多种不同配置的复杂对象时，使用建造者模式可以有效减少代码的复杂度和错误。建造者模式的核心思想是通过一个Builder对象来逐步构造最终的产品，而不是通过复杂的构造函数或者多参数初始化。每个构建步骤都相对独立，最终通过调用build()方法返回完整的对象。
2024-10-16 20:37:39
914
原创 设计模式之组合模式
组合设计模式（Composite Pattern）是一种结构型设计模式，它通过将对象组合成树形结构来表示“部分-整体”的层次结构，使客户端可以以统一的方式处理单个对象和组合对象。该模式允许客户端忽略对象组合和单个对象的差异，简化了复杂结构的操作。组合模式的核心在于树状结构，每个节点要么是叶子节点（即单个对象），要么是包含子节点的组合节点。无论节点是叶子还是组合，客户端都可以对它们执行相同的操作。组合模式特别适用于那些需要频繁操作对象集合和层次结构的场景，能够极大简化代码的复杂性。
2024-10-15 11:41:45
748
原创 设计模式之装饰器模式
装饰器模式(Decorator Pattern)是一种结构型设计模式，它允许在不改变对象自身的情况下动态地为对象添加新的功能。装饰器模式通过将对象包装在另一个对象中来实现功能的扩展，既保持了类的封闭性，又提高了代码的灵活性。装饰器模式的核心思想是通过“对象包装”来为现有对象提供额外的行为，而不是通过继承或修改类来扩展功能。每个装饰器都实现了与被装饰对象相同的接口，并且可以在保持接口不变的情况下，向对象添加不同的职责。多个装饰器还可以层层嵌套，动态组合不同的行为。这种设计方式符合开闭原则（OCP）
2024-09-30 18:20:05
706
原创 设计模式之备忘录模式
备忘录设计模式（Memento Pattern）是一种行为型设计模式，旨在允许对象在不暴露其内部状态的情况下保存和恢复其先前的状态。这种模式特别适合需要实现“撤销”操作的场景，如文本编辑器中的撤销功能、游戏中的状态保存等。备忘录模式主要有三个角色：发起人（Originator）、备忘录（Memento）和管理者（Caretaker）。发起人负责创建和恢复备忘录，备忘录则用于存储发起人的内部状态，而管理者负责管理备忘录对象的生命周期。需要保存对象状态以支持撤销和重做的系统。
2024-09-30 14:20:06
393
原创 设计模式之模板模式
模板设计模式（Template Method Pattern）是一种行为型设计模式，它定义了一个操作中的算法骨架，而将一些步骤的实现延迟到子类中。通过使用模板方法，子类可以在不改变算法结构的情况下，重新定义算法的某些步骤。模板设计模式通过定义算法骨架，并将具体步骤的实现延迟到子类中，提供了代码复用和灵活性。钩子方法的引入进一步增强了模式的灵活性，使子类可以选择性地覆盖某些步骤，甚至改变算法的执行流程。在实际开发中，模板设计模式非常适用于具有相似算法流程但部分实现细节需要自定义的场景。
2024-09-30 13:09:34
638
原创 设计模式之享元模式
享元设计模式（Flyweight Pattern）是一种结构型设计模式，旨在通过共享对象来有效地支持大量细粒度的对象。它的核心思想是尽量减少内存使用，尤其是在需要创建大量对象时，避免不必要的内存开销。可以理解为享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。享元模式下通常包含内部状态和外部状态概念，在使用时需要确保享元对象的内部状态是共享的，而外部状态是独立于对象的。内部状态：在享元对象中可以共享的状态，通常是不可变的。例如，字符的字体和样式。外部状态。
2024-09-30 12:04:22
860
原创 设计模式之适配器模式
适配器模式（Adapter Pattern）是一种结构型设计模式，旨在将一个类的接口转换为客户端所期待的接口，使得原本由于接口不兼容而无法在一起工作的类能够协同工作。适配器模式的核心思想是“适配”，即通过创建一个适配器类，使得两个不兼容的类能够合作。适配器模式可以被比作生活中的电源适配器，不同国家的插座标准不同，电器设备无法直接使用，但通过适配器（比如从三脚插头转换为两脚插头），电器可以正常工作。软件开发中，适配器的作用类似，用于解决接口不兼容问题。
2024-09-29 10:49:09
1105
原创 设计模式之原型模式
原型设计模式（Prototype Design Pattern）是一种创建型设计模式，其核心思想是通过复制（克隆）现有对象来创建新对象，而不是通过传统的实例化方式。这个模式在系统中需要创建大量相似对象时非常有用，可以避免反复创建同一类对象，并且在某些情况下还能提高性能。在原型模式中，对象实现一个原型接口，该接口规定了一个clone方法，用于返回对象自身的副本。这样，客户端就可以通过克隆的方式来创建对象，而不需要直接依赖具体类的构造函数。Prototype（原型接口）：定义一个用于克隆自身的接口。
2024-08-08 21:02:35
696
原创 设计模式之外观模式
外观设计模式通过提供一个高层接口，简化了复杂系统的使用，使得客户端代码更加简洁和易于维护。它隐藏了系统的复杂性，减少了子系统之间的耦合，并且可以通过引入新的外观类来适应系统的变化。外观模式在大型系统、编译器、多媒体处理和数据库操作等场景中非常有用。通过理解和应用外观模式，可以有效地提高软件系统的设计质量和可维护性。
2024-08-07 18:32:35
534
原创 设计模式之责任链模式
责任链模式（Chain of Responsibility Pattern）是一种行为设计模式，旨在将请求的发送者和接收者解耦，从而实现请求的动态处理。该模式将多个处理者（Handler）链接成一条链，并将请求沿着链传递，直到有一个处理者能够处理该请求为止。这样，每个处理者只需关注自己能处理的请求，而不必关心整个处理链的其他部分。适用场景当有多个对象可以处理一个请求，但并不确定哪个对象会处理该请求时。当希望在运行时动态地指定处理请求的对象时。
2024-08-01 19:07:55
274
原创 Java使用Process和ProcessBuilder调用外部任务
Process类是 Java 中用于表示和管理已经启动的操作系统进程的工具。通过Process对象，开发者可以与子进程进行交互，例如获取进程的输入、输出和错误流，发送输入数据，读取输出结果，监视进程的状态，等待进程结束以及获取退出码。它提供了方法来终止进程、检查进程是否仍在运行以及获取进程的执行结果。Process类在创建和管理系统进程时非常有用，特别是在需要与外部程序进行通信的应用场景中。常见的方法包括waitFor()和destroy()。类是 Java 中用于创建和管理操作系统进程的工具。
2024-07-22 19:25:43
1164
原创 设计模式之命令模式
命令模式通过将请求封装为对象来解耦请求的发送者和执行者，使代码更灵活、更具扩展性。它在需要对操作进行记录、撤销、重做以及支持事务操作时特别有用。然而，命令模式也会增加系统中类的数量，并且每一个具体的命令类都会导致代码的膨胀，因此在使用时需要权衡。
2024-07-20 21:13:48
628
原创 设计模式之工厂模式
工厂设计模式（Factory Pattern）是一种创建型设计模式，它帮助我们在不明确具体类的情况下创建对象。这个模式的主要动机是将对象的创建过程与其表示相分离，目的是使系统更具灵活性和可扩展性。在面向对象编程中，我们经常需要创建对象，这些对象可能来自不同的类，并且每个类的实例化过程可能会很复杂。如果我们在代码中直接使用这些类来创建对象，代码会变得难以维护和扩展。为了克服这些问题，工厂设计模式提供了一种解决方案，通过定义一个创建对象的接口，让子类决定实例化哪一个类，从而把对象的创建与使用分离开来。
2024-07-20 21:10:33
1062
原创 设计模式之单例模式
单例模式是一种创建型设计模式，确保一个类在应用程序的生命周期中仅有一个实例，并提供一个全局访问点。它通过私有构造函数、防止直接实例化，静态方法获取唯一实例，保证全局唯一性。单例模式常用于配置管理、日志记录、数据库连接池、线程池等需要共享资源的场景，具有减少资源浪费、确保状态一致性、简化全局访问等优点。特别是在多线程环境中，通过适当的同步机制，单例模式可以确保线程安全，避免实例重复创建的问题。
2024-07-20 21:08:14
527
原创 设计模式之策略模式
// 私有构造函数防止外部实例化@Override@Override@Override通过策略模式，我们可以很容易实现登录用户本地缓存功能，同时如果我们想扩展缓存策略，也可以定义Redis缓存策略，只需要通过配置变更就可以让程序运行依赖新的缓存策略。策略模式通过将算法封装在独立的策略类中，使得算法的切换和扩展变得更加容易，符合面向对象设计的开闭原则。
2024-07-20 21:05:01
643
原创 vue+element-ui容器布局
外层容器。当子元素中包含或时，全部子元素会垂直上下排列，否则会水平左右排列。：顶栏容器。：侧边栏容器。：主要区域容器。：底栏容器。以上组件采用了 flex 布局，使用前请确定目标浏览器是否兼容。此外，的子元素只能是后四者，后四者的父元素也只能是。
2024-05-26 03:38:10
536
原创 利用Spring Initializr初始化Springboot项目
Idea企业版本到期了，最近想设计一个数据开发平台，需要创建SpringBoot项目，本文算是个流水账，记录通过官网。创建Springboot项目的过程。
2024-05-14 12:35:43
280
原创 Flink基于开源类库实现FlinkSQL自定义UDAF类型推断异常解决
根据报错信息我们可以发现，这里因为在UDAF中引入了开源类库RoaringBitmap导致FlinkSQL UDAF编译类型推断报错，比如。 那么解决方案很简单，FlinkSQL UDF要求数据类型必须与预定义的类型一致，那么我们通过注解。 只需要加一个注解就可以解决问题。可以很清晰的说明是由于引用了。
2024-05-07 23:40:44
429
原创 FlinkSQL基于RoaringBitmap的UDAF实现UV指标
RoaringBitmap 是一种压缩的位图数据结构，用于存储大量稀疏或密集的整数集合。它结合了位图的优点（如快速查询和更新）和压缩技术的优势（如空间效率），能够在保持高效性能的同时，减少内存占用。 在 Flink 中，UDAF 通常需要实现几个接口，如getValue()等。/*** 创建基于RoaringBitmap的累加器* @returnreturn acc;} /*** 向累加器添加元素} /*** 撤回元素} /*** 合并多个累加器} } /**
2024-05-07 23:25:06
867
原创 FlinkSQL优化器查询重写技术引发UDF翻倍调用问题分析及解决方案
Flink SQL无疑是实时数仓领域一个最耀眼的明星，他对于统一流批一体的设计可谓是居功至伟。鉴于Flink SQL在实时数仓领域的卓越表现，我们很有必要对Flink SQL在ETL场景下的表现要有深刻的理解。本文聚焦于Flink SQL UDF使用场景下由于SQL重写导致UDF翻倍调用的原理分析及对应的应对策略。
2024-05-05 23:04:49
1001
原创 实时数仓之Flink实现版本维表数据的Redis全局缓存
在维度模型中，数据通常被划分为维度和事实两大阵营，而维度通常是渐变(Kimball维度模型领域通常称呼这种维度为缓慢变化维度或者又被称为渐变维度)的，这种场景下，要求我们在维表建模过程中，要更多的考虑维度版本的变化，保存维度变化的维表模型可以方便在ETL和应用过程中可以让事实数据匹配自己对应的维度信息，这种场景在实时数仓构建过程中是比较常见的。通常在维度建模过程中，针对渐变维表建模的方式主要有以下几种方案：Kimball渐变维表类型2(可以认为是方案)技术方案。
2024-05-04 23:11:47
1052
1
原创 Flink源码分析(13)Flink SQL客户端启动过程源码分析
Flink SQL Client启动是通过sql-client.sh脚本入口进行启动，因此本文的源码入口从sql-client.sh脚本开始。sql-client.sh跟踪sql-client.sh脚本发现该脚本实际调用了进行环境的初始化操作。下面让我们从方法入手分析 这里的DEFAULT_TERMINAL_FACTORY指的是jLine客户端继续下面追踪追踪源码发现最后都会进入执行追踪发现调用了这里的parser对象是SqlMultiLineParser的实例这里的par
2024-04-29 18:30:42
362
2
原创 Flink源码分析(12)Flink SQL执行流程源码分析
Flink SQL模块的真正目的是将用户提交的SQL语句转换成Flink DataStream的形式，最后提交生成的DataStream算子到执行引擎去执行的过程。，由于executeSql()方法在内部的调用逻辑上可以覆盖sqlQuery(sql)方法，最终会汇总到同一条执行路径，因此关于Flink SQL执行流程源码分析从。调用Calcite的SQL解析模块对SQL语句执行解析，返回SqlNode对象即Calcite的SQL语法树对象。在这里完成了SQL的第二步工作，SQL校验的完成，接着调用。
2024-04-29 14:36:23
1031
2
原创 Flink源码分析(11)Flink SQL执行环境初始化源码分析
上述为Flink SQL执行环境初始化相关的内容，首先了解上述源码流程对于后边理解Flink SQL的执行流程会有很大的帮助。然后创建了StreamTableEnvironment。首先来追踪planner创建过程都做了哪些操作。创建了SQL planner； 因此这里入口代码选择从。
2024-04-29 01:39:44
273
3
原创 Flink源码分析(10)Flink Checkpoint源码分析
以上内容就是Flink Checkpoint源码调用流程，理解Checkpoint原理对于理解Flink应用具有较大的帮助，以上内容由本人追踪源码理解，有误欢迎指正。对于某个checkpoint，当接收到所有operator的确认消息之时，发送消息通知各个operator，checkpoint已完成。**triggerCheckpoint()**是一个重要的节点方法，通过调用。从这里开始，与从构建Dispatcher调用链结合到一起了，即代码。保存已完成和正在进行中的checkpoint的相关信息。
2024-04-28 23:23:16
728
原创 Flink源码分析(6)TaskManager启动源码分析
从堆栈追踪可以发现，Flink Per-job下的TaskManager的任务类也回到了TaskManagerRunner，与Standalne一致。可以发现，在这里创建了TaskManagerRunner，并且启动TaskManagerRunner。方法触发，通过追踪发现TaskManager的启动类为。4.2 首先创建了TaskExecutor，继续追踪。这里的堆栈调用链路比较长，但总体思想就是想RM注册。方法继续分析TaskManager的启动源码。这里启动了taskSlotTable，同时在。
2024-04-28 03:22:57
1242
原创 Flink源码分析(5)JobMaster启动源码分析
Flink JobMaster源码启动入口从Dispatcher.runJob()方法处开始，下面让我们一起进入到JobMaster的源码分析中。这里启动jobmaster服务，注册心跳同时创建了监听服务，在jobmaster内部创建了slotpool，用于维护整个任务的资源。内执行了jobgraph到executiongraph的转换操作，这块内容见ExecutionGraph源码分析；方法，跟踪jobmaster启动过程中都做了哪些具体操作。之后会跳转到Task.run()开始执行Task。
2024-04-26 00:53:15
915
1
原创 Flink源码分析(3)Flink-Per-job Yarn集群启动前期准备源码分析
这段代码在启动ApplicationMaster之前做了各种检查，包括用户权限、内存、路径、yarn队列等等，在检查条件通过后通过。发现createClusterDescriptor方法是一个抽象方法，因为本文追踪Per-Job模式，所以由。在startAppMaster对启动应用设计的环境信息、配置信息和依赖信息和安全信息等进行了详细的配置，其中。Yarn集群描述器封装了yarn运行的基本配置信息，返回赋值到clusterDescriptor。向yarn提交任务；是启动AM的入口类，继续追踪。
2024-04-25 20:18:07
688
1
原创 Kimball维度模型之数据仓库模型治理
本文所描述的场景，其核心在于对现存数据仓库任务产生的潜在影响。而与之形成鲜明对比的是，笔者另外两篇文章的核心观点是：模型的发布或变更并不会对存量数据造成任何影响。这种差异为我们提供了一个更为宏观的视角，即篇头所提及的三篇文章共同构成了数据仓库建设的顶层逻辑。只要我们稍微深入学习Kimball的设计原则，并结合笔者的这三篇文章作为理论支撑，按照这些规范来设计数据仓库，就能构建出一个相对健壮、稳定的数据架构。事实上，平地起高楼并非想象中的那么困难，关键在于我们是否掌握了正确的方法和原则。
2024-04-11 18:23:36
1178
原创 一种可复用的业务监控类数据产品层级结构设计
BI产品模板化是Kimball大神针对DW/BI项目前端应用提出的一种顶层设计模式()，但在实际工作中，无论是产品经理的经验欠缺还是技术人员归纳意识不够，我们很难看到那种让人耳目一新的产品设计出现。在本文笔者希望从一个顶层视角来审视关于如何优雅的实现业务监控类产品设计方案，主要包括前端布局设计、接口设计和底层数据结构设计三个方面，目标站在业务视角来设计数据应用产品。
2024-04-07 16:09:24
345
实时数仓模拟流式数据源代码
2024-03-15
p8670579_112010_LINUX
2014-08-23
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人