阿里巴巴的相关-----ODPS技术架构、Java Web架构、PAI机器学习平台

摘要：ODPS是分布式的海量数据处理平台，提供了丰富的数据处理功能和灵活的编程框架。本文从ODPS面临的挑战、技术架构、Hadoop迁移到ODPS、应用实践注意点等方面带领我们初步了解了ODPS的现状与前景。

初识ODPS

ODPS是分布式的海量数据处理平台，提供了丰富的数据处理功能和灵活的编程框架，主要的功能组件有如下几个。

• Tunnel服务：数据进出ODPS的唯一通道，提供高并发、高吞吐量的数据上传和下载服务。
• SQL：基于SQL92并进行了本地化扩展，可用于构建大规模数据仓库和企业BI系统，是应用最为广泛的一类服务。
• DAG编程模型：类似Hadoop MapReduce，相对SQL更加灵活，但需要一定的开发工作量，适用于特定的业务场景或者自主开发新算法等。
• Graph编程模型：用于大数据量的图计算功能开发，如计算PageRank。
• XLIB：提供诸如SVD分解、逻辑回归、随机森林等分布式算法，可用于机器学习、数据挖掘等场景。
• 安全：管控ODPS中的所有数据对象，所有的访问都必须经过鉴权，提供了ACL、Policy等灵活强大的管理方式。

ODPS采用抽象的作业处理框架将不同场景的各种计算任务统一在同一个平台之上，共享安全、存储、数据管理和资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。

和阿里云的其他云计算服务一样，ODPS也是采用HTTP RESTful服务，并提供Java SDK、命令行工具（Command Line Tool，CLT）和上传下载工具dship，以及阿里云官网提供统一的管理控制台界面。在阿里内部，有多个团队基于ODPS构建交互界面的Web集成开发环境，提供数据采集、加工、处理分析、运营和维护的一条龙服务。基于ODPS进行应用开发，最直接的是使用CLT以及dship等工具。如果不能满足需要，也可以进一步考虑使用ODPS SDK或RESTful API等进行定制开发，如图1所示。

图1  ODPS应用开发模式

如果你的业务发展需要一个足够强大、能开箱即用的大数据处理平台，并且不想花费太多精力去关注这一切如何实现与运维，那么ODPS是一个非常理想的选择。

规模的挑战

在DT时代，数据是宝贵的生产资料，但不断扩大的数据规模给ODPS带来了极大的挑战。在阿里内部就曾直面这种情况：在可以预见的时间内，单个集群的规模无法再容纳所有的数据。

解决方案是扩大单集群的规模，同时让应用系统可以管理多个集群。在这个背景下，ODPS作为一个海量数据的处理平台，结合5K项目开发了多集群管理的功能，使得数据处理的规模跨上了一个新的台阶。当单个计算集群的存储或计算容量不足时，将数据重新分布到新的集群上。更重要的一点是，这种跨多个集群的能力，对上层应用是透明的，用户在运行SQL或者Graph模型时，不必了解数据是分布在哪个物理集群上，如图2所示。

图2  ODPS的跨集群能力

网站日志分析

这里，我们将基于最常见的网站日志分析这一应用场景，实践如何通过ODPS来构建企业数据仓库，包括数据的导入导出以及清洗转换。其ETL过程与基于传统数据库的解决方法并不完全一致，在数据传输环节并没有太多的清洗转换，这项工作是在数据加载到ODPS后，用SQL来完成的。在数据加载到ODPS后，可以充分利用平台的水平扩展能力，处理的数据量可以轻松地扩展到PB级别，而且作为一个统一的平台，除构建数据仓库外，在ODPS中利用内置的功能即可进行数据挖掘和建模等工作。在实际工作中，数据采集、数仓构建和数据挖掘等都是由不同的团队来完成的，针对这一情况，ODPS中提供了完善的安全管理功能，可以精确地控制每个人可以访问到的数据内容（下例中为突出主要的过程，忽略了用户的授权管理）。

数据来源于网站酷壳（CoolShell.cn）上的HTTP访问日志数据（access.log），格式如下：

