IT瘾腾讯推荐

腾讯向逾 30 个 GitHub 微信相关项目发出 DMCA 通知

Sun, 18 Jan 2026 13:38:56 CST

腾讯的微信以体积随时间不断膨胀著称，这促使很多开发者对微信进行了分析，其中一部分人将他们的分析方法或相关清理工具发布在代码托管平台 GitHub 上。但本月初，腾讯法务向超过 30 个 GitHub 项目发出了 DMCA 通知，导致这些项目被迫下架。腾讯法务指控开发者们违反了 DMCA 绕过技术保护措施的条款、违反了微信禁止逆向工程条款、威胁用户隐私和安全，以及侵犯知识产权。

腾讯、苹果客服回应微信或不再支持iPhone 16

Tue, 03 Sep 2024 01:21:25 CST

9月2日，“苹果微信”这一词条登上了微博热搜。有消息称，微信可能不支持 iPhone16，并提醒用户一定不要更新系统。记者联系到苹果的官方客服，对方表示微信是客户非常常用的一个APP，iPhone新品不会把之前顾客正常使用的APP权限关闭剥夺。“这个iPhone16不支持微信的说法，我们目前没有得到官方的通知。”该客服表示。随后，记者拨打了腾讯公司的官方电话，工作人员称：“暂时没有接收到这个消息。”（正观）

腾讯蓝鲸基座实现原理（基于amd，iframe的微前端方案）

Wed, 18 Oct 2023 18:00:51 CST

theme: vue-pro

前言

过去一段时间中，我曾经研究过一段时间的微前端方案，但我更像是直接站在巨人的肩膀上去看世界，上来就是从无界乾坤这些比较火热的方案入手，因此我也不禁好奇以前实现微前端都是怎么做的呢？

正好我接触过腾讯的蓝鲸项目，其使用的便是以前的微前端实现方案，以此为入口去研究下 以前是如何实现微前端及和现在的方案有什么差别。

各位大佬阅读此文的时候最好拉一下腾讯蓝鲸的代码，结合代码阅读，不然会比较生涩难懂。

知识储备

蓝鲸CI的代码开源链接：https://github.com/TencentBlueKing/bk-ci
蓝鲸基座共支持两种接入方式： iframe 及 amd

iframe:需要提供子项目对应的链接
amd:需要将子项目打包成 amd格式的js文件并提供相关的css文件

下面的内容将基于如何实现 iframe 及 amd 两种接入方式展开：

基座原理

众所周知我们在请求一个页面的时候，往往我们会先请求下来对应的页面模板。
同样在请求微前端项目的时候也会去获取页面模板，但和一般页面不同，微前端项目会先把基座的模板请求下来。

基座模板做了什么？

(1)

模版代码：https://github.com/TencentBlueKing/bk-ci/blob/master/src/frontend/devops-nav/src/index.html

结合代码，我们可以看到蓝鲸模板的代码中包含了很多js，比如说定义js，css加载函数及cookie相关操作的代码

因此 在基座模板代码中会先定义一下基础的函数。

(2)

因为基座本身也是一个系统，他并不知道会嵌入什么子系统，因此接着就会在基座的基础上去调用接口。
下面就是基座相关接口调用的地方。
会去调用getdata函数获取当前基座所有注册的项目信息。

(3)

完成基座注册系统的数据获取之后，就会基于内容执行init函数，这一步的作用是对注册系统的数据进行分类。

可以看到这里先调用了一个getServiceObject函数，下面是代码实现：

实际上就是对我们基座注册系统数据根据amd 及 iframe两种类型进行了分类，补全amd类型所需的js，css链接，同时也生成iframe路由集合。

紧接着就是根据地址和分类后的对象，去设置当前项目信息

假如当前项目是amd模式的话就会直接加载这段js和css 那么第一个子项目就被完成挂载了。

总结

到这里基座的模板需要完成的工作就基本结束了，总结下做了什么：

定义一些基础函数包括js加载css加载等
请求当前模板涉及的系统信息
调用init函数基于请求结果做过滤，得到所有服务基础信息对象，比如有什么服务，服务的类型及服务的资源链接等，还会在这一步生成iframe路由集合

在基座模板中实际上是做了一些初始化的工作。

基座如何加载子应用？

上一部分解释了基座在页面模版中做了什么准备工作，那基座是如何完成子应用的加载呢？

这里我们来介绍下基座如何加载子应用。

基座也是一个系统，蓝鲸为例其基座是一个vue2系统，也有自己的路由等信息， 所以在基座进行路由跳转等操作的时候一样是跳转到对应的路由，不同于一般项目的是其中子路由可能指向的是嵌入的子系统

（1）

这里来看看基座的路由文件

路由： https://github.com/TencentBlueKing/bk-ci/blob/master/src/frontend/devops-nav/src/router/index.ts

我们来研究下代码，也非常容易明白

蓝鲸基座这里和一般的vue项目一样，也有自己的路由文件，也导入了入口页等信息，值得注意的是：
这里基于window.serviceObject.iframeRoutes 和 iframe文件去批量生产了 iframeRoutes 最后并入了 routes 对象中（即第一第二个红框内的代码）

（2）

这一步实际上就已经完成了iframe类型的子系统的注册，后面如果进行路由跳转的时候就可以跳转到 iframe类型的子系统中，会指向IFrame.vue 文件

同时生成的 iframeRoutes 里面实际上是包含了各个注册的ifrema子系统的相关信息，包括请求链接等，当进入IFrame.vue 就可以基于当前路由挂载的内容得到iframe的具体链接，这样实际上就完成了iframe类型子系统的挂载

不妨看看iframe.vue 的代码长什么样：

iframe.vue: https://github.com/TencentBlueKing/bk-ci/blob/master/src/frontend/devops-nav/src/views/IFrame.vue

其中核心代码是里面的init函数：

这里会基于路由挂载的内容生成 src，这个src就是iframe 对应的链接。

因此可以看到蓝鲸基座如何接入iframe类型的子系统呢？实际上就是把生成的iframesRoutes注入到基座的路由中， 当基座路由跳转到iframe类型的子路由时就目标文件指向IFrame.vue文件，因为当前子系统的相关信息都注册到了路由上， IFrame.vue文件就可以基于自身生命周期将目标系统的路径生成，并挂到IFrame.vue文件的iframe标签上, 这样就完成了iframe类型子系统的挂载

但是显然这样子是很简陋的，路由同步，基座通信都没有，这些后面会说。

（3）

上面介绍了基座如何挂载基础的iframe子项目，那基座是怎样挂载amd类型的子项目呢？

在介绍这个之前我们需要先简单了解什么是amd:

  AMD（Asynchronous Module Definition）模式是一种用于在JavaScript中定义模块的规范。它允许开发者异步加载模块，并在模块加载完成后执行相应的回调函数。

在AMD模式中，每个模块都被定义为一个独立的文件，使用define函数来定义模块。define函数接受两个参数：模块的依赖数组和一个回调函数。依赖数组指定了当前模块所依赖的其他模块，而回调函数则定义了模块的功能和行为。

AMD模式的一个主要特点是支持异步加载模块。这意味着在应用程序运行时，可以根据需要动态地加载模块，而不是一次性加载所有模块。这种方式可以提高应用程序的性能和加载速度。

一个常见的AMD模块示例：
define(['dependency1', 'dependency2'], function(dep1, dep2) {
// 模块的功能代码
// ...
return moduleExports; // 返回模块的输出
});
在上面的示例中，模块依赖于 `dependency1` 和 `dependency2` 两个模块。当这两个模块加载完成后，回调函数将被执行，并传入相应的依赖模块作为参数。模块的功能代码可以在回调函数中定义，并通过 `return` 语句返回模块的输出。

总而言之，AMD模式是一种用于定义和加载JavaScript模块的规范，它支持异步加载和依赖管理，可以提高应用程序的性能和可维护性。

对于这种类型，会要求将子项目打包成amd格式的js包，当然umd也行，只是不同的模块化规范罢了。

所以当我们在浏览器中加载了对应格式的amd格式的js包，一般来说就已经加载了js包对应的子系统。

因此 蓝鲸基座中对于amd格式的加载实际上就是将对应的js和css通过标签的方式挂载到页面，这样就可以将对应的子系统加载下来

那基座如何实现amd的挂载呢？不妨看看基座的路由生命周期：

显而易见，通过即将跳转的路由名称，去serviceMap中进行映射，找到对应的子系统信息，通过解析的内容找到子系统对应的js和css文件，并完成加载。
这样子amd格式的子系统就已经完成加载了。

这里有两个小坑：
（1）一次加载可以加载一个子系统，那我如果后面希望跳转到其他页面再跳转回来，是否需要重新加载js和css呢？
（2）怎么把子系统挂到页面上？

显而易见并不是的，因为主包已经加载下来了，后续反复跳转如何快速定位到注册的子系统呢？最好的方式就是把子系统直接注册到基座上面即可和iframeRoutes一样

这就是为什么会有这段代码的存在？

这里就是为了将加载下来的子系统都挂载到基座路由中，后续子系统的路由切换都将在基座路由中进行，这样的好处是还同步将子系统和基座的路由做了同步。

这里会有同学问为什么，window.pages会有子系统相关的路由信息？

实际上这就是子系统接入规范要求了，如果希望子系统以amd的形式注册到基座中，那么子系统的入口文件中必须执行下面代码，手动把子系统的路由等信息挂载到window上。

（注：实际上这样会有一个隐患，子系统的名称是映射的key，而且这个key同时维护在基座和子系统中了，假如一方不小心改动就会导致难以排查的异常）

总结：
对于amd模式的子系统接入，相对来说比较简单，基座跳转的时候会拿到目标地址，基于目标地址去serviceObject中找对应的项目，假如找到了，那就解析出里面的js和css，并动态挂载到页面上。

并且在接入过程中会约束amd类型子项目要将自己的routes和store等信息注册到window上，这样js加载完之后基座就可以拿到子项目到路由等内容并将其注册到自身的路由中，后续的路由跳转就相当于在基座自身的路由中进行跳转，只是里面有一些vue文件是通过js动态加载下来的。

缺陷：这里amd的实现思路相当于把子项目直接加载到基座中进行运行，变成基座的子路由的思想。

没有做css隔离，也没有做js隔离，意味着子应用完全可以把service等重要信息直接修改或删除，有严重的漏洞存在。
路由合并的过程中是统一合并到一个数组下的，假如出现相同名称的路由，难以保证是否会出现异常。
这类名称做路由key的情况，不应该同时维护在基座和子项目中万一哪头突然改了就会导致难以发觉的异常。
代码中没看到自定义依赖的注入，需要提供自定义依赖注入机制。
技术栈锁死了，因为amd相当于是把子系统路由变成基座的子路由，因此技术栈必须和基座一致。

总结

这里介绍了基座是如何完成iframe和amd类型的子系统的加载。

核心是通过基座的路由完成的，对于iframe类型的子系统会将注册的iframeRoute合并到基座的路由中，后续如果要进行跳转到iframe类型的子系统的话，会并进入IFrame.vue，通过路由自带的数据和IFrame.vue的生命周期函数去生成iframe的链接，并将这个链接挂载到IFrame.vue的iframe标签上。

对于amd类型的子系统， 会通过基座路由钩子获取当前目标子系统的key，基于key去到serviceObject中映射对应的子系统，并解析出其中的js和css，动态挂载到基座的页面上。

通过接入规范，约束子系统将子系统的routes和stores等信息，通过key挂载到window上，当js和css动态挂载结束之后，就将子系统的routes合并到基座的路由中，这样子系统就转化成基座的子页面了，后续的跳转就相当于基座自身的路由跳转。

如何实现iframe类型的子系统路由同步及与基座间的交互？

上面的内容介绍了蓝鲸的基座做了什么准备工作以及如何实现amd和iframe两类基座的接入。

对于amd类型来说比较简单直接转化成基座的子路由，但是相对来说隔离性就比较差。

那iframe呢？iframe拥有极好的隔离性，那iframe模式会有什么问题吗？

对于iframe而言，如何实现路由的同步是一个大问题，因为iframe相当于中父页面中嵌入了一个小页面，二者的路由是不同的。

因此在蓝鲸基座这里设置了相关的交互机制实现二者的路由一致。

（1）

基座提供了iframeUtils 方法里面注册了message的监听函数，并创建了相关的交互事件，当触发message之后就会去匹配是否触发了对应key的函数。

iframeUtils: https://github.com/TencentBlueKing/bk-ci/blob/master/src/frontend/devops-nav/src/utils/iframeUtil.ts

下面我们来看看 iframeUtils 中一些重要的实现：

接收路由对象，导出iframeUtils的创建函数

注册iframe监听
声明路由更新函数

因此通过这些函数基座实现了监听iframe的postMessage能力，所以当iframe子系统可以通过触发postMessage去通知基座更新路由。

（2）

上面介绍了基座提供了iframe子系统通知基座触发指定行为的机制，假如基座改变了路由，又该如何通知到子应用更新路由呢？

很简单，基座直接监听路由即可，路由一旦发生改变，就执行init函数，重新生成src赋值给iframe标签即可，但是有一个问题就是基座无法触发子系统的路由跳转，哪怕跳转的路由在子系统中存在，这就导致如果基座希望更新子系统路由就必须重新走一遍iframe的加载流程，对于系统的加载速度，网络资源的损耗都是不利的。

（3）

（1）中我们介绍了基座实现了监听iframe的postMessage能力，通过iframe的postMessage可以让基座去同步路由，那我们iframe类型的子系统如何接入这个能力呢？

同样的基座也提供了相关的js文件，当我们加载这个文件之后就会自动为我们的工程补充上和基座沟通的渠道。
devopsUtil：https://github.com/TencentBlueKing/bk-ci/blob/master/src/frontend/devops-nav/src/assets/static/devops-utils.js

devopsUtil文件会加载一个立即执行函数，执行之后会对基座支持的所️交互行为进行注册挂载，这样子系统就可以通过挂载到vue上的函数进行和基座间的交互了。

稍微看下 devopsUtil 的代码：

当devopsUtil的代码执行结束之后，vue的原型上就会得到上述注册的事件，当iframe子系统主动去触发这些事件的时候，就会通过postMessage通知到基座，这样就可以完成基座的路由同步和基座子应用的通信了。
vue的原型上就有注册的事件：

因此对于iframe类型的子系统，必须要监听系统的路由变更，当路由变换的时候主动通知基座更新链接

到这里iframe类型的子系统挂载就完成了。

总结

这里介绍了iframe类型的子系统和基座如何实现路由同步及基座子应用的通信。

第一步基座会提供一个 iframeUtils 的文件， 里面注册了message的监听函数，并创建了相关的交互事件，当触发message之后就会去匹配是否触发了对应key的函数，基座就得到了和接收子应用触发事件的能力。
第二步为了 让基座去同步子应用的路由，当基座的链接发生改变就直接执行IFrame.vue文件的init方法，重新设置iframe标签的src。
第三步为了提供子系统触发基座事件的能力，基座会提供一个devopsUtil的js文件，子系统执行之后会将所有的触发事件都挂载到子系统的vue的原型上，里面封装了各类触发事件和postmessage方法，子系统就得到了触发事件的能力。
因此 如果要同步路由的话 就会变得很简单， 只需要监听子系统的路由，每当路由发生变更的时候执行挂载到原型的$syncUrl函数通知基座更新路由即可。

总结

到这里蓝鲸基座实现微前端的原理解析就完成了。
大概可以分成下面几步：

请求接口获取所有注册的子系统
过滤请求数据生成serviceObject，将所有的子系统信息都挂载到基座的window上
将iframeRoutes挂载到基座的路由上，当跳转到iframe类型的子系统时指向IFrame.vue文件，在IFrame.vue的生命周期中去读取当前路由的系统信息生成iframe的src链接，并赋值到IFrame.vue标签中。
当跳转到amd类型的子系统时，通过基座路由的钩子拿到跳转目标系统的key，通过key和serviceObject映射到目标子系统的信息，执行子系统的js和css，这样amd类型的子系统就会被加载到基座上，为了使用子系统，因此需要约束amd类型的子系统必须要将路由和stores等信息挂载到window上，接着基座路由钩子就会把路由直接注入到基座的路由中，这样就相当于把子系统合并到基座上，后续的跳转就相当于基座自身的路由跳转。
为了实现iframe类型子系统和基座的通信，基座会提供一个 devopsUtil文件，这个是一个立即执行函数里面封装了postmessage事件和基座支持的触发事件，执行之后这些函数都会被挂载到子系统的原型上，子系统就可以通过调用原型方法触发基座支持的事件，包括同步基座路由也可以通过监听子系统的路由，每当路由发生变更的时候执行挂载到原型的$syncUrl函数通知基座更新路由来实现。

后面会继续补充这种实现方式的优缺点及和目前流行的微前端方案相比有什么可以优化的点，未完待续。

腾讯开源的Markdown编辑器，开箱即用、轻量简洁、易扩展

Thu, 13 Jul 2023 17:40:04 CST

Markdown是我们开发者最为热爱的文本格式，自从爱上Markdown之后，我们的笔记、博客、留言等都希望有Markdown的支持。所以，Markdown编辑器已经是前端非常重要的一个组件了。

之前有推荐过一些开源的Markdown编辑器，今天继续推荐一个由腾讯开源的Markdown编辑器： Cherry Markdown Editor

这款编辑器包含我们常见的码字模式：

双栏编辑预览模式（左侧写、右侧预览）
纯预览模式
极简模式（无工具栏）
移动端预览模式

而对于语法支持上，除了支持标准Markdown语法之后，还拥有以下特性：

图片缩放、对齐、引用
根据表格内容生成图表

支持流程图、状态图、UML图常见图形需求

字体颜色、字体大小
字体背景颜色、上标、下标
Checklist
音视频

基本已经可以满足大部分的文字编辑需求。

当然了，如果您想实现更多其他高级编辑器拥有的，诸如：数学公式等负责的语法特性功能，您也可以进一步扩展，因为 Cherry Markdown Editor是开源的嘛！

最后，我们来一起看一下，这款编辑器的实际效果，具体如下图：

目前该开源项目已经斩获了1.8K Star，放在今日好像不是太多，但实属宝藏项目，如果您正好需要，感性收入囊中吧！

开源地址： https://github.com/Tencent/cherry-markdown/tree/main

欢迎扫描下方二维码，关注公众号：TJ君，订阅每日推荐，获取更多好用效率工具！

工作十年，在腾讯沉淀的高可用系统架构设计经验

Tue, 14 Mar 2023 10:48:05 CST

腾小云导读

在系统的开发过程中，很多开发者都为了实现系统的高可用性而发愁。本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用系统的架构设计需要有哪些关键的设计和考虑。希望腾讯的经验方法，能够给广大开发者提供参考。内容较长，您可以收藏后持续阅读。

看目录点收藏，随时涨技术

1 高可用系统的架构设计思想

1.1 可用性和高可用概念

1.2 高可用系统设计思想

2 研发规范层面

2.1 方案设计和编码规范

2.2 容量规划和评估

2.3 QPS 预估（漏斗型）

3 应用服务层面

3.1 无状态和负载均衡设计

3.2 弹性扩缩容设计

3.3 异步解耦和削峰设计（消息队列）

3.4 故障和容错设计

3.5 过载保护设计（限流、熔断、降级）

4 存储层面

4.1 集群存储（集中式存储）

4.2 分布式存储

5 产品层面

6 运维部署层面

6.1 开发阶段-灰度发布、接口测试设计

6.2 开发阶段-监控告警设计

6.3 开发阶段-安全性、防攻击设计

6.4 部署阶段-多机房部署（容灾设计）

6.5 线上运行阶段-故障演练（混沌实验）

6.6 线上运行阶段-接口拨测系列设计

7 异常应急层面

01、高可用系统的架构设计思想

1.1 可用性和高可用概念

可用性是一个可以量化的指标，是指在某个考察时间，系统能够正常运行的概率或时间占有率期望值。行业内一般用几个 9 表示可用性指标，对应用的可用性程度一般衡量标准有三个 9 到五个 9。一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。

高可用 High Availability 的定义（From 维基百科）：

高可用是 IT 术语，指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。服务不可能 100% 可用，因此要提高我们的高可用，就要尽最大可能的去增加我们服务的可用性，提高可用性指标。

一句话来表述就是：高可用就是让我们的服务在任何情况下，都尽最大可能地能够对外提供服务。

2.2 高可用系统设计思想

高可用系统的架构设计，需要有一套比较科学的工程管理套路。要从产品、开发、运维、基建等全方位去考量和设计。 高可用系统的架构设计思想包括但不限于：

做好研发规范。系统都是研发人员设计和编码写出来的，因此首先要对研发层面有一个规范和标准。
做好容量规划和评估。主要是让开发人员对系统要抗住的量级有一个基本认知，方便进行合理的架构设计和演进。
做好服务层面的高可用。主要是负载均衡、弹性扩缩容、异步解耦、故障容错、过载保护等。
做好存储层面的高可用。主要是冗余备份（热备，冷备）、失效转移（确认，转移，恢复）等。
做好运维层面的高可用。主要是发布测试、监控告警、容灾、故障演练等。
做好产品层面的高可用。主要是兜底策略等。
做好应急预案。主要是要思考在出现问题后怎样快速恢复，不至于让我们的异常事态扩大。

02、研发规范层面

2.1 方案设计和编码规范

研发规范层面是大家容易忽视的一个点。但是我们所有的设计，都是研发人员来完成的，包括从设计文档到编码再到发布上线。因此，研发层面也要有一个规范流程和套路，以让我们更好地去研发和维护一个高可用的系统：

阶段	事项
设计阶段	规范好相关方案设计文档的模板和提纲，让团队内部保持统一。
设计阶段	方案设计后一定要进行评审。在团队中，新项目一定要评审，重构项目一定要评审，大的系统优化或者升级一定要评审，其他的一般研发工作量超过一周的建议也要评审。
编码阶段	执行代码规范：工程的 layout 目录需结构规范，团队内部保持统一，尽量简洁；遵循团队内部的代码规范。一般公司都有对应语言的规范，如果没有则参考官方的规范，代码规范可以大大减少 bug 并且提高可用性。
	单测覆盖率：代码编写完需要有一定的单测能力来保证代码的健壮性，同时也能保障我们后续调整逻辑或者优化的时候可以保证代码的稳定。包括：增量覆盖率、全量覆盖率。具体的覆盖率要达到多少，可以根据团队内部的实际情况来定，一般定的规则是 50% 的覆盖率。
	日志规范：不要随便打日志、要接入远程日志、要能够分布式链路追踪。
发布上线阶段	参考下面运维部署层面章节的灰度发布和接口测试相关说明（即6.1）。

2.2 容量规划和评估

容量评估：

是指需要评估好在做的这个系统是为了应对一个什么体量的业务、这个业务请求量的平均值、高峰的峰值大概都在一个什么级别。

如果是新系统，那么就需要先搜集产品和运营同事对业务的大体预估，开发者根据他们给的数据再进行详细评估。如果是老系统，那么就可以根据历史数据来评估。评估的时候，要从一个整体角度来看全局的量级，然后再细化到每个子业务模块要承载的量级。

容量规划：

是指系统在设计的时候，就要能够初步规划好系统大致能够维持的量级，比如是十万级还是百万级别的请求量，或者更多。不同量级对应的系统架构设计完全不一样。尤其到了千万、亿级别的量级的时候，架构设计会有更多的考量。

这里值得注意的是，不需要在一开始就设计出远超当前业务真实流量的系统，要根据业务实际情况来设计。同时，容量规划还涉及到：系统上下游的各个模块、依赖的存储、依赖的三方服务分别需要多少资源，需要有一个相对可量化的数据。容量规划阶段更多是要依靠自身和团队的经验，比如要了解系统的 log 的性能、redis 的性能、rpc 接口的性能、服务化框架的性能等等，然后根据各种组件的性能来综合评估已经设计的系统的整体性能情况。

容量评估和容量规划之后，还需要做就是性能压测。最好是能够做到全链路压测。

性能压测的目的是确保系统的容量规划是否准确。假设设计的这个系统，规划的是能够抗千万级别的请求。那么实际上，真的能够抗住吗？在上线之前首先要根据经验来判断，其次是一定要经过性能压测得出准确结论。 性能压测要关注的指标很多，但是重点要关注的是两个指标：一个是 QPS，一个是响应耗时要确保压测的结果符合预期。

压测的步骤：可以先分模块单独压测。最后如果情况允许，那么最好执行全链路压测。

2.3 QPS 预估（漏斗型）

QPS 预估（漏斗型）指的是：一个真实的请求过来后，从接入层开始分别经过了整个系统的哪些层级、哪些模块，每一个层级的 QPS 的量级分别有多少。

从请求链路上来看，层级越往下，下游层级的量级就会越少。因为每经过一个层级，都有可能会被各种条件过滤掉一部分请求。例如进入活动页后查看商品详情然后下单这个例子，首先进入活动页，所有的请求都会进入访问。然后只会有部分用户查询商品详情。最后查看商品详情的这些用户又只会有部分用户会下单。这里就会有一个漏斗，所以从上层模块到下层模块的量级一定是逐步减少的。

QPS 预估（漏斗型）需要开发者按照请求的层面和模块，来构建预估漏斗模型，然后预估好每一个层级的量级。包括但不限于从服务、接口、分布式缓存等各个层面来预估，最后构成完整的 QPS 漏斗模型。

03、应用服务层面

3.1 无状态和负载均衡设计

要做到系统的高可用，一般应用服务的常规设计都是无状态的。这也就意味着，开发者可以部署多个实例来提高系统的可用性。而这多个实例之间的流量分配，就需要依赖系统的负载均衡能力。 「无状态 + 负载均衡」既可以让系统提高并发能力，也可以提高系统的可用性。

如果开发者的业务服务使用的是各种微服务框架，那么大概率在这个微服务框架里面就包含了服务发现和负载均衡的能力。这一整套流程包括：服务注册和发现、负载均衡、健康状态检查和自动剔除。当系统的任何一个服务实例出现故障后，它会被自动剔除掉。当系统有新增一个服务实例后，它会被会自动添加进来提供服务。

如果大家不是使用的微服务框架来开发的，那么就需要依赖负载均衡的代理服务，例如 LVS、Nginx 来帮系统实现负载均衡。当然，腾讯云的 CLB 负载均衡也支持亿级连接和千万级并发，各位感兴趣的话可自行搜索了解。

3.2 弹性扩缩容设计

弹性扩缩容设计是应对突峰流量的非常有效的手段之一，同时也是保障系统服务可用性的必要手段。弹性扩缩容针对的是系统无状态的应用服务而言的。服务是无状态的，因此可以随时根据请求量的大小来进行扩缩容，流量大就扩容来应对大量请求，流量小的时候就缩容减少资源占用。

怎么实现弹性扩缩容呢？ 现阶段都是云原生时代，大部分的公司都是采用容器化（K8s）部署，那么基于这个情况的话，弹性扩缩容就非常容易了，只需要配置好 K8s 的弹性条件就能自动根据 CPU 的使用率来实现。

如果不是容器化部署，是物理机部署的方式，那么要做到弹性扩缩容，必须要有一个公司内部的基础建设能力、能够在运营平台上针对服务的 CPU 或者 QPS 进行监控。如果超过一定的比例就自动扩缩容，就和 K8s 的弹性原理是一样的，只是需要自行实现。

3.3 异步解耦和削峰设计（消息队列）

要想系统能够高可用？ 从架构层面来说，要做到分层、分模块来设计。而分层分模块之后各个模块之间，还可以进行异步处理、解耦处理。目的是为了不相互影响，通过异步和解耦可以使系统的架构大大的提升可用性。

架构层面的异步解耦方式就是采用消息队列（比如常见的 Kafka），并且同时消息队列还有削峰的作用，这两者都可以提高系统的架构可用性：

采用消息队列之后，可以把同步的流程转换为异步的流程，消息生成者和消费者都只需要和消息队列进行交互。这样不仅做了异步处理，还将消息生成者和消费者进行了隔离。

方式	解析
异步	异步处理的优势在于，不管消息的后续处理的业务服务是否完成，只要消息队列还没满，那么就可以执行对外提供服务。而消费方则可以根据自身处理能力来消费消息，再进行处理。
解耦	解耦的优势在于如果消费方异常，并不影响生产方，依然可以对外提供服务。消息消费者恢复后可以继续从消息队列里面，获取消费数据后执行业务逻辑。
削峰	采用消息队列之后，还可以做到削峰的作用，当并发较高的时候甚至是流量突发的时候，只要消息生产者能够将消息写入到消息队列中，那么这个消息就不会丢。后续处理逻辑会慢慢的去消息队列里面消费这些突发的流量数据。这样就不会因为有突发流量而把整个系统打垮。

3.4 故障和容错设计

任何服务，一定会存在失败的情况，不可能有 100% 的可用性。服务在线上运行过程中，总会遇到各种各样意想不到的问题会让服务出现状况，因此业界来评价可用性 SLA 都是说多少个 9，例如 4 个 9(99.99%)的可用性。

为此，一般设计建议遵循「design for failure」的设计原则，设计出一套可容错的系统。需要做到尽早返回、自动修复，细节如下：

要点	解析
遵循 fail fast 原则	Fail fast 原则是说，当系统的主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，尽快返回错误，而不是等到出现负面影响才处理。

具备自我保护的能力	当系统依赖的其他服务出现问题的时候，要尽快的进行降级、兜底等各种异常保护措施，避免出现连锁反应导致整个服务完全不可用。例如当系统依赖的数据存储出现问题，不能一直重试从而导致数据完全不可用。

3.5 过载保护设计（限流、熔断、降级）

系统无法高可用的一个重要原因就在于：系统经常会有突发的流量到来，导致服务超载运行。这个时候首先要做的是快速扩容，并且开发者事先就要预留好一定的冗余。另外一个情况下，就算扩容了，但是还是会超载。例如超过了下游依赖的存储的最大容量、或者超过了下游依赖的三方服务的最大容量。

那么这个时候，系统就需要执行过载保护策略了，主要包括限流、熔断、降级，过载保护是为了保证服务部分可用，不至于导致整个服务完全不可用。

过载保护手段	解析
限流	限流是指对进入系统的请求进行限流处理，如果请求量超过了系统最大处理能力或者超过了开发者指定的处理能力，那么直接拒绝请求，通过这种丢弃部分请求的方式可以保证整个系统有一定的可用性，不至于让整个系统完全不可用。那么怎样判别超过最大处理能力呢？一般就是利用 QPS 来判别，如果 QPS 超过阈值，那么就直接拒绝请求。限流有很多细节的策略，例如针对接口限流、针对服务限流、针对用户限流。

熔断	熔断，断路（开路）的价值在于限制故障影响范围。一般希望控制、减少或中断和故障系统之间的通信，从而降低故障系统的负载，这有利于系统的恢复。一般系统的服务都会有很多下游依赖，如果下游依赖的服务出现问题，例如开始就超时甚至响应非常慢的话，如果不做任何处理，那么会导致整个请求都被卡住造成超时，那么系统的业务服务对外就无法提供任何正常的功能。为此，熔断策略就可以解决这个问题，熔断就是当系统依赖的下游服务出现问题时，可以快速对其进行熔断（不发起请求），这样系统的业务服务至少可以提供部分功能。熔断的设计至少需要包括：熔断请求判断机制算法、熔断恢复、熔断告警三部分。


降级	降级是指开发者划分好系统的核心功能和非核心功能，然后当系统超过最大处理能力之后，直接关闭掉非核心的功能，从而保证核心功能的可用。关闭非核心的功能后可以使系统释放部分资源，从而可以有资源来处理核心功能。

熔断和降级这两个策略虽有些相似，字面的意思都是要快速拒绝请求。但是却是两个维度的设计：降级的目的是应对系统自身的故障，而熔断的目的是应对系统依赖的外部服务故障。

04、存储层面

当前的互联网时代，应用服务基本都是无状态的。因此应用服务的高可用相对来说会比较简单。但是数据存储的高可用相对来说，会复杂很多。因为数据是有状态的，那具体开发者要怎样保障数据存储的高可用。下文一起来分析下。

存储层面的高可用方案本质是通过数据的冗余来实现，将数据复制到多个存储介质里面，可以有效的避免数据丢失，同时还可以提高并发能力。因为数据是有状态的，这里会比服务的高可用要复杂很多。

常见的解决存储高可用的方案有两种： 集群存储和分布式存储。业界大多是围绕这些来构建，或者是做相关衍生和扩展。下面展开讲解。

4.1 集群存储（集中式存储）

集群存储是指由若干个「通用存储设备」组成的用于存储的集群。组成集群存储的每个存储系统的性能和容量均可通过「集群」的方式得以叠加和扩展。

集群存储适合业务存储量规模一般的场景，常规的业务数据存储一般都是集群存储方式就足够了。现在一般业务数据存储的使用默认都是集群方式。比如 Redis、MySQL 等存储类型。一般中大型互联网公司默认是集群存储的方式。

集群存储就是常说的「 1 主多备」或者「 1 主多从」的架构。写数据通过主机，读数据一般通过从机。集群存储主要需要考虑如下几个问题：

主机如何将数据复制给备机（从机）？数据的写入都是通过主机，因此数据同步到备机（从机），就是要通过主机进行数据复制到备机（从机）。还需要考虑主备同步的时间延迟问题。
备机（从机）如何检测主机状态？
主机故障后，备机（从机）怎么切换为主机？主从架构中，如果主机发生故障，可直接将备机（从机）切换为主机。

4.2 分布式存储

分布式是指将不同的业务分布在不同的节点。分布式中的每一个节点，都可以做集群。

「分布式存储系统」是将数据分散存储在多台独立的设备上。传统的网络存储系统采用集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，也是可靠性和安全性的焦点，不能满足大规模存储应用的需要。

分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

分布式存储适合非常大规模的数据存储，业务数据量巨大的场景可以采用这种方式。常见的分布式存储比如 COS、GooseFS、Hadoop(HDFS)、HBase、Elasticsearch 等。

05

产品层面

产品层面的高可用架构解决方案，基本上就是指兜底产品策略。降级/限流的策略，更多的是从后端的业务服务和架构上的设计来考虑相关解决方案。这里说的兜底策略也可叫做「柔性降级策略」，更多的则是通过产品层面上来考虑。下面举几个例子：

当系统的页面获取不到数据时，或者无法访问时，要如何友好的告知用户。如「稍后重试」之类的方式。
当系统的真实的页面无法访问的时候，就需要产品提供一个默认页面，如果后端无法获取真实数据，那么直接渲染默认页面。
服务器需要停机维护，那么产品层面就会显示一个停机页面，所有用户只会弹出这个停机页面，不会请求后端服务。
抽奖商品显示一个默认兜底商品等等。

06、运维部署层面

6.1 开发阶段-灰度发布、接口测试设计

灰度发布、接口测试、接口拨测系列设计包括但不限于：

灰度发布：

服务发布上线的时候，要有一个灰度的过程。先灰度 1-2 个服务实例，然后逐步放量观察。如果一切 ok，再逐步灰度，直到所有实例发布完毕。

接口测试：

每次服务发布上线的时候，服务提供的各种接口，都要有接口测试用例。接口测试用例测试通过后，服务才能发布上线。这样目的是为了查看系统对外提供的接口是否能够正常运行，避免服务发布后才发现有问题。

灰度发布和接口测试，一般在大公司里面会有相关的 DevOps 流程来保证。

6.2 开发阶段-监控告警设计

监控告警的设计，对部分大公司来说不是问题。因为一定会有一些比较专门的人去做这种基础能力的建设，会有对应的配套系统，业务开发者只需要配置或使用即可。

那如果公司内部没有相关基础建设，就需要开发者分别来接入对应的系统，或者直接接入一些指标、链路、日志、事件等多数据支持、更加一体化的监控平台，比如腾讯云可观测平台。

