欢迎回来👏🏻！！
ER建模与维度建模：判断模型好坏，不能只数表的多少
同一份订单，在交易系统里是好几张互相连接的窄表，在分析系统里却是一张中心事实表，边上还围着一圈小表。前者侧重按业务对象和字段依赖组织数据，后者侧重按统计粒度和分析角度组织数据。这两种建模方式背后是两种数据组织思想：一种叫 ER 建模加规范化，先照业务的样子把对象和关系画清楚，再决定表怎么建；另一种叫
Hudi、Iceberg、Paimon 解决的从来不是存储，而是给数据湖加一层元数据
在对象存储上堆几千个 Parquet 文件，数据湖就算建好了吗？一旦要把它当仓库用，连“改一条订单的状态”都会很麻烦：Parquet 是列式文件，不能原地改一行，得把整个文件甚至一整个分区的文件读出来、改完再写回去，中途还得小心不能让正在跑的报表读到写了一半的数据。Hudi、Iceberg、Paim
连接数据库：客户端、USE、SHOW TABLES 与表结构
你在一张表格里见过几百行学生数据，知道它们“存在某个数据库里”，可那个数据库到底在哪、怎么用命令把它调出来？数据库不在你眼前的窗口里，它跑在另一台服务器上。想进去，得先拿连接信息连上服务器，再选定 learning 这个库，然后用 SHOW TABLES 列出表、用 DESCRIBE 看清 stud
数据仓库为什么要分层：把数据加工拆成 ODS、DWD、DWS、ADS 四道工序
一段 SQL 就能从原始数据中算出销售日报，为什么还要把数据加工拆成 ODS、DWD、DWS、ADS 四层？数据仓库分层解决的是一个很具体的问题：同一笔订单的销售额，运营看板、财务系统、活动复盘三张报表能算出三个不同的数。分层不是要把 ODS、DWD、DWS、ADS 这几个缩写背下来，而是把"从原始
SQL 与关系数据库：库、表、行、列和方言
SQL 是向数据库表达查询和数据操作要求的语言；关系数据库把数据组织在表中，表用列描述属性、用行保存记录。MySQL 是能够执行 SQL 的数据库软件，客户端则负责把语句发过去、把结果显示出来。看懂一张学生表，就能把这些名称与具体对象对应起来。 从学生表辨认库、表、行和列 把学生信息放在名为 lea
数据仓库的四个特点：从订单分析理解面向主题、集成、时变与非易失
继续介绍一下数据仓库的四个特点：面向主题、集成、时变、非易失。数据仓库把分散的业务数据整合到一起，供分析师分析业务、并为决策提供数据支持。它按要研究的业务范围安排数据，让不同来源的数据含义一致，并留下能说明过去情况的记录。 一、从订单分析看：数据仓库为什么需要这四个特点 订单系统首先要处理下单、支付
什么是数据仓库：定义、特点、使用场景与分层
数据仓库把业务数据按统一规则整理起来，并保存分析需要的历史记录，提供业务分析和决策能力。例如，我们可以用它对比不同时间、产品和客户的表现。 当分析需要关联几个系统的数据，或者比较过去和现在，数仓可以提供整理好的数据。它有面向主题、集成、时变和非易失这四个特点。理解这些特点后，还要弄清数据怎样接入、清
搭建指标语义层：从指标管理到指标语义
搭建指标语义层，不能从“给指标起一个好名字”开始，而要把一个业务指标拆成可审核的定义、可执行的计算、可连接的数据实体和可解释的使用边界。指标管理回答“这个指标是什么、谁负责、现在是否有效”；指标语义回答“在什么数据粒度、时间周期、过滤条件和关联路径下，统计维度，系统如何计算它”。只有两部分合在一起，
指标语义层开源工具全景：功能对比、优劣分析与选型指南
指标语义层的选型不能只看“能否定义指标”。先判断团队缺的是哪一层：如果需要跨平台使用统一的指标，优先评估 MetricFlow 或 Cube Core；如果希望把语义定义、指标目录和 BI 消费放在同一套产品里，Lightdash 更直接；如果指标只在 Superset 内部使用，它的轻量语义层通常
指标建设规范
一、指标定义 指标是用于衡量业务目标达成程度的可量化参数，它将抽象的业务目标转化为具体、可操作、可衡量的数值标识。在企业运营中，指标如同 “导航仪”，通过对业务数据的提炼和计算，直观展现业务的运行状态、发展趋势和存在问题。 例如， 电商企业的 “销售额” 指标，能够反映企业的销售业绩； 互联网产品的