本文根据徐皓老师在〖2018 DAMS中国数据资产管理峰会〗现场演讲内容整理而成。
讲师介绍
徐皓，奇虎360大数据中心技术总监。曾就职于华为，主要负责软件产品线平台相关研发工作，涉及中间件、云等相关领域。目前负责奇虎360数据中心平台的规划和建设。
我们今天介绍一下奇虎360大数据中心平台化的演进过程和实践，整个介绍分为四个部分：
-
大数据中心的业务背景；
-
大数据中心平台化的演进过程；
-
演进过程中的实践案例；
-
大数据中心未来的发展规划。
一、大数据中心的业务背景
1、背景
奇虎360数据中心2008年就已经成立，那个时候叫“数据中心”，但是从去年开始，我们更名为“大数据中心”。
为什么呢？实际上这种更名是有一定原因的。
原来这块做的事其实比较单一，主要是负责整个奇虎360各个业务线的数据分析和数据加工的需求，比如说做报表、为业务线的数据做二次加工处理等这些比较单一、重复的需求。
随着业务线逐渐增多，需求量也在不断增加，但是数据中心的人力投入基本上还是维持原来的规模，那么这种按业务部门提供定制化的数据分析能力的模式从人力上已经完全满足不了公司业务的发展速度。
公司的业务在迅速扩展，除了大家平时所熟知的PC安全卫士、360浏览器、360搜索以及移动端的手机安全卫士等应用软件之外，还有很多其他领域的业务软件。这是整个公司从资产角度所呈现的业务线概况：
从图中可以看到，主要分为游戏、搜索、个人安全、视频信息流、应用产品和IoT六个领域的业务资产，这里面包含了公司当前的70多个活跃产品、1000多张表、30000多字段的资产信息。这些资产除了包括大家所熟悉PC安全卫士、手机卫士、360导航等产品之外，还有游戏、视频、物联网等领域的资产数据。
从整个资产的角度来看， 360已经不是单一的以安全为主业的公司，而是以安全为核心技术的综合性的互联网公司。
从数据资源的角度来看，安全数据是360公司占比重最大的一块数据，包括上亿级别的PC端和移动端的数据、以及360浏览器等其他产品的数据，数据存储量接近1.6EB，同时每天还在以PB级的规模增长。那么这样一个海量数据存储和资产现状也对数据中心提出了更高的要求。
随着公司产品的多元化、数据的快速膨胀，公司的规模越来越大，原先的业务构建模式已经不能支撑公司的高速发展。从去年开始，公司开始了360的中场规划，把公司的公共能力集中管理和构建，形成公司大的平台战略，这其中就包括大数据平台。
2、业务
公司业务主要分三类应用场景：
-
数据的二次加工处理，比如从360搜索、360导航里产生的海量用户行为数据，这些数据需要在二次加工处理之后用于给上层数据应用使用；
-
海量数据的检索，公司拥有全球最全最多的互联网安全数据，主要涉及的产品包括360天眼、安全卫士、杀毒等等，针对这些海量数据，需要依托大数据平台进行快速查询和检索。
-
产品数据分析，这是一类比较常见的大数据需求，这类分析包括我们产品运营数据分析、定期的统计报告等等。基于分析报告、产品，制定后续的运营策略，诸如视频类、游戏等产品。
二、大数据中心平台演进过程
1、三个阶段
整个数据中心的演进过程可以参照下图，整体的过程就是：从产品以垂直领域的方式独立构建，逐渐地发展成为水平扩展方式的平台化建设。
-
第一个阶段：在2010年之前，都是以产品为单位的一些数据处理工具，每个产品之间没有任何交集，产品有自己的数据处理团队。在这个过程中，数据团队做一些和本产品相关的数据处理、数据加工工作。
-
第二个阶段：随着产品逐渐增多，每个产品重复开发的数据产品越来越多，在这样的背景下公司成立了数据处理部门，专门负责完成每个产品的数据需求，并逐渐形成一些数据处理的通用能力和工具，这个部门就是大数据中心的前身。
-
第三个阶段：也就是当前这个阶段。如前面所介绍，公司已经有了七十多个活跃产品，如果还是以产品需求为导入，承接定制化的需求，那么人力需求将会是成倍数增加，而基于公司对数据中心的定位，无论当前或者未来都不会按照需求量的增加配置相同比例的人力资源，所以构建统一的大数据处理平台，让产品基于平台的能力完成自己的数据应用需求，是这个阶段我们的重点发展方向。
在这里有必要说明一下，平台化的过程并不是一蹴而就的，一定是有场景和业务的推动，在长期运营的过程中逐渐形成、逐渐提炼的一个过程。我不赞成做软件一开始就平台化，你可以有平台化的思路，但是实际输出的是平台还是定制应用这个需要根据当时的外部情况综合考虑，平台有平台的好处，定制有定制的优点，都不能一概而论。
对于一些中小公司而言，平台化的构建一定要考虑清楚，因为这些公司的规模决定了他们的产品量级以及需求的量级不一定很大，这种情况下以构建统一平台的方式去支撑产品需求未必比提供定制化的能力更加高效。此外，平台本身对于使用者来说，其门槛通常都会更高。
2、发展里程碑
整个数据中心从成立到现在的发展里程碑大致是这样：
-
从2010年开始，第一个MR程序上线，标志着数据处理方式开始从传统方式转向分布式处理；
-
2011年开始老版本的数据处理程序全部下线，全面采用分布式的处理方式；
-
2011到2015年移动端应用逐渐增多，所以我们发布移动端SDK，用于方便移动端应用数据采集；
-
2015年之后数据处理平台发布，基于这个平台数据分析人员可以在一定程度上进行数据二次加工的自定义配置；
-
2016年的时候，我们数据处理平台发布实时计算功能；
-
2017年的12月，大数据平台第一版本发布，这个版本涵盖了整个数据处理生命周期的端到端能力，包含通用的数据产品和数据处理服务，数据分析人员可以在平台的基础上，根据他们的需求定制自己的数据分析功能。
3、QDAS+
我们新的平台叫QDAS+，我们把新平台定位为一站式的数据治理、加工及挖掘平台。
功能划分
上图是一个系统功能视图。整个系统分为四层：
第一层是数据接入层，包括公司应用的业务日志数据、安全相关数据，以及外部接入的数据；往上一层是基础平台，用于支撑数据中心平台正常运行，包括底层计算资源、存储资源、中间件以及其他的基础技术框架；在基础平台之上我们沉淀出了应用平台层，这一层实际上数据中心对外要用到服务和产品所依赖的公共能力，包括任务调度、数据采集、数据集成、报表组件、规则引擎、权限管理等等；最上层是直接对外的能力，分为两个部分，一个是服务，通过这些服务产品可以进行数据应用的二次定制；还有一部分是产品和工具，这些都是提供给产品直接使用的功能。
先说一下产品和工具。这块实际上就是通过界面接入的方式去使用数据平台的能力。那么除了这些产品和工具之外，我们为什么要提供服务？其主要原因在于有一些产品在使用方式上平台未必能满足，为了能更加灵活的支撑这些产品，数据中心将数据处理的能力以服务的形式发布出来，然后产品自己去做数据处理的工具。
技术架构
上图所示是整个数据中心的总体技术架构。平台支持四种数据源的接入，涵盖了所有产品的数据格式。整个系统分为8个子系统，数据处理平台（TITAN）、资产管理（QDAM）、机器学习平台（QMiner）、报表分析系统（Qreport）、知识管理系统（Qprofile）、在线查询工具（Qnote）、数据运维系统（QOPS）、数据开放服务，这7个模块涵盖了数据处理生命周期的所有阶段。
所有数据首先经过我们的数据处理平台TITAN进行数据的二次处理加工，处理完的数据统一纳入数据资产进行管理，同时作为其他的子系统的数据来源。整个平台数据运维由数据运维系统（QOPS）承载。
我们的数据资产分为四层：原始、明细、汇聚、应用，每次的含义大致描述下：
-
原始层：和原始输入文件保持一致，并在其基础上做一些基本处理，如格式校验、维度补齐等；
-
明细层：在原始层的基础上，按照规范完成数据的标准化，同时完成数据层面的分类；
-
汇聚层：围绕多个维度的主体域完成对于数据的汇聚，形成统一视图，诸如用户、商品、位置等等；
-
应用层：以明细和汇聚层的数据为基础，形成顶层应用所依赖的数据视图。
改进点
我们从四个方面来阐述平台的改进点：
数据资产
在资产这块，我们首先梳理了公司主要产品的数据，并在此基础上完成了全域的数据分层和归一化。在此之前，公司的产品虽然都是基于数据中心的能力去完成数据类的需求，但是产品间的数据是没有打通的，从逻辑上是隔离的，甚至有些在物理层面也是隔离的，这造成一个现象：公司的数据很多，但是这些数据无法进行一个有效的关联，数据使用范围受限，价值无法最大化。
在此基础上，我们推出可视化的数据价值地图，以资产为单位对数据进行多维度的呈现，包括访问量统计、数据质量、跨业务线使用量等。
还有就是做了统一的数据标准和安全体系建设。做这个的初衷主要有两个原因：
-
公司以往的数据安全分级粒度较粗，其实只有“是”或者“否”两类，数据对于用户要不提供、要不屏蔽，在实际场景中，对于某种资产而言，数据使用对象的范围是不一样的，那么这种粗粒度的划分将会有非常大的局限性；
-
行业环境对个人数据安全的要求也越来越高，在公司层面上对数据安全也提升到了一个战略的高度。
基于这两点方面的因素，我们做了统一数据的安全系统标准，包括对于数据进行安全的分级分层。
用户画像
在用户画像这块主要的工作就是基于归一化的数据资产，建立公司级的用户账号体系。因为360的产品有其自己的特点，每一个产品都有产品自己的账号，整个公司没有一个统一的账号体系，所以数据关联性较差，无法跨产品使用，我们用了半年的时间打通了跨产品的账号体系，形成虚拟的用户账号体系，并在此基础上完成了全公司产品的数据的用户画像。
数据平台
数据处理平台涉及三个方面的改进：
-
跨引擎计算，原来平台可以支持多种计算引擎，但是对于每一个独立的处理任务，无法进行跨计算引擎的混合处理；
-
支持混合数据源的输入，在360的很多产品数据会保存在多种数据源中，所以在此之前为了处理这种跨数据源的分析任务，只能采用配置多个任务的方式，所以在数据处理能力上增加了对混合数据源的支持；
-
任务配置图元化，这也是数据平台最重要的一个改进点。原先的数据处理平台针对公司的业务进行了抽象，并生成一些通用的处理模板，数据分析人员通过对模板中的属性修改来完成数据处理任务的配置。这种方式有很大的局限性，一旦有模板无法支撑的数据处理场景，那么就需要平台的开发人员去重新创建新的模板，这样需求响应速度慢，人力投入也多。
新的平台通过将计算逻辑和任务流程分离，这样就能通过配置的方式完成绝大部分数据处理需求。
数据服务
如前面我所描述的，数据服务是新平台的一个能力，这在原来是不具备的。通过数据服务平台提供了多种使用数据处理能力的接入方式。
三、演进过程中的实践案例
1、数据治理
用户数据归一化
有三个主要的原因驱动我们去做用户数据归一化：
-
数据关联度低：前面我向大家介绍过了360产品的一个主要特点，由于弱账号的原因导致公司没有一个统一的账号ID体系，海量业务数据孤立存放，所以产品和产品之间的数据无法关联，也没有办法复用。
-
数据缺乏维护：我们的数据很多，但是有些数据连产品自己的工程师都不一定清楚它的含义。这其中的原因有很多，比如有的产品工程师由于岗位的调用换了业务线、部门甚至不在公司了，但是没有做好公司交接，本身数据的负责人也几易其主，加之一些命名不规范等多个原因造成了数据维护困难。如果按照这种情况继续下去，将会对后续的数据治理带来很大的困难。
-
价值体现不足：产品数据的使用范围有很大局限性，大多只能在产品内使用，数据维度缺失、数据补齐难度较大。比如我们的视频类应用，在用户首次登陆的时候如果能知道其性别，并根据不同的性别来推送对应的视频，和单纯的按照排行榜进行视频推送相比，其推荐效果是完全不一样的。
那怎么做数据归一化呢？
我们分了两个步骤：
-
第一步就是业务行为数据的关系提取。我们刚才说了有很多的产品数据是孤立的，但是每个产品的数据资产维度是相通的，即使字段不一样，代表的含义是一样的。根据这些字段进行数据模型的整理和资产关系的建立，对公司主要产品的资产关系进行了梳理，形成一个公司级的产品间的资产关系图。
-
第二步是虚拟自然人的维度建立。在业务关系建立之后，会形成多对多的关系网，举个例子，一部手机可能对应多个PC，一台PC也可能对应多部手机。基于关系网的数据，找出每个节点之间的关联度，以此为基础进行ID的聚类关系，将这些关系ID形成一个虚拟自然人的用户ID，最终将产品间的资产数据打通。
上图是一张数据资产价值地图大盘，基于数据中心的资产上的多角度的呈现，包括每个产品的数据价值、每个资产的数据价值以及产品间的资产使用数据统计。
2、数据处理
下面要讲的是数据处理平台，我们称之为TITAN。在数据资产的用户归一化等数据治理动作之后，第二个要做的就是数据处理平台的建设。数据处理平台是整个数据中心能力的基石，它承载了数据治理以及数据二次加工的能力，所有和数据分析相关的功能从逻辑上都在其之上。
演进过程
数据处理平台的构建分为三个阶段：
-
第一阶段是分布式的数据处理工具。这个阶段将数据处理从传统方式转化到分布式的数据计算。其次将计算规则进行抽象，以模板化的形式对外呈现。原来只提供调度和底层计算的能力，数据处理的逻辑都是以编码方式完成，逐渐提取出公共的模板，比如PV/UV模板，这个模板上就会有一些参数可以进行调整。通过这些参数调整，最终完成PV/UV的计算。
-
第二阶段数据处理的平台化，从单一的数据源到支持多种数据源，支持多种计算引擎以及从单一的数据处理到增加报表、查询等模块，同时逐渐形成了模块化构建系统的雏形。
-
第三阶段也就是现在这个阶段，在前两个阶段的基础上提供了高性能、高可靠、低门槛的数据处理平台。原来平台底层计算引擎基于Hadoop构建，稳定但性能不够，对于时效性有要求的处理场景就显得有些力不从心。比如有个业务一周的数据大概是将近100T左右，使用老平台需要15小时，在切换了新的平台之后，相较之前的速度提升了一倍。老平台如果模板不能满足数据处理的场景怎么办？数据分析师就必须在分析平台上部署自己写的代码，这种要求比较高，因为具备编码能力的数据分析师在行业不多，而且使用平台的不仅仅是分析人员，还有我们的产品人员。
问题和挑战
在我们构建当前平台之初，所面临的问题和挑战有那些？主要是数据源类型、场景支持度、资源管控和使用门槛四个方面。
-
数据源类型方面，原来是不支持流式数据处理的，同时在一个任务里是没法跨多种不同的数据源；
-
场景支持度方面，以模板的思路去实现势必会有很多场景上面的限制，这个之前给大家说明了，另外任务调度类型支持较少的，只支持一次性或者按天执行，现在支持按周、按月，甚至于一些更复杂的，比如每个月的倒数第二天执行等等；
-
资源管控方面，老平台的计算资源的分配策略比较单一，遵循先导先得的策略。现在计算策略根据多个维度生成，比如加入了任务的优先级等维度，有效提升了任务整体执行效率，原来的数据资源要么能用，要么不用，没有一个分级的概念，新的平台将数据资产按照安全和逻辑两个领域进行分层，分为四层安全级别和四类数据视图；
-
在使用门槛方面，主要是解决系统使用难度和用户体验的问题，从模板式配置到采用自定义的任务配置方式的一个转变。
系统架构
整个数据处理平台的逻辑架构分为四层：数据、计算、组件、应用。其中调度监控、权限管理是属于系统监控模块，将计算、组件、应用这三层的能力统一监管，方便后期的平台运维。计算层目前支持Spark和Flink两种计算引擎，资源调度依赖于YARN来执行；组件层主要是计算组件库、规则引擎等用于支撑数据处理任务配置；应用层提供两种接入方式——界面接入和接口接入。
当前现状
这是数据处理平台当前运行现状，我们现在接入35个业务线的数据处理任务，计划今年完成老平台任务的迁移。
任务管理
在性能和可靠性方面做了三个主要优化：
-
防数据倾斜。这是为了防止在计算操作的时候，由于数据中的键值重复较多从而造成数据集中在某个节点上运算；
-
数据缓存。数据缓存的目的是为了减少在任务执行过程中的重复计算，对于有共享节点的任务，这些节点的数据会重复使用，在计算完成之后进行缓存，避免重复计算；
-
小文件合并。由于底层计算引擎的特性，在计算完成之后会生成较多的小文件，我们在将最终数据加载到存储上之前，会预先进行数据的合并工作，最终按照指定文件大小加载到存储上。
在场景优化方面也涉及三个改进点：
-
增加任务调试的能力。对于处理逻辑较复杂的任务，由于其节点配置较多，执行路径较长，往往不能一次性配置成功，任务调试可以将复杂的任务拆分成多个子任务执行，提升任务配置的效率；
-
异常策略配置。对于需要处理的原始数据，通常会因为各位原因在数据的质量方面会有一定的问题，比如某些维度缺失、数据值不规范等，这样就会导致在处理的过程中产生异常，并造成数据处理任务的失败，而这种质量问题在海量数据处理中对最终的结果影响程度不大，通过异常处理的策略配置尽可能保证数据处理任务的顺利执行；
-
默认值补齐。对于一些常见维度的数据，如果有缺失，会根据本业务线的常见处理规则将缺失的维度值以的默认值方式添加上去，保证数据的完整性。
3、在线查询
整体介绍
最后我们介绍下在线查询，这是当初设计的目标：
-
功能定位：实际上在线查询的功能可以通过数据处理平台和报表平台的能力来完成，那么为什么还需要在线查询呢？从功能定位和解决场景来看，是为了完成一次性数据分析任务，作为数据处理平台和报表平台的一种能力补充。
-
定位人群：数据分析人员，或者是具有一定数据分析能力的产品人员，因为在线查询是以标准SQL作为输入，所以要求有一定的数据处理经验。
-
主要特性：因为是数据处理和报表的一种能力补充，所以在功能点上需要涵盖这两块的基本能力。
架构设计
整体架构上分为三层，在查询服务层进行语法校验，校验完成后将查询输入传递到解析引擎层，完成针对不同数据源的语义转化，然后将转化之后的语法传到多语言执行平台，完成数据的查询。
当前现状
对100GB量级的聚合查询从原来的20分钟缩短到10分钟；10TB量级的聚合查询从2.5小时缩短到1.3小时。就目前数据中心应用场景来看，95%以上的查询分析集中在100GB量级。
查询响应时延绝大部分集中在2秒以内，原来我们每次查询的时候资源都必须重新申请，后来做了查询的绘画管理，保证用户资源在指定时间内可以重复使用，那么除了首次查询需要申请资源会造成延迟之外，后续查询请求因为无需重复申请资源，响应时长都能控制在秒级范围。
四、对未来的规划
整个平台是从去年开始构建，所以还有很多不足和缺失：
-
首先是数据生命周期内的运维能力。目前平台的运维能力还是以功能为核心的运维，对于以数据为核心的运维能力还有待建设，比如某个资产、某类数据在哪些数据场景中使用，他们的整个生命周期过程中的状态是什么等等；
-
其次就是场景化的解决方案。当前以服务和应用形式提供给产品使用，随着跨产品的数据需求越来越多，需要将服务和应用以解决方案的形式去对外呈现，快速满足产品的场景化需求。
Q & A
Q1：关于小文件合并这块，咱们360这边有没有一些比较好的一些提高效率的方式，或者比较好的经验？想咨询一下。
A1：小文件合并分为输入源文件和输出文件的合并两种情况，我们目前做的是结果数据的文件合并。规则很简单，就是保证没有空文件的基础上减少输出文件的数量，那么每个文件的大小如何规定，这个是需要根据业务场景来形成一个经验值。
Q2：这两个框架有互相借鉴的趋势，您觉得这两个之间未来应该如何取舍？
A2：这个问题实际上不是简单的几句话能描述清楚的。就Spark和Flink两种计算引擎而言，本身在设计思路上有很多差异点，比如Flink在实时计算能力方面有较多的改进和优势。这种问题还是应该从场景出发，比如对实时性要求较高的场景可以使用Flink，如果说对实时性要求不高，或者不是那么的高我觉得使用Spark就可以了。对于我们的平台能力而言，是可以支持这两种计算引擎的，且可以方便的切换。
