热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

瓜子大数据架构首曝光:掩藏在“二手车”背后的技术思考

提起车好多集团,可能有些人会感到陌生,但提起瓜子二手车、毛豆新车,想必都十分熟悉,脍炙人口的广告语使得大家忽视了这家公司的技术能力。车好多集团旗下拥有瓜子二手车、毛豆新车、车速拍与

提起 车好多集团,可能有些人会感到陌生,但提起瓜子二手车、毛豆新车,想必都十分熟悉,脍炙人口的广告语使得大家忽视了这家公司的技术能力。车好多集团旗下拥有瓜子二手车、毛豆新车、车速拍与瓜子养车四大品牌,协同为用户提供新车、二手车交易服务、汽车金融、售后保障、汽车维修保养等全产业链服务。

对汽车而言,大部分用户目前的消费习惯倾向于线上看车、咨询、预约,线下进行交易,这对车好多集团的大数据架构搭建提出了诸多挑战,比如线上与线下数据打通、海量数据分析、利用数据辅助智能化决策等。InfoQ 有幸采访到车好多集团旗下 瓜子二手车 的大数据及数据仓库方面多位技术工程师,就上述问题展开探讨并了解瓜子大数据技术选型历程。

瓜子大数据架构

虽然瓜子只是一家成立 3 年多的创业公司,但业务的快速发展让这家公司在大数据和数据仓库建设方面投入了巨大精力。从最初的四台服务机器到如今的五百多台机器,毛豆供应链及基础架构技术总监林正位坦言,瓜子大数据平台建设早期更多是需求和问题驱动:数据分析需求,效率不高、稳定性较差等问题让技术团队不得不快速演进迭代。

在数据平台层面,车好多数据平台技术负责人总监刘昊植坦言,早期瓜子存在四大痛点:一是其自身的业务流程过于复杂,导致指标体系的建设很难达成一致;数据仓库分层定义不清晰,按需构建而没有完全契合数仓建模方法论;定制化开发的 BI 平台难以灵活配置各业务线和事业群所需的数据可视化能力;应用多呈点状分布,没有形成一站式智能化数据开发平台。

 


 

如果你准备入行大数据,关于2019大数据目前的

【发展前景】戳我阅读

【就业岗位】戳我阅读

【大数据薪资待遇】戳我阅读

【完整的学习线路】戳我阅读

关注微信公众号itdaima获取大数据全套开发工具以及入门学习资料

 


 

起初,瓜子大数据架构主要为了满足业务方 BI 报表相关的查询诉求,如今几乎承载了瓜子大数据的所有需求,大数据高级技术专家彭超表示,目前的大数据架构主要支撑了报表相关服务;用户画像;用户增长、业务增长相关数据支持;所有业务线的消息队列;瓜子大脑,也就是人工智能相关诉求。总体来看,瓜子大数据架构主要用于支撑自有业务基于数据的精细化运营。

其中,每一个环节又都存在需要解决的关键问题。举例来说,瓜子目前的 OLAP 需求非常强烈,运营和销售人员需要了解当天的实时数据和明细数据,这就需要瓜子 BI 具备接到报表请求后秒级响应的能力。此外,如开篇所言,瓜子的业务特点决定其需要打通线上和线下数据,将全链路数据化到线上,通过统一的数据处理模型对数据进行分析。

在架构层面,瓜子大数据也存在一些痛点需要解决,比如最初基于 Hortonworks 的 Hadoop 构建,未来需要逐渐过渡到 CDH;结构化数据生态圈的打通;基于 Hive 的 OLAP 分析逐渐通过 Presto 解决跨数据源查询;由于 Kylin 和 Druid 不能满足原始数据快速更新变化的需求,因此团队决定转向 Kudu+Impala,通过 Lambda 架构提供对外的 OLAP 分析。

在实时计算层面,瓜子之前采用的是 Spark Streaming,目前是 Flink 与 Spark Streaming 共存的状态,存量用户主要在使用 Spark Streaming,增量用户主要使用 Flink。

在实时数仓 ETL 层面,瓜子数据仓库团队负责人孙强表示,瓜子需要处理的主要是业务数据,相比于日志数据,这部分数据的处理链条更长、难度更大。日志数据一旦生成基本不会更新或删除,Flink、Storm 都是相对成熟的解决方案。然而,业务数据的结构和处理逻辑相对复杂,瓜子在这方面进行了许多技术探索和演进,最早期选用的单机 Python 定制化数据处理方式,虽然有效支持了早期的业务需求,但随之数据规模的增长,很快就已无法支撑业务需求;接下来,瓜子曾考虑使用 Java ETL 替代原始方案,虽在性能上获得一定提升,但并没有完全解决问题。于是,团队开始调研当下比较热门的 Flink。

