2019-07-16 23:11:00 sinat_28007043 阅读数 153
  • 使用Apache Kylin搭建企业级开源大数据分析平台

    1024大数据技术峰会邀请到11位来自一线互联网企业的大数据核心研发团队骨干成员,针对选型开源技术搭建大数据平台、持续运维、优化提升大数据平台的各项性能,技术架构演进以及实现应用大数据支持业务创新发展,这几大核心展开深入的分享和交流。

    6534 人正在学习 去看看 互联网技术联盟

1. 五种主流的大数据架构

收集各大互联网公司大数据平台架构

1. 酷狗音乐的大数据平台架构:

https://www.infoq.cn/article/kugou-big-data-platform-restructure

 

2. 滴滴大数据离线和实时平台架构和实践:

https://myslide.cn/slides/15307

 

 3. 美图大数据平台lamda架构:

 https://www.infoq.cn/article/QycsTZSz0REAFTgmh_J0

 

持续更新中......

 

2019-12-23 09:48:15 An1090239782 阅读数 75
  • 使用Apache Kylin搭建企业级开源大数据分析平台

    1024大数据技术峰会邀请到11位来自一线互联网企业的大数据核心研发团队骨干成员,针对选型开源技术搭建大数据平台、持续运维、优化提升大数据平台的各项性能,技术架构演进以及实现应用大数据支持业务创新发展,这几大核心展开深入的分享和交流。

    6534 人正在学习 去看看 互联网技术联盟

基于HBase和Spark构建企业级数据处理平台

[基于HBase和Spark构建企业级数据处理平台]:阿里云数据库 李伟(沐远) PPT 演讲稿

1.1 一站式数据处理平台架构

在这里插入图片描述

1.2 典型业务场景

1.2.1 爬虫+搜索引擎

在这里插入图片描述

1.2.2 大数据风控系统

在这里插入图片描述

1.2.3 构建数据仓库(推荐、风控)

在这里插入图片描述

2019-05-16 17:44:22 haohaizijhz 阅读数 1629
  • 使用Apache Kylin搭建企业级开源大数据分析平台

    1024大数据技术峰会邀请到11位来自一线互联网企业的大数据核心研发团队骨干成员,针对选型开源技术搭建大数据平台、持续运维、优化提升大数据平台的各项性能,技术架构演进以及实现应用大数据支持业务创新发展,这几大核心展开深入的分享和交流。

    6534 人正在学习 去看看 互联网技术联盟
数据平台层级架构图

 

主流数据平台架构

一般包含三个层级,ODS层、数据仓库层、数据应用层。

业务系统的操作和日志数据抽取到ODS层,ODS的数据经过ETL过程(抽取Extraction,转化Transformation,加载Loading)进入数据仓库,数据仓库反哺业务,为业务的分析和决策提供支持:反应业务现状,预测业务未来发展趋势,为业务的优化拓展赋能智慧。

 

ODS层

设计方案

直接从业务系统和用户日志中抽取,可与业务系统、日志系统中的数据结构和关系保持一致。

作用

直接在业务系统和日志系统进行查询是会影响业务体统的正常运转,ODS的存在将查询操作和业务系统隔离开来,使分析师和决策者的查询更高效,隔离查询对业务系统运转的影响。

 

数据仓库

设计方案

推荐设计流程:业务建模-领域建模-逻辑建模-物理建模

业务建模-领域建模-逻辑建模-物理建模,的建模流程。
业务建模:深入业务现场,进行业务主线的划分,业务流程的整合。
领域建模:即是实体抽象的过程,抽象出各个业务主线涉及到的领域概念和实体。
逻辑建模:找出各个实体之间的关系,此时推荐3NF 建模方法,ER图很有帮助。
物理建模:ER图落地到具体的数据库。

作用

反应企业当前的经营状况、可进行多维度系统分析、数据挖掘的基础,为商业决策提供支持。

 

数据应用层

涉及方案

