整个2017年都在搞大数据平台，完全远离了机器学习，甚至都不记得写过类似ETL的job。
从数据到平台，从业务处理到基础服务。
Metrics的收集，报警，生成报表。Data pipeline的准确性，性能。Job的提交，资源分配。分布式组件的部署，运维。
同时也参与了一个portal的开发，管理分布在全球各地的clusters。
大数据的服务：存储，计算，传输，search等等基本都是分布式的，每种服务的组件都有很多，不管是商业的还是开源的，都是围绕着C(Consistency)A(Availability)P(Partition-Tolerance)理论，CP，AP各有所长。
具体的实现上，可以说是五花八门，不过本质思想也基本类似，比如为了实现C(Consistency), 争取保证每个node上每步的操作都一致：要么都做，要么都不做。为了达到这个目的以及conver各种极端情况（比如，接收方在接收之后commit之前down了）有2阶段提交，3阶段提交，Paxos等算法的实现。
虽然各种服务的各种组件处理的业务和实现的方法不同，但大都包括分partition，选master, 副本备份，服务发现，请求响应等几个功能。
Partition是分布式系统的最主要特征，即是承载数据大体量的保证，又而实现分而治之。hdfs的block, hbase的region，elasticsearch的shard，kafka干脆就叫partition，清晰明了。有个Partition必然会出现有的partition会挂掉的情况，即绕不过P(Partition-Tolerance)。
分了partition就要加强管理，所以基本上分布式系统中都有master role，存储meta data, 处理一些环境相关的问题。有了master role，那就得投票选出来谁是master。从而引出了选master的问题，比如脑裂。毕竟选master的过程也是会有极端情况的。为了防治选master的过程，又引出了定义什么时候可选，谁有资格投选票，有资格的选的太多，选举过程可能就会冗长，会影响到系统的A(Availability)，即AP的问题。当然也有不选master的所谓的去中心化的组件，比如cassandra, 不过没有中心之后，每个node都可以做同样的事情，是不是也可以称为个个都是中心？毕竟gossip协议让每个node都拿到同样的配置信息。
因为是分布式的，所以在多台node上备多份。有了多个备份之后，所以又会分leader partition(prime shard)与replic partition，从而引出主被之间的数据同步问题，就会涉及到CP的问题。比如kafka的Highwatermark, 必须保证所有ISR节点都复制了的备份文件，才能被consumer消费到。ES的doc在没有被复制到replic shard的时候，却依旧可以被search到。不同的设计其实就是在根据service的特性权衡AP。