文章/答案/技术大牛

发布

社区首页 >专栏 >【经验】数据仓库和大数据系统框架及常见问题

【经验】数据仓库和大数据系统框架及常见问题

辉哥

发布于 2020-06-02 07:10:59

2.6K0

文章被收录于专栏：区块链入门区块链入门

1. 摘要

笔者在学习过程中遇到的大数据框架，系统和数据库遇到的一些问题总结，也分享给大家一起学习。

2. 数据仓库框架及案例

2.1 数据仓库架构的演变

(1) 数据仓库架构演变

数据仓库概念是Inmon于1990年提出并给出了完整的建设方法。随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。

后来随着业务实时性要求的不断提高，人们开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，这便是Lambda架构。

再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。

框架演进

随着大数据应用的发展，人们逐渐对系统的实时性提出了要求，为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

Lambda架构-抛弃

Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构

Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。

Kappa架构-实时需求

(2) 阿里MaxComputer数仓分层

在阿里巴巴的数据体系中，我们建议将数据仓库分为三层，自下而上为：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。数据仓库的分层和各层级用途如下图所示：

1）数据引入层ODS（Operation Data Store）： 存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到MaxCompute的职责，同时记录基础数据的历史变化。

2）数据公共层CDM（Common Data Model，又称通用数据模型层） 包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

<1> 公共维度层（DIM-Dimension）： 基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。

<2> 公共汇总粒度事实层（DWS- Data Warehouse Service）： 以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。例如，服务层--留存-转化-GMV-复购率-日活，点赞、评论、收藏; 轻度聚合对DWD

<3> 明细粒度事实层（DWD-Data Warehouse Detail）： 以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。数据明细详情，去除空值，脏数据，超过极限范围的明细解析,具体表。明细粒度事实层的表通常也被称为逻辑事实表。

3）数据应用层ADS（Application Data Service）：存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。整体数据分类架构如下图所示：

在本教程中，从交易数据系统的数据经过DataWorks数据集成，同步到数据仓库的ODS层。经过数据开发形成事实宽表后，再以商品、地域等为维度进行公共汇总。整体的数据流向如下图所示。其中，ODS层到DIM层的ETL（萃取（Extract）、转置（Transform）及加载（Load））处理是在MaxCompute中进行的，处理完成后会同步到所有存储系统。ODS层和DWD层会放在数据中间件中，供下游订阅使用。而DWS层和ADS层的数据通常会落地到在线存储系统中，下游通过接口调用的形式使用。

2.2 数据仓库的标准架构

样例1

样例2

（1）数据采集层： 数据采集层的任务就是把数据从各种数据源中采集和存储到数据库上，期间有可能会做一些ETL（抽取extra，转化transfer，装载load ）操作。数据源种类可以有多种：

日志： 作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；
业务数据库： 如Mysql、Oracle 。业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案，有资源的话，可以基于DataX之上做二次开发，就能非常好的解决。当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。
来自HTTP/FTP的数据：合作伙伴提供的接口。有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；
其他数据源：如Excel等需要手工录入的数据

实时采集现在也成了大数据平台的标配，主流就是FLUME+KAFKA。

（2）数据存储与分析

HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。
使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。
Spark性能比MapReduce好很多，同时使用SparkSQL操作Hive。
Spark Streaming 是 Spark 核心 API 的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。 Spark Streaming 支持从多种数据源获取数据，包括 Kafka、Flume、Twitter、ZeroMQ、Kinesis 以及 TCP Sockets。从数据源获取数据之后，可以使用诸如 map、reduce、join 和 window 等高级函数进行复杂算法的处理，最后还可以将处理结果存储到文件系统、数据库和现场仪表盘中。
MLlib是Spark提供的可扩展的机器学习库。MLlib已经集成了大量机器学习的算法

（3）数据共享

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。

（4）数据应用

报表：报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层。
接口：接口的数据都是直接查询数据共享层即可得到。
即席查询：即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层直接查询。一般都是通过直接操作SQL得到。

