《阿里巴巴全域数据建设》（实录/PPT干货）

阿里巴巴目前生态建设包括了核心的电商业务，淘宝、天猫、聚划算等，同时还有文娱板块的优酷、土豆、UC浏览器等，当然还有本地化服务比如口碑、饿了么等。基于业态背后还有蚂蚁、菜鸟、阿里妈妈、阿里云等等。

这一系列的生态数据我们都会集中进行存储和管理，并构成了我们的全域数据所覆盖的范围。

一方面，上述每一种业态都是全域数据的来源；另外一方面基于这些优质的数据，进行解析和处理，再反哺给到业务。我们要实现的是：利用全域数据去驱动业务，让数据发挥更大价值。

以手淘为例，手机屏幕是非常小的，我们如何在有限的空间内展示给到用户看到他们真正希望看见的内容？“千人千面”这一应用的背后，实际上就是基于大数据的算法应用场景，来实现的。还有芝麻信用、菜鸟的智能物流、阿里妈妈的精准营销等等，它们都是通过大数据驱动之下，构成了业务与数据联通的闭环。

我们为什么要做全域数据？

首先，降低成本——

大家都知道大数据建设的资金投入其实是非常巨大的。比如基础建设的投入、机房、机架、服务器、网络带宽，包括软件平台建设，开发运维团队的组建等等，都会耗费企业大量的资金和人力。以优土（优酷土豆的简称）为例，优土去年加入阿里巴巴集团之后，我们开始启动数据融合项目：在此之前，优土有自己的Hadoop集群，阿里巴巴的数据规模则大的多，将优土数据融合到阿里大平台上，可以让优土获得更多弹性资源，也可以在基础设施运维、人力运维、平台运维上复用集团的技术体系；基于OneData大数据建设体系、统一的数据采集规范等，减少人力及运维成本。当项目完结后，我们发现目前优土在数据建设上的成本不到原来50%。

其次，技术赋能——

客观来说，在阿里生态内公司的数据能力参差不齐，因此为了赋能其他生态公司，我们通过短时间的数据体系迁移，让他们拥有和阿里集团同样的大数据能力。上述的优土融合项目就是通过半年时间，实现了技术赋能。

第三，数据连接——

我们知道数据孤岛的现象不光存在于传统行业，互联网行业也是一样。所以只有把数据连接起来，它才能发挥更大的价值，消除数据孤岛，让数据连接起来，也是我们进行全域数据建设的目的之一。

最后，赋能业务——

无论我们的集群规模有多大，服务体量有多大，最终还是要回归业务、通过业务的数据表现来体现我们的价值——把数据体系统一后，除了让业务可以更加准确、快速的获取决策分析数据外，还能提供业务快速试错的机会，最终为业务创新降低了门槛。

在整个全域数据接入过程中，尽管基础设施建设已经非常强大，但在实际过程中，我们仍然面对了诸多困难和挑战。仍以优土为例，它的大数据机房在青岛，阿里集团大部分数据集群都在内蒙古和张北，而涉及到数据迁移也绝不是“拉一根网线”这么简单——其中涉及到应用体系、大数据架构都需要定制方案去做；

另外，统一数据采集在接入的过程中也会就原有业务进行统一梳理，包括后面的数据验证，做过数据的人应该都知道其中的痛点；同时在迁移过程中，原有的数据对业务的服务还不能停，这事情我们叫——飞机上换轮子，一边要进行核心零部件更新，一边还要保持高速飞行；

最后就是项目周期，基于现实情况，大数据建设一般需要较长的周期，无法在几周内完工，因为大数据建设不是一蹴而就，而是一根体系化过程。

从基础设施来看，阿里经过电商发展，包括多年双11这种特殊场景下的考验，在基础设施上，从数据中心到网络到服务器，到数据库中间件、计算平台、数据平台、算法平台都有了非常多的沉淀。

因此，在建设全域数据的时候，我们要做的第一步就是将生态公司的数据在基础设施阶段就进行融合。

▊我们的数据组件划分如下：

最底层——数据采集，这是数据的来源；中间——计算存储平台：实时计算采用自主研发的Blink，离线则采用MaxCompute。

▊上图详细介绍了我们的数据组件：

基于用户的网上行为去做数据采集（我们有PC和无线的采集体系）然后放到实时、离线计算平台上来，这两个计算平台除本身计算能力外，还有许多基于SQL、Graph等可编程的能力，最上面就是研发工具、产品服务、BI工具。

有如此强有力的基础支撑外，长在上面的应用能力也非常给力：以研发工具为例，阿里有约两万名研发工程师，而每天基于阿里数据平台开展工作的同学就有近一万人！

基于这些丰富的大数据组件，大部分的研发同学、专业的或非专业的同学都能在上面基于大数据做一些探索和尝试。

