大数据分析的下一代架构--IOTA架构设计实践[下]

版权声明:*************本文为博主原创文章,未经许可不得转载************* https://lidong.blog.csdn.net/article/details/85486500

IOTA架构提出背景

大数据3.0时代以前,Lambda数据架构成为大数据公司必备的架构,它解决了大数据离线处理和实时数据处理的需求。典型的Lambda架构如下:
Lambda架构
Lambda架构的核心思想是:
数据从底层的数据源开始,经过各样的格式进入大数据平台,然后分成两条线进行计算。一条线是进入流式计算平台,去计算实时的一些指标;另一条线进入批量数据处理离线计算平台,去计算T+1的相关业务指标,这些指标需要隔日才能看见。
Lambda优点是稳定、实时和离线计算高峰错开,但是它有一些致命缺点,其缺点主要有:
● 实时与批量计算结果不一致引起的数据口径问题:因为批量和实时计算走的是两个计算框架和计算程序,算出的结果往往不同,经常看到一个数字当天看是一个数据,第二天看昨天的数据反而发生了变化。
● 批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
● 数据源变化都要重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都需要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不够迅速。
● 服务器存储大:数据仓库的典型设计,会产生大量的中间结果表,造成数据急速膨胀,加大服务器存储压力。

IOTA架构

IOT大潮下,智能手机、PC、智能硬件设备的计算能力越来越强,业务要求数据有实时的响应能力,Lambda架构已经不能适应当今大数据分析时代的需求
IOTA架构
IOTA架构的核心概念:
● Common Data Model:贯穿整体业务始终的数据模型,这个模型是整个业务的核心,要保持SDK、Buffer、历史数据、查询引擎保持一致。对于用户数据分析来讲可以定义为“主-谓-宾”或者“对象-事件”这样的抽象模型来满足各种各样的查询。
● Edge SDKs & Edge Servers:这是数据的采集端,不仅仅是过去的简单的SDK,在复杂的计算情况下,会赋予SDK更复杂的计算,在设备端就转化为形成统一的数据模型来进行传送。例如对于智能Wi-Fi采集的数据,从AC端就变为“X用户的MAC 地址-出现- A楼层(2018/4/11 18:00)”这种主-谓-宾结构。对于APP和H5页面来讲,没有计算工作量,只要求埋点格式即可。
● Real-Time Data:即实时数据缓存区。这部分是为了达到实时计算的目的,海量数据接收不可能海量实时入历史数据库,会出现建立索引延迟、历史数据碎片文件等问题。因此,有一个实时数据缓存区来存储最近几分钟或者几秒钟的数据。这块可以使用Kudu或HBase等组件来实现。此处的数据模型和SDK端数据模型是保持一致的,都是Common Data Model。
● Historical Data:历史数据沉浸区,这部分是保存了大量的历史数据,为了实现Ad-hoc查询,将自动建立相关索引提高整体历史数据查询效率,从而实现秒级复杂查询百亿条数据。例如可以使用HDFS存储历史数据,此处的数据模型依然SDK端数据模型是保持一致的Common Data Model。
● Dumper:Dumper的主要工作就是把最近几秒或者几分钟的Realtime Data区的数据,根据汇聚规则、建立索引,存储到历史存储结构Historical Data区中。
● Query Engine:查询引擎,提供统一的对外查询接口和协议(例如SQL),把Realtime Data和Historical Data合并到一起查询,从而实现对于数据实时的Ad-hoc查询。例如常见的计算引擎可以使用Presto、Impala、Clickhouse等。
● Realtime model feedback:通过Edge computing技术,在边缘端有更多的交互可以做,可以通过在Realtime Data去设定规则来对Edge SDK端进行控制,例如,数据上传的频次降低、语音控制的迅速反馈,某些条件和规则的触发等等。

整体思路是设定标准数据模型,通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中,以统一的数据模型贯穿始终,从而提高整体的预算效率,同时满足即时计算的需要,可以使用各种Ad-hoc Query来查询底层数据。

IOTA整体架构引擎实例

在这里插入图片描述

IOTA的特点:

  • 去“ETL”化
  • 高效:时时入库即时分析
  • 稳定:经过易观5.8Pb,5.2亿月活数据锤炼
  • 便捷:支持SQL级别的二次开发和UDAF定义
  • 扩充性强:组件基于Apache开源协议,可支持众多开源存储对接

IOTA架构 — 数据模型 Common Data Model

Common Data Model :
贯穿整体业务始终的核心数据模型,保持SDK、Buffer、历史数据、查询引擎端数据模型一致。
对于用户行为分析业务来讲:
    可以定义为“主-谓-宾”或者“用户-事件”抽象模型来满足各种各样的查询。
例如 :
智能手表:X用户 – 进行了 – 游泳运动
视频APP: X用户 – 播放 – 影片
电商网站:X用户 – 购买 – 手机( 2018/12/11 18:00:00 , IP , GPS)”

IOTA架构 — 数据模型 Common Data Model

用户-事件模型之事件 (Event)

事件(Event)

主要是描述用户做了什么事情,记录用户触发的行为,例如注册、登录、支付事件等等

事件属性

更精准的描述用户行为,例如事件发生的位置、方式和内容
每一条event数据对应用户的一次行为信息, 例如浏览、登录、搜索事件等等。
在这里插入图片描述
具体请参考易观方舟文档关于数据模型的说明:https://ark.analysys.cn/docs/integration-data-model.html

