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

2.1 数据仓库架构的演变

(1) 数据仓库架构演变

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

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

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

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

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

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

2.2 数据仓库的标准架构

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

• 作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；
  Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。
  Logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。你可以用它来统一对应用程序日志进行收集管理，提供 Web 接口用于查询和统计。Logstash 现在是ElasticSearch家族成员之一。
  Filebeat是本地文件的日志数据采集器，可监控日志目录或特定日志文件（tail file），并将它们转发给Elasticsearch或Logstatsh进行索引、kafka等。带有内部模块（auditd，Apache，Nginx，System和MySQL），可通过一个指定命令来简化通用日志格式的收集，解析和可视化。
  HDFS是一个文件系统，用于存储文件，通过目录树来定位文件；其次，它是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。HDFS的设计适合一次写入，多次读出的场景，且不支持文件的修改。适合用来做数据分析，并不适合用来做网盘应用。
  canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了MySQL（也支持mariaDB）。
  Apache Storm是自由开源的分布式实时计算系统，擅长处理海量数据，适用于数据实时处理而非批处理。
  批处理使用的大多是鼎鼎大名的hadoop或者hive，作为一个批处理系统，hadoop以其吞吐量大、自动容错等优点，在海量数据处理上得到了广泛的使用。但是，hadoop不擅长实时计算，因为它天然就是为批处理而生的，这也是业界一致的共识。
  Storm只能解决流处理问题，而且由于资源有限，很难创建Storm应用程序。个人认为，Storm被替代是趋势。

• 业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案，有资源的话，可以基于DataX之上做二次开发，就能非常好的解决。当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。
  DataX 是阿里巴巴的一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。

• 合作伙伴提供的接口 。有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；

• 如Excel等需要手工录入的数据

实时采集现在也成了大数据平台的标配，主流就是FLUME+KAFKA。
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala/JAVA语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源

（2） 数据存储与分析

• HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

• 离线数据分析与计算，也就是对实时性要求不高的部分，Hive是不错的选择。

• 使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。

• Spark Streaming 是 Spark 核心 API 的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。
  Spark Streaming 支持从多种数据源获取数据，包括 Kafka、Flume、Twitter、ZeroMQ、Kinesis 以及 TCP Sockets。从数据源获取数据之后，可以使用诸如 map、reduce、join 和 window 等高级函数进行复杂算法的处理，最后还可以将处理结果存储到文件系统、数据库和现场仪表盘中。

• MLlib是Spark提供的可扩展的机器学习库。MLlib已经集成了大量机器学习的算法

hive是基于Hadoop的一个数据仓库工具，用来进行数据提取、转化、加载（ETL），这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计，使MapReduce变得更加简单，而不必开发专门的MapReduce应用程序。hive是十分适合数据仓库的统计分析和Windows注册表文件。
Impala是基于Hive的大数据实时分析查询引擎，直接使用Hive的元数据库Metadata,意味着impala元数据都存储在Hive的metastore中。并且impala兼容Hive的sql解析，实现了Hive的SQL语义的子集，功能还在不断的完善中。
Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用hive进行数据转换处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

Spark使用Scala语言进行实现，也支持JAVA语言，它是一种面向对象、函数式编程语言，能够像操作本地集合对象一样轻松地操作分布式数据集，具有以下特点。
-1.运行速度快：Spark拥有DAG执行引擎，支持在内存中对数据进行迭代计算。官方提供的数据表明，如果数据由磁盘读取，速度是Hadoop MapReduce的10倍以上，如果数据从内存中读取，速度可以高达100多倍。
-2.易用性好：Spark不仅支持Scala编写应用程序，而且支持Java和Python等语言进行编写，特别是Scala是一种高效、可拓展的语言，能够用简洁的代码处理较为复杂的处理工作。
-4.随处运行：Spark具有很强的适应性，能够读取HDFS、Cassandra、HBase、S3和Techyon为持久层读写原生数据，能够以Mesos、YARN和自身携带的Standalone作为资源管理器调度job，来完成Spark应用程序的计算。

