4月18日下午，智领云联合创始人兼CTO，前EA（艺电）大数据平台高级工程经理宋文欣博士首度在智领云技术直播中开讲，向参加直播的数百位观众讲述了硅谷“数据中台”的故事。实际上，经过前几次的直播，很多人已经对数据中台有了更深入的了解。不过，可能大家还有这样的疑问，就是中国的数据中台市场如此火热，而国外数据中台就没有什么声音。其实，事实并不是这样，硅谷的公司其实已经早于中国建设了所谓的”数据中台“。只不过，在国外，并没有数据中台这个称谓，而是统一以数据平台的名称命名，但是这个数据平台已经具备了我们所说的数据中台的全部功能。
那么，作为全球技术风向标的硅谷企业的“数据中台“到底什么样，他们的“数据中台”是如何建设的？想必很多人对此多充满着好奇和疑问，而宋文欣博士从美国纽约州立石溪大学计算机取得博士学位之后就开始在硅谷从事大数据方面的工作，并曾经任职美国四大引擎之一的Ask.com以及久负盛名的美国EA（艺电），因此，由他来讲述硅谷“数据中台”的故事，称得上是恰如其分。

硅谷的“中台论”

宋文欣博士在直播开始就强调，在硅谷，并没有“中台”这个称谓，而是统称为数据平台，但是硅谷的数据平台实践与数据中台的理论是基本吻合的。中台由阿里巴巴的马云提出，并付诸于实践，形成了阿里“大中台，小前台”的战略。之后，“中台”开始风靡一时。
中台的火热，实质上也反映了中国数据驱动热潮逐步升温，正在同更先进的技术同步的趋势。虽然硅谷没有中台这样一个词，但硅谷的各厂商很早就已经开始了“中台”的建设，比如说EA，众所周知，中台的故事源于SuperCell这个游戏公司，它之所以发展的非常好，以一个小小的规模就能够创造很大的价值，就是因为它有一个统一的游戏开发的平台或者称之为中台。EA同样也有一个这样的游戏引擎开发平台，就叫做寒霜。寒霜是一个拥有可视化界面，可以非常方便地加载各种地图，做出各种光影效果以及音效的技术中台，最初是为《战地》系列游戏打造的。通过寒霜引擎，可以很轻松实现控制诸如雨点的大小，雪花片的形状等等功能。现在，寒霜引擎已经成为EA几乎所有游戏的开发引擎，这极大的提高了EA游戏的开发效率，这就是技术中台在硅谷实践的一个典型的例子。

那么，像数据中台的例子，在硅谷就比比皆是了，比如说Google的个性化搜索、Facebook的用户增长、Twitter的兴趣图谱以及LinkedIn的职场网络的建立，都离不开数据中台的背后支持。尤其共享经济领域，也是非常的明显，像Uber、Lyft、Airbnb，在他们的应用里面，这种个性化定制就是很典型的数据中台的应用。

EA（艺电）的“数据中台”建设

宋文欣博士在直播中重点讲述了EA构建数据中台过程。众所周知，EA是一家著名的游戏公司，闻名遐迩的《FIFA》、《战地》、《麦登橄榄球》系列等千、百万级销量的游戏大作均出自EA之手。在EA内部，按照游戏硬件平台，分为主机/PC平台游戏和移动游戏两部分，主机游戏就是PS4、XboxOne、Switch等游戏主机平台的游戏，EA的主要游戏大类是体育类游戏，像《FIFA》系列就是为EA贡献营收最多的游戏，还有《麦登橄榄球》，也是美国最热门的体育游戏。除此之外，战斗射击类游戏，像《战地》系列也久负盛名，是由EA在瑞典的Dice工作室开发。另外，还有一个比较有意思的游戏就是《模拟人生》系列，这是个经久不衰的游戏，到现在已经有了20年的历史。在移动端的游戏就更多了，比较知名的有《植物大战僵尸》系列等。

