工业级数仓分层及高并发松耦合大数据平台架构深刻剖析-DW商业环境实战

版权声明：本套技术专栏是做者（秦凯新）平时工做的总结和升华，经过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。QQ邮箱地址：1120746959@qq.com，若有任何技术交流，可随时联系。

1：数据分层重要性

• 屏蔽业务的影响，没必要改一次业务就须要从新接入数据（进行业务解耦）。

• 减小重复开发，开发一些通用的中间层数据，可以减小极大的重复计算（抽取通用数据，造成维度）

• 一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。并且便于维护数据的准确性，当数据出现问题以后，能够不用修复全部的数据，只须要从有问题的步骤开始修复。（数据分层开发以及有步骤修复）

• 清晰数据结构：每个数据分层都有它的做用域，这样咱们在使用表的时候能更方便地定位和理解。（STAGE ，ODS ，DWD，DWS做用域各司其职）

2：工业级数据仓库分层规划与质量监控

优雅地把数据DWD层和轻度汇总层放在同一个层级上，同时独立出来了维表和临时表。

• STAGE 层（与业务系统数据保持一致，多数据源的临时存储） STAGE 层做为数据缓冲层，主要负责采集不一样类型的业务系统数据并保存必定期限内的相关业务数据，完成不一样类型数据源的统一临时存储，同时避免 ETL 操做对业务系统性能形成影响，STAGE 层数据在数据结构、数据之间的逻辑关系上都与业务系统基本保持一致。

• ODS 数据层（与业务系统数据保持一致，进行数据清洗及规范化，保证不一样源数据的最终数据一致性，获得业务要求的指标数据表） ODS（Operational Data Store）层数据来源于 STAGE 层，它的数据通过了对 STAGE 层数据的清洗，包括编码表去重、去空、垃圾数据过滤、数据类型规则化等。

• DWD 数据层（添加代理键，造成关联体系，可单独对外提供查询服务） 把 ODS 数据表结构改变成项目主题数据仓库的表结构，对 DWD 层的全部表添加了代理键，标准化了业务系统编码类型不统一的问题，创建了数据仓库维度表和事实表的关联体系，也为缓慢变化维的实现奠基了基础。

• DWS：轻度汇总层（数据汇总，可与DWD进行并行存在） DWS：轻度汇总层，从ODS层中对用户的行为作一个初步的汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度作一些统计值，好比用户每一个时间段在不一样登陆ip购买的商品数等。这里作一层轻度的汇总会让计算更加的高效，在此基础上若是计算仅7天、30天、90天的行为的话会快不少。咱们但愿80%的业务都能经过咱们的DWS层计算，而不是ODS。

  ODS -> DWS: 不必通过 dwd。我举个例子，你的浏览商品行为，我作一层轻度汇总，就直接放在 dws 了

  DWD -> DWS: 若是所须要的资料表，要从好多表凑成一份，咱们从四五份我的资料表中凑出来了一份完整的资料表放在了 dwd 中。而后在 app 层，咱们要出一张画像表，包含用户资料和用户近一年的行为，咱们就直接从dwd中拿资料， 而后再在 dws 的基础上作一层统计，就成一个app表了。固然，这不是绝对，dws 和 dwd 有没有依赖关系主要看有没有这种需求。

• DWC 数据层（数据推送到业务系统，如经过消息队列进行解耦） DWC（Data Warehouse Center）层主要管理固化报表的数据存储，数据主要来源于 DWD 层，根据前台所需数据创建物理模型，使用 ETL 抽取 DWD 层数据推送给 DWC 层，这样显著减小前台应用直接关联 DWD 层查询明细数据的成本，提升平台数据获取的速度。

• TMP：临时表（临时表关联） TMP每一层的计算都会有不少临时表，专设一个DWTMP层来存储咱们数据仓库的临时表。