2.3 菜鸟仓配实时数据仓库

（1）整体设计

整体设计如下图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。

（2）数据模型

不管是从计算成本，还是从易用性，还是从复用性，还是从一致性……，我们都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，我们将实时中间层分为两层。

第一层 DWD公共实时明细层

实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到ADS（Application Data Store，报表层），供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用；

第二层 DWS公共实时汇总层

以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出。轻度汇总层写入ADS，用于前端产品复杂的olap查询场景，满足自助分析和产出报表的需求；高度汇总层写入Hbase，用于前端比较简单的kv查询场景，提升查询性能，比如实时大屏等；

注： 1.ADS是一款提供OLAP分析服务的引擎。开源提供类似功能的有，Elastic Search、Kylin、Druid等； 2.案例中选择把数据写入到Hbase供KV查询，也可根据情况选择其他引擎，比如数据量不多，查询压力也不大的话，可以用mysql

（3）数据保障

集团每年都有双十一等大促，大促期间流量与数据量都会暴增。实时系统要保证实时性，相对离线系统对数据量要更敏感，对稳定性要求更高。

所以为了应对这种场景，还需要在这种场景下做两种准备：

大促前的系统压测；
大促中的主备链路保障；

（4）实时数仓与离线数仓的对比

在看过前面的叙述与菜鸟案例之后，我们看一下实时数仓与离线数仓在几方面的对比：

[1] 首先，从架构上，实时数仓与离线数仓有比较明显的区别，实时数仓以Kappa架构为主，而离线数仓以传统大数据架构为主。Lambda架构可以认为是两者的中间态。

[2] 其次，从建设方法上，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外实时数仓中实时流数据的join有隐藏时间语义，在建设中需注意。

[3] 最后，从数据保障看，实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。

2.4 电商网站的数据仓库

（1）电商网站数据仓库分层图

上图可以认为是一个电商网站的数据体系设计。我们暂且只关注用户访问日志这一部分数据。

在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。

为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。

在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表；

然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。

最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。

备注：例子只是为了简单地说明每一层的作用，并不是最合理的解决方案，大家辩证地看待即可。

（2）电商网站数据仓库技术栈

数据层的存储一般如下：

Data Source： 数据源一般是业务库和埋点，当然也会有第三方购买数据等多种数据来源方式。业务库的存储一般是Mysql 和 PostgreSql。

ODS 层： ODS 的数据量一般非常大，所以大多数公司会选择存在HDFS上，即Hive或者Hbase，Hive居多。

DW 层： 一般和 ODS 的存储一致，但是为了满足更多的需求，也会有存放在 PG 和 ES 中的情况。

APP 层： 应用层的数据，一般都要求比较快的响应速度，因此一般是放在 Mysql、PG、Redis中。

计算引擎的话，可以简单参考图中所列就行。目前大数据相关的技术更新迭代比较快，本节所列仅为简单参考。

3. 问题

3.1 Haddoop中的hdfs、hbase、 hive区别与联系？

（1）Hive： Hive不支持更改数据的操作，Hive基于数据仓库，提供静态数据的动态查询。其使用类SQL语言，底层经过编译转为MapReduce程序，在Hadoop上运行，数据存储在HDFS上。

（2）Pig： Pig的语言层包括一个叫做PigLatin的文本语言,Pig Latin是面向数据流的编程方式。Pig和Hive类似更侧重于数据的查询和分析，底层都是转化成MapReduce程序运行。

区别是Hive是类SQL的查询语言，要求数据存储于表中，而Pig是面向数据流的一个程序语言。

（3）Sqoop： Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

（4）Hbase: Hbase是Hadoop database，即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。

HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据。

Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

（5）HDFS: HDFS是GFS的一种实现，他的完整名字是分布式文件系统，类似于FAT32，NTFS，是一种文件格式，是底层的。

Hive与Hbase的数据一般都存储在HDFS上。Hadoop HDFS为他们提供了高可靠性的底层存储支持。

