大数据分析的下一代架构

  • 时间:
  • 浏览:0

Common Data Model :

贯穿整体业务始终的核心数据模型,保持SDK、Buffer、历史数据、查询引擎端数据模型一致。

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

1.2 注册 ID

通常是业务数据库里的主键或其它唯一标识,注册 ID 是更加精确的用户 ID,但所以 应用不不用注册 ID,机会用户使用所以功能时是在未登录的情況下进行的,此时,就不不有注册 ID。

另外,在方舟系统中,大家以为用户主体来进行分析,并不是 用户主体机会是另另两被委托人,另另一个帐号,也机会是另另一个家电,一公里汽车。具体以哪几种做为用户主体,要根据用户实际的业务场景来决定。

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

更多关于IOTA架构的交流请加我微信,加我时请注明公司+职位+IOTA,谢谢:

机会需支持从历史到最近十根数据的即时查询,查询引擎可不都后能 共同查HBase缓冲区里和历史存储区的数据,采用View视图的办法进行查询。

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

1.3 distinct_id

即使有了who( 注册 ID / 匿名 ID),实际使用中也会居于注册用户匿名访问等情況,所以 可不都后能 另另一个唯一标识将用户行为贯穿起来,distinct_id 所以 在who 的基础上根据所以规则生成的唯一 ID。

2、全局 + 局部字典,尽量整型,处理过长字符串,数倍性能提升

如:事件名称使用id,查询速率单位提升近1倍

服务器端返回示意:

1、数据本地化,尽量处理shuffle调用

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

唯一标识

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

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

EasyScheduler(易调度) 主要处理数据研发ETL 复杂性性的依赖关系,而不到直观监控任务健康情況等大大问题。EasyScheduler以DAG流式的办法将Task组装起来,

可实时监控任务的运行情況,共同支持重试、从指定节点恢复失败、暂停及Kill任务等操作。

1、打上去布隆过滤器,TPC-DS有400%-400%性能提升

稀疏索引:

大数据3.0时代然后 ,Lambda数据架构成为大数据公司必备的架构,它处理了大数据离线处理和实时数据处理的需求。典型的Lambda架构如下:

更精准的描述用户行为,累似 事件居于的位置、办法和内容

每十根event数据对应用户的一次行为信息, 累似 浏览、登录、搜索事件等等。

小文件大大问题:

主所以 描述用户做了哪几种事情,记录用户触发的行为,累似 注册、登录、支付事件等等

Real-Time Data区是数据缓冲区,当从Kafka消费完数据首先落入Buffer区,原来设计主所以 机会目前主流存储格式全部都是支持实时追加(Parquet、ORC)。Buffer区一般采用HBase、Kudu等高性能存储,考虑到心智性性成熟的句子是什么是什么 度、可控、社区等因素,大家采用HBase。

关于olap引擎测评请参考:

http://geek.analysys.cn/topic/21 开源OLAP引擎测评报告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum)

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端进行控制,累似 ,数据上传的频次降低、语音控制的好快了 了 反馈,所以条件和规则的触发等等。

2、更最少的索引构建,如bitmap索引

1.1 匿名 ID

匿名 ID 用来在用户主体未登录应用然后 标识,当用户打开集成有方舟 SDK 的应用时,SDK 会给其分配另另一个 UUID 来做为匿名 ID 。

当然,方舟也提供了给用户主体设置匿名 ID 的办法,比要怎样不都后能 使用设备 ID ( iOS 的 IDFA/IDFV,Web 的 Cookie 等)。

更多关于调度的信息:

https://blog.csdn.net/oDaiLiDong/article/details/84994247

Lambda架构的核心思想是:

数据从底层的数据源然后 刚开使了了,经过各样的格式进入大数据平台,但会 分成两条线进行计算。十根线是进入流式计算平台,去计算实时的所以指标;另十根线进入批量数据处理离线计算平台,去计算T+1的相关业务指标,哪几种指标可不都后能 隔日可不都后能 看见。

Lambda优点是稳定、实时和离线计算高峰错开,但会 它有所以致命缺点,其缺点主要有:

● 实时与批量计算结果不一致引起的数据口径大大问题:机会批量和实时计算走的是另另一个计算框架和计算程序,算出的结果往往不同,另一直 看一遍另另一个数字当天看是另另一个数据,第二天看昨天的数据反而居于了变化。

● 批量计算在计算窗口内无法完成:在IOT时代,数据量级没得大,另一直 发现夜间不到4、一个小时的时间窗口,机会无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的大大问题。

● 数据源变化全部都是重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都可不都后能 针对ETL和Streaming做开发修改,整体开发周期很长,业务反应严重不足好快了 了 。

● 服务器存储大:数据仓库的典型设计,会产生血块的顶端结果表,造成数据迅疾膨胀,加大服务器存储压力。

数据有序:

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

3、堆外内存的使用,处理GC大大问题

当HBase里的数据量达到百万规模时,调度会启动DumpMR(Spark、MR任务)会将HBase数据flush到HDFS中去,机会可不都后能 支持数据的实时查询,大家采用R/W表切换方案,即另一直 写入一张表直到阈值,就写入新表,老表然后 刚开使了了转为ORC格式。

HDFS高效存储:

数据采集要注意:

整个数据处理流程都离不开另另一个组件 – 调度。

考虑调度易用性、可维护性及方便二次开发等综合是因为,大家开发了被委托人的大数据分布式调度系统EasyScheduler。

天下武功唯快不破!

-- 动态列族

-- 只存血块的数据

-- Rowkey设计hash

-- hfile数据转打上去OrcFile

-- Scan性能慢