全球架构师峰会深圳站 PPT 学习笔记

架构与其说是一门学问，更不如说是一种习惯，这就意味着，其实并没有绝对的好与坏，只要是适合团队节奏的架构，能把事情做好，抓到老鼠就是好猫。

参加大型技术会议的目的有很多，不过对于我这种没有机会去的人来说，先从 PPT 中学习，然后再问参会的同事，才是最能『吃免费午餐』的做法。这里要非常感谢主办方免费公开的演讲 PPT，也有全程直播，这种开放的心态，很好，很互联网。这篇文章我会把自己阅读的一些笔记和思考整理出来，以吃瓜群众的角度和大家分享一下。

同程研发团队的 10 年演变

从 1 到 1000: 业务拉锯战中如何打造一支千人精英研发团队

很多具体问题是每个快速扩张的技术团队多多少少都会遇到的，这里附上问题和我的一些理解：

如何营造学习和技术氛围？
- 开放、让大家参与到决策中，才能逐渐培养技术感觉和学习气氛
如何控制人浮于事？
- 以做事为核心，不弄形式主义
天天增删改查，业务型研发人员觉得没前途怎么办？
- 安排固定时间进行业务逻辑优化，尽量减少重复工作
研发人员的发展路径怎么规划引导？
- 可以根据不同人的不同追求，提高研发的灵活性
如何平衡技术提升和业务需求？
- 把 20% 重要的需求完成之后，一定要抽时间进行技术提升
工作成绩和效率如何评估，如何让管理层认可？
- 完成率、可用性、安全、价值、创新、业内水平，需要略懂行的管理层

其他一些思路：

不熟悉的东西要发挥同事的积极性
管理的答案来自身边，而不是自己心里
关键同事大多是招到的，不都是靠培养的
功劳比苦劳重要
不合适的人坚决要换
简单、真诚、开放是研发最好的凝聚力

企业级大数据知识图谱产品构建与应用

知识图谱是我研究了四年多的东西，所以关于这个话题的演讲，当然是会更加在意一些。

PPT 中给出的业务角度观察很有意思：

普通需求：通用、无行业属性、业务附加值低
- 如：搜索、报表计算、历史数据、大数据平台
中高级需求：用户画像、精准营销、推荐系统、商业智能
高级且痛点需求：重大事件语境、实时交易反欺诈、设备故障预测、数据驱动的资源变现

分别来说一下，普通需求基本上各个平台都作为基础功能提供了，但是在中高级需求上，不同的公司有完全不同的做法，而且由于这部分需求基本直接面对用户，不同用户不同时间的千差万别的反应，也使得知识图谱产品落地困难，或者说落地了并没有立竿见影的效果。

常用数据挖掘和机器学习的方法有：

自然语言处理
- 实体、关系抽取
- 文本分类
- 情感分析
图挖掘
- 社交网络分析
- 子图匹配
- 频繁子图匹配
评分模型
回归预测

Spark 展望 & Spark 程序开发

Spark 和 Hadoop 相比，由于思路和历史的不同，其实还是有不少差别的。Hadoop 生态系统已经相当成熟，配套的软件服务也很全，目前来说更多用于批处理，要写的代码稍多。而 Spark 更多依赖于内存，尤其是支持交互这一点，使得很多轻量级的应用成为可能。

Hadoop 本质上是一个分布式数据的基础架构，而 Spark 是一个数据处理工具。

Spark 生态支持的语言很多，其中 Python 和 Scala 在 ETL 部分占据统治地位，而数据可视化基本用 R，机器学习主要是 Scala。如果图省事儿的话，一个 Python 可以基本搞定大部分事情，从 Map-Reduce、SQL、Graph 到机器学习都可以。

神马搜索大数据基础架构

发展的三个阶段

满足大规模数据存储和（时效性）计算。业务代表：抓取、索引、排序
满足复杂的数据挖掘和处理需求。业务代表：日志挖掘、数据融合、推荐模型
功能和平台的标准化。代表：通用算法、通用调度、流程语言

大数据平台整体架构为

数据采集：爬虫、日志流
实时计算：链接抽取、网页质量、知识抽取
存储层：网页存储、图数据库 Titan、Hive、HBase
计算平台：Spark、MPI、Caffe -> 推荐模型
在线引擎：推荐引擎、检索引擎
离线计算：Map-Reduce, SQL, 去重、索引