• DM 数据层（数据主题） DM（Data Mart）层即数据集市，将指标与维度创建物理模型组成数据集市，这是 OLAP 的数据基础。该层实现了合并不一样系统的数据源来知足面向主题的业务需求，它的建模是终端用户驱动的，也是由业务需求驱动的。按主题，维度及 KPI 指标对 DM 层进行模型设计、建模，DM 层数据是将 DWD 层数据进行进一步整合、转换、汇总、计算等 ETL 操做处理获取的。

3 工业级数仓平台承载千万级别流量架构

3.1 设计准则

• 摒弃Mysql数据库集群（线上8主8从，32核+128G+SSD固态硬盘）承载高并发数据接入。
• 计算与存储分离，层次要清晰。
• kv存储对高并发的支撑能力至少是MySQL的数倍甚至数十倍，好比Redis每秒承载几万并发，Hbase高性能的读取和写入性能。
• Spark SQL计算引擎的深刻使用。
• MQ削峰填谷以及流量控制，减轻kv存储存储压力。
• Spark 的广播变量的使用以及cache静态数据缓存。
• MQ消费者流量控制系统重点实现数据校验、过滤无效数据、切分数据分片、数据同步的幂等机制、100%保证数据落地到kv集群的机制保障

3.2 高并发数据接入架构设计

3.3 高可用工业数据接入架构设计

• 异步转同步 ->限流算法 ->选择性丢弃流量
• 开启限流开关 –> 临时扩容Spark Slave集群 -> hash算法分发数据->小时级粒度(磁盘+内存双存储)
• 计算任务重分配 + 主备切换机制+YARN资源Fair队列调度（或K8s集群资源调度）
• 缓存集群AutoLoadCache 解决方案+ JVM本地缓存 + 限流机制
• 冷数据高频查询缓存（T+1模式下离线日志高频用户分析 ）
• MQ要求消费者配置副本机制和Ack应答机制。
• MQ要求在高并发状况下，须要考虑千兆带宽和万兆带宽对集群规模的规划。
• MQ要求在执行限流操做时，还须要考虑数据持久性对集群规模的规划。

4: 工业级数据质量管理

数据异常若是由客户方发现的而不是你，那么它带来的负面影响会超过你以前作的全部业务带来的正面影响。

• 规则引擎（通用模板创建）

1. 数据落地监控
2. 数据掉0监控：实际扩展一下就是数据量阈值监控，少于某个量就告警
3. 重复数据监控：不少表必定要监控重复数据的，这点相当重要。
4. 关键指标监控
5. 数据同比环比监控

• 数据对帐 Kafka数据落地，必需要有一个监控机制来知道咱们的数据落地状况，离线数据一样须要数据对帐，对帐方法有不少，好比能够和业务库来对比。

• 性能监控

1. 查询性能，好比es的某个索引，在不一样时间段的查询响应速度，同理presto、hive、kylin这些的查询都须要注意一下，这点能够经过任务监控来观察。
2. 数据读写影响，机器故障影响，在写入数据的时候其实会影响读数据的，须要监控一下，并作相应调整。

• 数据质量4要素 数据质量的评估，能够从完整性、准确性、一致性和及时性来考虑。

5: Kylin+BI平台的高可用系统架构设计

• Kylin 可扩展: 指能够对其主要依赖的三个模块作任意的扩展和替换，Kylin 的三大依赖模块分别是数据源（Hive）、构建引擎（MR）和存储引擎（HBase）

• Layered Cubing构建算法: 四维 Cube 须要五轮的 MapReduce 来完成：第一轮 MR 的输入是源数据，这一步会对维度列的值进行编码，并计算 ABCD 组合的结果。接下来的 MR 以上一轮的输出结果为输入，向上聚合计算三个维度的组合：ABC、BCD、ABD和ACD；依此类推，直到算出全部的维度组合。问题是不能充分利用系统的资源以及缓存中间计算结果，存在shuffle过程，重点是稳定