3.2 穿透和雪崩效应的概念和解决方案

（1）缓存穿透

概念缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要发生jdbc请求，去数据库再查询一遍，然后返回空。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

解决方案 如果查询数据库也为空，直接在Redis中设置一个为null的结果，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。当真正存入该数据时，清空相应的缓存即可。

（2）缓存雪崩

概念由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期间（缓存正常从Redis中获取）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机，造成系统的崩溃。

如果Redis中所有的key在同一实际失效的话，如果有大量的请求调用数据库，灰指甲导致整套系统瘫痪，这就是雪崩效应。

解决方案

加锁或者队列的方式这样可以保证来保证不会有大量的线程对数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力。但是与此同时又降低了系统的吞吐量。
分析用户的行为，尽量让缓存失效的时间均匀分布（也可以均摊失效时间）
使用二级缓存（EhCache+Redis）
使用消息中间件方式如果Redis查不到结果的情况下，这个时间直接扔给消息中间件，等到生产者生产了该消息后，消费者拿到消息就可以进行反馈了。

（3）二级缓存（EhCache+Redis）解决雪崩效应

现在用EhCache作为一级缓存，Redis作为二级缓存，先走本地内存查询，本地缓存如果没有，再走网络连接，这样效率会更高。

3.3 Serverless的概念和使用场景？

（1）概念：什么是 Serverless？

Serverless 圈内俗称为“无服务器架构”，Serverless 不是具体的一个编程框架、类库或者工具。简单来说，Serverless 是一种软件系统架构思想和方法，它的核心思想是用户无须关注支撑应用服务运行的底层主机。这种架构的思想和方法将对未来软件应用的设计、开发和运营产生深远的影响。所谓“无服务器”，并不是说基于 Serverless 架构的软件应用不需要服务器就可以运行，其指的是用户无须关心软件应用运行涉及的底层服务器的状态、资源（比如 CPU、内存、磁盘及网络）及数量。软件应用正常运行所需要的计算资源由底层的云计算平台动态提供。

目前行业可能更多处在容器 Docker+Kubernetes, 利用 IaaS、PaaS和SaaS 来快速搭建部署应用。

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

（2）流行的Serverless 工具、框架和平台

随着 Serverless 的日益流行，这几年业界已经出现了多种平台和工具帮助用户进行 Serverless 架构的转型和落地。目前市场上比较流行的 Serverless 工具、框架和平台有：

AWS Lambda，最早被大众所认可的 Serverless 实现。
Azure Functions，来自微软公有云的 Serverless 实现。
OpenWhisk，Apache 社区的开源 Serverless 框架。
Kubeless，基于 Kubernetes 架构实现的开源 Serverless 框架。
Fission，Platform9 推出的开源 Serverless 框架。
OpenFaaS，以容器技术为核心的开源 Serverless 框架。
Fn，来自 Oracle 的开源 Serverless 框架，由原 Iron Functions 团队开发。

（3）理解Serverless技术—FaaS和BaaS

1）云计算框架演进IaaS,PaaS,SaaS,FaaS,BaaS 云计算的发展从基础架构即服务（Infrastructure as a Service， IaaS），平台即服务（Platform as a Service，PaaS），软件即服务（Software as a Service，SaaS），慢慢开始演变到函数即服务（Function as a Service，FaaS）以及后台即服务（Backend as a Service，BaaS），Serverless 无服务化。

目前业界的各类 Serverless 实现按功能而言，主要为应用服务提供了两个方面的支持：函数即服务（Function as a Service，FaaS）以及后台即服务（Backend as a Service，BaaS）。

2） FaaS（Function as a Service，函数即服务）

FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。其中所指的服务器应用程序，是该技术与容器和PaaS（平台即服务）等其他现代化架构最大的差异。

FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，也不需要全时运行应用程序。

FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。例如AWS Lambda的函数可以通过Javascript、Python以及任何JVM语言（Java、Clojure、Scala）等实现。然而Lambda函数也可以执行任何捆绑有所需部署构件的进程，因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。