目前大数据处理场景有以下几个类型：
-1. 复杂的批量处理（Batch Data Processing），偏重点在于处理海量数据的能力，至于处理速度可忍受，通常的时间可能是在数十分钟到数小时；
-2. 基于历史数据的交互式查询（Interactive Query），通常的时间在数十秒到数十分钟之间；

SparkStreaming是一套框架。SparkStreaming是Spark核心API的一个扩展，可以实现高吞吐量的，具备容错机制的实时流数据处理。
MapReduce是一种编程模式。用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（归约）"，是它们的主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。它极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。 当前的软件实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（归约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。
Hive 是将Hive SQL转换成MapReduce然后提交到集群中去执行，大大简化了编写MapReduce程序的复杂性，由于MapReduce这种计算模型执行效率比较慢，所以Spark SQL应运而生，它是将Spark SQL转换成RDD，然后提交到集群中去运行，执行效率非常快！
Apache Flink是一个开源的分布式、高性能、高可用、准确的流处理框架，主要由Java代码实现，支持实时流(stream)处理和批(batch)处理，批数据只是流数据的一个极限的特例。
2）之前一些业务用flink开发，好多东西不支持，后来改成sparkStreaming开发，很稳定而且跑得很好；
3）阿里鼓吹flink多好多好，但是只有买了阿里云服务才能得到相关特性，开源的都是阉割版，比较难用；
ZooKeeper是一个高可用的分布式数据管理与系统协调框架。基于对Paxos算法的实现，使该框架保证了分布式环境中数据的强一致性。
-数据发布与订阅（配置中心）
在Hadoop1.x时代，Hadoop中的MapReduce同时处理业务逻辑运算和资源的调度，耦合性较大。

开源的列存储数据库管理系统，支持线性扩展，简单方便，高可靠性，

容错跑分快：比Vertica快5倍，比Hive快279倍，比MySQL快800倍,其可处理的数据级别已达到10亿级别

功能多：支持数据统计分析各种场景，支持类SQL查询，异地复制部署

低延迟：对于数据量（几千行，列不是很多）不是很大的短查询，如果数据已经被载入缓存，且使用主码，延迟在50MS左右。
并发量：虽然 ClickHouse 是一种在线分析型数据库，也可支持一定的并发。当单个查询比较短时，官方建议 100 Queries / second。
写入速度：在使用 MergeTree 引擎的情况下，写入速度大概是 50 - 200 M / s，如果按照 1 K 一条记录来算，大约每秒可写入 50000 ~ 200000 条记录每秒。如果每条记录比较小的话写入速度会更快

其主要的应用场景: 用于结构良好清晰且不可变的事件或日志流分析

Web和App分析，广告网络和RTB，电信，电子商务和金融，信息安全，监测和遥感，时间序列，商业智能，网络游戏，物联网

需要注意的是: 由于clickHouse不支持事务操作, 顾不能作为传统数据库来使用(OLTP),以及高请求率的键值访问，Blob或文档存储，超标准化数据

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。 这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库。
Apache Kylin一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据,它能在亚秒内查询巨大的Hive表。
Druid是一个专为大型数据集上的高性能切片和OLAP分析而设计的数据存储。Druid最常用作为GUI分析应用程序提供动力的数据存储，或者用作需要快速聚合的高度并发API的后端。Druid的常见应用领域包括：

HBase是建立在Hadoop文件系统之上的分布式面向列的数据库。
它是Hadoop的生态系统，提供对数据的随机实时读/写访问，是Hadoop文件系统的一部分。人们可以直接或通过HBase的存储HDFS数据。使用HBase在HDFS读取消费/随机访问数据。 HBase在Hadoop的文件系统之上，并提供了读写访问。