• Fast Cubing 构建算法：最大化利用 Mapper 端的 CPU 和内存，对分配的数据块，将须要的组合全都作计算后再输出给 Reducer；由 Reducer 再作一次合并（Merge），从而计算出完整数据的全部组合。配置方式kylin_job_conf_inmem.xml，包含了 MR 任务的配置项，当 Cube 构建算法是 Fast Cubing 时，会根据该文件的设置调整构建任务中的 MR 参数

• 调优必填项：

  #KYLIN配置
       kylin.query.force-limit 默认是没有限制，推荐设置为 1000；
       kylin.storage.hbase.hfile-size-gb 能够设置为 1，有助于加快 MR 速度；
       kylin.storage.hbase.min-region-count 能够设置为 HBase 节点数，强制数据分散在 N 个节点；
       kylin.storage.hbase.compression-codec 默认没有进行压缩，推荐在环境运行状况下配置压缩算法。
  
       #Hadoop配置
       yarn.nodemanager.resource.memory-mb 配置项的值不小于 8192MB
       yarn.scheduler.maximum-allocation-mb 配置项的值不小于 4096MB
       mapreduce.reduce.memory.mb 配置项的值不小于 700MB
       mapreduce.reduce.java.opts 配置项的值不小于 512MB
       yarn.nodemanager.resource.cpu-vcores 配置项的值不小于 8
       
       //运行在yarn-cluster模式，固然能够配置为独立 Spark 集群：spark://ip:7077
       kylin.engine.spark-conf.spark.master=yarn
       kylin.engine.spark-conf.spark.submit.deployMode=cluster 
       
       //启动动态资源分配
       kylin.engine.spark-conf.spark.dynamicAllocation.enabled=true
       kylin.engine.spark-conf.spark.dynamicAllocation.minExecutors=2
       kylin.engine.spark-conf.spark.dynamicAllocation.maxExecutors=1000
       kylin.engine.spark-conf.spark.dynamicAllocation.executorIdleTimeout=300
       kylin.engine.spark-conf.spark.shuffle.service.enabled=true
       kylin.engine.spark-conf.spark.shuffle.service.port=7337
       
       //内存设置
       kylin.engine.spark-conf.spark.driver.memory=2G
       
       //数据规模较大或者字典较大时，调大 executor 内存
       kylin.engine.spark-conf.spark.executor.memory=8G 
       kylin.engine.spark-conf.spark.executor.cores=4
       //心跳超时
       kylin.engine.spark-conf.spark.network.timeout=600
       //分区大小
       kylin.engine.spark.rdd-partition-cut-mb=100
  复制代码

• Count_Distinct 度量：

  近似实现：基于 HyperLogLog 算法，可接受的错误率（从9.75% 到 1.22%），低错误率须要更多存储；
    精确实现：基于 Bitmap（位图）算法，对于数据型为 tinyint、smallint 和 int 的数据，
              将把数据对应的值直接打入位图；对于数据型为 long，string 和其余的数
              据，将它们编码成字符串放入字典，而后再将对应的值打入位图。
              返回的度量结果是已经序列化的位图数据，而不只是计算的值。
  复制代码

• EXTEND_COLUMN 优化设置，解决存在对某个 id 进行过滤，但查询结果要展现为 name 的状况。

• 聚合组（Aggregation Group）

• 必要维度（Mandatory Dimension）

• 层级维度 （Hierachy Dimension）

• 联合维度（Joint Dimension）

• Rowkeys编码，推荐的顺序为：Mandatory 维度、where 过滤条件中出现频率较多的维度、高基数维度、低基数维度。这样作的好处是，充分利用过滤条件来缩小在 HBase 中扫描的范围，从而提升查询的效率

  dict：适用于大部分字段，默认推荐使用，但在超高基状况下，可能引发内存不足的问题；
    boolean：适用于字段值为true, false, TRUE, FALSE, True, False, t, f, T, F, yes, no, YES, NO, Yes, No, y, n, Y, N, 1, 0；integer：适用于字段值为整数字符。
    date：适用于字段值为日期字符，支持的格式包括yyyyMMdd、yyyy-MM-dd、yyyy-MM-dd HH:mm:ss、yyyy-MM-dd HH:mm:ss.SSS，其中若是包含时间戳部分会被截断；
    fix_length：适用于超高基场景，将选取字段的前 N 个字节做为编码值，当 N 小于字段长度，会形成字段截断
  复制代码

