公司​

• 总共成立四年，前两年都在写代码，最近一年半有一两百家企业在用
• Infra 在中国做很有优势，因为中国市场大，公司快糙猛拿来主义，infra 的好东西能够很快地被用上
• cofounders 里面没有 db 的经验
• open source 模式是未来，如果是闭源只能一家一家谈
• 最重要的商业决策：不在于算法有多nb 团队有多厉害，护城河的关键在于 1）社区 2）mysql 接口 (借用了 mysql 的社区开始，SQL 的支持很重要，比如连Kafka, Spark都支持 SQL)

TiDB 数据库原理​

• 越nb的工程师越喜欢高性能，认为越快越好。但是 TiDB 的首要目标不是做到最快，而是做到 Availability reliability 稳定性 IO和 无限扩展。高性能的成本太高，要根据用户的硬件优化。但是这里是通用的数据库，不可能去优化各种场景。简单留给用户，复杂留给自己（跟AWS意见相反）。
• 认为 eventual consistency 是个伪概念，实际上就是没一致性或者弱一致性。比如 cassandra WRN 设置好了，但到底过多久 能够resolve？不确定。太复杂，用户最好不需要知道操心这些复杂的设置。
• 跑分不是唯一的指标，TPCC/TPCH 分数高对实际没有太多指导意义。数据库是磨出来的。比如第一家客户，游戏公司，居然创建了3万张表，json 的 meta 信息连起来非常慢。
• 构架上不是 P2P，而是不同角色分得很清楚。
• KV 用的是 RocksDB 但是典型的 LSM tree 的写放大是15倍，这里优化到 value 拆出来，解决写放大的问题。
• 支持 MySQL 的client，也支持 SparkSQL 的读。
• SQL layer 没有用 MySQL 的模块。一开始有试过，但是1）下面很难分布式 2）代码太烂很难改。魔改的话，半年能做；但是长期的维护成本更高。重做不麻烦，都重构了三次了。这里用 Go 比用 C/C++/Rust 重构更方便。
• 一开始只想做 F1只做sql，和 CockroachDB 合作，后来他们往sql这边做，这边就只能往storage 做
• 挖了 Rust core team 的两个人。rust 很难招人，一般是招 C++的人然后转rust，他们会觉得很多脑袋里的约定编译器帮你搞定了。
• 不要低估造工业级轮子的难度。用 grpc，raft，rocksdb的好处是，如果业界有新的进展，会直接让使用者收益。
• Chunk (region) split 做了两个月，merge 做了三年。merge 做了形式化证明。

Tech 趋势​

• 为什么是现在？
  • hardware
  • Hot / cold data -> warm data
  • Log is the new database
• Everything is pluggable, 顶层 api 不变，下面即插即用可替换
• Distributed Transaction
  • 2PC is the only option
  • challenges: reduce round-trips
• Multi-tenancy achieved by kubernetes

中国 Biz Trend​

1. 中国速度，说上就得上
2. 对新技术服务赋能业务的期望更高。二三线城市的公司或者非BAT用新技术与巨头斗争。必须能够解决使用者的技术焦虑。
3. 基础软件人才储备逐渐变强。P产能CAP 对技术 content marketing 做了很多贡献。
4. 一些核心场景（银行核心系统）敢于使用国产技术。
5. PingCAP路径：开源（互联网/社区） <-> 商业化

为什么有这种框架？​

• 为了在更短的时间内处理更多的数据。
• 统一处理分布式系统中的容错问题。
• 将任务简化抽象以应对多变的业务要求。
• 分别适用于有界数据集（批处理）和无界数据集（流处理）。

批处理与流处理的发展史简介​

1. Hadoop 与 MapReduce。谷歌让批处理在一个分布式系统中像 MapRduceresult = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)一样简单。
2. Apache Storm 与有向图拓扑结构。MapReduce 不能很好地表示迭代算法。因此，内森·马兹（Nathan Marz）将流处理抽象成一个由 spouts 和 bolts 组件构成的图结构。
3. Spark 内存计算。辛湜（Reynold Xin）指出 Spark 在处理相同数据的时候比 Hadoop 少使用十倍机器的同时速度却快三倍
4. 基于 Millwheel 和 FlumeJava 的谷歌数据流（Google Dataflow）。谷歌使用窗口化API同时支持批处理与流处理。

