目录
项目解决方案
一、核心业务流程
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 | 目的地网点到货清点 |
目的地仓库管理员通过巴枪扫码确认，并回单给上一个中转物流网点。 | |
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这一类的数据库, 不是用来做计算的, 而是做`高吞吐存取`的作用
比如:有一个非常复杂的业务查询
- 用SQL写
- 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 | √ |
