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