元吐槽

又要开始胡言乱语了。

其实这个md文件的创建时间是“2018-05-28 02:55:38”,却拖了半年才写完。。。时间跨度比较大,各种内容比较杂,想到哪写到哪。我的习惯就是想到什么先记下来,然后慢慢去补充。

为啥叫“元吐槽”呢,大概是“关于吐槽的吐槽”吧。

元数据

元数据系统应该是数据平台中最“玄学”的系统了,很多人认识不到它的价值,也很难说清楚它到底是做什么用的。如果你去搜索“元数据”的定义,一般都会告诉你元数据是“关于数据的数据”,这特么就是废话。。。你还是不知道它是啥。就像《易经》一样,你可以说它包罗万象,也可以说他废话连篇。因为它太抽象,每个人总能找到自己的方式去“适配”它,都会有自己的理解,还都觉得自己是对的。还有人说:哲学是关于科学的科学、哲学是科学之母,一个道理。各种方法论/各种主义,一向是我吐槽的重灾区。。。

扯远了。元数据不是个新鲜概念,而且非常宽泛,任何系统运行时需要的数据,都可以叫做元数据。所以别纠结,我们讨论的更多是大数据场景中的元数据和对应的系统。

就像大数据领域很多系统都以Google为原型一样,关于元数据Google也有一篇论文:Goods: Organizing Google’s Datasets,介绍了google如何管理自己的数据集(Dataset),包括自动发现、组织、计算血缘、检索等。通俗点说就是数据集不断增多,但没人知道这些数据是什么,所以需要一个方式来管理。没什么太难的概念,但有几个值的注意的地方:

  • goods非常注重事后处理(post-hoc),给出的理由是不要干扰用户的正常使用。这也是现在业界大多数系统通用的做法,但并不绝对。在并不那么遥远的过去,还有一个概念:EDM(企业数据管理,真是拗口)。感觉上就是所有数据都必须先要在一个中心化的系统中注册,通过这种事前的方式去维护元数据。这也未必就完全是错的。最近接触了一些政府的系统,不同部门之间通过文本文件、excel文件、数据库等传递各种数据,强行事后反而麻烦。事后的前提是有统一的数据存储和处理方式。
  • goods中的很多元数据信息是“推断”而来,并不能保证准确。典型的就是schema,可能从proto文件中获取,可能从底层文件存储获取。这可能是google特殊的环境导致的。我们不一样,我们有hive啊,schema反而不是问题(当然前提是你所有数据在hive里)。
  • 有些元数据必须是手动补全的,这点非常重要,不要想着程序能做所有的事情
  • goods倡导的所谓data-culture,不明觉历

论文中还一再提到DataLake,感觉这又是最近炒起来的一个概念?(还有所谓的数仓2.0)来回来去就是数据集成整合那点事,摘录一段:

1
2
資料湖泊儲存的資料是最原始的形式,未經過任何處理及管理
資料湖泊不需要使用者在取得資料前事先建立好資料結構 (schema)

感觉是各种数据无脑灌进去,需要的时候再去解析。

说回元数据。就像之前说的,我们有hive,所有大多数小公司的元数据系统其实就是依托于hive,数据换一种组织方式,再补充一点自己的业务信息,就成了。很多个人开源的元数据项目,也就这么回事。业界的开源系统:Apache Atlas/Netflix Metacat(最近刚开源的),会支持更多的组件,但大多数情况下应该也是hive为主,而且鲜少见到有实际的应用案例。

结合我们的一些实践,尝试总结元数据的一些特点:

  • 很少有自顶向下的设计,都是被逼的。。。大家会更关注于那些“看得到的事情”:hadoop、spark、调度器、数据同步等等。元数据天生弱势,易被忽略。所以每个公司的元数据系统一般是跟整个体系紧密结合的,很少能拿来主义,就算有一些开源项目,也很少能开箱即用。
  • 可以回溯历史:这是最重要的特性,比如hive meta中只会有最新的schema,而元数据系统可以看到历史schema和操作人。这跟数仓有点像,元数据也是要抽象、要建模、有层次的。
  • 很多数据是统计性的,可能不准确,而且不要求/做不到实时更新
  • 受限于上一条特性,也许并不适合作为runtime的依赖,看场景
  • 数据来源庞杂,清洗逻辑也非常复杂(相对于业务的ETL流程而言)
  • 未来的趋势是和在线meta的融合

如果是hive表的元数据,大概有哪些:

  • 基本属性:owner、schema、分区、变更历史、sample data、对应的调度任务(或者说是表的更新逻辑)
  • 字段属性:安全等级、枚举值
  • 存储属性:大小、文件数、记录数、存储格式、压缩格式、副本数、生命周期
  • 业务属性:业务描述、所属业务线
  • 访问属性:创建时间、更新时间、访问情况(次数+时间跨度)
  • 其他:是否拉链表、是否源头表、增量/全量更新、各种统计信息(比如字段的count distinct)等

