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

IOTA架构提出背景

大数据3.0时代以前，Lambda数据架构成为大数据公司必备的架构，它解决了大数据离线处理和实时数据处理的需求。典型的Lambda架构如下：

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

IOTA架构

IOT大潮下，智能手机、PC、智能硬件设备的计算能力越来越强，业务要求数据有实时的响应能力，Lambda架构已经不能适应当今大数据分析时代的需求

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查询，将自动建立