建表注意：
数据大小，选择int bigint
索引：
1. mysql可以随意新增还好
2. doris需要在建表时就明确好可用的索引，并且注意索引最多36个字符，并且会被string类型截断，即最多能到第一个string类型的字段，且string类型最多截取前20字符

Redis HyperLogLog

学习笔记

疑问：

1. 伴生对象有什么作用

udf 的类型只能是class, 可以使object，至于为什么之前不行，还不清楚

scala使用java 的List需要添加前缀 util.List

MT外卖流量数仓建设

流量数据采集

1. 数据采集

1.1 前端埋点

• 代码埋点（MT）
  • 高度定制、控制精准、采集的数据丰富准确
  • 比较方便、灵活，能方便手机到用户在界面上的行为数据
• 可视化埋点
  • 埋点成本低，但质量不高
• 无埋点
  • 埋点成本低，但质量不高

1.2 后端埋点

它的优点是内网传输，即时性强，丢失风险小

2. 埋点类型

pv、mv、mc

3. 埋点规范与协作流程

**协作流程：**我们的流程是这样的，先由需求方提出需求交给业务 PM，业务 PM 在埋点平台做埋点配置，埋点平台根据配置生成代码给到客户端 RD，客户端RD 使用埋点 SDK 做埋点实施，实施之后由客户端 QA 来测试校验然后上线，接着数据组 RD 使用日志数据表加工数据将数据结果交付给数据组 PM，最后将结果交付给需求方。这里简单说下埋点配置环节，在美团外卖是由业务 PM 来统一负责，同时数据团队做规范的指导、定期参加一些埋点评审。

**埋点规范：**主要是约束一些字段的上报方法，包括字段名称、上报时机等。

**问题排查：**在问题排查方面，我们有一套比较完整埋点问题追踪流程，也是方便后续做埋点问题的复盘。

**埋点 SLA：**我们专门制定了一套埋点 SLA ( Service Level Agreement - 服务级别协议 ) 机制，目前这块主要由客户端 RD 和 QA 来保证 SLA，业务 PM 根据埋点重要性提供需要保证的 SLA 列表，数据组提供监控工具。

4. 埋点注意事项

前面介绍了埋点的基本信息与规范流程，这里给大家介绍一些埋点的注意事项。个人觉得做埋点还是非常需要经验的，甚至是需要更多的试错，这里给大家列了一些注意事项以供参考：

**同质参数的名称和类型保持一致：**主要就是体现在通用参数、业务参数、行为标识的统一，尽量做到事前治理，给整个的数据加工、数仓建设减轻工作量，当然在数仓加工过程中也一定要做一些容错；

**通用复用：**尽量少的创建新的事件，而是想办法复用原来的事件，方便后续的埋点管理；比如某弹窗在很多页面都出现过，弹窗模块曝光标识需要是唯一的，当它出现在不同的页面的时候，我们可以通过页面标识 page_id 来区分，而不是每出现一个新的页面就重新定义一个模块标识；

**最小粒度：**埋点定义到模块内的最小元素，可以避免重复上报；

**合并上报：**相同模块的 MV 事件可以合并上报；某一页面中一定出现的元素可以不用上报 ( 这里是指 MV 曝光事件 )，或者和 PV 时间合并上报，在 PV 中加一个字段标识即可；

**历史兼容：**不能改变已有事件标识的含义，不能改变属性标识的含义，不能改变参数值的含义；一般只做新增，不做修改，可以废弃；

**追踪回溯：**埋点设计文档可以回退到历史版本，便于排查问题。

流量数据加工

1. 流量数仓模型架构

**ODL：**Operational Data Layer，操作型数据层，这一层主要对采集到的数据进行无损着陆、基础字段清洗加工。ODL是原始日志明细宽表，完成了日志数据清洗过滤、归因建设、公共维度建设等。全链路归因建设在这一层实现。公共维度建设比如地理位置维度生成、常用维度代理键生成等，下沉到ODL来进行，降低了运维和下游使用成本，需要依赖于DIM层的环境维度表。

