一文读懂全球化系统中的日期时间处理问题_ 字节跳动技术团队的博客

1. 重要性

日期时间的处理，一直是计算机系统中看似简单，实则经常爆雷的问题。

例如，每隔几年，都会爆出的「千年虫问题」的各种变种，通常因为系统在设计之初，没有设计好日期时间的数据存储方式，或者低估了产品设计的生命周期，导致最初选型的数据结构不够用了。

千年虫问题：

年纪大的程序员，都知道千年虫问题。在 2000 年之前，很多系统用 2 位数字表示年份，这样 99 年是它能表达的最大数值。因此 1999 年之后的一年，在这些系统中是没有定义的，甚至可能出现多种奇怪的情况，例如“1900”、“1:00”、“19:0”（为什么？感兴趣的读者可以自己推测）。

如果说，「千年虫」是在时间维度上缺乏前瞻性的设计导致的，那么另一种缺乏前瞻性的问题，是空间维度的，即产品全球化、跨时区带来的问题。

全球化的产品中，如果时间的处理没有遵循统一的标准，会让整个系统充斥着难以理解和维护的时间转换。各种接口的对接文档，都不得不明确说明「这个接口的时间是什么时区的？需要如何处理？」后端服务如果需要跨国部署在多个大洲的机房时，因为服务器的时区不同，需要做大量的改造。

遗憾的是，大多情况下，产品不会一开始就有「全球化」属性。所以在一开始，产研团队都不会重视全球化的设计问题，很容易留下缺乏前瞻性的设计问题。

通常情况下，我们都不鼓励「过度设计」。然而，日期时间的设计，是最不怕「过度」的。这时因为，在技术上实现一个前瞻的时间日期方案，成本并不高；但如果一开始的设计不够，后期的升级和数据迁移工作，却是伤筋动骨的。

2. 如何表达时间和日期？

2.1 时间日期的传递：用字符串

在微服务之间，以及在前后端之间，建议用字符串传递日期时间。字符串清晰易读，易于人工调试，带来的开销通常也完全可以接受。（带大量时间数据的接口，建议考虑用 Unix Timestamp。）

如果用字符串，格式就不要自己发明了。有个非常明确的国际标准：ISO 8601（wikipedia: https://en.wikipedia.org/wiki/ISO_8601）

下面举例是符合规范的常用格式：

仅日期：2022-02-09
UTC 日期时间：2022-02-09T12:36:42Z
特定时区的日期时间：2022-02-09T20:36:42+08:00
精度更高的时间：2022-02-09T12:36:42.123456789Z

注意，MySQL 中使用的字符串格式（如 2022-02-09 12:36:42）并不符合规范，不建议使用。

2.2 时间日期的存储：关注 MySQL 中的 DateTime

不同数据库在时间日期相关对象的处理差异很大。这里单说 MySQL，因为坑不小。

MySQL 的 DateTime 数据在存储时 并不包含时区信息 ，因此，在读取时也不会做任何时区的转换。

同时，每个 MySQL 连接会话，都有「会话时区」的概念，但这个概念只影响 MySQL 的 NOW() 等有关当前时间的函数的行为，对数据中已经保存的 DateTime 没有任何影响。

SET time_zone =  '+00:00' ;
UPDATE tab SET datetime_colume = '2020-01-01 00:00:00';
SET time_zone =  '+08:00' ;  -- 换一个会话时区
SELECT datetime_colume FROM tab;
-- 返回值仍然是 '2020-01-01 00:00:00'，和写入的数据一致，和会话时间无关
---------
SET time_zone =  '+00:00' ;
SELECT NOW();   -- 假设返回 '2022-01-01 00:00:00'
UPDATE tab SET datetime_colume = NOW();   -- 存入的是 '2022-01-01 00:00:00'
SET time_zone =  '+08:00' ;  -- 换一个会话时区
SELECT NOW();   -- '2022-01-01 08:00:00' 根据时区变化了
SELECT datetime_colume FROM tab;   -- '2022-01-01 00:00:00' 已经写入的不会变

