这是句颇为自嘲的话，往往只有忙碌才能让人心安。或者说，忙碌才能让人忘却不安。
最近各种动荡，事情变来变去，理论上我应该是最头疼的才对，不知为何却奇妙的非常平静，也许这就是所谓的inner peace？
随着各种槽点逐渐积累，又可以“敷衍”出一篇文章了。
啥是中台？
“中台”这个东西，颇为玄妙。就像所谓的teenage sex：每个人都在谈论，但没人做过；每个人都声称自己做过，而且以为其他人都做过。于是我也不能免俗啊，总结下自己的理解。
我之前做数据平台，对这块还算了解。对平台而言，最重要的是三个字，“标准化”。我们提供通用的、标准化的能力：计算、存储、检索、开发IDE、SDK等，用户可以在此基础上组装自己的业务逻辑，典型的one fits all。平台提供的能力没有任何业务含义，而且往往有一套通用的“业界标准”，照猫画虎去实现就可以了，不同公司做出来骨架都差不多，血肉会有区别。总的来说比较偏技术，边界也比较清晰。
但平台也有自己的缺点：
- 入门的门槛较高。业务方如果真要用这一堆积木搭出自己的系统，需要很多前置知识。SQL你得会吧，调优也得懂吧，跑的慢怎么办，日志怎么看，数据如何治理；
- 对业务方而言比较繁琐，而且要遵守很多规范。作为平台方，我们希望用户不要逾矩，按我们的规范（SQL规范、表规范、指标规范、资源使用规范）来做事，但无论是硬性的产品限制，还是软性的规章制度，总是有些“不听话”的用户。个别用户甚至破解了我们的REST API，私自在系统里调用。。。所以我们一直在和用户“斗智斗勇”。这种事情吧，不好说谁对谁错。我作为平台方要维护长远的稳定性和完整性，但也能理解他们的苦衷；
- 平台对新需求反应一般比较慢，而且会拒绝掉很多带业务属性的、非通用化的需求，这也是用户经常吐槽的点，“怎么你们做需求这么慢”。对平台而言，最重要的是标准化，其次是稳定和效率，其他的都可以一定程度上牺牲；
- 最致命的：业务方搭出的东西，很难复用。下次有另一个业务方需要时，可能还要重新搭一遍，累，而且烦。大多数业务方的数据需求是类似的：用户标签（任何商业模式，只要想做运营，你都要了解自己的用户）、人群分析/透视、渠道归因分析等等，这其中很多模式可以固定下来并复用；
各种数据应用（GrowingIO/GA之类）会克服平台的一些问题，比如抽象出所谓的“套件”/“解决方案”来实现场景的复用、屏蔽平台的各种细节降低门槛达到开箱即用（终于不用关心SQL调优了）。但由于产品形态相对固定，更像是一杆到底的大包大揽，没有提供可扩展的API，你只能使用它提供的功能，而很难根据自己的业务特性去定制。或者说，这些产品是面向老板or运营的，而不是面向开发的。
如何弥补平台和应用之间的gap，就是中台的使命了。其实这也不是什么新鲜东西，可能很多公司都有类似的做法，只不过没有抽象出这一层。比如一个开发做类似的功能会在自己的多个应用之间copy and paste，时间长了慢慢就会形成自己的库，更进一步可能形成通用的SDK，这就有点中台的意味了。所以说计算机科学就是一门关于抽象的科学，hooray for the layers of abstraction。
中台很难是一个单独的系统或者是一个单独的SDK（正如数据平台也不等于hadoop），它应该是多个系统、多个方法论、多个规范的总和。所以很难说它“是什么”，只能描述它“应该具有的特征”：
- 面向业务场景，而且这些场景是可复用的，相对平台而言更“具象化”，“表达能力”/“scope”更小。这是核心特征，因为中台的目的就是简化各个业务方的开发代价，从其中抽象出共性并沉淀下来。如果业务场景不够复杂，别搞中台，只会适得其反。典型的复杂业务场景就是电商中的各种玩法，这也是为什么中台战略会是阿里首先提出来的原因；
- 提供足够丰富的API/扩展点，让业务开发可以根据自己的需求自由扩展、组合。这也是中台和平台的一个显著不同。平台会提供API，但这些API往往是固定的，如果不满足你的需求，你只能提需求要新的API；而中台提供的API，必须留下业务方自由扩展的空间。比如退货流程，电商中台会提供默认的、标准的退货流程，但如果你的业务场景特殊，完全可以自己覆盖默认的实现。所以说，中台的目标用户是业务开发人员。
- 中台未必需要有“界面”，API才是核心；
- 和平台不同，中台的边界很模糊。很多东西丢给业务方自己去做似乎可以，沉到中台来做好像也行。越接近上层、离业务越近，边界就越难划分，任何系统都是如此。很多时候也不用太纠结。正如中间件层越做越厚，“向上”侵蚀了很多业务开发的空间一样。
所以不管是业务中台、数据中台、算法中台，做好的前提是你要去了解你的业务方，了解之后才可能抽象的足够好。想想从他们的角度看来，需要哪些能力，如何才能更省力，比业务更懂业务。很多时候，业务方自己会有思维惯性和死角，也不知道更好的做法是什么，需要我们去push他。如何找业务方聊，多拉一些人背书，推广自己的产品，这又是一门艺术了。
写这些文字的过程中，总觉得好像模模糊糊摸到了某些更“真理”的东西，却又觉得有些虚无缥缈。大概这就是玄学研究多了的后果吧。。。
参考资料：
技术平民化
入职蚂蚁后，终于见到了PAI的真容。简单训练了一个评分卡模型，用了下分箱、WOE变换、特征分析等组件，真tm方便，我这种算法盲也能很快上手。我也不要求自己深究各个算法的原理和调参，只要会用就很满足了。
这让我想到，近年来的各种技术热点，什么“AI”、“大数据”、“云”，随着平台化、产品化的推进，门槛真的是越降越低。“算法能力”、“数据能力”慢慢会变成每个工程师的标配，而不应该只依赖于少数“专家”。忘了在哪里看到的，蚂蚁CTO阿玺去google挖人，希望能招到优秀的大数据专家，结果人家很诧异，“我们没有这种职位啊”。因为基础设施已经足够好用，人人都可以发挥自己的想象力，而不需要被职位所限。
早些年，你懂个lucene都能横着走。。。当时也有一种论调，“我就把一个东西研究透（这个东西可以是oracle、lucene、hadoop、linux之类），死磕，只要搞明白了，我就牛逼”。不能说这种想法错吧，只能说在当今的时代，做到这点越来越难了。纯粹的技术研究、技术创新，只属于一小撮高端的人，对个人素质的要求越来越高，圈子也会越来越小。大多数人所做的，都是“应用开发”；稍微深入一点的，可能是“平台开发”；真正到kernel那种级别的，凤毛麟角。这不光是因为系统越来越复杂，更多是由于大环境“不需要”这么多高端的人。
想想也对，如果底层系统真的足够完善，留少数人维护就好了，资本家都是很现实的，靠梦想驱动的毕竟还是少数。就像AI一样，如果未来真的替代了人工，可能导致很多人失业，但这个潮流谁也无法阻挡。历史上珍妮机的发明、几次工业革命的进程，都证明了这个道理。
这些年来IT从业者越来越多，个人素质却越来越堪忧，培训几个月就能上岗，也是同样的道理，因为“不需要”。
作为民工，除了被潮流裹挟，我能做点啥嘞，我也一直在思考。好在目前各种技术壁垒还没有那么高，在平民化的过程中，还有很多机会可以挖掘。
- 首先别妄图对抗潮流，想自己闭门造个什么极其牛逼的东西，然后一朝成名天下知。这是很多技术人的通病，现实中的关键往往不在于技术如何牛逼，而在于如何把技术推销出去，一个好看的界面可能比一个O(logN)的算法重要。我也一直觉得，产品化、平台化的重要性被很多人忽视，这是一个典型的double yes问题，技术和产品不能有任意一个短板，两手都要硬。
- 其次摆正自己的定位，自己适合做什么，想清楚。我觉得我就不适合做最底层的东西，虽然我很感兴趣，也愿意去了解，但比如说想到要研究一辈子数据库，天天读论文，就觉得很无趣。很多理论的东西说的极端点就是空想，我还是希望看到自己的东西能影响尽可能多的人。以前做平台，最大的成就感不是把平台搭出来，而是有很多人来用。我也不太适合去直接面向业务，这种事需要的是商业sense和决断力，我好像从来也没展露出这方面的天赋。我更适合的应该还是造铲子，然后卖给其他淘金人。这么说来，在潮流中我扮演的应该不是弄潮儿，而是推波助澜的投机者。。。吃不到肉喝口汤也行对吧。
但话又说回来，铲子也没那么好造，作为承上启下的纽带，需要对上下游都有了解。正如开头那个PAI的例子：不要求深究各个算法，但要理解基本原理，要会用。
读后感
我喜欢看到什么有趣的就先记下来，所以有些文章已经比较久了。
java脚本引擎的设计原理浅析
前段时间一直在研究规则引擎，这篇文章写的非常好，流程引擎/规则引擎/脚本引擎，还是不太一样
RxJava2.0——从放弃到入门
似乎android开发中使用rxjava比较多，我觉得其核心价值在于简化异步调用，使程序保持简洁（还记得js中的callback hell么）。异步 + 链式调用，类似js中的promise，但java世界还没有发展出async、await之类的东西。注意异步未必等于并发，协程不也是异步么。
Reactive的本质在于事件驱动，类似eventbus，观察者模式也是同样的道理，js的eventloop也是，yarn中的状态机也是。netty中的reactor模式也是同样的原理（有叫做reactive的，也有叫做reactor的，其实都是一个东西）。
Apache Kylin 在美团数十亿数据 OLAP 场景下的实践
关键在于：1. 构建cube的过程如何优化？分层策略；2. cube如何存储，hbase rowkey编码方式；3. SQL查询如何改写成hbase查询；
高性能队列——Disruptor
关键词：RingBuffer、无锁（大量利用CAS和volatile）、cache friendly
对比ArrayBlockingQueue来看
携程金融大数据风控算法实践：A卡原来是这么回事
为什么说流处理即未来？
很激进的想法，使用流处理的state完全替代db，并在此之上实现事务特性
中间事务的那一段描述很简单，但直觉上感觉肯定有问题，不可能这么简单。。。
这种东西也不能称作强一致性，必然会被外界看到不一致的中间状态
而且啊，流处理的retraction代价这种场景不能不考虑，也许远比带来的好处多，对比db的rollback
通用唯一识别码
Leaf——美团点评分布式ID生成系统
面试中常见的问题：如何生成唯一ID？没有标准答案，关键是思考的过程。
类似的还有如何设计一个短链系统。
SQL 查询优化原理与 Volcano Optimizer 介绍
前段时间听了tidb的一些分享，介绍了sql执行时的一些优化，向量化/codegen之类的。
不过我对这块不太了解，火山模型也只是知道而已，毕竟不是专业搞数据库的，感兴趣的可以参考CMU 15-721。
一篇文章掌握 Sql-On-Hadoop 核心技术：比较全，也比较简略
Apache Kafka 从 0.7 到 1.0：那些年我们踩过的坑
介绍了kafka的发展历史，正如文中所说：“它的设计理念非常简单，就是一个以 append-only 日志作为核心的数据存储结构”
消息中间件选型分析：从 Kafka 与 RabbitMQ 的对比看全局
看点不在于kafka，而在于各种MQ特性的总结：优先级队列/延迟队列/重试机制/消费方式/push or pull/持久化/消息过滤/多租户/协议支持/顺序性/事务等等。
RocketMQ 4.3 正式发布，支持分布式事务
名义上是讲rocketmq，实际上讲了分布式事务的各种解决方案。SAGA这个东西，第一次听说。
消息事务的本质，还是两阶段提交。
Kafka consumer offset max value?：一个好玩的问题，如果offset超过long最大值了咋整
蚂蚁数据分析平台的演进及数据分析方法的应用
我入职了蚂蚁也没看到这么个平台啊。。。不过大公司内部各种轮子造的真是挺多的。
文章讲的还是非常全面，不光是数据分析领域，对数据平台各个组件的介绍也非常有借鉴意义，对数据分析平台的痛点和演进过程分析的也很好，虽然有点抽象。
3.0版本虽然看着好像很nb，但从介绍的一些技术来看，似乎还是为了加速查询？
BAT 程序员们常用的开发工具
似乎最开始有个“阿里程序员常用开发工具”，现在演变出“BAT程序员常用开发工具”了。。。文章内容还是比较实用的。
碎碎念
我一直在想数据的价值要如何体现，但不得不悲观的承认从数据中淘金是很难的。如果不是被逼的，没人愿意做这种苦力活。如果还是以前那个流量红利的时代，谁还关心什么数据啊，野蛮成长就好了。
虽然大家都承认数据很重要，但数据本身很难作为核心业务（又不能直接卖对吧），更多还是提供一些附加价值。目前看来最主要的价值体现在运营上，比如用户运营、流量运营。而且大多数使用方式还比较初级，属于“验证想法”：我有一个假设，用数据来验证是否正确。而大家一直在探索的，是如何让数据“产生想法”，目前还没有很好的解。在大数据和AI的发展过程中，总会出现所谓的“万能论”。什么东西搞不定了，让算法同学解决下；什么现象解释不了，让数据同学看一下。而且一个很危险的倾向是为了用而用，什么都想往算法上面靠，反而把事情搞得很复杂。正如前几年比特币很火的时候，养个鸡都要用上区块链。很多时候，基于规则的解决方案往往比一个不可解释的算法更好，现实中的大多数系统也是规则+算法的结合。即使是在算法领域，LR这种容易解释的模型也比ANN这种难以解释的应用范围大得多。
