大数据笔试真题集锦---第七章:数仓面试题

第七章目录

第七章 数仓

数仓是一个面向主题的、集成的、稳定的、时变的，存储历史数据的仓库。

面向主题的：数仓中的数据按照主题进行存储，每个主题都是决策层分析的一个角度;

集成的：不同来源的数据会统一整合后存入数仓中;

稳定的：数据一旦进入仓库后不会轻易发生改变，就算数据本身需要变化也轻易不会改动原数据，会根据分析需求考虑数据的更新策略;

时变的：随着时间的推移，长时间不更新的数据会逐渐失去时效性，失去时效性的数据一般会被导出到外部压缩存储。目前常用的策略是"7年13个月"，即保存维度信息的拉链表不保存七年前的数据，保存流水信息的事实表不保存13个月前的数据。

当然，上述保存策略也是根据情况决定，利用价值较低的原始数据可能只保存一个周期就被导出，高度聚合的数据可能保存更长的时间。

7.1 数仓分层

数仓往往分为三层，ods、dw、dm，而dw层又可以根据业务细分为dwd、dws、dwa等多层

7.1.1 ods层

操作型数据层，存放的是从不同来源进入数仓的原始数据，ods层往往只存放少量加工的原始数据，因此这里的数据不是集成的。

7.1.2 dw层

数据仓库的核心，它根据数仓架构可能再次细分多层：

7.1.2.1 dwd层

数据细节层。将ods层的数据统一整合后，依照各

主题需要将数据拆分存储，常见的星型模型和雪花模型就是在这一层。

7.1.2.2 dws层

数据服务层。按照范式存储的数据在分析时往往需要进行多表join，这样的分析效率很低，因此需要将dwd层的数据按照分析需求提前进行整合。由于主题之间的重合，该层的设计是反三范式的，存在数据冗余。

除了上述分层以外，dw还有基础数据层、轻度汇总层等等，根据数仓架构而定。

7.1.2.3 DIM层

维度层。有些数仓会将dwd层中的维度表单独抽离出来维护。

7.1.3 dm层

存放使用DW层数据进行业务统计的结果，它们可能被用于线上可视化的指标分析，也可能用于进一步的数据挖掘使用。

分层作用：复杂问题简单化、减少重复计算、血缘追踪、架构更清晰

7.2 表的种类和特征

事务事实表：可以看做是保存某一事务的日志数据，事务一旦被提交就成为历史数据，只能以增量的方式维护。

维度表：从某个角度观察事实数据的窗口，存储的数据用来从某个角度描述事实。

全量表：保存每天所有的最新状态的数据

增量表：当数据改变时，将这个改变和改变后的结果记录下来，就是增量表。(a账户分两次存了100块，增量表显示为a账户金额100,200，并分别记录变化时间)

拉链表：用特定字段维护缓慢变化维度的表

流水表：记录表中所有改变的表。

周期快照表：按固定周期对事实表进行统计生成的表，按时间段保存记录，增量更新。

累积快照表：按过程对事实表进行统计生成的表，将每个事务切分成多个小事务，明确开始和结束的状态，每个小事务只保存一条结果。

7.3 拉链表如何实现

使用SCD策略维护特定字段实现。SCD1：不保存历史数据，直接覆盖更新SCD2：通过维护一个记录时间和一个过期时间来保存变化历史，增量更新SCD3：通过维护一个历史字段来保存上次的数据，更新数据时，先检查旧数据是否存在，如果存在就把旧数据的最新值保存到新数据的旧值字段，采用覆盖更新的方式存储数据。SCD4：单独建立一个历史维度表为该字段维护历史变化。SCD5：混合使用123的维护策略。

7.4 数仓搭建

7.4.1 建模流程

业务建模

根据业务部门进行划分，理清部门之间的关系，然后将各个部门的具体业务程序化，与业务部门开会协商出需求的指标、保存年限、维度等等。总体来讲，就是要知道他们需要哪些指标以及他们能提供哪些数据。业务建模的时间最长，而且与公司实际的业务环境息息相关，因此在这里需要根据实际生产环境和业务需求确认好数据仓库使用的工具和平台。

概念建模

将业务模型抽象化，分组合并类似的概念，细化概念，抽象出实体与实体之间的联系，理清各组概念之间的联系。说白了就是画图，把指标需要的哪些数据封装到一个实体里，实体与实体之间的关联等等用ER图表示出来。先画出局部ER图，最后再综合画出全局ER图。

