大数据平台与数据中台

数据平台

大数据平台是一个技术平台。这个技术平台提供了对于大数据的分布式采集，存储，流处理和计算，实时分析等能力。在没有大数据平台前也有数据集成和管理的平台，这种平台可以实现对结构化数据本身的采集，集成和管理。

• 数据平台是在数以万计的硬件之上建立统一的基础数据存储和计算的服务,当然我们所建设的数据平台需要周边一些辅助的服务来支撑核心服务的运行,以及一些数据平台管理类工具,辅助日常SRE工作
• 首先是个平台，平台的用户应该有方便的使用数据或计算能力的途经，因而一个完善的大数据平台需要提供且不限于数据仓库（模型管理，数据管理），计算服务（ETL，OLAP），任务的编排调度，数据可视化等。

数据中台

• 数据中台是抽象了数据能力的共性形成的数据服务能力,是一系列数据服务,用系统化思路解决数据前台对数据获取的难度,更好的赋能业务
• 数据中台除了需要提供通用能力外，还需要提供一些业务服务能力，就是一些看上去是行业的或需求定制的数据处理分析结果的查询能力。

数据平台与数据中台的区别与联系

如果整个数据中台建设有大数据平台，那么大数据平台也仅仅是一个底层技术平台和技术实现手段。

区别

• 核心区别是-是否跟业务强相关
• 数据平台和业务的联系并不密切,提供基础的存储,计算,调度,数仓工具等基础的技术服务,至于业务数据怎么存储,数据表如何组织,数据模型如何建,数据如何服务业务,数据平台并不关心
• 数据中台的目的是通过系统化思路的去组织数据,让数据更好的服务业务,包括数据前台的报表,自助分析,OLAP,维度指标管理,业务中台等

联系

• 数据平台是数据中台的基石,数据中台要基于需求业务体系,在数据平台之上去建设数据体系
• 数据中台的建设,也会给数据平台带来更多的技术需求和压力,促进数据平台技术栈更加多样性,性能向更优化方向发展

大数据平台更强调技术组件及数据，数据中台则更强调数据的使用

整体架构

1、数据平台

存储能力

• 分布式文件系统,不论是基于磁盘还是基于内存,只是不同存储成本的文件系统,带来不同存储性能和特性
• MQ类的主要支持数据采集和实时计算
• 数据库主要支持查询类和实时计算,类别很多,关系型,nosql,各有千秋

计算能力

• 离线计算,提供批处理计算能力,主要负责天,周,月等数据生产,主流的像早期的mr,后期的spark等
• 实时计算,提供实时数据处理能力,负责实时数据生产,当然实时离线是我们人为划定的时间界限,对于引擎而言,像spark,flink都提供实时和离线的解决方案
• 算法平台,主要提供机器学习,人工智能,数据挖掘的计算能力,算法框架的选择也是很多,当然在大数据生态还是需要运行在yarn这样资源管理平台,才可以发挥大数据的价值
• 查询类服务,提供一些和用户交互的查询能力,像一些mpp框架等,多数提供sql查询能力

管理平台

• 管理平台,是在原生的大数据生态的基础之上,为了更好的管理集群服务,管理集群的资源,提供灵活SRE能力和资源核算审计能力的一系列工具和合称

2、数据中台

数据仓库

• 数据中台包括数据仓库的全部内容,数据仓库为数据中台提供了数据对外提供服务的基础资源,数据中台将数据仓库建设的投入价值进行最大化,以加快数据赋能业务的速度
• 大家都知道数据仓库需要分层建设,需要面向业务主题,但是规范和落地往往是有差异,中台可以帮助数仓建模流程从文档化向标准化迈进,降低由于团队认知差异带来的数仓规范不统一的风险

数据集市

• 集市层主要面向具体应用做开发,是数仓向数据前台数据的重要连接层,数仓建设的好坏,对数据集市的建设影响很大
• 数仓和数据集市同样都面临数据重复建设,数据不一致的问题,需要中台协助数仓和数据集市规范化落地

数据开发