一个典型的企业数据仓库通常包含数据采集、数据加工和存储、数据展现等几个过程，如图3所示。

图3  数据仓库主要过程

数据采集

真实的网站日志数据中不可避免地会存在很多脏数据，可以先通过脚本对源数据做简单的处理解析，去掉无意义的信息，例如第二个字段“-”。在数据量比较大的情况下，单机处理可能成为瓶颈。这时可以将原始的数据先上传到ODPS，充分利用分布式处理的优势，通过ODPS SQL对数据进行转换。

在ODPS中，大部分的数据都是以结构化的表形式存在的，因此第一步要创建ODS层源数据表。由于数据是每天导入ODPS中，所以采取分区表，以日期字符串作为分区，在ODPS CLT中执行SQL如下：

假设当前数据是20140301这一天的，添加分区如下：

解析后的数据文件在/home/admin/data/20140301/output.log下，通过dship命令导入ODPS中，如下：

数据加工和存储

在ods_log_tracker表中，request字段包含三个信息：HTTP方法、请求路径和HTTP协议版本，如“GET /articles/4914.html HTTP/1.1”。在后续处理中，会统计方法为GET的请求总数，并对请求路径进行分析，因而可以把原始表的request字段拆解成三个字段method、url和protocol。这里使用的是ODPS SQL内置的正则函数解析的字符串并生成表dw_log_parser：

与传统的RDBMS相比，ODPS SQL面向大数据OLAP应用，没有事务，也没有提供update和delete功能。在写结果表时，尽量采用INSERT OVERWRITE到某个分区来保证数据一致性（如果用户写错数据，只需要重写该分区，不会污染整张表）。如果采用INSERT INTO某张表的方式，那么在作业因各种原因出现中断时，不方便确定断点并重新调度运行。

ODPS SQL提供了丰富的内置函数，极大方便了应用开发者。对于某些功能，如果SQL无法完成的话，那么可以通过实现UDF（用户自定义函数）来解决。例如希望将ip字段转化成数字形式，从而和另一张表关联查询，可以实现UDF，如下：

编译生成JAR包udf_ip2num.jar，将它作为资源上传到ODPS，然后创建函数并测试，如下：

表dual（需要用户自己创建）类似于Oracle中的dual表，包含一列和一行，经常用于查询一些伪列值（pseudo column），是SQL开发调试的利器。

对于较复杂的数据分析需求，还可以通过ODPS DAG（类似MapReduce）编程模型来实现。篇幅限制，这里不一一介绍。

图4  PV/UV展示结果

数据展现

应用数据集市往往是面向业务需求对数据仓库表进行查询分析，例如统计基于终端设备信息的PV和UV，生成结果表adm_user_measures。R是一款开源的、功能强大的数据分析工具。通过R来绘图，展示结果报表可以有两种方式：一是通过dship命令将数据导出到本地，再通过R展现结果；二是在R环境中安装RODPS Package，直接在R中读取表中的数据并展现。在RStudio中，基于小样本数据统计的展现结果如图4所示。

迁移到ODPS

Hadoop作为开源的大数据处理平台，已得到了广泛应用。在使用hadoop集群的用户，可以比较轻松地迁移到ODPS中，因为ODPS SQL与Hive SQL语法基本一致，而MapReduce作业可以迁移到更加灵活的DAG的执行模型。对于数据的迁移，可以通过ODPS Tunnel来完成。

数据通道服务ODPS Tunnel是ODPS与外部交互的统一数据通道，能提供高吞吐量的服务并且能够水平进行服务能力的扩展。Tunnel服务的SDK集成于ODPS SDK中。实际上，dship也是调用SDK实现的客户端工具，支持本地文件的导入导出。我们鼓励用户根据自己的场景需求，开发自己的工具，例如基于SDK开发对接其他数据源（如RDBMS）的工具。

把海量数据从Hadoop集群迁移到ODPS的基本思路是：实现一个Map Only程序，在Hadoop的Mapper中读取Hadoop源数据，调用ODPS SDK写到ODPS中。执行逻辑大致如图5所示。