在迁往FaaS的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。在FaaS的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。

相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。

FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。

大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。

3） BaaS（Backend as a Service，后端即服务）

BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件（而不是进程内的库）来提供服务。理解BaaS，需要搞清楚它与PaaS的区别。

首先BaaS并非PaaS，它们的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。其次从功能上讲，BaaS可以看作PaaS的一个子集，即提供第三方依赖组件的部分。

BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来，再做成外部服务，而这正是Auth0和Amazon Cognito等产品的目标。它们能实现全面的认证和用户管理，开发团队再也不用自己编写或者管理实现这些功能的代码。

（4）函数计算的一个开发者试用操作流程

阿里云的函数计算是基于Serverless这种架构实现的一个全托管产品，用户只需要上传核心代码到函数计算，就可以通过事件源或者SDK&API来运行代码。函数计算会准备好运行环境，并根据请求峰值来动态扩容运行环境。函数计算是按照执行时间来计费，请求处理完成后，计费停止，对于有业务请求有明显高峰和低谷的应用来说，相对节省成本。

（5）无服务器（Serverless）适用于哪些场景？

1）场景一：应用负载有显著的波峰波谷

Serverless 应用成功与否的评判标准并不是公司规模的大小，而是其业务背后的具体技术问题，比如业务波峰波谷明显，如何实现削峰填谷。一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。

业界普遍共识是，当自有机器的利用率小于 30%，使用 Serverless 后会有显著的效率提升。对于云服务厂商，在具备了足够多的用户之后，各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。

2）场景二：典型用例 - 基于事件的数据处理

视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。

开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题

（6）Serverless的局限

世界上没有能解决所有问题的万能解决方案和架构理念。Serverless 有它的特点和优势，但是同时也有它的局限。有的局限是由其架构特点决定的，有的是目前技术的成熟度决定的，毕竟 Serverless 还是一个起步时间不长的新兴技术领域，在许多方面还需要逐步完善。

1.控制力

Serverless 的一个突出优点是用户无须关注底层的计算资源，但是这个优点的反面是用户对底层的计算资源没有控制力。对于一些希望掌控底层计算资源的应用场景，Serverless 架构并不是最合适的选择。

2.可移植性

Serverless 应用的实现在很大程度上依赖于 Serverless 平台及该平台上的 FaaS 和 BaaS 服务。不同IT厂商的 Serverless 平台和解决方案的具体实现并不相同。而且，目前 Serverless 领域尚没有形成有关的行业标准，这意味着用户将一个平台上的 Serverless 应用移植到另一个平台时所需要付出的成本会比较高。较低的可移植性将造成厂商锁定（Vendor Lock-in）。这对希望发展 Serverless 技术，但是又不希望过度依赖特定供应商的企业而言是一个挑战。

3.安全性

在 Serverless 架构下，用户不能直接控制应用实际所运行的主机。不同用户的应用，或者同一用户的不同应用在运行时可能共用底层的主机资源。对于一些安全性要求较高的应用，这将带来潜在的安全风险。

4.性能

当一个 Serverless 应用长时间空闲时将会被从主机上卸载。当请求再次到达时，平台需要重新加载应用。应用的首次加载及重新加载的过程将产生一定的延时。对于一些对延时敏感的应用，需要通过预先加载或延长空闲超时时间等手段进行处理。

5.执行时长

Serverless 的一个重要特点是应用按需加载执行，而不是长时间持续部署在主机上。目前，大部分 Serverless 平台对 FaaS 函数的执行时长存在限制。因此 Serverless 应用更适合一些执行时长较短的作业。

6.技术成熟度

虽然 Serverless 技术的发展很快，但是毕竟它还是一门起步时间不长的新兴技术。因此，目前 Serverless 相关平台、工具和框架还处在一个不断变化和演进的阶段，开发和调试的用户体验还需要进一步提升。Serverless 相关的文档和资料相对比较少，深入了解 Serverless 架构的架构师、开发人员和运维人员也相对较少。