• 数据中台需要改变原来的开发模式,提供全流程的数据开发解决方案,规范开发流程的每一个步骤,达到大一统的效果
• 维度指标元数据管理
• 指标树主要维护了指标和指标之间关系,比如某个衍生指标是有哪些基础指标通过什么计算公式计算得到,这个关系很重要,这是做智能异动分析的基础,可以实现很多自动化的异常数据监控和分析能力
• 指标地图主要维护了指标和数据的物理存储的关联关系,通过地图我们可以轻松到找到哪些维度指标存储到了哪些物理存储里面
• 建模工具来帮助数仓和数据集市规范的落地,如果没有工具协助,我们制定再好的仓库分层方案,仓库建模方案都是徒劳的,经过长期的累计和人员流动,非常容易导致规范落地不标准,导致数据不一致等一系列问题
• 开发工具主要协助RD对ETL代码管理,如果还是通过原始命令+sql文件方式来管理ETL,那开发效率会很低,而且对依赖关系和调度的管理也是问题,开发工具会贯穿几乎开发的全流程,来加速开发

数据运维

• DQC,数据质量监控,提供日常数据质量监控能力,是保证数据一致性的基础,DQC一般提供的基础的质量监控,比如基础的同环比阈值监控,条数监控,空数据监控,均值监控等
• SLA,数据按时生产的参考标准,etl任务健康度评估的重要指标,保证数据按时交付,确定etl任务的优化目标
• 异动分析,为业务提供自动化的数据波动分析能力,帮助业务人员定位异常根源,快速调整业务决策
• 资产管理,数据中台的核心资源就是数据,数据以资产形式管理起来,可以是我们精确的知道我们拥有数据的情况,以方便对数据资源的管理
• 生命周期管理,数据都有时效性,随着时间推移,需要对数据进行生命周期管理,做合理的清理,属于数据治理的子模块

赋能对象

赋能管理者

• 赋能管理者,大盘类,大屏类产品,提供综合的,上层的业务视角的数据,来为管理者提供管理决策需要的基础数据
• 提升一点,可以配合业务经验和AI,来提供辅助决策意见,辅助管理者做决策

赋能业务运营

• 赋能业务运营,报表类,自助分析类产品,提供了比支持管理者产品更细粒度的数据,可以渗透到业务细节中,为底层运营决策提供精准的数据支持能力

赋能业务中台

• 赋能业务中台,没有数据的赋能,业务中台也还是偏向于业务公共服务的抽象,只有数据中台的赋能,才能使业务系统是一个智能化的业务系统
• 比如像"千人千面"的推荐系统

赋能数据变现

• 赋能数据变现,精准营销的广告系统,为广告带来更高的流水

赋能合作伙伴

• 赋能合作伙伴,强大的数据服务能力,可以为合作伙伴提供正确的决策方向,达到共赢的状态

（一）数据中台提供的能力

数据中台最终要落地到『数据』和『能力』两个方面上，数据是指企业生产过程中产生的数据；能力是指在数据处理、利用、精准赋能方面的体现出的优势。数据中台需要帮助企业建立起竞争优势，对内做到数据及时的开放和共享，对外能够建立起竞争壁垒和护城河。数据中台需提供以下几种能力：

数据中台需提供的能力

1.数据资产管理：数据资产管理能力是指数据仓库（实时数仓、离线数仓）建设、数据质量监控、数据指标体系等数据管理能力，将数据定义为一种资产或服务为业务赋能；

数据资产管理包括对数据资产目录、元数据、数据质量、数据血缘、数据生命周期等进行管理和展示，以一种更直观的方式展现企业的数据资产，提升企业的数据意识。

2.数据开放共享：数据不能仅仅止步于数据仓库，变成死数据，流转起来的数据才能发挥其价值，数据开放共享能力需要做到对企业内部在数据需求方面的予取予求，指哪打哪，精准赋能，一般会通过报表平台、BI工具、API服务的方式实现。

3.开发协作调度：开发协作调度能力主要解决数据处理的效率问题，通过开发平台的方式提升离线分析、实时分析、机器学习、人工智能等数据处理效率，提升数据流通速度；