系统	建设要求
监控系统	一般在监控系统这方面的开源解决方案包括但不限于这些： ELK (Elasticsearch、Logstash、Kibana) 日志收集和分析：我们的日志记录不能都本地存储，因为微服务化后，日志散落在很多机器上，因此必须要有一个远程日志记录的系统，ELK 是不二人选。 Prometheus 监控收集：可以监控各种系统层面的指标，包括自定义的一些业务指标 OpenTracing 分布式全链路追踪：一个请求的上下游这么多服务，怎么能够把一个请求的上下游全部串起来，那么就要依靠 OpenTracing，可以把一个请求下的所有链路都串起来并且有详细的记录。 OpenTelemetry 可观测系统标准：最新的标准，大一统，集合了跟踪数据（Traces），指标数据（Metrics），日志数据（Logs）来观测分布式系统状态的能力。我们会依托开源系统进行自建或者扩展，甚至直接使用都行，然后我们的监控的指标一般会包括：基础设施层的监控：主要是针对网络、交换机、路由器等低层基础设备，这些设备如果出现问题，那么依托其运行的业务服务肯定就无法稳定的提供服务，我们常见的核心监控指标包括网络流量(入和出)、网络丢包情况、网络连接数等。操作系统层的监控：这里需要包含物理机和容器。常见的核心指标监控包括 CPU 使用率、内存占用率、磁盘 IO 和网络带宽等。应用服务层的监控：这里的指标会比较多，核心的比如主调请求量、被调请求量、接口成功率、接口失败率、响应时间（平均值、P99、P95 等）等。业务内部的自定义监控：每个业务服务自己的一些自定义的监控指标。比如电商系统这里的：浏览、支付、发货等各种情况的业务指标。端用户层的监控：前面的监控更多的都是内部系统层面的，但是用户真正访问到页面，中间还有外网的情况，用户真正获取到数据的耗时、打开页面的耗时等这些信息也是非常重要的，但是这个一般就是需要客户端或者前端去进行统计了。

告警系统	这些系统接入完，还只是做到监控和统计，当出现问题时，还需要进行实时告警，因此要有一个实时告警系统，如果没有实时报警，系统运行异常后就无法快速感知，这样就无法快速处理，就会给使用者的业务带来重大故障和灾难。告警设计需要包括：实时性：实现秒级监控。全面性：覆盖所有系统业务。实用性：预警分为多个级别。监控人员可以方便、实用地根据预警严重程度做出精确的决策。多样性：预警方式提供推拉模式。包括短信，邮件，可视化界面，方便监控人员及时发现问题。

6.3 开发阶段-安全性、防攻击设计

安全性、防攻击设计的目的是为了防刷、防黑产、防黑客，避免被外部恶意攻击。一般有两个策略：

在公司级别的流量入口做好统一的防刷和鉴权的能力，例如在统一接入层做好封装。
在业务服务内部，做好相关的业务鉴权，比如登录态信息、例如增加业务鉴权的逻辑。

6.4 部署阶段-多机房部署（容灾设计）

一般的高可用策略，都是针对一个机房内的服务层面来设计的，但是如果整个机房都不可用了，例如地震、火灾、光纤挖断等情况怎么办？这就需要系统的服务和存储能够进行容灾了。容灾的常见方案就是多机房部署。

类型	解析
服务的多机房部署	服务的多机房部署比较容易。因为我们的服务都是无状态的，因此只要名字服务能够发现不同机房的服务，就可以实现调用。这里需要注意的是名字服务（或者说负载均衡服务）要能够有就近访问的能力。

存储的多机房部署	存储的多机房部署，这个会比较难搞一点，因为存储是有状态的，部署在不同的机房就涉及到存储的同步和复制问题。

条件不允许的情况下，保证多机房部署业务服务就可以了。

6.5 线上运行阶段-故障演练（混沌实验）

故障演练在大公司是一个常见的手段。在业界，Netflix 早在 2010 年就构建了混沌实验工具 Chaos Monkey。混沌实验工程对于提升复杂分布式系统的健壮性和可靠性发挥了重要作用。

简单的故障演练就是模拟机房断电、断网、服务挂掉等场景，然后看整个系统运行是否正常。系统就要参考混沌实验工程来进行详细的规划和设计，这个是一个相对较大的工程、效果较好，但是需要有大量人力去开发这种基础建设。

6.6 线上运行阶段-接口拨测系列设计

接口拨测和巡检类似，就是服务上线后，每隔一个固定时间（比如 5s）调用后端的各种接口，如果接口异常则进行告警。

针对接口拨测，一般也会有相关配套设施来提供相关的能力去实现。如果没有提供，那么开发者可以写一个接口拨测（巡检）的服务，定期去调用重要的接口。

07、异常应急层面

即使前面做了很多保障，也不一定招架住线上的各种异常情况。如果真出问题让系统的服务异常、无法提供服务，开发者还有最后一根救命稻草——那就是应急预案，将服务异常的损失降低到最小。

应急预案是需要开发者事先规划好，业务系统在各个层级出现问题后第一时间怎么恢复，并制定好相关规则和流程。当出现异常状况后可以按照既有的流程去执行。这样避免出现问题后手忙脚乱导致事态扩大。

最后，我们整理出本文的思维导图如上，供各位参考。总体来说，我们从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面，剖析了一个高可用系统的架构设计需要有哪些关键的设计和考虑。

以上便是本次分享的全部内容，如果您觉得内容有用，欢迎点赞、收藏，把内容分享给更多开发者。

-End-

原创作者｜吴德宝

技术责编｜吴德宝

腾小云福利来也

扫码一键领取 「腾讯云开发者-春季限定红包封面」

最近微信改版啦，有粉丝反馈收不到小云的文章。

请关注「腾讯云开发者」并 点亮星标，

周一三晚8点和小云一起 涨(领)技(福)术(利)！

你可能感兴趣的腾讯工程师作品

| 编程语言70年：谁是世界上最好的编程语言？

| 腾讯工程师聊 ChatGPT 技术「文集」

| 一文揭秘微信游戏推荐系统

| 微信全文搜索耗时降94%？我们用了这种方案

技术盲盒：前端｜后端｜ AI与算法｜运维｜工程师文化

阅读原文

腾讯内部数据治理实践

Mon, 06 Feb 2023 09:50:11 CST

导读：本文主要介绍目前腾讯数据治理的所在阶段和实践经验，以及基于目前的经验所沉淀的数据治理平台：WeData。

今天的介绍会围绕下面三方面展开：

数据治理挑战
腾讯内部数据治理实践
WeData 数据治理平台能力

分享嘉宾｜王浩仙腾讯云技术产品

编辑整理｜聚变腾讯

出品社区｜DataFun

数据治理挑战

首先和大家分享腾讯在数据治理上所面临的挑战。

1. 数据治理的挑战

在数据治理的过程中会遇到很多问题，我们简单分成三类：

管理类挑战：数据信息分散在不同的业务部门的业务库中，数据上报也分散在不同的位置，难以对这些分散的数据进行统一的管理。随着数据量的不断增大，如何投入更少的人力去进行数据信息的维护也是一大难题。
技术类挑战：我们的数据工程师在收集到数据后，数据的质量该怎么保证？如果数据本身质量不过关，可能带来负面的业务效果。
业务类挑战：在所有的数据上报之后，底层的业务元信息缺失，无法进行统一的审计或者度量。

2. 数据治理“马斯洛的需求层次理论”

数据治理对于不同企业，或者是一个企业在不同的发展阶段，所面临的问题是不一样的，这里进行了一个简单分类：

时效性：数据采集上来后，我们会关注数据产出的及时性，因为如果数据发生的时效性没有达标的话，对当前的业务判断来讲价值就会降低。
质量性：在数据已经有了一些闭环应用的基础上，还需要有准确性，完整性，有效性，如此才能保证在数据应用上能达成期望的效果。
可用性：如果数据是不可用的，则数据对我们的价值就降低。
安全性：在数据量很大之后，我们会更多地去关注数据共享或者数据应用，在这个过程中，我们的数据安全如何保障。
成本：解决问题过程中可能耗费大量人力、物力以及计算资源，我们是否能在解决问题的同时降低成本。

腾讯内部数据治理实践 1. 腾讯内部业务现状

接下来介绍腾讯内部的业务现状，腾讯分很多的 BG，包括企业、娱乐、云方向、内容方向。这些涉及数万业务线，数百个产品线，达到 EB 级的数据存储量，拥有数千的数据分析师。 2. 腾讯数据治理三阶段

每条业务线虽然不同，但也会有一些共性的地方。从大的方向上我们会分为三个阶段：

第一阶段：数据资产化，把数据这个物料变成一个有价值的资产，这才是我们所有的人做数据的一个最核心的目标。把这个目标达成了之后，才能把数据真正利用起来。
第二阶段：降本增效，如何把之前我们在做数据资产化过程中消耗的一些资源降下来，把整个投入降低，但是还能保持或者提高数据资产化的效果。
第三阶段：在前两个阶段都完成之后，会发现可以抽象出来一些通用的东西，把我们内部的经验理念孵化出来，去解决更多的问题，这是 数据治理平台化产品化的阶段。

3. 腾讯内部实践：腾讯新闻数据资产化

数据资产化阶段的实践，以腾讯新闻为例，在做数据治理这件事情的时候，最开始我们面临着两大问题：

缺少统一数据规范：各业务数据埋点规范、上报规范、数仓规范、指标规范各异。
数据质量难以保障：业务数据仓库庞大，缺乏数据分层及数据模型，数据复用度仅 15%，存在大量年久失修的数据。

针对这两大问题，我们进行了统一的数据资产化，包括统一埋点模型，升级数仓模型，构建指标模型。完成数据生产链路的规范化建设，从埋点到数仓到指标等，梳理完成了适合新闻的管理流程，并在大改版过程中快速应用。完成了 250 个模型设计或重构，52 个维表的设计以及 270 个应用表的开发。在数据资产完整性和分层规范达到 95%、复用度达到 73% 以上，跨层引用占比小于 5%。 4. 腾讯内部实践：PCG（平台与内容事业群）数据成本治理

数据成本的治理，我们以腾讯内部 PCG（平台与内容事业群）业务线为例。在做成本治理的时候，我们要去定义成本的范围，包括：数据采集平台，数据生成平台，数据分析平台，数据应用平台。我们通过两个方面进行了优化，一方面从资源用量上降低业务不合理使用，另一方面从资源单价上提升数据平台的效能。截止到今年，在月成本同比增加 30%+ 的情况下，业务单位用户/内容消费的大数据成本下降，业务大数据成本绝对值下降至少 10%。强化了大数据成本治理理论，沉淀了方法论、流程和平台能力。 5. 腾讯内部实践：治理平台化推动业务治理落地

海量数据给业务带来了巨大价值，同时也带来巨大的成本及负担。业务团队大数据成本盘点困难、治理执行门槛成本双高、治理效果不能有效量化，都是业务在推进资产治理的痛点。 我们把推动治理平台化分为了 4 个阶段：

现状概览：洞察全域数仓及大数据成本，呈现最真实的业务资产情况。
资产明细：全方位治理项洞察，基于资产分规范，对当前业务的待治理项进行明细展示。
治理方案：平台内置治理方案结合业务定制化治理方案。
治理执行：一站式治理执行，针对洞察出的治理项进行治理动作。

构建了一套属于我们自己的资产价值评分体系，包括：规范性、安全性、数据质量、数据成本、数据应用情况。将评分给到数据治理的实施人，帮助制定治理方案和复盘治理效果。

WeData 数据治理平台能力

1. 腾讯内部大数据能力的对外商业化输出——WeData

这是 WeData 数据开发治理平台的架构图，要形成一个闭环，与数据的生产生联动，因为数据治理不仅要处理存量数据，还要处理未来增量的数据。平台主要分成两大部分，左边是敏捷数据生产，包括：数据建模、数据集成、数据开发、数据服务。右边是高效数据治理，包括：资产治理，数据质量，数据安全，元数据资产。 2. WeData 数据治理服务 首先我们看图的中心部分，分为上下两层，上面是数据流通与存储的过程，下面是加工生产的过程，包括数据汇聚，数据开发与运维（基础管理，库表构建，脚本开发，脚本编排）和数据服务（在数据上生成 API）。 从图的左边看，首先要做的是数据建模，涉及到治理部分的能力，就包括最开始的数仓的规划，数仓定义和规范标准，模型定义和指标定义。前期定义之后，在接下来的数据生产的过程中，才能验证数据是否符合这个标准，如果前期没有定义，也可以在后期其他模块逐步地去发现完善它。 图的下方，主要是数据质量和数据安全部分。数据质量包括：事前的质量监控；事中的质量监测（如果不达标，我们会阻断流程，避免污染下游的数据）；事后的质量分析报告。数据安全也是包含三个部分，事前访问控制、事中脱敏加密，事后访问审计。数据的质量与安全的治理，贯穿数据的全生命周期。 图的右边是元数据资产，可以分成三个部分，首先发现元数据，采集元数据。接着，元数据采集上来之后，我作为数据的生产方，要具备管理好数据的能力，包括两层，第一层就是基本的技术元数据：库表，字段等。此外，还要从业务的角度去理解，所以需要大量的业务元数据的信息，与技术元信息进行关联。形成关联关系之后，数据使用者才能真正理解数据的业务含义。第三部分就是数据目录，通过数据目录让所有使用数据的人能快速的定位到目标数据。通过血缘关系，帮助排查数据的来源和去向。数据变更记录了数据源的每次变化以及对下游的影响。数据温度则体现了数据使用的具体情况。 3. WeData数据治理——规范工具

规范化工具可以分成三个部分，第一个部分就是数据管理，包括指标的管理，维度管理和元数据管理。第二部分是数仓规划，包括数仓定义，数据分层，业务分类，定义主题域业务过程。这一套规范定义完成了之后，还需要进行物化。物化指的是我们在生产数据的时候，将逻辑模型和真实的物理关联起来。此外，因为对接了很多不同行业的客户，我们也形成了不同行业的行业模板，可以在行业模板的基础上，完成企业体系标准的构建。 4. WeData数据治理——质量工具

质量工具要完成的过程分成 4 步： 第一步，定义规 则，确定数据质量衡量的标准是什么，形成质量规则库。规则又分成两部分，首先会有一些基础的规则，包括基础的空表的检测，数据行数检测，准确性或者唯一性的检测，在常规模板里面包括了均值的比较，波动率等指标；同时还可以通过自定义 SQL 的方式来完成具有业务特性的规则校验。 第二步，规则确定好后，需要把这个规则和我们的数据本身进行关联，去达到一个质量监控的效果。一般来说有两种形态，第一种形态就是事中在 ETL 的流程中进行监控，挂载到开发任务上去。当数据生产之后，去检查这个数据是否符合我们的质量规则，如果不符合可以进行阻断式的操作。第二种形态是离线周期性的检测，例如检测各分区的数据质量情况。 第三步，当发现数据问题之后，会进行一次数据问题的运维。一般情况下，数据都是会上下波动的，但如果波动超过了一定范围，则会发出报警。例如，一张表每天都应该有 1000 行，但是今天只有 500 行，可能这个数据的产出就有问题了，或者是其他一个业务导致的，这个时候会产生数据质量的告警，通知到相关的责任人，告警也不是处理的终点，我们会有质量报警的工单体系，当告警通知到责任人后，如果他觉得这个问题需要别人来参与的话，可以进行转单，直到这个的数据流程单被处理结束，最终形成一个问题记录进行归档，如果被认为是典型问题的话，还可以进行记录，在后面有其他人遇到类似问题的时候，可以借鉴处理。 第四步，有定期的质量报告的分析，针对哪些表经常会被阻塞，哪些任务经常会发生告警，把这种经常性出现问题的表找出来。 5. WeData 数据治理——安全工具

数据安全工具从三个方面进行治理：

敏感数据识别

从安全的角度进行数据的分类分级，确定数据是内部数据，还是敏感数据，还是机密性数据，这时就需要分级及分类的定义。此外需要提供规则识别的能力，通过这样的规则确定什么样的数据才是机密的数据 or 敏感的数据。比如在当前疫情反复的情况下，很可能会采集到很多姓名、性别、身份证这样的机密信息。我们可以做一个任务去管理数据扫描，扫描完之后把数据的分类进行打标，因为数据安全的分类、分级本质上也是定义在元数据上面的一种信息，扫描识别之后会存在底层元数据信息里面，让数据使用者知道谨慎地使用这些数据。

隐私保护

包括两种形式：第一种是常规的静态脱敏，可以把数据进行一个脱敏任务，到目标端形成一个脱敏后的数据。例如对身份证号码手机号登录，会进行打码处理，然后才能对外的输出。第二种是动态脱敏，跟平台工具紧密相关，比如数据集成的过程中，可以进行数据的加密，在数据查询时能够检索到。之后在数据分享时，就产生水印，水印支持溯源，进行一系列的隐私保护。

安全审计

数据已经发出去之后，是我们的安全审计，哪些人访问、导出、下载过，尤其针对敏感数据。 6. WeData 数据治理——元数据资产管理工具

数据可用性治理包含三个步骤： 第一步，提高数据搜索能力。如何能快速的去定位到想要的数据，包括全域内大搜的能力，因为作为一个业务方要去使用某个数据时，要知道企业内部是否有这个数据，如果没有那么谁可以去生产这部分的数据，如果有的话该找谁去申请以及如何去用这个数据，所以要在企业的范围内有一个全局的快捷的数据定位能力。 第二步，提高数据理解能力。找到数据后，业务方不是特别清楚数据的具体情况，但是我可以根据其他用户的使用情况（比方这份数据的热度和打份情况），把数据作为一个商品，快速的给到想要使用这些数据的人。将技术元信息和业务元信息全部呈现给用户，让他知道这个数据的全貌。 第三步，提高数据应用能力 ，查到数据后如何去应用。从数据使用者的角度，需要以何种形态去呈现，让数据使用者能够更好地使用数据。 7. WeData 数据治理——治理实践落地

在前面这几部分，包括规范、质量、安全以及可用性的基础上，我们对数据进行了深度的治理。治理达成的效果就是降本增效，降低不需要的那些数据的成本，提高数据的使用率。在资产治理模块对资产进行打分，形成企业级的评级体系。让组织治理者根据质量分进行治理的落地，去掉那些不常用的、冷的数据、数据孤岛的数据、重复的数据，再把有效的数据更好地利用起来。 04

问答环节

Q1：元数据打了安全标签之后，怎么向下游的模型或者任务进行传递？

A1：Wedata 在做元数据安全打标的时候都是相互独立的，不会根据血缘关系进行传递，因为上下游可能是不同的业务线，对敏感性的定义不同。 Q2：请问业务元数据该如何采集梳理，业务的元数据具体包括哪些内容？A2：按照我们资产资产治理的理论，业务元数据分为 5 类，第一类是规范性元数据，属于哪个分层哪个主题域业务域；第二类是质量元数据；第三类是安全元数据；第四类是成本元数据；第五类是应用元数据，包括使用上的温度。一般从这个 5 个维度去了解业务元信息。 Q3：请问 tbds 和 wedata 的关系是什么？A3：tbds 指的是我们底层的数据处理引擎，腾讯大数据产品主要分为两部分，共有云部分是 emr 和 cdw 数据仓库等产品，私有云上底层引擎体系管叫 tbds。其中，wedata 是指的数据治理工具。 今天的分享就到这里，谢谢大家。

｜分享嘉宾｜

王浩仙

腾讯云大数据平台产品中心技术产品

从事大数据产品领域7年，曾就职于金山、阿里，目前作为腾讯云大数据平台产品中心数据治理产品负责人。

腾讯孙驰天：游戏科技让数字孪生创造更大生产力

Wed, 04 Jan 2023 18:33:11 CST

毕业后做了几年赛车游戏，公司被苹果收购后转做自动驾驶。几年后离开苹果，成为了腾讯数字孪生仿真技术总监，孙驰天有着奇妙的转行经历。

几份工作看起来南辕北辙，但其实背后有着技术上的共通点，就是游戏科技。正如他所说，游戏人不只是玩游戏的达人，做游戏的开发者，更是用游戏科技进行前沿技术研发的人。

从小就热爱游戏的孙驰天在明白「游戏不能当饭吃」的道理后，爱上了数学物理，但在清华学习数学物理专业的时候，他发现自己缺少了一点做科学家的天赋，并且还是爱游戏。于是他从研究生又学起游戏开发，毕业后赴硅谷，开发了很成功的 AR 赛车游戏后，进入了苹果自动驾驶团队，再来到腾讯做自动驾驶模拟仿真系统，接着将这种数字孪生仿真技术应用到更大的工业互联网领域。

在他看来，自动驾驶模拟仿真系统近似为一种「高精度的赛车游戏」。现在元宇宙的模样会被很多人解释为「头号玩家」，一个所有人都在游戏的世界，实际上那个世界确实会被游戏充满，但不只是娱乐游戏，还有交通自动驾驶、建筑、工厂制造等各行各业的「游戏化」，也就是数字孪生的世界。

随着这个世界虚拟和真实越来越密不可分，孙驰天的工作经历背后，一场关于「游戏」的变革正在发生——游戏科技并非只能娱乐，而是已经成为重要的生产力工具。

以下为腾讯数字孪生仿真技术总监孙驰天在极客公园创新大会 IF 2023 上的演讲实录，由极客公园整理：

01

从赛车游戏，

到数字仿真

小霸王游戏机、Gameboy、PS2 等是我从小玩到大的游戏机。我是一个很爱游戏的人，可以说我的整个成长过程都和游戏相关。

我高中的时候对数学物理感兴趣，后来就去了清华数学物理专业，结果发现真正系统性的数学物理和中学的差异非常大。所以我发现天赋对学习数学物理很重要，我只能算是爱好者，当科学家太难了。于是后来我学了计算机图形学，本科时期的计算机课程也会涉及简单的沉浸式体验和游戏开发，为我后面做游戏打下了基础。

我很喜欢玩游戏，甚至研究生的时候直接申请了游戏开发学位，当时的课程主要是用游戏引擎进行游戏和沉浸式体验的应用开发。那是 2012 年，游戏引擎技术在国内用得还不多，对于我这个数学物理背景的人来说，花了很多时间学习理解掌握。

我读书期间用游戏引擎做了很多游戏开发，类型比较多，不管是普通的游戏还是 AR、VR 等交互性更有意思的沉浸式游戏。

毕业之后，我去了一家 AR 开发公司。当时是 2014 年，在硅谷 AR 很热，很多公司在探索使用 AR 开发游戏，我们也是其中之一。当时我们用英特尔的 Real Sense 摄像头帮助开发 AR 沉浸式游戏，用户可以通过摄像头，以 AR 方式控制游戏操作，是一个非常好用的 AR 交互设备。那是一个赛车类的乐高 IP 游戏。在当时来看，这款产品的游戏性、交互性、AR 的体验感都非常强，很受欢迎。

做了两个游戏后，这家 AR 公司被苹果收购，我也就加入了苹果。我当时有两个职业发展方向可以选择，一个是 AR 眼镜，一个是自动驾驶汽车。我当时很纠结，我的经理跟我说，你的背景和之前游戏开发的能力用于开发自动驾驶会更酷一些，尤其是开发自动驾驶汽车所需要的模拟仿真系统，会对这个行业有很好的帮助。我也觉得自动驾驶比较酷，就加入了自动驾驶团队，通过打造自动驾驶模拟仿真系统帮助自动驾驶的发展。

那么什么是自动驾驶汽车所需要的模拟仿真系统？大家可以理解为高精度的赛车游戏，我们通过营造高逼真的环境，让自动驾驶汽车在虚拟环境进行完整的场景测试，我们认为自动驾驶汽车在模拟环境测试得非常好，运行得非常平滑和稳定，我们才会将自动驾驶汽车在实地进行测试。

回国之后我加入了腾讯，一开始就是做自动驾驶模拟仿真相关工作。我们重新设计和打造了一个具备腾讯特色的自动驾驶模拟仿真系统产品，不仅自己用，还给国内外车厂、测试场、国家部委使用，是一个国产化自主可控的自动驾驶模拟仿真系统。

我当时选择的路线是游戏科技加数据驱动。数据驱动是采集大量的真实数据，比如真车的数据、动力学数据、传感器的数据，这些采集回来的真实数据训练和标定自动驾驶仿真系统。

游戏科技也是技术路线非常核心的一部分。腾讯在过去这些年具备扎实的游戏基础，比如游戏引擎，数据同步、场景生成的工具，以游戏引擎为例，比如一个摄像头、激光雷达是怎么运行和运作的，怎么让仿真的结果和真实的结果贴近，需要模拟激光雷达，进行反射，生成完整的点云的过程，进行场景的自动构建和渲染，整个过程需要借助游戏引擎的能力得到实现。

当时的技术路线，受到了传统仿真软件非常尖锐的挑战和批评，说「使用游戏引擎不够严谨」。但事实来看，5 年过去了，结果是所有的自动驾驶仿真软件全部支持游戏引擎，游戏科技的进步在仿真行业能帮助我们节省非常多的时间，解决很多问题，帮助我们加速仿真系统的开发速度。

我们打造这个产品的时候非常严谨，本着汽车行业非常规范的流程打造自动驾驶仿真系统，验证自动驾驶的安全性。我们用游戏科技和数据驱动精益求精地打造这个系统，帮助自动驾驶汽车进行测试和落地。

02

游戏科技让数字孪生

创造更大生产力

我们后面将数字孪生的能力扩展到更多的行业，不仅仅是解决自动驾驶仿真测试的问题，而是做得更通用。

数字孪生在过去几年比较火爆，它有很多的模块组成，包括渲染、大数据、模拟仿真、实时交互等，我们将在仿真积累的能力，游戏科技的能力用于更广泛的数字孪生的系统构建，核心的诉求是帮助我们更好地将物理世界映射到孪生世界内部，并且非常低成本的试错，将最优解或者最优方案反馈到物理世界，帮助我们进行物理世界的指挥或者控制。

其中我们用到了什么样的游戏科技点？一是自研的游戏引擎，游戏引擎是整个仿真孪生非常核心的点，使用自研游戏引擎可以实现国产化，而且可以帮助我们进行引擎的自定义化裁剪，不用使用标准化的商业引擎，商业引擎的沉重会带来计算的成本比较高，运行效率比较低等问题，而自研游戏引擎，可以帮助我们比较高效率地进行仿真、渲染的计算。

二是自动化建模和编辑工具，我们做数字孪生的时候用了很多这样的工具，比如高自动化地利用卫星图和地图数据，生成任何一个城市所有的道路、建筑、植被、水域，一天之内纯自动化地生成。

同时还有一些多用户协同。大家玩的王者荣耀或者主机游戏，本质上需要多用户协同做实时互动，而且对数据同步要求更高的方向，要求做到实时数据帧同步。大规模的云渲染得益于云游戏，可以帮助用户不依赖自己终端的性能，而是访问云端，获取好的渲染交互体验。我们不倾向于让用户采购非常贵的终端设备才能运行高保真效果，所以多用户协同和云渲染在数字孪生中是非常核心的能力。

我们在行业做了什么？比如交通行业，在地面交通仿真系统，我们基于实时车流数据，由高性能的传感器、摄像头+毫米波雷达感知到实时车流上报的系统，不是纯虚拟的交通流场景，而是映射智慧城市实时的车流。

基于这样的车流，我们可以注入一个虚拟事件，比如出现了虚拟的交通事故，对于道路有怎样的影响，从而帮助交通部门更好地疏导。右边是我们做一个无人机的应用，做航道的分析、冲突的预测、化解等，我们在交通行业，都用了游戏仿真的能力，实现交通系统效率提升的目的。

我们的孪生技术应用在不同行业的例子。比如政务孪生系统，工厂孪生系统可以提升工厂效率减少人员成本，建筑的孪生应用可以将电梯和所有的设备接入进行动态的管理，以及空调智能的管控，降低能耗……

我们也给到政府人员构建碳排放的管理平台，碳排放是比较复杂的问题，碳排放最大的行业，分别是工业、交通、建筑，所以要做比较好的碳排放的模型，需要将这三个领域的碳排放数据和短时间的预测，非常精准地孪生到数字孪生世界内部，基于碳排放模型作出未来的预测，帮助我们的环境管理方计算得出更好的解决之道，更好的实现碳达峰和碳中和的目的。

总结来看，不管是游戏引擎、自动化建模、云渲染，都是在通用型的数字孪生基础上提供用户从物理世界到孪生世界映射的工具。

是什么力量，让阿里云腾讯云和火山引擎走到了一起

Fri, 25 Feb 2022 21:40:35 CST

作者 | 李亮
编辑 | 苏子华

几天前，特斯拉表示，正在努力让用户在车载屏幕上玩 steam 的各种游戏。对于开发者而言，这意味着不需要进行移植或修改，大部分游戏就能接入车载屏，在座舱中运行。听到这样的消息，立刻有人兴奋地问：我是不是可以在电动皮卡上玩《赛博朋克 2077》了？

人对更沉浸、更美好的体验有着天然的向往。一块屏幕不断发展，就可以带来丰富体验。虽然目前智能汽车里的屏幕只拥有导航等简单的功能，但不久的将来，看电影、直播互动、视频开会都将成为常常在车里做的事情。

越来越习惯互动直播、视频连线的当下，人们对音视频的期待也从「看什么」变成了「怎么看」，期待更顺滑的体验。

迎接这样的未来，除了可以想象的硬件和算力进步，编转码、画质算法等底层音频技术也是不可或缺的前提。

正是对未来视频交互广泛场景的探索，让阿里云、腾讯云、和诞生于字节的火山引擎在今天联合发布一项新的技术标准—— 超低延时直播协议信令标准。这套标准，首次将传统直播技术 3 至 6 秒的延时缩短到 1 秒。这是第一个适合直播低延时的通用标准方案，也是三家技术先进方推动技术进步的一次尝试，将已验证的「最佳实践」普及。

这套标准可广泛应用于赛事直播、在线教育、电商直播等对实时性要求较高的场景，带来超低延时、低卡顿、秒开流畅的直播体验。