逻辑建模

将概念模型实体化，具体考虑概念对应的属性，事件考虑事实属性，维度考虑维度属性。总体来说就是建表，前面已经画出了关系图，这里只要将表里头有哪些字段考虑出来就可以，如果是事实表就考虑事实字段和业务主键，如果是维度表就考虑维度属性，SCD策略等等。在这里需要确定数据粒度，如果多个指标都用到一个字段，则取粒度最小的指标。如果不确定指标的量度，则取毫秒级作为粒度。

物理建模

综合现实的大数据平台、采集工具、etl工具、数仓组件、性能要求、管理要求等多方面因素，设计出具体的项目代码，完成数仓的搭建。

7.4.2 数据模型

星型模型

数仓（具体说是dwd层）中只有一张包含历史数据且不冗余的事实表和一组附属维度表，每个维度一张。事实表与维度表之间通过外键和主键关联。星型模型的维度表可能存在冗余，因此是反三范式的，这种模型在数据维护上较麻烦，但是性能更高，业界普遍使用星型模型。星型模型的难点在于拉链表的维护，拉链表一般不能有冗余。

雪花模型

针对星型模型的维度表进行扩展的模型，将维度表拆解成维度表+说明表，说明表又可以进一步拆分，最终形成事实表-维度表-说明表的多次连接。雪花模型的表一般遵循三范式，在数据的维护上会很方便，但是多表join影响性能。

星系模型

多个事实表采用星型模型共享维度表，就形成了一个星系。

Data Vault模型

从上述模型中我们不难看出，如果解决了拉链表的维护问题，星型模型的缺陷就已经可以忽略。Data Vault模型由中心表、链接表、附属表、PIT表组成，这里的中心表，事实上就是维度表，链接表就是事实表、附属表是拉链表。Data Vault模型就是通过将拉链表从维度表中分离出来，来达到方便维护的目的。首先，中心表是一组业务生命周期内绝不会变的维度表，打个比方就是java里头的常量，常量再怎么冗余也不会有影响。链接表则是保存流水类数据的事实表，它通过外键与多张中心表连接，但不会连接附属表。附属表则是从维度表中抽出来的可能会发生变化的字段或表，这一部分就采用拉链表的方式创建，中心表则通过外键关联附属表的主键。

从同一维度表拆出来的字段根据变化维度不同可能还要分成多表存储，为了避免时效不一致，所以还会建立一张PIT表，用于维护附属表的变化历史。中心表通过外键与PIT表相连，而PIT表则为每个附属表的主键都准备了一个时间字段保存数据的更新时间。

7.4.3 架构方式

inmon架构

自上而下的开发模式，从多个数据源出发，根据需求将不同数据源的数据经过ETL过程获取到各个主题需求的数据集成到数仓中，完成了数据治理后再进行统计业务，将统计结果存入数据集市。

kimball架构

自下而上的开发模式，往往已经存在某个关系明确的业务数据库，架构师需要根据数据库中的数据寻找出有价值的分析指标，然后根据这些指标建立数据集市，再从数据集市出发向下建设需要的数据仓库表。

7.5 数仓与数据库的区别

操作上：数据库是面向事务的，往往是行级操作;数仓则是面向分析的，往往是范围操作功能上：数据库提供即时的增删改查，数仓则寻求的是分析数据提供决策支持设计上：数据库基于ER模型，面向业务;数仓基于星型/雪花模型，面向主题数据上：数据库只保存最新的、近期的数据;数仓则保存所有数据性能上：数据库往往依靠索引快速返回;数仓则往往需要大范围磁盘扫描数据量：数据库数据一般为GB级别，数仓的数据则往往上百TB响应速度：数据库是毫秒级，数仓任务的执行时间往往数小时存储上：数据库是真实的物理存储，数仓则是逻辑存储。

7.6 表和字段建设规范

7.7 元数据管理、数据治理、数据中台

apache atlas

类型系统Type System是Atlas最核心的组件之一，用户可以通过类型系统对数据资产进行分类、定义，然后用Ingest/Export组件添加元数据或输出元数据变化。对外，其他系统可以通过REST API或Kafka Message与Atlas进行集成。

type:代表一类数据，如hdfs_path、hive_db等

entity:代表这类数据的一个实例，如数据库default是hive_db的一个entity