**IDL：**Integrated Data Layer，集成数据层，这一层在ODL之上，主要完成领域数据建模，描述业务对象属性、业务对象间的关系、业务行为属性、业务行为与业务对象的关系等。IDL层是明细宽表层，根据数据域和业务过程进行主题划分，在主题内描述业务对象和业务行为，特别是对主题内常用的扩展维度字段进行提取，并且进一步使用维度退化手段，提高明细宽表的易用性、降低使用成本。例如搜索主题筛选了用户搜索行为相关的日志，并将描述搜索业务的扩展字段进行提取。

**CDL：**Component Data Layer，元件数据层，这一层在IDL之上，主要完成分析实体识别，在主题划分基础上，形成分析实体/实体关系特征模型，对模型的指标进行加工，分为明细数据视图和聚合数据表两类。

**MDL：**Mart Data Layer，集市数据层，这一层在CDL之上，建立在主题划分基础上，通过维度层级汇总形成汇总表，通过维度主键关联形成宽表，给数据应用提供便利应用的半成品数据集，例如，常见的商家流量宽表（商家的点击、曝光、进店统计）。

**ADL：**App Data Layer，应用数据层，不属于OneData内统一建设，这一层在MDL之上，直接面对数据应用，优先使用MDL的数据，当MDL不满足时，可以向下使用CDL、IDL的数据。ADL作为数据应用的个性化数据一般不对外提供数据服务。

**DIM：**公共维度层，包括了流量数仓建设过程中使用的流量维表，分成主题维度表和环境维度表。其中主题维度表将埋点标识（用户行为标识）映射成主题维度，是IDL、CDL进行主题划分的核心维度表。环境维度表包括了流量静态属性中常见的维度，例如app名称、启动渠道、设备类型等，主要应用于ODL层的公共维度建设。

2. 流量数仓建设原则

在数仓建设中有很多原则，这里拿出其中三个在流量数仓中比较重要的原则跟大家分享下：

① 高内聚和低耦合

将业务相近或相关、粒度相同、高概率同时访问的数据放在一起。具体在流量数仓建设过程中，合理的主题划分其实就是遵循高内聚低耦合的原则。不合理的主题划分会导致数据使用成本、运维成本增大。主题划分是和业务强相关的事情，需要大家定期 review 自己的主题划分是否合理，一定要紧跟业务需求。

② 公共处理逻辑下沉且单一

越是底层公用的处理逻辑，越要放在数据底层封装与实现，不要让公共逻辑多处存在且暴露给上层的表。流量底层数据的公共处理逻辑主要是环境维度建设和归因建设。

③ 成本与性能平衡

==合理使用视图减少数据存储==

适当的进行数据冗余来换取查询和刷新性能，但不要过度冗余与数据复制。这是最通俗易懂的原则，但在流量数仓建设过程中，需要综合考虑各种使用场景，实践起来很难。美团外卖每天的数据量几百亿条，这样一份数据，如果在多处出现复制，对存储资源就是很大的浪费。成本与性能平衡确实需要多思考，在做数仓规划时就需要把这个事情考虑到。具体实践如下：

• 仅在IDL层保留了明细的日志数据，且通过维度退化手段提高明细宽表表的易用性、降低使用成本。
• IDL层的主题划分过程，如果B主题是A主题的子集，两个主题的区别在于业务描述（业务扩展维度字段）不同，那么A主题使用表来存储逻辑和数据，B主题在A主题表之上使用视图的方式存储数据加工逻辑。举例来说，在美团外卖app首页存在着很多资源位，资源位中有有一部分是营销活动的位置，那么营销活动主题就是B主题，美团外卖app首页资源位主题就是A主题。
• 在CDL层对明细数据也使用了视图，不再占用物理存储。

3. 维度建设

由于流量数据很多是半结构化的数据，没有分析维度的概念，所以数仓的建设时需要做很多维度建设工作。因此维度建设是整个流量数仓工作中最核心工作，同时也是最大的难点。

我们维度建设分为两种，环境维度和主题维度。

3.1 环境维度

3.2 主题维度

参考资料

1. 美团外卖流量数仓建设和分析应用

[toc]

2.11与2.12 的区别

1
2
3

val array = Array("a", "b", "c")
print(array.mkString)
print(array.mkString(""))

2.12与2.13的区别

整体区别

Scala 2.13 是一次重要的里程碑式更新，它主要在三个方面与 2.12 版本拉开了距离：彻底重构了集合框架、将标准库模块化，以及为 Scala 3 的发布清除了关键的技术障碍。下表清晰地总结了它们的主要差异：