此次的新技术标准，三方以推动行业直播技术进步、提升用户体验为初衷，在技术层面上共同探讨与协助。2 月 25 日举行的「火山引擎视频云科技原力峰会」上，火山引擎直播技术负责人周一楠说，[在超低延时这个方向上，阿里云、腾讯云和火山引擎一起，做了一件大事，为整个直播的发展做出了贡献」。

01 泛视频时代，需要怎样的直播技术

「姐的眼睛就是尺」，王濛的金句随着直播讲解辐射开来。当下的情绪、即时的反应，直播不仅传递信息，更是陪伴与交互的载体。音视频直播技术，也成为了目前最流行的在线交互方式之一。即时流畅是直播内在的追求。具体到音视频传输的技术上，通用与高效，是直播技术发展变迁的终极目标。

直播场景中，人与人会直接建立连接。一旦出现延时，就会出现各种问题。例如，主播反馈慢，电竞和抢购也会由于延时不同导致不在同一个水平线，线上的 PK 也会因效果不同而不公平。

通过内部 A/B 测试的方法，火山引擎验证了低延时的对观看行为的直接影响。在内部的反转实验中，团队将 3 秒的端到端延时的播放重新提升为 7 秒，用户的观看时长下降了 1.3%。

目前，市面上没有合适直播的低延时通用标准方案。这也是火山引擎、阿里云、腾讯云共同探索出的这套方案，提供一套标准，从而让各种直播业务，迈入 1s 内规模分发的大关。

所谓低延时，也就是直播时端到端的延时达到 500 毫秒~1500 毫秒，人眼无感。一套标准方案，也让不同的技术供应商之间方便互通。参与者使用一套 SDK（Soft Development kit，软件开发工具包）即可无缝切换各种供应商的产品。

这项协议交互细节全部开放，也将在 Github 上逐步开放，其他三方公司可按照标准来实现服务端和客户端接入。

在视频云原力峰会上，行业人士也分享了对于视频技术趋势的观察。IDC 企业及系统软件研究部研究经理魏云峰表示，根据研究预测，2025 年全球实时产生的数据里将有 25% 以非结构化存在。这其中，大部分将以图片、视频的形式存在。

未来对于音视频的需求可以归纳为清晰、流畅、互动。2020 年，中国视频云市场的规模接近 70 亿，并且在过去 2 年保持了年均复合增长率 50% 以上的增速。例如线上教育、远程手术、金融行业的内训等更多场景都会需要更便捷高质的视频技术。这些领域的具体需求不同，对应的视频云方案既需要差异化，又需要能够低门槛。

02 从「中台」到「To B」，从「能力」到「体验」

视频云是火山引擎云业务的一环，随着字节跳动的视频业务而成长，在字节跳动内部支撑了抖音、西瓜视频的播放体验。目前，其技术支持着每日 1 亿次播放、数千万次互动的应用。

火山引擎视频云技术负责人浩铭介绍，火山引擎团队在思考对视频端到端体验的持续优化的过程中，逐渐意识到体验的重要性。

随着支持字节的产品越来越多，团队开始思考，「把作为中台的业务模式变成 to B 的服务模式，会在业务支持效率和组织效能上有更大的提升。」

从技术出发往往思考的是功能指标（QoS），而火山引擎从体验指标（QoE）去思考问题，将技术指标直接与业务的增长结果关联。

这样的思维也带来许多有价值的发现。例如，网络受限的用户不得不选择低分辨率播放模式。如果在带宽受限的情况下将画质优化，做超分处理，整个大盘的播放时长能够提升 0.23%。

甚至一些容易被忽略的指标也会带来明显影响。在点播时前后视频的音量可能会忽高忽低，实现了音量均衡之后，结果显示，不仅仅人均观看时长提升了 3%，电商直播的 GMV 也提升了 4%。

在不同的应用场景上，火山引擎很早就尝试了各种合作，以验证技术效果。例如，点播上，火山引擎视频云为足球社区APP「懂球帝」提供了视频云解决方案，帮助「懂球帝」解决了播放中首屏卡顿的问题。球迷在浏览 APP 中的视频时，首帧时间降低 30% 以上。

峰会上，PICO 行业资深市场专家刘凯展望了未来视频互动的场景。他认为，未来用户会希望和视频本身交流，因此，许多厂商在研究的「立体视频」会有大量的应用空间。视频云技术负责人浩铭表示，未来 VR 的视频互动会呈现更大的自由度、以及虚实结合两个特点。火山引擎将与 PICO 共同打磨更多沉浸式的视频体验，不断沉淀到视频云的解决方案中。

03 体验优化的四个维度

视频体验如何建立指标并优化？火山引擎的视频云将其分为四个部分： 播放体验、互动体验、画质体验、性能体验。在四个不同维度上建立指标，以求数据驱动的业务增长。

播放体验的优化，意味着首帧压缩到 100ms 以下，崩溃率小于 1/10000。首帧即是视频播放的第一帧。

其实 100ms 是一个更为严苛的指标。因为按照人眼自然体验，当你被一个视频封面吸引，点击播放到首帧渲染出来的耗时小于 200ms 时，基本就没有延时和卡顿感了。而崩溃率小于 1/100000，这意味着，一个人每天刷 100 个短视频，3 年才能遇到一次播放器崩溃。

互动体验则集合了不同维度的指标，聚焦服务直播场景。目前多人线上语音沙龙是非常流行的互动方式，一般多人同时在线时，同时开麦的人数需要控制在 20 到 50 人，且多人共同说话时卡顿、吞音常常出现。

视频云首次实现了单房间上麦人数超过1000人服务。多人同时说话、抢答，语音即使重叠也会完整传递。百万级用户高并发，可以让单个直播间容纳超过1000个主播。

画质体验上，火山引擎提供的 BVC 编码器，能够在保证画质清晰度不变的情况下，带宽比行业竞品降低 10%。性能优化涉及使用成本，火山引擎从三个方面入手：提供参数配置、码率配置的最优解；自研算法实现图片压缩更优；视频高清低码，主观效果相同下，码率再节省 10%~20%。

火山引擎总经理谭待表示，开放互联是火山引擎云服务的重要发展理念。火山引擎希望与产业的各方、上下游进行深度合作。一方面希望把自己最好的技术拿出来，输出最佳实践；另外一方面，此次火山引擎与阿里云、腾讯云的技术合作是共建开放的协议标准，也欢迎更多人直接参与到标准的接入和建设。

*头图来源：视觉中国

腾讯音乐知识图谱搜索实践

Sat, 05 Feb 2022 00:00:00 CST

分享嘉宾：Elvin 腾讯音乐高级工程师

编辑整理：李一中科雨辰

出品平台：DataFunTalk

导读：近几年来，图数据在计算机领域得到了广泛的应用。互联网数据量指数级增长，大数据技术、图数据方面的应用增长很快，各家互联网大厂都在图数据分析和应用方面大量投入。为了让我们的搜索更加智能化，腾讯音乐也借助了知识图谱。今天和大家分享下腾讯音乐在图谱检索与业务实践方面的探索，主要包括以下几大部分：

音乐知识图谱介绍
图数据库选型
项目架构介绍
知识图谱搜索功能应用举例
总结与展望

01 音乐知识图谱介绍

首先和大家介绍下音乐知识图谱的相关知识。

1. 音乐数据分类

图状数据广泛存在，其中与音乐相关的业务数据主要有以下三类：

内容方面有歌曲、综艺、影视、专辑等；
歌手方面有歌手信息、歌手之间的关系，包括组合、相似等；
歌手和歌手内容之间的关系有演唱、作词、作曲等。

2. 音乐知识图谱的应用场景

(1) 复杂搜索需求实现

音乐知识图谱不仅可以做简单的搜索，还可以实现复杂搜索需求。例如要查询周杰伦的男女对唱的歌曲有哪些，如果要实现这个查询，需要对周杰伦的歌曲进行一定的过滤，歌手的数量要等于2，另一位歌手的性别是女性，还要考虑基于播放量、歌手权重等等的排序。在传统关系型数据要实现这个功能很复杂。利用知识图谱就比较简单了，先找到歌手周杰伦，查找周杰伦的所有歌曲中满足2人合唱，另一个歌手性别是女性的，只要两跳就可以实现复杂的搜索查询。

(2) 搜索结果的相关推荐

可以根据搜索的关键词，查询图谱中的实体节点，根据实体节点查询出关联的节点，用关联的节点给出推荐的结果。例如用户搜索周华健，可以通过关联信息推荐出李宗盛。如果通过搜索引擎，很难推荐出李宗盛，而用知识图谱，只要两跳，周华健歌手到对应组合（纵贯线），从组合再到另一歌手李宗盛，只要两跳。

(3) 基于知识计算给出答案

可以根据知识图谱的计算来给出一些答案，通过图谱的关联信息，实体上下位信息，实体属性信息，查询出相应的答案。例如用户搜索刘德华90年年代的歌曲，用知识图谱的话，只要歌手刘德华，时间90年代歌曲，两个联合起来就可以得到结果。

3. 搜索召回和知识图谱召回优缺点

搜索召回，是基于文本匹配的，召回之后会涉及相关性排序，相对来说比较复杂，精准度不足，可能过度召回。搜索召回的流程比较复杂，排序策略也相对复杂。

知识图谱召回，是基于实体之间的关系进行查询，可以做到精准召回，也没有过召回，召回的流程可以很短，也就是几条图查询的语句。另外，知识图谱还具备一定的推理能力。

02 图数据库选型

要实现图查询，首先得做图数据库的选型。

图数据库的选型，需要考虑以下几点因素：

开源非付费，考虑到成本及源码可控性，选择拥抱开源；
分布式框架可扩展，随着数据的增加和减少，后台必须是可扩展的；
高性能毫秒级多跳查询，要做到毫秒级的在线响应；
支持千亿级规模数据量；
支持数据批量导入导出。

我们对比了8个数据库，对优缺点进行了分析，对这些数据库进行了分类：

第一类，以Neo4j为代表的，只有单机版本，性能比较优秀，但是不满足分布式可扩展性要求。Neo4j的商业版本支持分布式，但是却是收费的。
第二类，JanusGraph、HugeGraph这类数据库，支持分布式可扩展的，他们的共同特点是在现有的图谱上增加了通用的图语义解释层，受到存储层架构的限制，存储层是外部数据库实现，不支持计算下推的功能，导致性能较差。
第三类，以NebulaGraph为代表，这一类数据库都实现了自己的存储层，支持计算下推，做了效率上的优化，性能提升很多。

从上图看到综合性能测试数据。我们通过1度邻居（跟点直接相连的点），2度邻居，共同邻居，这三个方面来对数据库性能进行测试，可以看到Nebula不管是单机性能，还是集群性能，都要远超于其他竞品。考虑到性能，社区活跃度，版本迭代速度，语言上的通用性，我们最终选择了Nebula数据库做为我们项目的图数据库。

03 项目架构介绍

1. 在线层

包含以下模块：

Storaged负责具体数据的存储，包括点数据、边数据，以及相关的索引；
Metad负责存储图数据的meta信息，例如数据库的schema、addition等；
Nebula graphd负责数据计算的逻辑层，是无状态的，可以进行平行扩展，内部执行计算引擎来完成查询的整个过程。
Nebula proxy是我们新增的模块，作为整个nebula模块的代理层，可以接受外部的命令，并对图数据进行操作，包括图的查询，更新，删除。另外，nebula proxy也负责协议的转换，集群的心跳和路由注册。

由于单集群有重建数据的需求，也为了防止机房故障，我们选择双集群来支撑整个服务的可用性。

在线层请求处理的流程为，cgi在接收到用户请求后，将用户请求传给broker模块，broker请求模版匹配生成相应的图查询语句，从Zookeeper中提取可用的集群，将查询语句发给nebula proxy进行图谱召回，nebula proxy将具体的查询语句传递给nebula graphd, nebula graphd负责执行最终的语句，然后把结果返回给broker层，broker层补充一些前端显示摘要后，将数据返回给前端做展示。

2. 离线层

音乐数据有实时的新增数据，例如新增发行的唱片，还有全量数据的更新，所以我们选择了全量加增量的数据层方案。

(1) 全量数据生成方案

音乐很多数据存在数据库中，先将数据从DB中dump出来后，由IndexBuilder模块将数据格式转换为所需的格式后形成一个全量的源数据，将全量的源数据上传到HDFS后，通过运行spark任务，把数据转为Nebula底层所需的数据文件，IndexMgr发现有新的常量数据生成后，将数据文件下载下来，将全量数据加载到NebulaProxy，这样全量数据就生成好了。

(2) 实时数据的生成

每隔一段时间，通常是几分钟，将几分钟之内的业务修改数据dump出来后，转为特定的格式，形成一个增量的源数据，增量的源数据存入到Kafka里面，可以用于数据的重发和恢复，DataSender从Kafka队列里面拉取到最新的数据，通过NebulaProxy发送到集群，这样增量数据就生效了。

这里涉及到了一个增量补发的问题，因为存量过程dump过程中要耗费很长时间，可能要花几个小时，在全量数据dump过程中也有新的增量数据，这期间的增量数据可能并没有进入到全量的数据当中。所以这里需要进行一个历史增量的补发，从T0后（全量同步开始时间）的新增数据，不在全量数据中，需要将T0之后的数据全部进行补发。

04 知识图谱搜索功能应用举例

1. 配置化召回

常规召回方式为：根据Query生成查询语句，获取召回结果，根据策略混排，召回结果展示。

这样做的问题是，每做一次，每增加一种新的召回策略，以上四步都要重复，所以召回不够灵活，业务改动大。

我们增加了一种新的基于Query模板的召回方式，就是根据模板生成对应的查询语句，同时预先设置了一些常用的混排策略。比如我们配置一个学校加校歌的模板，当查询校歌的时候，我们把学校的名字提取出来，填到查询语句里面，形成一个完整的图查询语句。同时也预置了一些混排插入策略，填入对应的混排参数，就可以做到上线。这样做的优点就是召回比较灵活，和搜索相比，召回上线的代价比较小。

2. 业务应用

我们最终上线了上图这些业务，支持各类搜索场景。

校歌搜索：当用户搜索大学校名和校歌组合时，召回对应的学校的校歌；
歌手场景：当用户搜索歌手名字的时候，返回歌手所在组合，以及合唱过知名歌曲的合作歌手等；
影视场景：当用户搜索影视主题曲、片尾曲、插曲等等的时候，返回对应的影视的歌曲。

05 总结与展望

今天的讨论从图数据的选型开始，到schema分类定义，项目架构层设计，再到知识图谱的搜索。结论是采用图数据，可以很好的把专家经验智能融入图谱。通过图数据技术实现的知识库，增强了检索、推荐、可视化等功能，腾讯音乐很好的对知识图谱技术进行了应用，大大提高了客户的搜索体验感，增强了客户黏度。让我们拥抱AI技术，让其更好地服务于生活。

06 精彩问答

Q：在搜索过程中有考虑音频信息吗？

A：这个是有考虑的，我们可以通过音频识别技术，首先去识别歌曲的一个大的分类流派，比如说像民谣摇滚流行这些流派，然后在线检索的时候，我们会通过这种语音搜索去召回。另外，我们跟QQ音乐天津实验室也有合作，比如像听目前的金科视曲，后台走的也是走我们的限量搜索，也是通过对音频信息进行的召回。

Q：语义检索结果排在第几位？是怎么和关键词检索一起排序的？

A：首先我们会通过算法去挖掘某一个语义标签跟某一首歌曲的相似度，语意搜索的话就可以通过语音标签进行召回，优先把语义相似度高的结果排到前面。当然也会有一些奇异的情况，比如说像赵雷有一首歌叫民谣，民谣这首歌就是一个歌曲，它同时也是一个语义，我们排序的时候也会兼顾这种混排的效果，最下层排序，首先会把民谣的歌曲放在前面，因为它毕竟是一个比较知名歌手的歌曲，下面会把对应的语义的结构放在后面，然后我们在更上层会有基于算法的排序模型去给用户推荐点击量高的调前。

Q：全量索引版本切换双buffer内存是否会翻倍？

A：实际上我们索引切换的过程中是没有双buffer的，是按每一个分片下的每一个副本进行逐个切换，切换的时候会进行动态的卸载，所以并没有占用额外的内存。

Q：跨越截断，是在index截断好，还是在线选择截断？

A：是在线选择截断，如果离线截断会导致数据丢失，这样是没办法回溯的。截断也是分片的，向量检索也是可以分片之后，做并行检索。

今天的分享就到这里，谢谢大家。

在文末分享、点赞、在看，给个3连击呗~

分享嘉宾：

活动推荐：

2022年02月19日，由英伟达、中电港联合举办的《深度学习推理优化与部署实践》技术分享，邀请英伟达、京东科技、vivo技术大咖，围绕“如何给深度学习加速？”为大家带来系列分享，感兴趣的小伙伴可识别下方海报二维码进行报名。

关于我们：

DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请近1000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章500+，百万+阅读，12万+精准粉丝。

分享、点赞、在看，给个 3连击呗！

腾讯应届生怒怼管理层腾讯高管：认真反思，尽快整改

Wed, 26 Jan 2022 20:21:01 CST

　　1月25日深夜，腾讯企业微信的一名应届生员工在部门内部大群中，因“赶版本”导致的高强度加班问题，发消息怒怼管理层。网传图片显示，该员工质疑管理者在进行任务排期时，只顾进度而忽略开发人员连续加班，影响健康的问题。

　　该员工表示，他在企业微信产品部年末评奖期间，看到一位同事的评语写道：“连续20多小时高强度并行设计和开发，确保了宣传页面按时上线”“持续1周高强度完成了超过200项产品和设计走查修改”等强调高强度加班的表述。

　　他认为，因高强度加班获得表彰，某种程度上并不是一个好信号。

　　“内测延期一天，企业微信是不是马上就会倒闭？官网延迟一天上线，客户是不是就马上跑到钉钉飞书那去？是不是非得让开发人员加这20多个小时的班，才能让这个版本满你们的意？你们做任务排期的时候到底有没有考虑过手下人的死活？”该员工称。

　　1月26日，在该员工在群里发难后，其直属领导、企业微信高管等都第一时间与其本人进行了沟通。

　　另外，企业微信负责人黄铁鸣也在腾讯内部论坛上，回答了关于这个问题的讨论，以下是回答内容：

　　大家好，我是WXG企业微信产品部的负责人ted。

　　上文中的截图是昨晚我们在部门大群里发的部门即时激励表彰文档，这个表彰是对取得了阶段性进展项目和个人的一次即时激励。其中的一些表彰内容引发了咱们一位同学对部门高强度工作问题、影响健康问题的反馈，对于这位同学敢于直言问题的态度，我是认可的。

　　昨晚我们也和这位同学通了电话，认真详细地了解了同学的情况和反馈，我们了解到这位同学刚加入部门2个月，刚来压力较大，与周边同学交流下来发现大家普遍工作高强度，加上近期身边好友不幸去世产生较大内心冲击，因此情绪迸发在部门群内表达了自己对高强度工作的意见。

　　关于上文中所提及的项目，是去年底企业微信和腾讯会议、腾讯文档的联合版本公司内测项目，这个项目是21年企业微信团队最重要的项目之一，项目牵涉到3个BG（业务集团）、3个产品的联合开发，上线的时间节奏也是基于三个团队之前的共同商定而确定的，时间紧、任务重，这确实令到我们很多同学连续高强度工作才得以保证了最终按时按质交付。

　　而后的4.0版本，又因为要赶企业微信4.0版年度发布会，再次令到大家强急行军。以上的这些，作为部门负责人，同学们的辛苦我看在眼里也记在心里，我很感谢大家为了项目为了产品而拼搏，也很惭愧因为项目因为产品而让大家如此辛劳。

　　今天的事情也再次提醒了我们，持续高强度的急行军是不持久的，也势必会影响到大家的工作与生活平衡，以及健康。之前BG层面还做了一个关于同学们工作状态的调研，大家普遍反映的问题是业务的价值感、工作强度、因为绩效考核“比加班、比谁走得晚”，从部门的管理者的角度，我的态度是，绝不会仅仅是根据大家的工作时长就来判断一个人的工作表现好坏或者绩效排名，这是不客观的，也是不可持续的。

　　其实基于之前BG层面的这个调研，我们也收到了很多同学匿名反馈的中肯建议和方案，我们也已经在思考优化方案，这位同学的敢于表达再次给我们做了对于快速优化的提醒。接下来，部门管理团队会尽快商议出一整套解决此类问题的具体方案，我的大体思路如下，先同步大家：

　　1、及时做好规划。同步优化产品迭代开发的规划与节奏，以及其它相关的流程、机制，尽量避免让大家在短期内高强度的工作。

　　2、健康合理工作时间。团队内部、跨团队合作，结合协同的必要性，共同商议健康合理的作息时间。

　　3、明确评价导向。不会让大家因为顾虑到考核排序而“比加班、比谁走得晚”，各团队负责人也要在团队内明确沟通考核的标准和依据，引导健康、可持续的工作方式。

　　后续具体的方案成型后我会在部门层面进行全员沟通，充分征集部门同事的意见。

　　最后，非常感谢这位同学的直言反馈，督促了我们尽快优化调整。感谢企业微信所有同学们一直以来的辛劳付出。期待未来我们用更健康、更持久的方式一起做出让用户满意的产品。

马化腾：腾讯只是一家普通公司随时都可以被替换

Tue, 11 Jan 2022 23:36:21 CST

去年底的员工大会上，马化腾对2021年发生的一系列变化表达了自己的想法，他说，腾讯只是国家社会大发展期间的一家普通公司，是国家发展浪潮下的受益者，并不是什么基础服务，随时都可以被替换。未来，腾讯在服务国家和社会的时候，要做到不缺位、做到位、不越位，做好助手、做好连接器。

一位腾讯中干告诉《晚点 LatePost》，过去互联网公司之间比的是增长速度，未来比的则是谁更稳健。2021 年 4 月，腾讯成立了可持续社会价值事业部（SSV）并承诺投入 1000 亿元实践共同富裕。

相关阅读：

与阿里巴巴习惯对组织频繁调整不同，腾讯（SEHK：00700）往往只在外部环境发生重大变化时才会进行大规模组织调整。2021 年就是这样的一年：

腾讯被要求放弃独家音乐版权；主导的斗鱼、虎牙合并案被否决；8 年以来第一次开放微信外部跳转链接；游戏的版号发放暂停、未成年保护日益严格；几乎清空对京东的持股，这曾是它最重要的一笔对外投资；随着市值不断下跌，腾讯也掉出了全球十大互联网公司之列。

过去，腾讯依靠微信、投资生态与手中掌握的海量版权在许多领域拔得头筹，但现在 “躺赢” 的日子已经一去不复返。腾讯董事局主席、CEO 马化腾与总裁刘炽平在 2021 年底的员工大会称，公司要降本增效、要 “过冬”。截至发稿，腾讯股价为每股 453 港币，市值 4.35 万亿港币（约合 5585 亿美元），位列全球第十一位。

为了应对上述变化带来的挑战，腾讯进行了一整年的调整，罕见地集中对多位副总裁级别管理者动刀：

平台与内容事业群（PCG）陆续换掉了大部分业务的一号位。这很大程度上源于 PCG 未来的战略探索：虚拟世界与现实社会的交互。新的方向需要能力模型更匹配的管理者来带领。腾讯 COO 任宇昕则在员工大会上称要给 PCG 多些时间。

在此次调整中，腾讯副总裁、天美工作室群总裁姚晓光跨事业群兼任了 QQ 所在的 PCG 社交平台业务负责人，这在腾讯一贯的职务任命中较为罕见。他在游戏行业的丰富经验有助于带领 QQ 进行虚拟与现实世界交互的探索。

新任信息平台与服务线负责人郄小虎则拥有深厚的技术背景，曾在 Google 和滴滴任职的他被认为是国内互联网企业最想从谷歌挖走的三个工程师之一。腾讯收购搜狗后将开启在搜索领域的投入，看点与 QQ 浏览器等产品未来也将强化推荐算法推荐在内的技术能力，这些业务均与郄小虎的能力模型相契合。

云与智慧产业事业群（CSIG）的重要性持续上升，并成立了区域业务部，目的是建立更多区域下沉渠道，以触达中小型企业。《晚点 LatePost》获悉，SAP 前全球高级副总裁、中国区总经理李强已经加入 CSIG 负责智慧工业与服务业业务；青桔 CEO 张治东加入 CSIG 任腾讯地图任负责人。

互动娱乐事业群（IEG）在国内游戏市场增长见顶之际开启了国际化进程。其中，发行部门成立了全新的国际品牌 Level Infinite，天美与光子两大工作室群则在海外多地布局了自研工作室。

腾讯音乐娱乐集团与阅文集团分别进行了业务调整，核心是摆脱自成立以来对版权的绝对依赖，未来将进一步向音乐、文学与影视的产业链上游深入。

原 QQ 负责人梁柱在 2021 年成为腾讯音乐的新任 CEO，他的此次调任也处在腾讯音乐被监管要求放弃独家版权的节点。一位腾讯音乐人士称，集团正在加强对音乐业务的把控力，所有内容业务需要进行更深度的协同从而形成真正意义上的 “集团军”，从这个角度来看，在 QQ 音乐与腾讯 PCG 都有丰富管理经历的梁柱是合适的人选。

腾讯是当前中国市值最高的互联网公司，微信在国内有超过 10 亿的活跃用户，这意味着它在监管、社会责任与商业之间寻求平衡时会面对更多挑战。

查看评论

消息称，腾讯和字节的内容即将向搜索开放，百度或成最大赢家？

Tue, 19 Oct 2021 07:58:00 CST

据彭博社报道，工信部正在考虑要求腾讯和字节跳动等媒体公司开放搜索壁垒——即允许用户在本平台上搜索并访问其他平台的内容。

知情人士说，规章设计仍在讨论当中。工信部希望可以通过百度等搜索引擎，让用户直接可以获取到微信上的数亿篇文章。其中一位知情人士说，工信部还在考虑将抖音的短视频也向搜索引擎开放。他们表示，监管机构正在向公司征求反馈意见，目前尚不清楚这一政策是否会实际执行。

如果政策得以实施，这将标志着国家在打破互联网巨头垄断——尤其是在腾讯和阿里——上取得重大进展。监管机构已经警告科技公司开放他们所谓的搜索壁垒，允许与竞争对手服务的链接。这同样也为全球范围内的反垄断进程做出了良好表率。

迫使字节跳动或腾讯允许百度和其他竞争对手在互联网搜索中展示他们的社交媒体内容，这将对互联网巨头的广告板块产生阶段影响。它可以将广告收入从微信或抖音等服务，转移到百度等搜索引擎上。

应此消息，百度在港股股价一度上涨4.3%。腾讯发言人拒绝评论，而字节跳动和百度的发言人则完全没有回应彭博社的评论请求。工信部对此也没有回复。

雷锋网分析，随着打击力度的扩大，反垄断局已向互联网大公司所经营的封闭生态系统宣战。一些公司采用封锁和其他方法来保护各自的领域，这成为了反垄断机构的主要打击对象：比如腾讯微信之于社交媒体，阿里巴巴的淘宝和天猫之于电子商务，以及字节跳动的抖音和今日头条之于视频和新闻。

而以可见的速度，垄断壁垒正在消除。腾讯上个月允许微信用户通过一对一消息链接到抖音视频和淘宝商店等内容，而阿里巴巴在其部分应用程序中添加了微信支付系统。

在先前，国家的互联网治理已经取得了不小的成效。国家先后整治了阿里巴巴和美团的市场滥用，并开展净网行动，同时先前出台的未成年人网游防沉迷新规也同样体现了国家智力互联网领域的决心。

据称，目前的审议主要集中在微信的公众账号上，它允许个人和企业发布从娱乐到新闻等多个领域的的文章内容，而这个庞大的内容库现在屏蔽了百度和字节跳动等搜索引擎。微信上的文章现在只出现在微信的本地搜索功能或搜狗上。

为了与微信竞争，百度于 2016 年推出了自己的内容平台——百家号来填充百度平台上的内容，这也使得百度在BAT的内容竞争上可以不落人后。

限制搜索服务的并非只有腾讯。2008 年，淘宝就屏蔽了百度搜索。据称，此举旨在保护消费者利益。而事实上，这将商家牢牢地绑定在了淘宝上，这也使得阿里从当时开始就主导了网上购物领域。知情人士说，目前尚不清楚工信部是否还打算取消对淘宝列表或其他内容的屏蔽。

【封面图片来源：网站名和讯网，所有者：和讯网】

腾讯看点基于 Flink 构建万亿数据量下的实时数仓及实时查询系统

Mon, 04 Oct 2021 00:00:00 CST

▼ 关注「 Flink 中文社区」，获取更多技术干货 ▼

摘要：本文由社区志愿者路培杰整理，腾讯看点数据团队高级工程师王展雄在 Flink Forward Asia 2020 分享的议题《腾讯看点基于 Flink 构建万亿数据量下的实时数仓及实时查询系统》。内容包括：

背景介绍
架构设计
实时数仓
实时数据查询系统
实时系统应用成果总结

Tips：点击 「阅读原 文」即可查看作者分享原版视频～
GitHub 地址欢迎大家给 Flink 点赞送 star~

一、背景介绍

1. 需要解决的业务痛点

推荐系统

对于推荐同学来说，想知道一个推荐策略在不同人群中的推荐效果是怎么样的。

运营

对于运营的同学来说，想知道在广东省的用户中，最火的广东地域内容是哪些？方便做地域 push。

审核

对于审核的同学，想知道过去 5 分钟游戏类被举报最多的内容和账号是哪些，方便能够及时处理。

内容创作

对于内容的作者，想知道今天到目前为止，内容被多少个用户观看，收到了多少个点赞和转发，方便能够及时调整他的策略。

老板决策

对于老板来说，想知道过去 10 分钟有多少用户消费了内容，对消费人群有一个宏观的了解。

以上这几点都是我们日常工作中经常遇到的业务场景，后面的篇幅中会给出对应的解决方案。

2. 开发前调研

在进行开发之前我们做了如下这些调研。

■ 2.1 离线数据分析平台能否满足这些需求

调研的结论是不能满足离线数据分析平台，不行的原因如下：

首先用户的消费行为数据上报需要经过 Spark 的多层离线计算，最终结果出库到 MySQL 或者 ES 提供给离线分析平台查询。这个过程的延时至少是 3-6 个小时，目前比较常见的都是提供隔天的查询，所以很多实时性要求高的业务场景都不能满足。

另一个问题是腾讯看点的数据量太大，带来的不稳定性也比较大，经常会有预料不到的延迟，所以离线分析平台是无法满足这些需求的。

■ 2.2 准实时数据分析平台

在腾讯内部提供了准实时数据查询的功能，底层技术用的是 Kudu + Impala，Impala 虽然是 MPP 架构的大数据计算引擎，并且访问以列式存储数据的 Kudu。但是对于实时数据的分析场景来说，它的查询响应速度和数据的延迟都还是比较高的。比如说查询一次实时的 DAU 返回结果的耗时至少是几分钟，无法提供良好的交互式的用户体验。
所以 Kudu+Impala 这种通用的大数据处理框架的速度优势，更多的是相比 Spark 加 HDFS 这种离线分析框架来说的，对于我们实时性要求更高的场景是无法满足的。因此需要进行开发，这就涉及到了方案选型和架构设计。

3. 腾讯看点信息流的业务流程

在大家介绍一下腾讯看点信息流的业务流程，了解了业务的流程，就能够更好的理解技术架构的方案。

第 1 步，内容创作者发布内容；

第 2 步，内容会经过内容审核系统启用或者下架；

第 3 步，启用的内容给到推荐系统和运营系统，分发给 C 侧用户；

第 4 步，内容分发给 C 侧用户之后，用户会产生各种行为，比如说曝光、点击举报等，这些行为数据通过埋点上报，实时接入到消息队列中；

第 5 步，构建实时数据仓库；

第 6 步，构建实时数据查询系统。

我们做的工作主要就在第 5 步和第 6 步，可以看一下我们的业务流程图来进一步的了解。

在业务流程图中，我们主要做的两部分工作，就是图中有颜色的这两部分：

橙色部分，我们构建了一个腾讯看点的实时数据仓库；

绿色部分，我们基于了 OLAP 的存储计算引擎，开发了实时数据分析系统。

为什么要构建实时数据仓库？因为原始的数据上报数据量非常大，一天上报的峰值就有上万亿条，而且上报的格式非常混乱，缺乏了内容的维度、信息用户的画像信息，下游就根本没有办法直接使用。
而我们提供的实时数据仓库，是根据腾讯看点信息流的业务场景，进行了内容维度的关联，用户画像的关联和各种粒度的聚合，下游可以非常方便的使用实时数据，而且实时数据仓库可以提供给下游的用户反复的消费使用，可以大量的减少重复的工作。
绿色部分的多维实时数据分析系统，消费了我们提供的实时数据仓库，利用了 OLAP 存储计算引擎，将海量的数据进行高效的存储，再提供高性能的多维实时分析功能。

二、架构设计

1. 设计的目标与难点

首先来看一下数据分析系统的设计目标与难点。我们的实时数据分析系统分为四大模块：

实时计算引擎；

实时存储引擎；

后台服务层；

前端展示层。

难点主要在于前两个模块，实时计算引擎和实时存储引擎。

千万级每秒的海量数据如何实时的接入，并且进行极低延迟的维表关联是有难度的；

实时存储引擎如何支持高并发的写入。高可用分布式和高性能的索引查询是比较难的，可以看一下我们的系统架构设计来了解这几个模块的具体实现。

2. 系统架构设计

关于系统架构的设计，主要从以下几方面来讲。

■ 2.1 实时计算

接入层主要是从千万级每秒的原始消息队列中拆分出不同业务不同行为数据的微队列。拿 QQ 看点的视频内容来说，拆分过后的数据就只有百万级每秒了。

实时计算层主要是负责多行行为流水数据进行 "行转列" 的操作，实时关联用户画像数据和内容维度数据。

实时数仓存储层主要就是设计出符合看点的业务，下游好用的实时消息队列。

我们暂时提供了两个消息队列，作为实时数仓的两层：

第一层是 DWM 层，它是内容 ID 和用户 ID 粒度聚合的，就是说一条数据包含了内容 ID 和用户 ID，然后还有 B 侧的内容维度数据，C 侧的用户行为数据，还有用户画像数据。

第二层是 DWS 层，这一层是内容 ID 粒度聚合的，就是一条数据包含了内容 ID、B 侧数据和 C 侧数据。可以看到内容 ID 和用户 ID 粒度的消息，队列流量进一步减小到了 10 万级每秒，内容 ID 粒度更是减小到了万级每秒，并且格式更加清晰，维度信息更加丰富。

■ 2.2 实时存储

实时写入层主要是负责 Hash 路由，将数据写入；

OLAP 存储层是利用 MPP 的存储引擎，设计出符合业务的索引和物化视图，高效存储海量数据；

后台接口层是提供了高效的多维实时查询接口。

■ 2.3 后台服务

后台服务是基于腾讯自研的 RPC 后台服务框架写的，并且会进行一些二级缓存。

■ 2.4 前端服务

前端采用的是开源组件 Ant Design，利用了 Nginx，反向代理了浏览器的请求到后台服务器上。

3. 方案选型

关于架构设计的方案选型，我们对比了业内的领先方案，最终选择了最符合我们业务场景的方案。

■ 3.1 实时数仓的选型

我们选择的是业内比较成熟的 Lambda 架构，它的优点是成熟度高，灵活性高，迁移成本低等等。但是它有一个缺点，实时和离线用了两套代码，可能会存在一个口径修改了数据，但另一个没有修改从而造成数据不一致的问题。我们的解决方案每天都有做数据对账的工作，如果有异常会进行告警。

■ 3.2 实时计算引擎的选型

我们选择了 Flink 作为实时计算引擎，是因为 Flink 在设计之初就是为了流处理来设计的，Sparks Streaming 严格来说还是微批处理，storm 现在用的已经不是很多了。并且， Flink 还有 exactly-once 的准确性，轻量级的容错机制，低延迟高吞吐，应用性高的特点，所以我们选择了 Flink 作为实时计算引擎。

■ 3.3 实时存储引擎

我们的要求是需要有维度索引，支持高并发的写入和高性能的多维实时 OLAP 查询。可以看到 HBase，TiDB 和 ES 都不能满足要求。Druid 有一个缺陷，它是按照时序划分 Segment，也就说明无法将同一个内容全部存放在同一个 Segment 上，所以在计算全局的 Top N 的时候就只能够计算近似值。于是我们选择了最近两年大火的 MPP 数据库引擎 Clickhouse，后面我会结合我们的具体使用场景和 Clickhouse 的内核原理，介绍一下 Clickhouse 的优势。

三、实时数仓

实时数仓也分为三块来介绍：

第一是如何构建实时数仓；

第二是实时数仓的优点；

第三是基于实时数仓，利用 Flink 开发实时应用时候遇到的一些问题。

实时数仓这一部分的难度在于它处于一个比较新的领域，并且各个公司各个业务的差距都比较大，怎么样能够设计出方便好用，符合看点信息流业务场景的实时数仓是有难度的。

1. 如何构建实时数仓

先看一下实时数仓要做什么。实时数仓对外来说就是几个消息队列，不同的消息队列里面存放的是不同聚合粒度的实时数据，包括了内容 ID、用户 ID、C 侧用户行为数据，B 侧内容维度数据和用户画像数据等。搭建实时数仓可以分为三步。

■ 1.1数据清洗

首先从海量的原始消息队列中进行复杂的数据清洗操作，可以获得格式清晰的实时数据。它的具体操作其实就是在 Flink 的实时计算环节，先按照一分钟的粒度进行了窗口的聚合，在窗口内原本多行的行为数据被转成了一行多列的数据格式。

■ 1.2 高性能维表关联

第二步是进行高性能的实时维表关联，补充用户画像数据和内容维度数据等。但是海量的用户画像数据是存在于 HDFS 上的，内容维度数据又是存在于 HBase 上的，所以想要极低延迟的维表关联是有技术挑战的。这一块在后文会单独介绍。

■ 1.3 不同粒度聚合

第三步是将算好的实时数据按照不同的粒度进行聚合，然后放到对应的消息队列中进行保存，可以提供给下游多用户复用，到这里实时数仓就搭建完成了。

接下来详细介绍一下第二步中高性能实时维表关联是怎么处理的。

几十亿的用户画像数据存放在 HDFS 上，肯定是无法进行高性能的维表关联的，所以需要进行缓存。由于数据量太大，本地缓存的代价不合理，我们采用的是 Redis 进行缓存，具体实现是通过 Spark 批量读取 HDFS 上的画像数据，每天更新 Redis 缓存，内容维度数据存放在 HBase 中。

为了不影响线上的业务，我们访问的是 HBase 的备库，而且由于内容维度变化的频率远高于用户画像，所以维度关联的时候，我们需要尽量的关联到实时的 HBase 数据。

一分钟窗口的数据，如果直接关联 HBase 的话，耗时是十几分钟，这样会导致任务延迟。我们发现 1000 条数据访问 HBase 是秒级的，而访问 Redis 的话只是毫秒级的，访问 Redis 的速度基本上是访问 HBase 的 1000 倍，所以我们在访问 HBase 的内容之前设置了一层 Redis 缓存，然后通过了监听 HBase-proxy 写流水，通过这样来保证缓存的一致性。

这样一分钟的窗口数据，原本关联内容维度数据耗时需要十几分钟，现在就变成了秒级。我们为了防止过期的数据浪费缓存，缓存的过期时间我们设置成了 24 个小时。

最后还有一些小的优化，比如说内容数据上报过程中会上报不少非常规的内容 ID，这些内容 ID 在 HBase 中是不存储的，会造成缓存穿透的问题。所以在实时计算的时候，我们直接过滤掉这些内容 ID，防止缓存穿透，又减少了一些时间。另外，因为设置了定时缓存，会引入一个缓存雪崩的问题，所以我们在实时计算的过程中进行了削峰填谷的操作，错开了设置缓存的时间，来缓解缓存雪崩的问题。

2. 实时数仓的优点

我们可以看一下，在我们建设实时数仓的前后，开发一个实时应用的区别。

没有数仓的时候，我们需要消费千万级每秒的原始队列，进行复杂的数据清洗，然后再进行用户画像关联、内容维度关联，才能够拿到符合要求格式的实时数据。开发和扩展的成本都会比较高。如果想开发一个新的应用，又要走一遍流程。现在有了实时数仓之后，如果再想开发一个内容 ID 粒度的实时应用，就直接申请 TPS 万级每秒的 DWS 层消息对列即可，开发成本变低很多，资源消耗小了很多，可扩展性也强了很多。

我们看一个实际的例子，开发我们系统的实时数据大屏，原本需要进行如上的所有操作才能够拿到数据，现在只需要消费 DWS 层消息队列写一条 Flink SQL 即可，仅仅会消耗 2 个 CPU 核心和 1GB 的内存。以 50 个消费者为例，建立实时数仓的前后，下游开发一个实时应用，可以减少 98% 的资源消耗，包括了计算资源、存储资源、人力成本和开发人员的学习接入成本等等，并且随着消费者越多节省的就越多，就拿 Redis 存储这一部分来说，一个月就能够省下上百万的人民币。

3. Flink 开发过程中遇到的问题总结

在利用 Flink 开发实时应用的过程中遇到过不少问题，这里选择几个比较有代表性的给大家分享一下。

■ 3.1 实时数据大屏

第一个是开发实时数据大屏的时候，开始是通过 Flink SQL 来实现的，功能非常简单，就是计算当天截止到当前累计的点击数，实现的方式也非常简单，输入的 source table 是实时数据仓库的消息队列。输出的 sink table 就是 Redis。SQL 就是：select sum(click) from sourceTable Group by day time。
这个任务看起来是没有问题的，但是实际跑起来数据却无法实时更新，是因为 source table 每到达一条点击数据，累计值都会加一，然后就会往 Redis 中写一条最新的数据。所以当数据量太大的时候，它就会频繁的写 Redis，所以这样就会导致写 Redis 的网络延迟会显得非常高，从而会导致背压数据无法实时更新。
我们做了一个简单的优化，用 table API 执行完 SQL 之后，转化成 DataStream，然后通过一个一秒钟的数据窗口，每秒钟仅仅会输出最新的累计值到 Redis 中，这样的数据就可以实时更新了。

■ 3.2 Flink state 的 TTL

Flink 的 1.6 版本开始引入了 state TTL，开启了 state TTL 之后，Flink 就会为每一个 keyed state 增加一个时间戳字段，通过时间戳字段就可以判断 state 是不是过期，是否需要进行清理。但是如果仅仅从字面意思上理解就会遇到一些问题，在 1.10 版本之前，虽然开启了 state TTL，但是 Flink 默认是不会自动清理过期的 state 的。所以如果是 heap memory backend，就会导致 OOM 的问题；如果是 rocksDB backend，就会导致 state 的状态越来越大，最终会导致重启的时候耗费的时间过长。后面经过调研，我们发现有两种方式可以清理 Flink 的过期的 state。
第一种是手动清理，第二种的话是自动清理。我们最终选择的是以手动触发的方式来清理过期的 state。每天在深夜，也就是业务低谷期的时候，我们会对 state 中的数据进行遍历的访问，访问到过期的数据，就会进行清理。
为什么我们没有选择 Flink 的自动清理策略，是因为 Flink 在 1.8 版本之前，只有一种自动清理策略，clean up in full snapshot。这种清理策略从名字上来看就知道他是在做全量 snapshot 的时候会进行清理，但是有一个致命的缺陷，它并不会减少本身 state 的大小，而是仅仅把清理过后的 state 做到 snapshot 里面，最终还是会 OOM。并且，它重启之后才能够加载到之前清理过的 state，会导致它频繁的重启。
虽然在 1.8 版本之后，增加了两种自动清理的策略，但是因为它是异步清理，所以他的清理时机和使用方式都不如手动清理那么灵活，所以最终我们还是选择了手动触发的方式进行清理。在 1.10 版本之后，默认是选择了自动清理的策略，但是这就要求用户对自动清理策略的时机和策略有比较好的了解，这样才能够更好的满足业务的需求。

■ 3.3 使用 Flink valueState 和 mapState 经验总结

虽然通过 valueState 也可以存储 map 结构的数据，但是能够使用 mapState 的地方尽量使用 mapState，最好不要通过 valueState 来存储 map 结构的数据，因为 Flink 对 mapState 是进行了优化的，效率会比 valuState 中存储 map 结构的数据更加高效。

比如我们遇到过的一个问题就是使用 valueState 存储了 map 结构的数据，选择的是 rocksDB backend。我们发现磁盘的 IO 变得越来越高，延迟也相应的增加。后面发现是因为 valueState 中修改 map 中的任意一个 key 都会把整个 map 的数据给读出来，然后再写回去，这样会导致 IO 过高。但是 mapState，它每一个 key 在 rocksDB 中都是一条单独的 key，磁盘 IO 的代价就会小很多。

■ 3.4 Checkpoint 超时问题

我们还遇到过一些问题，比如说 Checkpoint 超时了，当时我们第一个想法就是计算资源不足，并行度不够导致的超时，所以我们直接增加了计算资源，增大了并行度，但是超时的情况并没有得到缓解。后面经过研究才发现是数据倾斜，导致某个节点的 barrier 下发不及时导致的，通过 rebalance 之后才能够解决。

总的来说 Flink 功能还是很强的，它文档比较完善，网上资料非常丰富，社区也很活跃，一般遇到问题都能够比较快的找到解决方案。

四、实时数据查询系统

我们的实时查询系统，多维实时查询系统用的是 Clickhouse 来实现的，这块分为三个部分来介绍。第一是分布式高可用，第二是海量数据的写入，第三是高性能的查询。

Click house 有很多表引擎，表引擎决定了数据以什么方式存储，以什么方式加载，以及数据表拥有什么样的特性？目前 Clickhouse 拥有 merge tree、replaceingMerge Tree、AggregatingMergeTree、外存、内存、IO 等 20 多种表引擎，其中最体现 Clickhouse 性能特点的是 merge tree 及其家族表引擎，并且当前 Clickhouse 也只有 merge 及其家族表引擎支持了主键索引、数据分区、数据副本等优秀的特性。我们当前使用的也是 Clickhouse 的 merge tree 及其家族表引擎，接下来的介绍都是基于引擎展开的。

1. 分布式高可用

先看分布式高可用，不管单节点的性能多强，随着业务的增长，早晚都会有遇到瓶颈的一天，而且意外的宕机在计算机的运行中是无法避免的。Clickhouse 通过分片来水平扩展集群，将总的数据水平分成 m 分，然后每个分片中保存一份数据，避开了单节点的性能瓶颈，然后通过副本即每个分片拥有若干个数据一样的副本来保障集群的高可用。
再看看 Clickhouse 默认的高可用方案，数据写入是通过分布式表写入，然后分布式表会将数据同时写入到同一个分片的所有副本里面。这里会有一个问题，如果副本 0 写入成功，副本 1 写入失败，那么就会造成同一个分片的不同副本数据不一致的问题，所以默认的高可用方案是不能够用于生产环境的。
我们这里听取的是 Clickhouse 官方的建议，借助了 Zookeeper 实现高可用的方案，数据写入一个分片的时候，仅仅写入一个副本，然后再写 Zookeeper，通过 Zookeeper 告诉同一个分片的其他副本，再过来拉取数据，保证数据的一致性。
接下来看一下 Clickhouse 实现这种高可用方案的底层原理，这种高可用的方案需要通过 Clickhouse 的 replicated merge tree 表引擎来实现，其中在 replicated merge tree 表引擎的核心代码中，有大量跟 Zookeeper 进行交互的逻辑，从而实现了多个副本的协同，包括主副本的选举写入任务队列的变更和副本状态的变化等等。可以看到外部数据写入 Clickhouse 的一个分片，会先写入一个副本的内存中，在内存中按照指定的条件排好序，再写入磁盘的一个临时目录。最后将临时目录重命名为最终目录的名字，写完之后通过 Zookeeper 进行一系列的交互，实现数据的复制。
这里没有选用消息队列进行数据的同步，是因为 Zookeeper 更加轻量级，而且写的时候任意写一个副本，其他的副本都能够通过读 Zookeeper 获得一致性的数据，而且就算其他节点第一次来获取数据失败了，后面只要发现它跟 Zookeeper 上的数据记录不一致，就会再次尝试获取数据，保证数据的一致性。

2. 海量数据的写入

■ 2.1 Append + Merge

数据写入遇到的第一个问题是海量数据直接写 Clickhouse 是会失败的。Clickhouse 的 merge tree 家族表引擎的底层原理类似于 LSM tree，数据是通过 append 的方式写入，后续再启动 merge 线程，将小的数据文件进行合并。了解了 Clickhouse merge tree 家族表引擎的写入过程，我们就会发现以下两个问题。

如果一次写入的数据太少，比如一条数据只写一次，就会产生大量的文件目录。当后台合并线程来不及合并的时候，文件目录的数量就会越来越多，这会导致 Clickhouse 抛出 too many parts 的异常，写入失败。

另外，之前介绍的每一次写入除了数据本身，Clickhouse 还会需要跟 Zookeeper 进行 10 来次的数据交互，而我们知道 Zookeeper 本身是不能够承受很高的并发的，所以可以看到写入 Clickhouse QPS 过高，导致 zookeeper 的崩溃。

我们采用的解决方案是改用 batch 的方式写入，写入 zookeeper 一个 batch 的数据，产生一个数据目录，然后再与 Zookeeper 进行一次数据交互。那么 batch 设置多大？如果 batch 太小的话，就缓解不了 Zookeeper 的压力；但是 batch 也不能设置的太大，要不然上游的内存压力以及数据的延迟都会比较大。所以通过实验，最终我们选择了大小几十万的 batch，这样可以避免了 QPS 太高带来的问题。

其实当前的方案还是有优化空间的，比如说 Zookeeper 无法线性扩展，我有了解到业内有些团队就把 Mark 和 date part 相关的信息不写入 Zookeeper。这样能够减少 Zookeeper 的压力。不过这样涉及到了对源代码的修改，对于一般的业务团队来说，实现的成本就会比较高。

■ 2.2 分布式表写入

如果数据写入通过分布式表写入会遇到单点的磁盘问题，先介绍一下分布式表，分布式表实际上是一张逻辑表，它本身并不存储真实的数据，可以理解为一张代理表，比如用户查询分布式表，分布式表会将查询请求下发到每一个分片的本地表上进行查询，然后再收集每一个本地表的查询结果，汇总之后再返回给用户。那么用户写入分布式表的场景，是用户将一个大的 batch 的数据写入分布式表，然后分布式表示按照一定的规则，将大的 batch 的数据划分为若干个 mini batch 的数据，存储到不同的分片上。

这里有一个很容易误解的地方，我们最开始也是以为分布式表只是按照一定的规则做一个网络的转发，以为万兆网卡的带宽就足够，不会出现单点的性能瓶颈。但是实际上 Clickhouse 是这样做的，我们看一个例子，有三个分片 shard1，shard2 和 shard3，其中分布式表建立在 shard2 的节点上。

第一步，我们给分布式表写入 300 条数据，分布式表会根据路由规则把数据进行分组，假设 shard1 分到 50 条，shard2 分到 150 条，shard3 分到 100 条。

第二步，因为分布式表跟 shard2 是在同一台机器上，所以 shard2 的 150 条就直接写入磁盘了。然后 shard1 的 50 条和 shard3 的 100 条，并不是直接转发给他们的，而是也会在分布式表的机器上先写入磁盘的临时目录。

第三步，分布式表节点 shard2 会向 shard1 节点和 shard3 节点分别发起远程连接的请求，将对应临时目录的数据发送给 shard1 和 shard3。

这里可以看到分布式表所在的节点 shard2 全量数据都会先落在磁盘上，我们知道磁盘的读写速度都是不够快的，很容易就会出现单点的磁盘性能瓶颈。比如单 QQ 看点的视频内容，每天可能写入百亿级的数据，如果写一张分布式表，很容易就会造成单台机器出现磁盘的瓶颈，尤其是 Clickhouse 的底层运用的是 merge tree，它在合并的过程中会存在写放大的问题，这样会加重磁盘的压力。
我们做的两个优化方案:

第一个就是对磁盘做了 RAID 提升了磁盘的 IO；

第二就是在写入之前，上游进行了数据的划分分表操作，直接分开写入到不同的分片上，磁盘的压力直接变为了原来的 n 分之一，这样就很好的避免了磁盘的单点的瓶颈。

■ 2.3 局部 Top 并非全局 Top

虽然我们的写入是按照分片进行了划分，但是这里引入了一个分布式系统常见的问题，就是局部的 Top 并非全局 Top。比如说同一个内容 x 的数据落在了不同的分片上，计算全局 Top100 点击内容的时候，之前说到分布式表会将查询请求下发到各个分片上，计算局部的 Top100 点击的内容，然后将结果进行汇总。
举个例子，内容 x 在分片一和分片二上不是 Top100，所以在汇总数据的时候就会丢失掉分片一和分片二上的内容 x 的点击数据。

第二是会造成数据错误，我们做的优化就是在写入之前加上了一层路由，我们将同一个内容 ID 的数据全部路由到了同一个分片上，解决了该问题。这里需要多说一下，现在最新版的 Clickhouse 都是不存在这样这个问题的，对于有 group by 和 limit 的 SQL 命令，只把 group by 语句下发到本地表进行执行，然后各个本地表执行完的全量结果都会传到分布式表，在分布式表再进行一次全局的 group by，最后再做 limit 的操作。

这样虽然能够保证全局 top N 的正确性，但代价就是牺牲了一部分的执行性能。如果想要恢复到更高的执行性能，我们可以通过 Clickhouse 提供的 distributed_group_by_no_merge 参数来选择执行的方式。然后再将同一个内容 ID 的记录全部路由到同一个分片上，这样在本地表也能够执行 limit 操作。

3. 高性能的存储和查询

Clickhouse 高性能查询的一个关键点，就是稀疏索引。稀疏索引这个设计很有讲究，设计的好可以加速查询，设计的不好反而会影响查询效率。因为我们的查询大部分都是时间和内容 ID 相关的，比如说某个内容过去 n 分钟在各个人群的表现如何，我按照日期分钟粒度时间和内容 ID 建立了稀疏索引，针对某个内容的查询，建立稀疏索引之后，可以减少 99% 的文件扫描。
Clickhouse 高性能查询的第二点，就是我们现在的数据量太大，维度太多，拿 QQ 看点的视频内容来说，一天入库的流水就有上百亿条，有些维度有几百个类别，如果一次性把所有的维度进行预聚合查询反而会变慢，并且索引会占用大量的存储空间。我们的优化就是针对不同的维度建立对应的预聚合和物化视图，用空间换时间，这样可以缩短查询的时间。

举个例子，通过 summary merge tree 建立一个内容 ID 粒度聚合的累积，累加 pv 的物化视图，这样相当于提前进行了 group by 的计算，等真正需要查询聚合结果的时候，就直接查询物化视图，数据都是已经聚合计算过的，且数据的扫描量只是原始流水的千分之一。

分布式表查询还会有一个问题，就是查询单个内容 ID 的时候，分布式表会将查询请求下发到所有的分片上，然后再返回给查询结果进行汇总。实际上因为做过路由，一个内容 ID 只存在于一个分片上，剩下的分片其实都是在空跑。针对这类的查询，我们的优化就是后台按照同样的规则先进行路由，然后再查询目标分片，这样减少了 n 分之 n -1 的负载，可以大量的缩短查询时间。而且由于我们提供的是 OLAP 的查询，数据满足最终的一致性即可。所以通过主从副本的读写分离，也可以进一步的提升性能。我们在后台还做了一个一分钟的数据缓存，这样针对相同条件的查询，后台就可以直接返回。

4. Clickhouse 扩容方案

我们调研了业内一些常见的方案：

比如说 HBase 原始数据是存放在 HDFS 上的，扩容只是 region server 的扩容，并不涉及到原始数据的迁移。

但是 Clickhouse 的每个分片数据都是在本地，更像是 RocksDB 的底层存储引擎，不能像 HBase 那样方便的扩容。

然后是 Redis，Redis 是 Hash 槽这一种，类似于一致性 Hash 的方式，是比较经典的分布式缓存方案。

Redis slot 在 Hash 的过程中，虽然会存在短暂的 ASK 不可用，但是总体上来说迁移还是比较方便的。就从原来的 h0 迁移迁移到 h1，最后再删除 h0，但是 Clickhouse 大部分都是 OLAP 的批量查询，而且由于列式存储不支持删除的特性，一致性 hash 的方案也不是很合适。
我们目前的扩容方案就是从实时数仓另外消费一份数据写入新的 Clickhouse 集群，两个集群一起跑一段时间，因为实时数据我们现在就保存了三天，等三天之后，后台服务就直接访问新的 Clickhouse 集群。

五、实时系统应用成果总结

我们输出了腾讯看点的实时数据仓库，DWM 层和 DWS 层两个消息队列，上线了腾讯看点的实时数据分析系统，该系统能够亚秒级的响应多维条件查询请求。在未命中缓存的情况下：

过去 30 分钟的内容查询，99% 的请求耗时在一秒内；

过去 24 小时的内容查询 90% 的请求耗时在 5 秒内，99% 的请求耗时在 10 秒内。

热点推荐

Flink Forward Asia 2021 正式启动！议题火热征集中！

顺丰科技 Hudi on Flink 实时数仓实践

更多 Flink 相关技术问题，可扫码加入社区钉钉交流群～

戳我，查看作者分享原版视频！

腾讯还是向米哈游让步了？

Sun, 03 Oct 2021 10:07:41 CST

近日，腾讯应用宝首次出现了米哈游旗下游戏《原神》的安装包，同时提供了该游戏的云游戏试玩服务。

据报道，米哈游近期已与腾讯达成合作，合作从9月初《原神》2.1版本的上线开始。截至9月28日，《原神》在应用宝的下载量已近74万。

而且，值得注意的是，和此前腾讯应用宝上的绝大部分游戏都带有应用宝logo或是腾讯旗下游戏工作室logo的角标不同，应用宝内的《原神》并没有打上任何和腾讯有关的符号。事实上，此次应用宝上架的《原神》是米哈游的官服版本（而非主流做法接入自带渠道账户体系的渠道软件开发工具包），甚至也并没有像应用宝上的其他游戏一样接入腾讯的账号系统。

这一情况也被视作是腾讯方面对《原神》做出的让步。

另外也有消息称，此次上架，《原神》和应用宝采取了3：7的分成比例，米哈游将能分到70%的游戏收入，而应用宝只拿30%。若属实，这也是此前腾讯不曾有过的让步——一般来说，游戏在上架安卓手机应用商店这样的渠道时，后者的抽成比例达50%左右，而腾讯应用宝对手游的抽成一度高达70%。

考虑到此前米哈游和腾讯之间曾有过的“嫌隙”，此次两家的合作以及腾讯做出的让步也颇耐人寻味。

去年就曾有业内人士透露，腾讯游戏在去年下半年曾多次希望将米哈游纳入麾下，从计划收购，到提议入股，再到放低姿态表示愿意只拿流量分红，却最终被米哈游通通拒绝。这家游戏初创公司同时拒绝的，还有国内的另一大游戏流量渠道字节跳动。

从去年9月28日开始公测起，《原神》就采用了一条与以往游戏不同的发行路线。米哈游没有选择与应用宝、华为、小米和OPPO等几乎垄断了游戏分发渠道的应用商店合作，而是通过其官方网站以及一些其他第三方平台发行了该游戏。

事实证明，绕过这些主流渠道并没有阻碍《原神》迅速成为手游市场的一款现象级爆款游戏。

去年刚发布短短一周时，《原神》就创下了1700万次移动端下载和超过5000万美元收入的纪录。不到6个月的时间里，在超过50个国家和地区发行的《原神》就在苹果的App Store和谷歌应用商店创造了10亿美元的销售收入（相较之下，腾讯旗下的王牌手游《王者荣耀》花了18个月才达到这一水平），成为现阶段中国最成功的出海游戏。

YouTube博主直播玩《原神》

这款免费的开放世界手游还在不断创造新的纪录。根据Sensor Tower今年7月公布的数据，在美国，动作类游戏是今年上半年增速最快的手游类型，收入同比翻倍增长至4.36亿美元，其中，《原神》这款角色扮演类动作游戏贡献了最多收入，将近有1.74亿美元；App Annie也将《原神》评为今年为止仅次于《Roblox》的第二大吸金手游。

“米哈游开创了一个重要的先例：一家独立的中国游戏工作室也可以在 ‘一夜之间’发行一款全球范围的现象级游戏，甚至不需要腾讯的帮助。”游戏行业咨询公司Kantan Games的CEO Serkan Toto在接受《南华早报》的采访时曾这样表示。

事实上，《原神》和腾讯应用宝此次所达成的新合作模式，也标志着传统游戏行业渠道强（尤其是应用商店的垄断）、开发者弱的状况正在发生某种松动。

一些新的游戏发行渠道正在崛起。包括手游分享社区TapTap，短视频平台抖音和快手，以及哔哩哔哩这样的视频社区在内的平台都纷纷开始向游戏开发者示好，推出了为后者提供更高分成（甚至是平台零分成）的政策，这些都削弱了过去作为主流游戏发行渠道的腾讯和其他智能手机制造商的地位。

TapTap上的《原神》

与此同时，随着游戏版号新政的推行，国内手游行业已经从过去的粗放模式向精品化转型，游戏开发者对游戏质量的把控也更加看重，这些使得高质量游戏的议价权大幅提升。

“ 游戏发行渠道正变得越来越多元，高质量游戏如今也能更容易地吸引流量，这意味着游戏开发者拥有了更大的选择权和话语权。顶尖的游戏公司也更有可能去领导中国手游市场收入分成模式的变革。”民生证券在一份调研报告中如此写道。

事实上，在这次上架腾讯应用宝前，《原神》在今年2月就已经登陆小米应用商店，同样采取了3：7的分成比例，小米应用商店还为原神配备了包括开屏广告、首屏大图和浏览器广告推荐位等在内的全套宣传。

而就腾讯自身来说，其实也有提高旗下游戏分成比例的需求。早在2019年，腾讯就和国内各大渠道方“摊牌”，要求旗下部分的新游戏（例如《剑网3：指尖江湖》和《跑跑卡丁车：官方竞速版》）要采用7:3的分成比例。两年过去，腾讯自己的渠道终于也做了表率。

另一个被外界认为腾讯之所以会接受和米哈游3：7分成比例的原因是，经过多次延期的switch版《原神》即将在年末上线，腾讯作为switch在国内的代理，自然对游戏内容的需求也十分迫切，而以让步的方式上架《原神》则是一种对米哈游的示好。

就《原神》而言，选择与腾讯合作也的确符合其现阶段的利益。

相比起《王者荣耀》和《和平精英》这样更强调玩家与玩家对抗（PVP）的某种意义上的“社交游戏”，主打开放世界和角色扮演的《原神》，更多是玩家与环境的对抗（PVE），其世界观相比于传统的线性叙事游戏更为庞大，这也意味着此类游戏的内容基本全部需要开发商来提供。这同时带来一个问题——当游戏内容被消耗完全后，就会出现成规模的用户流失的情况。

所以与作为国内最大安卓渠道的应用宝合作，由于两者的用户群体存在一定差异，应用宝反而可能为《原神》带来新的用户增量。

高级TMT分析师、沣京资本基金经理吴悦风也因此认为，腾讯与米哈游的合作是一次双赢。“原神挖了一批应用宝的潜在用户，也可以借这个机会加大在企鹅系的买量，腾讯也可以赚一波这些新用户30%的分成。” 他在微博写道。

（本文首发于品玩英文站，原文链接： https://en.pingwest.com/a/9264，作者：Rebbeca Ren）

腾讯人最喜欢的编程语言是什么？ | 内含完整报告_TAPD敏捷研发-CSDN博客

Tue, 24 Aug 2021 07:43:01 CST

先抛结论：这份报告，含金量很足，请认真研读

刚刚，腾讯正式对外发布2020年度《腾讯研发大数据报告》，这份由腾讯技术委员会出品的报告，披露了过去一年腾讯在研发投入、研发效能及开源协同等方面的重要数据。

大家普遍关注的问题，在这里都可以找到答案，比如，腾讯人最喜欢什么编程语言，还有什么技术leader坚持写代码，腾讯开源协同进展等等，你都能在这份报告中找到答案。

准备好了吗，一起带你去感受吧。

研发人员占比68%，新增代码20亿行

腾讯在研发投入上持续加码。报告显示，2020年腾讯研发人员占公司总人数的68%，同比去年增长16%，在科技企业中位居前列。

在开源协同、自研上云两大技术战略的推动下，腾讯研发效能进一步提升，2020年腾讯新增研发项目超4000个，同比增长22%；新增代码超过20亿行，同比增长67%。研发人员日均完成5242个需求，有30%的需求能够在1天之内得到响应，平均需求响应时长缩短8.66小时，有46%的需求能够在3天内开发完成，单个Bug的平均解决时长较去年缩短了15%，研发更敏捷。

代码质量也是研发人员关注的重点。腾讯倡导“小批量、多批次”的代码提交策略。2020年，代码评审覆盖率达7成，平均每位评审人参评90次，平均每次评审293行代码。

在研发持续交付方面，腾讯平均每周构建次数达170万次，项目年均产物大小1TB，年均交付次数5万次，全年共推动修复代码Bug和安全漏洞131万个，编译加速累计节省编译耗时5.8万个小时。

DevOps工具协同集成，研发效能持续提升

在长期的研发实践中，腾讯推动了代码管理平台工蜂、敏捷研发协作平台 TAPD、智能化持续集成平台腾讯 CI（蓝盾）、集成化研效门户智研、企业级研发云平台等多个工具平台协同集成，共同组成了贯穿上下游的研效工具链体系。这一体系的标准化落地，进一步降低了开发成本、增强了研发人员的使用体验。TAPD、腾讯工蜂、蓝盾三大腾讯主流研发工具的日均API请求量达到四千万次。

2020年，腾讯通过信通院《研发运营一体化（ DevOps ）能力成熟度模型》系统和工具部分首批评估，获评为卓越级。这意味着腾讯形成了业内领先的研发体系，研发效能工具得到了国家级的权威认可。

C++蝉联腾讯最受欢迎的编程语言。随着云计算和微服务相关技术的进一步发展，Go语言使用次数增速第一，并超越JavaScript成为腾讯第二受欢迎的编程语言。同时，TypeScript以其优秀的架构设计和高兼容性，成为了2020年增速第二的语言，也是最具潜力的前端语言。

技术管理人员继续保持在研发方面的高参与度。腾讯70%的技术Leader持续输出代码。2020年全年，平均每人输出3.2万行，并且参与142次代码评审。54%的12级及以上技术专家潜心编码，人均输出代码3万余行，参与98次代码评审。

开源协同深入人心，开源贡献度居全球科技企业头部

2018年技术委员会成立以来，开源协同已成为腾讯在技术发展层面的一个关键词，开放的技术氛围和开放的代码文化逐渐深入人心。腾讯内部开源代码库新增超过57000个，比2019年增长了29%，有超过17000名研发人员参与贡献内部开源项目。

上线两年时间的腾讯内部技术交流社区“码客”，成为了腾讯研发人员精进技术、交流心得的“根据地”。2020年，码客上有200+个技术圈子助力研发人员学习成长。其中，55%的技术问题能够在提出后的1小时内得到响应，84%的技术问题可以在1天内得到解决。医疗AI、黑灰产人机对抗、Rust语言等新技术话题的关注度不断提升。

除社区分享交流之外，内部竞赛比拼也是腾讯研发人员自我提升的重点方向，2020年腾讯内部技术赛事吸引了近万名研发人员参与，赛事代码总提交次数达316万次。

开源向内提升了公司的研发效率，向外则是连接全球开发者共享知识、共建技术的桥梁。2020年是腾讯开源十周年，十年来，腾讯开源项目在Github上的全球Star数每年都有30%的增长，已经成为全球开源贡献最大的科技公司之一。

腾讯深度参与了数十个国际知名开源项目的贡献，在OpenJDK、KVM等多个顶级开源社区贡献榜中，腾讯均在国内排行第一，作为主要贡献者主导了7个国际知名开源项目的版本发布。腾讯向多个国际顶级开源基金会捐赠了6个开源项目，两大开源项目TencentOS Tiny、TKEstack入选国内首个开源基金会首批捐献项目。

今年抗疫期间，腾讯第一时间参与到Linux基金会全新的公共卫生计划LFPH中，作为中国唯一的创始成员单位，为全球合作抗击疫情做出了贡献。

用技术连接公益

“技术助力公益”则是腾讯技术文化的温暖一面。2020年，腾讯共有1132名研发人员参与了技术公益志愿者活动，总服务时长超过725个工作日，其中最多的一名同事共参与12个志愿项目。

腾讯即视团队积极探索AI安全技术在智慧养老领域的落地，打造智能视频分析解决方案，推出了“智能跌倒监测系统”，当系统发现老人跌倒时，会自动识别老人姿态，并自动报警，让老人得到及时救治，使养老更加智能、高效和安全。

在新冠肺炎疫情爆发的初期，在全国各地的腾讯人快速响应战疫需求，远程协作交付需求9万个，需求交付效率提升17%，交付了许多助疫新项目。通过各类疫情服务小程序，帮助民众更便捷地获取疫情信息和服务；通过腾讯会议、企业微信、腾讯文档等产品，帮助企业远程协作；通过在线教育的综合解决方案，服务全国超 1亿的师生授课、学习；为科研机构提供人工智能和算力支持，加速医药研究。

扫码观看鹅厂研发大数据揭秘👇

阿里巴巴和腾讯将不再享受减税政策

Mon, 16 Aug 2021 20:25:27 CST

　　据媒体报道，阿里巴巴在一次电话会议上向投资者透露，其部分业务将不再被视为重点软件企业，从而不再享受10%的税收优惠政策。中国监管机构正在考虑收紧所谓的“关键软件企业”的资格标准，对互联网公司享受的减税优惠提出更严格的要求。业内人士表示，税率优惠政策的变化主要针对的应该是阿里、腾讯等互联网巨头，而对更多创业初期的新经济企业影响不大。

　　4月，工业和信息化部与其他三个部门一起公布了软件企业的指导方针。据财新网报道，这些指导方针将有助于确定哪些企业可以被列为新的“重点软件企业”，别列为此类企业可以获得10%的优惠税率。4月的指导方针指出，合格的公司必须拥有“核心关键技术”，并以此为基础开展业务。这些公司的业务或产品也需要拥有自己的专利或知识产权。

　　在人员方面，指导方针规定，公司必须至少有40%的员工拥有本科或以上学历。此外，研究和开发专业人员需要至少占总人数的25%。符合条件的公司的研究和开发支出也必须占总收入的7%以上，而不是此前的6%。与软件产品开发有关的收入应至少占收入的55%，而以前是50%。

　　据彭博社报道，阿里巴巴预测9月份的公司有效税率为20%，比一年前的8%高出一倍多。阿里巴巴还警告说，大多数互联网公司将可能不再享受10%的税率。

　　摩根士丹利的股票分析师Gary Yu在给客户的一份说明中说，假设腾讯的企业所得税率从10%上升到15%，他预计腾讯的股价将受到6%的负面影响。腾讯是中国最大的游戏公司。Gary Yu说，最坏的情况是税率升至25%。

　　Gary Yu预计，中国第二大游戏公司网易的实际税率将在2021年至2023年期间从去年的20%上升到25%。

　　此举反映了北京对从阿里巴巴到腾讯和美团等大型科技公司的监管紧缩，这些企业运用其庞大的数据，以牺牲用户为代价来造福投资者，饱受外界抨击。8月5日，《证券时报》在一篇评论文章中指出，当这些软件产业已发展起来，具有相对优势时，政府就没有必要再继续给予产业扶持，给予税收优惠。

　　稿源：澎湃新闻

数据双向复制中的6个数据冲突场景和解决思路 - 云+社区 - 腾讯云

Sat, 26 Jun 2021 14:11:39 CST

在双向复制，数据多活中，核心的一个部分就是数据处理，如何保证数据的如下几个问题，是整个方案设计的关键技术。

数据错乱
数据冲突
数据回环
数据一致性

数据错乱的部分主要是基于消息队列的处理内容，可以转化为基于消息队列的消息延迟，消息丢失，消息重复这几个场景进行细化。

其中数据回环的部分可以参考之前的一篇文章。

MySQL双主模式下是如何避免数据回环冲突的

在整个数据流转的过程中，如何处理数据冲突问题，我设定了如下的几个场景，欢迎留言补充。

场景1： INSERT导致的唯一性冲突

同步INSERT语句时违背了唯一性约束，例如双向同步的两个节点同时或者在极为接近的时间INSERT某一个主键值相同的记录，那么同步到对端时，会因为已经存在相同主键值的记录，导致Insert同步失败。

解决思路：

①　使用分布式ID的方案来规避，对于失败的写入，生成新的分布式ID重新应用

②　对于流水型数据，ID自增的方式，可以在写入时不解析id列，采用目标端和消费端的业务ID一致性

③　对于流行型数据，ID自增的方式，写入采用了id列的方式，可以生成新的异常域（比如9999999999开头的ID列）消费应用

场景2： 表结构不同步导致的数据写入失败

在表结构变更过程中，可能因为同步延时问题，出现部分字段，约束不一致导致的数据写入失败

解决思路：

①　表结构变更过程需要避免DML写入，新增字段如果不为空，需要考虑设置默认值

②　数据应用解析需要指定字段名和字段顺序

③　对于新增字段的操作，比如数据字段约束（如不为空）写入失败，需要重新修改JSON数据，重新推送消费

④　对于删除字段的操作，比如字段不一致导致写入失败，需要重新修改JSON数据，重新推送消费

场景3： 字段顺序不一致导致的数据写入失败

解决方法：

①　需要在初始化时维护两端的字段顺序，确保一致

②　通过后端的服务进行字段稽核，分为周期性或者主动监测

③　对于insert语句，在消费数据时，需要指定字段顺序

场景4：UPDATE更新的记录不完全匹配

1） UPDATE要更新的记录在同步目标实例中不存在

解决思路：数据操作转换为幂等SQL,转换为INSERT ON DUPLICATE模式

2） UPDATE要更新的记录出现主键或唯一键冲突

解决思路：

对于状态型数据，如果存在update操作中的唯一性冲突，需要对该记录进行持久化，并阻塞后续对于此记录的事务处理操作，结合业务场景进行分析

场景5： DELETE对应的记录不存在

DELETE要删除的记录在同步的目标实例中不存在。

解决思路：出现这种冲突时，不论配置何种冲突修复策略，可以选择忽略DELETE此类操作。

场景6：表不存在

对一些数据存在周期性管理，可能会触发drop类操作，导致两端的表结构信息丢失

解决思路：

①　对于状态型数据，如果存在DML操作失败，需要对该记录进行持久化，并阻塞后续对于此记录的事务处理操作，稍后结合业务场景进行分析

②　对于流水型数据，如果存在DML操作失败，需要对该记录进行持久化，不阻塞后续对于此记录的事务处理操作，稍后结合业务场景进行分析

在这个基础上，对于数据消费方案和一致性方案，我们在明天给出一些设计方案。

十万腾讯人，自救1000天

Sun, 13 Jun 2021 14:21:52 CST

作者 | 蓝字原创首发 | 蓝字计划

“在腾讯就没有生活，真的是理应如此？”

5月29日凌晨1点39分，一条发布在腾讯内部论坛KM的帖子，犹如沸水泼油，炸出了三万多只鹅。

这位匿名提问者控诉道：在IEG旗下光子工作室（“和平精英”是其代表作）的家属，加班已经常态化。

“这种生存状态真的正常吗？”一位愤怒的妻子，点名责问相关部门：对加班严重的部门能否进行警告甚至强制措施？

这条发布在周六凌晨的帖子，迅速得到了五十多条跟帖，有人劝楼主用脚投票，也有人调侃“都已经这么拼，为什么做不出《原神》”。

最多的人点赞的一条回帖痛陈，个人的苦难不能全部归因于自由的选择。

换言之，在泥沙俱下的大环境，用脚投票的可行性并不高，对比外部，腾讯尚不算是最“卷”的级别。

一周过后，光子工作室发布新规：

1.周三健康日全部门下午六点下班；

2.其余工作日必须晚上九点前下班，特殊加班人数封顶10%，违规团队下周集体六点下班；

3.全面双休，特殊加班人数封顶10%，违规团队未来一个月不得加班；

4.禁止周末连续两天加班。

如此明确、严苛、不留余地的规定，在腾讯公司史上，实属罕见。

列宁说过：“堡垒往往最先从内部攻破”，这并不是KM第一次推动腾讯做出这样的决定了。

马化腾也说过： “很多病都是自救，没有人能帮你。”

2021年4月，马化腾出现在腾讯集团内部一年一度的战略见面会上，那天他和腾讯员工谈了很多内容，包括回应了对他腰部旧伤的担忧，他认为无论是自己，还是腾讯，只有自己可以拯救自己。

“腾讯病历”

时间轴拧回2018年8月12日，至今已1000天。一篇题为《五问！腾讯哪些大公司病让你不吐不快》的檄文，出现在腾讯公司KM上。

KM，是腾讯公司内部论坛的产品，像是企业版“知乎”，员工们可以匿名提问或畅言。在内部说法里， 就连马化腾都不能看到匿名员工的真实身份。

一位自称老鹅（腾讯人自称为鹅）的匿名员工，以KM发帖的形式公开上书——“我觉得腾讯病了，而且很重，到需要动大手术的地步。”

这位匿名老鹅列举了几年工作中观察总结的腾讯“大公司病”，简而言之：

1、我们对汇报、PPT、评奖和分享的重视，甚至超过了工作本身；

2、微信群越拉越多，群里真正解决问题的人越来越少；

3、专家越来越多，高质量创新反而减少，职称沦为养老院；

4、战略缺“大将”和“军长”，中高层权力板结；

5、规则屡屡突破，价值观摇摆，公司早期优秀文化面临稀释。

以上这条被称为“病历”的帖子中，发帖员工痛陈在过去几年，内部备受诟病的 “赛马机制”、“组织臃肿”、“权力板结”和“形式主义”。

比如描述公司内部“形式主义”背后，对应“叠罗汉”的怪现象：副组长向组长，副总监向总监，助理总经理向副总经理汇报，本来公司七个层级已经够多，现在官僚系统还在大膨胀七层都不够用了，“只能用起隔板，充分利用夹层隔板看似很薄，可坚不可摧”。

帖子结尾，匿名老鹅甚至公开向管理层喊话：中高层愿不愿自我解剖？有没有魄力自我手术？敢不敢壮士断腕？能否接受能上能下的流动？愿不愿意放下山头齐心协力补上船底的漏洞？

这条帖子阅读量了停留在64554次，当年腾讯财报数据显示共有4万6千名在册员工，意味着每个鹅厂人都读过这篇“檄文”帖子，还有人在反复不断浏览阅读了帖子。KM论坛里人潮涌动，“五问”腾讯的大讨论还在持续。

这条激烈的“檄文”帖子下方，还有不少员工实名邀请同事参与讨论回答，被邀请的同事有Ponyma、Mark和Xidan等， 他们分别是马化腾、任宇昕和奚丹。

大讨论足足持续了一个月

翌日，腾讯集团总办领导、集团高级副总裁奚丹回复了“五问”腾讯这张热帖，他认为不少观点也很到位。

“我代表总办给你点个赞！”

奚丹在回复中，承认大企业病已经成为腾讯最大的挑战之一，现在确实也到了要更加正视，并且拿出决心和行动的时候了。

总办领导一句表态激起万重浪。有企业文化部门员工干脆实名提问，一条《腾讯大企业病“五问”火了，谈谈你最想公司改变的一个痛点？》帖子成为了自我批评的新阵地。

谈痛点中，最高赞的质询来自于一位技术副总监。

他痛陈鹅厂没有CTO，自从2014年腾讯创始人之一张志东卸任后，腾讯CTO的位置空置至今。

长期以来，腾讯奉之金科玉律的“赛马机制”孵化出竞争成果的同时，也衍生出“重复造轮子”的诟病。

腾讯前CTO张志东

腾讯人也不是非要一个CTO，就连呼声最高的创始人之一、前CTO张志东在也公开回应称，自己不会重回公司业务一线，相信腾讯会孵化出新生力量。

症结背后是公司发展到了一个巨大体量，公司部门墙成了阻止公司前进的巨大阻力，万众期待CTO能够打破这种困局——“技术缺乏长期规划布局，我们技术配得起腾讯吗”、“对基础研究领域投入严重不足，追求中短期利息”、“找个CTO，让技术成为社会进步的阶梯”。

实际上腾讯没有CTO已经很多年，从来没有像今天这样备受诟病。有内部员工坦陈： 所谓没有CTO的吐槽，背后是腾讯人对改变现状的渴望。

大讨论足足持续了一个月。

一个月之前，“五问”腾讯缘起，不断挑战着几万腾讯人的神经，腾讯人试图在KM上问个清楚，究竟我们哪里做错了？

凭借着匿名的承诺，腾讯员工甚至抛出了《十省腾讯，公司到底怎么了，到底该关注什么问题》，直斥腾讯方向不明、管理地盘化、唯老板需求、干部甄选黑盒化......

在老腾讯人印象中，一向“佛系”的腾讯员工很少会情绪激烈，这次讨论的各种语气——太不客气！

不过，总办领导再也没有出面回应。

凌晨6点14分“对自己动刀”

事实上，在这场大讨论之前，腾讯总办早已预料到这种局面。据一位腾讯不具名的亲历受访者描述，他在大讨论期间，收到公司内部一个特殊调研团队邀请，参加了一场腾讯集团滨海总部35楼的小型闭门讨论，窗帘和门紧密，参与人员囊括了腾讯老员工、腾讯新员工，甚至有从其他同行处跳槽过来的资深“新鹅”。
“你可以谈任何关于腾讯的看法，尤其欢迎批评，你的领导和同事不会知道”，调研团队保证。
这位受访者回忆，现场每个人针对自己和公司的“批评”近乎开骂，议题集中在KM大讨论议题的具像化——大家都举了自己的例子，试图证明这些“批评”与“自我批评”真实存在。 “批评意见”会被如实记录，直呈总办。实际上早在2017年年底，腾讯核心管理团队便着手调研，试图“诊断”自身，并且意图进行腾讯公司史上的第三次组织架构变革。
“对自己动刀子”。 KM大讨论一个月后，2018年9月30日，马化腾在凌晨6点14分内部发出全员公开信，正式宣布组织架构升级，史称“930变革”。
之所以踩点凌晨6点14分，因为那是当天深圳气象台公布的日出时刻，意味深长。 930后腾讯的业务架构

组织架构升级与变革带来的变动，甚至“硝烟”，但是“930变革真的”凑效了吗？

腾讯KM上有迹可循，鹅厂人在结束了“五问”、“十问”甚至“天问”腾讯之后，提问陆续投射了新的变化，时间进入2019年，关于35岁焦虑、人到中年的讨论逐渐浮现。

《把老员工等同于没有创造力的贬值人，是否是一种舆论陷阱》、《35岁面临职场危机，应该怎么度过》、《鹅厂针对年轻员工发起的英才计划实施以来，进展如何》......

在组织架构变革官宣后的一年多时间里，腾讯KM上关于年龄焦虑和个人出路的讨论突然暴增。有一位匿名同事实在忍不住直问： “看了公司各种35岁的帖子，是不是之前所谓的年轻化，反映了公司产业升级失败的一个缩影？”

腾讯第三次组织架构升级协调整合全新事业群、全面拉开产业互联网战略背后，所带来的在人事组织上的“升级”，就是强化“干部能上能下”。

内部关于35岁焦虑、中年危机的帖子，某种程度上来源于此，属于组织架构变革的投射。

当有权者被打破了“铁饭碗”

“930变革”近一年后，腾讯内部正式发布《腾讯管理干部能上能下管理办法》，这意味着之前在KM大讨论中备受批评的“权力板结严重”，深深刺痛着腾讯上下几万人。

“干部能上能下”并非腾讯独有，亦并非新提法。事实上，我们从较权威信源得知，腾讯公司从2012年8月便正式推动了这一政策。

930战略升级和组织变革成为这一政策原则的“催化剂”。

自2018年9月30日开始，腾讯花一年时间，完成了10%的中高级管理骨干的“能下”，通过制度设计，这个“能下”比例每年被划定为5%，意思就是每年强制淘汰5%的管理层。

蓝字计划（微信公众号：NPO2020）观察到，腾讯知名员工网友Tegic（微信公众号：tegic0700）便公开描述了自己身边好几个朋友面临“被降职”。

Tegic在聊天记录中安慰“被能下”的中高干称： “把你们这些占着茅坑不拉屎的老家伙干掉，感觉我司又有希望了”。

有一组数据可以提供支撑：腾讯公司自930战略升级和组织变革后，推动青年英才晋升绿色通道，新晋升了35岁以下的年轻中干若干人，占当年所有新晋升中干的比例超过40%；新晋升30岁以下年轻总监首现；新晋升的组长中28岁以下年轻组长总量增加近2倍。

“能下”之后，出现“能上”，这也许才是腾讯人开始内部讨论“老龄化”的真正原因。

与其称KM上腾讯员工对“中年危机”的讨论是“年轻化焦虑”，不如说这是腾讯诊断“组织初老症”和“大企业病”的一道猛药。

员工们在内部KM的吐槽焦点，随着腾讯自身的改变而发生这潜移默化的变化，很少人会穿透一张张内部帖子， 发现鹅厂正在起变化。

腾讯活水计划介绍漫画《小T转岗记》

腾讯的To B战略进度也以同样的姿势，开始深入每一个鹅厂人的思维。

随着“腾讯究竟有没有To B的基因”讨论开始，腾讯人开始越来越多地思考，究竟能不能从原来的消费互联网业务领域的成功，同样实现在产业互联网。

KM的帖子充满了腾讯人的To B焦虑，其中一张热帖回收了一大堆“930变革”后，一线业务的真实故事，读起来“触目惊心”。

比如之前从来不用驻场陪同客户的程序员，因为开始服务甲方，竟然需要驻扎在客户公司度过618、双11甚至春节这种节日，“最后还被客户陪着过了自己的生日”；

有的售后员工因为经常帮客户解决问题，猝不及防收到了不得拒绝的答谢红包，拿着钱不知所措；又比如不少曾经在鹅厂内部备受宠爱的产品团队，开始产生被要求给客户道歉的恐惧所支配，惶惶不可终日......

这些都是产品为王、生于消费互联网的腾讯人转战产业互联网的阵痛。

一个关于英文名的2B大问题

出人意料的是，关于鹅厂人叫什么花名，在KM上就上升为一个事关企业发展的战略议题。一直以来，每个入职腾讯公司的员工，都会起一个属于自己的英文名，即使连马化腾（Pony）、张志东（Tony）、陈一丹（Charls）这些公司创始人也不例外。
这种英文名文化，和阿里巴巴每个人都起武侠花名类似。外界解读认为，这种起名文化符合互联网公司的企业性格——平等民主处事、减少层级隔阂、便于跨部门合作。
随着战略升级和组织变革的推进，是否直呼英文名的企业文化备受挑战，工作中越来越多出现称呼“X总”和“老板”， 被一些员工认为是对腾讯价值观的变相稀释。 KM上开始陆续出现质疑：“关于同事间的称呼，X姐、X哥在渐成主流吗？”、“公司上下级称呼X老板和X总越来越多，这和五六年前以英文名互称变化挺大的！”、“拒绝惯性叫‘总’，人人都敢PK！”、“腾讯越来越社会了吗？上下都是叫老板和总了？”...... 一种全新的声音出现了。 “言必称总和老板，是我们2B业务的需要和顺应潮流的体现”，不少腾讯员工表示某种程度能能够理解称呼习惯的变化，有一线的腾讯云销售就解释称，他们去跑政府客户、国企客户的时候，对方特别在乎你的称谓是什么：——是X总？还是小X？
这是个问题，还是个“2B（To B）”问题。
类似转战产业互联网后，业务领域变化带来的冲突故事，被越来越多地出现在内部KM上。某个大客户的云服务出现问题，三家云服务巨头同时维修，风格各异：A家嘘寒问暖服务到位、H家人海战术激情在线，而腾讯云团队只派了几个工程师到现场，尽管后端整个团队密锣紧鼓解决问题。

中国最大的煤矿企业，使用企业微信进行管理

尽管腾讯云最终能够为客户解决问题，但是却得不到客户的理解和认同，因为只派几个人到现场，场面看起来太不重视了！腾讯团队觉得很委屈，心想我们目标是为客户解决问题，没必要的排面只是形式主义。
但这就是“2B（To B）”的现状，如何全方位地服务客户，包括照顾客户的心态，也许都属于产业客户服务的关键，这与腾讯人之前埋头苦干，产品为王的经验大相径庭。这些故事和冲突背后，都凝聚总结了腾讯在“930变革”之后的阵痛和改变，化作一张张的帖子，浮现在内部KM上。
表面上弥漫这吐槽、不解甚至愤怒，但实际上都沉淀成了腾讯转型阵痛期的养料—— 自我批评，自我反省，自我进化。 不过，精明的腾讯员工们最近发现了一个小秘密——和总办领导一样的英文名，又开放可以注册了，比如说你也可以把英文名起作Pony，和这家公司董事长马化腾一样。
有人发现了这个秘密，把这个好消息又发在了KM上。
如今，腾讯共有4个员工选择拥有了Pony这个英文名，除了马化腾之外，其余都是普通一线员工。

从不“少数服从多数“的内部论坛

2019年，改革过去一年了，KM讨论也进入深水区。赛马机制和部门墙，成为这个阶段的重要焦点。在过去，腾讯的技术布局更多基于各大事业群的业务需求进行规划，这样的安排不乏合理之处： 让听得见炮火声的人来决策，更能适应快速变化的业务需求，并进一步降低跨部门的沟通损耗。 三十年河东，三十年河西。彼时所推崇的模式，是通过大中台整合所有数据，再利用算法提取相关信息，从而对内提供数据基础建设和统一的数据服务，对外提供服务商家的数据产品。
KM上腾讯人对其他竞争者的关注，开始多于过往。抖音在短短3年时间成长为6亿用户规模的超级App，就被归功于字节跳动强大的中台与算法。
在2018年，所有的赞誉都留给了阿里、字节引领的数据中台模式，而腾讯的散养式研发，在内部更多是收到了“重复造轮子”、“重业务轻技术”类似的抱怨。相比起”930变革“引发外部对腾讯战略布局的大讨论，在拥有数万名程序员的内部，人们更关心的反而是新近成立的「技术委员会」能够给内部带来什么改变。新闻一出，马上有员工率先发问：“技术委员会能否真正做到以技术人员为主？”
他的观点反映了不少程序员的心声： 技术就是技术，并不应该屈从于业务。 技术委员会可以了解各事业群的业务需求，但各事业群也需要站在公司整体的角度考虑，遵从技术委员会的决定。
按照规划，腾讯技术委员会由卢山和汤道生两名腾讯总办成员牵头，各个事业群的技术负责人悉数进入技术委员会的决策圈。技术委员会下设「开源协同」和「自研上云」项目组，推动内部代码的开源和协同，以及业务在云上全面整合。
腾讯希望通过技术委员会对赛马机制进行修正，减少无效的重复开发，整合沉淀内部的技术。两位总办成员中，卢山执掌的TEG（技术工程事业群）是腾讯内部的技术支撑部门，堪称腾讯的“神盾局”，他多次在内部表态全力支持汤道生和CSIG（腾讯云与智慧产业事业群）。和外界恨不得一个星期就看到腾讯新面貌不同，技术委员会的宣传力度，与人们期待的并不匹配。
据悉，决策层希望低调推动这项内功的修炼，减少对外公关，并要求各事业群技术负责人尽快摸清全公司现存的“技术债”，同时展开了建设技术图谱、专属讨论区、代码社区等基础工作，HR甚至成立了专门的工作组，为支持开源的部门和个人进行考核和晋升倾斜。员工想象中要霹雳手段拆掉部门墙、统合所有数据的场面没有出现，以至于在变革一周年的内部讨论中，有人在KM讨论道“开源协同暗流涌动，研发效率问题重视起来了”，但也有人感觉只是“换了一下事业群的名字”、“没有感受到中台的作用”，甚至吐槽“起了无数中台”，而要求打通全腾讯的算法和数据的大有人在。但这一次，汤道生所代表的总办在内外部表态都很坚决： 腾讯不做全公司范围的数据中台。 马化腾认为不做中台有利于用户隐私保护

这些都不难理解，基层员工站在自身工作的视角，会在KM上呼吁最大限度开源、协同、共享，最大限度提高效率；但决策层又必须有另外一重考量：这一步迈出去了，除了对业务和员工，还将对公司、社会长远有什么后果，这并非多数基层员工所能观察得到的。 “KM从来都不是少数服从多数，而是民主集中制。”有腾讯员工概括道。

科技向善成为了键盘上的焦虑

民主集中制，也体现在“科技向善”概念的首次公开——KM上大家集中一脸懵逼，啥？

“科技向善”这个观点，最先由张志东在2018年一场演讲中提出。

这位身家千亿却开着10万元大众宝来上班的IT男，亲手搭建了QQ的架构设计并能够沿用至今。凭借务实低调的作风，他在拥有数万名程序员的腾讯被尊为“大师兄”。

当年正是张志东有感于诸多大企业随着人员膨胀后导致文化稀释、沟通断层等问题，下令创办KM，并规定除非人命案件，内部任何人都无权要求KM部门提供匿名发言人的身份信息。

在张志东看来，KM是弥合大公司内部鸿沟的理想工具，尽管已经退休，他仍保留着终身荣誉顾问、腾讯学院荣誉院长的身份，每个月会去看两次乐问，十几年来累计回答了两百多个问题。

时间来到2019年，马化腾在朋友圈转发了一条腾讯优图借助AI找到失踪儿童的新闻，配语是：科技向善，我们新的使命和愿景。

同年11月，腾讯在21周年司庆上正式宣布将“科技向善”加入到公司使命愿景。

在腾讯帮助下，科研团队进行的沙漠化治理项目

短短一年时间，这四个字从“倡议”迅速升级为“使命”，在内外部都掀起了一场关于什么是“科技向善”的大讨论：

“怎么做才是科技向善？”

有人从实际业务出发，希望公司的软件不要效仿同行硬塞全家桶、续费不要做默认、消灭暗扣的扣费点......

也有人认为公司应该不仅仅是对产品细节小修小补，而是关注AI算法被滥用、用户隐私遭到侵犯、科技适老化建设严重滞后等社会性问题。

但也有员工担忧，这个充满理想主义色彩的使命愿景，会给腾讯带来无妄之灾：

“腾讯的「科技向善」和谷歌的「不作恶」差别很大......稍有不慎，你的行为就会被诟病不够“向善”，给业务捆上了道德的枷锁。”

果不其然，这个四个字很快成为内部灵魂拷问的必备词：

微信接槟榔企业广告，是否科技向善？

我厂新剧的设定，符合“科技向善”价值观？

科技向善，某些部门真的有在做吗？

广告多到影响用户使用，说好的科技向善呢?

每当问题出现，相关业务的总经理、总监免不了在内部公开道歉并承诺整改。

渐渐地，“科技向善”成为悬在所有腾讯员工上头的达摩克利斯之剑，上到决策层、下到基层员工，“我死后管它洪水滔天”的做法不再可取，因为一旦被外部曝光和内网责难，丢的不仅是个人，还是整个部门的脸面，甚至还将被全公司通报批评、接受处分。

腾讯素有偶像包袱。

外界流传“微信监听用户聊天来匹配广告”的谣言屡禁不绝，多次辟谣无果之后，张小龙竟下定决心推出自有输入法， 防止第三方输入法将用户信息收集后泄露和售卖。

但对于许多腾讯员工而言，内部和外部看到的像是两个截然不同的腾讯：他们在朋友圈、公众号时常可以看到身边同事转发的很多公司的正能量新闻，而在微博、知乎、抖音上，人们对腾讯的印象仍然停留在抄袭竞品、未成年人游戏等陈年老调上。

许多员工在KM中表达了自己的困惑：为什么首倡科技向善的腾讯，在外界口碑如此糟糕？

这样的烦恼，并非腾讯员工所独有，在全球范围内，包括Google、Facebook、苹果、亚马逊等科技公司，以及国内的阿里巴巴，都面临着如何与社会共处的难题，人们对于科技巨头的不安和不信任，和百年前面对石油、钢铁托拉斯如出一辙，在国与国之间蔓延开来。

一个首次被提问的热门词汇

2020年春末，腾讯的股价从2018年的谷底翻了一番，曾经的“腾讯没有梦想”和“背水一战”，都成了茶余饭后的冷笑话。

2B（To B）的质疑逐渐消散，新的矛盾暗流汹涌。

这也正是刘炽平所挥之不去的疑问：腾讯公司的战略蓝图当中，“仿佛少了一块”。

那个春天刚刚过去的全民战疫，给他带来了新的启发：在人心惶惶的2020年1月27日，腾讯受命紧急开发健康码，在内部贴出一份技术志愿者招募令，迅速获得数千员工响应。

整个疫情期间，腾讯有12000多名员工直接参与到了各式各样的战疫中来。

在此之前，拥有6万名员工的腾讯内部，要想推动如此大规模的线上协作，往往免不了合议、争执、妥协甚至流产等流程。但在公共利益面前，那道曾经备受诟病的“部门墙”居然神奇地消失了，KM上的提问，不断在互相寻找协作。

“微信生态可以为疫情做些什么？”

“腾讯公益能在疫情上尽什么力？”

“游戏部门是否应该推出传染病教育游戏来践行科技向善？”

“个人以及公司能为疫情做些什么？”

一方面是“战时状态”激发出的创新能力，健康码、腾讯会议、腾讯课堂都在疫情期间大放异彩，不仅在外部缓解了腾讯的口碑压力，也在内部KM中得到了充分的肯定；

一方面是社会对科技平台的期待和监管在层层加码，过去企业按比例投入一定利润参与公益的路径已经过时。

检查微信健康码，已经成为社会常态

在马化腾看来，如果一个企业的发展和所作出的贡献之间，没有合理的比例，是不可能往上生长的。

随着KM上关于社会价值的讨论越来越多，2020年秋天，「社会价值」开始成为重要的战略议题，列入到腾讯决策层的讨论中来。

2021年4月19日，腾讯再次启动战略升级，提出“可持续社会价值创新”战略，并宣布将为此首期投入500亿元设立“可持续社会价值事业部”（SSV），对包括基础科学、教育创新、乡村振兴、碳中和、FEW（食物、能源与水）、公众应急、养老科技和公益数字化等领域展开探索。

如果说“科技向善”是一句偏理想主义的口号，新战略、新部门的成立，昭示着腾讯要真刀真枪干一场了。

KM上一堆关于“如何向善”的提问，已经给出答案。

SSV新部门负责人陈菊红的企业微信和KM很快就被毛遂自荐的员工轰炸，“凌晨一点了，都有同事小窗问我：你们那儿还要不要人？”

腾讯全员很快收到了内部开放活水（注：活水是腾讯内部重新应聘换岗的特设制度）SSV的邮件邀请：产品经理、运营经理、项目经理、后台开发工程师、数字化解决方案架构师......

键盘侠的自省就是0前那个1

“科技向善”听起来非常浪漫主义。

截至今天，腾讯人在短短两年时间里，在KM上提出了38322条问题和看法。腾讯人对“向善”的疑问和思考，甚至超越了对饭堂菜式、升职加薪的花式重视。

这也包括腾讯总办领导、集团首席探索官网大为。网大为英文名叫做David Wallerstein，中文名的意思据说“网络上大有可为”。

2021年6月第一天，网大为在KM上问大家： “为什么要敢于坚持与众不同”？

网大为回想起2000年，他刚来到腾讯的时候，这家公司只有45个人，当时马化腾赶在互联网世纪泡沫崩盘前拿到了一笔救命钱，当时所有人的目标都很简单：让腾讯活下去。

时过境迁，20多年后的腾讯已经成为了人们眼中“稳定”的大公司，而网大为也体察到了一些变化：

10年前他进去电梯，很多员工会笑着跟他打招呼聊天，但从五六年前开始，公司电梯里没有人跟他说话了。

他问身边一位同事：“你在腾讯是做什么的？”

对方感觉很诧异：“你是什么意思？”

这件外人眼里，问一位同事从事什么岗位，也许再正常不过的事情，但如今却变得陌生起来。

这个变化对网大为触动很大，他在六一儿童节这天，明白了腾讯公司已经无可避免地长大：人们各司其职，分工细化，却也无可避免地遭遇沟通障碍和文化稀释的问题。

9万多人的腾讯，工作奋斗在全国乃至全球各地，加之在线化办公的普及， 如果没有共同驱动的核心价值，它将会沦为一台层级分明、没有人味的巨型商业机器。

KM上近十万腾讯人，这么多年来的撕逼讨论，艰难地维持、证明自己——我还是那么腾讯。

在刚刚结束的腾讯志愿者大会，这位首席探索官（CXO）在访谈中提到了他对企业文化的关注。

在他看来，把科技向善作为使命愿景，关心人、关心地球，在这个基础上提供产品和体验，才能吸引到更多志同道合的人才，才是腾讯接下来的生存之道。

钱没有了可以再赚，业务瓶颈可以突破，利润少了可以创造，但如果腾讯人不再像腾讯人，失去了自我质疑、自我反思和自我革命的企业文化，则失去了无数个“0”前面的那个“1”。

凌晨1点，马化腾给KM上网大为这篇访谈来了个一键三连：点赞、收藏和评论。

腾讯云联合毕马威发布《区域性银行数字化转型白皮书》

Sat, 12 Jun 2021 08:11:54 CST

　　中证网讯（记者齐金钊）6月10日，腾讯云和毕马威联合18家银行发布《区域性银行数字化转型白皮书》。该白皮书基于对18家区域性银行的深度访谈以及46家区域性银行的深度调研，揭示了区域性银行数字化转型的挑战、机遇和破局之道。

　　白皮书提出，“深耕本地、错位竞争、巧借外力”是区域性银行数字化转型的三大突破口，“新连接、新智能、新基建、新敏捷”四大新数字化能力体系的构建则是区域性银行数字化转型落地的基础。同时，在实施路径上，白皮书建议区域性银行制定数字化能力及价值评估体系，做好投入和收益评估，同时可以采取试点模式，引入成熟方案，打造短期速赢标杆，实现逐步突破。

　　腾讯云副总裁、腾讯云金融行业负责人郭仁声表示，不少区域性银行选择把数字化转型作为提升竞争力的关键手段，但不同银行数字化转型的背景、资源、能力并不完全相同，腾讯云联合毕马威发布白皮书，不试图下定义，而是通过同业实践，为银行家们提供策略参考。

　　毕马威中国副主席、毕马威腾讯全球客户业务主管合伙人黄文楷表示，区域性银行的数字化不仅要体现在技术研发、系统建设等“硬实力”上，同时对组织、文化与人才等“软实力”的要求也很高。毕马威联合腾讯云，希望助力区域性银行在危机中育先机、于变局中开新局，通过数字化转型和科技创新在市场中建立竞争优势。

　　据介绍，在腾讯云的支持下，已有多家区域性银行取得了数字化转型的阶段性成果。广州农商银行与腾讯云合作打造了全栈分布式金融云平台，全方位覆盖了基础设施建设、技术平台建设、业务平台建设、体系规范建设、架构规划、业务运营合作等领域。上海农商银行联合腾讯云构建业务、数据双中台，实现了业务能力共享和数据信息资产化。同时基于智慧中台整合各项AI组件和模型，打造了上海农商银行“智慧大脑”。江苏银行基于腾讯云孵化出的联邦学习应用服务打破数据孤岛，在保护隐私的同时，有效释放出了大数据生产力；龙江银行引入腾讯数据服务及伽利略解决方案，通过获客、业务线上化实现了零售业务的增长和突破。长沙银行以“弗兰社+呼啦+开放银行”平台为载体，实现了客户“吃喝玩乐美”全覆盖，5个月内新增用户20万，触达超过15万人次，带来存款、理财等金融业务超1亿元，实现了湖湘本土知名消费品牌客群的共享导流和生态共建。

　　腾讯云介绍，目前公司已累计服务了一大批金融领域客户，包括150多家银行、数十家券商与保险机构，以及超过90%持牌消金和众多泛金融企业。其中，腾讯云分布式数据库TDSQL已服务近半国内TOP 20银行，TOP10银行中服务比例更是高达60％。腾讯云还与中国银行、建设银行、中国人保、中国银联、深证通、中银国际证券等头部金融机构合作构建了金融云平台。企业微信已服务17家国有大型银行和全国性股份制银行总行，覆盖比例超过90%。

腾讯云Elasticsearch集群多可用区容灾实现原理及最佳实践

Fri, 07 May 2021 04:06:06 CST

引言

目前腾讯云 ES 集群可以支持双可用区及三可用区的集群部署，且支持单可用区平滑升级到多可用区集群。当一个可用区出现故障时，剩余可用区依然能够保障集群的稳定性、服务的可用性和数据的完整性。

数据节点

当客户选择了跨多可用区的集群架构部署时，集群的数据节点必须是多可用区的倍数，如客户选择的是三可用区部署，则数据节点个数应为 3，6，9，12 等，以此类推。

如上图 1 所示，我们在上海地域选择了三可用区集群的部署，数据节点数量选择 6 个。ES 会自动将 6 个数据节点均衡得分布在三个可用区中，并对每个节点标记上可用区属性，从而可以通过可用区感知功能将索引的分片自动分布在多可用区中，集群中节点的具体分布情况如图 2 所示。

从图 2 中我们可以看到，腾讯云 ES 提供了 VPC 内的负载均衡功能，客户可以直接通过 VIP 连接集群，由于 VIP 下绑定了集群内部的所有数据节点，因此客户所有的读写请求会均衡的分布到各个数据节点上。

另外该 VIP 还自带健康检查功能，如一个周期内多次检测到某节点未响应，健康检查功能则会暂时从该 VIP 的路由列表中摘除该异常节点，直到节点恢复正常。这样就保障了当一个节点宕机或者某一个可用区不可用的情况下，客户端依然能够无感知的请求集群。

专用主节点

为了保障集群的稳定性和高可用性，当选择多可用区集群架构部署时，需强制设置三个专用主节点。其中专用主节点的分布机制如下：

当选择三可用区部署时，会在每个可用区部署一个专用主节点，从而保障任何一个可用区不可用时，依然能够选出 Master 节点；当选择双可用区部署时，为了避免出现一个可用区上分布两个专用主节点且出现“该可用区不可用”导致选不出 Master 节点的情况，腾讯云 ES 会选择一个隐藏可用区用来专门部署专用主节点，如下图 3 所示。

索引副本分片

为了保障在一个可用区不可用的情况下，依然能够保证数据的完整性和服务的可用性，索引分片至少设置 1 副本。如果选择三可用区部署，当两个可用区不可用时，希望剩下的可用区依然能够完整提供服务，则索引的副本个数至少为 2 个。

ES多可用区架构部署实现机制

腾讯云 ES 多可用区集群部署依赖于 ES 提供的节点属性感知 awareness [1] 功能。通过对每个节点进行属性标记，即对节点进行可用区的属性标记:"node.attr.zone_id:shanghai-3"。

该属性配置在 elasticsearch.yml 文件中(也可以选择在启动节点时进行参数指定："./bin/elasticsearch -Enode.attr.zone_id=shanghai-3")，设置完节点属性后，腾讯云 ES 集群通过设置如下参数："cluster.routing.allocation.awareness.attributes=zone_id" 来让集群在分片分配中使用节点属性执行分配策略。

这样 ES 就可以通过可用区 zone_id 属性将节点进行分类。且将索引的主副本分片分布到属性 zone_id 不同的节点上。

例如，我们创建了一个具有 4 个数据节点的双可用区的集群，分别部署在上海 3 区和上海 4 区。那么上海 3 区的节点属性为: "node.attr.zone_id:shanghai-3"，上海 4 区的节点属性为: "node.attr.zone_id:shanghai-4"。

当我们创建一个索引，该索引有 5 个主分片和 1 个副本分片，那么所有的主分片和对应的副本分片都会均衡的分布在上海 3 区和 4 区上，而不会出现主分片和副本分片同时分布在上海 3 区或者上海 4 区的情况。

需要注意的是：这时候如果有一个可用区挂掉，如上海 3 区整体不可用，ES 会将上海 3 区的主副本分片在上海 4 区进行重建。即这时候会出现主副本分片同时分配在同一个可用区的情况。

为了防止某一个可用区不可用，导致另一个可用区磁盘容量被重建的分片大量耗尽的情况，腾讯云 ES 启用了分片强制感知 (force awareness) 的功能。

腾讯云 ES 通知设置如下参数：cluster.routing.allocation.awareness.force.zone_id.values=shanghai-3,shanghai-4，从而保证了在一个可用区不可用时，不会使得剩余的可用区磁盘资源不足的情况。

单可用区平滑升级多可用区

前文图 1 演示了在腾讯云 ES 控制台购买多可用区集群的操作步骤。对于存量的单可用区集群，腾讯云 ES 同样支持平滑升级到多可用区的部署架构。具体操作如下图 4 所示：

这里需要注意以下几点：

当选择了升级到多可用区时，只能设置新的可用区信息，不可更改节点配置和磁盘容量；当升级到双可用区时，数据节点数量自动翻倍；当升级到三可用区时，数据节点数量自动乘三倍；当从双可用区升级到三可用区时，数据节点数量自动乘 1.5 倍；如果原集群未设置专用主节点，则会强制选择设置 3 个专用主节点；如果原集群设置了专用主节点，则节点数量不变，腾讯云 ES 会自动完成专用主节点在各可用区之间的调度和分布。

单可用区升级到多可用区的变配流程最大的难点和挑战在于专用主节点的协调上。下面重点介绍腾讯云 ES 在处理可用区升级方案中专用主节点的实现机制：

为了下图说明方便，我们先对各类型节点使用不同颜色进行标记：

普通节点：包含 master、data、ingest 等所有属性，节点上存储索引数据，使用蓝色标记。

专用主节点：只包含 master 属性，在集群中属于专用主节点，不存储索引数据，只负责管理集群和存储集群的元数据信息，使用粉红色标记。

数据节点：只包含 data、ingest 属性，一般用于具有专用主节点的场景，该节点上存储索引数据，通常也被称为专有数据节点，使用绿色标记。

单可用区升级到多可用区场景分析：

（1）原单可用区集群没有专用主节点：

如果原单可用区集群没有设置专用主节点，这种情况下无论是升级到双可用区还是三可用区都是比较简单的。

升级变配流程如上图 5 所示：

在新增的可用区中申请创建并加入普通节点以及在每个可用区中各加入一个专用主节点（如果是升级到双可用区，则会在隐藏可用区加入一个专用主节点）；修改各可用区中普通节点的属性为专有数据节点，即上图中将蓝色变更为绿色。

在流程的第 2 步修改节点属性时，每重启一个节点，min_master_node 都会重新计算并设定，避免在中间状态发生脑裂。

（2）原单可用区集群已设置专用主节点：

如果原单可用区集群中已经设置了 3 个专用主节点，那么按照最终的状态来看，应该是每个可用区都会均衡分布一个专用主节点。

自然想到的流程是先在新增的可用区中各加入一个专用主节点，然后再将原可用区中的多余两个专用主节点下线即可。如下图 6 所示：

具体流程步骤如下：

在新增的可用区中加入数据节点及一个专用主节点（如果是升级到双可用区，则只需要在隐藏可用区申请加入一个专用主节点即可）；将原单可用区中多出的两个专用主节点下线。

但是这种升级变配流程存在一个隐藏的集群不可用风险。如图 7 所示：

从图 6 的第一个流程上我们再结合图 7 可以看到，如果在中间状态原单可用区突然发生不可用，那便会出现剩余的可用区中只剩下 2 个专用主节点，这时候从 5 个专主变成了 2 个专用主节点，便会出现选不出 Master 节点的情况，从而使得集群整体不可用，违背了跨可用区的容灾初衷。

为了规避上面分析的这种异常风险，我们对图 6 的第 1 个流程的中间状态做了优化，如下图 8 所示：

具体流程如下：

在新增的可用区中加入数据节点及两个专用主节点（如果是升级到双可用区，则只需要在隐藏可用区申请加入两个专用主节点即可）；将原单可用区中多出的两个专用主节点和新增的可用区中多出的一个专用主节点下线。

这样便可保证即使在流程一的中间状态下任何一个可用区不可用，依然不影响剩余专用主节点选出 Master 节点。从而保障了集群的高可用性。

结语

本篇文章我们详细介绍和分析了腾讯云 ES 集群多可用区容灾的实现原理和操作实践。并重点介绍了单可用区集群升级到多可用区的几种场景及具体流程细节，希望能够帮助到腾讯云 ES 的客户朋友们。

头图：Unsplash

作者：吴容

原文：https://mp.weixin.qq.com/s/7VzmoK4ZsVfnJflEs_B9tA

原文：腾讯云Elasticsearch集群多可用区容灾实现原理及最佳实践

来源：云加社区 - 微信公众号 [ID：QcloudCommunity]

转载：著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

腾讯唯一时序数据库：CTSDB 解密

Sat, 03 Apr 2021 17:51:20 CST

编辑推荐:

本文将对时序数据库的基本概念、应用场景及腾讯时序数据库CTSDB做简要介绍，希望对您有所帮助。
本文来自于公众号腾讯技术工程，由火龙果软件刘琛编辑推荐

什么是时序数据库

1. 时序数据

1.1 什么是时序数据？

在引入时序数据库之前，先要了解“时序数据”的概念：按照时间顺序记录系统、设备状态变化的数据被称为时序数据（TimeSeries Data）。它普遍存在于IT基础设施、运维监控系统和物联网中。

时序数据从时间维度上将孤立的观测值连成一条线，从而揭示软硬件系统的状态变化。孤立的观测值不能叫时序数据，但如果把大量的观测值用时间线串起来，我们就可以研究和分析观测值的趋势及规律。其意义体现在两方面：

（1）从时间轴往后看，时序数据可做成报表，观测数据变化规律、捕获异常。这里举两个例子：

下图为共享单车在旧金山某热门区域的每小时车辆的借还数量。通过分析该区域车辆数目的历史数据，单车公司可得知热点借车时间段是否需要车辆补给。

下图为某互联网服务的出入流量历史记录。从图中可以明显看到入流量（蓝色线）在某时间段有毛刺，服务提供商可基于此段时间排查服务有无异常。也可以进一步基于流量监控做告警，使运维人员能够及时处理线上问题。

（2）从时间轴向前看，时序数据可以建立数学模型、做统计分析，预测事物发展趋势。

举例，下图为联合国在2015年分析过往人口增长趋势后，发布的人口数字及预测报告。从图中可以看出未来非洲人口将持续增长，这是任何一个跨国企业都不该忽略的市场，也预示着当地政府面临重大挑战。

1.2 时序数据的数学模型

上面介绍了时序数据的基本概念，也说明了分析时序数据的意义。那么时序数据该怎样存储呢？数据的存储要考虑其数学模型和特点，时序数据当然也不例外。所以这里先介绍时序数据的数学模型和特点。

下图为一段时序数据，记录了一段时间内的某个集群里各机器上各端口的出入流量，每半小时记录一个观测值。这里以图中的数据为例，介绍下时序数据的数学模型（不同的时序数据库中，基本概念的称谓有可能不同，这里以腾讯CTSDB为准）：

metric：度量的数据集，类似于关系型数据库中的 table；

point：一个数据点，类似于关系型数据库中的 row；

timestamp：时间戳，表征采集到数据的时间点；

tag：维度列，代表数据的归属、属性，表明是哪个设备/模块产生的，一般不随着时间变化，供查询使用；

field：指标列，代表数据的测量值，随时间平滑波动，不需要查询。

如上图所示，这组数据的metric为Network，每个point由以下部分组成：

timestamp：时间戳

两个tag：host、port，代表每个point归属于哪台机器的哪个端口

两个field：bytes_in、bytes_out，代表piont的测量值，半小时内出入流量的平均值

同一个host、同一个port，每半小时产生一个point，随着时间的增长，field（bytes_in、bytes_out）不断变化。

如host：host4，port：51514，timestamp从02:00 到02:30的时间段内，bytes_in 从 37.937上涨到38.089，bytes_out从2897.26上涨到3009.86，说明这一段时间内该端口服务压力升高。

1.3 时序数据特点

数据模式：时序数据随时间增长，相同维度重复取值，指标平滑变化：这点从上面的Network表的数据变化可以看出。

写入：持续高并发写入，无更新操作：时序数据库面对的往往是百万甚至千万数量级终端设备的实时数据写入（如摩拜单车2017年全国车辆数为千万级），但数据大多表征设备状态，写入后不会更新。

查询：按不同维度对指标进行统计分析，且存在明显的冷热数据，一般只会频繁查询近期数据。

2. 时序数据库

有了时序数据后，该存储在哪里呢？首先我们看下传统的解决方案在存储时序数据时会遇到什么问题。

2.1 传统解决方案

时序数据往往是由百万级甚至千万级终端设备产生的，写入并发量比较高，属于海量数据场景。传统的时序数据解决方案主要有两种：关系型数据库（MySQL）、Hadoop生态。

・ MySQL：在海量的时序数据场景下存在如下问题

存储成本大：对于时序数据压缩不佳，需占用大量机器资源；

维护成本高：单机系统，需要在上层人工的分库分表，维护成本高；

写入吞吐低：单机写入吞吐低，很难满足时序数据千万级的写入压力；

查询性能差：适用于交易处理，海量数据的聚合分析性能差。

・ Hadoop生态（Hadoop、Spark等）

数据延迟高：离线批处理系统，数据从产生到可分析，耗时数小时、甚至天级；

查询性能差：不能很好的利用索引，依赖MapReduce任务，查询耗时一般在分钟级。

2.2 时序数据库

时序数据库是管理时序数据的专业化数据库，并针对时序数据的特点对写入、存储、查询等流程进行了优化，这些优化与时序数据的特点息息相关：

1) 存储成本：