分析型数据库（AnalyticDB，原ADS）是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime OLAP）云计算服务，用户可以在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索。
关联技术-交互式分析（Hologres）
Hologres是阿里巴巴自主研发的一款全面兼容PostgreSQL 11协议并与大数据生态无缝打通的实时交互式分析产品，致力于低成本高性能高可用的大规模计算型存储和极致的查询能力，为用户提供海量数据实时数仓解决方案和实时交互式查询服务，与大数据生态无缝打通，支持对PB级数据进行高并发、低延时的分析处理，让您轻松而经济地使用现有BI工具对数据进行多维分析透视和业务探索。
在离线大数据场景上，Hologres与MaxCompute在底层无缝打通，您可以使用熟悉的工具以标准SQL查询分析MaxCompute项目中的海量数据，快速获取查询结果。
在实时数据场景上，Hologres支持高性能的实时数据实时写入，写入即可查，为搭建企业级实时数仓快速助力。
兼容PostgreSQL协议，提供JDBC/ODBC 接口，您可以将查询到的海量数据轻松而经济的对接各种BI工具，无需数据迁移就能够支持更丰富的应用场景。

• 报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层。

• 接口的数据都是直接查询数据共享层即可得到。

• 即席查询通常是现有的报表和数据共享层的数据并不能满足需求，需要从数据存储层直接查询。一般都是通过直接操作SQL得到。

关联技术-Presto即席查询
Presto是由Facebook开发的一个分布式SQL查询引擎，是专门设计为用来专门进行大数据实时查询计算而设计和开发的产品。 它是为了解决Hive的MapReduce模型太慢以及不能通过BI或Dashboards直接展现HDFS数据等问题。
presto是基于java开发的。多数据源、支持SQL、扩展性强、高性能，流水线模式
-扩展性：支持开发自己的特定数据源的connector
-高性能：presto基于内存计算，在绝大多数情况下，presto的查询性能是hive的10倍以上，完全能实现交互式，实时查询
-流水线：presto是基于PipeLine设计的，在进行大量设计处理过程中，终端不需要等待所有的数据计算完毕之后才能看到结果，计算一部分就可以看部分结果
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。
Kibana是一个为Logstash和ElasticSearch提供的日志分析的Web接口，可使用它对日志进行高效的搜索、可视化、分析等各种操作。
是一款采用 go 语言编写的开源应用，主要用于大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，目前已经支持绝大部分常用的时序数据库。
Superset 是 Airbnb （知名在线房屋短租公司）开源的数据探查与可视化平台（曾用名 Panoramix、Caravel ），该工具在可视化、易用性和交互性上非常有特色，用户可以轻松对数据进行可视化分析。Superset 也是一款企业级商业智能 Web 应用程序。
阿里云产品，QuickBI通过自助服务可以让几万的阿里小二自己(自己需要的数据拖到仪表板或者表格里)来做数据分析。
阿里云产品，DavaV通过标准模版可以让技术人员用很少的工作量就可以做出有冲击力展示大屏。

2.4 菜鸟仓配实时数据仓库

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

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

第一层 DWD公共实时明细层

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

第二层 DWS公共实时汇总层

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

2.案例中选择把数据写入到Hbase供KV查询，也可根据情况选择其他引擎，比如数据量不多，查询压力也不大的话，可以用mysql

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

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

• 大促中的主备链路保障；

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

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

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

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

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

2.3 阿里云上大数据仓库解决方案

（1）阿里云上大数据仓库解决方案

阿里云为企业提供稳定可靠离线数仓和实时数仓的解决方案，包括数据采集、数据存储、数据开发、数据服务、数据运维、数据安全、数据质量、数据地图等完整链路。

（2）离线仓库架构介绍

基于Serverless的云上数据仓库解决方案 -开箱即用：简单几步开启自己的一站式大数据开发平台。
-低TCO：Serverless服务，免运维，降低企业成本
-资源弹性：根据数据规模系统自动扩展集群存储和计算能力
-强数据安全：多层沙箱机制防护与监控，备细粒度化授权

（3）实时仓库架构介绍

• 秒级延迟，实时构建数据仓库，架构简单，传统数仓平滑升级

• -消息队列取代传统数仓分层表
  -订阅式实时计算取代调度式批处理
  

（5）阿里数据仓库分层

数据仓库的分层和各层级用途如下图所示：

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

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

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

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

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

存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

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

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

（6）对应的阿里云产品介绍