就实时性而言,Flink 是一种能够满足事实数据关联维度数据需求的不错的解决方案,但其目前不足以应对高精度场景(对数据质量要求极高,不能出现数据丢失),很难满足瓜子业务中事实数据相互关联的复杂需求。最终,瓜子在对数据实时性和框架易用性和可维护性直接进行的权衡做出让步, 从真实时退到准实时,基于 Impla+Kudu 的准实时方案满足瓜子绝大部分数据应用场景,并通过数据工程师最熟悉的 SQL 语法进行开发,很大程度上减少了开发工作量,目前调度为保证每 15 分钟运行 Run 一次,每 Run 一次小于 15 分钟。数仓高级专家孙强表示,如果未来企业对时效性有更高诉求,可以将该时间缩短至 10 分钟甚至 5 分钟之内。

此外,针对早期数仓分层不规范的问题进行改进,对每一层的设计规范和原则进行清晰定义,按照规范构建整个数据仓库。

技术选型

综合整个瓜子的大数据架构,不难看出选用了不少开源组件。为避免重复造轮子,如今的不少公司都倾向于开源组件,选用开源意味着需要考虑社区成熟度、改进成本、自身技术实力等诸多问题,瓜子在这之中做过哪些思考呢?

彭超透露,瓜子在大数据方面的技术选型主要考虑了四点:一是公司实际需求;二是开源组件的技术成熟度;三是生态圈是否完善;四是未来可能的发展方向。以 Kafka 和 Hadoop 为例,这两项技术在社区发展已有十年时间,基本趋于稳定,迭代频率相对较低且功能完备,可以考虑选用;另一类是比较前沿的技术,比如 Flink、TiDB 等,瓜子也愿意花费精力调研和尝试。

林正位补充道,瓜子内部有一个“721”概念,即将 70% 的精力投入当前正在使用的核心技术研究;20% 的精力用以不断优化、改进以提升效率;10% 的精力用以应对技术变化,投入新技术的研究。

在 70% 和 20% 的部分,彭超介绍道,瓜子对很多组件进行过改动。举例来说,对 HBase 和 HDFS,做了平台和调优方面的改进;对 Presto,做了滚动更新、滚动重启、权限管理、高可用等层面的更新;对 Kafka,设计了统一平台以方便各业务线使用数据等;探索一些新的解决方案,比如 TiDB、流批处理等。

在 10% 的部分,大数据技术专家汪涉洋介绍道,瓜子会探索一些新技术,比如学习引擎、GPU 计算集群等,并希望在能力范围内对开源社区进行反哺,以希望对业务场景类似的公司或团队起到积极作用和参考价值,这也是瓜子技术委员会一直在遵守和倡导的原则。刘昊植补充道,瓜子技术委员会在公司发展的各个时期可能会承担不一样的责任和使命。现阶段,该委员会主要负责公司内部整个公司的技术栈收敛和更新,包括架构等各个维度;技术职级体系的规范化和统一;技术交流和培训化等工作,有能力开源并对社区做贡献一直是整个委员会要做的重点方向之一事情。

此外,上述四点技术选型标准也是未来瓜子大数据平台技术变更的重要影响因素,但考虑到变更成本(人力成本、机器成本、学习成本)和风险,刘昊植认为,未来,整个瓜子大数据平台会尽量采用已被验证的开源技术,并集中力量对选定技术方案进行深入研究和探索减少变更,同时瓜子大数据团队也会时刻保持对业界最新技术趋势的跟进但并不拒绝变化。比如,当下 NVMe 磁盘 IO 性能未来存储成本的大幅提升降低可能会带来的分布式架构的变革。

云平台选用考量

随着云计算的逐渐成熟,很多公司都开始创建高效、灵活的云使用环境,这些环境被部署在服务器、存储和网络资源池中,这类方案通常更具成本效益,可以提高大数据技术和高级分析的投资回报率。

过去几年,云平台大数据服务越来越成熟,单就这一项,主流云厂商可提供的服务列表就达到数十种,本地大数据服务的声音逐渐变小,这在 Cloudera 与 Hortonworks 合并之后尤为明显。实际上,云平台大数据服务和本地大数据服务各有其生存空间和适用场景,瓜子的大数据团队是如何考虑这一问题的呢?

