0
点赞
收藏
分享

微信扫一扫

客快物流大数据项目(三):项目解决方案

西曲风 2022-05-19 阅读 183

项目解决方案

一、核心业务流程

客快物流大数据项目(三):项目解决方案_spark客快物流大数据项目(三):项目解决方案_数据_02


操作步骤



说明



1



客户下单



客户通过微信公众号、微信小程序、App端、官网填写订单,并提交到物流公司的订单管理系统OMS系统。如果通过电话方式下单,将对接到物流公司的呼叫中心,呼叫中心接线员根据客户的描述,在OMS系统中填写订单信息。



2



受理登记、订单分派



快递员收到通知后,联系客户,与客户确认时间、确认要邮寄的货物。快递员上门取件,根据公司的规定,对客户要邮件的货物进行检查、确认



3



快递员上门提货



快递员收到通知后,联系客户,与客户确认时间、确认要邮寄的货物。快递员上门取件,根据公司的规定,对客户要邮件的货物进行检查、确认



4



运单扫描上传



快递员收到客户要邮寄的物件后,进行称重,根据要发往的目的地,进行计划,并现场收费(预付款),打印运单凭证。并扫描运单上传到物流公司OMS,运单会自动与订单建立关联。



5



快件回发货网点



快递员根据收派范围收取快件后,统一将货物运回发货网点



6



发货网点货物交接



快递员将收到的货物统一移交给仓库管理员,仓库管理员根据该快递员收取的货物逐一清点,确认货物准确无误,并依次录单。



7



发货网点收件入仓



仓库管理员将快件进行检查确认,放入到仓库临时存放区。



8



发货网点运单复核



发货物流网点仓库管理员再次清点运单,确保运单与实物匹配。



9



发货网点分类入库



发货物流网点仓库管理员根据货物的种类、运输方向、到达点进行分类入库。



10



发货网点运单整理(电话下单、网点下单)



发货物流网点分类整理运单,并交接给录单员录单。



11



发货网点分拣快件



对当班次中转的快件分拣,分开需要建包或装袋的快件



12



发货网点快件包装



将统一目的地的快件,进行打包装袋



13



发货网点配载装车



仓库管理员根据车辆容载进行合理配载,填好货物装车清单



14



发货网点封车



仓库管理员进行扫码录单,需要将车牌号录入到系统,并打印封车码,贴上封条



15



发货网点发车,开始进入干线运输



16



中转物流网点清点



快递车辆到达中转物流网点后,中转物流网点需要对车辆货物进行清单,确保与运单对应的装车清单货物一致,给回单给发货网点。



17



中转物流网点分类入库



18



货物装车/发车



19



干线运输



20



到达目的仓库



21



目的地网点到货清点



目的地仓库管理员通过巴枪扫码确认,并回单给上一个中转物流网点。



22



目的地网点分类仓库保存



按照类似发货方式分类入库保存。



23



目的地网点办理快件出仓、交接快件



在OMS系统中,系统根据派送区域分配快递员。目的地仓库管理员使用手持中转办理出仓,根据不同收派区域派送员交接。



24



目的地网点快递员派送



目的地网点派送员送货上门。



25



收货客户签收



客户签收货物


1、快递单

快递单指的是 对货物在从发货到签收的全生命流程中, 针对消费者端的一个唯一标记

2、运单

货物在运输的过程中 每一个环节所对应的 具体标记

因为快递企业内部分了许多的小部门,分公司, 有管运输 有管仓储

不同部门和不同部门 或不同公司和公司之间  进行货物传输的一个唯一标记

一个快递单,从产生到结束, 中间会经过许多的运单

一个运单 会包含多个快递单

客快物流大数据项目(三):项目解决方案_数据_03

3、干线运输

干线运输指的是运输的主干线, 在主干线上有最大的运力,一般快件的运行都是由支线去向主干线去汇集, 由主干线运输过去

好处就是 经由 支线 和干线的运输, 成本最低

客快物流大数据项目(三):项目解决方案_spark_04客快物流大数据项目(三):项目解决方案_数据_05

二、逻辑架构

客快物流大数据项目(三):项目解决方案_spark_06客快物流大数据项目(三):项目解决方案_数据_07

 说明:

  • 异构数据源

数据源主要有两种方式:Oracle数据库、MySQL数据库

  • 数据采集平台

数据采集平台负责将异构数据源采集到数据存储平台。分为批量导入以及实时采集两个部分:


实时采集



Oracle数据库采用ogg进行实时采集,MySQL数据库采用Canal进行实时采集。采集到的数据会存放到消息队列临时存储中。


  • 数据存储平台

本次建设的物流大数据平台存储平台较为丰富。因为不同的业务需要,存储分为以下几个部分:


Kafka



作为实时数据的临时存储区,方便进行实时ETL处理



Kudu