4.数据采集迁移：数据采集迁移能力解决数据源头问题，通过统一的方式收集业务数据，在合规合法的范围内采集企业内部所需要的数据。同时能够完成数据在企业内部迁移流转。

5.平台运维管控：良好的运维管控能力，能够保障计算资源、存储资源正常运行，保证数据正常生产和产出。主要是指大数据生态工具的运维管控能力。

6.数据可视化及自助分析：数据可视化主要解决数据展现能力，利用图表的方式诠释数据意义，更好的理解和利用数据；自助分析能力让业务人员，产品等非技术人员开展数据分析工作，做到人人都是数据分析师。

数据治理：传统的数据治理通常包含数据标准管理、元数据管理、数据质量管理、数据安全管理、数据生命周期管理等内容。

查询服务：输入特定的查询条件，返回该条件下的数据，以API形式供上层应用调用。

1）支持配置查询标识，底层数据组织一般会对该标识建立索引，以加快查询速度

2）支持配置过滤项

3）支持查询结果配置，包括数据排序规则和分页规则。

分析服务：借助分析组件高效的大数据分析能力，对数据进行关联分析，分析结果通过API形式供上层应用调用。

1）支持多源数据接入：企业的数据经过清洗加工转换成数据资产后，最终通过服务作用于业务系统，基于企业异构存储的现状，要求分析服务能够支持与Hive、ES、Greenplum、MySQL、Oracle、本地文件等多种数据源进行连接。

2）高性能即席查询：随着企业数据爆发式增长，传统的数据分析工具遇到分析能力的瓶颈，也就是对大数据量的分析越来越乏力。因此，这就要求分析服务内置高速计算引擎，以对数据进行高性能的即席计算，实现亿级数据毫秒级（至多秒级）分析和计算，减少用户等待时间。

3）多维数据分析

分析服务除了支持常规的数据分析、上卷下钻、切片切块之外，还应该支持多维的数据分析以及深层次的数据挖掘，发现数据背后的关联关系。

4）灵活对接业务系统

推荐服务：按约定的格式提供历史日志行为数据和实时访问数据，推荐模型就会生成相应的推荐API，从而为上层应用提供推荐服务。

推荐服务即所谓的千人千面，对不同的人对物的行为进行数据挖掘，构建每个人与物之间的关系程度，来推荐人、物以满足用户的兴趣爱好，以提升用户对业务的粘性。每个人打开手机淘宝看到的内容都不一样，这就是一种基于人的兴趣爱好的推荐服务能力。

1）支持不同行业的推荐：不同行业背后的推荐逻辑是有区别的

2）支持不同场景的推荐：以内容资讯为例，在用户冷启动场景下，应该推荐哪些资讯？在用户已有浏览行为的场景下，又该为其推荐哪些资讯？

3）支持推荐效果优化：从导入的原始数据开始，经过推荐组件生成推荐数据，再根据用户的浏览数据不断修正推荐模型，从而使推荐效果不断优化

二、数据中台架构与技术选型

1、数据中台架构核心组成

我认为的数据中台核心架构包括四大组成部分，具体是：

• 底座是数据基础平台，包括数据采集平台&计算平台&存储平台，这些可以自建也可以使用云计算服务；

• 中间部分两大块是中台的公共数据区，公共数据区包括数据仓库(数据湖) ，主要负责公共数据模型研发，还包括统一指标（标签）平台，负责把模型组织成可以对外服务的数据，例如数据指标、数据标签；

• 上层是数据应用服务层，主要将公共数据区的数据对外包装并提供服务，包括数据接口平台、多维查询平台，数据可视化平台、数据分析平台等。

另外，数据研发平台和数据管理平台贯穿始终，其中：

1）数据开发平台包括数据开发的各类工具组合，例如：数据管道工具（比如数据接入、数据导出）、模型设计工具、脚本开发工具、数据调度工具等。