利用时间递增、维度重复、指标平滑变化的特性，合理选择编码压缩算法，提高数据压缩比；

通过预降精度，对历史数据做聚合，节省存储空间。

2) 高并发写入：

批量写入数据，降低网络开销；

数据先写入内存，再周期性的dump为不可变的文件存储。

3) 低查询延时，高查询并发：

优化常见的查询模式，通过索引等技术降低查询延时；

通过缓存、routing等技术提高查询并发。

2.3 开源时序数据库对比

目前行业内比较流行的开源时序数据库产品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其产品特性对比如下图所示：

从上表可以看出，开源的时序数据库存在如下问题：

没有free、易用的分布式版本（OpenTSDB支持分布式部署，但依赖系统过多，维护成本高）；

聚合能力普遍较弱，而时序数据大多需要来做统计分析；

没有free的权限管理；

没有针对时间序列的多维度对比分析工具。

CTSDB

腾讯CTSDB（Cloud Time Series Database）是一种分布式、高性能、多分片、自均衡的时序数据库，针对时序数据的高并发写入、存在明显的冷热数据、IoT用户场景等做了大量优化，同时也支持各行业的日志解析和存储，其架构如下图所示。

1. CTSDB主要特点

1) 高性能：（具体性能数据将在后文给出）

支持批量写入、高并发查询；