▊下面介绍我们在全域数据建设中的几个体系：

首先看流量体系——

这是互联网行业和传统行业最大的区别。

打个比方，如果我们把淘宝可以看做流量分发中心，用户进来后把流量给到商品、给到卖家。那么在进行流量数据采集时，大家可能会给出不同的方案。

我们基于阿里巴巴多年的电商经验，也沉淀出来了一套统一的流量采集规范——超级位置模型：

以淘宝的页面为例：

站点就是淘宝，下面会有页面、区块、位置，这些都是可以根据业务实际需求去埋点，并直观获取页面任何位置的数据，比如页面概况分析、路径分析、跳转分析、页面点击、用户分析等等。业务方只需要按照规范埋点，我们就能够迅速给到基础的流量分析能力，而基于此，配套对应的数据产品就可以解决80%的流量方面的数据问题。

其次看计算组件化——

众所周知，基于互联网的基础内容其实是能够固化下来特定需求，中间过程可以通过工程化能力去解决，然后迅速把这些东西配置出来，而不需要每一个需求都去做代码开发计算——这就是计算组件化。

这样做的好处首先就是；配置简单、复用性高，同时，在注意统一规范后，未来接入uc、接入高德等业务，我们可以做到一键接入。

OneData体系，全域数据建设最核心的体系——

目前，从整个大数据建设过程来看，它分为数据接入、规范定义、计算加工、数据验证、数据稳定性，这几个部分合并构成了整体的数据研发流程。

OneData体系工具是全域建设的保障——我们知道现在存储和计算可能已不是瓶颈。随着分布式技术的发展，以Hadoop为典型代表，廉价的pc服务器即可搭建出超强的计算能力，因此存储和计算未来会变的越来越便宜，但相对昂贵的是工程师的时间成本。

所以，工具化是解决研发效率的关键一环。我们把大量机械、人肉、不产生价值的工作，通过工具去完成，比如从数据的接入开始，我们有OneClick保证高效接入，根据阿里巴巴完善的元数据，我们有能力把基于业务db的数据一键拉到计算平台，这个过程几乎不需要人的参与。

同时，通过OneDefine工具来确保数据建设过程是规范的，比如：模型分层、表命名规范、字段命名规范等。

再看计算过程——

阿里数据应用的群体在能力上是参差不齐的，有专业的数据研发、有算法工程师、有分析师、可能还有业务运营，很多人可能简单自学SQL后，就可以自己跑数据：通常情况下，SQL质量无法保证，如果查询的数据量非常大，可能后台几千台机器就转起来了，为避免类似情况发生，我们会在提交任务过程中做代码校验，对于性能问题、规范问题、代码质量问题都会给出必要的提示，比如sql代码对于除数为0没有做代码兼容，比如我们的ddl语句中没有做数据生命周期的设置，比如sql的query中没有做分区的条件限制，甚至你的sql代码别人已经计算过，可以复用结果不需要重新计算这些问题，我们都会给出精确到提示。

在数据研发过程中，代码编写可能只占工作量的20%，那么大部分时间都去干吗了？是数据验证，代码修改前和代码修改后，数据到底差多少，差在哪儿？过去如果没有工具只能写一堆角本，再去验证，效率极其低下，而且极易出错，现在有了“在彼岸”工具我们可以通过简单的勾勾选选就知道前后差异到底差在哪？然后迅速给测试报告，保证整个研发过程的数据质量是有保障的。

最后，任务上线后，大量时间都在运维，监控数据质量、监控产出时间等等，这些日常要去关注的工作我们也会有相关的工具去支持，因此OneData体系工具是全域数据建设的重要保障。

工具有了，规范有了，我们还需要与研发流程全程打通，我们就可以确保规范真正的落实到每位开发者身上，因此我们可以这样来理解研发流程：某位研发同学在做数据需求，要先把规范定义完成才能继续进行代码开发。

▊代码开发中会有两道检查：

第一道是SQLscan：这里面会检查代码规范性、代码质量、可能出现的性能问题，把这些问题避免掉；

另一道是“在彼岸”数据测试：重要的数据做了数据变更后，会要求做回归测试流程，轻松简单的勾选，就可以快速给出测试。如果任务需在生产环境运行，这两个环节必须完成后才能够提交，上述过程就是整个基于OneData体系的研发流程。

目前阿里巴巴数据总量已超EB级别，总表数也已经超百万，这么大体量下，如何能够做到高效灵活却又不失规范的大数据建设，我们确实探索了很长时间。

随着阿里业务的不断拓展，对于大数据能力的要求会越来越高，技术上，如何突破传统数仓etl架构？我们从基础设施的计算存储分离、离线在线混布等事情上已经开始探索，相信在不久的将来，我们会对传统数仓etl进行重新的定义。