2）数据管理平台包括统一元数据管理、数据质量管理、数据生命周期管理。针对数据全链路的数据管理，保证数据中台可以监控数据链路中的数据流向、数据使用效果、数据生命周期，以衡量数据的价值与成本。

以上是数据中台的核心部分，数据中台的组成也可以更加丰富，比如包括：数据资产平台、算法平台等等。

2、数据中台技术选型参考

在搭建数据中台方面，基于开源技术的选型，尤其是Hadoop生态圈有非常多的选择，从数据整体流向来看各大层级的选型。

• 数据采集工具：Canal、DataX、Sqoop

• 数据抽取层：sqoop和flume是两大主流工具，其中sqoop作为结构化数据（关系型数据库）离线抽取，flume作为非结构化日志接入；

• 数据存储层：Hadoop文件系统Hdfs大家都比较了解，而kafka作为流式数据总线应用也非常广泛；

• 计算与调度层，包括：

• 离线计算：离线计算主要是hive，spark，也有部分选用tez

• 实时计算：前些年storm，sparkStreaming比较流行，最近几年大家纷纷往Flink转型

• 数据调度：除了像Airflow Azkaban Oozie等，易观开源的Dolphin-scheduler也非常活跃 

• 数据引擎层：也就是我们常说的OLAP层。从概念上讲分为ROLAP、MOLAP以及两者混搭。MOLAP提前做一些预计算，以生成Cube的方式，达到空间换取查询效率；而ROLAP是即查即用，效率完全取决于查询引擎的性能，ES/HBASE/MYSQL

• 数据可视化层：比较主流的有Metabase、Superset、Redash，也可以选择阿里、百度的一些开源控件。

所以也有很多商业化的套件、以及基于云的数据组件可以选择，包括数据采集、处理、分析、数据可视化全过程，国内外有很多厂商都提供了丰富的选择。尤其在大数据可视化这块，国内有许多非常专业的商业套件。

三、数据研发实践

1、数据处理架构

下面是一个简单的数据处理架构演进过程：

最早数据仓库的计算只支持批处理，通常是按天定时处理数据，在后期逐步进化到准实时，本质上还是批处理，只是处理频度上得有提升，到小时级，或者15分钟这种。

随着技术不断进步，后期演化出一条新的流处理链路，这个链路和之前的批处理分别处理，然后在服务层面利用大数据的计算能力进行合并，向外提供离线+实时数据服务，这也是著名的lambda架构。

最近几年随着Flink等技术的发展，有一个趋势是流批一体化，在接入层统一采用流式接入，计算层采用统一套框架支持实时计算+离线计算，批处理仅仅作为流处理的一个特殊场景进行支持。整体上可以做到流处理、批处理的自由切换。

流计算和批处理在需求场景上有一些本质区别，前者主要用于支持线上业务场景（比如互联网的推荐、搜索、风控等），而批处理更多是支持离线统计分析。

2、数仓分层与主题分类

1）数仓分层

与传统ETL不同的，我们采用的是ELT的数据架构，较为适合在互联网，总体分为业务数据层、公共数据层、应用数据层三大层次。

① 业务数据层（ODS层）

表名：ODS_系统简称_业务系统表名

原始数据经过缓冲层（STG）的加载，会进入数仓的业务数据层，这一层采用范式建模，基本保持与数据源完全一致的结构，对于变化的数据，使用数据拉链加工与存储。

这一层选用范式建模，是指保持源系统（例如关系数据库）的范式结构，好处主要是：

• 一次性接入数据源结构，针对需求的变动不用频繁去与数据源对接；

• 便于业务研发更好地理解数据，同时是也是公司的原始数据资产。

针对变化数据采用数据拉链的好处：

• 保留历史数据的同时，尽可能少占用存储空间，长期来看，拉链存储比起每天全量保留历史节约大概90%空间；

• 快速、高效地获取历史任意一天业务系统的快照数据。

使用DataX同步数据步骤：

1）确定业务系统源表与贴源数据层目标表

2）配置数据字段映射关系，目标表可能会增加采集日期、分区、原系统标识等必要信息，业务相关内容不做转换

