基于Flume+Kafka+Hbase+Flink+FineBI的实时综合案例(一)案例需求

Flume+Kafka+Hbase+Flink+FineBI的实时综合案例

01：课程回顾

Hbase如何解决非索引查询速度慢的问题？

原因：Hbase以Rowkey作为唯一索引

现象：只要查询条件不是Rowkey前缀，不走索引

解决：构建二级索引

思想：自己建rowkey索引表，通过走两次索引来代替全表扫描

步骤

• step1：根据自己查询条件找到符合条件的原表的rowkey
• step2：根据原表rowkey去原表检索

问题：不同查询条件需要不同索引表，维护原表数据与索引数据同步问题

解决

方案一：手动管理：自己建表、自己写入数据【原表、索引表】

方案二：自己开发协处理器：协处理器的开发成本非常高

方案三：第三方工具：Phoenix

create [local] index indexName on tbname(Col) [include(col)]

• a.自动构建索引表/列族
• b.自动对原表中的数据构建索引，自动把索引数据同步到索引表
• c.自动维护中间所有过程

Phoenix支持哪几种索引，各自的区别和实现原理是什么？

索引设计：加快查询的效率

全局索引

create index 

• 索引表来实现
  • rowkey：查询条件+原表rowkey
  • col：x【占位】
• 过程：先查询索引表，从索引中查找满足条件的rowkey，再拿rowkey到原表查询结果
• 场景：写少读多
• 实现：先拦截写原表的请求，先写索引表，再去写原表
• 问题：查询的数据都在原表中，必须到原表拿数据，性能相对比较差

覆盖索引：基于全局索引

create index …… include

• 索引表来实现
  • rowkey：查询条件+原表rowkey
  • col：x【占位】
  • col……：经常作为查询结果要返回的列
• 过程：根据查询条件，直接从索引表返回，不再查询原表
• 场景：写少读多
• 实现：先拦截写原表的请求，先写索引表，再去写原表
• 问题：写的性能受到了较大影响

本地索引

create local index 

• 将索引与数据存储在原表中，索引用一个单独的列族来存储
  • rowkey：这条数据所在Region的StartKey + 查询条件 + 数据的rowey
• 过程：必须加载全部索引来进行索引查询，牺牲了一定读的性能
• 场景：写多读多
• 实现：在写入数据时，直接通过协处理器将数据和数据的索引写入原表的同一个region中
• 特点：数据侵入性比较高，所有读写都基于Phoenix进行读写，盐表不能使用本地索引

函数索引：一般不用

02：课程目标

• 目标
  • 每种存储对应的应用场景：MySQL、HDFS、HIve、Redis、Hbase、Kafka
  • 如何实现不同存储设计和开发
    • Hbase设计 + Hbase Java API
    • Kafka API
• 架构
  • 实时采集：Flume + Kafka
  • 实时存储：Kafka
  • 离线存储：Hbase
  • 离线计算：Hive 、Phoenix
  • 实时计算：Flink
  • 实时报表：FineBI
• 要求
  • 所有环节自己实现一遍
  • 自己设计，自己写代码

03：案例需求

目标：了解案例的背景及需求

路径

• step1：案例背景
• step2：整体目标
• step3：具体需求

实施

案例背景

image-20210905125503124

社交软件每天都有数千万的用户进行聊天, 陌陌、微信、脸书等公司想要对这些用户的聊天记录进行存储，满足用户的所有查询浏览以及后台需要对每天的消息量进行实时统计分析, 请设计如何实现数据的存储以及实时的数据统计分析工作。

整体目标

• 选择合理的存储容器进行数据存储, 并让其支持即席查询与离线分析工作

具体需求

• 离线分析：满足离线统计分析与即时查询
  • 根据发件人id + 收件人id + 消息日期 查询聊天记录
  • |
  • Rowkey设计
• 实时分析
  • 实时统计消息总量
  • 实时统计各个地区发送消息的总量
  • 实时统计各个地区接收消息的总量
  • 实时统计每个用户发送消息的总量
  • 实时统计每个用户接收消息的总量
  • |
  • 指标：消息总个数
  • 维度：时间 、地区、用户、消息类型

小结

• 了解案例的背景及需求