提供3000多款全球软件/控件产品
针对软件研发的各个阶段提供专业培训与技术咨询
根据客户需求提供定制化的软件开发服务
全球知名设计软件,显著提升设计质量
打造以经营为中心,实现生产过程透明化管理
帮助企业合理产能分配,提高资源利用率
快速打造数字化生产线,实现全流程追溯
生产过程精准追溯,满足企业合规要求
以六西格玛为理论基础,实现产品质量全数字化管理
通过大屏电子看板,实现车间透明化管理
对设备进行全生命周期管理,提高设备综合利用率
实现设备数据的实时采集与监控
利用数字化技术提升油气勘探的效率和成功率
钻井计划优化、实时监控和风险评估
提供业务洞察与决策支持实现数据驱动决策
转帖|行业资讯|编辑:龚雪|2017-04-05 11:12:08.000|阅读 251 次
概述:以工具链应对高速增长的数据需求量
# 慧都年终大促·界面/图表报表/文档/IDE等千款热门软控件火热促销中 >>
文 | 吕毅,链家网平台架构师
链家网于2015年成立大数据部门,开始构建基于Hadoop的技术体系,初期大数据部门以运营数据报表需求、公司核心指标需求为主。随着2015年链家网发力线上业务,toB与toC业务齐头并进,数据需求量激增的情况也随之在2016年突显,数据量增至PB级。我们开始思考如何改变现状,如何高效支撑未来可预见的众多数据需求。
链家网大数据部门成立之初,面对着零散的数据需求,最早期的办法是配置定时任务跑脚本,将结果通过邮件方式发送给需求方。2015年期间,随着运营数据需求的增加、希望查阅数据的人员增多,邮件的方式不方便人员间信息传递,并且查找历史数据也不方便,在技术上也因数据相关人太多导致邮件发送阻塞。
因此,考虑到运营数据需求、公司核心指标需求相对固定,并且维度可枚举,特在2015年基于ROLAP技术方案,搭建了早期的报表系统。
图1 链家网早期的报表系统
早期的报表系统,由数据开发工程师提交数据任务,通过配置Oozie定时任务,定时的基于Hive数据做ETL过程,将报表系统所需的数据推入关系型数据库(MySQL)中。该系统从接收需求到报表系统里看到数据,需要比较长的一段时间过程,涵盖过程如下:
流程过程较长,角色间传递信息较多,前后依赖太强,都是制约当时报表系统快速产出数据的根本问题。该系统在之后的迭代中,通过增加选取MySQL数据、自助勾选维度,实现了自助报表系统,命名为“地动仪”并服务至今。然而,流程长、传递信息多、依赖强的问题依旧没有根本解决,对于逐渐增多的数据分析需求,更不能及时响应。
地动仪在一定程度上解决了邮件方式的弊端,提供Web界面化的查询,支持历史查询和多人使用。但对于非订制化需求、数据探索需求、数据分析需求支持的力度并不好。我们开始规划更好的数据分析平台服务。
大数据工作划分,通常分为大数据应用、大数据平台两大部分。常见的大数据应用形态有数据挖掘、数据分析、个性化推荐、数据报表等,大数据应用形式相对更多样,可以根据业务不同而有具体的大数据应用产品。大数据平台,在一家公司中则应相对统一,以方便做好公司统一的数据接入规范、统一的数据管理机制、统一的数据处理能力等,做好数据管控。
因此,在对历史大数据架构进行梳理后,链家网将原有大数据部门工作细化,将大数据应用交由业务线团队或其他技术团队承担,便于业务线开展多样化的数据工作,同时将大数据部门聚焦于构建公司统一的大数据平台,负责公司内各部门数据相关需求的统一规划与实现,建设公司统一的数据仓库与数据服务。至此,链家网大数据平台团队诞生,我们开始着手建立平台,支持好未来公司内对数据使用上的各类需求。
在2016年中期,通过梳理各部门数据需求,将数据需求分类为:数据探索需求、报表需求、数据分析需求、数据API需求这四类。为满足这些数据需求,我们相应规划了下面这些数据产品:
AdHoc系统:解决数据探索性需求,基于SQL查询,查询速度要求高;
地动仪:解决报表需求,承接较固化报表需求、公司级报表需求;
BI产品:解决数据分析需求,支持多维查询,支持数据分析中常用的下钻、上卷等功能;
数据API:解决数据API需求,大数据API统一出口,支持各部门的格式化数据获取。
结合数据产品层面的规划,大数据平台在技术工作上做了重新规划,技术工作上划分出了四个部分:平台服务、数据管理、工具链与集群。
其中平台服务包含报表系统、BI系统与大数据API;大数据工具链包括OLAP引擎、即席查询AdHoc系统、调度系统三部分;大数据集群层面除集群性能、稳定性工作外,还包括集群安全、集群资源隔离两部分;贯穿服务、工具链、集群三层的数据管理部分,更加关注数据治理,内含元数据管理、指标管理、数据权限管理三大数据管理工作。技术工作划分情况如图2:
图2 链家网大数据平台
大数据平台的建设过程,是由下而上逐步完成的。首先要有Hadoop集群,在有HDFS与Hive后,才能开展数据接入工作,才能基于集群建设工具链;当工具链部分的OLAP引擎构建好,才有上层BI、报表系统和数据API,只有AdHoc能力构建好,才能提供基于SQL的数据探索平台,工具链中特别需要建设好调度系统,才能在实现好数据ETL任务的同时,管控数据流向与数据关系。
最后则是服务层面的建设,重心在于迎合需求的同时,服务做得更加易用。数据管理系统会穿插于整个大数据平台中。
大数据平台中衔接服务与集群的枢纽——工具链,正是整个平台能力的传送带,它肩负着将大数据能力输送到上层服务层的重任,也承担着上层多项服务被使用时的数据能力支持。
大数据平台内部工作,完全可以简单划分为集群与服务两部分,为何要在它们之间构建一层工具链层呢?由图1可以看到,原大数据架构中,因产品层面单一,数据从收集入HDFS后,数据流向单一,均由Oozie调度任务从Hive获取数据,并向上推送。
考虑到平台服务层面的多个产品形态,数据流向也需扩展才能满足产品所需能力,而数据流的管理与集群工作强制规划在一起,太过生硬。故全新开辟一层工具链层,通过借助集群能力,通过或使用开源或自研,来扩展数据转换与输出的能力,提供更多种的数据流形式,以满足上层数据服务需求。
对于工具链层面的设计,我们按照数据流向设计了下图中的工具链结构:
图3 大数据工具链数据流向规划
数据探索类需求,即数据查询需求,若都基于Hive采用MapReduce运算,速度上会大大影响用户的使用体验,然而即席查询AdHoc技术方面,Facebook开源的基于内存计算的Presto进入了我们的视野,考虑到Presto与Hive均为Facebook开源技术,在SQL兼容性方面通用性更强,特对Hive、Presto、Spark在SQL on Hadoop方面进行测试对比:
通过多次测试结果显示,在处理速度方面,Presto < Spark SQL < Hive,大部分情况下,Presto时间开销上远少于Hive SQL,速度优势稍微好于Spark SQL。考虑到公司内探索性数据查询需求由人发起,数量可控,Presto技术选型完全满足我们对响应速度的要求。
故采用Presto引擎搭建AdHoc平台,AdHoc的Web界面我们通过自研,除基础的数据查询功能外,实现了数据导出、转发、生成报表等功能,其中生成报表功能与调度系统打通,将数据探索工作成果进一步延伸,由AdHoc发起的调度任务,则是使用MapReduce离线运算。关于Presto UI部分,Airbnb开源的Airpal界面简洁清晰,也是不错的选择。
图4 Airbnb开源的基于Presto的UI界面
数据分析性需求按照工作方式细分,还可以分为非技术人员使用Web工具分析数据、技术型人员直连Hadoop集群提交分析任务两种类型。前者更多是运营、研究院、产品线数据PM等角色使用,后者则是做数据挖掘、推荐的工程师们在使用,对于工程师们,我们内网开放集群运算能力,供工程师们提交任务,通过集群中的资源隔离保障大家的任务高效运行。工具链中,则更关注前者的分析类场景,如何方便地满足。
非技术人员的数据分析需求,相对于比较固话的数据报表型需求,指标、维度的组合上希望灵活性更高,并且有着下钻、上卷分析数据的需求,更多维的查询数据。因为分析工作一般是连续查询数据,所以对于查询速度也有一定的期望。
鉴于此,我们考虑通过预置数据的方式,通过空间换时间,来解决查询速度问题。对于多维查询需求,我们考虑通过构建多维Cube方案解决。这正是MOLAP解决数据查询问题的方式,而MOLAP方案的有限技术选型中,我们更看好Apache Kylin项目。
Apache Kylin项目的一些特性,匹配我们的数据需求以及我们当时的现状。数据需求已经梳理清晰,要快、要多维查询,Kylin项目对于已创建了Cube并构建好数据的数据集上,提供亚秒级的快速查询。并且Kylin还提供工具方便构建Cube、提供API方便对接上游BI产品。
另一方面我们当时的现状是,海量数据库方面我们拥有稳定且调优过的HBase集群,这恰巧是Apache Kylin所依赖的数据库选型。综合这些情况,我们通过调研Kylin系统自身能力、Kylin与Sarku的对接情况,以及有Apache Kylin研发团队成员现场交流,逐步启动了基于Kylin的MOLAP引擎构建。预计不久我们将以Kylin为基础,为BI产品、数据API两项数据平台服务提供数据查询能力,以满足公司内的多维数据分析需求。
通过MOLAP建设,与原有地动仪ROLAP相辅相成,面向公司内有数据分析诉求的同事,提供更全面的数据分析平台。
调度系统,是大数据工具链的核心环节,乃至是大数据平台化的基础。数据ETL任务完全基于任务调度在有计划地执行,数据任务的关系、数据血缘也需要基于调度系统的能力来自动化构建。
在链家网大数据平台建设之初,最先对原有的Oozie调度系统进行调研分析,发现Oozie与Hadoop集群绑定太过紧密,任务间的状态传递必须依赖HDFS中的文件状态来传递任务状态,这导致一些数据任务需要我们用Hack的手段处理。
例如我们的任务是定时“先将Hive数据导到MySQL,再运行一个远程服务器脚本对MySQL统计数据,再将脚本统计的结果发送到xxx@lianjia.com邮箱”,这样的需求,整个过程没有产生HDFS文件的必要,但在使用Oozie时,我们不得不在每一步执行完后在HDFS中创建文件以便传递信息。
我们已经可预见未来数据任务需求会有所增加,随之而来的数据任务种类也将会扩充,若不做调度系统上的改变,大数据平台的数据任务能力,将会受限于Oozie的使用场景,这与平台设计理念不符,工具应当更好的支持平台建设,而非阻碍平台发展。
所以在那时,我们决定自研大数据调度系统,在参考了行业内一些调度系统解决方案的同时,我们梳理了现有的任务种类与可能的未来需求,逐步排期的实现调度系统必须的两大环节:调度环节、执行环节,并且抽象的设计了他们之间的传输协议,为未来扩展新型执行单元提供了可能。
图5 调度系统前端功能
图6 调度系统后端能力
工具链作为数据驱动纽带,工具化的为上层平台服务提供各类能力,上层平台服务包装大数据平台能力,开放给用户使用。围绕着工具链的建设,大数据平台较改造前的数据加工模式,提供了更丰富的上层数据服务。
通过Apache Kylin技术构建MOLAP引擎,与原有的ROLAP引擎相辅相成,搭配基于Presto的AdHoc服务,提供了一站式的快速数据查询、分析平台,并且提供了统一的大数据API,为公司各业务线、数据分析团队、数据应用方提供高可用稳定的数据格式化出口。随着调度系统的逐渐成熟,工具链层面的建设逐渐完善,平台化的大数据服务,整体较从前有全面的改善。链家网的大数据工作逐渐从报表阶段,步入了平台化自助服务的阶段。
当然,在建设大数据工具链的过程中,依然还有不少技术问题需要攻坚。例如Presto中还未完全兼容Hive SQL语法,需要涉及到Presto SQL解析器部分的调整工作,又例如Kylin如何能够根据指标系统中的指标自动构建Cube,需要考虑打通指标系统与Kylin系统,或通过自动化的程序来避免数据开发人员的重复操作。
工具链中的技术挑战还有不少,但我们清晰的发展路线,让我们有坚定的信心去逐个攻克,也欢迎有志之士加入,一同建设链家网大数据平台。
目前大数据工具链的技术问题,在陆续解决的同时,我们的平台服务、集群、数据管理相关的工作也都在紧锣密鼓的进行中。整体大数据平台长线的一些工作,也在逐渐规划着,例如自动化构建数据血缘、调度系统中任务DAG实时关系图、MOLAP与ROLAP的融合、数据API的全自助服务等技术问题。相信未来半年到一年的大数据平台发展过程中,在将平台服务包装的更为优秀的同时,将会积累更多实用的技术沉淀,促成公司、团队、个人共同成长与进步。
在建设链家网大数据平台期间,我们与百度、美团、滴滴和Kyligence有着良好的沟通交流,他们在大数据平台上的沉淀与经验在平台设计规划阶段,对我们的帮助很大,我们也将会在建设链家网大数据平台的同时,通过技术分享的方式与行业内大数据相关的朋友分享交流,帮助营造行业内大数据领域共同进步的良好氛围。
更多行业资讯,更新鲜的技术动态,尽在。
本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@pclwef.cn
通过提供强大的3D CAD数据访问工具并适用于桌面、移动和Web的高级环境3D可视化发动机,HOOPS在提升造船设计和制造流程的效率方面发挥了重要作用。
HOOPS Luminate在汽车行业中的应用具有广泛的潜力和深远的影响。它通过提供高效的3D可视化、虚拟装配与拆解、性能分析、客户定制等功能,帮助汽车制造商在设计、生产和销售过程中提升效率、降低成本并提高产品质量。
在不断发展的软件开发世界中,使工具和框架与最新的平台版本保持同步至关重要,欢迎查阅~
全球航运业对国际贸易至关重要,全球 90% 以上的商品通过海运运输。准确监控和控制这些集装箱的移动对于维持高效的供应链至关重要。手动输入集装箱号码是这一程序的关键部分,它带来了相当大的挑战,例如人为错误和效率低下。
服务电话
重庆/ 023-68661681
华东/ 13452821722
华南/ 18100878085
华北/ 17347785263
客户支持
技术支持咨询服务
服务热线:400-700-1020
邮箱:sales@pclwef.cn
关注我们
地址 : 重庆市九龙坡区火炬大道69号6幢