什么是中台
最近一段时间，"中台"这个概念火起来。感觉过去几年没人提的东西，一下子成为了众人口中的"我们公司已经做好多年"的产品。当然，很简单就能查到阿里在15年就提出过"大中台，小前台"的定义，大力发展中台，但是，很多公司还走在平台化的路上，中台，还只是概念。
在公开的资料里，对中台没有什么明确的定义(一如"云"的定义一样，笼统概括)，按照我的理解，就是前台(具体业务)与后台(基础服务)之间的，既贴近业务，又能抽取共性的部分组成的。核心词是通，把公司各个产品从孤舟链接起来，铁锁连舟，互通有无。
中台包括业务中台，移动中台和数据中台
- 业务中台
公司中各个产品的用户信息/订单/支付等信息打通，更利于子产品的发展。 - 移动中台
一如开发游戏的unity引擎，移动中台的重点是平台无关，包括客户端开发框架/网络/测试/运维/消息推送等内容。能做到快速适应各种平台。 - 数据中台
对数据比较熟悉，数据中台重点说一下。
数据中台
如果说业务是按产品独立的，那数据就有可能是按照功能独立的。数据孤岛现象非常明显，使用数据难度很大。在此基础上，数据中台应运而生。
一言以蔽之，数据中台，就是和数据相关的内容整合到一起，对外提供一站式的数据服务。
数据相关的内容，包括
- 基础服务
基本的大数据框架，Hadoop，spark，hbase，等的安装优化维护。
作为服务器的硬件，依然可以由基础架构部门负责。
- 日志规范
对公司各个产品的日志制定唯一规范，包括共用日志统一名称，非共有日志命名规则等。 -
数据仓库
数据接入，ETL，数据仓库，数据主题。 -
数据分析/数据挖掘/用户画像
全局分析/产品分析/公共画像/产品画像。 -
数据工具
报表系统/多维查询系统/元数据/调度/质量监控。
数据流程以及工具平台架构图:
架构图
虽然这就是一个标准的数据流图，但是对于不同时间段，不同数据量级，不同需求紧急度的公司，当然有不同的处理架构方法。
想象一下下面几个公司，应该怎么办。
- 初创公司，产品上线只有需要看到数据
- 拿到融资，产品稳定，用户量上来了，基于更方便以及更安全的角度考虑，需要自建数据中心。
- 已经有数据团队，和比较成熟的大数据平台。
我的建议
- 接入第三方统计平台，比如GA，百度统计，友盟等，根据规则发送数据，查看统计结果。
- 从无到有，需要一个时间，直接给一个完整的数据架构图，因为东西太多，让人有无从下手之感，可能一个季度过去了，还没有什么产出，期间业务团队怎们办。这种情况下，要双管齐下，按部就班搭建数据中心平台工具的时候，另外建立数据流，没有flume+kafka收集数据，就定时在业务服务器scp/rsync数据到数据服务器，没有mr/spark来做解析，就手写java/python甚至shell来解析，聚合数据，没有olap平台，就把数据写到mysql里，进行展示。数据建设的过程，不应该影响业务团队的数据使用。(自从16年开源的clickhouse问世之后，这个过程变得简单太多了)。
- 没说的，根据需求，缺什么模块就加什么模块吧。
总之，数据工作不是一成不变的，因地制宜才能更好的建设。
小结
这些所有的事情，都不是新的工作内容。数据从产生到使用，线路很长，不同部门的人都参与其中的不同模块，每个人只关注自己负责这一小块，知其然不知其所以然，想了解更多，横跨多个部门的结构也让人望而却步，对个公司以及个人发展都不友好。如果大家在一个架构里面，独立于业务来对数据进行处理，才真是一站式的数据服务。