等等...那么为什么 Flink 变得如此热门？​

1. Flink 快速采纳了 ==Google Dataflow== 以及 Apache Beam 的编程模式。
2. Flink 对 Chandy-Lamport checkpointing 算法的高效实现。

这些框架​

架构选择​

若要用商业机器来满足以上的需求，有这些热门的分布式系统架构……

• master-slave（中心化的）：Apache Storm + zookeeper， Apache Samza + YARN
• P2P（去中心化的）：Apache s4

功能​

1. DAG Topology 用来迭代处理 -例如Spark 中的 GraphX， Apache Storm 中的 topologies， Flink 中的 DataStream API。
2. 交付保证 (Delivery Guarantees)。如何确保节点与节点之间数据交付的可靠性？至少一次 / 至多一次 / 一次。
3. 容错性。使用cold/warm/hot standby, checkpointing 或者 active-active 来实现容错。
4. 无界数据集的窗口化API。例如 Apache 的流式窗口。Spark 的Window函数。Apache Beam 的窗口化。

不同架构的区别对照表​

我们优化的目标是什么？用户满意度​

我们正在寻找以下最佳 function 以最大化 用户满意度 。

用户满意度 = function(内容, 用户资料, 上下文)

1. 内容：文章、视频、用户生成内容短视频、问答等的特征。
2. 用户资料：兴趣、职业、年龄、性别和行为模式等。
3. 上下文：在工作空间、通勤、旅行等情况下的移动用户。

如何评估满意度？​

1. 可测量的目标，例如：

   • 点击率
   • 会话持续时间
   • 点赞
   • 评论
   • 转发

2. 难以测量的目标：

   • 广告和特殊类型内容（问答）的频率控制
   • 低俗内容的频率控制
   • 减少点击诱饵、低质量、恶心内容
   • 强制/置顶/高度权重重要新闻
   • 低权重来自低级账户的内容

如何优化这些目标？机器学习模型​

找到上述最佳 function 是一个典型的监督机器学习问题。为了实施该系统，我们有以下算法：

1. 协同过滤
2. 逻辑回归
3. 深度神经网络
4. 因子分解机
5. GBDT

一个世界级的推荐系统应该具备 灵活性，以进行 A/B 测试并结合上述多种算法。现在结合逻辑回归和深度神经网络变得流行。几年前，Facebook 使用了逻辑回归和 GBDT。

模型如何观察和测量现实？特征工程​

1. 内容特征与用户兴趣之间的相关性。 显式相关性包括关键词、类别、来源、类型。隐式相关性可以从 FM 等模型的用户向量或项目向量中提取。

2. 环境特征，如地理位置、时间。 可以用作偏见或在其基础上建立相关性。

3. 热门趋势。 有全球热门趋势、类别热门趋势、主题热门趋势和关键词热门趋势。热门趋势在我们对用户信息较少时非常有助于解决冷启动问题。

4. 协同特征，帮助避免推荐内容越来越集中。 协同过滤不是单独分析每个用户的历史，而是根据用户的点击、兴趣、主题、关键词或隐式向量找到用户的相似性。通过找到相似用户，可以扩展推荐内容的多样性。

实时大规模训练​

• 用户喜欢看到根据我们从他们的行为中跟踪到的内容实时更新的新闻源。
• 使用 Apache Storm 实时训练数据（点击、展示、收藏、分享）。
• 收集数据到达阈值后更新推荐模型
• 在高性能计算集群中存储模型参数，如数十亿的原始特征和数十亿的向量特征。

它们的实现步骤如下：

1. 在线服务实时记录特征。
2. 将数据写入 Kafka
3. 从 Kafka 向 Storm 导入数据
4. 填充完整的用户资料并准备样本
5. 根据最新样本更新模型参数
6. 在线建模获得新知识

如何进一步减少延迟？召回策略​

考虑到所有内容的超大规模，无法用模型预测所有事情。因此，我们需要召回策略来关注数据的代表性子集。性能在这里至关重要，超时时间为 50 毫秒。

在所有召回策略中，我们采用 InvertedIndex<Key, List<Article>> 。

Key 可以是主题、实体、来源等。

