大数据发展历程及技术选型

大数据发展历程

第一阶段

2000年-2010年

数仓提供方

企业级数据仓库（EDW）
IOT(IBM、Oracle、Teradata)
提供数据仓库建设从硬件、软件到实施的整体方案

需要购买大（中、小）型机 配套商用的关系型数据库
（Oracle、DB2、SQL Server）以及一些ETL/OLAP套件

使用范围

实施成本高昂 
集中在金融、电信、大型零售与制造等行业

作用

为企业提供报表、分析等数据
辅助企业的经营决策
电信行业的经营分析系统、银行的风控管理

第二阶段

2010年-2015年 大数据平台阶段

搭建方式

企业基于Hadoop分布式的计算框架
使用相对廉价的PC服务器就能搭建起大数据集群

目的

数据湖 降低传统数仓较为复杂的中间建模过程

使用过程

通过接入业务系统的原始数据 包括结构化、非结构数据

借助Hadoop生态强大计算引擎 将数据直接服务于应用 

使用范围

国内主流互联网企业纷纷搭建大数据平台

使用场景

决策分析
基于APP/门户站点的搜索推荐
A/B Test对产品进行升级迭代
用户画像（企业的营销、运营）

第三阶段

2015年至今 数据中台 云上大数据阶段

数据统一化

数据流转的所有环节进行统一化

从采集到存储到加工等过程

建立统一的公共数据模型体系

统一的指标与标签体系

提高数据的标准性、易用性

工具组件化

• 场景

数据再采集、计算、存储、应用过程涉及多业务线条 多场景

• 工具

采集工具、管道工具、计算&调度工具、数据服务工具、数据管理工具、可视化工具

应用服务化

通过数据中台应用服务化建设
提供标准应用服务
以数据可视化产品
数据API工具等服务

组织清晰化

按照职责分为 平台（工具）研发、数据研发、数据产品、数据分析

数据中台团队专注于数据内容&数据平台开发，提供各种基于数据的能力模块

其他部门人员如业务产品、运营、分析等角色，只需要借助工具/产品有效地使用数据，发挥其价值，无需关注数据加工的过程

当前阶段

使用场景

• 决策分析

• 大数据与线上事务系统（OLTP）的联动场景

电商平台查询个人所有历史订单
刷单
反作弊的实时拦截
一些实时推荐

大概流程

将数据的运算交给数据中台部门处理
前台部门直接通过API进行结果调用

数据中台能力

数据中台的集中化建设也更好地支撑起创新业务
比如通过大数据+分析建立起商业化数据变现产品 进行数据售卖
把数据变成新的业务

共享复用

早期数据仓库（建立公共数据模型）、大数据平台（研发一些组件化工具）的建设中，也是满足共享复用

• 共享数据组
• 公共数据组

借助云计算

云计算的发展可以快速提供数据中台建设的能力
例如企业无需自己搭建机房
使用云计算的弹性计算存储能力以及丰富的工具
可以支撑数据中台的快速搭建

争议

1、
大型（集团型）公司有相互独立的子公司
数据之间不需要太多连接与共享
分别构建自己子数据中台也是合理的架构
集团层面可以利用数据子中台进行数据上报解决集团层面数据大盘、统计、分析、财务等诉求

2、
一些小型公司是否需要在一开始就按照数据中台的架构进行建设

数据中台架构与技术选型

底座是数据基础平台

数据采集平台&计算平台&存储平台 
可自建可使用云计算服务

中间部分两大块是中台的公共数据区

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

上层是数据应用服务层

将公共数据区的数据对外包装并提供服务，包括数据接口平台、多维查询平台，数据可视化平台、数据分析平台等

贯穿始终

• 数据开发平台

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

• 数据管理平台

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

与业务充分结合

在数据中台的建设中一定不要忽视的是与业务的衔接
因为数据来源于业务并最终应用于业务
在数据中台的建设中需要有一系列的流程制度明确与业务的充分衔接
以保障数据源&数据产出的质量

数据中台技术选型参考

数据抽取层

• sqoop

结构化数据（关系型数据库）离线抽取

• flume

非结构化日志接入

数据存储层

Hadoop文件系统Hdfs
kafka作为流式数据总线

计算与调度层

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

实时计算

前些年storm，spark比较流行
最近几年大家纷纷往Flink转型

数据调度

除了像Airflow Azkaban Oozie等
易观开源的Dolphin-scheduler也非常活跃

数据引擎层

即OLAP层
这一层里的选择非常多
选择丰富主要是可以适配不同的数据应用场景
从概念上讲分为ROLAP、MOLAP以及两者混搭