2.3 时间日期的计算：语言原生的 DateTime 类型

各语言一般都提供了原生的 DateTime 数据类型，以表达绝对的日期时间，并且都支持上面 ISO 8601 规范的解析和格式化。

处理相对时区时，各种语言通常都是使用操作系统的时区数据库，来转化为绝对时区。时区数据库需要在联网情况下，由操作系统负责定时更新。

2.4 万能的 Unix Timestamp

Unix Timestamp 在存储、计算、传递环节都可以使用，可谓万能。它唯独不适合表达纪念日日期。

它通过一个数值表示了一个绝对时间与 Unix Epoch 时间（定义为 1970-01-01T00:00:00Z）的差值秒数。Unix Timestamp 本身已经表达了绝对时间，并不需要时区信息。

使用 Unix Timestamp 时，应特别注意选用合适的数值类型，它会影响时间表示的范围。稍不留神，你就可能种下一个新的千年虫。

用有符号 int32 ，最多表示到 2038 年。MySQL 的 TIMESTAMP 类型也是它，一个千年虫变种
用有符号 int64 ，并使用 9 位 10 进制定点小数位时，就是 Golang 的 UnixNano() ，可以表示 1678 年至 2262 年
一般不会用浮点数表示，因为浮点数的精度不固定

3. 产品视角的日期时间设计

本着不重不漏的原则，我们可以按如下表格划分产品中的所有日期时间对象：

	日期+时间	仅时间	仅日期
不指明时区，无需根据用户所在时区做转换	① 表示本地的确定时间点	③ 表示本地重复性时间	⑤ 表示纪念日、节日
指明时区，需根据用户所在时区做转换	② 表示全球唯一确定时间点	④ 表示全球可理解的重复性时间	❌ 不存在的场景

下面逐一解释这五种场景。

3.1 表示全球唯一确定时间点（表中的 ②）

信息量包含「年月日-时分秒-时区」。这样，就可以完全确定历史长河中的一个无歧义的时间点。这个时间点是完全客观的，和访问的用户地理位置无关，和服务器的地理位置无关，和什么都无关。

产品表现上，通常会根据查看者所在的时区来重新调整时间的显示。

用途举例：

单个事件发生的时间。如 2022 年冬奥会开幕式的时间：2022 年 2 月 4 日，20 点整，+0800 时区。一个英国人看电视转播预告时，会看到开幕式的转播时间是：2022 年 2 月 4 日中午 12 点整。这体现了根据查看者做时间的转换。

3.2 表示本地的确定时间点（表中的 ①）

包含「年月日-时分秒」，因为没有时区信息，所以它本身并不能确定一个精确的时间点，而是只在特定的情境下才有意义。

所谓特定的情境，是因为业务场景中蕴含了时区的信息，并且是大家公认的共识。因此，本质上它仍然表示了一个绝对时间。在产品表现上，因为对时区的共识，所以不需要根据查看者的时区来调整时间的展示。

用途举例：

在非国际化的产品中，明确知道用户所在的时区，那么去掉时区是最简单的处理方式，可以省去很多麻烦。
对于时区有其他约定俗成的理解。例如：飞机的起飞降落时间，酒店的入住离店时间，一定是按照飞机起落地、酒店坐落地当地时区来表达的。在所有订票网站上，都会按照这个规则显示时间，不论访问的用户身处哪个时区。

3.3 表示重复性时间（表中的 ③ 和 ④）

和前两类相比，去掉了「日期」这个信息，是为了描述重复性的日程。它可以是指明了时区的，也可以不指明时区，而基于人们对时区的共识去理解。

用途举例：