通过集群扩展，随时线性提升系统性能；

支持sharding、routing，加速查询。

2) 高可靠：

支持多副本；

机架感知，自动错开机架分配主从副本。

3) 易使用：

丰富的数据类型，REST接口，数据写入查询均使用json格式；

原生分布式，弹性可伸缩，数据自动均衡；

4) 低成本：

支持列存储，高压缩比（0.1左右），降低存储成本；

支持数据预降精度：降低存储成本的同时，提高查询性能。

副本数可按需调整。

5) 强大的聚合能力：

max,min,avg,percentile,sum,count,group by等常用聚合；

复杂的脚本聚合（例如可对多字段间的计算结果做聚合）；

时间区间聚合、GEO聚合、嵌套聚合。

6) 亮点能力:

数据监控告警：对存入数据进行数据量、字段统计、基线对比等监控，通过微信、短信、邮件告警；

权限系统：支持用户名密码、机器白名单的权限系统；

数据时效性：支持数据过期删除；

数据导出。

2. 竞品性能对比测试

这里选用业界较为流行的InfluxDB来与CTSDB做性能对比测试。

2.1 测试场景

CTSDB与InfluxDB对比测试：CTSDB与InfluxDB均单节点部署，单节点占用24个cpu核心，128g内存，万兆网卡,，磁盘SSD RAID0。