• MOLAP

提前做一些预计算
以生成Cube的方式
达到空间换取查询效率

• ROLAP

即查即用
效率完全取决于查询引擎的性能
ROLAP的趋势会更加明显 因为没有中间的数据链路

数据可视化层

比较主流的有Metabase、Superset、Redash
也可以选择阿里、百度的一些开源控件

组件选择

开源组件选择标准

• 是否有鲜活的成功案例，优先找自己类似业务场景

• 接口的开放性，与其他组件的兼容性

• 社区活跃性度&发展趋势

商业化组件

基于云的数据组件可以选择
包括数据采集、处理、分析、数据可视化全过程

数据研发实践

数据处理架构

最早数据仓库的计算只支持批处理
通常是按天定时处理数据

在后期逐步进化到准实时，本质上还是批处理
只是处理频度上得有提升，到小时级，或者15分钟这种

• lambda架构

后期演化出一条新的流处理链路 这个链路和之前的批处理分别处理
然后在服务层面利用大数据的计算能力进行合并
向外提供离线+实时数据服务

• Flink流批一体化

在接入层统一采用流式接入
计算层采用统一套框架支持实时计算+离线计算
批处理仅仅作为流处理的一个特殊场景进行支持
整体上可以做到流处理、批处理的自由切换

流批处理区别

• 流计算

用于支持线上业务场景（比如互联网的推荐、搜索、风控等）

• 批处理

更多是支持离线统计分析

业务数据层（ODS层）

• 原始数据

原始数据经过缓冲层（STG）的加载

会进入数仓的业务数据层

这一层采用范式建模

基本保持与数据源完全一致的结构

好处

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

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

• 变化的数据

使用数据拉链加工与存储

好处

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

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

公共数据层（包括公共明细层DWD，公共汇总层DWS）

公共数据层是数据仓库的核心层，是整个数仓中使用率最高的

采用维度建模思路

类型包括事务事实、周期快照、累积快照

方便下游对数据的使用设计一系列的宽表模型

在调用分布来看，宽表的使用占到70%以上

将不同业务过程中的事实进行统一整合，包括纵向整合&横向整合

• 纵向

对于商品、用户主数据类可能分散在不同的源系统中采用纵向整合

• 横向

横向整合主要包括交易、内容等行为数据不同业务过程的整合

比如：用户（用户信息、注册信息）购买（下单、支付、结算、覆约、完成）商品（商品信息，商家信息，等）

会把订单流转业务过程整合放到一张明细表里，同时会研发一些基于用户、或者商品视角的轻度汇总宽表

劣势

1、数据冗余较多，在存储、计算、调用较为占资源，建议尽量还是按场景去使用
2、宽表整合的信息较多，数据权限不好控制。建议可以根据需求，在有限范围内开放整体宽表权限，或者通过视图或者子表的方式建立不同权限的数据范围，适应不同组织的需求
3、宽表通常依赖比较多，会影响数据的产出的时效。

应用数据层（DWA层）

偏向应用的数据加工

也叫集市层

按维度建模思想

主题分类

• 数据主题视角

主题是将企业的业务进行宏观数据抽象
是数据仓库里数据的主要组织形式

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

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

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

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

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

2、第二级是主题

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

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

• 数据业务视角

数据业务域是根据企业经营的具体业务

结合企业的组织架构进行划分

层次和分类可以相对灵活，子分类可以允许重复

因为两条不同的业务域可能经营相同的业务，例如电商、内容下都有会员这个业务

内容+电商的数据主题与业务分类

一横一纵两个视角，将数据进行更好的归类，在数据模型设计中会打上相应分类标签，从而让数据研发&数据使用人员统一认知

以上两种分类方式主要应用于核心的公共数据层

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

数据研发流程

1、数据研发需要与业务部门充分衔接，比如在数据调研中要与业务研发同学进行线上数据&结构访谈

2、在数据开发中，与分析&业务同学共同确认标准口径

3、在数据研发完成后对数据使用方进行数据发布与培训

4、除了需求调研，其他部分都进行了线上化，包括数据的模型设计，早期会手写mapping文档，后期逐步把mapping文档进行了线上化

5、整体的数据模型设计通过模型设计工具完成，包括从概念模型、逻辑模型到物理模型的设计

6、模型设计完成后，可以一键生成数据知识文档

数据生命周期管理

数据研发完成，还需要关注数据生命周期

数据量的飞速增长不仅仅需要占用大量存储，比如像自建机房，会涉及扩充机柜、机房，往往会面临一些瓶颈

