[toc]
库
安装库
1 | pip install requests |
批量安装
1 | pip install -r requirements.txt |
requirements.txt
1 | requests==2.31.0 |
查看安装结果
1 | pip show python-dotenv |
[toc]
1 | pip install requests |
1 | pip install -r requirements.txt |
requirements.txt
1 | requests==2.31.0 |
1 | pip show python-dotenv |
1 | import scala.jdk.CollectionConverters._ |
1 | import scala.collection.mutable |
底层实现是单向链表,所以慎用通过index的遍历方式,因为每次都要从头节点开始查。IndexedSeq可以使用
1 | for (i until nums.lenght) { |
如果需要遍历List,又同时需要获取到index,可以改用迭代或zipWithIndex
1 | // 迭代 |
IndexedSeq 的实现主要包括:
udf 的类型只能是class, 可以使object,至于为什么之前不行,还不清楚
scala使用java 的List需要添加前缀 util.List
1 | import scala.collection.JavaConversions._ |
1 | val failingBids = ArrayBuffer[BidRecord]() |
[toc]
1 | val array = Array("a", "b", "c") |
Scala 2.13 是一次重要的里程碑式更新,它主要在三个方面与 2.12 版本拉开了距离:彻底重构了集合框架、将标准库模块化,以及为 Scala 3 的发布清除了关键的技术障碍。下表清晰地总结了它们的主要差异:
| 对比维度 | Scala 2.13 | Scala 2.12 |
|---|---|---|
| 集合库 (Collections) | 全面改革:为更简洁、安全、高效的集合层次结构铺平了道路-。Traversable 被移除,Seq 类型得到了精化等-。 |
稳定且成熟的经典集合体系-。 |
| 标准库结构 | 深度模块化 (Modularized):将庞大的标准库拆分为更小、职责单一的模块,减少了核心依赖并提升了可维护性-。 | 庞大的单体库(monolithic)。 |
| 二进制兼容性 | 与 2.12 不兼容:使用 _2.13 后缀标识,使用 2.13 库的 JAR 文件无法在 2.12 项目中运行-。 |
使用 _2.12 后缀,内部小版本之间(如 2.12.x)保持兼容-。 |
| 性能与优化 | 编译提速:编译器本身速度提升了约 5% 至 10%-。 运行时优化:为 Scala 3 和 Java 未来的新特性做准备。 | 已具备的基础优化功能,如 lambda 的优化-。 |
| 语言演进 | 弃用并清除“杂质”:弃用和移除了许多过时或罕见的特性,如 Symbol 字面量和早期初始化器,为 Scala 3 清扫道路-。 |
包含更多历史遗留的语言特性。 |
| 迁移与兼容 | 编译器帮助迁移:通过 -Xmigration 标志提供详细的迁移建议,并提供了辅助跨版本构建的工具,帮助开发者平稳过渡-。 |
使用标准的构建工具配置。 |
| 新功能与 API | 标准库增强:集合操作 (如 groupMap)-、StringOps 解析功能-和资源管理尝试,让代码更健壮和现代。 |
无相关新增特性。 |
这是 2.13 中最引人注目、影响最广泛的变化。新的集合库更加一致、安全且高效-。
Traversable,使得整个集合体系的继承关系更简单清晰-。Seq 类型明确:scala.Seq 在 2.13 中被明确为 scala.collection.immutable.Seq 的别名,避免了与 mutable.Seq 的混淆-。ArrayDeque,在特定操作上性能优于 ArrayBuffer,为开发者提供了更优的数据结构选择-。groupMap、groupMapReduce 等方法,让对集合的分组聚合操作更富表达力-。2.13 将原本庞大的标准库拆解为多个小模块,使依赖关系更清晰,并降低了应用启动时的内存占用-。
scala-library: 核心库。包含最基础的Any、AnyRef、Product等。scala-reflect: 反射库。只有在需要显式使用反射 API 时才需引入。scala-compiler: 编译器库。仅用于构建编译器插件等开发工具。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-。
Scala 3 是一次跨越式的进化,而非在 Scala 2.13 基础上的增量更新。它对语言的核心进行了重新构思和设计,旨在提供更强的表现力、更高的安全性和更流畅的开发体验。
下面,我将从关键特性、兼容性以及迁移路径等几个方面,为你详细梳理这两个版本之间的核心区别。
相比 Scala 2.13,Scala 3 在多个方面进行了重塑,引入了一系列强大的新特性。
Scala 3 将 Scala 2 中功能复杂的 implicit 拆解为几个更专注、语义更清晰的语法结构,降低了学习和使用难度-13。
| 特性 | Scala 2.13 | Scala 3 | 说明 |
|---|---|---|---|
| 类型类实例 | implicit val |
given |
given 专门用于定义“给定实例”-10-13 |
| 上下文参数 | implicit 参数列表 |
using 子句 |
using 专用于声明上下文参数-10-13 |
| 扩展方法 | implicit class |
extension |
内置的 extension 语法,声明和使用都更清晰-10-13 |
| 隐式转换 | implicit def |
given Conversion[A, B] |
将隐式转换能力收窄到一个明确的类型 Conversion 中-10-11 |
Scala 3 引入了众多在类型理论中早已存在但尚未进入主流工业语言的高级特性,让类型系统更加强大和灵活。
| 特性 | 说明 | 在 Scala 2.13 中的替代方案 |
|---|---|---|
交集类型 (A & B) |
表示既是 A 类型又是 B 类型的值,是类型安全的组合--27 |
A with B (复合类型),语义和行为不同 |
| **联合类型 (`A | B`)** | 表示是 A 类型或 B 类型的值,极大增强灵活性--27 |
不透明类型别名 (opaque type) |
隐藏具体实现,只提供抽象接口,实现零成本抽象--11-27 | AnyVal 值类或密封类,但性能或表达力有限 |
枚举 (enum) |
统一了枚举和代数数据类型,比组合 sealed class + case object 更简洁--11 |
使用 sealed trait/class 和 case object |
导出子句 (export) |
避免样板代码,轻松实现聚合或委托模式-27 | 手动编写委托方法 |
| 依赖函数类型 | 结果类型依赖于参数值,表达能力更强- | 没有 |
| 类型 Lambda | 内联的、类型级别的高阶函数,简洁地操作类型构造器-11-27 | 需要额外的辅助 trait,代码冗长 |
Scala 3 提供了一系列可选的新语法,让代码更简洁。
new 关键字可选:创建类的实例时,可以省略 new,使代码更简洁-13。if, while, for 等控制结构可以省略括号-13。package object-27。虽然变化巨大,但 Scala 3 的官方文档特别强调了它实现了与 Scala 2.13 在运行时的互操作性。
最关键的一点是,Scala 3 和 Scala 2.13 共享相同的应用程序二进制接口 (ABI)-1。这意味着:
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 中已弃用或使用频率低的特性。
| 类别 | 移除特性 | 简要说明 | 替代方案 |
|---|---|---|---|
| 语言构造 | do-while 循环 |
语法与新的控制结构冲突,被移除-21 | 使用 while 循环替代-21 |
| 过程语法 | 没有等号和返回类型、只有方法体的写法被移除-33 | 明确指定 : Unit = |
|
| 类型系统 | 存在类型 | 已被联合类型、交集类型等新概念取代-21 | 使用 Scala 3 的新类型特性 |
any2stringadd 隐式转换 |
可能导致不易察觉的字符串拼接错误,被移除-21 | 显式使用 .toString |
|
| 其他语法 | 符号字面量 ('xyz) |
符号字面量语法被移除-21 | 使用字符串字面量 "xyz"-21 |
视图界定 (A <% B) |
视图界定语法不再支持-19 | 使用普通参数或上下文界定 | |
| 早期初始化器 | 这种写法不再被支持-21 | 使用特质参数- | |
| 自动应用 | 无参方法 def foo 调用时可省略括号,Scala 3 强制显式写出foo() 以增加代码确定性-21 |
显式写出括号 |
总的来说,从 Scala 2.13 到 Scala 3 的演进,是一场深入内核的重大升级。它以打破非必要的源码兼容性为代价,换来了一个在类型系统、语法一致性和开发体验上更加强大的语言。这一点从官方为现有用户提供了完善的迁移工具链,并为 Scala 2.13 和 3 的代码提供了无缝的运行时互操作性,便可见一斑-1-3。
希望这份详细的对比能帮助你更好地理解 Scala 的演进。如果想了解特定特性(比如枚举或给定实例)的具体用法,我们可以继续深入探讨~
1 | val hasAnnotation = annotations.exists( |
这段 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 宏或编译时反射中,用于检查某个元素是否被特定注解标记。
它的优点是内网传输,即时性强,丢失风险小
pv、mv、mc
**协作流程:**我们的流程是这样的,先由需求方提出需求交给业务 PM,业务 PM 在埋点平台做埋点配置,埋点平台根据配置生成代码给到客户端 RD,客户端RD 使用埋点 SDK 做埋点实施,实施之后由客户端 QA 来测试校验然后上线,接着数据组 RD 使用日志数据表加工数据将数据结果交付给数据组 PM,最后将结果交付给需求方。这里简单说下埋点配置环节,在美团外卖是由业务 PM 来统一负责,同时数据团队做规范的指导、定期参加一些埋点评审。
**埋点规范:**主要是约束一些字段的上报方法,包括字段名称、上报时机等。
**问题排查:**在问题排查方面,我们有一套比较完整埋点问题追踪流程,也是方便后续做埋点问题的复盘。
**埋点 SLA:**我们专门制定了一套埋点 SLA ( Service Level Agreement - 服务级别协议 ) 机制,目前这块主要由客户端 RD 和 QA 来保证 SLA,业务 PM 根据埋点重要性提供需要保证的 SLA 列表,数据组提供监控工具。
前面介绍了埋点的基本信息与规范流程,这里给大家介绍一些埋点的注意事项。个人觉得做埋点还是非常需要经验的,甚至是需要更多的试错,这里给大家列了一些注意事项以供参考:
**同质参数的名称和类型保持一致:**主要就是体现在通用参数、业务参数、行为标识的统一,尽量做到事前治理,给整个的数据加工、数仓建设减轻工作量,当然在数仓加工过程中也一定要做一些容错;
**通用复用:**尽量少的创建新的事件,而是想办法复用原来的事件,方便后续的埋点管理;比如某弹窗在很多页面都出现过,弹窗模块曝光标识需要是唯一的,当它出现在不同的页面的时候,我们可以通过页面标识 page_id 来区分,而不是每出现一个新的页面就重新定义一个模块标识;
**最小粒度:**埋点定义到模块内的最小元素,可以避免重复上报;
**合并上报:**相同模块的 MV 事件可以合并上报;某一页面中一定出现的元素可以不用上报 ( 这里是指 MV 曝光事件 ),或者和 PV 时间合并上报,在 PV 中加一个字段标识即可;
**历史兼容:**不能改变已有事件标识的含义,不能改变属性标识的含义,不能改变参数值的含义;一般只做新增,不做修改,可以废弃;
**追踪回溯:**埋点设计文档可以回退到历史版本,便于排查问题。

**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层的公共维度建设。

在数仓建设中有很多原则,这里拿出其中三个在流量数仓中比较重要的原则跟大家分享下:
① 高内聚和低耦合
将业务相近或相关、粒度相同、高概率同时访问的数据放在一起。具体在流量数仓建设过程中,合理的主题划分其实就是遵循高内聚低耦合的原则。不合理的主题划分会导致数据使用成本、运维成本增大。主题划分是和业务强相关的事情,需要大家定期 review 自己的主题划分是否合理,一定要紧跟业务需求。
② 公共处理逻辑下沉且单一
越是底层公用的处理逻辑,越要放在数据底层封装与实现,不要让公共逻辑多处存在且暴露给上层的表。流量底层数据的公共处理逻辑主要是环境维度建设和归因建设。
③ 成本与性能平衡
==合理使用视图减少数据存储==
适当的进行数据冗余来换取查询和刷新性能,但不要过度冗余与数据复制。这是最通俗易懂的原则,但在流量数仓建设过程中,需要综合考虑各种使用场景,实践起来很难。美团外卖每天的数据量几百亿条,这样一份数据,如果在多处出现复制,对存储资源就是很大的浪费。成本与性能平衡确实需要多思考,在做数仓规划时就需要把这个事情考虑到。具体实践如下:

由于流量数据很多是半结构化的数据,没有分析维度的概念,所以数仓的建设时需要做很多维度建设工作。因此维度建设是整个流量数仓工作中最核心工作,同时也是最大的难点。
我们维度建设分为两种,环境维度和主题维度。