实际上,瓜子云平台总监高永超表示,瓜子云目前已经支持其内部大约三分之二左的业务运行,云本身的弹性扩容和成本优势让其承载了部分瓜子大数据服务,主要是面向最终用户的应用和 ETL 相关的系统需求。

对此,林正位提及,瓜子早期考虑过直接上云,甚至使用过一些第三方数据服务,但最终结果是难以与瓜子的业务需求和发展节奏完全契合。其次,在瓜子的整体技术规划中,整个技术团队希望未来有能力为开源做贡献并分享实践成果,这一想法的前提是瓜子自身必须具备较强的技术实力,因此团队决定在本地自建数据服务,而不是通过云平台获取所有基础能力,而一心扑在上层应用研发。

此外,目前很多企业的上云姿势未必是最佳的,这也导致很多企业没有充分享受到云计算的优势,并可能付出了巨大的成本,从而对这一技术的发展存疑。目前,瓜子已经将较容易享受到云平台优势的任务搬迁上云,而其他大数据服务依旧在本地运行。

高永超表示,瓜子云目前主要满足企业内部对 DevOps 的需求,接下来在 PaaS 层会做出很多改进,以进一步打消业务稳定性顾虑,但目前来看,即便云平台足够成熟且完善,还是存在一些特定应用无法上云,比如网络环境受到严格管制的金融类应用。

未来规划

采访最后,彭超表示,瓜子大数据未来发展主要围绕满足自身业务需求、平台化能力建设和大数据应用三方面展开。在满足自身业务需求的同时,团队希望有能力回馈社区;对所有大数据使用方提供平台化能力,形成平台化解决方案;针对大数据应用形成通用解决方案并对外提供。

在数据仓库层面,孙强补充道,未来几年会更加关注数据平台化(或者说数据中台)能力,并设计瓜子的数据开发平台和数据治理工具,这其中需要解决数据同步、数据开发、数据运维、数据血缘管理等问题,目前已经进行了一定积累,但还处于早期探索阶段,未来希望可以在这方面有所突破。

截至目前,车好多集团 业务遍布全国 200 多个城市,在业务高速发展的背后,不难看出其技术团队做了很多思考和调整。未来,期待其可以将这些技术能力进行一定程度的开放并为行业带来价值。

 