数据的应用来自于实际的业务需要,不要为了赶时髦急于上各种高大上的项目。
以上的架构方案最终都是应因为有数据应用的需求才去实施。
不要等到ODS、DW“建好了”,再去想怎么用。首先要有Why。
没有目的和规划的建设是无意义的浪费。

作用

实践的好,也许能成为三体里的星环公司。

 

2020-02-19 20:32:09 spwanderer 阅读数 99
  • 使用Apache Kylin搭建企业级开源大数据分析平台

    1024大数据技术峰会邀请到11位来自一线互联网企业的大数据核心研发团队骨干成员,针对选型开源技术搭建大数据平台、持续运维、优化提升大数据平台的各项性能,技术架构演进以及实现应用大数据支持业务创新发展,这几大核心展开深入的分享和交流。

    6534 人正在学习 去看看 互联网技术联盟

申明:文中涉及到的图片均为原创,未经授权,不得使用。

公众号原文链接:
数据平台初试(架构篇)——平台架构演化

本文主要介绍数据采集平台的三种架构设计,以支撑不同数据量的采集。之前监控大屏中曾出现了三张不同时间段的统计图,下面再看看这三张图:
在这里插入图片描述在这里插入图片描述
在这里插入图片描述
三张图,不同的时间段,对应的日采集数据量分别在10万,30万,110万,这三个数值,是每日采集数据量的极大值,在2020伊始,平台日采集量在10W量级,两周之后达到了30W+,而在1月31日当天,数据量爆发式的达到了110W+。接下来分别对这三个场景下的平台架构做简单的介绍。

石器时代

第一张图,日采集数据量10W+,此时平台还未稳定,采集数据需要手工提交,平台采集效率较低,没有多节点支撑。此时,平台不需要做特别的性能优化,数据采集下来之后直接解析入库。存在的问题是目前平台处于开发初期,更新较快,需要手工提交任务,或者手工采集,需要人工维护整个平台的运行,人走则停。此时采集数据类型已经满足业务需求,但是由于无法实现自动化处理,效率较低。需要将手工处理设计为自动化处理,增加多节点采集数据。该设计将数据量从0拉升到了十万,随后平台进入青铜时代。

青铜时代

日采集数据量30W,此时已解决了以上提出的问题,任务处理自动化,采集器实现了分布式处理,多台模拟器同时运行,此时平台已经趋于稳定,形成了固定模式的系统架构,如下图:
在这里插入图片描述
由上图可知,采集数据加入了简单的缓存机制,采集器与解析器相对分离,采集器专注于互联网数据的采集,而解析器专注于在缓存中获取数据之后进行解析,解析完成后将结构化数据入库,该设计在初期运行稳定,采集速度也较快,数据库每天能稳定增加30W数据。

问题的出现:在平稳运行一段时间后,系统开始出现延时,最明显的现象就是监控大屏出现线程阻塞。自此,平台开始占用机器额外内存,此时采集器并不知道下游的解析器无法完成解析任务,采集器还是会源源不断的将数据采集回来放入缓存中,随着内存的增大,机器性能降低,为了避免陷入恶性循环,不得不将采集器关闭,等待解析器慢慢将堆积的数据取走。由于该问题的出现,日采集数据达到极限,无法再往上增长。

排查:此时总数据量在300W,后经排查,存在的问题如下:

1.数据入库之前,由于为了避免数据重复,做了一个存在性校验,由于前期未考虑数据暴增问题,在数据库表结构设计时存在一定缺陷,导致此处需要走一步存在性校验,影响入库性能。

2.机器地理位置缺陷:由于机器是分几次购买的,而且主要依赖于优惠政策,所以导致几个机器不在同一地区。在入库过程中,数据需要网络传输,由于网络延时,入库过程及其缓慢,导致整个数据堆积。该问题经有限优化,堆积数据得到一定缓解。

随着总数据量的提升,问题依然存在,而且堆积不断增多,单位时间入库数据量不断减少,急需新的设计介入,对平台做一次大型升级。该设计将数据量从十万拉升到了400W,随后平台进入电气时代。