数据依赖​

• 特征依赖于用户端和内容端的标签。
• 召回策略依赖于用户端和内容端的标签。
• 用户标签的内容分析和数据挖掘是推荐系统的基石。

什么是内容分析？​

内容分析 = 从原始文章和用户行为中推导中间数据。

以文章为例。为了建模用户兴趣，我们需要对内容和文章进行标记。为了将用户与“互联网”标签的兴趣关联起来，我们需要知道用户是否阅读了带有“互联网”标签的文章。

我们为什么要分析这些原始数据？​

我们这样做的原因是 …

1. 标记用户（用户资料）
   • 标记喜欢带有“互联网”标签的文章的用户。标记喜欢带有“小米”标签的文章的用户。
2. 通过标签向用户推荐内容
   • 向带有“小米”标签的用户推送“小米”内容。向带有“Dota”标签的用户推送“Dota”内容。
3. 按主题准备内容
   • 将“德甲”文章放入“德甲主题”。将“饮食”文章放入“饮食主题”。

案例研究：一篇文章的分析结果​

这是“文章特征”页面的示例。文章特征包括分类、关键词、主题、实体。

文章特征是什么？

1. 语义标签：人类预定义这些标签并赋予明确的含义。

2. 隐式语义，包括主题和关键词。主题特征描述了单词的统计信息。某些规则生成关键词。

3. 相似性。重复推荐曾是我们客户反馈中最严重的问题。

4. 时间和地点。

5. 质量。滥用、色情、广告或“心灵鸡汤”？

文章特征的重要性​

• 推荐系统并非完全无法在没有文章特征的情况下工作。亚马逊、沃尔玛、Netflix 可以通过协同过滤进行推荐。
• 然而，在新闻产品中，用户消费的是同一天的内容。没有文章特征的引导是困难的。协同过滤无法帮助引导。
  • 文章特征的粒度越细，启动的能力越强。

更多关于语义标签​

我们将语义标签的特征分为三个层次：

1. 分类：用于用户资料、过滤主题内容、推荐召回、推荐特征
2. 概念：用于过滤主题内容、搜索标签、推荐召回（喜欢）
3. 实体：用于过滤主题内容、搜索标签、推荐召回（喜欢）

为什么要分为不同层次？我们这样做是为了能够以不同的粒度捕捉文章。

1. 分类：覆盖全面，准确性低。
2. 概念：覆盖中等，准确性中等。
3. 实体：覆盖低，准确性高。它仅覆盖每个领域的热门人物、组织、产品。

分类和概念共享相同的技术基础设施。

我们为什么需要语义标签？

• 隐式语义
  • 一直运作良好。
  • 成本远低于语义标签。
• 但是，主题和兴趣需要一个明确的标记系统。
• 语义标签还评估了公司在 NPL 技术方面的能力。

文档分类​

分类层次结构

1. 根
2. 科学、体育、金融、娱乐
3. 足球、网球、乒乓球、田径、游泳
4. 国际、国内
5. A 队、B 队

分类器：

• SVM
• SVM + CNN
• SVM + CNN + RNN

计算相关性​

1. 对文章进行词汇分析
2. 过滤关键词
3. 消歧义
4. 计算相关性

我们优化的目标是什么？用户满意度​

我们正在寻找以下最佳 函数 以最大化 用户满意度 。

用户满意度 = 函数(内容, 用户画像, 上下文)

1. 内容：文章、视频、用户生成内容短视频、问答等的特征。
2. 用户画像：兴趣、职业、年龄、性别和行为模式等。
3. 上下文：工作空间、通勤、旅行等场景下的移动用户。

如何评估满意度？​

1. 可测量的目标，例如：

   • 点击率
   • 会话时长
   • 点赞
   • 评论
   • 转发

2. 难以测量的目标：

   • 广告和特殊类型内容（问答）的频率控制
   • 低俗内容的频率控制
   • 减少点击诱饵、低质量、恶心内容
   • 强制/固定/高度权重重要新闻
   • 低权重来自低级账户的内容

如何优化这些目标？机器学习模型​

寻找上述最佳 函数 是一个典型的监督机器学习问题。为了实现系统，我们有以下算法：