EA游戏的种类很多，分布在各种平台之上，有近百个游戏品种，这些热门游戏的数据量是非常巨大的，以《FIFA》为例，在2019年，《FIFA》拥有4500万名玩家，各种平台囊括在一起，玩家们每90分钟完成50万场比赛，3百多万脚射门，接近2百万个扑救，99万个进球。另外一个是《战地》，这个射击类游戏，在2017年的时候也有超过两千一百万游戏玩家，每天大约产生1TB的数据。《模拟人生》系列，也在全球有超过两千万的游戏玩家，在20年间，一共卖出了两亿份。还有去年一个大火的游戏，《Apex英雄》，在72小时内，玩家就达到了一千万，这个数字还在持续增长。最近，由于疫情，在线游戏玩家剧增，EA的服务器正在经受着巨大的流量，相信会不断刷新一些游戏数据的记录。

那么，EA的数字化的状态是怎样的？上图是EA在2012年以前的一个状态，当时EA的数字化建设基本上是比较初级的，是一个烟囱式的架构。每个游戏工作室、业务部门基本都有自己一整套的数据分析流水线。当时，基本上不可能把这些跨游戏平台的数据、跨不同游戏的数据以及跨部门的数据，整合在一起来分析。彼时，EA在玩家心目中的形象也不是特别好，2012年的时候，EA被美国消费者杂志评为最差劲的公司。那时，EA的玩家数量在减少，游戏时间也在下降，游戏的故障事件频发，整个EA处于一个必须变革的状态。

痛定思痛，EA提出了“Player First“这个理念，开始构建数字化驱动的架构，建设大数据平台。EA首先调整了组织架构，打破了各个部门运营自己的数字驱动架构的孤岛模式，把所有的数据标准，数据规范的制订工作交给了宋文欣所在的大数据部门，这个大数据部门重点发展了两个团队，一个是产品团队，负责数据规范和数据标准的制订，与各个游戏工作室以及业务部门商讨，共同制订EA的游戏数字字典，所有游戏的发布都要经过产品团队的确认以后，才能够发布。另外一个团队就是大数据研发团队，这个研发团队从最开始的时候，只有三个工程师，经过多年的不断成长，到后来已经发展到大约有60个人的规模。而经过大约一年的打磨，EA的数字平台已经初步形成。各个游戏工作室、业务部门的数据都会从一个统一的平台汇聚到以Hadoop为基础的一个数据平台上来，是一个统一的Data Warehouse，有统一的算法去进行各种分析。像玩家趋势分析、玩家档案，包括市场推广分析等组件都已经统一到了一个数据应用平台之上，整个延时已经缩短到了以小时为单位，而不像以前，一般需要一到三天时间才能完成统计。

EA“数据中台”建设的步骤

接下来，宋文欣博士具体讲述了EA数据中台建设的详细步骤。
首先，EA建设数据中台的原则就是按照业务部门的需求和痛点，逐步来建设大数据平台，而不是说为了做大数据而做大数据，这是一个基本的原则。EA的数据中台，要服务所有的游戏工作室及业务部门，涉及到游戏设计开发、在线服务、运营状况分析以及反欺诈等方方面面。在游戏市场推广方面，也要能让市场部门快速获客，让客服部门能够分析出玩家的热点投诉。同时，对于高层决策，则支持的更多，包括月报、季报、营收预测、战略决策等等。所以，EA整个数据中台，就是基于公司的需求和痛点，逐步地去解决和建设的。

而建设的第一步，就是要能够快速的迭代。最开始的时候，EA大约花了一个季度的时间，建立了一个30个节点的集群，也就是将游戏数据从各个游戏平台汇聚到大数据平台，提供一些基础的数据浏览、查看和下载功能。在这个阶段，业务部门的能力还是非常有限的，只能够通过界面，把数据下载，然后导入到自己的Excel里面去做一些分析和报表，还可以在自己的笔记本，客户端上来做一些简单的查询，功能非常有限。但是这个阶段是非常重要的，因为各业务部门都希望快速的见到一些成效，如果做一个很大的规划，花很长时间才能够让大家看到效果，相信各个业务部门对大数据平台的信心会随着时间的推移，逐步下降。这就是数据中台建设的一个非常重要的方法论，即一定要能够快速迭代，快速见效。

