小土刀

全球架构师峰会深圳站 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 到机器学习都可以。

神马搜索大数据基础架构

发展的三个阶段

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

大数据平台整体架构为

  • 数据采集:爬虫、日志流
  • 实时计算:链接抽取、网页质量、知识抽取
  • 存储层:网页存储、图数据库 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 的质量还是能看出参差的
    • 有些甚至连标题都没有
    • 逻辑问题
    • 排版问题
    • 字体问题
  • 话题选择还是颇为广泛,很涨见识
  • 保持技术栈单一,不要扩展太多,考虑团队学习成本,运维成本,稳定性等等
  • 各家都在技术上展示自己推广自己,还是蛮凭借实力说话的
  • 自己还是得在工作中多尝试摸索一下方向,写完书就深入扎进去

参考链接

您的支持是对我创作最大的鼓励!

热评文章