attribute:定义type和entity的具体属性

数据治理

数据中台（未完待续）

数据中台是由阿里巴巴在2015年提出的概念。所谓数据中台，即实现数据的分层与水平解耦，沉淀公共的数据能力，可分为三层，数据模型、数据服务与数据开发，通过数据建模实现跨域数据整合和知识沉淀，通过数据服务实现对于数据的封装和开放，快速、灵活满足上层应用的要求，通过数据开发工具满足个性化数据和应用的需要

7.8 其他

7.8.1 如果让你处理hbase 怎么保证数据的安全性可靠性 不需要具体的设置 要一套方案

  有关数据安全及可靠我们认为大体上分为存储安全和使用安全
  1 数据存储安全
  hbase是基于hdfs的一种数据存储解决方案，所以有关数据的安全性可靠性可以利用hdfs自身的副本机制保障。另外原生的hbase（1.x）并没有提供数据备份机制，目前还是依赖于企业自身的研发保障，如阿里的云hbase进行数据备份。另外在实际操作过程会存在不小心产生的数据误操作，这样备份同样具有实际应用的意义。
  ​
  2 数据使用安全
  示例用户通过接口直接访问HBase数据库，这种情况下存在安全隐患的概率会比较大。一种可能性是黑客会通过黑客技术入侵数据库，对用户的数据进行肆意的“操作”，造成用户数据无法访问，然后进行勒索。必然会要求一种安全机制进行任务守护
  ​

7.8.2 hbase的架构

 

 

  HBase中的存储包括HMaster、HRegionSever、HRegion、HLog、Store、MemStore、StoreFile、HFile等角色构成，具体如下
  ​

HMaster的作用

  HBase中的每张表都通过键按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过256M就要被分割成两个，这个过程由HRegionServer管理，而HRegion的分配由HMaster管理
  ​
  1.为HRegionServer分配HRegion
  2.负责HRegionServer的负载均衡
  3.发现失效的HRegionServer并重新分配
  4.HDFS上的垃圾文件回收
  5.处理Schema更新请求
  ​

HRegionServer的作用

  1.维护HMaster分配给它的HRegion，处理对这些HRegion的IO请求
  2.负责切分正在运行过程中变得过大的HRegion可以看到，Client访问HBase上的数据并不需要HMaster参与，寻址访问ZooKeeper和HRegionServer，数据读写访问HRegionServer，HMaster仅仅维护Table和Region的元数据信息，Table的元数据信息保存在ZooKeeper上，负载很低。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表的每个列簇创建一个Store对象，每个Store都会有一个MemStore和0或多个StoreFile与之对应，每个StoreFile都会对应一个HFile，HFile就是实际的存储文件。因此，一个HRegion有多少列簇就有多少个Store。
  3 一个HRegionServer会有多个HRegion和一个HLog。
  ​

HRegion的作用

      Table在行的方向上分割为多个HRegion，HRegion是HBase中分布式存储和负载均衡的最小单元，即不同的HRegion可以分别在不同的HRegionServer上，但同一个HRegion是不会拆分到多个HRegionServer上的。HRegion按大小分割，每个表一般只有一个HRegion，随着数据不断插入表，HRegion不断增大，当HRegion的某个列簇达到一个阀值（默认256M）时就会分成两个新的HRegion。
  ​
  1、<表名，StartRowKey, 创建时间>
  2、由目录表(-ROOT-和.META.)记录该Region的EndRowKey
  HRegion定位：HRegion被分配给哪个HRegionServer是完全动态的，所以需要机制来定位HRegion具体在哪个HRegionServer，HBase使用三层结构来定位HRegion：
  ​
  1、通过zk里的文件/hbase/rs得到-ROOT-表的位置。-ROOT-表只有一个region。
  2、通过-ROOT-表查找.META.表的第一个表中相应的HRegion位置。其实-ROOT-表是.META.表的第一个region；
  .META.表中的每一个Region在-ROOT-表中都是一行记录。
  3、通过.META.表找到所要的用户表HRegion的位置。用户表的每个HRegion在.META.表中都是一行记录。
  -ROOT-表永远不会被分隔为多个HRegion，保证了最多需要三次跳转，就能定位到任意的region。Client会将查询的位置信息保存缓存起来，缓存不会主动失效，因此如果Client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的HRegion，其中三次用来发现缓存失效，另外三次用来获取位置信息。
  ​