接下来的第二步就是工具的开放，大数据平台或者说数据中台很重要的一点，就是业务部门要能够自助的进行数据的探索，要能够快速利用大数据平台上的工具自助的去发现市场的动态，然后对市场变化进行反应。如果说所有的数据分析，工具的使用以及市场变化的洞察都需要依赖于大数据研发部门，那么，这个工作是无法展开的，因为EA有众多的业务部门和游戏工作室，有众多不同的数据分析的需求，这个是逐渐发展中的大数据研发团队所无法去满足的。因此，第二阶段重点的工作就是开发一个自助的数据分析工具，让业务部门能够通过一些简单的操作，就能够去做自助式的数据分析。同时，大数据团队也研发了一些针对高级工程师的功能，例如，业务部门在做完自助分析以后，如果觉得这个作业是需要长期的运行，比如说，是每天自己的日常报表的一部分，那么就可以把它发布到生产服务器。这样的功能，极大地解放了业务部门的生产力，也充分调动了业务部门使用“数据中台”的积极性。

第三阶段，就是能力的复用。在能力复用方面，也还是要从需求的痛点出发，那么EA首先要满足的痛点，就是《FIFA》的痛点，因为EA几乎50%的营收都来自于《FIFA》系列游戏。而《FIFA》早期的主要痛点之一，就是在游戏中会有人利用一些欺诈行为售卖游戏币获利，为此，EA在《FIFA》中首先推出了反欺诈系统，这个系统是为《FIFA》开发的反欺诈模型，在这个模型推出后，它每个月能为《FIFA》挽回将近两、三百万美元的经济损失。在这个模型逐步完善并得到足够的反馈、稳定之后，再将这样的能力抽象处理，共享和复用，并推广到其他的游戏当中，这就是数据中台里面另外一个重要的方法论，就是要能够把数据共享，复用的能力体现出来，而不是只为某一个特定的部门或者特定的公司提供一个特定的功能。

第四阶段，就是形成数据闭环，也就是说，数据一定要回到业务当中去。数据回到业务中有两种途径。一种是间接的方式，就是通过对数据的分析，掌握市场的动态，来指导经营的方向以及措施，来提升业务。而另一种直接的方式就是把数据融入到业务当中去。在游戏领域具体来说，做的工作就是根据玩家的历史行为，为玩家动态地推荐游戏的难度，或者是动态地组织游戏战队。在这个阶段，系统把大量的历史数据，通过人工智能、机器学习的算法，让这些数据形成有价值的分析结果，然后回馈到业务当中去。到这个阶段为止，可以说初步的数据平台，已经基本成型，各个环节都已经打通并形成了数据闭环，这就是EA建设数据中台的基本步骤。

EA数据中台建设四原则

在EA数据中台的建设其实还有四项基本原则。

第一个原则就是拥抱开源，不重复造轮子。其实在硅谷，几乎所有的科技公司都是使用这样的一个方式和原则，在大数据领域尤其明显。众所周知，Hadoop生态有将近几百个组件，大部分都是由硅谷的高科技公司研发。大家使用这些大数据开源组件的原则，也是基本上会采用经过其他公司验证过，比较成熟的系统。硅谷的工程师文化还是比较浓厚，每个科技公司基本上每周都会举办一些技术的沙龙，讨论一些技术问题。一般在开源系统的使用中如果遇到了问题，就可以直接向这些开源代码的贡献者提问或者是参加他们组织的技术沙龙，面对面的去交流，一般很快就会得到反馈。比如说有些系统中没有的功能，不用等到提交阶段，就可以先拿到这样一个补丁，把它补充到自己的系统中，然后等到真正提交之后，再去升级，从而可以更快地解决遇到的问题。这样的事情经常发生。所以，拥抱开源，不重复造轮子，这基本是硅谷的科技公司共同遵循的一个原则。

