大数据发展历程
第一阶段
2000年-
数仓提供方
IOT(IBM、Oracle、Teradata) 提供数据仓库建设从硬件、软件到实施的整体方案 需要购买大（中、小）型机配套商用的关系型数据库 （Oracle、DB2、SQLServer）以及一些ETL/OLAP套件企业级数据仓库（EDW）
使用范围
集中在金融、电信、大型零售与制造等行业实施成本高昂
作用
辅助企业的经营决策 电信行业的经营分析系统、银行的风控管理为企业提供报表、分析等数据
第二阶段
- 大数据平台阶段
搭建方式
使用相对廉价的PC服务器就能搭建起大数据集群企业基于Hadoop分布式的计算框架
目的
数据湖降低传统数仓较为复杂的中间建模过程
使用过程
借助Hadoop生态强大计算引擎将数据直接服务于应用通过接入业务系统的原始数据包括结构化、非结构数据
使用范围
国内主流互联网企业纷纷搭建大数据平台
使用场景
基于APP/门户站点的搜索推荐 A/BTest对产品进行升级迭代 用户画像（企业的营销、运营）决策分析
第三阶段
至今 数据中台 云上大数据阶段
数据统一化
从采集到存储到加工等过程 建立统一的公共数据模型体系 统一的指标与标签体系 提高数据的标准性、易用性数据流转的所有环节进行统一化
工具组件化
场景
数据再采集、计算、存储、应用过程涉及多业务线条多场景
工具
采集工具、管道工具、计算&调度工具、数据服务工具、数据管理工具、可视化工具
应用服务化
提供标准应用服务 以数据可视化产品 数据API工具等服务通过数据中台应用服务化建设
组织清晰化
数据中台团队专注于数据内容&数据平台开发，提供各种基于数据的能力模块 其他部门人员如业务产品、运营、分析等角色，只需要借助工具/产品有效地使用数据，发挥其价值，无需关注数据加工的过程按照职责分为平台（工具）研发、数据研发、数据产品、数据分析
当前阶段
使用场景
决策分析
大数据与线上事务系统（OLTP）的联动场景
刷单 反作弊的实时拦截 一些实时推荐电商平台查询个人所有历史订单
大概流程
前台部门直接通过API进行结果调用将数据的运算交给数据中台部门处理
数据中台能力
比如通过大数据+分析建立起商业化数据变现产品进行数据售卖 把数据变成新的业务数据中台的集中化建设也更好地支撑起创新业务
共享复用
早期数据仓库（建立公共数据模型）、大数据平台（研发一些组件化工具）的建设中，也是满足共享复用
共享数据组
公共数据组
借助云计算
例如企业无需自己搭建机房 使用云计算的弹性计算存储能力以及丰富的工具 可以支撑数据中台的快速搭建云计算的发展可以快速提供数据中台建设的能力
争议
大型（集团型）公司有相互独立的子公司 数据之间不需要太多连接与共享 分别构建自己子数据中台也是合理的架构 集团层面可以利用数据子中台进行数据上报解决集团层面数据大盘、统计、分析、财务等诉求 2、 一些小型公司是否需要在一开始就按照数据中台的架构进行建设1、
数据中台架构与技术选型
底座是数据基础平台
可自建可使用云计算服务数据采集平台&计算平台&存储平台
中间部分两大块是中台的公共数据区
主要负责公共数据模型研发 还包括统一指标（标签）平台 负责把模型组织成可以对外服务的数据，例如数据指标、数据标签公共数据区包括数据仓库(数据湖)
上层是数据应用服务层
将公共数据区的数据对外包装并提供服务，包括数据接口平台、多维查询平台，数据可视化平台、数据分析平台等
贯穿始终
数据开发平台
例如：数据管道工具（比如数据接入、数据导出）、模型设计工具、脚本开发工具、数据调度工具等包括数据开发的各类工具组合
数据管理平台
针对数据全链路的数据管理，保证数据中台可以监控数据链路中的数据流向、数据使用效果、数据生命周期，以衡量数据的价值与成本包括统一元数据管理、数据质量管理、数据生命周期管理
与业务充分结合
因为数据来源于业务并最终应用于业务 在数据中台的建设中需要有一系列的流程制度明确与业务的充分衔接 以保障数据源&数据产出的质量在数据中台的建设中一定不要忽视的是与业务的衔接
数据中台技术选型参考
数据抽取层
sqoop
结构化数据（关系型数据库）离线抽取
flume
非结构化日志接入
数据存储层
kafka作为流式数据总线Hadoop文件系统Hdfs
计算与调度层
也有部分选用tez离线计算主要是hive，spark
实时计算
最近几年大家纷纷往Flink转型前些年storm，spark比较流行
数据调度
易观开源的Dolphin-scheduler也非常活跃除了像AirflowAzkabanOozie等
数据引擎层
这一层里的选择非常多 选择丰富主要是可以适配不同的数据应用场景 从概念上讲分为ROLAP、MOLAP以及两者混搭即OLAP层
MOLAP
以生成Cube的方式 达到空间换取查询效率提前做一些预计算
ROLAP
效率完全取决于查询引擎的性能 ROLAP的趋势会更加明显因为没有中间的数据链路即查即用
数据可视化层
也可以选择阿里、百度的一些开源控件比较主流的有Metabase、Superset、Redash
组件选择
开源组件选择标准
是否有鲜活的成功案例，优先找自己类似业务场景
接口的开放性，与其他组件的兼容性
社区活跃性度&发展趋势
商业化组件
包括数据采集、处理、分析、数据可视化全过程基于云的数据组件可以选择
数据研发实践
数据处理架构
通常是按天定时处理数据 在后期逐步进化到准实时，本质上还是批处理 只是处理频度上得有提升，到小时级，或者15分钟这种最早数据仓库的计算只支持批处理
lambda架构
然后在服务层面利用大数据的计算能力进行合并 向外提供离线+实时数据服务后期演化出一条新的流处理链路这个链路和之前的批处理分别处理
Flink流批一体化
计算层采用统一套框架支持实时计算+离线计算 批处理仅仅作为流处理的一个特殊场景进行支持 整体上可以做到流处理、批处理的自由切换在接入层统一采用流式接入
流批处理区别
流计算
用于支持线上业务场景（比如互联网的推荐、搜索、风控等）
批处理
更多是支持离线统计分析
业务数据层（ODS层）
原始数据
会进入数仓的业务数据层 这一层采用范式建模 基本保持与数据源完全一致的结构原始数据经过缓冲层（STG）的加载
好处
2、便于业务研发更好地理解数据，同时是也是公司的原始数据资产1、一次性接入数据源结构，针对需求的变动不用频繁去与数据源对接
变化的数据
使用数据拉链加工与存储
好处
长期来看，拉链存储比起每天全量保留历史节约大概90%空间 2、快速、高效地获取历史任意一天业务系统的快照数据1、保留历史数据的同时，尽可能少占用存储空间
公共数据层（包括公共明细层DWD，公共汇总层DWS）
采用维度建模思路 类型包括事务事实、周期快照、累积快照 方便下游对数据的使用设计一系列的宽表模型 在调用分布来看，宽表的使用占到70%以上公共数据层是数据仓库的核心层，是整个数仓中使用率最高的
将不同业务过程中的事实进行统一整合，包括纵向整合&横向整合
纵向
对于商品、用户主数据类可能分散在不同的源系统中采用纵向整合
横向
比如：用户（用户信息、注册信息）购买（下单、支付、结算、覆约、完成）商品（商品信息，商家信息，等） 会把订单流转业务过程整合放到一张明细表里，同时会研发一些基于用户、或者商品视角的轻度汇总宽表横向整合主要包括交易、内容等行为数据不同业务过程的整合
劣势
2、宽表整合的信息较多，数据权限不好控制。建议可以根据需求，在有限范围内开放整体宽表权限，或者通过视图或者子表的方式建立不同权限的数据范围，适应不同组织的需求 3、宽表通常依赖比较多，会影响数据的产出的时效。1、数据冗余较多，在存储、计算、调用较为占资源，建议尽量还是按场景去使用
应用数据层（DWA层）
也叫集市层 按维度建模思想偏向应用的数据加工
主题分类
数据主题视角
是数据仓库里数据的主要组织形式 1、参照波特价值链，分析企业本身经营的业务（基本活动、支持型活动），分别对应哪些数据 2、参照业界通用模型，例如像IBM、TD等针对大型行业（如电信、金融、零售）有一些数据主题的通用划分方法 3、对企业的内部数据（线上数据模块、数据字典）进行摸底，确认对应到哪些主题主题是将企业的业务进行宏观数据抽象
划分结果会按照三个层级：主题域—》主题—》子主题
1、第一级是主题域，针对相对稳定的主题进行合并，归拢到主题域，利于数据的理解与建立全局的数据资产目录 2、第二级是主题 3、第三级是子主题，主要针对有些主题下分类较多，比如供应链主题下会包含采购、仓储、配送等子主题 数据主题划分建议完全互斥，不建议重复
数据业务视角
结合企业的组织架构进行划分 层次和分类可以相对灵活，子分类可以允许重复 因为两条不同的业务域可能经营相同的业务，例如电商、内容下都有会员这个业务数据业务域是根据企业经营的具体业务
内容+电商的数据主题与业务分类
以上两种分类方式主要应用于核心的公共数据层 业务数据层、应用数据层并不需要遵循以上分类规则，比如业务数据层（ODS层）是按照数据源进行分类，应用数据层（DWA）是根据具体的应用进行分类一横一纵两个视角，将数据进行更好的归类，在数据模型设计中会打上相应分类标签，从而让数据研发&数据使用人员统一认知
数据研发流程
2、在数据开发中，与分析&业务同学共同确认标准口径 3、在数据研发完成后对数据使用方进行数据发布与培训 4、除了需求调研，其他部分都进行了线上化，包括数据的模型设计，早期会手写mapping文档，后期逐步把mapping文档进行了线上化 5、整体的数据模型设计通过模型设计工具完成，包括从概念模型、逻辑模型到物理模型的设计 6、模型设计完成后，可以一键生成数据知识文档1、数据研发需要与业务部门充分衔接，比如在数据调研中要与业务研发同学进行线上数据&结构访谈
数据生命周期管理
数据量的飞速增长不仅仅需要占用大量存储，比如像自建机房，会涉及扩充机柜、机房，往往会面临一些瓶颈 另外一方面，大量的数据会降低数据的计算效率，所以从数据的生成开始，就需要考虑生命周期，并且结合数据的使用情况制定数据归档、数据销毁等管理策略 1、降存量 通过数据压缩技术、降副本等方式，以及在数据模型更合理的设计 将存量数据存储降低 2、控增量 根据数据重要性，可恢复性等考量角度，确认数据的保留周期 并根据周期自动归档或删除 3、摊成本 可以通过一些算法，比如数据调用分布、需求来源等 把成本分摊到相应业务部门 让相关业务部门关注到成本数据研发完成，还需要关注数据生命周期
数据安全
1、通过一个独立的物理集群对敏感数据进行隔离与强管控 2、将数据划分不同的安全或敏感等级（例如有些财务数据的非常敏感，需要谨慎对外开放） 根据不同的等级设定不同的访问审批机制 在数据归档、销毁也需要制定好配套的安全管理措施，避免安全风险针对用户敏感信息，需要在接入时考虑如何加密
数据质量管理
管理的环节：事前、事中、事后、以及事故管理 针对数据运维的告警发送 传统的方式：短信、邮件、电话 将运维告警以数据接口的方式与这些工具进行对接，将告警发送到企业内部的即时通讯工具数据质量管理3个角度：准确性、及时性、一致性
数据应用架构
数据仓库（或者数据湖）
主要将数据落地到HDFS负责原始数据的计算
数据引擎层
这一层之前提到选择非常多，可以根据自己的场景选择一个混搭组合 可选择的有Presto，Kylin，Druid，Mysql数据加工完成之后，会将数据推送到不同的引擎中
数据服务层
屏蔽底层不同的数据引擎 为上层统一查询提供标准接口通过统一化的SQL调用服务
指标平台
定位于衔接数据研发与数据应用 包括指标的标准定义、逻辑、计算方式、分类等各项内容 指标分类上分为标准指标(指标口径经过审核过)、以及非标准指标指标平台是一个非常关键的产品
多维查询
查询的数据主要来源指标平台 可以选定不同的指标维度组合进行结果呈现 用户可以一次性查询得到结果 也可以将查询结果配置成可视化的报表进行固化一个即席查询工具
中间是统一元数据管理
（包括数仓的元数据、查询引擎的元数据、指标元数据等） 以及监控这些元数据的调用情况对整个架构中可以对外提供服务的元数据进行统一管理
最右侧是权限管理
在设计上需要考虑周全，比如针对表级、指标级、维度级别都可以进行控制 同时产品层面也需要灵活配置权限审批级别与人员权限管理关乎到数据安全
面向用户使用层面
用户通过多维去查询各类指标&维度数据得到数据结果列表 再选择可视化配置面板，完成各类图表、表格的自主配置 并发布到个人看板或者业务大盘目录里 也可以将配置的数据看板进行灵活组合，定制成一个小型的数据产品开放的是多维查询&可视化
数据ROI评估
同时会评估数据的成本指数（例如计算成本、存储成本等） 比如针对价值低，成本高的数据，可以考虑下线等根据活跃度（调用次数等）、覆盖度（通过血缘关系找出依赖数量），以及贡献度（依赖数据的重要等级）来确认数据的价值
简介
Bigtable：一个结构化数据的分布式存储系统 就像Bigtable利用了Google文件系统（FileSystem）所提供的分布式数据存储一样 HBase在Hadoop之上提供了类似于Bigtable的能力 HBase是Apache的Hadoop项目的子项目 HBase不同于一般的关系数据库是一个适合于非结构化数据存储的数据库 另一个不同的是HBase基于列的而不是基于行的模式HBase是一个分布式的、面向列的开源数据库
结构
HBase–HadoopDatabase，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统 利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群 HBase是GoogleBigtable的开源实现，类似GoogleBigtable利用GFS作为其文件存储系统，HBase利用HadoopHDFS作为其文件存储系统 Google运行MapReduce来处理Bigtable中的海量数据 HBase同样利用HadoopMapReduce来处理HBase中的海量数据 GoogleBigtable利用Chubby作为协同服务 HBase利用Zookeeper作为对应 HBase位于结构化存储层 HadoopHDFS为HBase提供了高可靠性的底层存储支持 HadoopMapReduce为HBase提供了高性能的计算能力 Zookeeper为HBase提供了稳定服务和failover机制 Pig和Hive还为HBase提供了高层语言支持 使得在HBase上进行数据统计处理变的非常简单 Sqoop则为HBase提供了方便的RDBMS数据导入功能 使得传统数据库数据向HBase中迁移变的非常方便
访问接口
RESTGateway，支持REST风格的HttpAPI访问HBase,解除了语言限制NativeJavaAPI，最常规和高效的访问方式，适合HadoopMapReduceJob并行批处理HBase表数据
HBase数据模型Table & Column Family
Row Key
行键，Table的主键，Table中的记录默认按照RowKey升序排序
Timestamp:时间戳
每次数据操作对应的时间戳，可以看作是数据的versionnumber
Column Family：列簇
一个ColumnFamily中可以由任意多个Column组成 即ColumnFamily支持动态扩展 无需预先定义Column的数量以及类型 所有Column均以二进制格式存储 用户需要自行进行类型转换Table在水平方向有一个或者多个ColumnFamily组成
Table & Region
会逐渐分裂成多份splits，成为regions 一个region由[startkey,endkey)表示 不同的region会被Master分配给相应的RegionServer进行管理当Table随着记录数不断增加而变大后
.META.：记录了用户表的Region信息，.META.可以有多个region -ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region Zookeeper中记录了-ROOT-表的location Client访问用户数据之前需要首先访问zookeeper 然后访问-ROOT-表，接着访问.META.表 最后才能找到用户数据的位置去访问，中间需要多次网络操作 不过client端会做cache缓存HBase中有两张特殊的Table，-ROOT-和.META.
MapReduce on HBase
HBase提供了配套的TableInputFormat和TableOutputFormatAPI 可以方便的将HBaseTable作为HadoopMapReduce的Source和Sink 对于MapReduceJob应用开发人员来说，基本不需要关注HBase系统自身的细节HBaseTable和Region的关系比较类似HDFSFile和Block的关系
Client
对于管理类操作，Client与HMaster进行RPC 对于数据读写类操作，Client与HRegionServer进行RPCHBaseClient使用HBase的RPC机制与HMaster和HRegionServer进行通信
Zookeeper
HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中 使得HMaster可以随时感知到各个HRegionServer的健康状态 Zookeeper也避免了HMaster的单点问题ZookeeperQuorum中除了存储了-ROOT-表的地址和HMaster的地址
HMaster
HBase中可以启动多个HMaster 通过Zookeeper的MasterElection机制保证总有一个Master运行 HMaster在功能上主要负责Table和Region的管理工作 1.管理用户对Table的增、删、改、查操作 2.管理HRegionServer的负载均衡，调整Region分布 3.在RegionSplit后，负责新Region的分配 4.在HRegionServer停机后，负责失效HRegionServer上的Regions迁移HMaster没有单点问题
HRegionServer
向HDFS文件系统中读写数据，是HBase中最核心的模块 HRegionServer内部管理了一系列HRegion对象 每个HRegion对应了Table中的一个Region HRegion中由多个HStore组成 每个HStore对应了Table中的一个ColumnFamily的存储 可以看出每个ColumnFamily其实就是一个集中的存储单元 因此最好将具备共同IO特性的column放在一个ColumnFamily中，这样最高效HRegionServer主要负责响应用户I/O请求
HStore
其中由两部分组成，一部分是MemStore 一部分是StoreFiles MemStore是SortedMemoryBuffer 用户写入的数据首先会放入MemStore 当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）HStore存储是HBase存储的核心了
StoreFile
将多个StoreFiles合并成一个StoreFile 合并过程中会进行版本合并和数据删除 因此可以看出HBase其实只有增加数据 所有的更新和删除操作都是在后续的compact过程中进行的 这使得用户的写操作只要进入内存中就可以立即返回 保证了HBaseI/O的高性能 当StoreFilesCompact后，会逐步形成越来越大的StoreFile 当单个StoreFile大小超过一定阈值后，会触发Split操作 同时把当前RegionSplit成2个Region 父Region会下线 新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上 使得原先1个Region的压力得以分流到2个Region上当StoreFile文件数量增长到一定阈值，会触发Compact合并操作
HLog
因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失 这就需要引入HLog了 每个HRegionServer中都有一个HLog对象 HLog是一个实现WriteAheadLog的类 在每次用户操作写入MemStore的同时 也会写一份数据到HLog文件中 HLog文件定期会滚动出新的 并删除旧的文件（已持久化到StoreFile中的数据） 当HRegionServer意外终止后 HMaster会通过Zookeeper感知到 HMaster首先会处理遗留的HLog文件 将其中不同Region的Log数据进行拆分 分别放到相应region的目录下 然后再将失效的region重新分配 领取到这些region的HRegionServer在LoadRegion的过程中，会发现有历史HLog需要处理 因此会ReplayHLog中的数据到MemStore中 然后flush到StoreFiles，完成数据恢复在分布式系统环境中，无法避免系统出错或者宕机
存储格式
HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，主要包括上述提出的两种文件类型
HFile
HFile是Hadoop的二进制格式文件 实际上StoreFile就是对HFile做了轻量级包装 即StoreFile底层就是HFile HBase中WAL（WriteAheadLog）的存储格式 物理上是Hadoop的SequenceFile 首先HFile文件是不定长的 长度固定的只有其中的两块：Trailer和FileInfo Trailer中有指针指向其他数据块的起始点 FileInfo中记录了文件的一些Meta信息 例如：AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY等 DataIndex和MetaIndex块记录了每个Data块和Meta块的起始点 DataBlock是HBaseI/O的基本单元，为了提高效率 HRegionServer中有基于LRU的BlockCache机制 每个Data块的大小可以在创建一个Table的时候通过参数指定 大号的Block有利于顺序Scan，小号Block利于随机查询 每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成 Magic内容就是一些随机数字，目的是防止数据损坏 HFile里面的每个KeyValue对就是一个简单的byte数组 但是这个byte数组里面包含了很多项，并且有固定的结构 里面的具体结构： 开始是两个固定长度的数值，分别表示Key的长度和Value的长度 紧接着是Key，开始是固定长度的数值 表示RowKey的长度，紧接着是RowKey 然后是固定长度的数值，表示Family的长度 然后是Family，接着是Qualifier 然后是两个固定长度的数值， 表示TimeStamp和KeyType（Put/Delete） Value部分没有这么复杂的结构，就是纯粹的二进制数据了HBase中KeyValue数据的存储格式
HLogFile
SequenceFile的Key是HLogKey对象 HLogKey中记录了写入数据的归属信息 除了table和region名字外，同时还包括sequencenumber和timestamp，timestamp是“写入时间”，sequencenumber的起始值为0，或者是最近一次存入文件系统中sequencenumber。 HLogSequeceFile的Value是HBase的KeyValue对象，即对应HFile中的KeyValueHLog文件就是一个普通的HadoopSequenceFile
参考文章
/item/HBase/7670213?fr=aladdin/s?id=1665096379718834187&wfr=spider&for=pc
