关于人人车数据平台,水永老师主要分享了4部分内容:
\n第一部分,整体的架构;
\n第二部分,Web IDE的实时计算平台;
\n第三部分,对于离线结果的BI报表平台;
\n第四部分,移动端的数据驱动实践。
\n整体架构
\n1. 数据门户中涵盖几个平台:
\nBI报表、元数据管理、实时计算平台、自助取数平台、数据工单平台、监控平台。
\n2. 数据平台的发展历程:
\n元数据管理平台、BI报表平台、实时计算平台、监控平台、自助取数平台、数据工单平台、统一数据权限平台
\n3. 大数据平台的整体架构:
\nOne data,如图,最左边是数据源,有日志、埋点、MySQL、SDK,最后统一落在Hadoop上。避免数据烟囱,降低计算、存储成本,保障数据指标口径一致,各种场景下看到的数据一致性,为上层建立了统一的数据服务层One service奠基。
\nOne service,数据的下游使用方很多,不可能让每个使用的人直接查表,库。在这种状态下定义一个Service层,也就是api层,对外暴露查询服务。这些是service层以下的引擎,底层有很多的引擎,对上层应用来说是无感知的。比如时序数据库Druid,包括SQL on Hadoop模式的Presto,spark SQL。还有一些列式存储的数据库,比如ClickHouse。数据的使用通过数据元数据平台申请,按表级别粒度管控。Service层保证数据的一致性,不论是查Druid,还是ClickHouse,拿到的数据是一样的。如果是小量数据则是restful api,大批量数据则是下载任务。
\nOne meta,统一的元数据管理,包含数据地图,指标管理,权限管控。元数据可能是最后一块要攻克的高地了,元数据是数据的数据,即数据的骨架。承载底层数据生产的血缘、上层应用报表/指标。使用数据第一步,申请权限,账号。在指标百科中可以看到自己使用的数据指标在哪个仪表盘中,在BI平台的仪表中申请权限,大大提高数据分发使用的效率。有句话说的好,元数据做得好,产品技术下班早。
\n4. 数据的流向
\n如图,左侧是它的分层,从数据源到计算层,到数据通道,到引擎。从下往上,左侧虚线是离线的数据,右侧实线,是实时的数据。
\n首先数据从数据源落到自己的Hadoop集群上。再往上是SQL on Hadoop模式,零延迟,可以快速查到数据。再往上,实时部分,使用Spark Streaming去做Kafka通道的转换,支撑订单预估,风险评估等。
\nLambda架构很理想,但在数据的一致性和准确性的挑战上,大大增加了复杂度。对离线数据和实时数据上的应用和数据流进行拆分,业务分离,对不同的领域用专业的方案去解决。
\n实时计算平台
\n实时计算平台是基于Apache Spark构建的一站式、高性能实时大数据处理平台,提供了一整套Web IDE用于编写SQL,语法检测、调试、发布、监控。对于只会写SQL的BI同学来说,提供SQL语义的流式数据分析能力,可大幅降低流数据分析门槛。BI同学无需关注实现细节(将SQL转化为Spark流式任务),只需选取输入输出表,根据需求编写SQL即可实现一个实时计算任务。平台当前支持MySQL、Kafka两种数据源,并支持异构数据源join,及多流join(限定场景),支持用户自定义UDF,同时为了应对不同的场景需要,支持了三种端到端的消息传输语义:At-least-once、At-most-once、Exactly-once。
\n1. 计算引擎选型
\n实时计算常用的3个选型:Storm,Spark Streaming,Flink。
\n通过如上表格可对三者进行比较,首先淘汰的是Storm,因为它不支持使用SQL。
\n那剩下的就是Spark和Flink了,两者都基于内存计算,而且都支持SQL,尤其Spark在SQL方面做了深层次的优化。
\n虽然两者在流式计算方面做的都比较好。但两者还是有区别的,Spark当前支持两种引擎Streaming和Structured Streaming。Spark Streaming是Micro Batch模式,Structured streaming 即支持Micro Batch模式,又支持continuous模式(以流方式处理)。Flink Streaming以流的方式处理流数据。Spark和Flink当前都可以满足我司在实时方面的需求,鉴于Spark社区更加活跃,更加稳定,而且在SQL优化方面做的比较好,最终选择Spark作为计算引擎。
\n2. 实时计算平台整体架构
\n实时计算数据流如上图所示自左至右。数据源从左侧打点开始,业务RD在前端和后端会由不同的语言打点。通过统一的log打点平台(log.renrenche.com)接受打点过来的数据。数据收集上来之后,开始数据平台接入。数据上来以后做一个解压和还原,还原之后进入到Kafka相应Topic中。实时计算平台将Kafka topic作为数据源,抽象为View进行使用。BI同学编写SQL时可直接作为表查询使用,输出结果可根据实际需要选择输出到Mysql或者Kafka中。 进入到Mysql的数据可直接用于业务需要进行展示,进入Kafka的数据可通过同步工具,同步到ES或者druid中进行报表展示或者实时预警。
\n3. 实时数据管理
\n数据采集端有很多Client进行打点,将数据收集上来,这些数据如何管理?我们强调一个数据工单的平台,其最大的好处是,在下拉单选页面申请一个data job(业务线-部门-功能-xx),并填写其用途,下游消费方。当下游拿到这个data job时,可以在平台上查到Schema,这个Schema就是后续的一个基础。
\n4. 流与表的转换
\n数据处理有一个非常核心的概念就是流和表,在实时里就是一个流,在离线里面就是一个表。Kafka完美的诠释了流和表,因为Kafka既能为数据定义Schema,同时具有一个持久性以及可重放性,所以它能够完美被Spark Streaming/ Structured读取和解释。平台根据Topic对应的Schema,会将其生成一个base view。拿到这个base view之后对于用户来说,将这个流变成了一个表。有了表之后,就可以让用户进行SQL实现一个实时任务,可以对表进行聚合等离线常规操作。也可以异构表join,多流join等操作,底层流join由Spark Structured引擎支持。
\n计算之后的结果要被下游使用,又回写入到kafka中去,谁让kafka是最好的数据通道。实时的特点就是时序性,数据应用一个引擎最好的方式选择一个时序数据库,我们选择了Druid。
\n5. Web IDE
\n左侧上方的是目录树,方便进行项目管理。左中是数据源,包括Mysql和Kafka,亦可以自行添加数据源。左下是管理的UDF,引入进入项目即可使用,为了优化引入的jar包,亦可自行添加自定义UDF。右侧是主界面,写完SQL即可进行调试、排错,以及构造数据验收,屏蔽掉实时环境、DataSet、DStream、RDD等概念。IDE中包含,调试,监控,查看血缘关系功能,对于非实时开发的同学而言,是极低的理解和使用成本,完全可以WEB IDE上自行完成一个实时任务开发。
\n6. 调试
\n自动从数据源Mysql/Kafka中取前几条,填充到每一个字段中去,得到构造数据,亦可以手工自定义数据,即可调试和结果查看。整个过程是与生产环境隔离,在docker环境完成,任务与任务之间相互隔离。
\n7. 监控
\n根据Spark暴露出来的API实现监控流数据的状态,可时刻监控数据流入以及调试延迟信息。
\n8. 血缘关系
\n方便BI同学进行表间依赖关系的梳理,表有类型三种类型:真实表、匿名表、临时表,尤其排查复杂的SQL时,此处一目了然。
\n9. 参数配置
\nWeb IDE 意味着线下IDE的功能都要有,包括可以配置参数,比如配置信息,优化参数等,UDF的配置。对于各个参数要有默认参数。
\n10. 开发-调试-发布
\n手动提交实时任务时都是使用spark-submit,但这种方式并不适合进行自动化提交(依赖客户端环境、上线速度慢、不便查看任务状态),最终确定基于YARN-API进行提交。所有的控制都在一个API中,无需上传依赖jar,上线速度快,也方便查看任务当前状态,同时YARN-API是更友好的API接口。这样就可以很轻易的去封装每个参数。
\n封装YARN-API的过程中包括了调试和发布。在Docker容器中编译调试,验收通过后发布上线,接入生产环境MySQL和Kafka数据。
\n11. 最后总结下实时计算平台的特点:
\nBI报表平台
\n我们的目标是,构建一个小白级拖拽,所见即所得,包含移动端的数据平台。而在技术上需要考虑几个大难点:
\n低延时。包括数据更新低延时、数据查询低延时,在灵活的报表平台上,数据预构建类的引擎几乎不用考虑,需要精心管理索引的成本亦高,能在千万记录级别百余字段的数据基础上,亚秒或秒级别。
\n高并发。低延时的一个克星。没有大内存,MPP架构就难以施展能力。即使有大内存,复杂度和高并发下,同样也难以通过benchmark。
\n同步中全量增量的数据一致性。全量和增量同步还需要考虑主键去重、分区去重,一般的OLAP引擎数据写入都是append模式,几乎不支持update和delete。
\n1. 技术选型
\n在这些眼花撩乱的数据引擎中,各自有着自己特性,在不同的业务体系中,总有他们发挥的场景。我们需要一些标准评估哪个引擎更适合自身的业务场景,POC产品原型验证以及TPC benchmark压测。
\n自古磨刀不误砍柴工,梳理清楚业务场景才能在对每一个引擎做POC时高效靠谱,不至于贸然上船而到后期骑虎难下。若能转化成SQL场景,则在TPC-DS/TPC-H压测下更能科学判断一款引擎的场景能力。前者POC是定性分析,决定引擎能不能;后者TPC是定量分析,决定引擎到底有多强。
\n2. 一见钟情ClickHouse
\n人人车的BI平台选择了ClickHouse,支持较高的并发,支持亿级别量级查询,支持增量、全量同步,支持幂等性去重,支持更新update和删除delete,亚秒级延时,支持SQL。用自身业务的sql跑压测,4台测试机就跑出了10qps/30并发,已经是一见钟情了。
\n列式数据引擎ClickHouse,有很多特别适合BI场景的特性。在我们使用SQL的时候往往查询的列是很少的,列式数据库可以让我们在做聚合等操作时,只需要取出少量的列,可以大大减少内存与外存之间的数据交换。
\nClickHouse性能确实太强悍了,在一台4核8G的机器上,对一亿七千条数据count,跑了3秒多。在第一次没有任何缓存的情况下,多维度group by+order by跑了9秒多。在我们看来ClickHouse如同AK47,简单可靠,性能强悍,手动性强。换言之大部分需要自己配置,如分布式和副本集,数据去重幂等性。Clickhouse已经支持update/delete,方便做数据的更新,但在大数据的性能要求下,ReplacingMergeTree在实践中仍然是更好的选择。
\n3. BI 数据架构
\nClickHouse借用Zookeeper实现集群管理,高效管理副本和分片。副本可以提高集群的稳定性,分片用于做性能的扩展。ClickHouse的副本,不仅可以提高稳定性,还可以提高性能。发来的请求可以均匀的落在副本上,压测过程在几乎性能随之线性增长。
\n4. BI 报表平台
\n单表查询,选择一个表,左侧列出所有字段,亦可自定义配置字段名。拖拽字段到维度和数值上,右侧即会高亮显示可用图表类型。亦可增加对比轴,数据源过滤,图内筛选器,图表生成后前端方便用户自行筛选城市,时间等。
\n图表编辑生成后,三端(PC、Android、IOS)同步原样展示。
\n5. 高级功能
\n生成合表。除了单表查询外,还可以自己写SQL join/union生成新的表,仪表盘中的图表可以在合表的基础上输出。适合一些有能力的分析师对数仓的主题表做深度关联分析。
\n合表的血缘关系,上游的表是否生成,是否同步完成,以及被哪些合表作为源表使用,被哪些图表使用。另外高级用户可以根据自己的权限从数据仓库中查询数据,已经在全家桶中AD-HOC打通。
\n6. 最后总结BI报表平台特点:
\n数据驱动
\n我们线下有两万多人,包括销售,评估师等,线上有上千人,包括运营,产品等。线上做数据分析和线下执行完全不是一个思路,线上的总部可以在web上在几十个仪表盘关注几百个指标,但是线下人员一个手机。
\n其次,要分清线下管理的难点和本质。线下评估师销售面对的是各色各样的人,还要跟黄牛斗争,直面金钱的诱惑(飞单),让员工每天在一个开放的空间里做人性的考验,这种商业模式是不明智的。不要尝试与线下斗智斗勇,犹如秀才带兵打仗,如果没有一个有力的管理抓手,将会在无数次学习中成长。
\n如果管理抓手刚好又能跟数据结合,实现对线下的业务管理和数据管理,这就是数据驱动。
\n数据驱动一直是经常听说,但一直没有亲眼看到的东西,尤其在这种复杂的业务场景中。线上总部数据分析在PC端,做更全面深度分析,制定出与战略相匹配的业务指标,且与业绩直接挂钩。并且特别为线下提供掌上数据移动端(Android,iOS),使得线下随时随地只关注和自己业绩相关指标。考核什么就会得到什么,使线下人员的注意力聚焦自己每天业绩,各层级管理人员数据汇总,无论是在数据流通和人员调动上,管理抓手更为高效。
\n作者介绍:
\n吴水永,人人车大数据平台负责人,DevOps开源项目walle-web.io作者。2016年1月加入人人车,从0到1搭建起BI 报表平台、实时计算平台、元数据管理、Ad-Hoc、ETL、数据工单化等大数据平台,并结合大数据和营销实现平台化用户增长、全渠道营销。
\n本文来自吴水永在 DataFun 社区的演讲,由 DataFun 编辑整理。
\n