每周三 8:00+0800 开会，如果这可以是个跨国的会议，大家都能理解正确的时间。这时，产品表现上应该注意根据查看者来调整显示。
每周三 8:00 起飞的航班，航班起飞地的时区是蕴含的共识。产品表现中不必根据查看者的时区调整显示。

3.4 纪念日日期（表中的 ⑤）

日期对象几乎只有一个有意义的用途：表示纪念日/节日。它不会包含时区信息。

认为「日期」只能用于「纪念日」，有些绝对了。但我确实查阅了很多资料，也没有看到任何非「纪念日」用途的日期。

小吴的生日是 3 月 11 日，那么不管他在中国还是美国，都会在 3 月 11 日这一天过生日。
每年 12 月 25 日是西方的圣诞节，各个国家都在 12 月 25 日这一天庆祝，虽然它们并不在同一个时区。

产品体现上，不需要根据时区调整日期的显示。本质上，「纪念日」的逻辑，其实是人脑的不严谨导致的一种习惯，是不严谨、不客观的习惯。不包含时区信息，就是为了满足这种不严谨的习惯。

3.5 区分「纪念日日期」与「精度不高的绝对时间」

上面说过，日期对象不能包含时区。你可能会问，我需要表示“北京时间 2022 年 3 月 22 日”呢？答案是：这不是一个日期，而是一个「精度不高的绝对时间」。

很多情况下，当你想用日期时，其实很可能需要的是个「精度不高的绝对时间」。在飞书人力套件的业务中，经常会遇到这种场景。

例如，一个在美国的同学与一个在日本的同学，都在 2022 年 3 月 22 日这天从公司离职了，由同一个在北京的 HR 办理离职事项。

	美国同学（-5:00时区）	日本同学（+9:00时区）
员工理解的最后工作日	2022-03-22
员工理解的系统中离职生效时间	2022-03-23 00:00:00（各自的本地时间）
北京的HR理解的系统中离职生效时间	2022-03-23 13:00:00 +0800	2022-03-22 23:00:00 +0800
服务器执行离职相关系统动作的绝对时间（以UTC计）	2022-03-23 05:00:00 UTC	2022-03-22 15:00:00 UTC

可见，从我们用户视角理解的「一个事件发生的日期」，其实是我们忽略了时间的精度。在产品全球化之前，我们通过一些默认的简化，忽略了时间精度的问题（例如把时间都填成 00:00:00）。一旦面临产品的全球化，就需要补齐时间、提高精度。

而补齐时间、提高精度的方式，需要根据具体的产品形态具体考虑、明确定义。

例如，在上述离职场景下，就需要按照这个公司对离职的定义来补充，可以是当地时间当天的 23:59:59，也可以是当天下班时间，如 17:00:00。

又比如，对于跨团队的业务，例如一个同学的上级汇报线从一个美国 Leader 转到一个日本 Leader，那么为了避免歧义，通常会约定一个确定的生效时区，如统一按照公司的总部所在地的时间来计算。

4. 日期时间的技术实现

4.1 确定时区的 DateTime

适用于上面的 ①②③④ 四种场景。

所有后端暴露的接口中的时间对象，全部以 UTC 时间表示。

同时，所有后端在存储、计算、传输时间时，也统一使用 UTC 时间。由于 DB 存储时间时，时区信息会被丢掉，因此应保证丢掉的时区，是大家明确约定清楚的无歧义的，即 UTC。这样一来，DB 中的所有时间字段也都没有歧义。

接口内部产生的时间，例如 CreatedAt 、 UpdatedAt 时间，都应该转换为 UTC 再落盘。如果直接使用了 MySQL 的 NOW() 函数，应确保 MySQL Session 的时区设置正确。

在前端或 BFF 负责处理用户输入的时间，以及展示给客户看到的时间。包括两个步骤：