3）如果是增量同步或着有条件的同步部分数据，则配置数据同步条件

4）清理目标表对应数据

5）启动同步任务，往贴源数据层目标表导入数据

6）验证任务是否可以正确运行，并且采集到准确数据

7）发布采集任务，加入生产调度，并配置相关限速、容错、质量监控、告警机制

② 公共数据层，统一数仓层DW（包括公共明细层DWD，公共汇总层DWS）

公共数据层是数据仓库的核心层，是整个数仓中使用率最高的，这一层主要采用的维度建模思路进行设计，类型包括事务事实、周期快照、累积快照。同时为了方便下游对数据的使用，我们会设计一系列的宽表模型，将不同业务过程中的事实进行统一整合，包括纵向整合&横向整合；对于商品、用户主数据类可能分散在不同的源系统中采用纵向整合；横向整合主要包括交易、内容等行为数据不同业务过程的整合，比如：用户（用户信息、注册信息）购买（下单、支付、结算、覆约、完成）商品（商品信息，商家信息，等），我们会把订单流转业务过程整合放到一张明细表里，同时会研发一些基于用户、或者商品视角的轻度汇总宽表。

宽表非常便于理解和易用，下游应用调用也方便。我们之前也做过一些统计，在调用分布来看，宽表的使用占到70%以上。

虽然宽表的使用在数仓建模中非常普遍，但是也有一些缺陷：

• 数据冗余较多，在存储、计算、调用较为占资源，建议尽量还是按场景去使用；

• 宽表整合的信息较多，数据权限不好控制。建议可以根据需求，在有限范围内开放整体宽表权限，或者通过视图或者子表的方式建立不同权限的数据范围，适应不同组织的需求；

• 宽表通常依赖比较多，会影响数据的产出的时效。

标签数据层TDM

面向对象建模，对跨业务板块、跨数据域的特定对象数据进行整合，通过IDMapping把各个业务板块、各个业务过程中的同一对象的数据打通，形成对象的全域标签体系，方便深度分析、挖掘、应用。

③ 应用数据层（DWA层）

顾名思义，就是偏向应用的数据加工，也可以叫集市层，这一层的设计可以相对灵活，贴近应用即可，总体设计思想仍然可以按维度建模思想为主。

2）主题分类

数仓架构的数据分类两个视角，包括主题视角与业务视角。

① 数据主题视角

最重要的一个视角，也就是咱们经常提到的数仓主题，主题是将企业的业务进行宏观数据抽象，是数据仓库里数据的主要组织形式，划分方法如下：

• 参照波特价值链，分析企业本身经营的业务（基本活动、支持型活动），分别对应哪些数据；

• 参照业界通用模型，例如像IBM、TD等针对大型行业（如电信、金融、零售）有一些数据主题的通用划分方法；

• 对企业的内部数据（线上数据模块、数据字典）进行摸底，确认对应到哪些主题。

划分结果会按照三个层级：主题域--》主题--》子主题。

• 第一级是主题域，针对相对稳定的主题进行合并，归拢到主题域，利于数据的理解与建立全局的数据资产目录；

• 第二级是主题；

• 第三级是子主题，主要针对有些主题下分类较多，比如供应链主题下会包含采购、仓储、配送等子主题。

数据主题划分建议完全互斥，不建议重复。

② 数据业务视角

数据业务域是根据企业经营的具体业务，结合企业的组织架构进行划分，层次和分类可以相对灵活，子分类可以允许重复，因为两条不同的业务域可能经营相同的业务，例如电商、内容下都有会员这个业务。

上图是一个比较典型的内容+电商的数据主题与业务分类。

以上一横一纵两个视角，将数据进行更好的归类，在数据模型设计中会打上相应分类标签，从而让数据研发&数据使用人员统一认知。以上两种分类方式主要应用于核心的公共数据层。

业务数据层、应用数据层并不需要遵循以上分类规则，比如业务数据层（ODS层）是按照数据源进行分类，应用数据层（DWA）是根据具体的应用进行分类。

3、数据研发流程

除了合理的架构之外，数据研发的流程也很重要，总体流程如下：