此外还有各种衍生属性:

  • 血缘(表+字段):最常见的衍生属性
  • DataProfile:来自阿里的概念,是否废弃表、是否有重复数据、是否不更新、存储健康分等,有点类似用户画像

别纠结概念,元数据的概念非常宽泛,上面列的只是比较常见的。

但有这些数据之后嘞?能干啥用?这也是我经常吐槽的点,不要跟我说要计算血缘,而是说要血缘做什么。

  • 数据发现:帮助用户找到想要的数据,可能需要引入类似电商的类目和标签体系,还可以借鉴一些概念:收藏夹啊、详情页啊之类
  • 报表:比如计算每个部门/人的账单
  • 存储治理:比如删除无用数据,比如对于冷存的数据降低副本数,比如找到可删除的衍生数据
  • 监控/报警:典型的就是血缘,上游的数据变更要给下游预警
  • 数据服务:这个比较玄学,“正确的组织方式有可能帮助用户发现数据的价值”,就像xmind有助于我们去思考问题一样,关键要将所有的数据视为“资产”去管理,通过数据资产去产生利益(应该没有负资产吧。。)

这还只是hive表的元数据管理,更进一步,还有调度任务的、hdfs的、数据源的、kafka topic的、hbase表的等等。
广义上来说,运维的CMDB也是元数据系统。甚至可以说一切皆元数据(听着就很神棍)。。。

参考资料:

元数据管理系统解析
打个广告,我老板的文章

自服务数据共享与服务架构详解
这个文章有点“官方”,讲的有些晦涩,而且更侧重事前处理?
痛点分析的不错:过程不可控、数据不开放、缺乏共享。
自服务的概念挺有意思,但与post-hoc的理念相悖,而且会带来额外的成本。
如何从一个数据的管理者变为数据资产的经营者,带来新的业务?

淺談資料湖泊(Data Lake)

重磅!Netflix开源大数据发现服务框架Metacat

Hive wiki: StatsDev / HIVE-2526
hive本身自带一些统计信息,可以作为元数据的一部分,但并不准确
而且通过spark sql进行的操作无法统计(有人问hive on spark和spark sql的差别,这就是一例)
如果想要准确的数据需要analyze table,但有代价

分布式小杂烩

分布式大杂烩续集。
最近重看了遍Raft的论文,又引出了一大堆乱七八糟的问题,整理下。

关于CAP

我一直都知道CAP中的C和ACID的C是不一样的,但是说不清楚。也知道“一致性”这个词非常混乱,业务的一致性和副本的一致性完全是两个东西,甚至还有人说storm是弱一致性的(意思应该是计算结果不准确吧)。直到看了知乎上这个回答:如何理解数据库的内部一致性和外部一致性?,真的是豁然开朗,很多概念都澄清了。像Spanner论文中一直提到的外部一致性,之前就一直似懂非懂。