1. 协同过滤
2. 逻辑回归
3. 深度神经网络
4. 因子分解机
5. GBDT

一个世界级的推荐系统应该具备 灵活性，能够进行 A/B 测试并结合上述多种算法。现在结合逻辑回归和深度神经网络的做法越来越流行。Facebook 多年前就同时使用了逻辑回归和 GBDT。

模型如何观察和测量现实？特征工程​

1. 内容特征与用户兴趣之间的相关性。 显性相关性包括关键词、类别、来源、类型。隐性相关性可以从用户向量或模型如因子分解机中的物品向量中提取。

2. 环境特征，如地理位置、时间。 可以作为偏差或在其基础上建立相关性。

3. 热门趋势。 有全球热门趋势、类别热门趋势、主题热门趋势和关键词热门趋势。热门趋势在我们对用户信息较少时非常有助于解决冷启动问题。

4. 协同特征，有助于避免推荐内容越来越集中。 协同过滤不是单独分析每个用户的历史，而是根据用户的点击、兴趣、主题、关键词或隐性向量找到用户之间的相似性。通过找到相似用户，可以扩展推荐内容的多样性。

大规模实时训练​

• 用户喜欢看到根据我们从他们的行为中跟踪到的信息实时更新的新闻推送。
• 使用 Apache Storm 实时训练数据（点击、展示、收藏、分享）。
• 收集数据直到达到阈值，然后更新推荐模型
• 在高性能计算集群中存储模型参数，如数百亿的原始特征和数十亿的向量特征。

它们的实现步骤如下：

1. 在线服务实时记录特征。
2. 将数据写入 Kafka
3. 从 Kafka 向 Storm 进件数据
4. 填充完整的用户画像并准备样本
5. 根据最新样本更新模型参数
6. 在线建模获得新知识

如何进一步减少延迟？召回策略​

考虑到所有内容的超大规模，无法用模型预测所有事情。因此，我们需要召回策略来关注数据的代表性子集。性能在这里至关重要，超时为 50 毫秒。

在所有召回策略中，我们采用 反向索引<Key, List<Article>>。

Key 可以是主题、实体、来源等。

数据依赖​

• 特征依赖于用户端和内容端的标签。
• 召回策略依赖于用户端和内容端的标签。
• 用户标签的内容分析和数据挖掘是推荐系统的基石。

为什么需要这样的框架？​

• 以低延迟处理高吞吐量。
• 分布式系统中的容错能力。
• 通用抽象以满足多变的业务需求。
• 适用于有界数据集（批处理）和无界数据集（流处理）。

批处理/流处理的简史​

1. Hadoop 和 MapReduce。Google 使批处理在分布式系统中变得简单，如 MR result = pairs.map((pair) => (morePairs)).reduce(somePairs => lessPairs)。
2. Apache Storm 和 DAG 拓扑。MR 无法有效表达迭代算法。因此，Nathan Marz 将流处理抽象为喷口和螺栓的图。
3. Spark 内存计算。Reynold Xin 表示，Spark 使用 10 倍更少的机器 以 3 倍更快 的速度对相同数据进行排序。
4. 基于 Millwheel 和 FlumeJava 的 Google Dataflow。Google 支持批处理和流处理计算，使用窗口 API。

等等……但为什么 Flink 正在获得越来越多的关注？​

1. 它快速采用了 ==Google Dataflow==/Beam 编程模型。
2. 它对 Chandy-Lamport 检查点的高效实现。

如何？​

架构选择​

为了用商品机器满足上述需求，流处理框架在这些架构中使用分布式系统……

• 主从（集中式）：apache storm 与 zookeeper，apache samza 与 YARN。
• P2P（去中心化）：apache s4。

特性​

1. DAG 拓扑用于迭代处理。例如，Spark 中的 GraphX，Apache Storm 中的拓扑，Flink 中的数据流 API。
2. 交付保证。如何保证从节点到节点的数据交付？至少一次 / 至多一次 / 精确一次。
3. 容错能力。使用 冷/热备用、检查点或主动-主动。
4. 无界数据集的窗口 API。例如，Apache Flink 中的流窗口。Spark 窗口函数。Apache Beam 中的窗口处理。

比较​

动机​

在用户登录时利用用户和设备数据进行斗争