处理“精度不高的时间”问题。 比如：员工异动的生效时间，用户只设置到“天”的精度。那么如果不跨国，可以补全用户会话时区的 00:00:00 为精确生效时间；如果跨国，那就看客户如何定义，以及产品给客户怎样的灵活性：例如，可以以客户公司总部所在地的时区的 00:00:00 为精确生效的时间。
时区转换。 注意，这里不一定是使用用户的会话时区来转换。如前面介绍的飞机火车宾馆的预定时间，就要以预定当地的时区来转换。

上述两点，是一定需要在产品设计中定义清晰的，切忌含糊不清。

不要较真儿抬杠的几点：

由于历史原因，DB 里已经采用北京时间保存了，那么我们可以约定+0800 时区是我们所有后端接口的时间。只要用一个确定的绝对时区，就不会有歧义，不必非要时 UTC。
也可以在后端接口的网关层处理时间转换。不要较真那算不算 BFF，我们需要的是，时区转换逻辑应严禁深入到后端的下层去。

4.2 不带时区的 Date

适用于上面的 ⑤，即纪念日场景。

输入或展示时，都不对日期做任何处理。日期对象直接保存在 DB 中。

只有真正的纪念日有必要用这种方式，应当非常谨慎。例如保存一个联系人的生日时。

5. 关于时区的特殊处理

5.1 时区的不确定性

使用绝对的时差来表示时区，例如：“东 8 区”表示比世界协调时间（UTC）早 8 个小时的时区。这是个客观的时区。

很多时候，我们关注的是一个城市或地区的时区。例如：Asia/Shanghai 表示中国时间；三字母的缩写 EST 表示美国东部标准时间。注意，这些根据地理位置定义的时区的时差是会发生变化的，变化因素包括：可能受到当地政策的影响，或夏令时影响。

对于历史的时间，地理时区是可以确定客观时区的，因为没有人会重新定义已经过去的时间。

对于未来的时间，地理时区并不能确定客观时区。因此，如果一个未来的事件是按照非绝对时区约定的，那么它很可能变化。并且， 我们的产品需要考虑到处理这种变化。

例如，中国员工发起一个“每天早 8 点”的跨国会议，那么在美国，由于夏令时的改变，冬天开会的时间和夏天是不一样的。反之，美国员工发起的一个“每天早 8 点”的跨国会议，由于美国夏令时的变化，对中国员工的时间也是夏天和冬天不一样的。

5.2 夏令时

某些国家在夏天，会把时间调快一小时（提前一小时）。这表现为，同一个地区，在冬天和夏天用不同的绝对时区。

这样做，是因为夏天白天很长，调整后会在白天的更早的时段上班，从而下班后有更长的天亮的时间。注意，并不是把 10 点上班调整到 9 点上班，而是全社会重新定义了 10 点提前了一小时。

一个具体的例子，在美国：

在 2021 年 3 月 14 日凌晨 1:59:59 后，下一秒就是凌晨 3:00:00。因此，美国的 2021 年 3 月 14 日凌晨 2:10:00 这个时间 实际上不存在 。为了兼容，根据 RFC5545，如果日程约在了这个不存在的时间，会认为是 3:10:00。

在 2021 年 11 月 7 日凌晨 1:59:59 后，下一秒是凌晨 1:00:00。因此，美国的 2021 年 11 月 7 日凌晨 1:10:00 这个时间 实际上会出现两次 。为了避免歧义，根据 RFC5545，看到这个时间时，会认为是靠前的时间点。因此，除非用别国的时区来约日程，否则，美国老板是不可能约你在重叠的第二个小时内开会的。

6. 阅读更多及参考文献

Wikipedia: ISO8601 - 用字符串表达各种时间对象的标准

https://en.wikipedia.org/wiki/ISO_8601

RFC3339 - 互联网上关于时间和日期实现的通用建议

https://www.rfc-editor.org/rfc/rfc3339

RFC5545 - iCalendar 互联网日历应用的规范

https://datatracker.ietf.org/doc/html/rfc5545

Stackoverflow: Daylight saving time and time zone best practices [closed] - 技术实现建议