Hadoop MapReduce程序的执行逻辑主要包含两阶段：一是在客户端本地执行，如参数解析和设置、预处理等，这在main函数完成；二是在集群上执行Mapper，多台Worker分布式执行map代码。在Mapper执行完成后，客户端有时还会做一些收尾工作，如执行状态汇总。

图5  Hadoop到ODPS的数据迁移

这里，我们在客户端本地的main函数中解析参数，创建UploadSession，把SessionID传给Mapper，Mapper通过SessionID获取UploadSession，实现写数据到ODPS。当Mapper执行完成后，客户端判断执行结果状态，执行Session的commit操作，把成功上传的数据Move到结果表中。

默认情况下，Hadoop会自动根据文件数划分Mapper个数。在文件大小比较均匀时，这种方式没什么问题。然而存在大文件时，整个大文件只在一个Mapper中执行可能会很慢，造成性能瓶颈。这种情况下，应用程序可自己对文件进行切分。

下面实现一个类Hdfs2ODPS来完成这个功能。其中run函数完成了前面提到的主要逻辑，主要代码如下（其中包括了对ODPS Tunnel的使用）：

在这个函数中，首先调用函数parseArguments对参数进行解析（后面会给出），然后初始化DataTunnel和UploadSession。创建UploadSession后，获取SessionID，并设置到conf中，在集群上运行的Mapper类会通过该conf获取各个参数。然后，调用runJob函数，其代码如下：

runJob函数设置Hadoop conf，然后通过JobClient.runJob(conf);启动Mapper类在集群上运行，最后调用conf.getNumMapTasks() 获取Task数，Task数即上传到ODPS的并发数。在Mapper中，可以通过conf.getLong("mapred.task.partition")获取Task编号，其值范围为[0, NumMapTasks)。因此，在Mapper中可以把Task编号作为上传的blockid。客户端在Mapper成功返回时，就完成commit所有的Session。

应用实践注意点

与单机环境相比，在ODPS这样的分布式环境中进行开发，思维模式上需要有很大转变。下面分享一些实践中的注意点。

在分布式环境下，数据传输需要涉及不同机器的通信协作，可以说它是使用ODPS整个过程中最不稳定的环节，因为它是一个开放性问题，由于数据源的不确定，如文件格式、数据类型、中文字符编码格式、分隔符、不同系统（如Windows和Linux）下换行符不同，double类型的精度损失等，存在各种未知的情况。脏数据也是不可避免的，在解析处理时，往往是把脏数据写到另一个文件中，便于后续人工介入查看，而不是直接丢弃。在上传数据时，Tunnel是Append模式写入数据，因而如果多次写入同一份数据，就会存在数据重复。为了保证数据上传的“幂等性”，可以先删除要导入的分区，再上传，这样重复上传也不会存在数据重复。收集数据是一切数据处理的开始，所以必须非常严谨可靠，保证数据的正确性，否则在该环节引入的正确性问题会导致后续处理全部出错，且很难发现。

对于数据处理流程设计，要特别注意以下几点。

• 数据模型：好的数据模型事半功倍。
• 数据表的分区管理：如数据每天流入，按日期加工处理，则可以采取时间作为分区，在后续处理时可以避免全表扫描，同时也避免由于误操作污染全表数据。
• 数据倾斜：这是作业运行慢的一个主要原因，数据倾斜导致某台机器成为瓶颈，无法利用分布式系统的优势，主要可以从业务角度解决。
• 数据的产出时间：在数据处理Pipeline中，数据源往往是依赖上游业务生成的，上游业务的数据产出延迟很可能会影响到整个Pipeline结果的产出。
• 数据质量和监控：要有适当的监控措施，如某天发生数据抖动，要找出原因，及时发现潜在问题。
• 作业性能优化：优化可以给整个Pipeline的基线留出更多时间，而且往往消耗资源更少，节约成本。
• 数据生命周期管理：设置表的生命周期，可以及时删除临时中间表，否则随着业务规模扩大，数据会膨胀很快。