包括需求分析/数据调研、数据模型设计、数据开发&测试、上线发布等流程。

在之前数据中台的核心架构提到不闭门造车，数据研发需要与业务部门充分衔接，比如在数据调研中要与业务研发同学进行线上数据&结构访谈；在数据开发中，与分析&业务同学共同确认标准口径；在数据研发完成后对数据使用方进行数据发布与培训。

以上流程中，除了需求调研，其他部分我们都进行了线上化，包括数据的模型设计，早期我们会手写mapping文档，后期我们逐步把mapping文档进行了线上化，整体的数据模型设计通过模型设计工具完成，包括从概念模型、逻辑模型到物理模型的设计。模型设计完成后，可以一键生成数据知识文档。

4、数据生命周期管理

数据研发完成，还需要关注数据生命周期，一方面数据量的飞速增长不仅仅需要占用大量存储，比如像自建机房，会涉及扩充机柜、机房，往往会面临一些瓶颈；另外一方面，大量的数据会降低数据的计算效率，所以从数据的生成开始，我们就需要考虑生命周期，并且结合数据的使用情况制定数据归档、数据销毁等管理策略。

针对数据已经占用了大量存储资源，可以采取一系列措施进行成本控制，例如：

• 降存量：通过数据压缩技术、降副本等方式，以及在数据模型更合理的设计，将存量数据存储降低；

• 控增量：根据数据重要性，可恢复性等考量角度，确认数据的保留周期，并根据周期自动归档或删除；

• 摊成本：可以通过一些算法，比如数据调用分布、需求来源等，把成本分摊到相应业务部门，让相关业务部门关注到成本。

数据安全也是数据生命周期管理重的一个重要课题，比如针对用户敏感信息，需要在接入时考虑如何加密。一种做法是通过一个独立的物理集群对敏感数据进行隔离与强管控；数据使用中，也需要将数据划分不同的安全或敏感等级（例如有些财务数据的非常敏感，需要谨慎对外开放），根据不同的等级设定不同的访问审批机制。另外，在数据归档、销毁也需要制定好配套的安全管理措施，避免安全风险。

5、数据质量管理

数据质量管理主要包括3个角度：准确性、及时性、一致性。

管理的环节包括：事前、事中、事后、以及事故管理。

针对数据运维的告警发送，传统的方式主要是短信、邮件、电话；随着移动办公工具功能逐步的强大，可以将运维告警以数据接口的方式与这些工具进行对接，将告警发送到企业内部的即时通讯工具。

6、数据应用架构

数据研发最终还是需要赋能到业务&应用，一个合理的数据应用架构是非常关键的，这张图是一个应用架构的简图参考：

从数据的流向上分：

• 数据仓库（或者数据湖）：负责原始数据的计算，主要将数据落地到HDFS；

• 数据引擎层：数据加工完成之后，会将数据推送到不同的引擎中，这一层之前提到选择非常多，可以根据自己的场景选择一个混搭组合，比如我们目前选择的有Presto，Kylin，Druid，Mysql；

• 数据服务层：通过统一化的SQL调用服务，屏蔽底层不同的数据引擎，为上层统一查询提供标准接口；

• 指标平台：指标平台是一个非常关键的产品，定位于衔接数据研发与数据应用，包括指标的标准定义、逻辑、计算方式、分类等各项内容。指标分类上我们分为标准指标(指标口径经过审核过)、以及非标准指标；

• 多维查询：这是我们的一个即席查询工具，查询的数据主要来源指标平台，可以选定不同的指标维度组合进行结果呈现，用户可以一次性查询得到结果，也可以将查询结果配置成可视化的报表进行固化。

中间是统一元数据管理：对整个架构中可以对外提供服务的元数据进行统一管理（包括数仓的元数据、查询引擎的元数据、指标元数据等），以及监控这些元数据的调用情况。

最右侧是权限管理：权限管理关乎到数据安全，在设计上需要考虑周全，比如针对表级、指标级、维度级别都可以进行控制；同时产品层面也需要灵活配置权限审批级别与人员。