第二个原则，要使用基于公有云的混合架构。因为数据中台建设的思路是快速迭代，那么在公有云的架构上，实现快速迭代是非常方便和灵活的。EA的大数据平台，绝大部分的资源都在AWS上面，但是一些比较关键的资源，像EA的游戏服务器，实时采集系统等还是放在了私有云的架构中。因为这些服务的实时性要求很高，EA希望能自己掌控这些资源，然后在私有云和公有云之间，搭建了一个专有的高速网络，从而构建了一个混合云的架构。但是，作为混合架构有一个问题，就是虽然我们每个季度都会与亚马逊的产品团队进行讨论，来解决一些问题，但是公有云普遍存在的一个问题就是，它不可能为某个用户去做一些快速的修改或者迭代，所以EA在公有云上基本就是使用一些基础的资源，像Kafka、Hadoop这样的大数据组件还是我们大数据团队自己来搭建和维护。

第三个原则就是汇集所有数据到统一平台。这个说起来容易，但是做起来非常难。因为EA在不断地收购各种游戏工作室，游戏工作室的分布是全球性的，像《战地》，工作室是在瑞典，《Real Racing》的工作室是在澳大利亚，研发《FIFA》的工作室是在加拿大。每个游戏部门都会说自己有特殊的情况，希望保留自己的一套数据平台。因此，要真正的把所有的游戏数据全部汇聚到统一的平台，操作的难度很大。但是我们一定要坚持这样一个原则，所以，我们花了很长一段时间，终于把所有的游戏的数据都统一到了一个平台上，这是一个非常关键的原则。

第四个原则就是重点投资人工智能、机器学习这些“皇冠”组件。因为在游戏领域，如果能通过人工智能、机器学习，把游戏数据反馈到游戏当中去，特别像推荐算法，能够动态的调整游戏的难度，动态的组织游戏战队，那么这对于游戏玩家的体验会有一个很大的提升，这也是一个重要的原则。在这方面，EA的大数据部门花了很大的力气去投资，不光是人才，还有技术的投资都做了很多工作。这就是EA数据中台建设遵循的四个原则。

EA的数字化驱动架构

EA数字化驱动的架构如上图所示，是一个称之为Wholesale Engineering的架构。这个数字化驱动架构，是针对EA所有的游戏工作室、部门来设计的，是一个设计的准则。但在实际的建设过程中，并不是一开始就去做这样一个通用的系统。虽然总体原则是要保证这个系统最后是服务所有的游戏工作室和部门，但是具体到每个组件，每个子系统的时候，都采用的是由特殊到一般的建设过程。如前所述，我们首先是服务EA最盈利的部门《FIFA》团队，解决它的问题，通过解决《FIFA》团队的痛点和难点，再来解决其他游戏部门的问题。在此过程中，把其中一些可以共用、能够复用的部分抽象、共享出来，变成一个开放给全公司使用的服务。是这样一种循序渐进的建设方式，而不是说一开始就设计一个大而全的一个架构，企图来适应所有的游戏工作室和业务部门，这是不现实的。因此，我们的整个建设过程是逐步渐进的方式，最后达到的目的是Wholesale Engineering。

这个架构，首先要提的是命名的规则，基本采用的是以江河湖海这样比较容易记忆的单词来描述各个子系统，因为在EA这样一个全球性的公司中，需要有一些比较规范的词汇来描述组件，我们用River来描述数据的采集，Lighting表示快速的实时采集和处理，主要采集手机、游戏客户端以及PC端的实时游戏数据。Tide组件表示批处理，主要是处理游戏服务器的数据。