此外，数据比对、A/B测试、开发测试和生产尽可能采用两个独立的Project。简言之，在应用开发实践中，要理解计费规则，尽可能优化存储计算开销。

ODPS现状和前景

阿里巴巴提出了“数据分享第一平台”的愿景，其多年来坚持投资开发ODPS平台的初心就是希望有一天能够以安全和市场的模式，让中小互联网企业能够使用阿里巴巴最宝贵的数据。阿里内部提出了所有数据“存、通和用”，将不同业务数据关联起来，发挥整体作用。ODPS目前正在发展中，它在规模上，支持淘宝核心数据仓库，每天有PB级的数据流入和加工；在正确性上，支持阿里金融的小额无担保贷款业务，其对数据计算的准确性要求非常苛刻；在安全上，支持支付宝数据全部运行在ODPS平台上，由于支付宝要符合银行监管需要，对安全性要求非常高，除了支持各种授权和鉴权审查，ODPS平台还支持“最小访问权限”原则：作业不但要检查是否有权限访问数据，而且在整个执行过程中，只允许访问自己的数据，不能访问其他数据。

前面的示例只是展现了ODPS的冰山一角。作为阿里巴巴云计算大数据平台，ODPS采用内聚式平台系统架构，各个组件紧凑内聚，除了结构化数据处理SQL、分布式编程模型MapReduce外，还包含图计算模型、实时流处理和机器学习平台，如图6所示。

图6  ODPS功能模块

随着ODPS对外开放的不断推进和第三方数据的流入，相信会有各种创新在ODPS上生根发芽、开花结果。

尽管如此，云计算和大数据是两个新兴的领域，技术和产品发展日新月异。作为一个平台，虽然ODPS已在阿里内部被广泛使用，但在产品和技术上还有很多方面需要进一步完善和加强，希望ODPS能够和云计算大数据应用共同成长，成为业界最安全、最可靠和最方便易用的平台。

本文主要内容节选自作者即将出版的新书《ODPS权威指南》。

本文作者：张云远，长期工作于数据仓库及BI领域，先后任职于建设银行、TCS及惠普，2011年加入阿里云，担任ODPS产品经理，主要负责SQL模块的产品功能。经历了阿里金融等数据仓库在ODPS上的建设过程，作为登月一号项目的PM负责将小微金服离线数据平台迁移到ODPS。

李妹芳，阿里数据平台事业部工程师，曾译有《linux系统编程》、《数据之美》、《数据可视化之美》等书，其新书《ODPS权威指南》即将上市。

在云栖TechDay第十五期活动上，阿里云iDST资深技术专家褚崴给大家带来了《阿里云机器学习平台》的分享，他以机器学习的概念入手展开了此次分享，演讲中他重点介绍了阿里云机器学习平台的基础架构和产品特点，并结合阿里内部的芝麻信用分、推荐系统等场景讲解了PAI平台的具体应用方案。

下文根据褚崴的演讲内容整理。

---

 

机器学习

图一 机器学习分类

机器学习简单来说就是，人教机器在我们积累的数据当中发现规律，然后能够辅助我们来做一些预测和决策。

机器学习笼统地讲可以分为三类：

1）有监督学习(supervised learning)，是指每个样本都有对应的期望值，然后通过搭建模型，完成从输入的特征向量到目标值映射，典型的例子是回归和分类问题；

2）无监督学习(unsupervised learning)，是指在所有的样本中没有任何目标值，我们期望从数据本身发现一些潜在的规律，比如说做一些简单的聚类；

3）增强学习(Reinforcement learning)相对来说比较复杂，是指一个系统和外界环境不断地交互，获得外界反馈，然后决定自身的行为，达到长期目标的最优化，其中典型的案例就是阿法狗下围棋，或者无人驾驶。

图二 机器学习兴起的因素

最近几年，机器学习比以前更火了，主要是我们在深度学习技术上取得了一定的进展，总结起来应该是三大因素：

第一个因素是数据的因素。互联网上每天生成海量的数据，有图像、语音、视频、还有各类传感器产生的数据，例如各种定位信息、穿戴设备；非结构化的文本数据也是重要的组成部分。数据越多，深度学习越容易得到表现好的模型。