Store相关

  Store
  每一个HRegion由一个或多个Store组成，至少是一个Store，HBase会把一起访问的数据放在一个Store里面，即为每个ColumnFamily建一个Store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个MemStore和0或者多个StoreFile组成。 HBase以Store的大小来判断是否需要切分HRegion。
  ​
  MemStore
  MemStore 是放在内存里的，保存修改的数据即keyValues。当MemStore的大小达到一个阀值（默认64MB）时，MemStore会被Flush到文件，
  即生成一个快照。目前HBase会有一个线程来负责MemStore的Flush操作。
  ​
  StoreFile
  MemStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。
  ​

HFile

  HBase中KeyValue数据的存储格式，是Hadoop的二进制格式文件。 首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。
  ​

7.8.3 hbase的优化

写入数据方面

  Auto Flash
  通过调用HTable.setAutoFlushTo(false)方法可以将HTable写客户端自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存的时候，才会向HBase服务端发起写请求。默认情况下auto flush是开启的。
  ​
  Write Buffer
  通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte字节数，可以根基实际写入数据量的多少来设置该值。
  ​
  WAL Flag
  在HBase中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会写到WAL（Write Ahead Log）日志，即HLog，一个RegionServer上的所有Region共享一个HLog，只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功，如果写WAL日志失败，客户端被告知提交失败，这样做的好处是可以做到RegionServer宕机后的数据恢复。
  对于不太重要的数据，可以在Put/Delete操作时，通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数，放弃写WAL日志，以提高数据写入的性能。
  注：如果关闭WAL日志，一旦RegionServer宕机，Put/Delete的数据将会无法根据WAL日志进行恢复。
  ​
  Compression 压缩
  数据量大，边压边写也会提升性能的，毕竟IO是大数据的最严重的瓶颈，哪怕使用了SSD也是一样。众多的压缩方式中，推荐使用SNAPPY。从压缩率和压缩速度来看，性价比最高。
  HColumnDescriptor hcd = new HColumnDescriptor(familyName);   
  hcd.setCompressionType(Algorithm.SNAPPY);  
  ​
  批量写
  通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase，同样HBase提供了另一个方法：通过调用HTable.put(List)方法可以将指定的row key列表，批量写入多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高，网络传输RTT高的情景下可能带来明显的性能提升。
  ​
  多线程并发写
  在客户端开启多个 HTable 写线程，每个写线程负责一个 HTable 对象的 flush 操作，这样结合定时 flush 和写 buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被 flush（如1秒内），同时又保证在数据量大的时候，写 buffer 一满就及时进行 flush。
  ​
  ​

读数据方面

  批量读
  通过调用 HTable.get(Get) 方法可以根据一个指定的 row key 获取一行记录，同样 HBase 提供了另一个方法：通过调用 HTable.get(List) 方法可以根据一个指定的 row key 列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络 I/O 开销，这对于对数据实时性要求高而且网络传输 RTT 高的情景下可能带来明显的性能提升。
  缓存查询结果
  对于频繁查询 HBase 的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询 HBase；否则对 HBase 发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑 LRU 等常用的策略。
  ​