尝试总结下,其实很多地方可以类比java的并发机制:

  • ACID中的C,核心在于“约束”,事务前后DB的约束不被破坏。什么是约束?其实我们很多时候都意识不到约束的存在,比如主键、唯一索引、字段类型,换句话说,这是DBMS定下来的“规矩”,不可逾越
    • 经常有人用转账的例子来说明一致性,但感觉这并不是一个好的例子。“转账前后总金额不变”,真实中可能并不是DB的约束,而是业务系统的约束。
  • ACID中的I,关注的是多个事务并发时的表现,一个事务是否能“意识”到其他事务的存在
    • 在Serializable级别下,所有事务都是隔离的、互不干扰,有点像as-if-serial(并不准确,as-if-serial指的是单个线程的行为)
    • 但其实ANSI定义的Serializable并不准确。这种隔离级别下,虽然不会有常见的脏读/不可重复读等问题,但会有其他问题,比如write skew。所以ANSI的Serializable也可以被称作Snapshot Isolation(经典论文A Critique of ANSI SQL Isolation Levels
  • CAP中的C,核心在于“顺序”,类比java中的happens-before语义
    • CAP中的C,其实跟DB没啥关系,甚至跟并发也没啥关系。所有系统中都要考虑到操作的顺序性。我先set a=10,然后再读a的值,我读到的是10么?这看起来像是废话,那是因为我们在用的很多系统中,隐式的保证了这个语义(一个线程中的每个操作,happens-before于该线程中的任意后续操作),在单机系统中也很容易做出这种保证。但分布式系统中,再引入并发的情况下,就没那么容易。
    • CAP中的C,严格指的是Linearizability,翻译做线性一致性。我的理解:对同一份数据的读/写都是原子的,并且按顺序(一般情况下是时间顺序)发生,后面的操作可以看到前面操作的结果。类比java中的volatile关键字。
    • 具体到DB中的事务,其实指的是:如果某个事务写入的值对外界可见了,那后续所有的事务都能读到这个值(可能是那个写事务提交了,也可能是脏读之类)
  • ACID中的I和CAP中的C,针对的其实是两种不同的特性,虽然跟并发都有点相关。二者结合才能完整的描述一个系统。比如我们大概可以说mysql默认是Repeatable Read + Linearizable的。同时满足Serializable + Linearizable的系统,也可以称作Strict Serializable,或External Consistency,也就是Spanner这种。
  • 既然顺序如此重要,那如何决定操作的顺序?单机系统很容易生成一个全局递增的id,比如mysql中的事务id;zk虽然不是单机系统,但zxid的设计也是类似的。而在分布式系统中,更多是使用时间来决定。见Lamport大爷的经典论文:Time, Clocks, and the Ordering of Events in a Distributed System
    • 如果有一个全局唯一的、准确的时间服务(比如Percolator中的中的TSO),那一个写事务完全可以选用当前时间作为事务id(或者说是数据的版本号),因为后续的读事务id肯定大于这个写事务,也就能读取到写入的数据,保证Linearizability会更容易
    • Spanner中的commit wait time,其实也是为了保证Linearizability,保证写入数据的版本号小于后续任意读事务的版本号,排除时间误差的影响

感觉上,似乎CAP理论中的三个维度,并不是true or false,而是0~100,不可能在3个方向上都达到100。
话说分布式领域,还有很多非常经典的论文值得一看,可惜精力有限,而且都比较偏理论,研究起来很花时间。

参考资料:

聊聊事务的30年发展历史
很赞,讲了各种隔离级别的历史问题,我以前总是搞不清SI和SSI。其中有一例精彩吐槽:

也正是从此,大家开始意识到他们需要关心可串行性,一部分原因是 Jeff Dean 认为其非常重要。与此同时,持续呼吁该观点将近 20 年的 Michael Stonebraker 表示很无奈,大家显然只在 Google 明星工程师声明某件事的重要性时才会关心它。

分布式系统一致性

一致性模型
很赞,讲清楚很不容易。对pingcap还挺有好感的,很佩服能把这些玩的溜的人

分布式系统的时间
[译] 分布式系统中的一致性模型

OCC和MVCC的区别是什么
感觉这个区别挺微妙的,别被那么多概念绕进去,按逻辑想想,很多东西大概就能明白了

强一致性、顺序一致性、弱一致性和共识
隔离级别、SI 和 SSI

2PC与3PC的区别
很多人其实没有搞清楚3PC

分布式共识

提到分布式一致性,大多都会提到paxos/raft之类。但其实这是个翻译的锅,paxos中的一致其实是consensus,指的是“共识”;而ACID和CAP中的C,指的是consistency。paxos/raft应该称作分布式共识算法,解决的问题是“分布式环境下多个节点如何对某个问题达成一致”,区块链中的PoW算法也在此列。paxos和raft经常被拿来对比,却较少有paxos/zab的对比。

raft就不说了,这是我这些年看过的最通俗易懂的一篇论文,作者生怕你不懂,遣词造句都尽量简单。你需要的一切都能在论文里找到。而且raft就像kafka一样,有种简单但强大的感觉。
paxos就不一样了。首先论文本身就非常抽象,而且又缺少了很多细节,工程实现中也有非常多的坑。chuppy的论文中(没记错的话)也有吐槽:“工程中实现的paxos和原本的paxos,根本就是两个东西了,所以大多数系统都是运行在一个未经证明的算法上”。

一些关键点:

  • 对于basic paxos,理解paxos instance的概念非常重要。虽然论文里好像没有明确提出这个概念。简单点说一次表决过程就是一个instance。也正是在paxos instance概念之上,才能衍生出multi paxos(虽然Lamport大爷没有用这个词,全靠自己想象)
  • 单次paxos instance的流程,是非常好理解的,如果我们不去关心它的证明。
  • 如何生成提案号,论文中并没有指出。
    • 这个提案号不需要是全局有序的,甚至不用偏序,理论上随机生成都可以。。。就是提案通过的概率会很低而已。两个proposer完全可能生成一样的提案号,但只有一个能通过phase-1。
    • 工程实现中,如果能保证全局有序,当然是最佳的,或者至少保证单个节点是递增的。一些文章会说将机器的IP作为提案号的一部分,比如高位放时间戳,低位放IP,这样某些机器的话语权会天生“较大”,不过算法的目的是尽快达成共识,也许这也不是问题。
    • chuppy的论文中,给处理了一个算法:s = 已知的最大值 * 节点个数 + 自身编号
  • 集群的各个节点状态是有可能不一致的,所以每次读也必须走一次paxos流程,这样才能保证读的一致性
    • 论文中也说:为了确定被选定的value,必须重新发起一次新的提案,这事一般是learner角色来做
    • 也有这么说的:通过learner角色使所有Acceptor达到最终一致性。
  • 理论上来讲,一次提案不必发给所有的acceptor,提案发起者自己选定一个majaroity发送就可以了,所以各个节点的状态很可能是不一致的
    • majaroity的概念需要准确理解,是整个集群的大多数,而不是活着的节点的大多数,所以成员变更是一件非常麻烦的事,Lamport大爷也没说成员变更的事,后续的《Paxos Made Practical》进行了补全
    • 只有收到majaroity的commit成功消息后,才能回复客户端
  • 活锁问题很好理解,如果所有节点都能任意提议。由此引出了leader的概念
    • leader如何选举,并没有规定,可以通过paxos来选,但未必
    • leader还一般还要搭配lease机制,持续保持leader身份
    • 而且竞选leader不需要有最新的状态,这点和raft很不一样
  • multi-paxos并不是为了解决活锁问题,而是为了在某些场景下(单一proposer连续多次提交)提高效率,跳过prepare阶段,直接commit
    • 有些资料中提到leader必须先执行一段时间正常的两阶段流程,大概是为了catch up状态
    • 状态catch up包括两部分:最大的instanceId,和日志重确认。因为新的leader状态很可能是落后的,而且命令序列中可能有“空洞”。这个时候leader其实扮演的是learner角色。
    • 关于命令空洞的问题,论文中说的不是特别清楚,我觉得典型场景就是并发处理多个请求,后面的请求先成功,然后leader挂了
  • 理解paxos的关键在于,每个节点都是一个状态机,如何让各个状态机保持一致?
    • 最常见的机制就是State machine replication,也是Lamport大爷的经典论文,让所有节点回放相同的命令序列。这也正是multi-paxos做的事:在所有节点上确认相同的instance序列。
    • 这是一个非常抽象的模型,可以用在很多地方,但每一个场景中都必须自己思考如何应用。Lamport大爷只提供水泥的配方,然后每个人开始自己造房子。

总的来说,建议还是不要直接看论文,太tm难懂了。应该先大概了解些paxos的概念再去看。而且各种关于paxos的文章太多了,不乏很多误导性的(我也不敢说自己的理解是对的),工程实现也是五花八门,还是直接看原文、看wiki比较好。

相比之下,zab就简单明确的多,估计很大程度上是因为有zookeeper这样一个“标准”实现。
zab和paxos的区别,官方wiki中说的很清楚,前提是真的理解了paxos的状态机本质;zab论文的也道出了关键区别:《Zab: High-performance broadcast for primary-backup systems》。我来尝试着解说下:

  • paxos可能会对请求“重排序”的,只要没有处理过的请求(或者是说没有返回给客户端成功消息的请求),先后顺序无所谓,所有参与的节点,会“商议”出一个顺序。paxos只要最终形成的“instance序列”是一致的就可以了,所有的replica基于这个序列去回放,最终就能达到一致的状态。
  • 而在某些场景中,是不能重排序的。能重排序的,往往是“外部client请求”;不能重排序的,往往是“增量状态更新”(incremental state changes)。这也就是state machine replication和primary-backup这两种机制的差别。
  • paxos也能用于primary-backup,但性能会差;而zab就是为这类场景而设计的,借鉴了paxos中的很多思想,比如两阶段、表决机制
  • zab中的所有写操作,是严格有序的(因果有序),所有写请求都由leader处理。leader生成递增的zxid,proposal会按顺序提交,tcp协议保证follower也是按顺序收到,follower保证按顺序回复
    • 这种设计必然会限制吞吐量,所以写性能堪忧(虽然我没看代码求证过),而且不能水平扩展。之前一篇文章阿里巴巴为什么不用 ZooKeeper 做服务发现也有提到这个问题。
    • 我猜测,表决的时候不必一次次表决,可以一次表决多个事务,这样比较合理
  • zxid还是一个挺巧妙的设计的,配合epoch概念,保证即使leader 切换,zxid也是递增的

zab总体还是比较简单的,感觉上就像mysql binlog replication的威力加强版。。。但zookeeper不等于zab,zookeeper还是额外做了很多事情的。

此外常提到的算法还有Viewstamped Replication,据说和paxos本质上是一样的,时间上还要更早些。raft的论文中也有提到自己和VR/zab的区别。

还有个画风不太一样的算法就是GOSSIP,常见的应用是cassandra和redis。据说可以在O(logN)的时间上收敛,但不会有一个“精确”的时间点,很好玩。

所有这些共识算法吧,你可以绞尽脑汁想各种异常状况,但还是难以覆盖,很难证明它是完备的,至少我的脑子是不行。。。

参考资料:

【译】Paxos Made Simple
即使是paxos made simple,也没那么好懂

一步一步理解Paxos算法
英文wiki:https://en.wikipedia.org/wiki/Paxos_(computer_science)#Basic_Paxos
中文wiki:https://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95

Paxos历史回顾
各种历史渊源讲的比较好

使用Basic-Paxos协议的日志同步与恢复
OceanBase大神的一系列文章,blog中除了paxos还有很多其他内容,非常赞

http://paxos.systems/index.html
一个非常赞的站,集合了各种资料

分布式一致性论文阅读阶段性小结
Multi Paxos:Basic Paxos的进化:这里提到的队列策略我没太懂

各种paxos made系列:
Paxos Made Live:google最让人印象深刻的就是强大的工程能力
Paxos Made Practical
Paxos Made Code
Paxos Made Moderately Complex

Zab:Zookeeper 中的分布式一致性协议介绍
Raft 为什么是更易理解的分布式一致性算法
Raft对比ZAB协议
ZooKeeper Recipes and Solutions

30 种共识算法完全列表:币圈真是群魔乱舞。。。

其他

很多算法中都涉及到选主,这其实是一个很古老的话题,也经过很多研究了,比如Bully算法。每个算法都可以定义自己的选主机制,比如zab中的快速选举,raft中的随机超时等。

研究的过程中,突然想到BT下载,这也是个挺神奇的东西。以前有tracker服务器的时候还好理解,磁力链是真的挺神奇的,各个节点是怎么知道数据块所在的位置的?虽然一直知道是所谓的DHT,以后有空再研究。
期间也接触了一些RDMA的概念,似乎是要专门的硬件?还找到了一个RDMA与HDFS集成的项目:R4H,不过已经废弃了。

参考资料:

https://www.jianshu.com/p/f1659aba5aed
https://zh.wikipedia.org/wiki/%E7%A3%81%E5%8A%9B%E9%93%BE%E6%8E%A5

数据平台

老生常谈了。时不时我就会思考一下,数据的价值是什么,平台的价值是什么。

有段时间我经常以“xxx bigdata archtecture”为关键字在google中搜索,xxx可以是uber/airbnb/netflix/linkedin等等。一直以来各种分享、文章、架构图也看了不少,各种《大数据xxx》的书也看了不少。单纯说技术架构吧,大同小异,尤其各种小厂,毕竟有能力造轮子的还是少数。可能在规模、一些细节上有差异,但都不是本质的区别。那我们所做的事情意义何在?不就是搭个hadoop?(题外话,我很不喜欢这种“不就是xxx”的句式,这样说的人,要么非常资深,要么非常无知,而且无知的居多。比如我也可以说,所谓运营不就是拉新/转化/留存/召回,但这几个字背后是多少辛酸泪啊。。。)

平台 ≠ 各种开源组件的堆砌,同样的水泥,造出来的可能是陋室也可能是别墅。它的意义在于:

  • 赋能,我一直觉得这是所有大数据技术,甚至可以是所有技术的根本价值。它能拓宽你的想象空间,做到之前做不到的事。
    • 我一直说,我是造发动机的,也是卖铁锹的,工具本身不产生价值;或者说,它是整个价值链的最上游;
    • 我能对外提供什么样的能力?可以是数据开发的能力,可以是可视化能力,可以是调度能力。能力也是有层次的:我们可以笼统的说,我们提供的是“洞察”数据的能力,是在数据中淘金的能力。然后再对这些能力进行细分/下钻,大概可以总结出一个能力模型吧。
  • 提升效率与稳定性。解决了“能不能”的问题,接下来就是“好不好”。毕竟基础组件就那些,能提供的能力也不会差太多。最重要的衡量标准就是效率和稳定,经历过烟囱式架构或者大单体应用的人,大概能够体会其中痛点。
    • 包括提升用户开发效率和降低管理成本两方面。更进一步,关注用户的体验与口碑。我喜欢讲的一个例子就是docker,它刚出现时只是把各种技术“黏合”起来,但就是极端好用,才有了后续的发展机会。广大人民群众就是这么耿直。。。
    • 所以产品化是很重要,但也很容易被搞技术的人忽视的一个方面。
    • 稳定不是靠运气的,而是靠系统化的建设,靠制度和规范的推进,需要自顶向下的规划
  • 与业务的契合度,这是每个公司之间最大的差别,不是所有经验都可以复制。
    • 大多数技术都会有一个支撑业务(满足现有需求) -> 预见业务(满足未来需求) -> 驱动业务(创造需求)的过程,尤其是各种新的技术。
    • 我不光是个造发动机的,我还可以教你怎样用的更好。很多业务方自己是不够敏感的。
  • 数据文化,这就比较玄学了。我一直觉得数据能力应该是所有开发同学必备的能力,就像数据库/SQL一样,而不应该是需要专门培养的。甚至产品/运营也要具备这种能力,或者说这种思维。如何降低这个门槛,倡导这种文化,因环境而异。

有用户问我,你们是不是中间件?仔细想了下,还真有点像。提到中间件,一般会想到RPC/trace/分库分表/配置中心/统一网关/MQ等等。和运维也有点像,运维=CMDB/DBA/nginx/发布平台/监控/GIT/持续集成等等。都是提供一些基础的“能力”,都是将一些公共的技术抽象出来。差别大概在于我们更偏上层一点,如果去驱动业务会更方便,毕竟数据是可以渗透到业务的整个生命周期的。很多所谓的平台,如果做的更偏业务一些,就会变成业务系统,比如分领域的用户画像。
什么时候我们能做到像分库分表中间件一样,让所有人能“下意识”的去使用,大概这事就成了。有那么点润物细无声的意境。

大多数平台也许大概是这么个发展路径:

  1. 对需求从0开始支持。最开始的绝大多数需求都是报表,然后自己搭建hadoop、写各种ETL;
  2. 引入更多开源组件,开始各种排列组合;开始出现分工;
  3. 开始各种内部组件的开发,但大多是零散的点;对开源组件有限度的修改;快速的野蛮成长;
  4. 开始平台化 + 填坑;开始数据体系的建设,而不只是单纯的关注技术;出现更广泛的应用场景;开始关注功能之外的东西,比如治理;
  5. 对内大规模定制各种开源组件,整合各种需求,支撑并且驱动业务;对外做技术输出,持续提升影响力;
  6. 自研 + 公有云?

一家之言。太长远的我也看不清。
这个分类也很笼统,目前来说,我们大概处于第四阶段吧。

说点题外话。价值这种东西,总是时不时困扰我,我相信其他人也是。我看到很多做“纯技术”的同学很焦虑,总觉得自己离业务太远;也看到很多做业务开发的同学很迷茫,觉得自己一直没有长进。这大概是一个永恒的话题吧,似乎每个人都在质疑自己在做的事的价值?那是不是可以推论所有的事情都没有价值。。。原来大家都是虚无主义的信徒啊。
我觉得吧,价值没有是否,只有难易。我们大多数的质疑,只是畏惧困难而已,人类天性可以理解。所以问题不在于有没有价值,而在于你自己是否愿意相信这个价值,在于如何让其他人也相信并且认同。如果我们自己不能笃定,也就没有资格回应别人的质疑。与其自己在角落怀疑人生,不如尝试去把它变成现实。

最近总是一不小心就开始灌鸡汤。。。

参考资料:

《大数据平台基础架构指南》
给老板的书打个广告,没有太多细节,更多是宏观的指导,适合从业一段时间的人看

DataWorks V2.0:可以参考,很多在做的事情都类似

Apache Zeppelin vs Jupyter Notebook: comparison and experience
相对于传统IDE的另一种交互方式,最近应用场景越来越多

大数据平台架构从0到1之后
cluster+工具链+interface的分层,很特别;queryengine很赞,kylin玩的溜

58大数据平台架构演进
技术演进过程(稳定性 -> 平台治理 -> 性能 -> 异构计算)和我们很像
对于各种故障实例的分享很赞,有很多是我们真实碰到过的

Uber’s Big Data Platform: 100+ Petabytes with Minute Latency
发展过程非常清晰,Incremental data modeling挺有意思

Evolution of the Netflix Data Pipeline

方法论和架构

方法论我也不是第一次吐槽了。为什么各种方法论这么蛋疼,一方面很多方法论是不讲逻辑的,或者有一些逻辑但是不自洽;但更多是因为不分场景的胡乱套用。虽然这不是方法论本身的锅,但管杀不管埋也不行吧。。。

大道至简,如果剥去所有包装,道理都是相通的,也是所有人都能理解的。儒学提炼下大概是“仁义礼智信”,心学提炼下大概是“知行合一”,xx宗教提炼下大概是“躺倒挨锤”(好像没什么不对)。这些文字大家都能读,但能领悟内涵的,很难;身体力行的,更难;想传达给其他人,难上加难。毕竟面对的是活生生的人,有思维、有智慧的人。人的理解总是有差别的,就像宗教的不同流派。为了防止这种分歧,又只能变得繁杂,对简单的概念附上各种“细则”去说明,真是矛盾。更蛋疼的是,有人总喜欢把简单的东西复杂化,演绎出一大套理论和术语。
如此说来,面对机器反而容易些。

这就和鸡汤文一样,道理都是对的,可能也确实是别人从自身经历总结而来的,但直接灌给你是没用的,必须你自己感悟出来。自上向下的指导各种思想,一般效果都不咋样,毕竟知易行难;往往要自下而上的总结出来。凭空指挥总是容易的,我能想出无数种可能性,每一种逻辑上都说的通,但求证的过程十分痛苦,而且未必有结论。
所以我对各种方法论都比较警惕,很难全盘接受,批判并吸收才是正途。

架构这个词,从某种意义上来说,也是方法论的一种,所以也会被滥用。架构是为了“更好的解决问题”,而不是为了架构而架构。各种抽象是真的有用,而不是为了抽象而抽象。大概是我最近看了一些反面例子,有些愤世嫉俗了。。。

解决问题的前提是发现问题,但很多人欠缺这个能力,我也是。
能力的成长不是天生的,也很难是别人灌输的,而是来自于不断的挫折与思考。除非你天赋异秉,洞察力超群,否则大多数“正常人”都只有经历过痛苦才能成长。有句话怎么说的,“未长夜痛哭者,不足与语人生”。

毕竟所谓的架构,如果放着不管,就会一直“腐烂”,就像热力学第三定律一样,无论当初设计的多么好。只不过腐烂的速度不一样而已,除非你的业务停滞不前。(业务倒逼技术升级,某些时候很无奈,但换一个角度来看,也是很幸福。。。)
大多数的系统,都是最初设计时,架构和需求非常match,然后不断的“打补丁”,最后实在补不上了,来一次重构。提前设计不是不可以,但小心变成过度设计。超前一步是天才,超前100步就是神经病了。如何在“现在”和“未来”之间平衡,如何在“架构”和“需求”之间平衡,会是永恒的难题。这可以说是技术的难处,也可以说是技术的魅力。
所谓架构师,就要思考更好的解决方法,即是“最佳实践”。不用最佳实践可以不?可以,但在可维护性、复用性、稳定性、扩展性上,就可能会有问题。
而且很多事情啊,都是粗略看很简单,但一细想就有很多问题。就说日志采集吧,h5/native、预聚合、降级、采样、设备标志、到达率。。。这些细节往往才是真正体现能力和深度的地方。

参考资料:

阿里盒马领域驱动设计实践
非常赞,并不是DDD的无脑吹,让我真正理解了Persistence Ignorance的重要性

优秀架构师必须掌握的架构思维
怎么样的架构才是好架构?

PostgreSQL-51风控系统背后的利器
跟这哥们打过些交道,解决问题的思路很清晰,虽然他喜欢的postgre给我们带来很多麻烦。。。

以人为本

很多时候,我经常在想,到底是因人成事还是因事成人,虽然实际情况必然是两个因素的混合。

但就我观察到的情况来看,大多数还是人的因素更占主导,尤其是小公司。
大公司也许可以靠各种基础设施、靠制度、靠流程,让那些不那么优秀的人也发挥作用,比如amazon。说的露骨一点,大多数人在这里就是螺丝钉而已。但在小公司,一件事情是否能做成,很大程度取决于这件事的owner是否足够优秀,是否有足够的推动力。换句话说,靠人的优秀来弥补基础的不足。毕竟从事情本身来说,大多并没有特别的前瞻性,很多时候是有经验可以借鉴,有路可以重复走的。
有点像法治 vs 人治的区别?

如果能源源不断招到优秀的人,很多问题都会迎刃而解。但毕竟这只是个理想状态。讽刺的是,大公司反而更容易招到优秀的人。
带领优秀的人做事总是更容易的,如何带领不那么优秀的人把事情做成,如何在管理成本很高的情况下把事情做成,才是管理能力的体现。“有多少人做多少事”,这不是一个很好的心态。我更希望是做“应该做的”、“正确”的事。从这个角度来说,事才是最终的目标,而人只是达成目标的一个手段,虽然是最重要的一个手段。

怎样才是优秀的人?我也一直在思考。我理解的码农的基本素养:

  1. 技术能力。吃饭的家伙,但也只是个最低的门槛。
  2. 业务sense。这个标准就能刷掉一大波人。可以不直接参与业务,但必须要理解业务,知道如何产生价值。某些场景下,可以近似理解为产品意识。
  3. 价值观。很玄学,但真的有用。区别度很高。

每一点展开都能讲很多。

价值观这个东西,也算是“恶名远扬”,我以前一直挺反感的。但我反感的是各种滥用和教条。
经历过的人越来越多之后,深深觉得“技术”只能决定人的下限,而“价值观”(或者说习惯/态度/方法)才能决定人的上限。而其中最重要的一条就是“积极”,或者叫自驱。不安于现状,主动思考如何做的更好,并能驱动整件事情的改进,碰到困难想办法解决而不是推诿,是否有不顾一切达成目标的心气。这些事情,说起来都很简单,但能做到的人真的是少数。很多人只是嘴上说着不甘于平庸,却不愿做出改变。
另外很重要的一条就是逻辑思考能力。虽然都是搞技术的,但很多人却欠缺这种能力。这世上虽然有很多不讲逻辑的事情,但庆幸的是大多数还是讲逻辑的,只是有些隐藏的比较深而已,只要稍微多想一点就能明白很多事情。

如何培养优秀的人?这又是一个很大的话题。
如果换个角度想想呢,作为个体,如何成长最快?必然是有个牛人带你,言传身教。影响人成长最大的因素是环境,和优秀的人在一起非常重要。出淤泥而不染不是不行,只是大多数人没这个素质,更容易变成“比烂”。如何建立一个良性的循环,让优秀变成一种习惯和氛围,一直都是难题。

杂七杂八

各种奇奇怪怪的读后感。

MPP 与 Hadoop是什么关系
所谓MPP,感觉是传统意义上的分布式数据库领域的?别纠结概念

gRPC-Web 发布,REST 又要被干掉了?
脑洞真大,刚开始看到题目还以为js真的具备调用RPC的能力了,其实后面还是有个proxy的

天天写「业务代码」,如何成为「技术大牛」?
来,干了这碗鸡汤

知识图谱的技术与应用:例子讲的比较简单,想象空间还是挺大的
一个支付服务的最终一致性实践案例:比较典型的案例,类似BASE

Service Mesh:下一代微服务
大多数公司连上一代微服务还玩不好吧
看了下似乎是将服务发现、通信等又抽象了一层?

Bit Map在大数据精准营销中的应用
其实就是位图索引,但结合hbase做了很多事情
跟BloomFilter一样,都是非常精巧的数据结构

布隆过滤器在实时指标计算中的应用
常见的估算UV方法:BloomFilter和HyperLogLog,很多时候从业务层面也可以优化

机器学习、优化理论、统计分析、数据挖掘、神经网络、人工智能、模式识别之间的关系是什么?
数据挖掘,也是一个很模糊的词,大概就是分类、聚类、预测、估算,还有NLP
或者说,机器学习指的是技术,而数据挖掘指的是业务目标?
这需要的不是多强大的算法能力,而是工程能力

Jison:很好玩的小工具,自动生成parser,有点像antlr

阿里技术参考图册
感觉PR的成分多一些,很多只是宏观的梳理,不过还是值得一看
话说梳理业务逻辑并不比技术简单,很佩服能梳理的头头是道的人

深度剖析阿里巴巴对 Flink 的优化与改进
我对flink其实不太熟,印象深刻的是FlinkSQL,摘录一段:

我们发现有了Dynamic-Table之后我们不需要再创造任何新的流式SQL的语义。因此我们得出这样的结论:流式SQL是没必要存在的。ANSI SQL完全可以描述Stream SQL的语义,保持ANSI SQL的标准语义是我们构建Flink SQL的一个基本原则

这还是挺特殊的,大多数流式SQL还是要新增一些语法的吧,google dataflow也没做到这一点吧。以后再研究下。话说Blink最近也要开源了啊。

说到流计算,前段时间看了Streaming 101Streaming 102,又看了Foundations of streaming SQL,一路按图索骥找到《Streaming Systems》(这本书一定要看动图,不然很难懂),看了几章总算开了点窍。因为我大部分对流计算的认知还停留在storm的年代,虽然很早就知道DataflowBeam,但也没仔细研究过。等读完了要好好总结下,批处理和流处理的对比还是很有意思的。

The Evolution of Large-Scale Data Processing
《Streaming System》最后一章的中文版,期待中文版上市

END?

乱七八糟的写了这么多,我自己都觉得啰嗦了,不过写文字从来都不是目的,思考才是目的。
有人看了我的文字,说我挺纠结的,想太多。我也承认。
怎么说呢,有些人天生有成功的直觉,总是能凭直觉做出正确的选择;我好像还没显露出这种特质。。。所以还是多想想吧,总比浑浑噩噩的好,只是别因为思考而畏缩不前。
或者其实大家都在纠结,只是没有显露出来?

很多时候,有些问题我觉得已经想明白了,但过段时间再看,又糊涂了。。。我就是不断的在“好像懂了” -> “好像还是不懂” 之间循环。
而且当你无所事事太久,一直看剧、刷新闻啥的,思考能力就会退化,思维会变得“扁平化”,缺少深度。深度来自哪里?来自于日常的思考和积累,从来就没有什么灵丹妙药,而且这可能是很痛苦的一个过程。
不过我发现一个现象啊,好点子往往都是洗澡的时候想出来的。为一个问题苦思许久不得要领时,往往能在某次洗澡时灵感迸发。。。虽然比不上阿基米德的“eureka”,但也让我很欣慰了。

现在最大的心愿就是下篇文章能写个“纯技术”的。。。但是吧太简单的(介绍类、tip类)写起来没意思,也没价值;复杂的吧,又需要很多时间研究。。。技术类的文章,要么就是对某个问题钻研的比较深,要说透彻;要么就是高屋建瓴,比较成体系。最关键的,还是要有自己的思考,copy-paste就没意思了。

这篇文字拖了这么久,可以说是忙,可以说是诸事缠身,不过这都是借口,其实就是懒吧。。。拖到最后,看着一堆要填的坑,真是头疼。不过写着写着就high了,吐槽还是挺爽的。