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 高可用数据接入架构设计
4: 工业级数据质量管理
数据异常如果由客户方发现的而不是你, 那么它带来的负面影响会超过你之前做的所有业务带来的正面影响.
规则引擎(通用模板建立)
数据落地监控
数据掉 0 监控: 实际扩展一下就是数据量阈值监控, 少于某个量就告警
重复数据监控: 很多表一定要监控重复数据的, 这点至关重要.
关键指标监控
数据同比环比监控
数据对账 Kafka 数据落地, 必须要有一个监控机制来知道我们的数据落地情况, 离线数据同样需要数据对账, 对账方法有很多, 比如可以和业务库来对比.
性能监控
查询性能, 比如 es 的某个索引, 在不同时间段的查询响应速度, 同理 presto,hive,kylin 这些的查询都需要注意一下, 这点可以通过任务监控来观察.
数据读写影响, 机器故障影响, 在写入数据的时候其实会影响读数据的, 需要监控一下, 并做相应调整.
数据质量 4 要素 数据质量的评估, 可以从完整性, 准确性, 一致性和及时性来考虑.
5: Kylin+BI 平台的高可用系统架构设计
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: 工业数据查询平台的架构优化(数据库集群方案优化)
来源: https://juejin.im/post/5c2ef817518825258004fcc6