我们首先有一个基于Hadoop的分布式存储，称作Ocean，是一个不断扩展的系统，在分布式存储上面，构建了一个叫做Shark的组件，是整个ETL作业的组件，有几千个作业在同时运行，不断进行各种统计分析工作。在作业调度方面，使用Oozie开源软件来进行作业调度，后来也对Oozie做了一些改进，因为Oozie里的作业上下游分析不是特别好，还有一些作业的依赖描述也是非常不清晰。因此，我们对Oozie做了两个改造，一个是在Oozie上面做了一层数据血缘分析，也就是无论是一个作业或者数据表，都可以在很短的时间，从几千，上万个作业中分析出哪些表是这张表的上游，哪些是它的下游，哪些作业是产生数据的，哪些作业是消费数据的作业。为什么要得到这样的信息？因为在整个运维的工作中，经常有大量的这类工作需要去做。有些作业要重新运行，因为游戏服务器有时候会出现一些故障，那么数据输送的不及时，有时候就需要补发一些数据，那么一旦数据发生补送以后，就要重新运行一些作业，因此要很快的去定位到到底有哪些作业需要进行这样的操作。第二就是作业依赖的关系不是特别的好。通常，一个作业完成以后要能够通过消息机制，通知下一个作业马上进行，但Oozie在这方面做得就不是很方便，需要定义复杂的数据依赖。因此，在这个机制上面我们也做了一些改进，对于ETL作业，基本上都是用Java来写MapReduce作业，还有Hive作业，后来还加入了一些Spark作业，这三类类型的作业比较多。

在数据处理的下面一层就是各种数据仓库、数据存储的子系统。从左往右，最左边是Surf，是数据科学家使用的人工智能机器学习模型库，这些模型数据都保存在Surf中。右边是Black Pearl ，就是实时数据仓库，Black Pearl用的是Couchbase，基本上类似于像Redis那样的基于内存的存储架构，它主要是存储像标签系统的结果以及一些缓存的数据。Pond是一个数据探索的工具，Pond是提供给业务部门进行数据探索的工具。它会不断从生产系统，也就是Ocean中拉取最新的生产数据。Pond的探索能力是很强的，不仅可以探索最近24小时，最近几天内的一些热数据，还能够去加载一些冷数据。在Pond的整个建设过程当中，我们还做了一些工作，主要是做优先级的管理，因为Pond上面每天有四、五百人运行作业，有将近五、六百个作业在上面运行，这个优先级管理是很重要的，我们还做了邮件通知，每个人在运行一个作业以后，通过邮件来通知业务人员。还有一个重要的功能就是统计分析以及计费的功能。实际上，Pond也是一个用来考察各个业务部门对大数据平台使用频率、频次以及价值的衡量的工具，因此，管理层经常需要这样的数据。同时，这也是对业务部门的一种压力，有了这个统计，就能够对每个部门的价值进行数据的分析和衡量。最右边是Pearl，就是传统的数据仓库，最开始用的是Teradata，后来因为Teradata相当昂贵，换成了AWS的Redshift。在数据仓库背后运行着各种BI工具，像Superset这样的可视化工具，都运行在这个传统的数据仓库之后。

接下来是数据服务层，就是把数据能力开放出来，以服务的方式提供给各个游戏工作室、业务部门来使用。除了一些BI工具之外，数据服务中包括的另一个重要的工具就是异常检测。异常检测有两种，一种是数据的异常检测，另一种是运维的异常检测，比如游戏服务器的网络状况，这是游戏发布以及游戏运行期间非常重要的一个指标。EA之前经常会出现区域性的网络故障，玩家对此抱怨很多，而异常检测可以极大地改善这种情况，减轻运维部门的压力，使他们能够及时获知哪个区域有网络问题，马上进行修复。游戏分析则是比较常规的动作，比如像DAU、游戏类购买情况等等，很多部门可以把这样一个接口服务，做成实时大屏放在业务部门来查看自己业务相关的数据，而且还可以自己定义、探索相关数据。如果有能力比较强的数据分析员，也可以用编程式的方式来访问这些数据，并接入自己的系统。虽然是把数据分析的数据化驱动架构统一到一个平台，但我们还是给了各个游戏、业务部门一定的自由度，就是他们可以通过接口服务，把数据拉取到他们的系统中，做一些定制化的工作。

最下面一层是数据应用层。在这层有几个比较典型的应用，首先是360度玩家分析。在EA的平台上，每个玩家都可以跨平台的玩各种游戏。在构建数据驱动架构之前，很难去掌握每个玩家全面的动态，有了数字化驱动架构以后，就可以清晰分析出玩家的全貌动态，比如说一个玩家，早上上班的时候，等地铁的时候玩什么手游，下班回到家里，通过PC平台或者游戏机，他又玩了什么游戏；周末，和朋友们一起又玩什么样的游戏，这就可以形成一个比较全面的玩家分析，更精准的去根据玩家的兴趣推荐新的游戏给这些玩家，甚至为玩家的朋友们推荐他们感兴趣的游戏。