CTSDB单节点集群与双节点集群对比测试：用以验证CTSDB的线性扩展能力。

2.2 写入性能测试

数据样例：

导入的数据由InfluxDB的官方测试工具产生，https://github.com/influxdata/influxdb-comparisons。

数据为若干host的时序数据，每个point包含10个tag（均为string类型），10个filed（均为float类型），timestamp为时间戳（一个host每10秒一个点）。

样例如下所示：

测试结果：

(1) CTSDB单节点集群与InfluxDB单机版写入性能对比

结论:CTSDB单节点写入性能最高在19w，InfluxDB在15w。

(2) CTSDB单节点集群与CTSDB双节点集群写入性能对比

结论:CTSDB单节点集群写入最高可达20w，双节点集群写入性能34w。

2.3 查询性能测试

查询样例：

这里以CTSDB的查询语句为例：

查询语句解读：

取出1个host的全量数据，然后任取一个小时做过滤后，按分钟粒度分桶（groupby，最终结果有60个桶），最后输出所有的桶，并计算桶内所有数据的usage_user字段最大值。

注意这里的查询使用了CTSDB的routing功能，用以加速查询。

查询结果样例：

测试结果：

(1) CTSDB单节点集群与InfluxDB单机版查询性能对比

结论：CTSDB查询性能整体比InfluxDB好很多，当并发数较高时（40），CTSDB查询性能比InfluxDB高出近4倍，在2w左右。在并发线程数达到50时，InfluxDB出现链接错误，拒绝查询请求；此时，CTSDB可正常查询。

(2) CTSDB单节点集群与双节点集群查询性能对比

结论：在并发数较高的情况下，双节点集群查询性能较单节点集群有了大幅度提升，呈现了查询性能线性扩展的趋势。

用户因微信封禁链接诉腾讯垄断：后者申请移送深圳法院审理

Fri, 19 Mar 2021 18:07:12 CST

一位个人用户针对腾讯的反垄断诉讼案，出现管辖权异议，而现在也有了新的进展。近日，腾讯向北京知识产权法院提出管辖权异议，申请将张正鑫起诉腾讯垄断案移送至深圳市中级人民法院（以下简称“深圳市中院”）审理。 此前，因发现无法通过微信向好友直接分享淘宝、抖音链接，微信用户张正鑫以腾讯拒绝交易为由将腾讯告上法庭。

2020年12月17日下午，律师张正鑫因工作需要，在淘宝搜索到一件图书商品。但当他想通过微信将商品链接发送给某微信好友时，却发现不能像京东或者拼多多一样将商品链接发送，而是需要复制淘宝网址信息，通过在微信输入框粘贴方式发送给好友淘宝网址。当日，他尝试将抖音链接发送给某微信好友，发现也无法像微视一样可发送短视频链接。

之后张正鑫发现，朋友通过微信发送给他的含有淘宝商品网址的信息及含抖音短视频网址的信息在微信上也无法直接打开，需要复制网址后在其他浏览器打开。

张正鑫认为，微信目前在国内的普及率较高，微信限制用户发送淘宝、抖音链接的做法违反了《中华人民共和国反垄断法》第17条禁止具有市场支配地位的经营者滥用市场支配地位，没有正当理由，拒绝与交易相对人进行交易；没有正当理由搭售商品，或者在交易时附加其他不合理的交易条件等条款。

值得一提的是，近期有媒体统计了腾讯的诉讼情况。数据显示，近三年通过管辖异议移送到深圳中院审理的案件，腾讯全部胜诉。

查看评论

腾讯云推出云开发低代码平台，帮助小白成为“开发者”

Sun, 29 Nov 2020 13:11:30 CST

IT之家11月29日消息据腾讯云微信公众号消息，腾讯云的小程序云开发已经成为国内最大的 Serverless 开发平台。同时，腾讯云从今天起，正式推出云开发低代码平台。

据腾讯方面公布数据，目前云开发注册用户数已达 56 万，较去年同期增长 1.5 倍；所服务的开发者超过 100 万；日调用次数超过 7 亿。

官方称，云开发低代码平台始于去年云开发大会最后的悬念——“重新定义开发”。腾讯云表示，通过云开发低代码平台，无需或少量代码就可以快速生成应用程序，用户可以通过拖拽相应的功能模块，创建应用，可以让越来越多的小白成为 “开发者”。

IT之家了解到，低代码开发平台 LCDP 即为 Low-Code Development Platform，意义在于可以帮助开发者提升生产效率，避免进行重复性工作，使其可以更加专注于业务逻辑、架构和算法设计。

腾讯云举例称，粤省事小程序如果现在要开发一个 “贫困认证”的功能，可以通过低代码平台直接复用政务基础组件和已有业务逻辑抽象。基于此，新功能代码行数从 2000 多行降低到 61 行，文件个数从 42 个缩减为 1 个，其交付效率大幅度提升。

此外，中国电子技术标准化研究院今日启动了《信息技术云计算云开发通用技术要求》标准编制工作，这将成为云计算领域首个云开发标准。

▲ 图源官方

腾讯信息流热点挖掘技术实践

Sun, 20 Sep 2020 00:00:00 CST

分享嘉宾：罗锦文腾讯研究员

编辑整理：Jane Zhang

出品平台：DataFunTalk

导读：当前各大资讯社交类APP都在显著的版面展示或者推荐热点相关内容，信息流应用能否快速发现热点、引导用户阅读热点，是影响用户体验的重要因素。本次分享主要介绍腾讯在热点挖掘方面的工作。基于搜索数据和自媒体文章，通过时序分析方法和内容聚类相结合的方法挖掘热点，并将热点聚类成事件和话题。用户搜索和媒体生产能够从消费和生产两个方面更加准确的度量热度，事件和话题同时能够辅助用户理解，做到热点的个性化下发，从而提升信息流热点体验。本文主要内容包括：

项目背景
相关研究方法
热点计算框架
热点挖掘
热点应用

项目背景

1. 热点应用场景

当前各大资讯类的产品都在显著的版面上展示和推荐热点相关内容，针对热点内容的推荐和呈现也变得非常多元化，比如：微博有微博热搜榜；知乎通过事件讨论的形式运营热点；百度有历史悠久的百度热搜榜；头条通过兴趣推荐的方式做热点分发频道，腾讯在对大事件做脉络运营。当前各大产品都对热点进行了大量的投入，我们基于腾讯看点丰富的视频数据，深挖用户的兴趣内容，接下来看下我们在腾讯看点的推荐频道页。

2. 热点核心推荐问题

这里对腾讯看点进行问题的分析，当前基于热点的问题存在以下几个问题：

及时性。热点挖掘需要及时监控全网站点，以科比去世为例，及时发现这一事件，并挖掘出来对应报道，才能有效帮助热点进行推荐和分发。
全面性问题。不同站点对热点的呈现不同，需要将事件榜单、话题榜单和对应的多种报道合理组织起来。比如，当一篇"南宁-工厂发生火灾"文章入库后，热点挖掘能否判断已有的挖掘结果与之对应，才能更好地进行推荐。
热度合理性问题。热度值是热度的重要特征，不同的数据源的事件热度各有不同，比如微博热搜榜当时有"钱峰又胖了"的话题，排在微博热搜榜很高的位置上，但是由于不同媒体的受众不同，在看点这边就很少有文章报道或者有用户去阅读。
热点分发的问题。热点文章和视频都有冷启动的问题，如在北京朝阳疫情定为高风险时，大部分是根据兴趣点推荐的，最近一段时间大家的用户画像中提出来"疫情"这个特征，如果基于疫情进行下发，非北京地区的用户不关注这个文章，这会降低系统的分发效率。因此要进行泛化，比如泛化到"北京疫情"这样的话题，来做用户分发，以此解决这篇文章冷启动的问题。

接下来能看到热点推荐有没有从事件推荐的角度来理解文章。有没有从事件的角度来理解文章，是提升热点推荐效果需要重点讨论的点。带着这几个问题，来看看传统的相关研究是怎么解决这个问题的。

02 相关研究方法

1. 事件抽取

任务定义：

作为信息抽取的一个重要任务，事件抽取是从一个无结构化的文本中自动抽取出来结构化的知识。以ACE任务为例，事件抽取可以分为事件检测和事件要素提取。事件检测是识别句子中的触发词trigger，这个词是描述时间的核心动作，然后根据预先定义好的框架，进行事件类型分类，因此事件分类是一个封闭集合。我是科比的粉丝，专门研究过科比不幸遇难时的相关报道，以科比去世为例，这里"凌晨四点，NBA球星科比布莱恩坠机身亡"，可以识别出trigger词为"身亡"，事件类型分类为die – 死亡事件类型，对应的事件要素是：event frame，包括：施害者、受害者、事件、地点等。通过事件提取的方式，能提到时间是"凌晨四点"，受害者是"科比·布莱恩"，把受害者和时间对应起来。这就是一个比较完整的事件抽取过程。

问题点：

可以看到事件抽取任务，是针对原子事件，通常是不可再分的，如通常提及的"新冠疫情爆发"，"南方洪水成灾"，这是有很多子事件的，不能通过事件抽取挖掘出来，同时事件框架要提前定义好，但是事件类型有限，难以覆盖新涌现出来的事件，因此只将事件抽取作为一个重要的特征抽取工具。

2. 话题检测与追踪 ( TDT )

接下来的任务和热点挖掘更相关，就是话题检测与追踪中的TDT任务，这个任务有20多年的历史了，定义的是处理新闻报道的系统。输入可以是固定的文章或者流式数据，结果是以聚类的方式将文档组织起来的话题。

话题检测：检测和组织系统中未预先设定的话题，也就是新话题的发现。

事件追踪：新到达系统的报道是否是已知话题的后续报道，也就是把新到达的文章和已有话题算相似度。

通常研究方法分为2类：

第一类算法是寻找TDT任务中的新的聚类算法，或对已有聚类算法的改造，常用的算法有：k-means、DBSCAN、层次聚类；
第二类算法是挖掘新的聚类特征来提高TDT任务的计算效果，如使用文本的语义特征、分类特征、实体特征、上面事件抽取提到的特征，和任务结合起来，计算更准确的相似度。当然TDT也有很多别的子任务，大家有兴趣可以去看一下。

突发事件监测：TDT为我们处理海量数据提供了很多新的解决思路，之后衍生出来了突发事件检测任务，值得关注。突发特征指的是伴随着事件的发生，若干与该事件密切相关的特征出现反常现象，比如文档、词语的爆发，比如南方下暴雨，暴雨这个词就会比去年或者前几个月的时序有明显的不同，最近是一个显著爆发的特征。我们可以通过检测突发特征来发现事件，这类研究目标与TDT任务不同，不再局限于传统的新闻报道，可以针对多类型的数据，比如微博、搜索、视频数据，受此输入的影响，我们将时序分析方法和话题聚类相结合，来提升热点挖掘的效果，以上方法都能很好地指导我们进行热点挖掘的工作。

接下来针对腾讯海量的数据和数据类型多的特点，提出了我们自己的热点计算框架，下面简单介绍。

03 热点计算框架

1. 总框架

整体分两部分：离线挖掘和在线理解，离线挖掘内容非常丰富，着重讲这块。

离线挖掘流程：先是资源引入，有3个不同的端，腾讯看点浏览器、qq浏览器、qq里的腾讯看点频道，接入丰富的数据之后，通过话题抽取，来提取热点特征，进行话题融合，把挖掘到的结果聚类成话题，再把话题拆分成对应的事件。

为什么先做话题聚类，再做事件拆分呢？

还以科比去世为例。当时描述这个话题，一部分报道的是"科比意外身亡"，另一部分报道"科比妻子悲痛欲绝"，以及"明星悼念科比"。当事件在凌晨刚发生的时候，只有一个媒体和几家论坛报道了这个事情，算法比较难把主要描述"明星悼念科比"和"科比意外身亡"的文章拆成两个，看做一个更加合理，文章增加一两个小时后，很多媒体从不同的角度描述这个事件，文章的丰富程度足以支撑我们把这个话题拆封成合理的较细的粒度，这个细分是比较符合用户兴趣的，比如女性用户更加关心科比妻子的情况，而对一些外国明星悼念科比不那么感兴趣，因此能够以更加有针对性的事件的粒度推荐，提升热点推荐的效果。

详细流程：

① 热点挖掘热点挖掘是为了满足全面性、及时性的要求，把热点挖掘拆为定时任务和流式任务。

定时任务：主要是搜索点击的特征、搜索词文章中的关键词的时序特征，与文章内容聚类的方式结合，把描述相近资源的文章聚合在一起，以话题形式组织起来。
流式任务：将入库的文章，及时通过事件判断过滤掉非事件内容，提升计算流程的时效性。

② 话题融合经过话题挖掘和实践挖掘后，进行话题融合。话题是对向上泛化，需要话题解析模块，将不同输入来源的热点信息以特征提取，与流式处理的融合，组织成话题的粒度；最后通过话题融合模块，从3个不同的角度定义一个热度，这样定好的热度，更加符合平台用户的热度感知，这样能帮助我们进行热点推荐。 ③ 事件拆分得到话题后，为了有效组织事件内容，需要对话题进行拆分，通过对事件命名的方式，把事件以简短的名称组织起来，得到事件tag，这样能支持线上使用，如事件榜单、事件脉络等，事件的核心词和热词进行热度匹配，把事件统一管理起来服务于热点相关的应用。

为什么要做话题库和事件库？

以近期的"暴雨资讯"为例，用户感兴趣的是"安徽特发特大暴雨"的事件内容，而非提及暴雨的文章 ( 比如"日本暴雨导致山洪爆发" )，我们需要把不同的数据源以话题库的形式组织起来，帮助热点推荐以跳出关键词 ( "暴雨" ) 推荐的限制，为用户提供更加符合其兴趣的内容。有了热点计算框架后，我们看看在应用场景上如何落地。

04 热点挖掘

1. QueryLog热点挖掘

第一个是基于query的热点挖掘。

① 预处理：构造Query时序数据

基于这样的假设：如果热点热门，用户有了解详细内容的需求。会通过query去搜索事件详情，因此我们以query为数据来源，这是一个显而易见的事情。如南宁发生火灾，用户会搜索南宁工厂，了解具体的伤亡情况。用户的搜索多种多样，基于突发热点能检测的方式，常见的是根据搜索词构建时间序列，使用BRD算法计算突发性，突发性需要进行分段处理、斜率检测、需要做分段设计，难以维护。我们构造了query热点计算流程来解决这个问题。

② 热门识别：时序分析，识别热门Query

首先是构造这个时序之后，通过时间序列分析来识别热门query，具体做法：定义一个热门query的趋势模板，前面几天平滑，最近有一个上升的趋势；或者小幅度上升，近期然后突然下降、热度减退的模板，这样计算事件的相似度，如果符合，就认为是热门的query，否则就不是。

相似度计算最开始是使用欧拉距离，需要把时间轴上的两个点做严格对齐。虽然趋势一致，但是欧拉对齐会导致相似度计算值较低，会带来bad case，后来使用DTW ( 动态时间规划 ) 算法，使用动态规划的方式来对齐时间序列，能更好捕捉趋势相似的情况。

③ 话题检测：相似Query聚类，形成话题

挖掘到热门query之后，可以发现用户的搜索比较随意，同一个事件的描述也是多种多样，对应多个query，所以需要把相同事件的query聚集起来，构造一个话题，与TDT中的无监督有所不同，搜索可以使用点击二部图的方式，以不同的query 可以点到同一个标题时，认为这两个query相似，结合语义特征，比如"吴亦凡女友"和"吴亦凡恋情"，语义比较相似；还有实体特征，"科比退役""姚明退役"，虽然两个都带有"退役"，看起来字面相似度较高，但是"科比"和"姚明"在事件中是不同的主题，可以对相似度降权。最后对相似度的综合得到更好地query相似度量，得到话题聚类结构。这里可以看到将query到话题的聚类。

最后，我们可以看到用户行为的话题检测，可以帮我们有效度量话题的消费热度。为什么是消费热度呢？是因为用户非主动搜索内容，表示用户有主动的消费意愿，所以是消费热度。这也是非常有效的话题度量方式。

④ 事件识别

在话题检测之前，当话题达到可拆分时，我们会对事件做拆分。常见的话题会伴随非事件的话题，比如热门美剧更新时，会出现热度突发，这样会混合这些query，因此基于监督做事件分类。比如词特征、点击信息，把"下载"去掉，url中的站点信息、域名信息加入进去，train一个分类器，可以有效识别出来哪些是事件、哪些是非事件。

事件命名，组里的同学在之前通过词法分析工具的基础上，提取了一个新的事件命名方式，基于query 和title构造图模型，来挖掘事件concept和event的命名。这是之前话题挖掘的延续，这个任务已经发表在SIGMOD 2020上，大家有兴趣可以做详细阅读。当前挖掘效果每天新增100+事件，准确率人工评估95+。可以看到对当前的挖掘效果，在传统上的提升。

2. 资讯文章热点挖掘

作为信息流服务的团队，每天打交道最多的是海量数据。当热门发生时，自媒体作者会主动跟进热点，创作文章跟进这些内容，比如当科比去世的一个小时后，即便是凌晨四点，作者也会也及时更新做报道。

挖掘主要是采用聚类的方式，离线的方式是将文章的数据按照固定发布时间做切分，通过batch learning对文章进行聚类，k-means、层次聚类这些方法会忽略这样的问题：每天有很多如描述刘德华过往文章，如果直接套用聚类算法会挖掘出来并非热点，会影响用户体验。热点文章包含时效性，如果直接套用聚类，没考虑时效性。传统的突发事件检测Graph event detection是基于二项分布或者傅里叶变化的方法发现突发次，这些突发次会持续一段时间的增长，而非突发的一个尖点。并且基于词粒度的挖掘会带来很多bad case，NLP同学都会发现这样的问题。切词的粒度不可控。

基于这些问题，提出了新的挖掘方式： 基于关键词和动态时间规划的方法来进行事件挖掘。

我们这里使用的处理方式：

① 预处理及热门识别

关键词描述文章主体，借助组内篇章理解的能力，将文章特征转换为关键词特征，与query挖掘相似，将关键词在文章库中出现的频次，构造时间序列，再用DTW算法与固定的模板做匹配，得到挖掘到的热门关键词。比如暴雨，或者前段时间北京6月份疫情，三文鱼突然热起来，通过这种方式挖掘出来"三文鱼"热门关键词，能召回很多描述新发地疫情相关的文章。当时召回的文章的acc和 recall都很高。接下来回到暴雨，通过暴雨召回所有和暴雨相关的文章，再构造热门关键词的实体特征，包括抽取的地点，安徽、合肥，加入实体特征，再用语言模型提取title的特征，计算相似度，3个相似度综合得到文章自底向下的层次聚类，从而得把南方暴雨聚成一个话题。而之前提到的"日本山洪爆发"，虽然提到了暴雨，相似度较低，会聚类为一个孤立的点，可以过滤掉。

② 话题检测

在这之后，同样是聚类，得到的话题是自媒体创作的文章。自媒体作者可以认为是专家用户，他们创作文章的数量，可度量话题热度，定义为生产热度。

③ 事件拆分

然后做事件拆分，以"江西洪涝致699万人受灾"和"重庆暴雨成灾"两个事件为例，基于看点的数据分布，作为一个触发词发现和元素抽取任务，就可以得到受灾和成灾的trigger相似，但argument不相似，这样可以把话题合理拆分成两个不同的时间，拆分为时间后，通过rank，可以把聚类为相似度较高的标题抽出来，然后基于seq2seq + attention的方式，形成可以展示的事件名称，从而得到合理的拆分和事件命名。

④ 热度计算

还可以得到事件库，可以query挖掘得到的消费热度，基于咨询得到的生产热度，基于全网的监控的全网热度，综合起来，对挖掘到的热门文章，进行合理的热度，帮助推荐系统做推荐，提供更好的热度特征。

通过热点挖掘算法，得到更加满足用户兴趣的话题集合、事件集合和对应的热度。

接下来看在热点推荐场景下如何应用起来。

05 热点应用

1. 图文热点应用

图文热点应用。资讯库是流式文章入库，在线理解借助语义匹配模型，将新入库的文章和已有的事件库关联起来，使用的是双塔结构和MatchPyramid模型结合，将文章标题和事件的名称的BOW特征，计算语义相关度，而MatchPyramid模型则构造事件词与文章内容的交互矩阵，比如事件名称包含6个词，文章选择前300个词，是300维，得到6*300的矩阵，做卷积计算，得到一个相似度量，将这两个做线性融合，得到显性匹配的分。这样也可以把在线文章进入事件库，赋上事件标签、话题标签、综合热度，给推荐系统使用。在事件匹配的准确率上，也达到了较高的标准，事件覆盖效果也比较好。

这不仅可以用在图文挖掘上，也可以用在视频、小视频热点挖掘中。

2. 视频&小视频热点

视频&小视频热中的应用，主要是基于热点挖掘得到的文本信息，将图文计算的热点传递给视频和小视频，怎么做的呢？视频能够准确打出影视综合明星tag，通过已挖掘好的热门词库，可以筛选出来近期热门的影视明星类的视频和小视频。我们还会解决这样的问题，比如快乐大本营已经播了很多年，经常出现老片段新发，或者明星自制的明星短剧，需要借助视频关键词、作者的信息、人工标签，过滤掉非热门视频，得到热门视频的候选。另一个是基于新闻报道的视频，人工不知道事件的前提下，直接打事件标签很困难，需要借助已经挖掘到的事件库，和视频标题做匹配，匹配近期的热门事件的视频和小视频，如"科比坠机"，可以匹配到"科比去世"，"科比坠机身亡事件"，得到这些标题后，进入热门视频库中，帮助推荐系统给用户推荐更加热门的视频和小视频。

今天的分享就到这里，谢谢大家。

在文末分享、点赞、在看，给个三连击呗~~

嘉宾介绍：

罗锦文

腾讯 | 研究员

本科毕业于兰州大学，研究生毕业于北京大学。2016年阿里实习，然后2017下半年转战百度实习，于18年加入腾讯正式工作，负责新NLP新热内容挖掘和词法分析相关工作。

社群推荐：

欢迎加入 DataFunTalk NLP 算法交流群，跟同行零距离交流。如想进群，请识别下面的二维码，回复“ NLP”入群。

文章推荐：

腾讯信息流内容理解技术实践

关于我们：

DataFunTalk 专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100场线下沙龙、论坛及峰会，已邀请近500位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章300+，百万+阅读，7万+精准粉丝。

分享、点赞、在看，给个 三连击呗！

腾讯重新定义敏捷

Fri, 04 Sep 2020 16:16:48 CST

敏捷需要重构

敏捷开发奠基人 Robert C. Martin 接受采访时曾表示：软件研发领域成功的秘诀其实是用很多小团队解决很多小问题。随着 IT 互联网的飞速扩大，业务规模的海量增长，软件开发领域走向了用大团队解决大问题。

但大团队先天性的臃肿、迟缓、滞后的弊端，带来了瀑布式软件开发的效率低下。于是在世纪交替之际，软件开发领域的先驱 Robert C. Martin 与 Martin Fowler、Kent Beck 等人共同起草了一份后来引发全球软件革命的文件，是为“敏捷宣言”。

二十年过去了，敏捷开发已经演变成了一种文化，但在其落地过程中却遭遇了种种问题，Robert C. Martin 也在近期表示敏捷运动最成功的只有敏捷一词。在过去二十年中，原本简洁明了的敏捷概念已经变得含糊不清，精益、看板、LeSS、SAFe、现代化、技能提升等等理念让人捉摸不透。

实际上，敏捷开发只是一个从众多特性化的实践中提炼出的共性化的指导思想和原则，并没有给出具体的实践步骤。在实际的工作中，如果企业只是照猫画虎，不针对自己的业务模式、团队规模等特性制定自己的敏捷开发流程，最终都只能流于表面，成效寥寥。

腾讯是国内最早一批实践敏捷开发的企业，早在 2006 年腾讯就引入了敏捷开发的理念，敏捷成为腾讯研发文化的内核。14 年后，腾讯用 TAPD 重新定义了敏捷，这个对内覆盖超 90% 业务的研发平台，对外服务数十个行业、数十万家企业客户的 SaaS 工具，走出了一条别样的敏捷之路。

14 年：探索、实践与重定义

2006 年，腾讯的联合创始人、CTO 张志东先生提出了要创立腾讯自己的敏捷产品研发框架，也就是后来的 TAPD——Tencent Agile Product Development，腾讯敏捷研发协作平台。

在那个年代，国内的敏捷开发落地并没有太多参考实践，预见敏捷开发革命性的企业并不多，大家更愿意在瀑布式的模型下按部就班地做着软件开发工作。腾讯借鉴了业界比较成熟的敏捷思想精髓，吸取了 Scrum、XP、FDD 的养分，经过在腾讯团队的敏捷沉淀实践，总结梳理出了这一套腾讯的敏捷产品研发模型。

所有尝试过敏捷开发的研发团队应该都能感同身受：让团队内的研发人员认可敏捷开发这个理念有多难。而在腾讯这样研发人员占据半数以上的集团公司，推行敏捷开发更不容易。不易之处不仅在于理念的认可，更在于如何向数万研发人员做名词解释：究竟什么才是敏捷？

敏捷在实践中的困境也正是如此：一千个读者有一千个哈姆雷特，一千个团队有一千种敏捷实践。腾讯选择了扎根于自己的企业文化，从中提炼出了重定义的腾讯式敏捷： 以用户价值为依归的快速迭代，小步快跑，鼓励用户参与，持续交付和灰度验证。

从认定敏捷开发的那天起，腾讯在内部打造了一系列的敏捷培训课程，组织了四百多场的敏捷培训，同时也组建了专业的敏捷教练团队进行指导，同时在公司内组织了线上和线下敏捷实践交流，去帮助各大团队进行敏捷经验交流和分享。 通过建立敏捷研发文化，培养兴趣、影响习惯、激发动力，鼓励自适应，从而促进敏捷研发体系进一步完善、进化。

敏捷文化的打造是上层建筑，一款支持实践落地的工具平台是底层基础。2006 年起，腾讯研发团队开始打造这款支撑腾讯敏捷项目管理的工具平台——TAPD。TAPD 平台可以说是沉淀、固化了腾讯最优秀团队的敏捷实践成果。到今天，TAPD 已经覆盖腾讯所有研发团队、各类业务线，沉淀了多种研发模型，支持了 QQ、微信、王者荣耀等明星产品各个阶段的研发协作。

在微信的创业初期，由于团队只有 10 人左右，所有的沟通都在 Excel 上完成。当产品小有名气时，团队规模扩张到了 30~50 人，为了解决版本发布周期极不稳定、经常遗漏 bug 等问题，便引入了 TAPD，尤其是其中的缺陷、迭代需求模块，很好地帮助团队完成了迭代节奏稳定、缺陷跟进等关键问题。当微信进入稳定期后，团队规模扩张到了数百人，对更完善的报表、项目进度、多项目协作以及发布跟进等提出了更高的要求，所幸的是，TAPD 早已能够通过更多模块和功能的配置，很好地给予了支持，也才成为了微信研发团队最值得信赖的研发及沟通协作平台。

正是通过这样内部的持续实践和团队从小到大的成长，丰富了敏捷研发的类型，形成了有腾讯特色的四种研发模型，从稳定迭代到极速发版，从大型团队研发到多业务线敏捷协同，不同的业务场景都能找到适合自己的敏捷研发模型。

这也推动了 TAPD 工具平台的“乐高化”，研发团队可以根据各自团队的规模、业务场景按需组装，TAPD 成为了腾讯敏捷研发协作领域的唯一大中台。

研发过程及工具支撑

DevOps 工具链集成

2015 年，同程旅游通过张志东偶然得知了 TAPD 的存在，双方一拍即合定下了合作意向，这是 TAPD 平台第一次试水对外开放。通过这次合作，TAPD 帮助同程旅游从瀑布流的研发模式成功转型为敏捷研发模式，敏捷迭代、小步快跑，在快速变化的旅游市场中快速占领市场。

截至今天，TAPD 已累计服务数十万家各领域企业，提供适合各行业特色的研发管理解决方案，同时助力高校人才培养，为高校软件工程专业提供课程建设、企业案例和企业实践等支持。TAPD 同时致力于构建开发者生态，从生产端助力开发者，依托服务端连接企业客户，通过搭建开放、连接的平台生态，帮助开发者更快更好地进行应用开发与服务创新。

腾讯的离职员工成为了播撒 TAPD 的“火种”，靠着口碑积累、口耳相传，这一套在腾讯积累沉淀 14 年之久的敏捷研发工具平台开始在金融、游戏、电商、音视频、生活服务等市场生根发芽，由此带来的各异场景下的使用体验，就像敏捷模型的“深度学习”，让这种敏捷变得更加本土化。

敏捷开发在落地过程中遇冷的原因是什么？是抽象化的概念在具象化的场景面前没有统一的解释标准，企业在实践中往往只取到了敏捷的“形”，而忽略了敏捷的“神”。腾讯 14 年的敏捷开发落地过程中，一以贯之的是重定义后的核心理念： 以用户价值为依归的快速迭代，小步快跑，鼓励用户参与，持续交付和灰度验证。而 TAPD 在这 14 年的发展过程中，也不再仅仅是一套敏捷研发协作的工具平台，更成为了一种验证有效的敏捷文化落地方法论。

写在最后

TAPD 首次对外发声是在 2015 年的 ArchSummit 全球架构师峰会（深圳站），举办方正是 InfoQ 所在的极客邦科技。极客邦科技也是 TAPD 的核心用户，动笔之前，笔者向我司从来不对付的研发与产品总监调研了使用体验，得到的反馈居然都是特！别！好！这大概是我第一次在同一件事情上看到他们达成了惊人的统一。

而今，TAPD 平台对外开放已有三年。根据 TAPD 企业数字化转型调查，当前，87.9% 的企业正在尝试数字化转型，数字化转型的价值已获企业普遍认可。而在数字化转型路上，数字化协同办公、敏捷能力最受企业重视。

腾讯 TAPD 负责人表示：“对外开放三周年，TAPD 已经从腾讯内部的一款敏捷开发工具，成长为服务整个社会和行业的云端 SaaS 敏捷研发工具。我们始终坚持‘要在协作中看到一个个活生生的人，看到人和任务之间的关系’的初心，专注于连接代码与人，助力全行业的研发效能提升。”

行业真正需要的，是怎样的敏捷？

“薛定谔式的敏捷”，No！

重定义的敏捷，Yes！

以上。

腾讯万亿级 Elasticsearch 内存效率提升技术解密

Tue, 16 Jun 2020 00:00:00 CST

作者：morningchen，腾讯 TEG 后台开发工程师

Elasticsearch（ ES ）是一款功能强大的开源分布式实时搜索引擎，在日志分析（主要应用场景）、企业级搜索、时序分析等领域有广泛应用，几乎是各大公司搜索分析引擎的开源首选方案。