第二个因素是大规模分布式高性能计算能力的提升。这些年来，GPU高性能计算、分布式云计算等计算平台迅猛发展，让大规模的数据挖掘和数据建模成为可能，也为深度学习的飞跃创造了物质基础；阿里云的愿景之一就是成为和水电煤一样的基础设施。

第三个因素是指算法上的创新。随着数据和计算能力的提升，算法本身也有了很大的进展，尤其在深度学习方面，譬如从脑神经学上得到的灵感，在激活函数上进行了稀疏性的处理，等等。

基于上述三点，人工智能又迎来了它的第二个春天。人工智能将以更快的速度进入我们的生产和生活中来，成为我们的眼睛，我们的耳朵，帮助我们更快捷地获取信息，辅助我们做出决策。机器学习平台产品也因此而产生，加速迭代过程，助力技术的发展。

机器学习平台：PAI 平台

图三 主流机器学习平台

阿里去年发布了自己的智能平台，其目的是为了加速整个创新过程，提高工作效率。该平台是基于阿里云的云计算平台，具有处理超大规模数据的能力和分布式的存储能力，同时整个模型支持超大规模的建模以及GPU计算。此外，该平台还具有社区的特点：实验结果可共享、社区团队相互协作。该智能平台主要分为三层，第一层是Web UI界面，第二层是IDST算法层，最后一层是ODPS平台层。下文更加详细地介绍。

图四 PAI平台内部界面

上图所示的是PAI平台内部的界面。左边是主要功能区，中间是一个画布。使用者可以用鼠标将相应的组件拖拽到画布上，形成一个有向的工作流，完成从元数据到数据处理再到建模等一系列的数据挖掘工作。右边主要是用于设置组件内参数。

下面来介绍下它主要功能：

• 搜索功能：当我们有很多数据、表、实验时，可以通过搜索功能快速查找到你需要的资料；
  
• 实验列表：通过双击实验名称，在画布上显示原来的有向实验流图，可以继续之前没有完成的实验；
  
• 数据表，它类似于文件管理器，可以查看你所有的数据表；
  
• 算法和工具列表，包含了常用的机器学习算法组件等核心功能；
  
• 模型列表，通过该功能，使用者可以管理所有的模型，并且可以与其他使用者共享这些产品模型。
  

 

图五 建立一个模型训练实验

建立一个模型训练实验的步骤包括：首先，选择有运行权限的Project，新建算法实验；然后在组件列表中拖拉ODPS源、特征工程、机器学习算法等组件搭建挖掘流；最后点击运行即可。

图六 数据探索分析

在整个过程当中，需要做进行一些数据的探索分析，所有的算法都会提供一个重要性的分析，提供特征排序。这里面最为重要的是评估分析，我们希望整个评估是全面而准确的。

图形工作流的优势在于，使用者可以很容易地进行循环实验。因为在模型优化时，需要多次循环迭代优化，通过该模板，每次修改相应的参数再进行重复实验，大大提高了工作效率。  

图七 PAI平台特点

该平台通过交互的界面降低了技术门槛，使用者可以轻松实现数据挖掘的工作，而无需太多经验；其次，其内嵌的算法，都是经过阿里内部多年的淬炼，在性能和准确率上都有较大的提升；最后是数据智能，该平台提供了从元数据到模型部署整套流程，通过提供基本的组件，使用者可以搭建各个垂直场景下的解决方案。

我们的客户主要包括以下几部分：一类是传统的大型企业和政府部门，如中石化、中石油、气象局等；另一类是中小企业，主要是公共云上的初创用户；以及一些个人用户，如数据科学家，研究人员等。

图八 PAI平台架构图

上图是PAI整体框架图，最底层是基础设施层，包括CPU和GPU集群；其上一层是阿里提供的计算框架，包括MaxCompute的MapReduce/SQL/MPI等计算方式；中间一层是模型算法层，包含数据预处理，特征工程，机器学习算法等基本组件，帮助使用者完成简单的工作；平台化产品主要是项目管理、算法模型分享，以及一些特定的需求；最上层是应用层，阿里内部的搜索、推荐、蚂蚁金服等项目在进行数据挖掘工作时，都是依赖PAI平台产品。 