3.4 ETL的定义是什么？

ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL一词较常用在数据仓库，但其对象并不限于数据仓库。 ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据， ETL是BI商业智能项目重要的一个环节。

3.5 数据仓库（DW或DWH）的定义？

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用使用。

（1）数据仓库的特点

面向主题的： 数据仓库都是基于某个明确的主题，仅需要与该主题相关的数据，其他的无关细节将会被去掉。

集成的： 数据仓库里面的数据都是经过ETL（ Extract-Transform-Load 抽取-转换-加载）操作后被集中放到同一个数据源，数据仓库里的数据是来自于各种不同的数据源。

随时间变化的： 关键数据隐式或者显示地随时间变化而变化。

数据相对稳定的： 数据装入后一般只是进行查询操作，没有传统数据库的增删改操作。

总结： 数据仓库就是整合多个数据源的历史数据进行细粒度的、多维的分析，可以有效地帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。

（2）数据仓库的作用

可以整合公司的所有业务，建立统一的数据中心。
分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果。
可以作为各个业务的数据源，形成业务数据互相反馈的良性循环。
可以提供数据报表，用于公司的决策等等。可以提供数据报表，用于公司的决策等等。

注解-数据处理大致可以分成两大类： [1] 联机事务处理OLTP（on-line transaction processing） OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作。

[2] 联机分析处理OLAP（On-Line Analytical Processing） OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 OLAP系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

（3）数据仓库的要求**

高效率： 数据仓库的分析数据一般分为日、周、月、季、年等，可以看出，以日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，如果数据仓库设计的不好，需要延时一到两天才能显示数据，这显然是不能出现这种事情的。

数据质量高： 数据仓库所提供的各种信息，肯定要准确的数据。数据仓库通常要经过数据清洗，装载，查询，展现等多个流程而得到的，如果复杂的架构会有更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据不准确或者有错误，如果客户看到错误的信息就可能导致分析出错误的决策，造成损失经济的损失。

扩展性： 之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，因为如果在未来需要扩展一些新的功能了，就可以不用重建数据仓库系统，就能很稳定运行。因为重建一个数据创库是比较耗费人力和财力。可扩展性主要体现在数据建模的合理性。

（4）数据仓库具体的分层

标准的数据仓库分层：ods（临时存储层），pdw（数据仓库层），mid（数据集市层），app（应用层）。

ods：历史存储层 它和源系统数据是同构的，而且这一层数据粒度是最细的，这层的表分为两种，一种是存储当前需要加载的数据，一种是用于存储处理完后的数据。

pdw：数据仓库层 它的数据是干净的数据，是一致的准确的，也就是清洗后的数据，它的数据一般都遵循数据库第三范式，数据粒度和ods的粒度相同，它会保存bi系统中所有历史数据

mid：数据集市层 它是面向主题组织数据的，通常是星状和雪花状数据，从数据粒度来讲，它是轻度汇总级别的数据，已经不存在明细的数据了，从广度来说，它包含了所有业务数量。从分析角度讲，大概就是近几年。

app：应用层 数据粒度高度汇总，倒不一定涵盖所有业务数据，只是mid层数据的一个子集。

3.6 联机分析处理 (OLAP--online analytical procession) 概念？

（1） OLAP 联机分析处理 (OLAP--online analytical procession) 允许以一种称为多维数据集的多维结构访问来自商业数据源（如数据仓库）的经过聚合和组织整理的数据。 OLAP会为关系数据库带来3个优点：持续的快速响应，基于元数据的查询及电子表格样式的公式。主要优点是能够提前计算数值，这样就能快速地呈现报表。OLAP工具通常分为两种基本基本模式：电子表格模型和数据库模型。 （2） Cube Cube即多维数据集，是指一组用于分析数据的相关度量值和维度，是分析服务中存储和分析的基本单位。Cube是聚合数据的集合，允许查询并快速返回结果。Cube就像一个坐标系，每一个Dimension代表一个坐标系，要想得到一个一个点，就必须在每一个坐标轴上取得一个值，而这个点就是Cube中的Cell。如下（图-1）所示。Cube能够包含不同维度的度量值，因此Cube有时也称为统一维度模型（Unified Dimensional Model，UDM）。