推荐阅读
  • 背景应用安全领域,各类攻击长久以来都危害着互联网上的应用,在web应用安全风险中,各类注入、跨站等攻击仍然占据着较前的位置。WAF(Web应用防火墙)正是为防御和阻断这类攻击而存在 ... [详细]
  • Oracle优化新常态的五大禁止及其性能隐患
    本文介绍了Oracle优化新常态中的五大禁止措施,包括禁止外键、禁止视图、禁止触发器、禁止存储过程和禁止JOB,并分析了这些禁止措施可能带来的性能隐患。文章还讨论了这些禁止措施在C/S架构和B/S架构中的不同应用情况,并提出了解决方案。 ... [详细]
  • 一、Hadoop来历Hadoop的思想来源于Google在做搜索引擎的时候出现一个很大的问题就是这么多网页我如何才能以最快的速度来搜索到,由于这个问题Google发明 ... [详细]
  • 云原生边缘计算之KubeEdge简介及功能特点
    本文介绍了云原生边缘计算中的KubeEdge系统,该系统是一个开源系统,用于将容器化应用程序编排功能扩展到Edge的主机。它基于Kubernetes构建,并为网络应用程序提供基础架构支持。同时,KubeEdge具有离线模式、基于Kubernetes的节点、群集、应用程序和设备管理、资源优化等特点。此外,KubeEdge还支持跨平台工作,在私有、公共和混合云中都可以运行。同时,KubeEdge还提供数据管理和数据分析管道引擎的支持。最后,本文还介绍了KubeEdge系统生成证书的方法。 ... [详细]
  • 一次上线事故,30岁+的程序员踩坑经验之谈
    本文主要介绍了一位30岁+的程序员在一次上线事故中踩坑的经验之谈。文章提到了在双十一活动期间,作为一个在线医疗项目,他们进行了优惠折扣活动的升级改造。然而,在上线前的最后一天,由于大量数据请求,导致部分接口出现问题。作者通过部署两台opentsdb来解决问题,但读数据的opentsdb仍然经常假死。作者只能查询最近24小时的数据。这次事故给他带来了很多教训和经验。 ... [详细]
  • 基于PgpoolII的PostgreSQL集群安装与配置教程
    本文介绍了基于PgpoolII的PostgreSQL集群的安装与配置教程。Pgpool-II是一个位于PostgreSQL服务器和PostgreSQL数据库客户端之间的中间件,提供了连接池、复制、负载均衡、缓存、看门狗、限制链接等功能,可以用于搭建高可用的PostgreSQL集群。文章详细介绍了通过yum安装Pgpool-II的步骤,并提供了相关的官方参考地址。 ... [详细]
  • Spring特性实现接口多类的动态调用详解
    本文详细介绍了如何使用Spring特性实现接口多类的动态调用。通过对Spring IoC容器的基础类BeanFactory和ApplicationContext的介绍,以及getBeansOfType方法的应用,解决了在实际工作中遇到的接口及多个实现类的问题。同时,文章还提到了SPI使用的不便之处,并介绍了借助ApplicationContext实现需求的方法。阅读本文,你将了解到Spring特性的实现原理和实际应用方式。 ... [详细]
  • Tomcat/Jetty为何选择扩展线程池而不是使用JDK原生线程池?
    本文探讨了Tomcat和Jetty选择扩展线程池而不是使用JDK原生线程池的原因。通过比较IO密集型任务和CPU密集型任务的特点,解释了为何Tomcat和Jetty需要扩展线程池来提高并发度和任务处理速度。同时,介绍了JDK原生线程池的工作流程。 ... [详细]
  • 本文介绍了一个在线急等问题解决方法,即如何统计数据库中某个字段下的所有数据,并将结果显示在文本框里。作者提到了自己是一个菜鸟,希望能够得到帮助。作者使用的是ACCESS数据库,并且给出了一个例子,希望得到的结果是560。作者还提到自己已经尝试了使用"select sum(字段2) from 表名"的语句,得到的结果是650,但不知道如何得到560。希望能够得到解决方案。 ... [详细]
  • FineReport平台数据分析图表显示部分系列接口的应用场景和实现思路
    本文介绍了FineReport平台数据分析图表显示部分系列接口的应用场景和实现思路。当图表系列较多时,用户希望可以自己设置哪些系列显示,哪些系列不显示。通过调用FR.Chart.WebUtils.getChart("chartID").getChartWithIndex(chartIndex).setSeriesVisible()接口,可以获取需要显示的系列图表对象,并在表单中显示这些系列。本文以决策报表为例,详细介绍了实现方法,并给出了示例。 ... [详细]
  • 本文介绍了简书APP的PRD文档规范写法及内容概述。PRD文档的要求因公司、团队或产品而异,本文总结了简书APP的PRD文档框架,包括版本信息、文档说明、产品简介、产品特色、用户分析和产品架构等内容。简书APP致力于提供最好的分享体验,为写作者打造最优秀的写作软件,为阅读者打造最优雅的阅读社区。主要用户为喜欢分享交流、爱生活拥有文艺气息的年轻人,喜爱文字并想在喧嚣网络中沉淀文字的读写人。产品架构包括了主要模块,并应展开至最小用户可见单元。 ... [详细]
  • 在Oracle11g以前版本中的的DataGuard物理备用数据库,可以以只读的方式打开数据库,但此时MediaRecovery利用日志进行数据同步的过 ... [详细]
  • 本文介绍了操作系统的定义和功能,包括操作系统的本质、用户界面以及系统调用的分类。同时还介绍了进程和线程的区别,包括进程和线程的定义和作用。 ... [详细]
  • 合并列值-合并为一列问题需求:createtabletab(Aint,Bint,Cint)inserttabselect1,2,3unionallsel ... [详细]
  • 本文介绍了在Android开发中使用软引用和弱引用的应用。如果一个对象只具有软引用,那么只有在内存不够的情况下才会被回收,可以用来实现内存敏感的高速缓存;而如果一个对象只具有弱引用,不管内存是否足够,都会被垃圾回收器回收。软引用和弱引用还可以与引用队列联合使用,当被引用的对象被回收时,会将引用加入到关联的引用队列中。软引用和弱引用的根本区别在于生命周期的长短,弱引用的对象可能随时被回收,而软引用的对象只有在内存不够时才会被回收。 ... [详细]
author-avatar
巴黎不快乐123
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有