目前依托于PAI机器学习平台，提供基本组件，通过拖拽的操作，完成工作流程的整体布局；同时在垂直场景下，提供一些更为专业的组件，例如在文本分析方面，我们提供了一套完整的文本分析的算法组件。

产品特点

接下来，介绍一下参数服务器和分布式深度学习的算法产品两部分。

去年我们基于非常流行的深度学习开源工具Caffe做了一版改造，将单机版的Caffe改造成了多机版的Caffe，内部我们称其为Pluto。在GPU和机器之间的通信进行了相应的开发，使其支持流水式通信，在必要时可以占满带宽，减少空闲等待时间，该产品同样支持DNN、CNN、RNN等常用的机器学习模型。

图九 Pluto

Pluto主要的特点在于数据的分片，每个GPU只处理一部分数据。如果我们采用16个GPU，则处理数据的规模就比以前扩大了16倍；另外，采用了InfiniBand来做机与机之间的通信，理论上具有56G通信的带宽。GPU的调度，是由阿里云集群调度管理完成的，摆脱了单机的模式。在Pluto做开发时，使用方式完全兼容Caffe，扩展性很强。

 

图十 Pluto 性能提升

上面是一个加速比的图。我们做了一个对比实验：如果你用8卡跟1卡的性能做比较，你会得到将近7倍的性能提升。

图十一 参数服务器

下面向大家介绍下参数服务器，其主要思想是：不仅仅是进行数据并行，同时将模型分片，将大的模型分为多个子集，每个参数服务器只存一个子集，全部的参数服务器聚合在一起拼凑成一个完整的模型。该系统主要的创新点在于失败重试的功能，在分布式系统上，上百个节点协同工作时，经常会出现一个或几个节点挂掉的情况，如果没有失败重试机制，任务就会有一定的几率失败，需要重新提交任务到集群调度。

失败重试是将每个节点的状态备份到相邻（前后）的节点，当个别节点死掉后，重启一个新的节点，同时从原节点相邻的节点获取所存储的状态，理论上可以实现任务的100%完成。

还有一个功能是异步迭代，无需等待全部节点完成任务，当大部分节点完成任务时，就可以直接更新对应的模型，这样可以不需要等待慢机的结果，从而摆脱慢机的影响，提升效率。  

应用案例 

下面介绍在阿里内部的三个应用场景。

图十二 应用一：推荐系统

第一个应用是推荐系统，主要是参数服务器在推荐系统内的应用。当在淘宝购物时，经查询显示的商品一般都是非常个性化的推荐，它是基于商品的信息和用户的个人信息以及行为信息三者的特征提取。这个过程中形成的特征一般都是很大，在没有参数服务器时，采用的是MPI实现方法，MPI中所有的模型都存在于一个节点上，受限于自身物理内存上限，它只能处理2000万个特征；通过使用参数服务器，我们可以把更大模型（比如说2亿个特征的模型），分散到10个或者是100个参数服务器上，打破了规模的瓶颈，实现了性能上的提升。

图十三 应用二：芝麻信用分

第二个应用是芝麻信用分。芝麻信用分是通过个人的数据来评估你个人信用。做芝麻信用分时，我们将个人信息分成了五大纬度：身份特质、履约能力、信用历史、朋友圈状况和个人行为进行评估信用等级。

在去年，我们利用DNN深度学习模型，尝试做芝麻信用分评分模型。

输入是用户原始的特征，基于专家知识将上千维的特征分为五部分，每部分对应评分的维度。我们通过一个本地结构化的深度学习网络，来捕捉相应方面的评分。由于业务对解释性的需求，我们改变了模型的结构，在最上面的隐层，一共有五个神经原，每个神经原的输出都对应着它五个维度上面值的变化；再往下一层，是改变维度分数的因子层；用这种本地结构化的方式，维持模型的可解释性。

  

