最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
打印 上一主题 下一主题
开启左侧

数据中台建设杂谈

[复制链接]
跳转到指定楼层
楼主
发表于 2019-7-3 11:51:50 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
现状
公司属于是互联网金融行业,但因为只是中小型企业,技术积累较少,数据部门也是16年未开始组建的。最初只是一个提数小组,为业务部门提供他们需要的数据,直到上层领导有意走数据驱动业务的方式,才创建了数据部,也可能只是为了赶时髦,毕境17年,各种GB、TB已经满天飞。
于是领导就带领着大家搞起了大数据,创建了最初的仓库平台、搭建了报表平台、可视化平台,对业务提供支撑。几乎没有相关技术储备,可以说从0到1,轰轰烈烈,加班加点搞了几个月,初见成效。在做大数据平台的同时,也引入了一些数据应用产品,比如多维分析的saiku,BI工具SuperSet,用于提供报表和提数需求;并且也开发了自己的数据管理平台、统一调度中心,可以小有成就。
18年年初(3月初左右)公司上层决策创建金融事业中心并单独运营,部门负责人被抽离到金融,并带走部分核心人员,再加上离职人员,技术所剩无几,导致后续大数据平台停步不前,没有什么新的产品开发,日常工作即停留在对原有系统的使用上,应对越来越多的提数需求和个性化的业务定制需求,响应乏力。同事们也有心改造,但无奈人员缺乏,技术储备不足等原因,未能见成效。
当然,近1年多的时间同事们也没有闲着,在完成工作的时事,尝试了一些大数据应用的技术和方案,算是做了些相关技能的存储。
设想
2018Q4研发中心架构调整,欲建立去中心化的开发平台,即各业务部门各自管理自己的应用和数据,同时同步到数据中台。各业务部门对其它部门的数据需求,统一走数据中台。所以数据部又一次走到了风口,面临压力,着手改造。
现有的数据仓库架构
如下图所示,按照业内标准的数据架构,数据采集层、数据计算层、数据服务层、数据应用层进行描述。
首先是从各业务部门数据库,通过OGG、Sqoop、DataX、Kettle等工具同步定时同步数据到数据中心存储系统上,包括大数据平台HDFS、关系型数据库。然后提供几种查询平台,如kylin、hive、Oracle等,进行数据获取,如通过Kylin建模的方式,离线预处理T-1的离线数据;通过oracle数据库,提数人员写SQL查询等,得到想要的数据,目前只支持离线数据。数据同步完成对,外的的数据服务,目前提供了手工提数工单、数据网关接口、帆软BI报表、帆软可视化等方式对业务部门提供查询。
标准数据中台构架
如下图所示
通用的数据中台架构,即从数据同步->模型抽象->对外应用进行划分,其中操作层作了些同步、清洗、日志采集等收集数据的事情;公共维度对业务数据进行建模,划分度量、维度等对数据进行建模,当然也可以采用其它建模方式;应用数据层是对创建好的数据对外提供服务的方式,包含传输数据的渠道、展示数据的方式等。
从我们现有的架构的数据仓库架构来看,最初也是按照这个架构进行设计的。但从具体的实现去分析实则存在很多的问题,及需要改进的地方。下面对现有架构的问题进行一下分析。
存在的问题
当前系统架构,对于技术的应用边界、所选技术的性能等问题没有明确的说明。大致列举如下:
  • 数据同步就有OGG、DataX、Sqoop、Kettle,到你在什么情况下使用OGG比较好,在什么情况下应该使用DataX等问题没有明确界线;另外是否需要这么多同步技术支撑,还是说选择1个主流技术和一个补偿机制即可。
现在的大数据平台,只是搭建完成,功能只使用了基础的hdfs/hive,对于其它的技术没用实践;
  • 数据同步离线可以多种方式实现,目前实时同步使用的是OGG数据同步。OGG同步是公司DBA进行管理,这方面的责任是否清晰,如果出问题,他们是否能积极支援。
  • 公共维度模型层目前是使用kylin做离线OLAP计算,内部采用维度建模思想,这些建模示例能否单独抽象出来,应用在其它的查询或提数方式,更有利于扩展。

4.计算引擎单一,目前只有hive方式查询,对于近实时的要求高的应用就不能满足了。应该提供批和流同步支持的查询,针对不同的情况,选择不同的查询引擎。
5.同步与查询模块,能否经受得住后期全业务部门的数据查询需求和高并发、大数据量的考验。需要做哪些改进。
我们能改进的点
  • 应该针对不同的查询需求,提供不同的数据服务出口。比如规范性强的直接走数据网关;定制化要求高的可以走报表;个性化的数据可以走提数工单,定义好边界。
  • 提供批和流两种查询支持。计算是仓库的大脑,如果速度慢,完全影响体验及数据的反馈。
  • 数据建模。应该统一数据建模,建议规范定义和整理,用于数据提取或自助提数。也可减少与业务人员的理解分歧。

理想的仓库
如图所示。
提供批流两种计算方式、对外针对不同的需求,提供不同的对外数据输出。优化建模,改进同步,增加消息同步补偿。
最后
个人见解,很多不足,后期再变更吧。另外理想很丰满,现实很骨感,4季度结束再回头看吧。
参考
阿里巴巴《大数据之路》

楼主热帖
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏 转播转播 分享分享 分享淘帖 赞 踩

168大数据 - 论坛版权1.本主题所有言论和图片纯属网友个人见解,与本站立场无关
2.本站所有主题由网友自行投稿发布。若为首发或独家,该帖子作者与168大数据享有帖子相关版权。
3.其他单位或个人使用、转载或引用本文时必须同时征得该帖子作者和168大数据的同意,并添加本文出处。
4.本站所收集的部分公开资料来源于网络,转载目的在于传递价值及用于交流学习,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。
5.任何通过此网页连接而得到的资讯、产品及服务,本站概不负责,亦不负任何法律责任。
6.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源,若标注有误或遗漏而侵犯到任何版权问题,请尽快告知,本站将及时删除。
7.168大数据管理员和版主有权不事先通知发贴者而删除本文。

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-4-24 12:56

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表