https://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices

Stackoverflow: How to store repeating dates keeping in mind daylight saving time - 技术实现建议

https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35

Medium: How to Deal with Date and Time across Time Zones - 技术实现建议

https://medium.com/@vivekmadurai/how-to-deal-with-date-and-time-across-time-zones-39b1bd747f35

Microsoft365: Behavior and format options of the Date and Time field - 微软的时间和日期字段的文档

https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/customize/behavior-format-date-time-field?view=op-9-1

Time Change 2021 in the United States - 美国 2021 年夏令时的调整方式

https://www.timeanddate.com/time/change/usa?year=2021

（上下滑动查看全部）

我们来自 字节跳动飞书技术团队飞书人力套件团队 ，目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。我们关注的产品领域主要在企业经验管理软件上，包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统，也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统。欢迎加入我们。

开发工程师/资深后端开发工程师

负责企业 SaaS 产品的后端架构设计与研发，为海内外租户及用户提供优质的信息服务和极致体验；
参与产品需求的讨论和规划、功能定义等，帮助职能部门梳理业务思路，固化工作流，提高效率；
协助团队攻克各种大数据、高并发、数据隔离等方面的技术难点攻坚；
参与制定团队研发流程规范，帮助团队落地并提升整体的研发质量；

本科及以上学历，计算机、通信等相关专业，五年以上工作经验；
熟练掌握 Linux 环境下的 Go/Python/C/C++/Java 等 1 至 2 种以上语言；
扎实的技术基础，了解微服务架构的技术挑战，并有对应的解决方案；
较好的产品意识，愿意将产品效果做为工作最重要的驱动因素；
熟悉业务架构设计理论，熟悉行业常见的架构方案；
积极乐观，认真负责，乐于协作。

官网投递：

https://jobs.bytedance.com/referral/pc/position/detail/?token=MTsxNjUwNjE3NDE3MjM4OzY5NDg5NzU0ODAyNjM0MTEyMzA7NzA1MDM3MjgzOTc4ODc3NTY5NA

点击“阅读原文”了解更多岗位！