🚀 核心变化深度解析

1. 集合框架 (Collections Framework)

这是 2.13 中最引人注目、影响最广泛的变化。新的集合库更加一致、安全且高效-。

• 层次结构简化：去除了冗余的顶层特质 Traversable，使得整个集合体系的继承关系更简单清晰-。
• Seq 类型明确：scala.Seq 在 2.13 中被明确为 scala.collection.immutable.Seq 的别名，避免了与 mutable.Seq 的混淆-。
• 新成员加入：引入了 ArrayDeque，在特定操作上性能优于 ArrayBuffer，为开发者提供了更优的数据结构选择-。
• API 更加直观：新增了 groupMap、groupMapReduce 等方法，让对集合的分组聚合操作更富表达力-。

2. 标准库模块化 (Modularized Standard Library)

2.13 将原本庞大的标准库拆解为多个小模块，使依赖关系更清晰，并降低了应用启动时的内存占用-。

• scala-library: 核心库。包含最基础的Any、AnyRef、Product等。
• scala-reflect: 反射库。只有在需要显式使用反射 API 时才需引入。
• scala-compiler: 编译器库。仅用于构建编译器插件等开发工具。

3. 为 Scala 3 铺平道路

2.13 在语言层面移除了大量历史遗留或将来不再支持的旧特性-。

• Symbol 字面量: 语法 'mySymbol 被弃用，推荐使用普通的 String 字面量 "mySymbol" 来代替。
• ⇒ unicode 箭头: ⇒ 被弃用，统一使用标准 ASCII 箭头 =>。
• 早期初始化器: 这种不够优雅的特性被弃用，官方推荐使用更为清晰的 trait 参数等新方式。
• do-while 循环: 这种形式的循环被移除。

📦 项目迁移与兼容性策略

由于 2.13 与 2.12 二进制不兼容-，迁移项目时需要分情况处理。

对于库的作者，需要使用 交叉编译 (Cross-building) 来发布同时兼容两个版本的 JAR 包。对于应用开发者，最直接的方式就是在依赖升级前，确保所有第三方库都已提供其 2.13 版本。

🛠️ 官方迁移工具

• -Xmigration 标志: 在 sbt 或 scalac 的选项中设置该标志，编译器会在你使用了新版 Collection 中行为可能发生变化的地方给出详细的警告或建议，帮助你定位问题-。
• scala-collection-compat 库: 这是一个由官方维护的兼容性库，提供了大量 2.13 中的新集合 API 作为“补丁”，让你在 2.12 项目中就能提前用上新语法，有助于平稳过渡-。

此外，Scala 2.13 对 JDK 的支持也更为出色。2.13.6 及更高版本支持 JDK 17-，2.13.11 及以上版本支持 JDK 21-。

2.13与3.x的区别

整体概括

Scala 3 是一次跨越式的进化，而非在 Scala 2.13 基础上的增量更新。它对语言的核心进行了重新构思和设计，旨在提供更强的表现力、更高的安全性和更流畅的开发体验。

下面，我将从关键特性、兼容性以及迁移路径等几个方面，为你详细梳理这两个版本之间的核心区别。

🚀 Scala 3 的关键进化

相比 Scala 2.13，Scala 3 在多个方面进行了重塑，引入了一系列强大的新特性。

1. 清晰的上下文抽象

Scala 3 将 Scala 2 中功能复杂的 implicit 拆解为几个更专注、语义更清晰的语法结构，降低了学习和使用难度-13。

2. 更强大的类型系统

Scala 3 引入了众多在类型理论中早已存在但尚未进入主流工业语言的高级特性，让类型系统更加强大和灵活。

3. 现代化的语法

Scala 3 提供了一系列可选的新语法，让代码更简洁。

• 可选大括号和缩进语法：你可以选择用缩进来代替大括号，像 Python 那样组织代码块-13-15。
• 显式 new 关键字可选：创建类的实例时，可以省略 new，使代码更简洁-13。
• 控制结构的简化：if, while, for 等控制结构可以省略括号-13。
• 顶级定义：可以直接在包内定义方法、字段等，代替 package object-27。

🤝 兼容性与迁移