数据及集群管理

  预分区
  默认情况下，在创建HBase表的时候会自动创建一个Region分区，当导入数据的时候，所有的HBase客户端都向Region写数据，知道这个Region足够大才进行切分，一种可以加快批量写入速度的方法是通过预先创建一些空的Regions，这样当数据写入HBase的时候，会按照Region分区情况，在进群内做数据的负载均衡。
  Rowkey优化
  rowkey是按照字典存储，因此设置rowkey时，要充分利用排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放到一块。
  rowkey若是递增生成的，建议不要使用正序直接写入，可以使用字符串反转方式写入，使得rowkey大致均衡分布，这样设计的好处是能将RegionServer的负载均衡，否则容易产生所有新数据都在集中在一个RegionServer上堆积的现象，这一点还可以结合table的与分区设计。
  减少Column Family数量
  不要在一张表中定义太多的column family。目前HBase并不能很好的处理超过2-3个column family的表，因为某个column family在flush的时候，它临近的column family也会因关联效应被触发flush，最终导致系统产生更过的I/O;
  设置最大版本数
  创建表的时候，可以通过 HColumnDescriptor.setMaxVersions(int maxVersions) 设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置 setMaxVersions(1)。
  缓存策略（setCaching）
  创建表的时候，可以通过HColumnDEscriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。
  设置存储生命期
  创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命周期，过期数据将自动被删除
  磁盘配置
  每台RegionServer管理10-1000个Regions。每个Region在1-2G，则每台server最少要10G，最大要1000*2G=2TB，考虑3备份，需要6TB。方案1是3块2TB磁盘，2是12块500G磁盘，带宽足够时，后者能提供更大的吞吐率，更细力度的冗余备份，更快速的单盘故障恢复。
  分配何时的内存给RegionServer
  在不影响其他服务的情况下，越大越好。在HBase的conf目录下的hbase-env.sh的最后添加export HBASE_REGIONSERVER_OPTS="- Xmx16000m $HBASE_REGIONSERVER_OPTS"
  其中16000m为分配给REgionServer的内存大小。
  写数据的备份数
  备份数与读性能是成正比，与写性能成反比，且备份数影响高可用性。有两种配置方式，一种是将hdfs-site.xml拷贝到hbase的conf目录下，然后在其中添加或修改配置项dfs.replication的值为要设置的备份数，这种修改所有的HBase用户都生效。另一种方式是改写HBase代码，让HBase支持针对列族设置备份数，在创建表时，设置列族备份数，默认为3，此种备份数支队设置的列族生效。
  客户端一次从服务器拉取的数量
  通过配置一次拉取较大的数据量可以减少客户端获取数据的时间，但是他会占用客户端的内存，有三个地方可以进行配置
  ​
  在HBase的conf配置文件中进行配置hbase.client.scanner.caching;
  通过调用HTble.setScannerCaching(int scannerCaching)进行配置；
  通过调用Sacn.setCaching(int caching)进行配置，三者的优先级越来越高。
  ​
  客户端拉取的时候指定列族
  scan是指定需要column family，可以减少网络传输数据量，否则默认scan操作会返回整行所有column family的数据
  拉取完数据之后关闭ResultScanner
  通过 scan 取完数据后，记得要关闭 ResultScanner，否则 RegionServer 可能会出现问题（对应的 Server 资源无法释放）。
  RegionServer的请求处理IO线程数
  较少的IO线程适用于处理单次请求内存消耗较高的Big Put场景（大容量单词Put或设置了较大cache的scan，均数据Big Put）或RegionServer的内存比较紧张的场景。
  较多的IO线程，适用于单次请求内存消耗低，TPS要求（每次事务处理量）非常高的场景。这只该值的时候，以监控内存为主要参考
  在hbase-site.xml配置文件中配置项为hbase.regionserver.handle.count
  Region大小设置
  配置项hbase.hregion.max.filesize，所属配置文件为hbase-site.xml，默认大小是256m。
  在当前RegionServer上单个Region的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的Region。小Region对split和compaction友好，因为拆分Region或compact小Region里的StoreFile速度非常快，内存占用低。缺点是split和compaction会很频繁，特别是数量较多的小Region不同的split，compaction，会导致集群响应时间波动很大，Region数量太多不仅给管理上带来麻烦，设置会引起一些HBase个bug。一般 512M 以下的都算小 Region。大 Region 则不太适合经常 split 和 compaction，因为做一次 compact 和 split 会产生较长时间的停顿，对应用的读写性能冲击非常大。
  此外，大 Region 意味着较大的 StoreFile，compaction 时对内存也是一个挑战。如果你的应用场景中，某个时间点的访问量较低，那么在此时做 compact 和 split，既能顺利完成 split 和 compaction，又能保证绝大多数时间平稳的读写性能。compaction 是无法避免的，split 可以从自动调整为手动。只要通过将这个参数值调大到某个很难达到的值，比如 100G，就可以间接禁用自动 split(RegionServer 不会对未到达 100G 的 Region 做 split)。再配合 RegionSplitter 这个工具，在需要 split 时，手动 split。手动 split 在灵活性和稳定性上比起自动 split 要高很多，而且管理成本增加不多，比较推荐 online 实时系统使用。内存方面，小 Region 在设置 memstore 的大小值上比较灵活，大 Region 则过大过小都不行，过大会导致 flush 时 app 的 IO wait 增高，过小则因 StoreFile 过多影响读性能。
  ​

7.8.4 hbase的集群搭建

