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

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

目录

项目解决方案

一、核心业务流程

1、快递单

2、运单

3、干线运输

二、逻辑架构

三、数据流转

四、项目的技术选型

1、流式处理平台

2、分布式计算平台

3、海量数据存储

五、框架软件版本

六、技术亮点

七、服务器资源规划

---

项目解决方案 一、核心业务流程

 

*** 作步骤

说明

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

目的地网点到货清点

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

22

目的地网点分类仓库保存

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

23

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

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

24

目的地网点快递员派送

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

25

收货客户签收

客户签收货物

1、快递单

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

2、运单

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

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

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

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

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

3、干线运输

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

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

二、逻辑架构

 说明：

• 异构数据源

数据源主要有两种方式：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（即席查询）

自助报表

三、数据流转

• 业务数据主要存放到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生态

• 如果对延迟要求不高的情况下，可以使用 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搭建数据服务
• 存储、计算性能调优

七、服务器资源规划

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

用途

主机名

*** 作系统/版本

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

√

---

•  博客主页：https://lansonli.blog.csdn.net
• 欢迎点赞  收藏 ⭐留言  如有错误敬请指正！
• 本文由 Lansonli 原创，首发于 CSDN博客
• 大数据系列文章会每天更新，停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