用户-事件模型之用户 (Profile)

用户这里没有太多要说的,要提醒注意唯一标识这块
唯一标识

方舟的事件模型中,数据上报时会有用户这个实体,使用 who 来进行标识,在登录前匿名阶段,who 中会记录一个 匿名 ID ,登录后会记录一个注册 ID。

1.1 匿名 ID
匿名 ID 用来在用户主体未登录应用之前标识,当用户打开集成有方舟 SDK 的应用时,SDK 会给其分配一个 UUID 来做为匿名 ID 。
当然,方舟也提供了给用户主体设置匿名 ID 的方式,比如可以使用设备 ID ( iOS 的 IDFA/IDFV,Web 的 Cookie 等)。

1.2 注册 ID
通常是业务数据库里的主键或其它唯一标识,注册 ID 是更加精确的用户 ID,但很多应用不会用注册 ID,或者用户使用一些功能时是在未登录的状态下进行的,此时,就不会有注册 ID。
另外,在方舟系统中,我们以为用户主体来进行分析,这个用户主体可能是一个人,一个帐号,也可能是一个家电,一辆汽车。具体以什么做为用户主体,要根据用户实际的业务场景来决定。

1.3 distinct_id
即使有了who( 注册 ID / 匿名 ID),实际使用中也会存在注册用户匿名访问等情况,所以需要一个唯一标识将用户行为贯穿起来,distinct_id 就是在who 的基础上根据一些规则生成的唯一 ID。

IOTA架构 — 数据流转过程

iota数据架构数据流转过程

IOTA架构 — 数据采集(Ingestion)

数据采集

在这里插入图片描述
数据采集要注意:

传输加密
策略控制
		
	服务器可以随时更改发发送策略,比如发送频率调整,重试频率

	发送策略优先级: 服务器策略>debug>用户设置>启动、间隔策略

	服务器约束示例 

服务器端返回示意:
在这里插入图片描述

IOTA架构 — 数据缓冲区(Real-Time Data)

Real-Time Data区是数据缓冲区,当从Kafka消费完数据首先落入Buffer区,这样设计主要是因为目前主流存储格式都不支持实时追加(Parquet、ORC)。Buffer区一般采用HBase、Kudu等高性能存储,考虑到成熟度、可控、社区等因素,我们采用HBase。
在这里插入图片描述

  • HBase的特点:
    – 主键查询速度快
    – Scan性能慢

  • 如何解决Scan性能:-- In-memory
    – Snappy压缩
    – 动态列族
    – 只存一定量的数据
    – Rowkey设计hash
    – hfile数据转换成OrcFile

IOTA架构 — 历史存储区(Historical data storage)

当HBase里的数据量达到百万规模时,调度会启动DumpMR(Spark、MR任务)会将HBase数据flush到HDFS中去,因为还要支持数据的实时查询,我们采用R/W表切换方案,即一直写入一张表直到阈值,就写入新表,老表开始转为ORC格式。
HDFS高效存储:

	按天分区
	基于用户ID,事件时间排序
	冷热分层
	Orc存储
	BloomFilter 
	稀疏索引
	Snappy压缩

小文件问题:

	不按事件分区
	MergerMR定时合并小文件

稀疏索引:
在这里插入图片描述
数据有序:
在这里插入图片描述

IOTA架构 — 即时查询引擎(Query Engine)

因为需支持从历史到最近一条数据的即时查询,查询引擎需要同时查HBase缓冲区里和历史存储区的数据,采用View视图的方式进行查询。

Query Engine基于Presto进行二次开发
  • HBase-Connector定制开发、优化
  • 通过视图View建立热数据与历史数据的联合计算
  • Session,漏斗,留存,智能路径等模型的算法实现
    在这里插入图片描述
    关于olap引擎测评请参考:
    http://geek.analysys.cn/topic/21 开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum)

IOTA架构 — 调度(EasyScheduler)

整个数据处理流程都离不开一个组件 – 调度。
考虑调度易用性、可维护性及方便二次开发等综合原因,我们开发了自己的大数据分布式调度系统EasyScheduler。

EasyScheduler(易调度) 主要解决数据研发ETL 错综复杂的依赖关系,而不能直观监控任务健康状态等问题。EasyScheduler以DAG流式的方式将Task组装起来,
可实时监控任务的运行状态,同时支持重试、从指定节点恢复失败、暂停及Kill任务等操作。
在这里插入图片描述
更多关于调度的信息:
https://blog.csdn.net/oDaiLiDong/article/details/84994247

IOTA架构 — 优化策略

在这里插入图片描述

IOTA架构 — 优化经验

1、添加布隆过滤器,TPC-DS有50%-80%性能提升

2、全局 + 局部字典,尽量整型,避免过长字符串,数倍性能提升
如:事件名称使用id,查询速度提升近1倍

3、数据缓存Alluxio使用,2~5倍性能提升

4、SQL优化,耗时sql优化非常重要

5、Unsafe调用。Presto里开源Slice的使用

IOTA架构 — 前进方向

天下武功唯快不破!
在这里插入图片描述

1、数据本地化,尽量避免shuffle调用

2、更合适的索引构建,如bitmap索引

3、堆外内存的使用,避免GC问题
在这里插入图片描述

更多关于IOTA架构的交流请加我微信,加我时请注明公司+职位+IOTA,谢谢:
在这里插入图片描述

展开阅读全文

没有更多推荐了,返回首页