Tencent ES 是内核级深度优化的 ES 分支，持续地进行高可用、高性能、低成本等全方位优化，已支撑的单集群规模达到千级节点、万亿级吞吐。Tencent ES 已在公司内部开源，同时也积极贡献开源社区，截止目前已向社区提交 PR 25+。腾讯联合 Elastic 官方在腾讯云上提供了内核增强版 ES 云服务，支撑公司内部云、外部云、专有云达 60PB+ 的数据存储，服务蘑菇街、知乎、B 站、凤凰网等业内头部客户。

本文主要介绍 Tencent ES 的主要优化点之一：零拷贝内存 Off Heap，提升内存使用效率，降低存储成本。最终达到，在读写性能与源生逻辑一致的前提下，堆内存使用率降低 80%，单节点存储量从 5TB 提升至 50TB 的效果。

问题：日志分析场景数据量大，ES 内存瓶颈导致存储成本较高

上节提到，日志分析是 ES 的主要应用场景（占比 60%），而日志数据的特点显著：

数据量大，成本是主要诉求：我们大批线上大客户，数据量在几百 TB 甚至 PB 级，单集群占用几百台机器。如此规模的数据量，带来了较高的成本，甚至有些客户吐槽，日志的存储成本已超越产品自身的成本。
数据访问冷热特性明显：如下图所示，日志访问近多远少，历史极少访问却占用大量成本。

分析：成本瓶颈在哪里：堆内存使用率过高

我们对线上售卖的集群做硬件成本分析后，发现成本主要在磁盘和内存。为了降低磁盘成本，我们采取冷热分离、Rollup、备份归档、数据裁剪等多种方式降成本。在冷热分离的集群，我们通过大容量的冷存储机型，来存储历史数据，使得磁盘成本下降 60% 左右。

问题也随之而来：如上图所示，大容量的冷机型，存在磁盘使用率过低的问题（ 40 % 以下），原因是堆内存使用率过高了（ 70 % 左右），制约磁盘使用率无法提升。（其中单节点磁盘使用率 40%，约 13TB 左右，这已经是 Tencent ES 优化后的效果，源生只能支持到 5 TB 左右）所以，为了提升低成本的冷机型磁盘使用率，同时也为了降低内存成本，我们需要降低 ES 的堆内存使用率。

堆内存使用率为什么会高？

ES 是通过 JAVA 语言编写的，在介绍如何降低堆内存使用率之前，先了解下 JAVA 的堆内存：

堆内存就是由 JVM （JAVA 虚拟机）管理的内存。建立在堆内存中的对象有生命周期管理机制，由垃圾回收机时自动回收过期对象占用的内存。
堆外内存是由用户程序管理的内存，堆外内存中的对象过期时，需要由用户代码显示释放。

1. 运营侧调整装箱策略能否解决问题？

了解了 JAVA 堆内存后，我们看，能否通过调整运营策略来提升堆内存容量呢？

堆内存分配大一点行不行？超过 32GB，指针压缩失效，内存浪费， 50GB 堆内存性能与 31GB 接近且垃圾回收压力大，也影响性能；
多节点部署提高堆内存总量是否可行？多节点部署，占用机器量更大，用户成本上升大客户节点数过多（几百个），集群元数据管理瓶颈，可用性下降反向推动云上用户拆分集群，阻力很大。

所以，简单的运营侧策略调整无法解决堆内存使用率过高的问题。那么我们就需要确认 ES 的堆内存是被什么数据占用了，能否优化。

2. 堆内存被什么数据占用了？

我们对线上集群的堆内存分布情况做统计分析后，发现绝大部分堆内存主要被 FST（ Finite State Transducer ）占用了：

FST 内存占用量占分堆内存总量的 50% ~ 70%
FST 与磁盘数据量成正比：10TB 磁盘数据量，其对应的 FST 内存占用量在 10GB ~ 15GB 左右。

因此，我们的目标就是就是通过内核层的优化，降低 FST 的堆内存占用量。

方案：降低 FST 堆内存占用量

什么是 FST ？

在介绍具体的方案前，先来了解下 FST 到底是什么。

如上图所示，ES 底层存储采用 Lucene（搜索引擎），写入时会根据原始数据的内容，分词，然后生成倒排索引。查询时，先通过查询倒排索引找到数据地址（DocID）），再读取原始数据（行存数据、列存数据）。但由于 Lucene 会为原始数据中的每个词都生成倒排索引，数据量较大。所以倒排索引对应的倒排表被存放在磁盘上。这样如果每次查询都直接读取磁盘上的倒排表，再查询目标关键词，会有很多次磁盘 IO，严重影响查询性能。为了解磁盘 IO 问题，Lucene 引入排索引的二级索引 FST [Finite State Transducer] 。原理上可以理解为前缀树，加速查询。

其原理如下：

将原本的分词表，拆分成多个 Block ，每个 Block 会包含 25 ~ 48 个词（Term）。图中做了简单示意，Allen 和 After 组成一个 Block 。
将每个 Block 中所有词的公共前缀抽取出来，如 Allen 和 After 的公共前缀是 A 。
将各个 Block 的公共前缀，按照类似前缀树的逻辑组合成 FST，其叶子节点携带对应 Block 的首地址。（实际 FST 结构更为复杂，前缀后缀都有压缩，来降低内存占用量）
为了加速查询，FST 永驻堆内内存，无法被 GC 回收。
用户查询时，先通过关键词（Term）查询内存中的 FST ，找到该 Term 对应的 Block 首地址。再读磁盘上的分词表，将该 Block 加载到内存，遍历该 Block ，查找到目标 Term 对应的 DocID。再按照一定的排序规则，生成 DocID 的优先级队列，再按该队列的顺序读取磁盘中的原始数据（行存或列存）。

由此可知， FST 常驻堆内内存，无法被 GC 回收，长期占用 50% ~ 70% 的堆内存！

解决方案

既然 FST 是常驻堆内内存，导致堆内存使用率过高，那么解决问题的思路有两种：

降低 FST 在堆内的内存使用量
将 FST 从堆内存（OnHeap，有 32GB 容量限制）移到堆外内存（OffHeap）。因为堆外内存无容量上限，可通过扩充机器内存来提升容量。（堆外内存容量限制近似为物理内存 - JAVA 堆内存）自然也就有了相应方案：

解决方案一：降低 FST 在堆内的内存使用量

在 Tencent ES 成立前期，我们采用过这种方案。具体的做法是，将 FST 对应的 Block 大小，从 25 ~ 48，放大一倍至 49 ~ 96 。这样，在关键词 Term 数相同的情况下，Block 数量降低了一倍，对应的 FST 内存理论上也会下降一倍。

优点：我们实测发现，这种方案下，FST 的堆内存占用量下降了 40% 左右。
缺点：(1)由于 Block 内的 Term 数变多了，那么每次遍历 Block 查找目标 Term 时，需要从磁盘读取的数据量更大了，因此也带来了明显的查询性能损耗，约 20% 。(2)该方案只是让 FST 占用的内存下降了一半，仍无法控制 FST 占用的内存总量。不同场景下，FST 数据量大小差异也很大，在全文检索的字段较多时，仍然存在 FST 内存过高的问题。

由此我们可以看出，简单的降低 FST 的堆内存使用量，并不是一个普适性的方案，需要更为通用、彻底限制住 FST 总大小的方案。

解决方案二：将 FST 从堆内存（OnHeap）移到堆外内存（OffHeap）

将 FST 从堆内存（OnHeap）移到堆外内存（OffHeap），几乎可以完全释放 FST 在堆内存占据的使用空间，这也是 JAVA 实践方向上一个普遍使用的方案。对于 JAVA 的堆内存不足，将部分内存移到堆外内存（OffHeap）的问题，ES 社区和其他 JAVA 系产品都有相应的解决方案。

ES 社区方案：该方案是将 FST 从堆内存中剔除，直接交由 MMAP 管理。FST 在磁盘上也是有对应的持久化文件的，Lucene 的 .tip 文件，该方案每次查询时直接通过 MMap 读取 .tip 文件，通过文件系统缓存 FST 数据。

优点：这种方实现简单，代码改动量小
缺点：(1)我们早期也试用过这种方式实现，但是由于 MMAP 属于 page cache 可能被系统回收掉。而且 ES 的大查询也会使用大量的系统缓存导致 FST 占用的内存被冲掉，瞬间产生较多的读盘操作，从而带来性能的 N 倍损耗，容易产生查询毛刺。特别是在 SATA 盘上，严重时查询时延有 10 倍的毛刺。(2)Lucene 8.x 、ES 7.x 后才支持该功能，存量的 6.x 用户无法使用。

HBase 方案 HBase 的方案是，在堆外搭建一个 Cache，将其一部分堆内存（Bucket Cache，Data Block 缓存）移到堆外，释放堆内内存。

优点：数据缓存放在堆外，释放大量堆内内存
缺点：(1)淘汰策略完全依赖 LRU 策略，(2)只是把数据缓存放置在堆外，索引的缓存还在堆内

Tencent ES 方案我们的方案总体上接近 HBase 的方案，相比之下：

优点：(1)相比于 ES 社区方案，我们堆外的 Cache 保证 FST 的内存空间不受系统影响。(2)相比于 HBase 方案，我们实现了更精准的数据淘汰策略，提高了内存使用率。也通过多级 Cache 解决性能问题，所以我们敢于把索引放置在堆外。

实现：全链路 0 拷贝 FST OffHeap Cache

下面通过将由浅入深地向大家介绍我们实现 FST OffHeap 的过程，及其中碰见的问题和解决方案。

总体架构

在实现 OffHeap 方案的初期，我们的架构如上图所示。先来看下源生逻辑是怎样访问 FST 的：

数据写入：ES 的一次 Refresh / Merge 动作，会生成一个新的 Lucene Segment，相应的在磁盘上生成该 Segment 对应的各种数据文件。其中 .tip 文件里面存储的就是该 Segment 各个字段的 FST 信息。在生成 .tip 文件后，Lucene 也会将每个字段（ Field ）的 FST 数据解析后，拷贝至该 Field 在 OnHeap 内存中的对象里，作为一个成员变量永驻内存，直到该 Segment 被删除（ Index 被删除、Segment Merge 时）。
数据查询：查询时，直接访问 OnHeap 的 FST 。

再来看下优化后的 Tencent ES 是怎样访问 FST 的：

数据写入：在 OffHeap 内存放置一个 LRU Cache，在生成新的 Segment 时，不再将 .tip 中的 FST 数据拷贝至 OffHeap LRU Cache。将其对应的 Key 放置在 OnHeap 的 Field 中，不再将 FST 拷贝至 OnHeap 的 Field 中。这样就把 FST 从 OnHeap 移到了 OffHeap。
数据查询：查询时，通过 OnHeap Field 中保存的 Key，去 OffHeap LRU Cache 中查询 FST 数据，将其拷贝至 OnHeap 后，做查询操作。若 Cache Miss ，则从磁盘的 .tip 文件中的相应位置读取该 Field 对应的 FST 做查询，同时将其放置到 OffHeap LRU Cache 中。

将两种方案做个对比，如下表所示：

那么可以总结出 Tencent ES 优化后的 FST 访问逻辑的优势和劣势：

优势：在 OnHeap 我们用 100B 左右的 Key 置换 MB 级别的 FST，大大降低的内存占用量，使得单节点最大支持的磁盘数据量有了 5 倍以上的提升。
劣势：FST 在每次查询时都要从 OffHeap LRU Cache 拷贝至 OnHeap，相比于源生逻辑直接访问 OnHeap 的 FST ，读写都多了拷贝的动作，造成高并发读写时有 20%+ 的性能损耗。

所以，我们要对 OffHeap LRU Cache 的读写路径做优化，减少 Copy 次数，提升读写性能。具体的实现方案是全链路零拷贝 OffHeap FST 访问逻辑。

全链路零拷贝 OffHeap FST 访问逻辑

ES 源生逻辑访问 FST 只支持堆内的操作，怎样做到让它能直接访问堆外的数据呢？

为此，我们做了两方面优化：

OffHeap LRU Cache：改造读数据逻辑，Cache 只返回数据地址，封装为一个 Buffer，堆内只存数据地址，这样就把 FST 的访问从先拷贝至 OnHeap 再访问优化为直读 OffHeap 内存。
ES：重构 FST 读写逻辑，实现 FST 访问直读 OffHeap 内存：
FST 抽象为一个 FST Buffer，对外提供 FST 形式的各种访问接口。内部实现按 FST 的数据结构读取 OffHeap Buffer 的逻辑，作为访问 OffHeap FST 的代理。
将 ES 访问 FST 的所有链路全部改造为 FST Buffer 接口的形式，优化 FST 的读写路径如下所示：

经过上述优化，把 FST 的数据访问由 1 次 Copy 优化为 0 Copy，实现了全链路零拷贝 OffHeap FST 访问逻辑。同时也将 FST 的数据写入从 2 次 Copy 优化为 1 次 Copy。读写性能损耗从 20%+ 下降至 7%。

虽然这样性能影响已经比较小了，但我们还是想挑战下自己，能否将性能优化到极致呢？

多级 Cache 将性能优化到极致

要进一步优化性能，需要搞清楚一个问题：7% 的性能损耗在哪里？Perf 分析后发现，Hot 堆栈是 OffHeap Cache 计算 Hash、校验 Key 等逻辑。为什么会有频繁读 Cache 的操作呢？我们分析 Lucene 的源码发现，在高并发读写时，一次读写入上千条数据，则会有读 Cache 上千次。例如，一个 bulk update 写入 3000 条数据，3 分片，每个分片大概有 1000 条数据 update 操作，那么就有 1000 次读 Cache 的逻辑。而这 1000 次读 Cache，基本上是读的同一个 Key （_id 对应的 Key），能否做到让这 1000 次查询的 Key，稍微缓存一会，防止那么多次读 Cache 的操作呢？

我们的优化方案是：OnHeap + OffHeap 的两级 Cache 架构，降低 OffHeap Cache 访问频率。而堆内的 Cache 一定要轻量，最少的占用 OnHeap 内存，否则就违背了我们要将 FST 从 OnHeap 移出去的初衷。所以，我们最终选用堆内的弱引用机制（ WeakRefrence ）来缓存 OffHeap FST 的指针，作为 OnHeap 的轻量级 Cache，利用 JVM 的 GC 自动释放无效的弱引用，同时堆外内存。

相比于直接设置一个 OnHeap Cache，弱引用有占用内存小，避免拷贝等优势。

这样我们访问 FST 的逻辑，会先查询堆内的各个查询共享的 WeakRefrence，当其已经被释放时，才会访问 OffHeap Cache。这样就大大降低了 OffHeap Cache 的访问频率。

这里的挑战是，两级 Cache，key 的关联释放问题。JVM GC 时会销毁 WeakRefrence 对应的 OnHeap 对象，但 Java 无析构函数，无法自动释放堆外指针。而我们期望，在堆内的 WeakRefrence 释放时，同时释放堆外指针，从而对 OffHeap Cache 的 Key 的引用计数减一，使其可以根据 LRU 规则自动回收无效的 FST 数据。

深入分析 JAVA 垃圾回收、弱引用机制后，发现可以通过注册一个 WeakRefrence Queue，在 WeakRefrence 释放前，可以捕获到它。进而改造 WeakRefrence 的数据结构，使其在被捕获后，对 OffHeap Cahe 的 Key 引用计数减一，然后才被回收。

经过上述 OnHeap WeakRefrence + OffHeap LRU Cache 两级 Cache 架构的优化后，高并发读写性能基本与源生逻辑持平。

其他优化点

除了上述的性能优化外，Tencent ES 的 FST OffHeap 还做了一些其他优化：

精准控制 Cache 淘汰策略，内存高效使用：
LSM Tree 底层文件合并过程，及时淘汰无效数据
字段粒度 Cache 控制：有去重需求：主键（_id ）写入 Cache，提升写入性能无去重需求：主键（_id ）不写入 Cache，降低内存成本【20%-40%】
CAS 并发控制：解决 Cache Miss 后，并发读文件的 IO 放大问题
不停服动态调整 Cache 大小：用户可根据业务情况，在不停服的情况下随时调整 Cache 大小
不停服动态开关 OffHeap Cache ：
用户按需开关 OffHeap Cache 功能
存量集群上线部署兼容性

优化效果

最后来看下我们层层优化后，最终的效果：

压测效果

通过 ES 官方 Bench 工具 ES Rally 压测，结果如下：

线上效果

根据线上集群的实际运行效果看，当开启 OffHeap 功能后，集群整体平均 JVM 的内存使用率从 70%+ 下降至 30% 左右。

Tencent ES 将持续地进行高可用、高性能、低成本等全方位优化：可用性方面，将提升 ES 的故障自愈能力、故障自动分析诊断，达到零接触运维的目标；高性能方面，将进一步提升 ES 的海量数据实时分析能力；低成本方面，将提供存储与计算分离的能力，基于腾讯自研的共享文件系统 CFS，进一步缩减成本。

最后，欢迎各位对 ES 内核技术有兴趣的同学扫描下方的二维码与我们展开交流，同时也欢迎大家在腾讯云体验 CES 云服务。

浅谈“HTAP” - 云+社区 - 腾讯云

Sat, 13 Jun 2020 12:22:34 CST

HTAP是近些年来比较火的一个概念，下面就聊聊其前世今生及技术特点。

1. 数据应用类别

根据数据的使用特征，可简单做如下划分。在选择技术平台之前，我们需要做好这样的定位。

1).OLTP

联机事务处理OLTP

（On-Line Transaction Processing）

OLTP是事件驱动、面向应用的，也称为面向交易的处理过程。其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作的快速响应。例如银行类、电子商务类的交易系统就是典型的OLTP系统。其具备以下特点：

直接面向应用，数据在系统中产生。
基于交易的处理系统。
每次交易牵涉的数据量很小；对响应时间要求非常高。
用户数量非常庞大，其用户是操作人员，并发度很高。
数据库的各种操作主要基于索引进行。
以SQL作为交互载体。
总体数据量相对较小。

2).OLAP

联机实时分析OLAP

（On-Line Analytical Processing）

OLAP是面向数据分析的，也称为面向信息分析处理过程。它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。其特征是应对海量数据，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。例如数据仓库是其典型的OLAP系统。其具备以下特点：

本身不产生数据，其基础数据来源于生产系统中的操作数据
基于查询的分析系统；复杂查询经常使用多表联结、全表扫描等，牵涉的数量往往十分庞大
每次查询设计的数据量很大，响应时间与具体查询有很大关系
用户数量相对较小，其用户主要是业务人员与管理人员
由于业务问题不固定，数据库的各种操作不能完全基于索引进行
以SQL为主要载体，也支持语言类交互
总体数据量相对较大

3).OTHER

除了传统的OLTP、OLAP类，近些年来针对数据的使用又有些新特点，我将其归入了“其他”类。

多模随着业务“互联网化”和“智能化”的发展以及架构 “微服务”和“云化”的发展，应用系统对数据的存储管理提出了新的标准和要求，数据的多样性成为突出的问题。早期数据库主要面对结构化数据的处理场景。后面随着业务的发展，逐渐产生了对非结构化数据的处理需求。包括结构化数据、半结构化(JSON、XML等)数据、文本数据、地理空间数据、图数据、音视频数据等。多模，正是指单一数据库支持多种类型数据的存储与处理。
流式流式处理(实时计算)，是来源于对数据加工时效性的需求。数据的业务价值随着时间的流失而迅速降低，因此在数据发生后必须尽快对其进行计算和处理。传统基于周期类的处理方式，显然无法满足需求。随着移动互联网、物联网和传感器的发展导致大量的流式数据产生。相应地出现了专有的流式数据处理平台，如Storm、Kafka等。近些年来，很多数据库开始支持流式数据处理，例如MemSQL、PipelineDB。有些专有流式数据处理平台开始提供SQL接口，例如KSQL基于Kafka提供了流式SQL处理引擎。
高阶随着对数据使用的深入，数据的使用不再仅仅以简单的增删改查或分组聚合类操作，而对于其更为高阶的使用也逐步引起大家的重视。例如使用机器学习、统计分析和模式识别等算法，对数据进行分析等。

对比 — OLAP vs OLTP

2. 数据处理模式

面对上述复杂多变的应用场景，数据应用的多种类别，是由单一平台处理，还是由不同平台来处理呢？一般来说，专有系统的性能将比通用系统性能高一到两个数量级，因而不同的业务应采用不同的系统。但正如古人说“天下大势、分久必合、合久必分”，在数据处理领域也有一种趋势，由单一平台来处理。这里选择的核心在于如何来辩证看待需求和技术。它们是一对矛盾体，当这对矛盾缓和时，数据处理领域将更趋向于整合；而当这对矛盾尖锐时，数据处理领域将趋于分散。就软硬件技术发展现状和当前需求来看，未来整合的趋势更为明显。集成数据平台将能满足绝大多数用户的场景，只有极少数企业需要使用专有系统来实现其特殊的需求。

1).分散式（专有平台）

目前比较常规的方式，是采用多个专有平台，来针对不同场景进行数据处理。因此是跨平台的，因此是有个数据传输的过程。这之中会带来两个问题：数据同步、数据冗余。数据同步的核心是数据时效性问题，过期的数据往往会丧失价值。常见的做法如下:

OLTP系统中的数据变化，通过日志的形式暴露出来；通过消息队列解耦传输；后端的ETL消费拉取，将数据同步到OLAP中。整个链条较长，对于时效性要求较高的场景是个考验。此外，数据在链条中流动，是存在多份的数据冗余保存。在常规的高可用环境下，数据会进一步保存多份。因此这里面隐藏了比较大的技术、人力成本以及数据同步成本。而且横跨如此之多的技术栈、数据库产品，每个技术栈背后又需要单独的团队支持和维护，如DBA、大数据、基础架构等。这些都蕴含着巨大的人力、技术、时间、运维成本。正是出于在满足各种业务需求的同时，提高时效性，减低数据冗余、缩短链条等，收敛技术栈就变得很重要。这也是通用类平台解决方案，诞生的出发点。

2).集中式（通用平台）

用户厌倦了为不同的数据处理采用不同的数据处理系统，更倾向于采用集成数据处理平台来处理企业的各种数据类型。对于融合了联机事务处理和联机实时分析的场景，也就是下面所谈到的HTAP。此类通用平台方案具备下面优点：

通过数据整合避免信息孤岛，便于共享和统一数据管理。
基于SQL的数据集成平台可提供良好的数据独立性，使应用能专注于业务逻辑，不用关心数据的底层操作细节。
集成数据平台能提供更好的实时性和更全的数据，为业务提供更快更准的分析和决策。
能够避免各种系统之间的胶合，企业总体技术架构简单，不需要复杂的数据导入/导出等，易于管理和维护。
便于人才培养和知识共享，无须为各种专有系统培养开发、运维和管理人才。

3. HTAP

HTAP数据库（Hybrid Transaction and Analytical Process，混合事务和分析处理）。2014年Gartner的一份报告中使用混合事务分析处理(HTAP)一词描述新型的应用程序框架，以打破OLTP和OLAP之间的隔阂，既可以应用于事务型数据库场景，亦可以应用于分析型数据库场景。实现实时业务决策。这种架构具有显而易见的优势：不但避免了繁琐且昂贵的ETL操作，而且可以更快地对最新数据进行分析。这种快速分析数据的能力将成为未来企业的核心竞争力之一。

1).技术要点

底层数据要么只有一份，要么可快速复制，并且同时满足高并发的实时更新。
要满足海量数据的容量问题，在存储、计算都具有很好的线性扩展能力。
具有很好的优化器，可满足事务类、分析类的语句需求。
具备标准的SQL，并支持诸如二级索引、分区、列式存储、向量化计算等技术。

2).重点技术 – 行列存储

行存储（Row-based）：对于传统的关系型数据库，比如甲骨文的OracleDB和MySQL，IBM的DB2、微软的SQL Server等，一般都是采用行存储（Row-based）行。在基于行式存储的数据库中，数据是按照行数据为基础逻辑存储单元进行存储的，一行中的数据在存储介质中以连续存储形式存在。

列式存储（Column-based）是相对于行式存储来说的，新兴的Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中，数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。

传统的行式数据库，是按照行存储的，维护大量的索引和物化视图无论是在时间（处理）还是空间（存储）面成本都很高。而列式数据库恰恰相反，列式数据库的数据是按照列存储，每一列单独存放，数据即是索引。只访问查询涉及的列，大大降低了系统I/O，每一列由一个线来处理，而且由于数据类型一致，数据特征相似，极大方便压缩。

3).重点技术 – MPP

MPP (Massively Parallel Processing)，即大规模并行处理，在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。下面以典型的MPP产品Greenplum架构为例。

4).重点技术 – 资源隔离

OLTP、OLAP类两者对资源的使用特点不同，需要在资源层面做好隔离工作，避免相互影响。常见的通过定义资源队列的方式，指定用户分配队列，起到资源隔离的作用。

5).HTAP产品

下图是网站找到的数据库产品分类图，针对HTAP类的可参考对象线上的相关产品。当然这只是一家之言，仅供参考！

为什么腾讯 QQ 的大数据平台选择了这款数据库？

Sun, 24 May 2020 00:00:00 CST

作者：韩健

来源：大数据DT（ID：hzdashuju）

00 为什么QQ要选择InfluxDB？

从2016年起，笔者在腾讯公司负责QQ后台的海量服务分布式组件的架构设计和研发工作，如微服务开发框架、名字路由、名字服务、配置中心等，做了大量分布式架构、高性能架构、海量服务、过载保护、柔性可用、负载均衡、容灾、水平扩展等方面的工作，以公共组件的形式支撑来自QQ后台和其他BG海量服务的海量流量。

2018年年底，笔者负责监控大数据平台的研发工作，致力于减少现有监控后台成本，以及支撑内部和外部海量监控数据的需求，打造千亿级监控大数据平台。

笔者发现，当前监控技术领域缺乏优秀的监控系统，尤其是在海量监控数据场景中，很多团队常用的做法是堆服务器和堆开源软件，比如大量采用高配置的服务器，单机近百CPU核数、TB内存、数十TB的SSD存储，安装了大量开源软件，如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MongoDB等， 但实际效果并不理想。

众多开源软件的组合是在增加了系统的运营成本和数据的处理延迟的情况下解决接入计算，在海量标签和时间序列线情况下，常出现查询超时、数据拉不出来等问题，且成本高昂。

笔者认为，海量或千亿级是整体的量，是个笼统的概念，可以 分而治之，通过分集群的方法来解决，海量监控数据的真正挑战在于以下几点：

能否做到实时。实时是种质变的能力，可将一个离线监控平台提升为一个实时决策系统。难点在于能否设计实现高性能的架构，以及能否实现水平扩展等。
分集群后，单个业务的流量大小、标签集多少是关键。流量大，相对容易解决，主要涉及系统性能和水平扩展等。标签集多，海量标签，海量时间序列线，如何做查询优化是挑战，如笔者遇到的一些业务上报的监控数据，有几十个维度的标签，并将QQ号和URL作为标签值，有非常海量的时间序列线。
针对监控数据多写少读、成本敏感的特点， 如何设计高效的存储引擎？既能充分发挥硬件性能，又能在高效压缩存储的同时保障查询效率。

为了更好地打造有竞争力的监控系统，我们将技术理念定位为“技术降成本， 坚决反对开源软件堆砌”。

首先，我们认为云计算是基建，决定它能否成功的关键在于能否在基础技术上突破，打造出相比开源软件更有成本优势的云原生软件；
其次，虽然现在开源软件非常繁荣，基于开源软件，我们很容易搭建一个基础系统，将功能跑起来，但绝大部分开源软件侧重的是功能，而不是针对海量监控数据的场景进行设计，或多或少都有其局限性，且成本也非常高昂。

因此我们要做的是借助强大的技术和工程能力，直面问题，在架构和源码层面解决它，而不是引入和堆砌更多的开源软件。

出于工程效率的考虑，我们选择基于开源软件进行二次开发，使用开源软件的部分代码，按照我们的想法进行架构设计和功能开发。在对众多的开源软件进行调研分析后， 我们最终选择了以InfluxDB源码为基础进行二次开发。

之所以选择InfluxDB源码，主要是因为我们对InfluxDB源码背后的技术和工程实力比较认可。InfluxDB研发团队能真正解决海量监控数据场景的问题，也是在认真地打造一款优秀的监控产品（出于读写性能和可用性的考虑，InfluxDB研发团队曾2次重构存储引擎）。

在笔者着手以InfluxDB源码为基础开发集群等功能时，业界还没有团队实现了真正可用的InfluxDB集群能力。一些团队只是通过Proxy实现了负载均衡，却无法突破单机接入计算和存储的限制，缺乏一致性能力。

有些团队在对InfluxDB进行了多年的学习和研究后，最终考虑到基于时序分片的复杂度而放弃了基于InfluxDB开发集群能力，转而选择基于RocksDB、Zookeeper等开源软件进行自建。

笔者在3个月内快速开发出了CP和AP架构分离、时序分片、水平扩展等基本集群能力，另外，根据业务的特点，在索引引擎、冷热分离、查询实现、第三方协议、高可用性、可运营性等方面也做了大量的工作。

最终的效果也是符合预期的，如从替换现有监控系统后台的实施对比来看，我们用了不到10%的机器成本就支撑起原监控后台所支撑的海量监控数据，成本优势突出。

InfluxDB是一款非常优秀的软件，直接推动监控技术进入了实时、纳秒级的新时代，除了类SQL查询语言、RESTful API等现代特性外，还具有读写性能高、存储压缩率高、生态丰富、功能强大等特性。

01 什么是InfluxDB

InfluxDB是一个开源的、高性能的时序型数据库，在时序型数据库DB-Engines Ranking上排名第一。

在介绍InfluxDB之前，先来介绍下 时序数据。按照时间顺序记录系统、设备状态变化的数据被称为时序数据（Time Series Data），如CPU利用率、某一时间的环境温度等。

时序数据以时间作为主要的查询纬度，通常会将连续的多个时序数据绘制成线，制作基于时间的多纬度报表，用于揭示数据背后的趋势、规律、异常，进行实时在线预测和预警，时序数据普遍存在于IT基础设施、运维监控系统和物联网中。

时序数据主要有如下 3个特点：

抵达的数据几乎总是作为新条目被记录，无更新操作。
数据通常按照时间顺序抵达。
时间是一个主坐标轴。

时序型数据库是存放时序数据的专用型数据库，并且支持时序数据的快速写入、持久化、多纬度的实时聚合运算等功能。

传统数据库通常记录数据的当前值，时序型数据库则记录所有的历史数据，在处理当前时序数据时又要不断接收新的时序数据，同时时序数据的查询也总是以时间为基础查询条件，并专注于解决以下海量数据场景的问题：

时序数据的写入：如何支持千万级/秒数据的写入。
时序数据的读取：如何支持千万级/秒数据的聚合和查询。
成本敏感：海量数据存储带来的是成本问题，如何更低成本地存储这些数据，是时序型数据库需要解决的关键问题。

InfluxDB是一个由InfluxData公司开发的开源时序型数据库，专注于海量时序数据的高性能读、高性能写、高效存储与实时分析，在DB-Engines Ranking时序型数据库排行榜上位列榜首，广泛应用于DevOps监控、IoT监控、实时分析等场景。

具体的DB-Engines Ranking时序型数据库的排行榜（源自2019年5月的DB-Engines Ranking数据）如图1-1所示。

InfluxDB部署简单、使用方便，在技术实现上充分利用了Go语言的特性，无须任何外部依赖即可独立部署；
提供类似于SQL的查询语言，接口友好，使用方便；拥有丰富的聚合运算和采样能力；
提供灵活的数据保留策略（Retention Policy）来设置数据的保留时间和副本数；
在保障数据可靠性的同时，及时删除过期数据，释放存储空间；
提供灵活的连续查询（Continuous Query）来实现对海量数据的采样。
支持多种通信协议，除了HTTP、UDP等原生协议，还兼容CollectD、Graphite、OpenTSDB、Prometheus等组件的通信协议。

▲图1-1 时序型数据库DB-Engines Ranking排名

讲到InfluxDB，就不能不提InfluxData的 开源高性能时序中台TICK（Telegraf + InfluxDB + Chronograf + Kapacitor），InfluxDB是作为TICK的存储系统进行设计和开发的。

TICK专注于DevOps监控、IoT监控、实时分析等应用场景，是一个集成了采集、存储、分析、可视化等能力的开源时序中台，由Telegraf、 InfluxDB、Chronograf、Kapacitor 4个组件以一种灵活松散但紧密配合、互为补充的方式构成，各个模块相互配合、互为补充，整体系统架构如图1-2所示。

▲图1-2 TICK系统架构

Telegraf是用于采集和上报指标的数据采集程序，采用灵活的、可配置的插件实现。

Telegraf可以通过配置文件的配置，采集当前运行主机的指定指标，如CPU负载、内存使用等，也可以从第三方消费者服务（如StatsD、Kafka等）拉取数据，上报到已支持的多种存储系统、服务或消息队列，如InfluxDB、Graphite、OpenTSDB、Datadog、Librato、Kafka、MQTT、NSQ等。

InfluxDB是专注于时序数据场景（如DevOps监控、IoT监控、实时分析等）的高性能时序型数据库， 支持灵活的自定义保留策略和类SQL的操作接口。

Chronograf是可视化的、BS架构的管理系统，可用于配置和管理接收到的监控数据、告警，并支持通过灵活强大的模块和库，快速配置数据可视化仪表盘、告警规则、可视化规则。

Kapacitor是从零构建的原生数据处理引擎，支持流式处理和批量处理，支持灵活强大的自定义功能，如定义新的告警阈值、告警指标特征、告警统计异常特征等，以及后续的告警处理行为。

除了灵活，Kapacitor也很开放，能灵活地集成对接第三系统，如HipChat、OpsGenie、Alerta、Sensu、PagerDuty、Slack等。

02 InfluxDB的优势

存储和分析时序数据的时序型系统并不鲜见，自计算机问世以来，我们一直在数据库中存储时序数据。

最初，使用通用存储系统存储时序数据，如MySQL。第一代时序平台，如KDB +、RRDtool、Graphite等，在20年前就推出了，主要用于存储和分析数据中心的时序数据，以及高频金融数据、股票波动率等。

根据DB-Engines等数据库趋势跟踪和行业分析网站发布的信息， 时序型数据库是数据库市场中份额增长最快的部分。原因很明显，计算机虚拟世界，如数据库、网络、容器、系统、应用程序等，和物理世界，如家用设备、城市基础设施、工厂机器、电力设施等，正在创建海量的时序数据。

现在更多的企业会通过时序存储和数据分析来获得预测能力和实时决策能力，从而为客户提供更好的使用体验。这意味着底层数据平台需要发展以应对新的工作负载的挑战，以及更多的数据点、数据源、监控维度、控制策略和精度更高的实时响应，对下一代时序中台提出了更高的要求，具体如下所示。

专为时序存储和高性能读写而设计：计算机虚拟世界的各种系统和应用，以及物理世界的IoT设备等都在创建海量的时序数据，每秒千万级的数据吞吐量是很常见的，而且这些数据还需要可以以非阻塞方式接收并且可压缩以节省有限的存储资源。
专为实时操作而设计：预测能力和实时决策能力，需要收到数据后，就能实时输出最新的数据分析结果，执行预定义的操作。
专为高可用性而设计：现代软件系统需要全天候可用，除了基本的集群能力，还需要根据需求自动扩容和缩容，支持柔性可用等。

InfluxData选择从头开始构建InfluxDB以支持下一代时序中台的需求，InfluxDB通过实现高度可扩展的数据接收和存储引擎，可以高效地实时收集、存储、查询、可视化显示和执行预定义操作。它通过连续查询提升查询效率和缩短延迟，通过数据保留策略，及时高效地删除过期冷数据，提升存储效率。

为什么通用数据库在时序场景上不是最优的选择呢？许多通用数据库正在为时序数据添加一些支持，虽然可能很容易使用，但它们基本上都不是针对海量时序数据的吞吐量和实时操作而设计的。

与InfluxDB相比，通用数据库，如Cassandra、MongoDB、HBase等，需要开发人员投入大量的时间进行代码编写，以开发与InfluxDB类似的功能。 具体来说，开发人员需要做如下工作：

编写代码实现跨集群数据分片功能、聚合运算和采样功能、数据生命周期管理功能等。
实现丰富的API接口。
编写用于数据采集的工具。
实现实时处理模块并编写用于监控和警报的代码。
编写可视化引擎以向用户显示时序数据。