图十四 应用三：光学文字识别

 

最后一个应用是图象上面的光学文字的识别。我们主要做强模板类、证件类的文字识别，以及自然场景下文字的识别。强模板服务（身份证识别）在数加平台上也提供了相应的入口，目前可以达到身份证单字准确率99.6%以上、整体的准确率93%。

在识别中用到的是CNN模型，但其实整个流程特别长，不是深度学习一个建模就能解决的问题，包括版面分析、文字行的检测、切割等等技术。在CNN训练中，我们采用了多机多卡分布式算法产品，之前利用一千万个图像训练CNN模型，大约需要耗时70个小时，迭代速度非常缓慢；采用分布式8卡产品之后，不到十个小时就可以完成模型训练。

总结

阿里云机器学习平台既支持深度学习，又支持CPU、GPU任务混合调度。接下来发展的方向，是数据智能的方向，一是提供智能化的组件，例如将参数调优的工作也替用户完成；另一个就是开发垂直应用领域需要的算法组件，逐渐形成行业解决方案。  

---

关于分享者

褚崴博士，现任职阿里云iDST资深技术专家，负责分布式机器学习平台产品的研发。之前先后曾任职美国微软首席科学家，美国雅虎实验室科学家，美国哥伦比亚大学副研究科学家。2003年至2006年，在英国伦敦大学学院Gatsby Unit做博士后研究工作，2003年在新加坡国立大学获得博士学位，统计机器学习方向。在顶级期刊和国际会议上累计发表40余篇论文，ACM WSDM 2011年会获得最佳论文奖。2015年入选浙江省“千人计划”创新人才，2016年入选第十二批国家“千人计划”创新长期类人才。

“你学习一门技术的最佳时机是三年前，其次是现在。”这话从来很灵验。经过这次面试，觉得需要整理下Java Web相关的资料，以便自己提高或者更快适应可能面临的新的工作。

　　首先谈谈java Web需要掌握哪些东西。这里是一些知识点的搜集，暂不做详细说明，欢迎各位博友补充指正。

1.底层

• Java语言相关的就不说了，首先是JVM的结构和工作原理。比较重要的是Java内存模型，各种GC算法，Classloader的加载原理等。个人对底层的一些东西还算比较了解，所以不过多纠结，实际上程序编译链接过程以及二进制文件的处理还是很值得研究的。
• JVM监控及调优。作为一个开发人员并不一定需要非常熟悉JVM调优的方法，但如果具备JVM监控及调优的能力，将让你对程序运行状况了如指掌，对于问题定位也会敏感得多。
• Java多线程。对于线程安全的理解，以及如何在自己的程序中避免多线程造成的不一致问题等。
• I/O。Java中常常提到的是BIO/NIO，即阻塞型I/O与非阻塞型I/O，其实并不难理解，结合Linux中的同步I/O和异步I/O的实现原理，基本都是相通的，每种I/O方式解决的问题，又存在什么问题，为什么使用epoll。

2.Servlet

　　Servlet是运行于服务端的Java程序，一般实现自己的Java服务端应用都从HttpServlet类继承，然后实现自己的init | doGet | doPost | service方法。Servlet的生命周期从其加载开始，首先执行一次初始化，调用init方法，之后便可运行自身的服务，当生命周期结束时，调用destroy方法回收资源，结束服务。

　　仅了解原理当然是不够的，还要实战能力，在IDE中写写简单的代码谁都会，然而真正让一个程序能够运行起来也还需要点其他的东西，这里我指的是Servlet的容器。servlet的容器有很多，常用的以Tomcat为例，安装好Tomcat后，在开发时必须包含进Tomcat的lib。IDE确实惯坏了好多人，目录如何组织，程序如何编译、如何部署这些问题都被IDE屏蔽掉了，如果要对整体有比较透彻的了解，建议一切从命令行动手。

　　具体可参考：《Servlet与JSP核心编程》。

3.框架

　　Java Web开发的用到的框架之多简直令人发指，而且因为版本的更新换代导致的问题也是层出不穷。然而这也是Web技术不断演化的结果，要么选择接受，要么引领节奏。