虽然变化巨大，但 Scala 3 的官方文档特别强调了它实现了与 Scala 2.13 在运行时的互操作性。

🔄 运行时兼容：无缝互操作

最关键的一点是，Scala 3 和 Scala 2.13 共享相同的应用程序二进制接口 (ABI)-1。这意味着：

• 二进制兼容：用 Scala 2.13 编译的库，可以直接作为依赖用在 Scala 3 项目中，反之亦然-1-3。
• 一致的运行时：除少数改进（如 lazy val 的初始化性能）外，编译后的字节码行为高度一致，确保了性能的稳定-1。

🔄 源码兼容：非破坏性升级

尽管运行时兼容，但两种语言在源码层面并不完全兼容-2-15。为了让迁移过程平滑，官方提供了完善的工具链：

• 提前探测（-Xsource:3）：在 Scala 2.13 项目中添加此编译选项，编译器会提前警告不兼容未来的 Scala 3 代码，帮助你早做准备-2-30。
• 过渡版本（3.0-migration）：此编译器模式会将破坏性的源码改动降级为警告，并尝试提供自动迁移建议-2。
• 自动重写与工具：内置的迁移模式与 scalafix 等工具，可以自动将符合规则的旧代码重写为 Scala 3 风格-5-30。

需要注意的是，Scala 2 的宏（Macro）系统在 Scala 3 中被全新的编译期编程机制（如 inline）取代。这意味着任何依赖 Scala 2 宏的库都必须升级到 Scala 3 版本才能正常工作-25。官方迁移指南提供了一个检查清单，列出了第三方库的迁移状态-25。

🔄 已移除的语言特性

为了精简语言，Scala 3 移除了一些在 Scala 2.13 中已弃用或使用频率低的特性。

💎 总结

总的来说，从 Scala 2.13 到 Scala 3 的演进，是一场深入内核的重大升级。它以打破非必要的源码兼容性为代价，换来了一个在类型系统、语法一致性和开发体验上更加强大的语言。这一点从官方为现有用户提供了完善的迁移工具链，并为 Scala 2.13 和 3 的代码提供了无缝的运行时互操作性，便可见一斑-1-3。

希望这份详细的对比能帮助你更好地理解 Scala 的演进。如果想了解特定特性（比如枚举或给定实例）的具体用法，我们可以继续深入探讨～

1
2
3

val hasAnnotation = annotations.exists(
    _.tree.tpe =:= typeOf[MyAnnotation]
  )

这段 Scala 代码的作用是检查 annotations 集合中是否包含特定类型的注解:

• annotations：一个集合（如 List、Seq），其中每个元素代表一个注解。
• exists：集合的一个方法，判断是否存在至少一个元素满足给定的条件，返回布尔值。
• _：占位符，表示集合中的每个元素。
• _.tree.tpe：假设每个注解元素有一个 tree 字段（可能表示抽象语法树节点），该字段又有 tpe 字段，表示该节点的类型信息（通常是 scala.reflect.api.Types.Type）。
• =:=：类型相等性比较操作符，用于判断两个 Type 是否完全相同。
• typeOf[MyAnnotation]：通过 Scala 反射获取 MyAnnotation 的类型 Type 对象。

整句含义：
判断 annotations 集合中是否存在一个注解，其对应的语法树节点的类型与 MyAnnotation 类型完全一致。如果存在，hasAnnotation 为 true，否则为 false。

这种写法常见于 Scala 宏或编译时反射中，用于检查某个元素是否被特定注解标记。

流量-用户

待解决问题：

对于不同页面流量的统计，比如首页点击uv，没有细粒度聚合表

中间层

1. 用户页面相关数据汇总
   1. 维度：用户、端、页面
   2. 指标：曝光pv、停留时长
2. 用户模块相关数据汇总
   1. 维度：用户、端、页面、模块。
   2. 指标：曝光pv、点击pv、停留时长？

被打了一巴掌

跟警察说3句话

1. 对方当众殴打我，事实清楚，他已经违反了治安管理处罚法，我要求依法处理，并且立刻向我出具立案的回执
2. 我现在已经有点儿恶心，并且视线模糊，我要求立刻调取现场监控，并依法对我的伤情进行鉴定
3. 如果我的合法诉求不被受理，那我将通过12389热线向你们上级部门进行投诉，并追究相关的不作为责任。