QuickBI通过自助服务可以让几万的阿里小二自己(自己需要的数据拖到仪表板或者表格里)来做数据分析。
DavaV通过标准模版可以让技术人员用很少的工作量就可以做出有冲击力展示大屏。
PAI底层支持多种计算框架：有流式算法框架Flink，基于开源版本深度优化的深度学习框架TensorFlow，支持千亿特征千亿样本的大规模并行化计算框架Parameter Server，同时也兼容Spark、PYSpark、MapReduce等业内主流开源框架。

敏感数据保护SDDP（Sensitive Data Discovery and Protection），在满足等保V2.0“安全审计”及“个人信息保护”的合规要求的基础上，为您提供敏感数据识别、数据安全审计、数据脱敏、智能异常检测等数据安全能力，形成一体化的数据安全解决方案。
SDDP可根据预先定义的敏感数据关键字段，扫描MaxCompute、关系型数据库（RDS）或对象存储（OSS）中待检测的数据，通过敏感数据规则中的命中次数来判断是否属于敏感数据。

[2] 数据分析与存储层

MaxCompute（原ODPS）是一项大数据计算服务，它能提供快速、完全托管的PB级数据仓库解决方案，使您可以经济并高效的分析处理 海量数据。
离线归档存储，采用OSS。使用RESTful API 可以在互联网任何位置存储和访问，容量和处理能力弹性扩展，多种存储类型供选择全面优化存储成本。
交互式分析（Hologres）是一款兼容PostgreSQL协议的实时交互式分析产品。Hologres与大数据生态无缝打通，支持对PB级数据进行高并发、低延时的分析处理，让您轻松而经济地使用现有BI工具对数据进行多维分析透视和业务探索

数据总线（DataHub）服务是阿里云提供的流式数据(Streaming Data)服务，它提供流式数据的发布 (Publish)和订阅 (Subscribe)的功能，让您可以轻松构建基于流式数据的分析和应用。
日志服务（LogService，简称LOG/原SLS）是针对实时数据的一站式服务，无需开发即可完成数据采集、消费、投递以及查询分析等功能，帮助提升运维、运营效率，建立DT时代海量日志处理能力。
（4）DTS 数据迁移
数据传输服务(Data Transmission Service) DTS支持关系型数据库、NoSQL、大数据(OLAP)等数据源间的数据传输。 它是一种集数据迁移、数据订阅及数据实时同步于一体的数据传输服务。数据传输致力于在公共云、混合云场景下，解决远距离、毫秒级异步数据传输难题。 它底层的数据流基础设施为阿里双11异地多活基础架构， 为数千下游应用提供实时数据流，已在线上稳定运行6年之久。 您可以使用数据传输轻松构建安全、可扩展、高可用的数据架构。

第一款产品是dataworks，其面向的市场往往是在500万元以上的客户项目，更适合做私有化部署。
DataWorks（数据工场，原大数据开发套件）是阿里云数加重要的PaaS平台产品，它提供全面托管的工作流服务，一站式开发管理的界面，帮助企业专注于数据价值的挖掘和探索。 DataWorks（数据工场）基于MaxCompute作为核心的计算、存储引擎，提供了海量数据的离线加工分析、数据挖掘的能力。 DataWorks和MaxCompute关系紧密，DataWorks为MaxCompute提供一站式的数据同步、业务流程设计、数据开发、管理和运维功能。 使用DataWorks，可对数据进行数据传输、数据转换等相关操作，从不同的数据存储引入数据，对数据进行转化处理，最后将数据提取到其他数据系统。完成整个数据的分析流程，如下图所示：

• 提供强大的调度能力，支持按照时间、依赖关系的任务触发机制，支持每日千万级别的任务按照DAG关系准确、准时运行。支持分钟、小时、天、周和月多种调度周期配置。完全托管的服务，无需关心调度服务器资源问题。租户之间提供隔离，保证不同租户之间的任务不会相互影响。

• 支持数据同步、SHELL、MaxCompute SQL、MaxCompute MR等多种任务类型，通过任务之间的相互依赖完成复杂的数据分析处理。
  1.数据转化能力依托MaxCompute强大的能力，保证了大数据的分析处理性能。
  2.数据同步能够依托DataWorks>数据集成的强力支撑，支持多达20+数据源，提供稳定高效的数据传输。