另外一方面，大量的数据会降低数据的计算效率，所以从数据的生成开始，就需要考虑生命周期，并且结合数据的使用情况制定数据归档、数据销毁等管理策略

1、降存量

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

2、控增量

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

3、摊成本

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

数据安全

针对用户敏感信息，需要在接入时考虑如何加密

1、通过一个独立的物理集群对敏感数据进行隔离与强管控

2、将数据划分不同的安全或敏感等级（例如有些财务数据的非常敏感，需要谨慎对外开放）

根据不同的等级设定不同的访问审批机制

在数据归档、销毁也需要制定好配套的安全管理措施，避免安全风险

数据质量管理

数据质量管理3个角度：准确性、及时性、一致性

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

针对数据运维的告警发送

传统的方式：短信、邮件、电话

将运维告警以数据接口的方式与这些工具进行对接，将告警发送到企业内部的即时通讯工具

数据应用架构

• 数据仓库（或者数据湖）

负责原始数据的计算
主要将数据落地到HDFS

• 数据引擎层

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

• 数据服务层

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

• 指标平台

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

• 多维查询

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

• 中间是统一元数据管理

对整个架构中可以对外提供服务的元数据进行统一管理
（包括数仓的元数据、查询引擎的元数据、指标元数据等）

以及监控这些元数据的调用情况

• 最右侧是权限管理

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

• 面向用户使用层面

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

数据ROI评估

根据活跃度（调用次数等）、覆盖度（通过血缘关系找出依赖数量），以及贡献度（依赖数据的重要等级）来确认数据的价值

同时会评估数据的成本指数（例如计算成本、存储成本等）

比如针对价值低，成本高的数据，可以考虑下线等

简介

HBase是一个分布式的、面向列的开源数据库

Bigtable：一个结构化数据的分布式存储系统

就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样

HBase在Hadoop之上提供了类似于Bigtable的能力

HBase是Apache的Hadoop项目的子项目

HBase不同于一般的关系数据库 是一个适合于非结构化数据存储的数据库

另一个不同的是HBase基于列的而不是基于行的模式

结构

HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统

利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群

HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统

Google运行MapReduce来处理Bigtable中的海量数据
HBase同样利用Hadoop MapReduce来处理HBase中的海量数据
Google Bigtable利用 Chubby作为协同服务
HBase利用Zookeeper作为对应

HBase位于结构化存储层
Hadoop HDFS为HBase提供了高可靠性的底层存储支持
Hadoop MapReduce为HBase提供了高性能的计算能力
Zookeeper为HBase提供了稳定服务和failover机制


Pig和Hive还为HBase提供了高层语言支持
使得在HBase上进行数据统计处理变的非常简单

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

访问接口

Native Java API，最常规和高效的访问方式，适合Hadoop MapReduce Job并行批处理HBase表数据

REST Gateway，支持REST 风格的Http API访问HBase, 解除了语言限制

HBase数据模型Table & Column Family

• Row Key

行键，Table的主键，Table中的记录默认按照Row Key升序排序

• Timestamp:时间戳

每次数据操作对应的时间戳，可以看作是数据的version number

• Column Family：列簇

Table在水平方向有一个或者多个Column Family组成
一个Column Family中可以由任意多个Column组成
即Column Family支持动态扩展
无需预先定义Column的数量以及类型
所有Column均以二进制格式存储
用户需要自行进行类型转换

• Table & Region

当Table随着记录数不断增加而变大后
会逐渐分裂成多份splits，成为regions
一个region由[startkey,endkey)表示
不同的region会被Master分配给相应的RegionServer进行管理

HBase中有两张特殊的Table，-ROOT-和.META.

.META.：记录了用户表的Region信息，.META.可以有多个region

-ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region

Zookeeper中记录了-ROOT-表的location


Client访问用户数据之前需要首先访问zookeeper
然后访问-ROOT-表，接着访问.META.表
最后才能找到用户数据的位置去访问，中间需要多次网络操作
不过client端会做cache缓存

• MapReduce on HBase

HBase Table和Region的关系 比较类似HDFS File和Block的关系

HBase提供了配套的TableInputFormat和TableOutputFormat API

可以方便的将HBase Table作为Hadoop MapReduce的Source和Sink

对于MapReduce Job应用开发人员来说，基本不需要关注HBase系统自身的细节

• Client

HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信

对于管理类操作，Client与HMaster进行RPC

对于数据读写类操作，Client与HRegionServer进行RPC

• Zookeeper

Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址

HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中

使得HMaster可以随时感知到各个HRegionServer的健康状态

Zookeeper也避免了HMaster的单点问题

• HMaster

HMaster没有单点问题
HBase中可以启动多个HMaster
通过Zookeeper的Master Election机制保证总有一个Master运行
HMaster在功能上主要负责Table和Region的管理工作

1. 管理用户对Table的增、删、改、查操作

2. 管理HRegionServer的负载均衡，调整Region分布

3. 在Region Split后，负责新Region的分配

4. 在HRegionServer停机后，负责失效HRegionServer 上的Regions迁移

• HRegionServer

HRegionServer主要负责响应用户I/O请求
向HDFS文件系统中读写数据，是HBase中最核心的模块

HRegionServer内部管理了一系列HRegion对象
每个HRegion对应了Table中的一个Region
HRegion中由多个HStore组成

每个HStore对应了Table中的一个Column Family的存储
可以看出每个Column Family其实就是一个集中的存储单元
因此最好将具备共同IO特性的column放在一个Column Family中，这样最高效

• HStore

HStore存储是HBase存储的核心了
其中由两部分组成，一部分是MemStore
一部分是StoreFiles
MemStore是Sorted Memory Buffer
用户写入的数据首先会放入MemStore
当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）

• StoreFile

当StoreFile文件数量增长到一定阈值，会触发Compact合并操作
将多个StoreFiles合并成一个StoreFile
合并过程中会进行版本合并和数据删除
因此可以看出HBase其实只有增加数据
所有的更新和删除操作都是在后续的compact过程中进行的
这使得用户的写操作只要进入内存中就可以立即返回
保证了HBase I/O的高性能
当StoreFiles Compact后，会逐步形成越来越大的StoreFile
当单个StoreFile大小超过一定阈值后，会触发Split操作
同时把当前Region Split成2个Region
父Region会下线
新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上
使得原先1个Region的压力得以分流到2个Region上

• HLog

在分布式系统环境中，无法避免系统出错或者宕机
因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失
这就需要引入HLog了
每个HRegionServer中都有一个HLog对象
HLog是一个实现Write Ahead Log的类
在每次用户操作写入MemStore的同时
也会写一份数据到HLog文件中
HLog文件定期会滚动出新的
并删除旧的文件（已持久化到StoreFile中的数据）
当HRegionServer意外终止后
HMaster会通过Zookeeper感知到
HMaster首先会处理遗留的 HLog文件
将其中不同Region的Log数据进行拆分
分别放到相应region的目录下
然后再将失效的region重新分配
领取 到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理
因此会Replay HLog中的数据到MemStore中
然后flush到StoreFiles，完成数据恢复

存储格式

HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括上述提出的两种文件类型

• HFile

HBase中KeyValue数据的存储格式
HFile是Hadoop的二进制格式文件
实际上StoreFile就是对HFile做了轻量级包装
即StoreFile底层就是HFile

HBase中WAL（Write Ahead Log） 的存储格式
物理上是Hadoop的Sequence File

首先HFile文件是不定长的
长度固定的只有其中的两块：Trailer和FileInfo

Trailer中有指针指向其他数据块的起始点

File Info中记录了文件的一些Meta信息
例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等

Data Index和Meta Index块记录了每个Data块和Meta块的起始点

Data Block是HBase I/O的基本单元，为了提高效率


HRegionServer中有基于LRU的Block Cache机制

每个Data块的大小可以在创建一个Table的时候通过参数指定

大号的Block有利于顺序Scan，小号Block利于随机查询

每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成
Magic内容就是一些随机数字，目的是防止数据损坏

HFile里面的每个KeyValue对就是一个简单的byte数组

但是这个byte数组里面包含了很多项，并且有固定的结构

里面的具体结构：

开始是两个固定长度的数值，分别表示Key的长度和Value的长度
紧接着是Key，开始是固定长度的数值
表示RowKey的长度，紧接着是RowKey
然后是固定长度的数值，表示Family的长度
然后是Family，接着是Qualifier
然后是两个固定长度的数值，
表示Time Stamp和Key Type（Put/Delete）
Value部分没有这么复杂的结构，就是纯粹的二进制数据了

• HLogFile

HLog文件就是一个普通的Hadoop Sequence File
Sequence File 的Key是HLogKey对象
HLogKey中记录了写入数据的归属信息
除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue

参考文章

https://baijiahao.baidu.com/s?id=1665096379718834187&wfr=spider&for=pc

https://baike.baidu.com/item/HBase/7670213?fr=aladdin