这里提到的 Hbase 其实之前我自己在使用的时候也遇到了诸多问题，从内存、垃圾回收到自动分区再到数据扫描，其实都有很大的延迟。神马搜索做的尝试还是蛮有意思的，不过目前我们的业务基本都还在 RDS 上，也暂时不用这么大体量，所以还好。

最后的心得还是比较给力的

关注业务，更要关注人：大家解决问题的方式往往能给人以启发
不要轻信直觉：逆向思考比经验更宝贵
不要迷信开源
多平台是不得已的选择
积累口碑

人工智能产品创新技术分析

人工智能产品的两条生命线之一『数据闭环』
人工智能产品的两条生命线之二『业务闭环』

总体来说框架概念居多，具体到架构的不多，毕竟目前深度学习大家的套路都是一样的。

面向游戏业务的内存数据库开发

游戏业务和其他业务在特性上还是有比较明显的不同之处的，比如说玩家大部分时间都在操作自己的数据，每个玩家的数据集并不大。但是具体进行切分的时候，需要根据玩家信息来进行细致考虑。

目前来说还暂时不考虑涉及大型多人游戏的开发，我还是偏向于主机小品游戏。

微博个性化 Feed 的评测之道

信息流实际上是应对信息过载的最佳方法，通过学习用户的偏好，给他们看他们想看未看的，才能提高粘性和日活。具体的实践套路其实也很清晰：

设计算法
实验算法
算法评测：这一步需要调优
算法应用：完成之后可以进入新算法的研究周期

整个流程需要引入的是自动评测（A/B Test）以及半自动或人工评测，这样可以极大减少测试调试算法的成本。微博的做法是自己做了一个系统来进行测试，我们也可以内部做一个这样的系统然后开源出去，不过这种系统和业务的耦合度太高，估计只有嵌入到 Hadoop 或者 Spark 生态系统中才可能有更多人愿意采用。

滴滴出行业务系统的架构升级

提出一个很有实践意义的套路：代码治理 + 模块下沉

按照产品逻辑，重新划分模块；提供模块下沉所需要的工具和流程
将不同模块拆分到不同仓库之中；全新的基于模块的构建系统
消除模块间的循环依赖；控制模块下沉所需成本
独立的模块开发、测试、上线流程；临时的全公司需求管控

核心设计思想在几个端也很有参考价值，主要是无状态 + 异步化

客户端：互相独立无依赖的界面流程；异步获取共享数据
- iOS: Cocoapods
- Android: Gradle + maven
Web App：业务互不干扰的并发加载；异步获取共享数据
- scrat / webpack 管理组件依赖
- 动态加载义务代码
- 实现一系列公共组件，提供贴近客户端的交互体验
服务端：易于扩容的无状态服务单元；用订阅/发布模型解耦

个人感觉滴滴在技术这一块进步还是非常明显的，要争取看齐！

创业团队极速发展过程中的分分合合

痛点：产品、技术、运营三大组织间的分分合合

一级部门上，倾向产品、技术分离
二级部门上，倾向产品研发合一

创业之除，唯快不破；持续发展，团队稳定；持续高速，流程规范；

工程师创业指南

选择行业：市场够大、市场初级、高频、BAT 难进入、护城河
弯路：广告效应、补贴效应、代替用户做事、节后效应
不要去创造新需要
改变低效率、高成本

一个二次创业者是怎样失败的

时代已改变，个人英雄主义时代已落幕
选择创业方向至关重要，创业需要运气
自己能力再强，也不如一支互补的团队
融资已成为一项基本能力
互联网创业已然是全方位的战争，需要抱团
Move Fast or Die
拓宽自己的人脉，储备合伙人资源，VC 资源
避开存量市场，寻找增量市场
技术创新驱动互联网 IT 产业发展
机会：垂直领域的直播；人工只能；机器人，VR/AR

一些感悟

PPT 的质量还是能看出参差的
- 有些甚至连标题都没有
- 逻辑问题
- 排版问题
- 字体问题
话题选择还是颇为广泛，很涨见识
保持技术栈单一，不要扩展太多，考虑团队学习成本，运维成本，稳定性等等
各家都在技术上展示自己推广自己，还是蛮凭借实力说话的
自己还是得在工作中多尝试摸索一下方向，写完书就深入扎进去