提起车好多集团，可能有些人会感到陌生，但提起瓜子二手车、毛豆新车，想必都十分熟悉，脍炙人口的广告语使得大家忽视了这家公司的技术能力。车好多集团旗下拥有瓜子二手车、毛豆新车、车速拍与瓜子养车四大品牌，协同为用户提供新车、二手车交易服务、汽车金融、售后保障、汽车维修保养等全产业链服务。
对汽车而言，大部分用户目前的消费习惯倾向于线上看车、咨询、预约，线下进行交易，这对车好多集团的大数据架构搭建提出了诸多挑战，比如线上与线下数据打通、海量数据分析、利用数据辅助智能化决策等。InfoQ 有幸采访到车好多集团旗下瓜子二手车的大数据及数据仓库方面多位技术工程师，就上述问题展开探讨并了解瓜子大数据技术选型历程。
虽然瓜子只是一家成立 3 年多的创业公司，但业务的快速发展让这家公司在大数据和数据仓库建设方面投入了巨大精力。从最初的四台服务机器到如今的两百多台机器，新车供应链及基础架构技术总监林正位坦言，瓜子大数据平台建设早期更多是需求和问题驱动：数据分析需求，效率不高、稳定性较差等问题让技术团队不得不快速演进迭代。
在数据平台层面，车好多数据平台技术负责人总监刘昊植坦言，早期瓜子存在四大痛点：一是其自身的业务流程过于复杂，导致指标体系的建设很难达成一致；数据仓库分层定义不清晰，按需构建而没有完全契合数仓建模方法论；定制化开发的 BI 平台难以灵活配置各业务线和事业群所需的数据可视化能力；应用多呈点状分布，没有形成一站式智能化数据开发平台。
起初，瓜子大数据架构主要为了满足业务方 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% 的部分，大数据技术专家汪涉洋介绍道，瓜子会探索一些新的解决方案，比如 TiDB、流批处理等，并希望在能力范围内对开源社区进行反哺，以希望对业务场景类似的公司或团队起到积极作用和参考价值，这也是瓜子技术委员会一直在遵守和倡导的原则。刘昊植补充道，瓜子技术委员会在公司发展的各个时期可能会承担不一样的责任和使命。现阶段，该委员会主要负责公司内部整个公司的技术栈收敛和更新，包括架构等各个维度；技术职级体系的规范化和统一；技术交流和培训化等工作，有能力开源并对社区做贡献一直是整个委员会要做的重点方向之一事情。
此外，上述四点技术选型标准也是未来瓜子大数据平台技术变更的重要影响因素，但考虑到变更成本（人力成本、机器成本、学习成本）和风险，刘昊植认为，未来，整个瓜子大数据平台会尽量采用已被验证的开源技术，并集中力量对选定技术方案进行深入研究和探索减少变更，同时瓜子大数据团队也会时刻保持对业界最新技术趋势的跟进但并不拒绝变化。比如，当下 NVMe 磁盘 IO 性能未来存储成本的大幅提升降低可能会带来的分布式架构的变革。
随着云计算的逐渐成熟，很多公司都开始创建高效、灵活的云使用环境，这些环境被部署在服务器、存储和网络资源池中，这类方案通常更具成本效益，可以提高大数据技术和高级分析的投资回报率。
过去几年，云平台大数据服务越来越成熟，单就这一项，主流云厂商可提供的服务列表就达到数十种，本地大数据服务的声音逐渐变小，这在 Cloudera 与 Hortonworks 合并之后尤为明显。实际上，云平台大数据服务和本地大数据服务各有其生存空间和适用场景，瓜子的大数据团队是如何考虑这一问题的呢？
实际上，瓜子云平台总监高永超表示，瓜子云目前已经支持其内部大约三分之二左的业务运行，云本身的弹性扩容和成本优势让其承载了部分瓜子大数据服务，主要是面向最终用户的应用和 ETL 相关的系统需求。
对此，林正位提及，瓜子早期考虑过直接上云，甚至采购过一些第三方数据服务，但最终结果是难以与瓜子的业务需求和发展节奏完全契合。其次，在瓜子的整体技术规划中，整个技术团队希望未来有能力为开源做贡献并分享实践成果，这一想法的前提是瓜子自身必须具备较强的技术实力，因此团队决定在本地自建数据服务，而不是通过云平台获取所有基础能力，而一心扑在上层应用研发。
此外，目前很多企业的上云姿势未必是最佳的，这也导致很多企业没有充分享受到云计算的优势，并可能付出了巨大的成本，从而对这一技术的发展存疑。目前，瓜子已经将较容易享受到云平台优势的任务搬迁上云，而其他大数据服务依旧在本地运行。
高永超表示，瓜子云目前主要满足企业内部对 DevOps 的需求，接下来在 PaaS 层会做出很多改进，以进一步打消业务稳定性顾虑，但目前来看，即便云平台足够成熟且完善，还是存在一些特定应用无法上云，比如网络环境受到严格管制的金融类应用。
采访最后，彭超表示，瓜子大数据未来发展主要围绕满足自身业务需求、平台化能力建设和大数据应用三方面展开。在满足自身业务需求的同时，团队希望有能力回馈社区；对所有大数据使用方提供平台化能力，形成平台化解决方案；针对大数据应用形成通用解决方案并对外提供。
在数据仓库层面，孙强补充道，未来几年会更加关注数据平台化（或者说数据中台）能力，并设计瓜子的数据开发平台和数据治理工具，这其中需要解决数据同步、数据开发、数据运维、数据血缘管理等问题，目前已经进行了一定积累，但还处于早期探索阶段，未来希望可以在这方面有所突破。
截至目前，车好多集团业务遍布全国 200 多个城市，在业务高速发展的背后，不难看出其技术团队做了很多思考和调整。未来，期待其可以将这些技术能力进行一定程度的开放并为行业带来价值。
关注微信