• ShardBy 设置：建议选择基数较大的列做为 ShardBy 列，以使得数据能够均匀分布；

5.1 单节点部署模式

5.2 集群部署模式

Kylin 实例是无状态的服务，运行时的状态信息存储在 HBase metastore 中。 出于负载均衡的考虑，您能够启用多个共享一个 metastore 的 Kylin 实例，使得各个节点分担查询压力且互为备份，从而提升服务的可用性。

Kylin 集群模式部署 若是您须要将多个 Kylin 节点组成集群，请确保他们使用同一个 Hadoop 集群、HBase 集群。而后在每一个节点的配置文件 $KYLIN_HOME/conf/kylin.properties 中执行下述操做：

• 配置相同的 kylin.metadata.url 值，即配置全部的 Kylin 节点使用同一个 HBase metastore。
• 配置 Kylin 节点列表 kylin.server.cluster-servers，包括全部节点（包括当前节点），当事件变化时，接收变化的节点须要通知其余全部节点（包括当前节点）。
• 配置 Kylin 节点的运行模式 kylin.server.mode，参数值可选 all, job, query 中的一个，默认值为 all。 job 模式表明该服务仅用于任务调度，不用于查询；query 模式表明该服务仅用于查询，不用于构建任务的调度；all 模式表明该服务同时用于任务调度和 SQL 查询。
• 注意：默认状况下只有一个实例用于构建任务的调度 （即 kylin.server.mode 设置为 all 或者 job 模式）。

• 任务引擎高可用 从 v2.0 开始, Kylin 支持多个任务引擎一块儿运行，相比于默认单任务引擎的配置，多引擎能够保证任务构建的高可用。

• 使用多任务引擎，你能够在多个 Kylin 节点上配置它的角色为 job 或 all。为了不它们之间产生竞争，须要启用分布式任务锁，请在 kylin.properties 里配置：

  kylin.job.scheduler.default=2
    kylin.job.lock=org.apache.kylin.storage.hbase.util.ZookeeperJobLock
  复制代码

5.3 读写分离部署模式

• 经过架构图能够看到Kylin会访问两个集群的HDFS，建议两个集群的NameService务必不能相同，尤为是集群启用NameNode HA时，相同的NameService会致使组件在跨集群访问HDFS时因没法区分NameService而出现问题。
• 搭建两个Hadoop环境当作Hadoop集群，一个集群部署HDFS、Hive、MR、YARN做为计算集群，负责Cube构建。一个集群部署HDFS、YARN、HBase负责Cube存储。

  

53.4 备份Kylin的元数据

• 从Kylin的配置文件kylin.properties中查看到：

  ## The metadata store in hbase
        kylin.metadata.url=kylin_metadata@hbase
        表示Kylin的元数据被保存在HBase的kylin_metadata表中
  复制代码

• 备份Kylin的元数据

  /bin/metastore.sh backup
        这将备份元数据到本地目录KYLIN_HOME/metadata_backps下面，目录的命名格式为：
        KYLIN_HOME/meta_backups/meta_year_month_day_hour_minute_second
        好比个人Kylin的家目录为/var/lib/kylin/kylin，那么备份数据的目录为：
        /var/lib/kylin/kylin/meta_backups/meta_2018_01_04_11_50_32
  复制代码

• 恢复元数据

  首先reset当前Kylin的元数据存储，这将清理掉全部存储在HBase中的Kylin元数据，确保在此以前作过备份。

  ./bin/metastore.sh reset
  复制代码

  上传备份的元数据到Kylin的元数据中

  ./bin/metastore.sh restore$KYLIN_HOME/meta_backups/meta_xxxx_xx_xx_xx_xx_xx 
  复制代码

