大数据生长历程第一阶段2000年-2010年数仓提供方企业级数据堆栈（EDW）IOT(IBM、Oracle、Teradata)提供数据堆栈建设从硬件、软件到实施的整体方案需要购置大（中、小）型机配套商用的关系型数据库（Oracle、DB2、SQLServer）以及一些ETL/OLAP套件使用规模实施成本高昂集中在金融、电信、大型零售与制造等行业作用为企业提供报表、分析等数据辅助企业的谋划决议电信行业的谋划分析系统、银行的风控治理第二阶段2010年-2015年 大数据平台阶段搭建方式企业基于Hadoop漫衍式的盘算框架使用相对廉价的PC服务器就能搭建起大数据集群目的数据湖降低传统数仓较为庞大的中间建模历程使用历程通过接入业务系统的原始数据包罗结构化、非结构数据借助Hadoop生态强大盘算引擎将数据直接服务于应用使用规模海内主流互联网企业纷纷搭建大数据平台使用场景决议分析基于APP/门户站点的搜索推荐A/BTest对产物举行升级迭代用户画像（企业的营销、运营）第三阶段2015年至今 数据中台 云上大数据阶段数据统一化数据流转的所有环节举行统一化从收罗到存储到加工等历程建设统一的公共数据模型体系统一的指标与标签体系提高数据的尺度性、易用性工具组件化场景数据再收罗、盘算、存储、应用历程涉及多业务线条多场景工具收罗工具、管道工具、盘算&调理工具、数据服务工具、数据治理工具、可视化工具应用服务化通过数据中台应用服务化建设提供尺度应用服务以数据可视化产物数据API工具等服务组织清晰化根据职责分为平台（工具）研发、数据研发、数据产物、数据分析数据中台团队专注于数据内容&数据平台开发，提供种种基于数据的能力模块其他部门人员如业务产物、运营、分析等角色，只需要借助工具/产物有效地使用数据，发挥其价值，无需关注数据加工的历程当前阶段使用场景决议分析大数据与线上事务系统（OLTP）的联动场景电商平台查询小我私家所有历史订单刷单反作弊的实时拦截一些实时推荐或许流程将数据的运算交给数据中台部门处置惩罚前台部门直接通过API举行效果挪用数据中台能力数据中台的集中化建设也更好地支撑起创新业务好比通过大数据+分析建设起商业化数据变现产物举行数据售卖把数据酿成新的业务共享复用早期数据堆栈（建设公共数据模型）、大数据平台（研发一些组件化工具）的建设中，也是满足共享复用共享数据组公共数据组借助云盘算云盘算的生长可以快速提供数据中台建设的能力例如企业无需自己搭建机房使用云盘算的弹性盘算存储能力以及富厚的工具可以支撑数据中台的快速搭建争议1、大型（团体型）公司有相互独立的子公司数据之间不需要太多毗连与共享划分构建自己子数据中台也是合理的架构团体层面可以使用数据子中台举行数据上报解决团体层面数据大盘、统计、分析、财政等诉求2、一些小型公司是否需要在一开始就根据数据中台的架构举行建设数据中台架构与技术选型底座是数据基础平台数据收罗平台&盘算平台&存储平台可自建可使用云盘算服务中间部门两大块是中台的公共数据区公共数据区包罗数据堆栈(数据湖)主要卖力公共数据模型研发还包罗统一指标（标签）平台卖力把模型组织成可以对外服务的数据，例如数据指标、数据标签上层是数据应用服务层将公共数据区的数据对外包装并提供服务，包罗数据接口平台、多维查询平台，数据可视化平台、数据分析平台等贯串始终数据开发平台包罗数据开发的各种工具组合例如：数据管道工具（好比数据接入、数据导出）、模型设计工具、剧本开发工具、数据调理工具等数据治理平台包罗统一元数据治理、数据质量治理、数据生命周期治理针对数据全链路的数据治理，保证数据中台可以监控数据链路中的数据流向、数据使用效果、数据生命周期，以权衡数据的价值与成本与业务充实联合在数据中台的建设中一定不要忽视的是与业务的衔接因为数据泉源于业务并最终应用于业务在数据中台的建设中需要有一系列的流程制度明确与业务的充实衔接以保障数据源&数据产出的质量数据中台技术选型参考数据抽取层sqoop结构化数据（关系型数据库）离线抽取flume非结构化日志接入数据存储层Hadoop文件系统Hdfskafka作为流式数据总线盘算与调理层离线盘算主要是hive，spark也有部门选用tez实时盘算前些年storm，spark比力盛行最近几年大家纷纷往Flink转型数据调理除了像AirflowAzkabanOozie等易观开源的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文件系统（FileSystem）所提供的漫衍式数据存储一样HBase在Hadoop之上提供了类似于Bigtable的能力HBase是Apache的Hadoop项目的子项目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中迁移变的很是利便会见接口NativeJavaAPI，最通例和高效的会见方式，适合HadoopMapReduceJob并行批处置惩罚HBase表数据RESTGateway，支持REST气势派头的HttpAPI会见HBase,排除了语言限制HBase数据模型Table & Column FamilyRow Key行键，Table的主键，Table中的记载默认根据RowKey升序排序Timestamp:时间戳每次数据操作对应的时间戳，可以看作是数据的versionnumberColumn Family：列簇Table在水平偏向有一个或者多个ColumnFamily组成一个ColumnFamily中可以由任意多个Column组成即ColumnFamily支持动态扩展无需预先界说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-只有一个regionZookeeper中记载了-ROOT-表的locationClient会见用户数据之前需要首先会见zookeeper然后会见-ROOT-表，接着会见.META.表最后才气找到用户数据的位置去会见，中间需要多次网络操作不外client端会做cache缓存MapReduce on HBaseHBaseTable和Region的关系比力类似HDFSFile和Block的关系HBase提供了配套的TableInputFormat和TableOutputFormatAPI可以利便的将HBaseTable作为HadoopMapReduce的Source和Sink对于MapReduceJob应用开发人员来说，基本不需要关注HBase系统自身的细节ClientHBaseClient使用HBase的RPC机制与HMaster和HRegionServer举行通信对于治理类操作，Client与HMaster举行RPC对于数据读写类操作，Client与HRegionServer举行RPCZookeeperZookeeperQuorum中除了存储了-ROOT-表的地址和HMaster的地址HRegionServer也会把自己以Ephemeral方式注册到Zookeeper中使得HMaster可以随时感知到各个HRegionServer的康健状态Zookeeper也制止了HMaster的单点问题HMasterHMaster没有单点问题HBase中可以启动多个HMaster通过Zookeeper的MasterElection机制保证总有一个Master运行HMaster在功效上主要卖力Table和Region的治理事情1.治理用户对Table的增、删、改、查操作2.治理HRegionServer的负载平衡，调整Region漫衍3.在RegionSplit后，卖力新Region的分配4.在HRegionServer停机后，卖力失效HRegionServer上的Regions迁移HRegionServerHRegionServer主要卖力响应用户I/O请求向HDFS文件系统中读写数据，是HBase中最焦点的模块HRegionServer内部治理了一系列HRegion工具每个HRegion对应了Table中的一个RegionHRegion中由多个HStore组成每个HStore对应了Table中的一个ColumnFamily的存储可以看出每个ColumnFamily其实就是一个集中的存储单元因此最好将具备配合IO特性的column放在一个ColumnFamily中，这样最高效HStoreHStore存储是HBase存储的焦点了其中由两部门组成，一部门是MemStore一部门是StoreFilesMemStore是SortedMemoryBuffer用户写入的数据首先会放入MemStore当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）StoreFile当StoreFile文件数量增长到一定阈值，会触发Compact合并操作将多个StoreFiles合并成一个StoreFile合并历程中会举行版本合并和数据删除因此可以看出HBase其实只有增加数据所有的更新和删除操作都是在后续的compact历程中举行的这使得用户的写操作只要进入内存中就可以立刻返回保证了HBaseI/O的高性能当StoreFilesCompact后，会逐步形成越来越大的StoreFile当单个StoreFile巨细凌驾一定阈值后，会触发Split操作同时把当前RegionSplit成2个Region父Region会下线新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上使得原先1个Region的压力得以分流到2个Region上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文件系统上，主要包罗上述提出的两种文件类型HFileHBase中KeyValue数据的存储花样HFile是Hadoop的二进制花样文件实际上StoreFile就是对HFile做了轻量级包装即StoreFile底层就是HFileHBase中WAL（WriteAheadLog）的存储花样物理上是Hadoop的SequenceFile首先HFile文件是不定长的长度牢固的只有其中的两块：Trailer和FileInfoTrailer中有指针指向其他数据块的起始点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部门没有这么庞大的结构，就是纯粹的二进制数据了HLogFileHLog文件就是一个普通的HadoopSequenceFileSequenceFile的Key是HLogKey工具HLogKey中记载了写入数据的归属信息除了table和region名字外，同时还包罗sequencenumber和timestamp，timestamp是“写入时间”，sequencenumber的起始值为0，或者是最近一次存入文件系统中sequencenumber。

HLogSequeceFile的Value是HBase的KeyValue工具，即对应HFile中的KeyValue参考文章https://baijiahao.baidu.com/s?id=1665096379718834187&wfr=spider&for=pchttps://baike.baidu.com/item/HBase/7670213?fr=aladdin。

本文来源：爱游戏最新app官方下载-www.mccaee.com