• 提供可视化的代码开发、工作流设计器页面，无需搭配任何开发工具，简单的拖拽和开发就可以完成复杂的数据分析任务。只要有浏览器有网络，便可随时随地进行开发工作。

• 运维中心提供可视化的任务监控管理工具，支持以DAG图的形式展示任务运行时的全局情况。可方便地配置短信报警，任务发生错误可及时通知相关同学，保证业务正常运行。

• -仅支持Chrome浏览器54以上版本。
  -目前无法支持SQL运行在阿里云云数据库、阿里云分析型数据库等产品，仅支持MaxCompute。

第二款产品是dataphin，其面向的往往是400万-500万元的客户项目，更多的与新零售进行绑定。

Dataworks，在阿里集团内部为大家所熟知的部分是D2，在阿里云则是数加平台的主体-数据工厂。DataWorks（数据工场）具备全栈数据研发能力（数据集成与开发、 生产运维调度、离线与实时分析、数据质量治理与资产管理、安全防护、数据共享与服务、机器学习、数据应用搭建）的大数据平台；

Dataphin，通过输出阿里数据中台实战沉淀的大数据建设体系OneData+OneID +OneService(产品+技术+方法论)，一站式提供集数据引入、规范定义、数据建模、数据研发、数据萃取的全链路智能数据构建及管理服务。

因此，DataWorks具备全栈数据研发能力和机器学习开发能力的大数据平台,这是dataworks的优势，劣势就是不具备数据中台(数据仓库)建设方法论的指导；Dataphin具备完善的“OneData+OneID +OneService(产品+技术+方法论)” 数据中台(数据仓库)建设方法论构建体系，这是dataphih的最大优势，劣势就是不具备很强的全栈数据研发能力，暂时也不具备机器学习开发能力。

定位为大数据开发平台，ETL、数据仓库建设等对开发者不做任何限制。开发者可以利用dataworks做任意想做的工作，数据中台(数据仓库)构建的方法论也不做任何限制。开发者可以利用dataworks，既可以按照维度建模理论构建数据中台(数据仓库)、也可以按照范氏建模理论构建数据中台(数据仓库)、也可以按照E/R理论构建数据中台(数据仓库)，灵活性是dataworks的优势之一，当然也是劣势之一。因为缺乏数据中台(数据仓库)建设方法论的支持，dataworks对于缺乏数据中台建设方法论经验的开发者(或者企业)不够简单易用；

定位于输出阿里巴巴数据中台方法论，开发者严格按照基于阿里多年零售经验的维度建模理论构建数据中台(数据仓库)。“设计即开发”，这是dataphin坚持的核心理念，使用dataphin的时候，开发者需要严格定义业务板块、数据域、业务过程、维度、原子指标、派生指标，然后“傻瓜式”地构建数据中台（数据仓库）。开发者可能都不用写任何代码(甚至连sql都可能不用写)，只要按照上述维度建模方法论完成所有设计，即可构建数据中台(数据仓库)。

不论是dataworks还是dataphin，均定位于离线批量开发能力。对于实时计算能力的支持，dataworks比dataphin稍微更强一些。利用dataworks集成的datahub+flink等工具能力，能够实现一些简单应用场景的实时计算能力； dataphin也在规划实时计算能力，预计再过几个月，dataphin最新版本也能实现一些简单场景的实时计算能力。

总而言之，如果开发者(或者企业)希望傻瓜式的构建数据中台(数据仓库)，而且是借鉴阿里基于零售业务积累的“OneData+OneID +OneService”方法论构建维度建模体系的数据中台，那么dataphin是不错的选择；如果开发者(或者企业)希望购买一套全栈数据研发能力的大数据平台，涵盖完善的数据集成与开发、生产运维调度、离线与实时分析、数据质量治理与资产管理、安全防护、数据共享与服务、机器学习、数据微服务应用搭建等能力。而且数据中台(数据仓库)不限制于维度建体系，那么dataworks是不错的选择。

（1）构建 OPPO 离线数仓