• 从Kylin元数据中清理掉无用的资源

  （1）首先，执行检查，这是安全的操做，不会修改任何内容：
    ./bin/metastore.sh clean
    将须要被删除的资源(resources)罗列出来
    
    （2）添加“--delete true”参数，这样就会清理掉哪些无用的资源。
        切记，在这个命令操做以前，必定要备份Kylin元数据： 
    ./bin/metastore.sh clean --delete true
  复制代码

5.5: 工业数据计算平台与业务系统解耦设计

• 消息中间件削峰填谷

• 手动流量开关配合数据库运维操做

• 多系统同时订阅数据（广播模式fanout）

• 实时数据计算限流控制，把消息系统做为数据存储中间引擎，经过设置不一样的消费速度进行数据的流入管控。

6:工业数据查询平台的架构优化（数据库集群方案优化）

版权声明：本套技术专栏是做者（秦凯新）平时工做的总结和升华，经过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。QQ邮箱地址：1120746959@qq.com，若有任何技术交流，可随时联系。

6.1 纯MySQL分库分表及冷热数据存储弊端

• 若是彻底用MySQL数据库集群方案来承载是很不靠谱的，数据量是不断增长，并且增速很快，天天都新增几千万，再强悍的分库分表方案都是不合适的。
• 为对冷数据的查询，通常都是针对大量数据的查询，好比用户会选择过去几个月，甚至一年的数据进行分析查询，此时若是纯用MySQL一定是灾难性的。

6.2 查询平台数据存储优化（冷热数据分层）

6.2.1 冷数据的查询基本都是200毫秒之内的响应速度

• 冷数据所有采用ES+HBase来进行存储，ES中主要存放要对冷数据进行筛选的各类条件索引，好比日期以及各类维度的数据，而后HBase中会存放全量的数据字段。

6.2.2 热数据实现负载高并发的每秒十万级别的查询，

• 热数据缓存(Redis及Codis)集群（优先查询缓存）。
• 热数据数据库集群（其次查询），主库与从库同步，分库分表方案，实现基于Mysql热数据查询。

• 90%以上的高并发查询都走缓存集群，剩下10%的查询落地到数据库集群

7 工业领域数据分析业务模型

• 车辆热区分布
• 车辆行驶区域模型
• 充电区域模型
• 车辆补贴预测计算
• 每一辆车辆闲置率计算排序
• 单台车按月进行运行强度计算，进行多月份对比展现
• 全部车辆进行运行强度排序，辅助调度。
• 每一辆上个月天天平均行驶里程
• 每一辆车上个月总运行天数
• 维保预测
• 每一台车每月总耗电量成本（充电），结合运营商力度，评估电池性能
• 每一台车平均天天的耗电量
• 每一台车综合质量系数 = 1/月综合故障次数
• 每一台车百千米耗电量
• 每一台车综合成本系数 =上个月百千米回馈电量/上个月最高百千米回馈电量
• 汽车载重分布、满载率分布
• 车速分布统计和经济性驾驶分析

8 总结

工业级大数据平台的系统要求很是高，对于高并发的场景犹如屡见不鲜，这也是我为何花费大量笔墨来解析我主导的工业大数据仓库的主要缘由，到目前为止，这个架构是我最成功的平台案例。包含了几乎主流的大数据组件。固然还有Kylin，今天收到Kylin团队的邀请，但愿将来可以为国产的优秀开源项目作一点贡献。

版权声明：本套技术专栏是做者（秦凯新）平时工做的总结和升华，经过从真实商业环境抽取案例进行总结和分享，并给出商业应用的调优建议和集群环境容量规划等内容，请持续关注本套博客。QQ邮箱地址：1120746959@qq.com，若有任何技术交流，可随时联系。

秦凯新 于深圳