十三年来，淘宝走过的大数据之路

　　2003年至今淘宝网从零开始飞速发展，走过了13个年头，支撑淘宝业务野蛮式生长背后是一套不断完善的技术平台，淘宝大数据平台，就是其中非常重要的一个组成部分，承担了数据采集、加工处理、数据应用的职责，淘宝大数据平台一路到今天，总共经历了三个大的阶段（如图1），不同阶段面临了不一样的挑战，随着我的理解回顾下这些年大数据所经历过的故事：

图1 数据仓库平台发展三个阶段

第一个阶段：RAC 时代

　　2008年前的单节点 ORACLE，这个时候还称不上数据仓库，只能承担简单的数据处理工作，也基本上没有数据仓库架构，随着业务的飞速发展，很快单节点的 ORACLE 因无扩展能力，计算存储能力就应付不了了；

　　2008年之后，为了应对日益增长的数据量，RAC 集群应运而生，从一开始的4个节点逐步发展到20个节点，成为当时号称全球最大的 RAC 集群，在 ORACLE 官网上也作为了经典案例，RAC 集群当时不管在稳定性、安全性、存储能力还是计算能力都表现非常优秀，随之而来第一代数据仓库架构也逐步形成；

　　这个阶段数据的 ETL 过程主要通过 ORACLE 的存储过程实现，大量的 SQL 脚本任务运行在集群上，任务运行的调度过程是通过 Crontab 来进行控制管理，随着任务数的不断增长，这时面临最大的问题是如何保证这成千上万的脚本每天是正常运行，出错后如何及时发现解决，这在当时天天困扰着开发，一直处于每天救火的状态，也就是这个时候，为了解决这个难题，数据团队开始自主研发调度系统，并将之命名为天网调度系统，形成了如下第一代调度系统的架构和原型：

图2 天网调度系统架构

图3 天网调度系统原型

第二个阶段：HADOOP 时代

　　调度系统的上线很好的解决了每天救火的状态，但是好景不常在；2008年，淘宝 B2C 新平台淘宝商城（天猫前身）上线；2009年，淘宝网成为中国最大的综合卖场；2010年1月1日淘宝网发布全新首页，此后聚划算上线，然后又推出一淘网；业务的飞速发展给数据带来的挑战，就是每天处理的数据量也在不断的翻倍，首先碰上瓶颈的是 RAC 集群针对网站的访问日志数据已经搞不定了，RAC 集群虽然有一定的扩展能力，但是无法无限制的线性扩展，并且扩容就意味着高昂的机器成本和软件成本，为了应对日益增长的数据量，2009年数据团队开始探索新的技术领域，同时探索应用了两个方向的技术：Greenplum 和 Hadoop，主要的场景就是用来解决海量的日志数据，Hadoop 因其良好的线性扩展能力，并且是开源的系统，能够基于官方版本二次开发适合淘宝的特性功能，逐渐占据了优势；

　　2010年初，最终确定放弃 Greenplum 和 RAC，全面使用 Hadoop，也就是这个时候我加入了淘宝数据团队，之后不久数据团队启动了去 O 项目，整个数据团队历经一个多月时间，风风火火将所有 RAC 上的存储过程，改写成 HIVE 和 MR 脚本，并将所有的数据都搬到了 Hadoop 上，Hadoop 集群命名为云梯1，形成了 Hadoop 时代的数据仓库架构，如下图4：

图4 云梯1数据仓库架构

　　进入2010年底，数据应用场景越来越多，2010年底发布了量子统计（淘宝官方版），2011年4月1日淘宝发布了数据魔方，将数据对外进行开放，广告和搜索团队也大量将数据应用到业务系统中，对内的淘数据产品也越来越成熟，数据的大量应用，带来的一个问题是如何保证数据的准确性和稳定性，需要从数据采集到数据加工及最终的数据应用全流程的保障；

　　这时第一个环节就碰到了问题，数据同步，业务系统有各种各样的数据源，ORACLE、MYSQL、日志系统、爬虫数据，当时有多种同步的方式，有通过 SHELL 脚本的、也有通过 Jdbcdump 的、还有别的方式，当时负责数据同步的同学，最痛苦的事情莫过于，业务系统进行数据库变更时，各种同步任务需要不断的调整，每次调整几百个任务极其容易出错，当时为了解决数据同步的问题，数据工具团队开始研发专门的同步工具 DATAX，也就是现在同步中心的前身，同时还研发了针对 DB 的实时同步工具 Dbsync 和针对日志的 TT，现在统一叫 TT，如图5：

