元吐槽

又要开始胡言乱语了。

其实这个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）来回来去就是数据集成整合那点事，摘录一段：

資料湖泊儲存的資料是最原始的形式，未經過任何處理及管理
資料湖泊不需要使用者在取得資料前事先建立好資料結構 (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 101和Streaming 102，又看了Foundations of streaming SQL，一路按图索骥找到《Streaming Systems》（这本书一定要看动图，不然很难懂），看了几章总算开了点窍。因为我大部分对流计算的认知还停留在storm的年代，虽然很早就知道Dataflow和Beam，但也没仔细研究过。等读完了要好好总结下，批处理和流处理的对比还是很有意思的。

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

END？

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

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

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

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