过往 2、3 年，我们的重点聚焦在离线数仓的构建。上图大致描述了整个构建过程：首先，数据来源基本是手机、日志文件以及 DB 数据库，我们基于 Apache NiFi 打造了高可用、高吞吐的接入系统，将数据统一落入 HDFS，形成原始层；紧接着，基于 Hive 的小时级 ETL 与天级汇总 Hive 任务，分别负责计算生成明细层与汇总层；最后，应用层是基于 OPPO 内部研发的数据产品，主要是报表分析、用户画像以及接口服务。此外，中间的明细层还支持基于 Presto 的即席查询与自助提数。
伴随着离线数仓的逐步完善，业务对实时数仓的诉求也愈发强烈。

（2）数仓实时化的诉求

对于数仓实时化的诉求，大家通常都是从业务视角来看，但其实站在平台的角度，实时化也能带来切实的好处。首先，从业务侧来看，报表、标签、接口等都会有实时的应用场景，分别参见上图左边的几个案例；其次，对平台侧来说，我们可以从三个案例来看：第一，OPPO 大量的批量任务都是从 0 点开始启动，都是通过 T+1 的方式去做数据处理，这会导致计算负载集中爆发，对集群的压力很大；第二，标签导入也属于一种 T+1 批量任务，每次全量导入都会耗费很长的时间；第三，数据质量的监控也必须是 T+1 的，导致没办法及时发现数据的一些问题。

既然业务侧和平台侧都有实时化的这个诉求，那 OPPO 是如何来构建自己的实时数仓呢？

（3）离线到实时的平滑迁移

无论是一个平台还是一个系统，都离不开上下两个层次的构成：上层是 API，是面向用户的编程抽象与接口；下层是 Runtime，是面向内核的执行引擎。我们希望从离线到实时的迁移是平滑的，是什么意思呢？从 API 这层来看，数仓的抽象是 Table、编程接口是 SQL+UDF，离线数仓时代用户已经习惯了这样的 API，迁移到实时数仓后最好也能保持一致。而从 Runtime 这层来看，计算引擎从

基于以上的思路，只需要把之前提到的离线数仓 pipeline 改造下，就得到了实时数仓 pipeline。

（4）构建 OPPO 实时数仓

从上图可以看到，整个 pipeline 与离线数仓基本相似，只是把 Hive 替换为 Flink，把 HDFS 替换为 Kafka。从总体流程来看，基本模型是不变的，还是由原始层、明细层、汇总层、应用层的级联计算来构成。

因此，这里的核心问题是如何基于 Flink 构建出这个 pipeline，下面就介绍下我们基于 Flink SQL 所做的一些工作。

2.5 电商网站的数据仓库

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

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

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

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

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

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

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

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

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

数据层的存储一般如下：

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

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

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

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

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

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

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

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

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

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

则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，使得数据向HBase中迁移变的非常方便。

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

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

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

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

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

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

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

• 这样可以保证来保证不会有大量的线程对数据库一次性进行读写，避免缓存失效时对数据库造成太大的压力，虽然能够在一定的程度上缓解了数据库的压力。但是与此同时又降低了系统的吞吐量。

• 分析用户的行为，尽量让缓存失效的时间均匀分布（也可以均摊失效时间）

• 如果Redis查不到结果的情况下，这个时间直接扔给消息中间件，等到生产者生产了该消息后，消费者拿到消息就可以进行反馈了。

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

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

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

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

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

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）。

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） 场景二：典型用例 - 基于事件的数据处理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。 OLAP系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

（3） 数据仓库的要求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（3）云厂商的解决方案

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

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

Lake运行在现有数据湖之上，与Apache Spark api完全兼容。架构图如下：

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

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

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

简单来说，MPP是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果(与Hadoop相似)。

（1）MaxCompute - 大数据计算服务（MaxCompute，原名ODPS）是一种快速、完全托管的TB/PB级数据仓库解决方案。

（1）云上大数据仓库解决方案

（2）数据仓库介绍与实时数仓案例

（3）OPPO数据中台之基石：基于Flink SQL构建实数据仓库

（4）知乎实时数仓实践及架构演进