（3）度量（measures）

度量表示用来聚合分析的数字信息，度量的集合组合成了一个特殊的维度。如数量、销售额、利润等。度量值是事实数据，它是用户可能要聚合的事务性值或度量。度量值源自一个或多个源表中的列，并且分组到度量值组。度量可分为两个范畴：存储度量和计算度量。存储度量是直接加载、聚合和存储进数据库的，它们可以从存储的计算结果中获取。计算度量是查询时动态计算度量的值，只有计算规则是存储在数据库中的。度量值可以是“销售额”、“出货量”等。

（4）维度（dimention）

维度是一组属性，表示与多维数据集中度量值相关的领域，并且用于分析多维数据集中的度量值。例如，“客户”维度可能包括“客户名称”、“客户性别”以及“客户所在市县”等属性，用户可以按这些属性对多维数据集中的度量值进行分析。属性源自一个或多个源表中的列。可以将每个维度中的属性组织到层次结构中，以便提供分析路径。比如（图-1）中的三个维度：时间、来源、路线。维度有3个主要的组成部分：层级、级别和属性。

（5）层级（Hierarchy）

维度层级是可选的，但是OLAP系统常见的。一个层级是一个逻辑结构，它将一个维度的成员分组以用于分析。比如，一个Time维度可能有一个描述了月份怎样分组以显示一个季度和季度怎样分组以显示一个整年的层级。一个维度可以有多个层级。一个维度的结构是基于父子关系来组织层级的。

（6）级别（Level）

一个维度上可以包含的层次结构，表示特定的分类。如地域维度可以包含的级别层次级：国家、省、市；时间维度包含的级别层次包含：年、季度、月、日等。每一个级别显示了层级中的一个位置。底层级别上的级别包含了聚合它下面级别的值。不同级别的成员有一个一对多的父子关系。一个层级一般包含几个级别，而一个单独的级别可以包含进不只一个的层级。如果在一个维度上建有多个层级，那么可能一个层级会显示在不只一个的层级中或可能只存在于一个层级中。

（7）属性

属性提供了关于维度成员的描述信息，并且当你选择维度成员用于分析的时候也是可用的。大多数属性类型是可选的。

（8）元数据（Metadata）

元数据就是关于数据的数据。通过增加标签，数字就从数据变成了信息。如下图所示，我们知道70代表销售量。这个标签就是元数据。元数据也称为度量值，包含在有属性和层次结构组成、与数值数据相关的维度中。

（9）成员

一个成员是维度（包括度量<Measures>）上的项目值。如图-1中时间维度上”半年“级别的成员就包含：上半年、下半年...季度成员包含：第一季度、第二季度等。

（10）计算成员

计算成员是一种运行通过特殊表示式动态计算的成员。也就形成了度量（Measures）的结果。计算成员不影响现有的Cube数据，它基于cube数据，通过各种数学表达式和各种函数定义，可以创建复杂的表达式。任何动态分析功能，都可以通过计算成员实现，比如实现占比，同期比等等。

3.7 数据湖(Data Lake)定义以及与数据仓库的区别？

（1）数据湖定义？

数据湖是一个以原始格式(通常是对象块或文件)存储数据的系统或存储库。数据湖通常是所有企业数据的单一存储。用于报告、可视化、高级分析和机器学习等任务。数据湖可以包括来自关系数据库的结构化数据(行和列)、半结构化数据(CSV、日志、XML、JSON)、非结构化数据(电子邮件、文档、pdf)和二进制数据(图像、音频、视频)。定义中的重点内容我用红色字体标注出来，简单说明一下这几点：

原始格式：数据不做预处理，保存数据的原始状态；
单一存储：存储库中会汇总多种数据源，是一个单一库；
用于机器学习：除了 BI 、报表分析，数据湖更适用于机器学习；