与Impala mpp计算引擎对接,支持更新,也支持大规模数据的存储



HDFS



存储温数据、冷数据。大规模的分析将基于HDFS存储进行计算。



ElasticSearch



所有业务数据的查询都将基于ElasticSearch来实现



ClickHouse



实时OLAP分析


  • 数据计算平台

数据计算平台主要分为离线计算和实时计算。


离线计算



Impala:提供准实时的高效率OLAP计算、以及快速的数据查询



Spark/ Spark-SQL:大批量数据的作业将以Spark方式运行



实时计算



采用StructuredStreaming开发实时ETL业务


  • 大数据平台应用


离线场景



报表系统



小区画像



实时场景



DashBoard



业务监控



实时报表



交互查询



AdHoc(即席查询)



自助报表


三、数据流转

客快物流大数据项目(三):项目解决方案_数据_08客快物流大数据项目(三):项目解决方案_spark_09

  • 业务数据主要存放到Oracle和Mysql数据库中
  • OGG和Canal分别将Oracle和Mysql的增量数据同步到kafka集群,然后通过Structure Streaming程序进行实时ETL处理,将处理的结果写入到Kudu数据库中,供应用平台进行分析处理
  • 使用Spark与Kudu整合,进行一些ETL处理后,将数据导入到Kudu中,方便进行数据的准实时分析、查询。
  • 为了将一些要求监控的业务实时展示,Structure Streaming流处理会将数据写入到ClickHouse,Java Web后端直接将数据查询出来进行展示。
  • 为了方便业务部门对各类单据的查询,Structure Streaming流式处理系统同时也将数据经过JOIN处理后,将数据写入到Elastic Search中,然后基于Spring Cloud开发能够支撑高并发访问的数据服务,方便运营人员、客户的查询。

四、项目的技术选型

1、流式处理平台

采用Kafka作为消息传输中间介质(事件总线\消息总线)

  • kafka对比其他MQ的优点


可扩展



Kafka集群可以透明的扩展,增加新的服务器进集群。



高性能



Kafka性能远超过传统的ActiveMQ、RabbitMQ等,Kafka支持Batch操作。



容错性



Kafka每个Partition数据会复制到几台服务器,当某个Broker失效时,Zookeeper将通知生产者和消费者从而使用其他的Broker。


  • kafka对比其他MQ的缺点


重复消息



Kafka保证每条消息至少送达一次,虽然几率很小,但一条消息可能被送达多次。



消息乱序



Kafka某一个固定的Partition内部的消息是保证有序的,如果一个Topic有多个Partition,partition之间的消息送达不保证有序。



复杂性



Kafka需要Zookeeper的支持,Topic一般需要人工创建,部署和维护比一般MQ成本更高。


  • kafka对比其他MQ的使用场景


Kafka



主要用于处理活跃的流式数据,大数据量的数据处理上



其他MQ



用在对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量还在其次,更适合于企业级的开发


  • 总结





数据可靠性



延迟



单机吞吐



社区



客户端



ActiveMQ





/



万级



不太活跃



支持全面



RabbitMQ





微秒级



万级



活跃



支持全面



Kafka





毫秒级



十万级



活跃



支持全面



RocketMQ





毫秒级



十万级



有待加强



有待加强


2、分布式计算平台

分布式计算采用Spark生态

客快物流大数据项目(三):项目解决方案_数据_10

  • 如果对延迟要求不高的情况下,可以使用 Spark Streaming,它拥有丰富的高级 API,使用简单,并且 Spark 生态也比较成熟,吞吐量大,部署简单,社区活跃度较高,从 GitHub 的 star 数量也可以看得出来现在公司用 Spark 还是居多的,并且在新版本还引入了Structured Streaming,这也会让 Spark 的体系更加完善。
  • 如果对延迟性要求非常高的话,可以使用当下最火的流处理框架 Flink,采用原生的流处理系统,保证了低延迟性,在 API 和容错性方面做的也比较完善,使用和部署相对来说也是比较简单的,加上国内阿里贡献的 Blink,相信接下来 Flink 的功能将会更加完善,发展也会更加好,社区问题的响应速度也是非常快的,另外还有专门的钉钉大群和中文列表供大家提问,每周还会有专家进行直播讲解和答疑。

结论:


本项目使用Structured Streaming开发实时部分,同时离线计算使用到SparkSQL,而Spark的生态相对于Flink更加成熟,因此采用Spark开发


3、海量数据存储

ETL后的数据存储到Kudu中,供离线、准实时查询、分析

Kudu是一个与hbase类似的列式存储分布式数据库

官方给kudu的定位是:在更新更及时的基础上实现更快的数据分析

  • Kudu对比其他列式存储(Hbase、HDFS)


HDFS



使用列式存储格式Apache Parquet,Apache ORC,适合离线分析,不支持单条纪录级别的update操作,随机读写性能差



