1.1 数据中台概念的起源
尽管大数据产生于硅谷，数据中台与大数据关系密切，但硅谷却没有数据中台这个名词，因此，我们首先要来看看“数据中台”的概念是如何在其倡议者阿里巴巴内部产生的。下面的故事想必很多人都听说过。
2015年年中，马云带领阿里巴巴集团高管拜访了一家芬兰的小型游戏公司Supercell。让马云及其高管团队感到惊讶的是，这家仅有不到200名员工的小型游戏公司竟创造了高达15亿美元的年税前利润！该公司典型的开发模式是以小团队为单位的单独“作战”，每个团队不超过7名员工。每个团队都可以自己决定开发什么样的游戏产品，然后以最快的速度推出公测版，如果不受欢迎，就立刻放弃，寻找新的方向。这种开发模式使Supercell能非常快速和敏捷地找到玩家喜欢的方向，从而更容易开发出能够迎合玩家需求的游戏产品。
而Supercell之所以能够支持多个团队快速、敏捷地推出高质量的游戏作品，其强大的中台能力功不可没。因此，在拜访Supercell的旅程结束之后，马云决定对阿里巴巴的组织和系统架构进行整体调整，建立阿里产品技术和数据能力的强大中台，构建“大中台，小前台”的组织和业务体制。
当然，Supercell的研发模式并不是什么革命性的创新，绝大部分硅谷公司也有类似的模式：本来就不大的公司被分成若干个小组。这样做的好处是各小组可以快速决策、研发并将产品推向市场，而不需要重复开发游戏引擎、数据分析、服务器等后台基础设施和服务。这里，“游戏引擎”可以看作业务中台，“数据分析”可以看作数据中台，“服务器等后台基础设施”可以看作PaaS/IaaS平台，也就是有些文章中所说的技术中台。
实际上，虽然硅谷并没有“数据中台”这一叫法，但硅谷的公司早已自然形成了中台的意识。从早期的中间件（Middleware）、面向服务的架构（SOA）到后来的IaaS/PaaS/DaaS平台、微服务（Microservice），都有中台思想的影子，都来源于避免重复造轮子、快速迭代、数据驱动、业务驱动这些硅谷工程师文化的核心理念。国内类似的概念“技术中台”就源于中间件、PaaS平台。但是这种中间件、平台、中台的功能一般并非由一个顶层设计得出，而是一步步建立起来的。在硅谷的企业中有一个非常重要的理念就是不要做“过早优化”（Premature Optimization），也就是说，不要在不需要的时候进行优化。一定要先完成功能再优化，因此不需要中台的时候没有必要刻意建一个大而全的中台。当然，在建设数据中台的不同阶段可以使用不同的技术，只要保证中台建设能够平滑过渡即可。
下面就来简单介绍笔者曾在硅谷负责建设的两个典型大数据项目，看看它们和数据中台的关系。
1.1.1 艺电的“数据中台”改造
EA（艺电）是一家总部位于硅谷的知名跨国游戏公司，创造和发行了众多深受游戏迷喜爱的游戏，例如《FIFA足球》《Madden橄榄球》《NHL冰球》和《NBA篮球》等体育游戏，令军迷们狂热的《战地》及《星球大战》系列游戏，以及经久不衰的《模拟城市》《模拟人生》《植物大战僵尸》等游戏。
这些游戏都是由EA位于全球各地的游戏工作室开发的，但是游戏里所涉及的数据分析工具却是由位于硅谷总部的大数据团队提供的。在有统一的大数据平台之前，EA的每个工作室都需要开发自己的大数据平台，编写自己的大数据分析程序。各个工作室的数据能力参差不齐，数据质量得不到保证，有的产品甚至完全没有数据分析。各个工作室之间无法共享数据和用户资源，总部在汇总全集团的营业数据时也费时费力。这可以说是一个非常典型的数据孤岛的情况。
2011年，EA开始逐步建立全局大数据平台（类似于具有数据中台功能的平台），将各个工作室的数据逐渐汇聚到这个全局大数据平台上，并为各个工作室提供统一的数据分析和数据服务工具。各个工作室不再需要自己维护大数据平台，也无须自己雇用大数据平台开发人员，它们既可以使用集团的数据分析系统得到自己需要的业务报表，又可以使用系统提供的反欺诈、产品推荐等服务，专注于业务使它们能够快速推出新产品。同时，由于各个游戏的数据得以打通，用户数据得到统一，EA可以构建更全面的用户画像，帮助工作室更精准地为用户提供个性化服务，提升用户体验。而且，集团总部能够快速且自动地获得全局的运营信息，而无须等到各个业务部门提交月度报表之后再手工合并和审核。
通过大数据平台的建设，在2012年和2013年被评为最差劲体验游戏公司、营收逐年下降的EA，一举华丽转身，2014年被评为最佳体验游戏公司之一，2015年更是创下43亿美元的营收历史新高。
本书作者之一宋文欣作为主要技术和团队负责人带领了EA大数据平台团队的组建以及该平台的设计和建设。第16章将详细描述其类似于Supercell的平台的建设历程。
1.1.2 Twitter的数据驱动
Twitter是硅谷社交三驾马车之一，其陌生人/公开社交与Facebook的熟人/私有社交、LinkedIn的职场社交都对互联网产生了极大影响。这三驾马车出现于2006～2008年，在时间上与此相耦合的一个现象是大数据的发展。Facebook成立于2004年，Twitter成立于2006年，LinkedIn成立于2002年（但发展期是2006～2010年），而作为大数据的启动项目，Hadoop的首发时间是2006年。
熟悉大数据早期发展历程的业内人士都知道，虽然Hadoop起源于Google，由Yahoo!开源，但是Facebook、Twitter和LinkedIn却是硅谷早期推动大数据发展的核心力量，Hive、Pig、HBase、Mesos、Kafka、Spark、Storm、Thrift、Presto、Parquet以及其他很多现在广泛使用的大数据组件，都是由这三家公司开源或提供最早的企业级应用和支持的。究其原因，除了这几家公司的工程师文化和对开源的推崇之外，更重要的是实际业务的数据驱动需求，因为它们都需要通过分析海量的数据来推动产品研发、用户拓展和核心营收的增长。
以Twitter为例，整个公司的管理都基于数据驱动的理念，而其底层支撑是一个全局共享的大数据平台。从CEO需要的BI部门实时业务报表、广告部门的精准定位、产品部门的个性化推荐，到用户拓展部门的增长黑客技术、反欺诈部门的异常监控、研发部门的实时产品反馈、运维部门的智能运维，相关的数据应用都通过统一的数据工具运行在同一个大数据平台之上。
整个平台中的数据能力共享和复用随处可见：产品部门研发的用户画像可以被广告部门用来精准定位目标客户，社交图谱被用来实现用户拓展；反欺诈部门的机器人识别功能被广告部门用来识别恶意点击，被BI部门用来精确统计日活用户；广告部门开发的实时数据处理体系被产品部门用来提升推荐的实时性；诸如此类。
公司从2011年的300人发展到2014年的4000人，大数据平台从80台服务器的单纯Hadoop集群扩展到8000台服务器的核心数据处理平台，都没有出现数据孤岛、应用孤岛及重复造轮子的问题。
更为重要的是，因为有了强大的数据能力核心平台，Twitter的产品迭代速度得到大幅提升。在2011年以前，开发和发布产品的流程非常冗长，产品经理需要到各个部门调研可以使用的数据，并协调数据的生产化问题。在产品推出之后，需要专门的数据工程师支持，定制单独的数据看板和报表才能拿到产品的反馈。在大数据平台逐渐完善之后，产品经理可以直接在平台上探索现有的数据和各种API，与研发人员合作使用各种数据服务快速形成产品原型，然后通过数据平台提供的测试框架快速发布测试，在发布后可以直接通过平台提供的数据看板查看用户反应，而无须自己编写程序。整个产品的开发和迭代流程从以月计改为以周计，活跃用户数也从2011年不到1亿增长到2014年接近3亿。
本书作者之一彭锋作为Twitter架构师委员会中负责大数据体系的高级架构师，在大数据平台的建设中负责架构设计和项目审计，经历了从80台机器的Hadoop集群到8000台服务器集群的整个建设历程。本书会穿插介绍Twitter大数据平台建设的一些思路和经验。