数据中台的前世今生

 容器服务Docker K8S     |      2020-07-26 00:00:00

就像20年前的虚拟化，5年前的容器化，这两年的中台化似乎也是势不可挡。但凡跟互联网沾边的行业，金融、零售、通讯都开始规划各自的中台化战略。抛开行业属性比较强的业务中台，我们今天就单独来讲讲数据中台的发展过程。
说到中台，就不得不提一家公司：芬兰的游戏厂商Supercell。2015年年中，马云带领阿里巴巴集团高管，拜访了位于芬兰赫尔辛基的移动游戏公司Supercell。这家成立于2010年，仅凭政府借贷的30万欧元起家，从芬兰30平米小隔间走出来的游戏公司在短短4年时间里凭借《海岛奇兵》《部落冲突》《卡通农场》这三款游戏获得了17亿美元的收入，因此惊动了马云。
Supercell首先带给马云的是组织的变革。Supercell将组织按产品线分割，而非传统的职能分割，管理以自底向上的方式，其创始人埃卡·潘纳宁在接受采访时就表示希望成为全球最“弱”的CEO，所有决定由游戏团队来做，毕竟研发者才是最接近玩家的，他们比任何人都更清楚玩家的需求。扁平化的管理也使得开发流程更加高效，敏捷的不仅是开发团队，还包括整个组织。由此阿里开始了根据产品进行事业群编制。
1.png

    解决了组织架构，为满足企业在不同时期所面临的外部并发，技术架构也必须是弹性扩展的，为此Supercell在成立第二年（2011年）就完成了应用的微服务化与数据库层的切片。甚至来说Supercell的微服务更轻量级，所有的游戏都复用一套网关代理、主页模块、匹配模块和战斗模块。整个组织使用一套高可用的组件库，一种开发语言，一个团队即One Repo，One Language，One Team。这**比阿里的三One概念早了整整八年**。

2.png
说到这里，大家多少可以看出一些端倪：阿里的组织和技术沿革很大程度上参照了这家公司的历史，那这家公司又是怎么发展起来，并且发展到什么程度了呢？
最早的时候（2010年），Supercell的游戏很单一，数据量也不大，联机系统可以满足一切的查询/报表请求，因此对于数据汇聚集中分析的需求并不大，处在数据库阶段。
2020-07-26_1-14-57.jpg
随着数据量的增加，OLTP无法同时支持事务处理和资料调取的请求，OLAP的业务开始多了起来，尤其是需要对用户的一些行为做分析，这些行为事件发生在客户端也可能在服务端，需要有一个统一的整合平台即数仓进行统一归集分析，Supercell选择了AWS的S3做为存储，并通过QlikView做界面展示。
2020-07-26_1-31-14.jpg
由此便引申出了中台能力发展的第二个阶段，数据仓库阶段，这一阶段为日后的数据中台建设提供了全域数据，即生产资料。
2020-07-26_1-27-39.jpg
随着游戏种类以及实时计算需求的增加，2013年下半年，Supercell终于考虑添加流式管道（Streaming Pipeline）作为数据缓冲层，由于之前和AWS的良好合作，这次的流管产品多数团队也是投票给了Kinesis，相对于Kafka，它的运维更加简单，体验更好（天生与AWS管理界面集成），后续可以对接各种事件消费者，不论是实时查询面板，第三方集成，实时分析，还是通过统一的KV日志格式集成入库S3。
3.png
4.png
这一阶段，仓库进化为数据湖/大数据平台，具备了计算能力和流式数据的处理能力，可以提供算法输出，从而更好地服务前端应用。
2020-07-26_2-01-35.jpg
同年在数据湖设计上，Supercell使用Azkaban批量工作流任务调度器将CSV数据加载到AWS的Vertica数仓中，数据科学家通过开发接口对历史数据进行分析，形成一些数据服务，对内或对外输出。
5.png

这个架构在之后几年里遇到了新的瓶颈。首先Vertica集群的负载达到的峰值，第二在ETL的时候查询会变得缓慢，第三数仓的扩容花费巨大，第四存储与计算耦合紧密，第五再大的宽表数据库都会有列的极限。注意到这些问题之后，Supercell致力于：
  • 限制Vertica的数据存储量；
  • 将存储与计算资源切割；
  • 将ETL流程与查询流程切割；
  • 维护单一来源的置信数据；

  • 利用云的便利性优化资源使用。

        到2018年，公司决定将Amazon S3作为单一置信来源，以Parquet列表的形式存放数据，将Amazon EMR用作ETL转存目标，原来的Vertica只用来存放计算结果（例如账号、统计数据和KPI）而不是原始数据。

    6.jpg

    这样一来，Azkaban还是控制ETL流程，只是这次加载到Amazon EMR托管集群平台，然后以多张Parquet列表的形式存放到Amazon S3中，因为公司已经对数据行数做了切片，使用列表存储更能提升存储效率。

    分布式的S3作为唯一置信源，消费使用与列表更加契合的Athena作为查询工具，数据科学家可以到计算平台EMR中查看实时数据并做分析，包装成实时数据产品，也可以通过界面工具到置信源S3或结果数仓Vertica中查看OLAP大数据并进行建模分析，生成数据产品。

7.png
在2018年完成改造之后，由于EMR的延展性，可以瞬间扩展出大量的数据集就很好地解决了列宽的问题，并且有效地将存储与计算分离（EMR负责计算，S3负责存储）。在ETL时可以通过计划任务扩建一个集群跑ETL，跑完之后释放资源。而且EMR的环境对于数据科学团队来说更加友好。
2020-07-26_2-23-33.jpg
至此，数据中台的生产要素已全部构建完成，包括了数据（生产资料）、算法（生产工具）和算力（生产者），形成了人工驱动，自动学习的服务模式，支持绝大多数业务的同时实现了企业自身数据价值的最大化。

展望未来，数据分析能力的强大并不能解决业务对于实时性的要求，而从各大云厂商纷纷致力于自身消息队列产品的开发来看，距离纯事件驱动的分布式消息中台不会太远，传统的分布式HDFS存储以后只能作为消息中台的归档系统，而像ETL，结构化数据库会渐渐淡出历史舞台，至少在互联网，大数据类的行业会是这样。