另外一个比较重要的就是标签系统，它能够让游戏推广部门很快速从几百万、上千万玩家中去挑选出合适的玩家，给他们发送推广邮件，比如说发送折扣信息，引导他们去购买更多类似游戏等。在没有标签系统之前，市场推广人员需要自己去运行查询，这通常需要很长时间，还要把电子邮件全部下载下来，放到系统中做分发，一般来说，一天可能就只能做一次这样的推送。有了标签系统以后，就可以在几秒钟之内从上千万的玩家中，轻松筛选出符合某种条件的玩家，例如，男性，20-30岁，喜欢体育游戏，住在湾区等。然后下一个界面，就是电子邮件的模板，点击发送按钮，就能很轻松的把一次推广工作完成，而且一天中可以做很多次。这个标签系统，后来推广到EA的所有游戏，大大提升了游戏推广部门的效率。

还有一个典型应用就是推荐系统。推荐系统可以针对游戏进行动态的难度调整，以及动态的去匹配玩家的对手，推荐系统是基于人工智能、机器学习以及大数据技术结合来开发的一个应用。

最后一个典型的应用，就是游戏实验，其实就是A/B测试。在互联网企业中也是经常出现A/B测试，例如游戏的α版，β版等，都是通过游戏实验这个应用来评估和完成，这就是EA整个数字化驱动架构的一个全貌。

硅谷”独角兽“的数据中台建设

接着，宋文欣博士简单介绍了硅谷其他的”独角兽“企业如何建设数据中台。

硅谷的科技公司建设数据中台基本的思路，首先就是要有一个稳定的基础架构。稳定性、可靠性、可扩展性、高可用性，这些都是稳定基础架构的重要衡量指标。其次，是及时的商业洞见，这就是为什么会有实时系统，为什么每个公司都会有自助式的数据探索工具的根本原因。第三，就是快速响应市场的变化。这就是为什么会有A/B测试框架，会有CI/CD这样一个流程。因为不管数据产品也好，业务产品也罢，它们的发布都要能够跟上市场的变化。第四，就是数据的共享和复用。我们提到的数据模型、数据服务，这些服务都是要能够开放给全公司所有的业务部门来使用，能够去提升企业的整个业务。第五，数据治理。就是元数据的管理、数据异常检测，这是整个公司数据资产很重要的一部分，企业要能够很清楚的理清每个应用到底是谁开发、谁使用，这些数据从哪儿来，到哪儿去。还有数据异常检测，一个像数据中台这样复杂的系统，不可能没有问题。那么，所有这些异常都需要有数据异常检测这样一个系统，来自动的进行跟踪和维护。最后一个比较重要的，就是衡量体系。一个数据中台建设，是一个投入很大的项目。因此，企业需要能够衡量ROI，就是投入产出比。投入这么多，到底给公司的回报是什么。还有一个就是性能指标，即整个系统和各个子系统，从信息产生到最后掌握信息的反馈时间，和市场平均水平相比，结果如何等。

Twitter的“数据中台”

Twitter是一个在社交领域成名较早的公司，它的数据中台架构基本上与EA的架构类似，上面是Production的Hosts，就是服务器，它的数据首先通过Scribe采集到中间绿色的HDFS组件中，也会有Kafka这样的实时采集。下面是一个Hadoop生产集群，当中还配置了Hbase。在生产集群左侧有一个DAL，就是数据访问层，这是元数据管理的一个组件。再往下，有一个ad-hoc集群，是一个随机查询的Hadoop Data Warehouse，这也是给Twitter的各个业务部门去自助探索的一个集群。同样，它也会把一些数据传送到传统的数据仓库中去，就像右边的Vertica、MySQL，背后也支撑了一些BI工具，以便可以进行进一步分析。整个架构看起来与EA的架构比较相似，只是在各个不同的环节上采用了不同的组件。Twitter的数据量也很大，每天大约产生12个TB的数据，每分钟有将近45万个Tweets。Twitter对大数据开源的贡献也是很大的，像Heron，Ambrose，Gizzard，FlockDB，Scalding，Parquet这些开源软件，都出自Twitter之手。