在面向用户使用层面，我们主要开放的是多维查询&可视化，用户通过多维去查询各类指标&维度数据，得到数据结果列表，再选择可视化配置面板，完成各类图表、表格的自主配置，并发布到个人看板或者业务大盘目录里。也可以将配置的数据看板进行灵活组合，定制成一个小型的数据产品。

7、数据ROI评估

在数据研发中，也要考量数据的ROI，下面是一个简单的ROI模型：

根据活跃度（调用次数等）、覆盖度（通过血缘关系找出依赖数量），以及贡献度（依赖数据的重要等级）来确认数据的价值。同时会评估数据的成本指数（例如计算成本、存储成本等）。

通过以上两者相除，综合得到数据的ROI，针对ROI可以将数据分为不同等级，并相应进行数据治理。比如针对价值低，成本高的数据，可以考虑下线等。

数据研发趋势&关注点

• 提效：目前借助工具的研发可以把绝大部分数据研发工作线上化，将来借助AI等能力，实现数据处理中包括开发、运维的自动化，提升处理效率；

• 灵活：流批一体化，包括流处理与批处理自由切换，之前已经提到过，个人认为也是一个发展的趋势；

• 降本：数据研发链路的成本控制，在数据建设的早期通常不太引起关注，随着数据量不断的积累，往往存储、计算成本成为瓶颈。针对数据建设成本需提前考虑；

• 算力：我们看到Google，IBM和阿里都在研究量子计算，将来的数据中间层（比如数仓的公共模型）是否可以考虑虚拟化（比如只保留规则&数据结构），具体数据内容在应用发起时，即调即用，更多时候可以不需要占用存储资源。算力的不断提升，有可能会颠覆一些传统数据建设的思路。

> > > >Q&A

Q1：请问贵公司如何压缩数据？又如何删除副本呢？

A：我们主要使用parquet +snappy压缩；另外，如果发现压缩率较低，可以通过排序来调整数据分布，降副本可以了解下EC纠删码技术。

Q2：对于批处理效率低的问题该怎么处理？

A：具体可以看什么原因导致，如果是整体效率低，可以看资源利用是否集中，如果集中，可以考虑任务分等级、错峰进行队列隔离等；如果是个别任务问题，那就要考虑逻辑和加工链路是否有问题，比如说可以全量改增量处理，逻辑参数优化；如果倾斜导致可以针对具体倾斜原因采取不同的优化方式。

Q3：请问基于Hadoop生态组件构建DW存在哪些不足？与MPP比较？

A：如果之前一直是按照传统商业套件进行建设，可能在数据不能直接update这个点上不习惯。另外大部分技术都是经历反复演进才达到稳定的，所以最好能选用成熟组件。与MPP比较，MPP横向扩充到一定规模可能会有瓶颈，而Hadoop集群可以灵活扩充节点来增加算力，比如现在国内单集群几千台、上万台的场景都有。

Q10：请问mapping是建模管理的？是否用用ERWIN或者PD工具吧？

A：以前我们是通过excel模版建模并生成mapping文档，现在只是把这个模版搬到线上，这个小工具可以连通到建表，并且发布到数据知识系统。我们没有使用ERWIN或者PD，模型之间的关系会辅助用一些思维导图软件。

Q11：为什么要基于Hive建数仓？它不支持索引、更新、事务。

A：Hive 搭建数仓当前来看处理效率、稳定性都是经过验证过的。更新可以通过insert overwrite来解决。

Q12：数据湖是什么技术？跟数仓的关系是啥？

A：跟数仓是两个独立的概念，通过直接接入源系统的原始数据（包括结构化、非结构化），利用大数据强大的计算能力，直接将数据服务于应用。主要为缩短传统数仓的中间建模与处理（ETL）过程，目前有看到一些云+数据湖的方案。

https://blog.csdn.net/tzs_1041218129/article/details/106132196

https://mp.weixin.qq.com/s/5z_87K8MXJb7yY7niWHDZw

https://www.toutiao.com/i6831701675690951172/