Spring

　　spring是一个强大而又“轻量级”的Java开发框架，之所以打引号是因为感觉并不是那么轻量。Spring的主要目的在于简化Java应用开发，以配置方式代替硬编码方式的编程，模块解耦，其架构如下图所示。包括了数据访问、远程通信、AOP、核心容器等部分。

　

 Figure 1 Spring体系架构

　　Spring的核心主要有三点：

• IoC：反转控制。

　　反转控制就是指将控制权由类内部抽离到容器，由容器类的实例化及动作进行配置管理。

• Dependency-injection：依赖注入  

　　对象的依赖关系由负责协调系统中各个对象的第三方组件在创建对象时设定。对象不自行创建或管理它们的依赖关系，依赖关系被自动注入到需要它们的对象中。通过参数和配置能够体会出“注入”这个词在这里有多形象。依赖注入的最大好处就是松耦合。不需要再类内部去和特定的类进行绑定，而是将一些依赖关系以参数的形式注入到类内部。

• Aspect Oriented Programming：面向切向编程

 　　在软件开发中，分布于应用中多处的功能被称为横切关注点。这些横切关注点往往和业务逻辑是相分离的，将这些横切关注点与业务逻辑相分离正式AOP要解决的。AOP编程能够让遍布在应用各处的功能分离出来形成可重用的组件。是高内聚低耦合的又一个体现，将通用实现模块与核心业务模块相分离。

 　　具体参考：《Spring In Action》

Hibernate

　　数据持久化框架其实也有很多，需要掌握的不仅是hibernate，只是因为Hibernate在以前的企业级应用中用的比较多而已，另外MyBatis也占有相当重要的份额。Hibernate是一个全自动的持久化框架，并不是那么方便，所以很多开发者更倾向于使用MyBatis，淘宝就是这样。

　　Hibernate的工作流程：首先通过configuration对象读取配置文件；解析映射信息，创建StandardSessionFactory；调用openSession打开session；创建事务transaction，之后进行持久化操作；完成后提交事务，关闭session，关闭sessionFactory。

 Figuer 2 Hibernate工作流程

　　要理解ORM的理念：ORM意为对象关系映射。是一种为了解决程序的面向对象模型与数据库关系模型互不匹配问题的技术。

　　hibernate中比较重要的是对象的4种状态转换及条件。分别是transient瞬时态、persistent持久态、detached游离态和移除态，状态转换如下：

 

 Figure 3 Hibernate对象状态转换图

Struts 2

　　Struts出现的最早，也是思想提供者之一，从名字就可以看得出其重要性，其设计目的是为了简化Java开发，统一事务切面化。

　　Struts最关键的地方在于Action的执行，拦截器的原理、valuestack及OGNL。

 　　具体参考：《Struts in Action》

 4.HTTP

　　这个不用多谈，太重要了，作为Web开发者，如果不特别熟悉Http将会是一件很麻烦的事。

• Http的报头格式
• Http协议的各种返回码是什么意思
• https如何实现
• B/S架构的工作原理
• Cookie和Session的原理
• restful API

5.设计模式

　　这里就不列举23种模式了，个人觉得纯粹看书学习《设计模式》并没有什么用，要在实际应用中碰到，并且多问几个为什么，而且自己写代码时能有使用设计模式的意识才能对各种设计模式有更深的领悟。

 

　　当然Web开发远不止这么些东西，我这里暂时也只好先列些重要的。应用开发后，还有部署的问题，因此又会涉及CDN和负载均衡等问题就更复杂了......

　　另外在Web开发的过程中，要养成良好的开发习惯，比如开发之前能够熟练地使用UML类图，交互图等，这将避免你犯很多错误。感谢面试官轻虐，自己觉得还有许多不扎实的地方，还需要继续努力才能对得起这次机会。

转载来源：

http://blog.csdn.net/nicholas_liu2017/article/details/72872322

http://blog.csdn.net/nicholas_liu2017/article/details/73065661

http://blog.csdn.net/nicholas_liu2017/article/details/73521750