电气时代

由于以上两个问题的不断升级,机器资源无法更换,只能在软件层面不断提升性能,经过排查和研究,需要解决的问题如下:

1.入库之前不做存在性校验,但是不能导致数据重复
2.机器分散,在入库过程中网络延时较大
3.在数据高峰,阻塞过高,使得机器内存占用过大

针对以上问题,经过研究,得到了解决方案:
1.入库直接判断主键是否存在,存在则更新,不存在则插入。该操作需要修改原数据库表结构设计。
2.减少网络传输次数。该操作通过批处理可解决,每次入库1000条等类似措施。
3.数据高峰阻塞过高,内存占用多。将阻塞的数据不放在内存,直接写入硬盘。

根据以上三点,新的设计图如下:
在这里插入图片描述
根据设计图可以看出来,主要做的改进在两块,一块是在采集器后面加入了kafka,采集器采集到数据后,短暂放入缓存队列,再批量放入kafka,解决了采集器一侧的数据堆积问题。第二部分是整个解析器,重新构造json解析器,由原来的python切换为java,支持分布式解析,速度提升3倍左右,解决了解析器部分的阻塞,即使在数据高峰,数据也会顺序写入硬盘,不会使内存占用过多。第三部分是解析器后面的数据入库逻辑,加入了缓存队列和批处理,大大节省了网络延时,一次网络延时将入库1000条数据,其他时间机器资源就可以执行其他操作。第四部分提升是数据库中表结构的修改,不再使用自增ID,目前直接使用采集到的ID,可以直接判断数据是否在库中存在。

该设计在升级完成后的第一天测试,10个小时数据量就达到了53W,远远超过之前24小时采集到的34W数据,而第二天性能测试,开启两台模拟器采集数据,15小时采集111W数据,远远超出第一代架构设计。目前还没有进行更持久的测试,根据性能测试当天的表现,平台性能远没有达到饱和,测试使用的服务端机器为1核2G内存,部署了kafka和解析器,监控大屏。采集器为本地笔记本拖两台模拟器。预测平台解析能力能拖4台模拟器,日采集数据量极大值能超过200W,曾经也出现过一个小时采集30W数据的极端环境,平台依然平稳运行,升级之后平台总体性能基本满意。目前该设计已经投入使用,也是真正能上生产环境的第一个架构设计,截止目前,该设计将数据量从400W拉升到了1000W,并将继续增长,期待未来的表现。

未来时代

目前的设计,理论上能将数据量拉升到几千万,此后,虽然平台支持横向扩展,但是数据库需要寻找新方案实现,继续使用mysql则需要分库分表,目前的定位是,当未来数据爆炸的时候,存储库由mysql切换为HBase,再设置索引到内存数据库,提升查询速度。整个设计图如下:
在这里插入图片描述
一款来自未来的设计,该设计全部支持分布式集群环境架构,所有组件支持横向扩展,在未来,该架构设计将打造大规模数据采集与存储平台,投入使用之后将可以通过简单的配置扩展机器资源,满足中期平台的业务扩张,该设计计划将平台数据由千万级别拉升到十亿乃至于百亿级别。

以上就是目前采集平台的架构设计演化史,简单分享出来,可以给正在摸索的朋友一个参考。喜欢的朋友欢迎点赞收藏订阅,能点个关注就更好啦,我将不定时更新一些文章,公众号和其他平台不经常登录,如有需要,可以给我留言或者添加我的公众号同名微信“SPWanderer”,备注“交流”即可。

往期回顾

数据可视化大屏的价值——从超市实时营业额作战平台说起
实时大屏如何支撑海量数据处理——超市实时监控大屏V2.x
数据平台初试(技术篇)——抖音数据采集(初级版)
数据平台初试(技术篇)——抖音数据采集(高级版)
数据平台初试(产品篇)——监控大屏初露面
在这里插入图片描述

1.饿了么大数据架构2.斗鱼平台架构

博文 来自: weixin_43740680
没有更多推荐了,返回首页