动手点关注干货不迷路‍‍1. 背景火山引擎对于用户敏感数据尤为重视，在火山引擎提供的数据分析产品中，广泛采用差分隐私技术对用户敏感信息进行保护。此类数据产品通常构建于 ClickHouse 等数据引擎之上，以 SQL 查询方式来执行计算逻辑，且查询逻辑往往较为复杂，因此对差分隐私的应用提出了以下要求：零改造、零感知：最大程度避免影响业务现有查询方式，最好做到业务零感知、零改造；良好、灵活的适配性：... 动手点关注干货不迷路‍‍项目简介ByConity 是字节跳动开源的云原生数据仓库，它采用计算-存储分离的架构，支持多个关键功能特性，如计算存储分离、弹性扩缩容、租户资源隔离和数据读写的强一致性等。通过利用主流的 OLAP 引擎优化，如列存储、向量化执行、MPP 执行、查询优化等，ByConity 可以提供优异的读写性能。项目背景ByConity 的背景可以追溯到 2018 年，当时字节跳动开始在内... 动手点关注干货不迷路‍‍Apache Iceberg 是一种开源数据 Lakehouse 表格式，提供强大的功能和开放的生态系统，如：Time travel，ACID 事务，partition evolution，schema evolution 等功能。本文将讨论火山引擎EMR团队针对 Iceberg 组件的优化思路，通过引入索引来提高查询性能。采用 Iceberg 构建数据湖仓火山引擎 E-M... 动手点关注干货不迷路近日，CVPR Workshop 下属的 NTIRE2023大赛公布比赛结果，在双目超分双三次插值保真赛道和360° 全景图像超分赛道上，火山引擎多媒体实验室凭借自主研发的算法获得了双料冠军，技术能力达到行业领先水平。NTIRE（New Trends in Image Restoration and Enhancement）是新兴的计算机视觉国际竞赛，每年在模式识别和机器视觉... 动手点关注干货不迷路本文只用于技术交流，仅代表作者个人观点。作为 CEO，Sam 将 OpenAI 的内部氛围组织的很好，有位 OpenAI 的前员工告诉拾象团队，当 2018 年 GPT-2 的论文被驳回时，Sam 在团队周会上将拒信的内容朗读给所有员工，并告诉大家在通往成功的路上总会有阻碍，但是大家一定要有信念。本文试图从技术角度，借助 GPT 的公开资料，解读如何入门 GPT 以及相关大语言... 动手点关注干货不迷路前言近日，第 17 届世界编码器大赛 MSU 2022 公布硬件编码器比赛结果，在 60 fps（帧率）的超快视频编码赛道上，火山引擎多媒体实验室自主研发的 BVE 1.1 编码器表现突出，荣获最佳 FPGA 编码器（各项指标大幅领先）；并在所有硬件编码器中，技术指标获得一项第一和两项第二，技术能力达到行业领先水平。MSU 编码器比赛是由国际机构主办和测评，是视频编码业内影响力... 动手点关注干货不迷路1. SDK简介图片在业务应用场景是一个常见的元素，veImageX（简称ImageX）为业务提供了灵活、高效的一站式图片处理解决方案，包括了服务端 SDK、上传 SDK 和客户端图片加载 SDK。本文就来介绍下 iOS 客户端图片加载 SDK（下文中简称 SDK），SDK 主要提供图片网络加载、图像解码、图片基础处理与变换以及图片服务质量监控上报等能力。1.1 业内主流开源... 动手点关注干货不迷路I. 传统数仓的演进：云数仓近年来，随着数据“爆炸式”的增长，越来越多的数据被产生、收集和存储。而挖掘海量数据中的真实价值，从其中提取商机并洞见未来，则成了现代企业和组织不可忽视的命题。随着数据量级和复杂度的增大，数据分析处理的技术架构也在不断演进。在面对海量数据分析时，传统 OLAP 技术架构中的痛点变得越来越明显，如扩容缩容耗时长，导致资源利用率偏低，成本居高不下；以及运维... 动手点关注干货不迷路项目地址：https://github.com/bytedance/primus随着机器学习的发展，模型及训练模型所需的数据量越来越大，也都趋向于通过分布式训练实现。而算法工程师通常需要对这些分布式框架涉及到的底层文件存储和调度系统有较深的理解，才能够快速批量开启模型训练，保证资源利用率。目前业界有很多类似的框架，如 TonY、TensorFlowOnSpark，Kubeflo... 动手点关注干货不迷路前言我们知道 Go 语言的三位领导者中有两位来自 Plan 9 项目，这直接导致了 Go 语言的汇编采用了比较有个性的 Plan 9 风格。不过，我们不能因咽废食而放弃无所不能的汇编。1、 Go 汇编基础知识1.1、通用寄存器不同体系结构的 CPU，其内部寄存器的数量、种类以及名称可能大不相同，这里我们只介绍 AMD64 的寄存器。AMD64 有 20 多个可以直接在汇编代码中... 动手点关注干货不迷路背景DataLeap 作为一站式数据中台套件，汇集了字节内部多年积累的数据集成、开发、运维、治理、资产、安全等全套数据中台建设的经验，助力企业客户提升数据研发治理效率、降低管理成本。Data Catalog 是一种元数据管理的服务，会收集技术元数据，并在其基础上提供更丰富的业务上下文与语义，通常支持元数据编目、查找、详情浏览等功能。目前 Data Catalog 作为火山引擎大... 动手点关注干货不迷路本文重点探讨全部模块化后带来的依赖解析瓶颈，主要包括对头文件增量编译分析等内容。优化方案基于 Swift Toolchain 源码，本文不再探讨 Toolchain 相关基本概念及配置流程等，仅聚焦方案本身。背景随着混编落地的业务场景越来越多，越来越大，开发中出现的性能痛点开始显现，问题很明显集中在被 Swift 环境所依赖的 OC 仓的头文件改动上。因此基建架构把重点放在接口... 动手点关注干货不迷路简介CloudWeGo - Shmipc是字节跳动服务框架团队研发的高性能进程间通讯库，它基于共享内存构建，具有零拷贝的特点，同时它引入的同步机制具有批量收割 IO 的能力，相对于其他进程间通讯方式能明显提升性能。在字节内部，Shmipc 应用于 Service Mesh 场景下，mesh proxy 进程与业务逻辑进程、与通用 sidecar 进程的通讯，在大包场景和 I... 动手点关注干货不迷路火山引擎湖仓一体分析服务 LAS（Lakehouse Analytics Service），是面向湖仓一体架构的 Serverless 数据处理分析服务，提供字节跳动最佳实践的一站式 EB 级海量数据存储计算和交互分析能力，兼容 Spark、Presto 生态，帮助企业轻松构建智能实时湖仓。LAS 服务是什么？LAS 有哪些优化特性？本文将从基础概念、数据库内核特性优化、数据服... 动手点关注干货不迷路背景每天在世界各地都有海量用户在短视频 App 上分享充满创意的视频或是生活中的精彩故事。由于使用者所在的环境不可控（高铁、电梯等弱网环境），若直接播放原始画质的视频，可能导致观看影片的过程中出现卡顿甚至无法播放的情形，导致观影感受不佳。为了让不同网络条件的使用者，都能顺畅地观看这些视频，每一条视频的发布，都需要经过转码的过程，生成不同档位的视频，即使用户在网络不好的环境中，也... 动手点关注干货不迷路导读：经过十多年的发展，数据治理在传统行业以及新兴互联网公司都已经产生落地实践。字节跳动也在探索一种分布式的数据治理方式。本篇内容来源于火山引擎超话数据直播活动的回顾，将从以下四个部分展开分享：字节的挑战与实践数据治理的发展与分布式分布式自治架构分布式自治核心能力字节的挑战与实践首先来看一个问题：“一家公司，数据体系要怎么搭建？”方案一：整体规划，系统架构驱动方案二：问... 动手点关注干货不迷路近期 NLP 界的大语言模型 (Large LM) 引领了一波研究热潮。有关大语言模型介绍的博文众多、此处推荐一下 Stanford 为此专门设计的一门课程（仅开源了讲义）。Stanford CS324 - Large Language Modelsstanford-cs324.github.io/winter2022/大语言模型当然也影响到了机器翻译领域。近一个月里 arx... 动手点关注干货不迷路写在前面Go 为了自身 goroutine 执行和调度的效率，自身在 runtime 中实现了一套 goroutine 的调度器，下面通过一段简单的代码展示一下 Go 应用程序在运行时的 goroutine，方便大家更好的理解。The Go scheduler is part of the Go runtime, and the Go runtime is built into... 动手点关注干货不迷路DataLeap 是火山引擎数智平台 VeDI 旗下的大数据研发治理套件产品，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。数据血缘是帮助用户找数据、理解数据以及使数据发挥价值的基础能力。基于字节跳动内部沉淀的数据治理经验，火山引擎 DataLeap 具备完备的数据血缘能力，本文将从数... 动手点关注干货不迷路世界杯的编码技术挑战对于世界杯这样的大型体育赛事而言，视频编码算法既要在高速运动、复杂纹理的场景下确保直播内容的清晰度和流畅度，保障用户的观赛体验，又要兼顾码率、延迟等对网络传输层面尤为敏感的指标。另外，抖音实现了业界首次的世界杯比赛支持 4K HDR 10-bit 直播，其内容信息量相较于以往有极大提升，对编码器的实时性提出了更高要求。火山引擎如何完成这个挑战BVC 编码器长...