1. ATO（账户接管）
2. 僵尸网络攻击

ATO的检测难度从易到难

1. 单个IP
2. 同一设备上的IP
3. 全球范围内的IP
4. 10万个IP
5. 针对特定账户的攻击
6. 网络钓鱼和恶意软件

解决方案​

半监督学习 = 无标签数据 + 少量有标签数据

为什么？学习准确性优于无监督学习 + 所需时间和成本低于监督学习

• K均值：效果不佳
• DBSCAN：效果更好。使用标签来
  1. 调整超参数
  2. 约束

挑战

• 手动特征选择
• 对抗环境中的特征演变
• 可扩展性
• 无在线DBSCAN

架构

生产设置

• 批处理：7天的数据，每小时运行一次DBSCAN
• 流处理：60分钟的移动窗口，运行流式K均值
• 使用反馈信号成功率将聚类标记为好、坏或未知
• 坏聚类：始终丢弃
• 好聚类：小比例的尝试
• 未知聚类：X%的尝试

免责声明：以下所有内容均来自公共资源或纯粹原创。 这里不包含优步的涉密内容。

要求​

• 为全球的交通运输市场提供服务
• 大规模的实时调度
• 后端设计

架构​

为何要微服务？​

==Conway定律== 软件的系统结构会对应企业的组织结构。

结合单体 ==代码库== 和微服务可以同时利用两者的长处.

调度服务​

• 由geohash提供一致的哈希地址
• 数据在内存中是瞬态的，因此不需要复制. (CAP: AP高于CP)
• 分片中使用单线程或者锁，以防止双重调度

支付服务​

==关键是要有异步设计==, 因为跨多个系统的ACID交易支付系统通常具有非常长的延迟.

• 利用事件队列
• 支付接口集成 Braintree, PayPal, Card.io, Alipay 等
• 通过详尽的 log 来记录所有 event
• 使用具有等幂性、指数退避和随机抖动的API

用户档案服务和行程记录服务​

• 使用缓存降低延迟
• 随着 1) 支持更多的国家和地区 2) 用户角色（司机，骑手，餐馆老板，食客等）逐渐增加，为这些用户提供用户档案服务也面临着巨大的挑战。

通知推送服务​

• 苹果通知推送服务 (不可靠)
• 谷歌云消息服务GCM （它可以检测到是否成功递送) 或者
• 短信服务通常更可靠

安迪格鲁夫强调：==管理者最重要的责任是激发他的下属做出最佳的表现==。

不幸的是，没有一种管理风格适合各种场景下的所有人。找到最佳管理风格的基本变量是下属的任务相关成熟度（TRM）。

一个人的任务相关的成熟度取决于具体的工作项目，它的改进需要时间。 当任务相关的成熟度达到最高水平时，这个人的知识水平和积极性就会达到一定高度，让他的管理者能够顺利地把工作委派给他。

这其中的关键是==管理方式无所谓好坏，只有有效和无效==。

什么是“变化厌恶”？​

总的来说，“变化厌恶”就是每当你改变人们经常在产品中使用到的东西时，用户中会出现骚动和反对的声音。这种骚动几乎会出现在如 Gmail，YouTube，iPhone 等产品的每一个版本中。

如何减轻甚至避免“变化厌恶”？​

1. 让用户能够事先知晓、事后理解。事先把新版本的重大改变告知用户，并向其阐述做出这些改变的原因，事后要给出如何过渡的指导。
2. 允许用户自由切换。不要断绝用户切换回原版本的渠道，不要让他们落入孤立无助的境地。
3. 持续跟进用户的反馈。

不要让“变化厌恶”成为没把事情做好的借口​

随着时间的推移，产品的改变究竟是好是坏，人们终究会得到答案。

安迪·格罗夫强调，==管理者最重要的责任是激发下属的最佳表现。==

不幸的是，一种管理风格并不适合所有人和所有场景。寻找最佳管理风格的一个基本变量是下属的任务相关成熟度（TRM）。

一个人的 TRM 取决于特定的工作项目。提高 TRM 需要时间。当 TRM 达到最高水平时，个人的知识水平和动机都已准备好让她的管理者委派工作。

关键在于将任何管理模式视为有效或无效，而不是好或坏。