hbase集群搭建之前首先完成hadoop集群搭建

  环境搭建
  wget http://mirror.bit.edu.cn/apache/hbase/1.x.y/hbase-1.x.y-bin.tar.gz
  #解压
  tar -xzvf hbase-1.x.y-bin.tar.gz  -C /usr/local/
  #重命名 
  mv hbase-1.x.y hbase
  ​
  ​
  配置环境变量vim /etc/profile
  #内容
  export HBASE_HOME=/usr/local/hbase
  export PATH=$HBASE_HOME/bin:$PATH
  #使立即生效
  source /etc/profile
  ​
  ​
  修改系统变量ulimit
  ulimit -n 10240
  ​
  配置文件
  hbase 相关的配置主要包括hbase-env.sh、hbase-site.xml、regionservers三个文件，都在 /usr/local/hbase/conf目录下面：配置hbase-env.sh
  vim hbase-env.sh
  #内容
  export JAVA_HOME=/usr/lib/jvm/jre-1.7.0-openjdk.x86_64
  export HBASE_CLASSPATH=/usr/local/hbase/conf
  # 此配置信息，设置由hbase自己管理zookeeper，不需要单独的zookeeper。
  export HBASE_MANAGES_ZK=true
  export HBASE_HOME=/usr/local/hbase
  export HADOOP_HOME=/usr/local/hadoop
  #Hbase日志目录
  export HBASE_LOG_DIR=/usr/local/hbase/logs
  ​
  配置 hbase-site.xml
  
      
          hbase.rootdir
          hdfs://hadoop-master:9000/hbase
      
      
          hbase.cluster.distributed
          true
      
      
          hbase.master
          hadoop-master:60000
      
      
          hbase.zookeeper.quorum
          hadoop-master,hadoop-slave1,hadoop-slave2,hadoop-slave3
      
  
  ​
  配置regionservers
  vim /usr/local/hbase/conf/regionservers
  hadoop-master
  hadoop-slave1
  hadoop-slave2
  hadoop-slave3
  ​
  复制hbase到从节点中
  scp -r /usr/local/hbase hadoop-slave1:/usr/local/
  scp -r /usr/local/hbase hadoop-slave2:/usr/local/
  scp -r /usr/local/hbase hadoop-slave3:/usr/local/
  ​
  hbase启动
  ~/hbase/bin/start-hbase.sh
  ​

7.8.5 hbase的管理你有什么看法

  运维任务
  regionserver添加/删除节点 master备份
  1 添加新节点 
  复制hbase目录并进行配置文件修改（regionserver增加新节点）并保持配置文件在全集群一致，在新节点上启动相关进程如hbase-daemon.sh start regionserver命令
  ​
  2 删除节点
  停止相关进程（例如regionserver hbase-daemon.sh stop regionserver），下线节点需注意
  (2-1) 如果负载均衡进程正在执行，请先停止，因为其可能会和master转移region产生竞争
  (2-2) 如果该节点上的数据量很大，移动region的过程可能很漫长
  ​
  3 master备份
  (3-1) 修改配置文件conf/backup-master文件
  (3-2) 启动相关进程 hbase-daemon.sh start master
  ​
  数据迁移
  (1) 导入导出
  HBase的jar包中包含了两个以MapReduce作业形式来导入导出数据的工具，如hadoop jar ${hbase.jar} export ${tablename} ${outputdir
  该工具其余的参数可以做到增量导出、控制导出的数据版本等功能.
  ​
  (2)
  ​
  ​

7.8.6 你用数仓呀，说一下数仓的你们的数据处理，数据流转

  具体数仓甚至数据治理方面可以参考下图
  按照数仓分层思想，分为ods贴源层、dw主题层、mid维表层、dm集市层、app应该层
  过程如下：
  1 数据通过采集或同步落地基于HDFS存储的ods层
  2 主题抽取确认
  3 如果有此需求，构建基于主题数据的微聚合结果
  4 构建维表层数据，如时间、地区、产品类别等数据
  5 进行数据集市构建如统计结果、用户画像、TopN热门数据
  6 进行集市数据的输出到app进行BI可视化展示
  ​

 

7.8.7 你怎么看dws和dm

  dws是基于主题数据做的微聚合，对下游的dm集市数据聚合起到提高计算效率的优化，另外对于其他如用户画像标签表可以做到数据复用的目的。
  dm是集市数据层，主要是针对app应用数据层，包括了统计报表类的结果数据、用户标签表数据及TopN的热门数据（如商品、音乐、聊天话题等）
  ​