图5 云梯1数据同步工具

　　天网调度系统也不断进行完善，开始支持小时调度、甚至分钟调度，并且集成了自动告警等一系统功能，升级为在云端，相关的 DQC 系统、数据地图、血缘分析等周边系统在这个时期不断推出，数据团队也不在断壮大。

　　在这期间，双十一网购狂欢节的影响力不断放大，已成为中国电子商务行业的年度盛事，并且逐渐影响到国际电子商务行业，不断刷新的成交记录刺激着所有人的神经。这时为了直观的提供第一线的数据给到决策层，产生了数据直播间的数据应用，需要活动当天及统计相关的数据，2013年前，采用的方式都是基于 Hadoop 一个小时计算一次的方式进行数据计算，数据存在一定的延迟性，从2013年开始，数据团队开始投入研发实时计算平台，也就是现在的 galaxy，并在当年的双11上线了第一个应用，双11数据直播间实时版本。

第三个阶段：MaxCompute（原 ODPS） 时代

　　就在 Hadoop 大量应用的同时，另外一个项目正在悄悄进行，那就是阿里云团队自主研发的 ODPS 系统，ODPS 所有的代码都由阿里自己完成，在统一、安全、可管理、能开放方面相比于 Hadoop 做了大量的完善，ODPS 系统命名为云梯二，从2010年开始，在很长一段时间内，一直处于云梯一和云梯二并存的状态；

　　这期间，集团为更好的打造数据生态，成立了 CDO，统一数据平台事业群，专门投入研发大数据平台的相关工具，包含计算存储平台、周边的调度系统、元数据血缘系统、数据质量管理系统、还有 DQC 等；

　　这个状态持续到2013年4月， 这时出现了一个新的挑战，Hadoop 集群的上限是5000个节点，按照当时数据增长数据的推算，集群存储即将撞墙，但是基于当时的状况，ODPS 无法完全替代 Hadoop，于是当时启动了一个规模非常庞大的项目，叫做“5K 项目”，同时进行云梯一和云梯二的跨机房集群项目，当时世界上没有任何一家公司具备跨机房的能力，存在非常大的技术挑战，最后项目历经近5个月的周期，攻克大量技术难点，项目取得了成功；

　　在“5K 项目”成功的同时，ODPS 架构逐步成熟，于是全集团又启动了一个规模更庞大的项目，叫做“登月项目”，将全集团的数据加工应用全部搬移到 ODPS，项目一直持续到2015年，Hadoop 正式下线，淘宝大数据彻底进入 ODPS 时代，整个数据的生态圈也越来越丰富，同时，阿里云开始对外提供云服务，其中大数据解决方案作为其中重要的组成部分，也开始对外提供；

　　时间回到2013年时，当时淘宝数据团队的每个成员都在忙于应对各类需求，每天都有做不完的各类报表，当时为了解救自己，数据团队开始摸索探索新的数据服务模式，思考如何解决数据冗余、口径统一、数据交换、用户自助等一系统问题，最终通过一段时间思考和摸索，开始研发孔明灯产品，针对不同的数据角色形成了一套完整的数据解决方案，如下：

图6 孔明灯解决方案

　　孔明灯产品的出现，对传统的开发模式做了个升级，对整个大数据建设也起到了非常好的管理作用，当时在淘宝内部，覆盖了大部分的业务 BU，对数据使用成本的降低，释放了大量的人力，同时也吸引了外部用户高德地图、阿里健康基于这套体系进行大数据建设；

　　2014年，集团公共层项目启动，集团内的各个数据团队，开始进行数据内容重构和整合，同时，CCO 正式成立，七公来到 CCO 带领技术团队，薛奎来到 CCO 带领数据仓库团队，CCO 也基于 ODPS 启动公共层建设项目，集成了包括淘系、1688、ICBU、AE 相关的服务数据，公共层建设的同时完成了登月项目，并且与 DIC 团队、RDC 团队协同建设了服务数据门户 DIGO 产品；

　　如今，数据在阿里巴巴已经深入到每个角落，阿里云有强大的算法团队、大批的数据接口人、分析师，每天的工作都与数据产生关联，随着人工智能的不断深入使用，业务系统的不断创新迭代，对数据的采集、加工、应用又提出了新的要求，如何更好的提供数据服务，面对未来我们需要思考更多，数据将进入一个新的时代——数据智能时代。