（2）数据湖和数据仓库的对比

大数据刚兴起的时候，数据主要用途是BI 、报表、可视化。因此数据需要是结构化的，并且需要 ETL 对数据进行预处理。这个阶段数据仓库更适合完成这样的需求，所以企业大部分需要分析的数据都集中到数据仓库中。而机器学习的兴起对数据的需求更加灵活，如果从数据仓库中提数会有一些问题。比如：数据都是结构化的；数据是经过处理的可能并不是算法想要的结果；算法同学与数仓开发同学沟通成本较大等。做算法的同学需要经常理解我们的数仓模型，甚至要深入到做了什么业务处理，并且我们的处理可能并不是他们的想要的。基于上面遇到的各种问题，数据湖的概念应运而生。下面的表格对比一下数据湖和数据仓库的区别，主要来自 AWS 。

从以上表格的区别上我们可以看到数据湖的应用场景主要在于机器学习，并且在用的时候再建 Schema 更加灵活。虽然数据湖能够解决企业中机器学习应用方面的数据诉求，可以与数据仓库团队解耦。但并不意味着数据湖可以取代数据仓库，数据仓库在高效的报表和可视化分析中仍有优势。

（3）云厂商的解决方案

近几年云计算的概念也是非常火，各大云厂商自然不会错失数据湖的解决方案。下面简单介绍阿里云、AWS 和 Azure 分别的数据产品。

阿里云：Data Lake Analytics 通过标准JDBC直接对阿里云OSS，TableStore，RDS，MongoDB等不同数据源中存储的数据进行查询和分析。DLA 无缝集成各类商业分析工具，提供便捷的数据可视化。阿里云OSS 可以存储各种结构化、半结构化、非结构化的数据，可以当做一个数据湖的存储库。DLA 使用前需要创建 Schema 、定义表，再进行后续分析。

AWS：Lake Formation 可以识别 S3 或关系数据库和 NoSQL 数据库中存储的现有数据，并将数据移动到 S3 数据湖中。使用 EMR for Apache Spark（测试版）、Redshift 或 Athena 进行分析。支持的数据源跟阿里云差不多。

Azure：Azure Data Lake Storage 基于 Azure Blob 存储构建的高度可缩放的安全 Data Lake 功能,通过 Azure Databricks 对数据湖中的数据进行处理、分析。但文档中并没有看到支持其他数据源的说明。

（4）开源解决方案

Databricks 团队（开源 Spark 框架）年初开源了 Delta lake 框架， Delta lake 是存储层，为数据湖带来了可靠性。Delta Lake 提供 ACID 事务【原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)】、可伸缩的元数据处理，并统一流和批数据处理。Delta Lake运行在现有数据湖之上，与Apache Spark api完全兼容。架构图如下：

3.8 JDBC的定义是什么？

Java数据库连接，（Java Database Connectivity，简称JDBC）是Java语言中用来规范客户端程序如何来访问数据库的应用程序接口，提供了诸如查询和更新数据库中数据的方法。JDBC也是Sun Microsystems的商标。我们通常说的JDBC是面向关系型数据库的。

JDBC驱动程序共分四种类型：

类型1 JDBC-ODBC桥 这种类型的驱动把所有JDBC的调用传递给ODBC，再让后者调用数据库本地驱动代码（也就是数据库厂商提供的数据库操作二进制代码库，例如Oracle中的oci.dll）。 类型2 本地API驱动 这种类型的驱动通过客户端加载数据库厂商提供的本地代码库（C/C++等）来访问数据库，而在驱动程序中则包含了Java代码。 类型3 网络协议驱动 这种类型的驱动给客户端提供了一个网络API，客户端上的JDBC驱动程序使用套接字（Socket）来调用服务器上的中间件程序，后者在将其请求转化为所需的具体API调用。 类型4 本地协议驱动 这种类型的驱动使用Socket，直接在客户端和数据库间通信。