Airbnb的“数据中台”

Airbnb是共享民宿领域的一个佼佼者，它的数据中台架构从左到右，依次是Event Logs，包括MySQL Dumps数据源，通过Kafka，Sqoop进行数据采集。Sqoop是批量采集，Kafka是实时采集，之后进入名叫Gold的主生产Hive集群，通过复制了以后，变成一个名叫Sliver的Hive集群。然后还有一个Spark的集群，进行Spark计算。整个集群的调度系统使用了Airflow Scheduling。Airflow Scheduling是Airbnb推出的一个工作流管理的开源软件，Airflow与前面提到的Oozie，是两个比较常用的工作流管理开源软件。不过，Airflow从性能和使用上来说，应该是比Oozie更先进的工作流管理软件。下面支持两个集群的就是Presto Cluster存储，Presto的存储计算能力比Hive更加的高效快速。右边是一些BI的工具。这个架构基本上也是和EA、Twitter的架构基本上相同，只是各个环节的组件不同。数据中台在Airbnb的应用也很广泛的，像自然语言分析，房价预测、回归分析预定、协同过滤分析房东喜好等。

硅谷建设“数据中台”面临的挑战

在直播的最后，宋文欣博士谈到了硅谷企业建设“数据中台”面临的一些挑战。

第一个挑战就是大数据的组件繁多，部署升级比较困难。Hadoop生态有几百个组件，每个组件之间的依赖相当的复杂，每一次Hadop集群的升级、扩展，都是一个非常复杂的工作，要进行长达一个月的计划，准备。最后的操作也基本上是以天为单位，有时候甚至需要两、三天时间才能完成。

第二个挑战就是数据流调度工具的局限。数据流调度工具一般安装都比较复杂，同时，还存在性能瓶颈。像Airbnb用的Airflow，安装就需要有一定的编程的能力，整个流水线的部署还是相对来说复杂了一点。EA用的Oozie在作业数量接近八千到一万以后，经常会出现调度机制失灵的现象。

第三个挑战就是缺少统一的全局数据资产管理。在数据中台中，有四个要素，就是用户、数据、应用和资源。这四大要素，每两两之间的关系分析，在应用过程中经常会用到，比如，在Oozie中，我们曾经就做了一个工具，能够去找到数据和它运行数据的作业之间的关系，但这只是覆盖了其中两个要素，而像用户和资源这两个要素，还是没有统一管理起来，也就是说目前市面上还没有一个产品能够真正的把这四个元素都统一管理起来。

第四个挑战是选择的困难。如此多的组件，究竟应该如何选择？每家企业都有自己的业务特点，每家企业都要求稳定性、可靠性。那么在这种情况下，应该如何选择？这对于很多建设数据中台的企业来说，也是一个痛点。

最后一个挑战，是中美同样面临的情况，就是人才难得。宋文欣博士在EA的时候，基本上头一年的时间每天都在面试，整个面试过了五六百人。因此，人才难得永远是一个挑战，即便是是在硅谷这样一个高科技公司云集的环境中。同样，国内也是如此。大数据人才的培养，目前还没有能够跟上，但数据中台建设的热潮已经滚滚而来，各个企业也都已经意识到数据中台的建设是一个必经之路，这也导致大数据方面的人才更加难得。

宋文欣博士表示，而应对这样的一些挑战，其实也是他之所以回国创立智领云公司的初衷。智领云就是想通过一个标准化的数据中台产品来解决这些挑战和难点。比如说针对大数据组件部署难的问题，智领云的数据中台采用了纯粹的云原生架构，通过容器化大数据组件的方式，大大简化了大数据平台部署难、升级难的问题。智领云的数据流水线工具，是一个分布式的流水线作业管理系统，具有非常优异的性能，在内部测试中，同时处理几万个作业毫无问题。同时，它采用的是完全可视化的操作，通过鼠标拖拽即可完成相关工作。此外，它的编程也是相当的简洁，全局的人工智能管理。智领云还开发了一个资源管理系统，能够把用户、数据、应用和资源统一的管理起来，背后支撑这个系统是一个类似Google爬虫的系统。在整个系统中，把所有元数据、用户数据、用户的访问记录等所有的资源体系都能够挖掘出来，建立各种关联，统一的展示在用户面前。这就是智领云做得工作，选择困难，迎难而上。