HBASE



可以进行高效随机读写,却并不适用于基于SQL的数据分析方向,大批量数据获取时的性能较差。



KUDU



KUDU较好的解决了HDFS与HBASE的这些缺点,它不及HDFS批处理快,也不及HBase随机读写能力强,但是反过来它比HBase批处理快(适用于OLAP的分析场景),而且比HDFS随机读写能力强(适用于实时写入或者更新的场景),这就是它能解决的问题。


HBase和Kudu这一类的数据库, 不是用来做计算的, 而是做`高吞吐存取`的作用

比如:有一个非常复杂的业务查询

  1. 用SQL写
  2. SELECT * 后 用代码处理

不管是OLAP还是OLTP 都是2最好

Elastic Search作为单据数据的存储介质,供顾客查询订单信息

  • Elastic Search的使用场景

ES是一个文档型的NoSQL数据库, 特点是: 全文检索


记录和日志分析



围绕Elasticsearch构建的生态系统使其成为最容易实施和扩展日志记录解决方案之一,利用这一点来将日志记录添加到他们的主要用例中,或者将我们纯粹用于日志记录。



采集和组合公共数据



Elasticsearch可以灵活地接收多个不同的数据源,并能使得这些数据可以管理和搜索



全文搜索



非常强大的全文检索功能,方便顾客查询订单相关的数据



事件数据和指标



Elasticsearch还可以很好地处理时间序列数据,如指标(metrics )和应用程序事件



数据可视化




凭借大量的图表选项,地理数据的平铺服务和时间序列数据的TimeLion,Kibana是一款功能强大且易于使用的可视化工具。对于上面的每个用例,Kibana都会处理一些可视化组件。


ClickHouse作为实时数据的指标计算存储数据库

  • ClickHouse与其他的OLAP框架的比较


商业OLAP数据库




例如:HP Vertica, Actian the Vector。
区别:ClickHouse是开源而且免费的。



云解决方案




例如:亚马逊RedShift和谷歌的BigQuery
区别:ClickHouse可以使用自己机器部署,无需为云付费



Hadoop生态软件




例如:Cloudera Impala, Spark SQL, Facebook Presto , Apache Drill
区别:

ClickHouse支持实时的高并发系统

ClickHouse不依赖于Hadoop生态软件和基础

ClickHouse支持分布式机房的部署



开源OLAP数据库




例如:InfiniDB, MonetDB, LucidDB
区别:这些项目的应用的规模较小,并没有应用在大型的互联网服务当中,相比之下,ClickHouse的成熟度和稳定性远远超过这些软件



开源分析




例如:Druid , Apache Kylin
区别:ClickHouse可以支持从原始数据的直接查询,ClickHouse支持类SQL语言,提供了传统关系型数据的便利


五、框架软件版本


Centos



7.5



Cloudera Manager



6.2.1



Hadoop



3.0.0+cdh6.2.1



ZooKeeper



3.4.5+cdh6.2.1



Kafka



2.1.0+cdh6.2.1



Scala



2.11



Spark



2.4.0-cdh6.2.1



Clickhouse



0.22



Oracle



11g



Mysql



5.7



Canal



1.1.2



Kudu



1.9.0+cdh6.2.1



Azkaban



3.71.0



ElasticSearch



7.6.1



Impala



3.2.0+cdh6.2.1



HUE



4.3.0+cdh6.2.1



Spring Cloud



Hoxton.SR6



NodeJS



12.18.2



VUE



2.13.3


注意:


在项目实施中,框架版本选型尽可能不要选择最新的版本,选择最新框架半年前左右的稳定版本。


六、技术亮点

  • 完整Lambda架构系统,有离线业务、也有实时业务
  • ClickHouse实时存储、计算引擎
  • Kudu + Impala准实时分析系统
  • 基于Docker搭建异构数据源,还原企业真实应用场景
  • 以企业主流的Spark生态圈为核心技术,例如:Spark、Spark SQL、structured Streaming
  • ELK全文检索
  • Spring Cloud搭建数据服务
  • 存储、计算性能调优

七、服务器资源规划

客快物流大数据项目(三):项目解决方案_spark_11客快物流大数据项目(三):项目解决方案_kafka_12

因服务器资源有限,该项目采用两台服务器进行演示,每台服务器配置如下:


用途



主机名



操作系统/版本



IP



内存



硬盘



业务系统服务器



node1



Centos/7.5.1804



192.168.88.10



3GB



40G



大数据服务器



node2



Centos/7.5.1804



192.168.88.20



12GB



60G


使用到的软件信息:


服务器



node1



node2



Docker








Oracle(11g)








OGG








MySql 5.7








Canal








Hadoop








Spark








Kafka








ClickHouse








ElasticSearch








Kudu








Azkaban








Impala








HUE







举报

相关推荐

0 条评论