为了让读者对InfluxDB的优势有个直观的认识，接下来，会把InfluxDB和其他被用作时序存储的系统（如ElasticSearch、MongoDB、OpenTSDB）做简要的对比：

1. InfluxDB vs ElasticSearch

ElasticSearch是专为搜索而设计的系统，是实现搜索功能的绝佳选择。

然而，对于时序数据，却并非如此。在处理时序数据时，InfluxDB的性能远远超过ElasticSearch系统，对于写入吞吐量，InfluxDB通常优于ElasticSearch 5～10倍，具体差值取决于架构。对于特定时序的查询速度，使用ElasticSearch比使用InfluxDB要慢5～100倍，具体差值取决于查询的时间范围。

最后，如果需要存储原始数据以便稍后查询，则ElasticSearch上的硬盘占用比InfluxDB大10～15倍。如果先汇总数据再存储，ElasticSearch的硬盘占用比InfluxDB大3～4倍。综合来看，ElasticSearch非常适合进行搜索，但不适用于时序存储和实时分析。

2. InfluxDB vs MongoDB

MongoDB是一个开源的、面向文档的数据库，俗称NoSQL数据库，用C和C ++语言编写。虽然它通常不被认为是真正的时序型数据库（TSDB），但它经常被用作时序存储系统。它以时间戳和分组的形式提供建模原语，使用户能够存储和查询时序数据。

MongoDB旨在存储“无模式”数据，其中每个对象可能具有不同的结构。实际上，MongoDB通常用于存储内容大小可变的JSON或BSON对象。由于其采用通用性和无模式数据存储区设计，MongoDB无法利用时序数据的高度结构化特性。

需要特别指出的是，时序数据由标签（键/值串对）和时间戳组成，这时必须对MongoDB做专门配置以支持时序数据，但这样做效率很低。

相比MongoDB，InfluxDB的性能和成本优势明显，InfluxDB的写性能大约是MongoDB的2.4倍，存储效率大约是MongoDB的20倍，查询效率大约是MongoDB的5.7倍。综合来看，MongoDB非常适合文档和自定义对象，但不适用于大规模的时序数据和实时分析。

3. InfluxDB vs OpenTSDB

OpenTSDB是一个可扩展的分布式时序型数据库，用Java语言编写，构建在HBase之上。它最初是由Benoît Sigoure于2010年开始编写的，并在LGPL下开源。

OpenTSDB不是一个独立的时序型数据库，相反，它依赖HBase作为其数据存储层，因此OpenTSDB时序守护进程（OpenTSDB中的TSD用语）在实例之间没有共享状态可以高效地提供查询引擎的功能。

OpenTSDB允许通过其API进行简单的聚合和数学运算，但没有完整的查询语言。OpenTSDB支持毫秒的分辨率，但随着亚毫秒级操作的普及，OpenTSDB有时会出现精度不足的问题。

相比OpenTSDB，InfluxDB的性能和成本优势明显，InfluxDB的写性能大约是OpenTSDB的5倍，存储效率大约是OpenTSDB的16.5倍，查询效率大约是OpenTSDB的3.65倍。

另外，OpenTSDB的设计初衷主要是用于生成仪表板图，不是为了满足任意查询，也不是为了存储数据。这些限制会影响它的使用方式。

03 InfluxDB的特性

作为一个开源系统，InfluxDB究竟有什么魅力吸引了如此多的用户，从而在时序型数据库DB-Engines Ranking上排名第一呢？

1. InfluxDB的特点

InfluxDB是支持时序数据高效读写、压缩存储、实时计算能力的数据库服务，除了具有成本优势的高性能读、高性能写、高存储率， InfluxDB还具有如下特点：

无系统环境依赖，部署方便。
无模式（schema-less）的数据模型，灵活强大。
原生HTTP管理接口，免插件配置和免第三方依赖。
强大的类SQL查询语句，学习成本低，上手快。
丰富的权限管理功能：精细到“表”级别。
丰富的时效管理功能：自动删除过期数据，自定义删除指标数据。
低成本存储，采样时序数据，压缩存储。
丰富的聚合函数，支持AVG、SUM、MAX、MIN等聚合函数。

2. 核心概念

InfluxDB实现了类SQL的接口，尽管与传统关系型数据库（如MySQL）语法相似，但InfluxDB在语义体系上有些差别，接下来将以一条CPU利用率的时序数据为例介绍相关的核心概念，如代码清单1-3所示。

代码清单1-3 一条CPU利率的时序数据

> insert cpu_usage,host=server01,location=cn-sz user=23.0,system=57.0
> select * from cpu_usage
name: cpu_usage
time             host     location system user
----             ----     -------- ------ ----
1557834774258860710 server01 cn-sz    55     25
>

时间（Time）：如代码清单1-3中的“1557834774258860710”，表示数据生成时的时间戳，与MySQL不同的是，在InfluxDB中，时间几乎可以看作主键的代名词。
表（Measurement）：如代码清单1-3中的“cpu_usage”，表示一组有关联的时序数据，类似于MySQL中表（Table）的概念。
标签（Tag）：如代码清单1-3中的“host=server01”和“location=cn-sz”，用于创建索引，提升查询性能，一般存放的是标示数据点来源的属性信息，在代码清单1-3中，host和location分别是表中的两个标签键，对应的标签值分别为server01和cn-sz。
指标（Field）：如代码清单1-3中的“user=23.0”和“system=57.0”，一般存放的是具体的时序数据，即随着时间戳的变化而变化的数据，与标签不同的是，未对指标数据创建索引，在代码清单1-3中，user和system分别是表中的两个指标键，对应的指标值分别为23.0和57.0。
时序数据记录（Point）：如代码清单1-3中的“1557834774258860710 server01 cn-sz 55 25”，表示一条具体的时序数据记录，由时序（Series）和时间戳（Timestamp）唯一标识，类似于MySQL中的一行记录。
保留策略（Retention Policy）：定义InfluxDB的数据保留时长和数据存储的副本数，通过设置合理的保存时间（Duration）和副本数（Replication），在提升数据存储可用性的同时，避免数据爆炸。
时间序列线（Series）：表示表名、保留策略、标签集都相同的一组数据。

关于作者：韩健，资深架构师，现就职于腾讯，担任监控大数据平台技术负责人，曾先后担任创业公司CTO、Intel资深工程师。既对分布式系统、InfluxDB的架构设计和开发有深刻的理解，又在海量服务分布式组件架构设计、高性能架构设计、高质量代码编写等方面有深厚的积累，经验丰富。

本文摘编自《InfluxDB原理与实战》，经出版方授权发布。

延伸阅读《InfluxDB原理与实战》

点击上图了解及购买

转载请联系微信：DoctorData

推荐语：InfluxDB技术专家基于DB-Engines排名TOP的时序数据库，打造千亿级大数据监控平台经验总结。包含9个企业级案例，100余示例，300余条命令和语法。

腾讯产品项目流程的七个阶段

Tue, 12 May 2020 00:00:00 CST

“腾讯”是产品经理的黄埔军校。笔者有幸学习到腾讯产品经理对产品项目的流程管理，特此整理并结合实际工作经验分享给大家。

长话短说，腾讯产品项目的主题流程划分成了七个阶段，“概念阶段（CONCEPT）”、“提案阶段（PROPOSAL）”、“原型开发阶段（PROTOTYPE）”、“产品开发阶段（ALPHA）”、“内测阶段（CLOSE BETA）”、“正式运营阶段（OPERATION）”和“结项（CLOSE）”.

一、概念阶段（CONCEPT）

概念阶段主要由“专家评审组”和“概念提出人”共同参与。

概念提示人负责【概念提出】，交由专家评审组进行【概念评审】和【存入概念库】操作。

二、提案阶段（PROPOSAL）

提案阶段主要由“决策委员会”、“专家评审组”、“项目组”和“研发”共同参与。

由决策委员会组织【成立提案小组】，项目组和研发负责【准备提案评审材料】，材料交由专家评审组进行【提案专家评审】，通过专家评审后交由决策委员会进行【提案决策评审】。

未通过评审则提案PASS；待修订则打回至【准备提案评审材料】步骤；通过评审则进入下一阶段。

众所周知的是，“提案阶段”类似“需求调研阶段”。日常工作中，对于需求调研咱们会分成三个部分“行业调研”、“市场调研”和“竞品调研”。

1. 行业调研

行业调研：行业分析是指根据经济学原理，综合应用统计学、计量经济学等分析工具对行业经济的运行状况、产品生产、销售、消费、技术、行业竞争力、市场竞争格局、行业政策等行业要素进行深入的分析，从而发现行业运行的内在经济规律，进而进一步预测未来行业发展的趋势。

政策！政策！政策！没有亘古不变的行业，要时刻拥抱变化，顺势而为，做该做的事。

2. 市场调研

市场调研：市场调研常用手法有“定性研究”、“定量研究”、“技术观察”和“试验设计”四种。

专业的事尽量交由专业的人去做，可以有效规避企业在市场调研上所承受的风险。转移市场调研的风险，在国内有诸多知名机构可以选择，具体如下。

China Ceidea Market Research 策点市场调研公司
Acorn Marketing & Research Consultants 毅群市场研究咨询股份有限公司
上海伊霍珀信息科技股份有限公司
北京新数易博（EBMRS）信息咨询有限公司
华通明略（MillwardBrown ACSR）信息咨询有限公司
中机系（北京）信息技术研究院
中国商业数据中心
尼尔森市场研究中心
数字100市场研究公司
益普索（中国）市场研究咨询有限公司
凯度（中国）购物者指数（Kantar Worldpanel China）
上海AC尼尔森市场研究公司
盖洛普（中国）咨询有限公司
华南国际市场研究公司
百维数元信息科技（北京）有限公司
艾斯艾（北京）市场调查有限公司（SSI China）
欧睿（Euromonitor）市场调查机构

2. 竞品调研

竞品调研：主要是对导入期竞争对手的市场经营情况与策略进行深入的调研分析。 ^[1]

竞品分析一词最早源于经济学领域。市场营销和战略管理方面的竞品分析是指对现有的或潜在的竞争产品的优势和劣势进行评价。这个分析提供了制定产品战略的依据，将竞品分析获得的相关竞品特征整合到有效的产品战略制定、实施、监控和调整的框架当中来。

竞品分析包含了三部分内容：竞品、分析维度和分析准则。

（1）竞品选择

竞品选择的范围并不局限于具有直接竞争关系的产品，以iPad版即时通讯应用为例，除了QQ、MSN等产品以外，我们还需要选择一些国外的产品如IM+、AIM、IMO等优秀且受众群体较大的产品。

（2）分析维度

通常我们进行竞品分析，可能会从以下几个维度进行对比分析：战略定位、盈利模式、用户群体、产品功能、产品界面（交互方式、视觉表现）等。

竞品分析是每一个互联网从业人员都需要做的一项基本工作，不同的职能区分，侧重点会不一样。如运营人员可能更加侧重产品的战略定位、盈利模式、推广方式，产品策划人员更侧重于产品定位、目标用户、产品功能。交互设计师更侧重于产品界面、具体的交互形式。当然这些维度是有机联系的，断然不可以孤立对待。

（3）分析准则

拿交互设计的竞品分析来说，需要参照“可用性准则”来进行分析，可用性准则有很多不同版本，当前较为常用的10项可用性准则为：

一致性和标准性
通过有效的反馈信息提供显著的系统状态
方便快捷的使用
预防出错
协助用户认识，分析和改正错误
识别而不是回忆
符合用户的真实世界
用户自由控制权
美观，精简的设计
帮助和说明

三、原型开发阶段（PROTOTYPE）

原型开发阶段主要由“决策委员会”、“专家评审组”、“项目组”和“研发”共同参与。

决策委员会负责【成立原型小组】，交由对应的项目组和研发进行【原型版本制作】，完成制作后，交由专家评审组进行【原型专家评审】，通过专家评审后，交由决策委员会进行【立项决策评审】。

评审期间，立项决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入立项流程。

“原型开发阶段”对应咱们日常工作中的“需求澄清”和“需求设计”。

1. 需求澄清

需求澄清：通过具体的方法论，澄清需求本身，消除项目参与人员对需求的认知差异。

关键步骤

（1）需求池（Demand pool）

需求池（Demand pool）需求池将需求列成合同式的文件，最常见的方式是将需求列入一个合同式的表。

（2）功能需求点列表(Function List)

功能需求点列表(Function List) 在功能需求分析完成后。要详细列出用户需求功能点列表。

（3）用例图（use case diagram）

用例图（use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

尽管用例本身会涉及大量细节和各种可能性，用例图却能提纲挈领地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示，因此被誉为“搭建系统的蓝图”。

由于其简单纯粹的本质，用例图是项目参与者间交流的好工具。用例图的画法是对现实世界的一种刻画，可以让项目参与者明白系统要做成什么样。箫庆龙等（Siau and Lee）曾研究是否存在用例图不适用或不必要的情景，结果发现用例图可以更简洁地传达系统的设计意图，“比类图诠释得更加完整”。

用例图的目的就是为了可以让人在一个更高的层次概览整个系统，用平白的话语让项目参与者理解系统。它可以辅以额外的图表和文档，以更加完整地展现系统的功能和技术细节。

（4）流程图（Flow Charts）

流程图（Flow Charts）是表示算法、工作流或流程的一种框图表示，它以不同类型的框代表不同种类的步骤，每两个步骤之间则以箭头连接。这种表示方法便于说明解决已知问题的方法。流程图在分析、设计、记录及操控许多领域的流程或程序都有广泛应用。

弄清楚用例图中的这些角色，在系统中每一步需要走什么流程，对应不同的判断状态进入怎样的子流程，是否支持逆向操作

（5）产品整体架构图

产品架构图暂无一个标准答案。这里我们借鉴软件架构的解释来参考：软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

图片来自CSDN社区-PMCAFF产品社区-一张图讲清楚产品架构

（6）产品信息结构图

产品信息架构图暂无一个标准答案。个人认为，产品信息结构图就是告诉研发有什么关键信息，同时给需求提出者自查的一份文档。

2. 需求设计

需求设计一般指的是设计是“原型文档”和“PRD文档”。

在日常的工作中，时间紧任务重的项目，通常在绘制原型图的时候，专门备注了对应的说明文档。这样做的目的是为了方便研发人员快速理解需求，跟上快速迭代的节奏。

四、产品开发阶段（ALPHA）

产品开发阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。

①决策委员会负责【成立项目组】，交由对应的项目组和研发进行【PRE-ALPHA版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再交由专家评审组进行【PRE-ALPHA专家评审】，通过专家评审后，交由决策委员会进行【PRE-ALPHA决策评审】，通过后交由运营准备【内部转产】。

②项目组和研发进行【ALPHA版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再自行安排【内测规划及准备】，下一步再交由专家评审组进行【产品内测上线专家评审】，通过专家评审后，交由决策委员会进行【P产品内测上线决策评审】。

③项目组和研发进行【总体运营规划】，交由专家评审组进行【总体运营规划专家评审】，通过专家评审后，交由决策委员会进行【总体运营规划决策评审】，通过后研发和运营准备【封测上线发布】并收集【封测运营反馈】，用于矫正项目组和研发进行【ALPHA版本制作】。

评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入内测阶段。

五、内测阶段（CLOSE BETA）

内测阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。

①项目组和研发进行【版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再自行安排【正式运营规划及准备】，下一步再交由专家评审组进行【正式运营上线专家评审】，通过专家评审后，交由决策委员会进行【正式运营上线决策评审】。

②运营负责【产品内测上线发布】、【内测运营服务】以及【内测运营反馈】。交由对应的项目组和研发佐证【版本制作】，通过后交由研发和项目组负责【正式运营规划及准备】。

评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入正式运营阶段。

六、正式运营阶段（OPERATION）

正式运营阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。

①项目组和研发进行【版本制作】，完成制作后，先自行进行【小版本评审】，再交由运营负责【正式运营上线发布】、【正式运营服务】以及【正式运营反馈】如有问题自行修订，再交由项目组和研发安排【运营结项计划和准备】，下一步再交由专家评审组进行【正式运营结束专家评审】，通过专家评审后，交由决策委员会进行【正式运营结束决策评审】，通过后交由运营负责【正式运营结项准备】，准备进入结项阶段。

②在【小版本评审】通过后，交由专家评审组进行【大版本评审】，通过后交由研发和项目组进行【版本制作】。

评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入正式运营阶段。

七、结项（CLOSE）

结项阶段主要由“运营”负责。

确认项目进入结项阶段后，交由运营负责【产品下线】，OVER。

结项是一个项目的尾声，难免有种飞鸟尽良弓藏的感觉，这是正常的。

一方面，有“柯达”这样相当优秀的企业，带着遗憾离场，他没做错啥，只是不被大家所需要。

另一方面，正是有数不清的产品被干掉，咱们产品的存在才被衬托得更有意义。那为什么不去拥抱变化，选择去创造更能经得住时间检验的产品！

尾记

产品经理他可以是一个改变世界的神，他也可以是一个普通人。

普通的人，专注好眼下的一件事，那他就是最棒的产品经理。你也可以，谢谢支持，共勉~

作者：木深；公众号：异世治人录

本文由@木深原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

腾讯云中间件团队在 Service Mesh 中的实践与探索

Fri, 08 May 2020 00:00:00 CST

【编者的话】Service Mesh 作为腾讯微服务平台（TSF）支持的微服务架构之一，产品化命名为 Mesh 微服务平台（Tencent Service Mesh Framework，简称 TSF Mesh），提供下一代微服务架构 - 服务网格（Service Mesh）的解决方案，覆盖公有云、私有云和本地化部署等多种场景。从 2018 年 8 月推出首个版本以来，已经陆续在金融、新零售、工业互联网，以及公司内部等生产环境落地。在产品落地过程中，遇到了一系列技术挑战，如非 Kubernetes 环境的支持、多租户隔离、与 Spring Cloud 服务框架的互通、海量服务实例下的域名解析等等。针对这些问题，通过自研以及社区合作，最终得以解决。本文主要从用户场景出发，以生产实践探索过程中遇到的挑战为切入点，梳理和总结应对的解决方案，以期望对 Service Mesh 的认识、对 TSF Mesh 产品的了解有所帮助。

背景介绍

什么是 Service Mesh？根据 Buoyant CEO，Service Mesh 理念的提出者和先行者，William Morgan 定义，Service Mesh（服务网格）是一个专注于处理服务间通信的基础设施层。用于解决服务间复杂拓扑中的可靠请求传递，是云原生技术栈的关键组件之一。

2018 年被很多人称为 “Service Mesh 之年”，这一年，业界几乎所有大厂都在尝试推出自己的 Service Mesh 产品。Service Mesh 中的明星项目 Istio 在这一年也是蓄势待发，作为 Google、IBM、Lyft 联合开发的开源项目，陆续发布了0.5、0.6、0.7、0.8 和 1.0 版本，到 2018 年 7 月 31日 1.0 GA 时，对 Istio 来说是一个重要的里程碑，官方宣称所有的核心功能都可以用于生产。

以 GitHub 上的 star 数量的角度来看一下 Istio 在近几年的受欢迎程度，下图显示的是 Istio 的 GitHub star 数量随时间变化曲线。可以看到在 2018 年，Istio 的 star 数量大概增长了一万，目前已经超过 2.2万颗星，其增长趋势也非常平稳。

早在 2017 年，腾讯云中间件团队就选定 Istio 为技术路线，开始 Service Mesh 的相关预研和研发工作。作为腾讯微服务平台（TSF）的无侵入式微服务框架的核心实现，于 18 年初在腾讯广告平台投入，打磨稳定后，陆续开始对外输出，目前在金融、工业互联网等领域都有落地案例。

产品落地过程并非一帆风顺，会遇到一些问题和挑战。接下来，首先以开源 Istio 为切入点，介绍一下 TSF Mesh，之后对 TSF Mesh 产品化探索过程中的部分典型问题以及解决方案进行梳理和分享。

TSF Mesh介绍

Mesh 微服务平台（Tencent Service Mesh Framework，简称 TSF Mesh），基于 Service Mesh 的理念，为应用提供服务自动注册与发现、服务路由、鉴权、限流、熔断等服务治理能力，且应用无需对源代码进行侵入式改造，即可与该服务框架进行集成。

在开发选型上，基于业界达到商用标准的开源软件 Istio 进行构建，主要原因如下：

Istio 功能相对完备，mesh 该有的能力都有。
社区活跃，资源丰富，CNCF 成员，代表云原生标准化。
Golang（Istio）& C++ 14（Envoy）都是高性能语言，且运行起来资源使用灵活，独立性好，无 JVM 等外部依赖。

在了解 TSF Mesh 架构之前，先回顾一下 Istio 的架构图，如下图所示：

在上面的架构图中，Istio Mesh 分为两块：数据面板和控制面板。Envoy 在 Istio 中扮演数据面板的角色，作为服务的代理，被部署为 Sidecar，服务无需感知 Envoy 的存在；控制面板包含 Pilot，Mixer，Citadel 等组件。这些组件的主要功能如下：

Envoy：作为底层的代理，通常选用其扩展版本 istio-proxy，用于调度服务网格中所有服务的出入站流量。包含了丰富的内置功能，例如动态服务发现，负载均衡，HTTP/2&gRPC 代理，熔断器，健康检查，基于百分比流量拆分的灰度发布，故障注入，性能指标等。
Pilot：控制面的核心组件，为 Envoy 提供服务发现、智能路由（如 AB 测试、灰度发布）和弹性流量管理功能（如超时、重试、熔断），负责将高层的抽象的路由规则转化成低级的 Envoy 的配置。
Mixer：提供策略检查和遥测功能。
Citadel：安全组件，提供了自动生成、分发、轮换与撤销密钥和证书功能。

TSF Mesh 整体架构上，其核心能力与开源的 Istio 保持一致，同时对 Envoy、Pilot、Mixer、Pilot-Agent 组件做了增强，并且新增组件 Apiserver 和 Mesh-DNS。外围能力聚焦在安全性、易用性、可维护性和可观测性，如下图所示：

运营支撑提供了运营端管理和租户端管理，比如租户端的角色管理，集群管理，命名空间管理，应用管理，服务治理等；运营端提供资源管理等。监控系统提供了日志功能，链路追踪，调用链拓扑图，指标监控等。基础组件为限流、注册中心、配置中心、日志采集和实时监控提供支撑。Paas为应用部署提供支撑，比如 aPaaS等。

TSF Mesh 保留 Istio 所有的原生特性，同时对 Service Mesh 叠加了部分商业特性，如下：

平台解耦：支持 Kubernetes/VM/裸金属服务器环境
新旧兼容：支持 Spring Cloud 应用、Service Mesh 应用互通，统一治理
多租户隔离、管理支持
调用链、日志、监控落盘
高可用性

TSF Mesh 产品化挑战

支持异构的计算平台

尽管 Istio 强调自身可扩展性的重要性在于适配各种不同的平台，也可以对接其他服务发现机制，但在实际场景中，通过深入分析 Istio 几个版本的代码和设计，可以发现其重要的能力都是基于 Kubernetes 进行构建的。以下面两点为例：

服务配置管理

Istio 的所有路由规则和控制策略都是通过 Kubernetes CRD 实现，可以说 Istio 的 APIServer 就是 Kubernetes 的 APIServer，数据也自然地被存在了对应 Kubernetes 的 etcd 中。如下图所示：

服务发现及健康检查

Istio 的服务发现机制基于 Kubernetes 的 Services/Endpoints，从 Kube-apiserver 中获取 Service 和 Endpoint，然后将其转换成 Istio 服务模型的 Service 和 ServiceInstance。同时 Istio 不提供域名解析能力，域名访问机制也依赖于 kube-dns，CoreDNS 等构建。节点健康检查能力基于 LivenessProbe/ReadinessProbe 机制实现。

在实际场景中，TSF 的用户并非都是 Kubernetes 用户，例如公司内部的一个业务因历史遗留问题，不能完全容器化改造，同时存在 VM 和容器环境，场景如下：

从上面的业务场景可以看出，业务要求能够将其部署在自研 PaaS 以及 Kubernetes 的容器、虚拟机以及裸金属的服务都可以通过 Service Mesh 进行相互访问。

为了实现多平台的部署，必须与 Kubernetes 进行解耦。在脱离 Kubernetes 后，Istio 面临以下四个问题：

服务的动态配置管理不可用
服务节点健康检查不可用
服务自动注册与反注册能力不可用
流量劫持不可用

针对这 4 个问题，TSF Mesh 团队对 Istio 的能力进行了扩展和增强，增强后的架构如下：

增强 Pilot 的 Consul 适配器，与 Consul 注册中心对接；增加 Apiserver 实现元数据转换；增强 Pilot-Agent，实现VM的自动注入，服务注册，Envoy 管理。经过改造后，Service Mesh 成功与 Kubernetes 平台解耦，组网变得更加简洁，通过 GRPC 和 REST API 可以对数据面进行全方位的控制，可从容适配任何的底层部署环境，对于私有云客户可以提供更好的体验。

支持多租户

租户的概念不止局限于集群的用户，它可以包含为一组计算，网络，存储等资源组成的工作负载集合。而在多租户场景中，需要对不同的租户提供尽可能的安全隔离，以最大程度的避免恶意租户对其他租户的攻击，同时需要保证租户之间公平地分配共享集群资源。

在公有云或私有云场景下，用户对隐私和隔离看得非常重要。往往不同用户/租户之间，服务配置、节点信息、控制信息等资源数据是隔离的，互相不可见。但是 Istio 本身并不支持这种级别的隔，需要框架集成者去扩展。

Istio 依托于 kubernetes 能力，可实现 “soft-multitenancy”，即单一 Kubernetes 控制平面和多个 Istio 控制平面以及多个服务网格相结合；每个租户都有自己的一个控制平面和一个服务网格。

其它租户模式，比如单独的 Istio 控制平面控制多集群网格的场景，Istio 并不支持。在这种场景下，每个租户一个网格，集群管理员控制和监控整个 Istio 控制面以及所有网格，租户管理员只能控制特定的网格。这种场景与云环境下的多租户概念比较稳合，对此 TSF Mesh 通过数据建模，实现了这种租户模式，即单控制面多集群网格。基本架构如下图所示：

在上图中，实现了租户管理、租户数据的隔离存储、Pilot 控制面缓存增加租户索引。在这种场景下，各租户只能看到自身的集群资源，包括计算资源、逻辑资源、应用资源等，其它租户创建的集群资源不可见，Sidecar 只能从控制端同步到本租户的配置和服务 xDS 信息。

服务寻址

在侵入式框架下，目标服务的标识通常是服务名，服务注册与发现是强关联的，通过服务发现机制实现服务名到服务实例的寻址。在 Service Mesh 机制下，对应用是无侵入的，服务发现机制只能下沉到 Service Mesh，这意味着客户端通过目标服务标识名称的访问方式，需要域名解析能力的支持。

Istio 下的应用使用完全限定域名 FQDN（fully qualified domain name）进行相互调用，基于 FQDN 的寻址依赖 DNS 服务器，Istio 官方对 DNS 服务器的说明如下：

Istio does not provide a DNS. Applications can try to resolve the FQDN using the DNS service present in the underlying platform (kube-dns, mesos-dns, etc.).

从上面的描述看出，Istio 并不提供 DNS 的能力，依托于平台的能力，如 Kubernetes 平台下的 kube-dns 。以 Istio 的官方提供的demo：bookinfo 为例，Reviews 与 Ratings 之间的完整的服务调用会经过以下过程：

从图上可以看出，Reviews 和 Ratings 的互通，kube-dns 主要实现 2 个功能：

服务的 DNS 请求被 kube-dns 接管
kube-dns 将服务名解析成可被 iptables 接管的虚拟 IP（clusterIP）

正如前面提到的，用户的生产环境不一定包含 kubernetes 或者 kube-dns，我们需要另外寻找一种机制来实现上面的两个功能。

在 DNS 选型上，有集中式和分布式两种方案，集中式 DNS：代表有 kube-dns，CoreDNS 等，通过内置或者插件的方式，实现与服务注册中心进行数据同步。

集中式 DNS 存在以下问题：组网中额外增加一套 DNS 集群，并且一旦 DNS Server 集群不可用，所有数据面节点在 DNS 缓存失效后都无法工作，因此需要为 DNS Server 考虑高可用甚至容灾等一系列后续需求，会导致后期运维成本增加。

分布式 DNS 将服务 DNS 的能力下沉到数据平面。分布式 DNS 运行在数据面节点上，DNS 无单点故障，无需考虑集群容灾等问题，只需要有机制可以重新拉起即可。由于与业务进程运行在同一节点，因此其资源占用率必须控制得足够低，才不会对业务进程产生影响。

综合考虑，最终 TSF Mesh 选用了分布式 DNS 的方案，以独立进程作为 DNS Server，如下图所示：

图中 Mesh-DNS 通过 Pilot 同步服务信息，当应用通过服务名调用时，会进入 Mesh-dns 进行域名的本地解析，然后流量被 iptables 接管，之后到达 Envoy，最后由 Envoy 动态路由到 upstream；对于其它非 Mesh 服务的域名解析，Mesh-DNS 会透明传输，走默认的 DNS。通过配置缓存本地化以及异常退出后自动拉起并加载配置，保证在异常情况下的高可用。

值得一提的是 Istio 暴力流量接管问题，这个也是大家诟病比较多的。由于 Istio 的数据面针对 Kubernetes 容器内流量进行全接管，但是对于虚拟机或裸金属场景可能不适用，毕竟虚拟机或裸金属上可能不仅仅只有 Mesh 的服务。因此，需要考虑细粒度的接管方案，使得 Mesh 与非 Mesh 应用在同一个虚拟机/容器中可以共存。TSF Mesh 对这块能力也做了增强，只需要少量的 iptables 规则，即可完成 Mesh 与非 Mesh 流量的筛选。

与异构服务框架互通

微服务框架可以分为侵入式和非侵入式两种，目前比较主流的微服务框架 Spring Cloud，基于 Spring Boot 开发，提供一套完整的微服务解决方案，包括服务注册与发现，配置中心，全链路监控，API网关，熔断器，远程调用等开源组件，并且可以根据需求对部分组件进行扩展和替换。与 Service Mesh 之处不同在于，Spring Cloud 是一种侵入式的微服务框架，需要 SDK 支撑，并且技术栈受限于 Java。

出于功能重叠、语言壁垒、耦合性，开发运维成本，技术门槛，云原生生态等多方面的因素，有相当一部分用户开始尝试 Service Mesh，或者往 Service Mesh 迁移和转型，但仍然存在一些遗留的 Spring Cloud 的服务，希望能与 Service Mesh 中的服务互通。用户期望支持的架构如下图所示：

在上面这个架构中，最大的挑战在于涉及了两个不同的微服务框架之间的互通。这两个微服务框架从架构模式、概念模型、功能逻辑，技术栈上，都存在较大的差异。唯一相共的点，就是他们都是微服务框架，可以将应用的能力通过服务的形式提供出来，给外部用户调用，外部用户实际上并不感知服务的具体形态。

基于这个共同点，为了使得不同框架下的服务能够正常工作，TSF 团队做了大量的开发工作，将两个微服务框架，从部署模式、服务及功能模型上进行了拉通，主要包括如下几点：

可观测性

在上一小节，提到了 Service Mesh 与 Spring Cloud 的能力互通，TSF Mesh 为了提供更好的用户体验，在日志、监控和调用链方面的能力也与 Spring Cloud 拉通，在 Envoy 标准 Tracers 能力（envoy.zipkin）的基础上，增加了envoy.local 类型，使其支持监控和调用链日志落到本地挂载盘，由 TSF 的 APM 系统采集并分析，实现 Mesh 应用与 Spring 应用的调用链串接。

如下图展示了两种不同微服务架构下，一致的服务依赖拓扑能力。user、shop、promotion 为 Service Mesh 应用，provider-demo 为 Spring Cloud 应用，服务间的箭头表示了调用关系。

总结与展望

TSF Mesh 作为腾讯微服务平台 TSF 的 Service Mesh 解决方案，在持续交付中，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。本文主要从用户实际场景出发，挑选了 TSF Mesh 产品化过程中遇到的部分典型问题和应对的解决方案，进行梳理和介绍，希望对 TSF Mesh 产品的了解以及技术演进思路有所帮助。还有一些问题和解决办法，涉及较深的技术细节，或显枯燥，并未一一罗列，比如性能优化相关，Mixer 相关，自定义协议相关，部署相关等等。

TSF Mesh 团队拥抱开源协同，努力跟进 Service Mesh 的技术发展趋势，积极参与社区贡献。就技术发展趋势，有些点仍值得后续探讨，比如控制面单体化，UDPA（通用数据平面API）的标准化演进，wasm 在 envoy 中扮演的角色，mixer 下沉，协议扩展，性能优化等等。

回顾过去，从 "Service Mesh" 和 "Istio" 这两个词汇第一次进入公众视野到如今，有将近四年的时间，见证了数据面板的争奇斗艳，也亲历了 xDS 的“快速”演变，架构与性能之间的妥协也从未停歇。总之，一句话：流年笑掷，未来可期。

原文链接： https://mp.weixin.qq.com/s/20UJMs4U5YEUfxV6dS3oJg

IT瘾腾讯推荐

腾讯向逾 30 个 GitHub 微信相关项目发出 DMCA 通知

腾讯、苹果客服回应微信或不再支持iPhone 16

腾讯蓝鲸基座实现原理（基于amd，iframe的微前端方案）

theme: vue-pro

前言

知识储备

基座原理

基座模板做了什么？

(1)

(2)

(3)

总结

基座如何加载子应用？

（1）

（2）

（3）

总结

如何实现iframe类型的子系统路由同步及与基座间的交互？

（1）

（2）

（3）

总结

总结

腾讯开源的Markdown编辑器，开箱即用、轻量简洁、易扩展

工作十年，在腾讯沉淀的高可用系统架构设计经验

01、高可用系统的架构设计思想

1.1 可用性和高可用概念

2.2 高可用系统设计思想

02、 研发规范层面

2.1 方案设计和编码规范

2.2 容量规划和评估

2.3 QPS 预估（漏斗型）

03、应用服务层面

3.1 无状态和负载均衡设计

3.2 弹性扩缩容设计

3.3 异步解耦和削峰设计（消息队列）

3.4 故障和容错设计

3.5 过载保护设计（限流、熔断、降级）

04、存储层面

4.1 集群存储（集中式存储）

4.2 分布式存储

05

06、 运维部署层面

6.1 开发阶段-灰度发布、接口测试设计

6.2 开发阶段-监控告警设计

6.3 开发阶段-安全性、防攻击设计

6.4 部署阶段-多机房部署（容灾设计）

6.5 线上运行阶段-故障演练（混沌实验）

6.6 线上运行阶段-接口拨测系列设计

07、异常应急层面

腾讯内部数据治理实践

腾讯孙驰天：游戏科技让数字孪生创造更大生产力

01

02

是什么力量，让阿里云腾讯云和火山引擎走到了一起

01 泛视频时代，需要怎样的直播技术

02 从「中台」到「To B」，从「能力」到「体验」

03 体验优化的四个维度

腾讯音乐知识图谱搜索实践

腾讯应届生怒怼管理层 腾讯高管：认真反思，尽快整改

马化腾：腾讯只是一家普通公司 随时都可以被替换

消息称，腾讯和字节的内容即将向搜索开放，百度或成最大赢家？

腾讯看点基于 Flink 构建万亿数据量下的实时数仓及实时查询系统

2. 开发前调研

■ 2.1 离线数据分析平台能否满足这些需求

■ 2.2 准实时数据分析平台

3. 腾讯看点信息流的业务流程

2. 系统架构设计

■ 2.1 实时计算

■ 2.2 实时存储

■ 2.3 后台服务

■ 2.4 前端服务

3. 方案选型

■ 3.1 实时数仓的选型

■ 3.2 实 时计算引擎的 选型

■ 3.3 实时存储引擎

1. 如何构建实时数仓

■ 1.1数据清洗

■ 1.2 高性能维表关联

02、研发规范层面

06、运维部署层面

腾讯应届生怒怼管理层腾讯高管：认真反思，尽快整改

马化腾：腾讯只是一家普通公司随时都可以被替换

■ 3.2 实时计算引擎的选型

■ 1.3 不同粒度聚合