宋文欣博士最后总结，在整个大数据平台/数据中台建设中，不论是大数据组件的部署，还是大数据组件的应用、配置，智领云都把它做成了标准化组件，这使得用户在使用时感觉非常简单。用户可以很简单的使用、配置整个系统。如果觉得某个组件性能不符合要求，用户也可以轻松的把它淘汰掉或者升级。同时，通过使用智领云这样一个标准化的数据中台以后，整个大数据的建设工作、运维工作都可以做到了很大程度的简化，用户需要的可能只是一些专业的、在企业业务领域内专家级的数据科学家或者是维护云原生平台的一些IT运维人员，而不必去考虑如何才能招募到一些大数据专家或者大数据公司来开发一个数据中台，这对于解决人才招聘难的问题，同样也是一个很好的解决方案。

直播问答精选：

1.硅谷有没有数据中台概念？数据平台和中国数据中台有何异同？
没有太对区别，但在提法上面说法有点不同，实质的建设内容是一样的。快速迭代，上线，能力共享，复用，自助式等。理论上硅谷没有技术中台，业务中台，数据中台等的区分，但是建设内容是一样的。

2.数据中台如何保证安全方面的问题？
数据中台重要特性是多租户，在EA也是一样，每个部门能看到和使用的数据都是不同的，是一个多租户的形式。在游戏采集的时候，每个国家都会对数据安全性进行控制，这个是有硬性规定的。这也是为什么EA要自己开发数据采集的工具。一般采用单点登录（LDAP）的方式来保证安全性。

3.硅谷的方案能否理解为私有的解决方案，硅谷有没有提供数据中台SaaS化的服务？
各个公司的数据中台都是私有的方案，但是不代表他们之间没有共性，总体建设的方式基本是一致的。建设方法是公开的。硅谷没有SaaS化的数据中台，但是有SaaS化的服务，例如有公司把Hive的计算引擎做成SaaS化服务的案例。但这是一种服务，不能称为数据中台。Amazon提供一些基础性的服务，但是也不能称之为中台。云服务上也没有提供一个SaaS化的服务来服务各个企业。安全性也是一个重要的考虑因素。

4.数据中台如何打通来自不同平台的数据？
没有一个开源的软件或商业化软件可以实现，但是我们的产品可以帮助实现，这些外部数据有些接口可以把数据引流进来。但是国内的数据都提供丰富的接口管理，我们的产品也做了数据采集接口开发，后面也会把这个做成通用的产品。

5.数据湖未来发展的趋势？
数据湖在数据中台是个逻辑性的组织部分，所有的原始数据，没有经过任何处理，形成的就是一个数据湖。数据仓库里可以建立模型后，通过数据湖到数据仓库的匹配，把数据规整，进行转换。数据湖是数据中台比不可少的过程
未来发展：采集工具的丰富，轻松构建从数据湖到数据仓库的通道，让数据湖的物理模型和数据仓库的逻辑模型进行对接，稳定的构建数仓的各种表及数据集市的表。

6.硅谷互联网公司的实践能否应用到国内的企业？
这就是智领云创建的初衷，传统的企业在解决这些问题是很困难，帮助传统企业在建设过程中不需做大量的人力物力投入，快速搭建，实现数据中台的建设，这就是我们产品的出发点，解决传统企业建设数据中台难点。

7.实时数据分析的数据中台有什么特殊考虑？
实时采集，需要重点考虑稳定性、高可用、易扩展，系统构建，设计实现要非常谨慎，不出故障还能快速应对流量的变化，这些是构建的基本原则，可选择kafka架构作为基础，把实时处理的整个架构搭建起来。