大数平台整体架构选型

⼤数平台整体架构选型
数据处理分为三⼤类：
第⼀类是从业务的⾓度，细分为查询检索、数据挖掘、统计分析、深度分析，其中深度分析分为机器学习和神经⽹络。

第⼆类是从技术的⾓度，细分为Batch、SQL、流式处理、machine learning、Deep learning。

第三类是编程模型，细分为离线编程模型、内存编程模型、实时编程模型。

结合前⽂讲述的数据源特点、分类、采集⽅式、存储选型、数据分析、数据处理，我在这⾥给出⼀个总体的⼤数据平台的架构。

值得注意的是，架构图中去掉了监控、资源协调、安全⽇志等。

⼤数据平台整体架构思考
左侧是数据源，有实时流的数据（可能是结构化、⾮结构化，但其特点是实时的），有离线数据，离线数据⼀般采⽤的多为ETL的⼯具，常见的做法是在⼤数据平台⾥使⽤Sqoop或Flume去同步数据，或调⼀些NIO的框架去读取加载，然后写到HDFS⾥⾯，当然也有⼀些特别的技术存储的类型，⽐如HAWQ就是⼀个⽀持分布式、⽀持事务⼀致性的开源数据库。

从业务场景来看，如果我们做统计分析，就可以使⽤SQL或MapReduce或streaming或Spark。

如果做查询检索，同步写到HDFS的同时还要考虑写到ES⾥。

如果做数据分析，可以建⼀个Cube，然后再进⼊OLAP的场景。

为了⽀持这么多功能，我们怎么搭建我们的数据平台的呢？
Lambda架构
Lambda架构的主要思想是将⼤数据系统架构为多层个层次，分别为批处理层（batchlayer）、实时处理层（speedlayer）、服务层（servinglayer）如图（C）。

理想状态下，任何数据访问都可以从表达式Query= function(alldata)开始，但是，若数据达到相当⼤的⼀个级别（例如PB），且还需要⽀持实时查询时，就需要耗费⾮常庞⼤的资源。

⼀个解决⽅式是预运算查询函数（precomputedquery funciton）。

书中将这种预运算查询函数称之为Batch View（A），这样当需要执⾏查询时，可以从BatchView中读取结果。

这样⼀个预先运算好的View是可以建⽴索引的，因⽽可以⽀持随机读取（B）。

于是系统就变成：
（A）batchview = function(all data)；
（B）query =function(batch view)。

Lambda架构组件选型
下图给出了Lambda架构中各组件在⼤数据⽣态系统中和阿⾥集团的常⽤组件。

数据流存储选⽤不可变⽇志的分布式系统Kafa、TT、Metaq；BatchLayer数据集的存储选⽤Hadoop的HDFS或者阿⾥云的ODPS；BatchView的加⼯采⽤MapReduce；BatchView数据的存储采⽤Mysql（查询少量的最近结果数据）、Hbase（查询⼤量的历史结果数据）。

SpeedLayer采⽤增量数据处理Storm、Flink；RealtimeView增量结果数据集采⽤内存数据库Redis。

图（H）
Lambda是⼀个通⽤框架，各模块选型不要局限于上⾯给出的组件，特别是view的选型。

因为View是和各业务关联⾮常⼤的概念，View选择组件时要根据业务的需求，选择最合适的组件。

Lambda架构的评估
优点：
a、数据的不可变性。

⾥⾯给出的数据传输模型是在初始化阶段对数据进⾏实例化，这样的做法是能获益良多的。

能够使得⼤量的MapReduce⼯作变得有迹可循，从⽽便于在不同阶段进⾏独⽴调试。

b、强调了数据的重新计算问题。

在流处理中重新计算是个主要挑战，但是经常被忽视。

⽐⽅说，某⼯作流的数据输出是由输⼊决定的，那么⼀旦代码发⽣改动，我们将不得不重新计算来检视变更的效度。

什么情况下代码会改动呢？例如需求发⽣变更，计算字段需要调整或者程序发出错误，需要进⾏调试。

缺点：
a、Jay Kreps认为Lambda包含固有的开发和运维的复杂性。

Lambda需要将所有的算法实现两次，⼀次是为批处理系统，另⼀次是为实时系统，还要求查询得到的是两个系统结果的合并。

由于存在以上缺点，Linkedin的Jaykreps提出了Kappa架构如图（I）：
图（I）
1、使⽤Kafka或其它系统来对需要重新计算的数据进⾏⽇志记录，以及提供给多个订阅者使⽤。

例如需要重新计算30天内的数据，我们可以
在Kafka中设置30天的数据保留值。

2、当需要进⾏重新计算时，启动流处理作业的第⼆个实例对之前获得的数据进⾏处理，之后直接把结果数据放⼊新的数据输出表中。

3、当作业完成时，让应⽤程序直接读取新的数据记录表。

4、停⽌历史作业，删除旧的数据输出表。

Kappa架构暂时未做深⼊了解，在此不做评价。

我个⼈觉得，不同的数据架构有各⾃的优缺点，我们使⽤的时候只能根据应⽤场景，选择更合适的架构，才能扬长避短。

flume + Hadoop
在具体介绍本⽂内容之前，先给⼤家看⼀下Hadoop业务的整体开发流程：
这⾥写图⽚描述
从Hadoop的业务开发流程图中可以看出，在⼤数据的业务处理过程中，对于数据的采集是⼗分重要的⼀步，也是不可避免的⼀步，从⽽引出我们本⽂的主⾓—Flume。

本⽂将围绕Flume的架构、Flume的应⽤(⽇志采集)进⾏详细的介绍。

flume的特点：
flume是⼀个分布式、可靠、和⾼可⽤的海量⽇志采集、聚合和传输的系统。

⽀持在⽇志系统中定制各类数据发送⽅，⽤于收集数据;同时，Flume提供对数据进⾏简单处理，并写到各种数据接受⽅(⽐如⽂本、HDFS、Hbase等)的能⼒。

flume的数据流由事件(Event)贯穿始终。

事件是Flume的基本数据单位，它携带⽇志数据(字节数组形式)并且携带有头信息，这些Event 由Agent外部的Source⽣成，当Source捕获事件后会进⾏特定的格式化，然后Source会把事件推⼊(单个或多个)Channel中。

你可以把Channel看作是⼀个缓冲区，它将保存事件直到Sink处理完该事件。

Sink负责持久化⽇志或者把事件推向另⼀个Source。

Kafka + Hbase + Phoenix
先看⼀下我们数据处理的主要步骤，⾸先是我们SDK采集数据，采集数据之后，⾸先把它扔到我们的消息队列⾥做⼀个基础的持久化，之后我们会有两部分，⼀部分是实时统计，⼀部分是离线统计，这两部分统计完之后会把统计结果存下来，然后提供给我们的查询服务，最后是我们外部展⽰界⾯。

我们的数据平台主要基于中间的四个绿⾊的部分。

关于要求，对消息队列来说肯定是吞吐量⼀定要⼤，要⾮常好的扩展性，如果有⼀个消息的波峰的话要随时能够扩展，因为所有的东西都是分布式的，所以要保证节点故障不会影响我们正常的业务。

我们的实时计算⽬前采⽤的是分钟级别的实时，没有精确到秒级，离线计算需要计算速度⾮常快，这两部分我们当初在考虑的时候就选⽤了Spark，因为Spark本⾝既⽀持实时，⼜⽀持离线，⽽且相对于其他的实时的⽅案来说，像Flink或者是Storm和Samza来说，我们不需要到秒级的这种实时，我们需要的是吞吐量，所以我们选择Spark。

实时部分⽤的是Spark streaming，离线部分⽤的是Spark offline的⽅案。

查询⽅案因为我们要⽀持多个维度的组合排序，所以我们希望⽀持sql，这样的话各种组合排序就可以转化成sql的group和order操作。

消息队列 -- Kafka
消息队列我们选择的是Kafka，因为在我们看来，Kafka⽬前是最成熟的分布式消息队列⽅案，⽽且它的性能、扩展性也⾮常好，⽽且⽀持容错⽅案，你可以通过设置冗余来保证数据的完整性。

Kafka⽬前得到了所有主流流式计算框架的⽀持，像Spark, Flink, Storm, Samza等等；另外⼀个就是我们公司的⼏个创始⼈都来⾃于LinkedIn，他们之前在LinkedIn的时候就已经⽤过Kafka，对Kafka⾮常熟，所以我们选择了Kafka。

消息时序 -- HBase
但选定Kafka之后我们发现了⼀个问题就是消息时序的问题。

⾸先我们的数据采集程中，因为不同的⽤户⽹络带宽不⼀样，数据可能是有延迟的，晚到的消息反⽽可能更早发⽣，⽽且Kafka不同的partition之间是不保证时序的。

但是我们所有的离线统计程序都是需要按时间统计的，所以我们就需要⼀个⽀持时序的数据库帮我们把数据排好序，这⾥我们选了HBase。

我们⽤消息产⽣的时间加上我们⽣成消息的ID做成它唯⼀的row key，进⾏排序和索引。

SQL On HBase -- Apache Phoenix
对于sql的⽅案来说，我们选择的是Phoenix。

选Phoenix是因为我们考虑了⽬前⼏个SQL On HBase的⽅案，我们发现Phoenix的效率⾮常好，是因为它充分的利⽤了HBase coprocessor的特性，在server端进⾏了⼤量的计算，所以⼤量减轻了client的数据压⼒还有计算压⼒。

还有就是它⽀持HBase的Column Family概念，⽐如说我们要⽀持40个纬度的时候我们会有⼀张⼤宽表，如果我们把所有的列都设置⼀个列
族的话，在查询任意⼀个列的时候都需要把40列的数据都读出来，这样是得不偿失的，所以Phoenix⽀持Column Family的话，我们就可以把不同的列根据它们的相关性分成⼏个列族，查询的时候可能只会命中⼀个到两个列族，这样⼤⼤减少了读取量。

Phoenix还⽀持Spark的DataSource API，⽀持列剪枝和⾏过滤的功能，⽽且⽀持数据写⼊。

什么是Spark的DataSource API呢， Spark在1.2的时候提供了DataSource API，它主要是给Spark框架提供⼀种快速读取外界数据的能⼒，这个API可以⽅便的把不同的数据格式通过DataSource API注册成Spark的表，然后通过Spark SQL直接读取。

它可以充分利⽤Spark分布式的优点进⾏并发读取，⽽且Spark本⾝有⼀个很好的优化引擎，能够极⼤的加快Spark SQL的执⾏。

因为Spark最近⾮常的⽕，所以它的社区资源⾮常的多，基本上所有主流的框架，像我们常见的Phoenix，Cassandra, MongoDB都有Spark DataSource相关的实现。

还有⼀个就是它提供了⼀个统⼀的数据类型，把所有的外部表都统⼀转化成Spark的数据类型，这样的话不同的外部表能够相互的关联和操作。

在经过上述的思考之后，我们选择了这样的⼀个数据框架。

⾸先我们最下⾯是三个SDK，JS、安卓和iOS，采集完数据之后会发到我们的负载均衡器，我们的负载均衡器⽤的是AWS，它会⾃动把我们这些数据发到我们的server端，server在收集完数据之后会进⾏⼀个初步的清洗，把那些不规律的数据给清洗掉，然后再把那些数据发到Kafka⾥，后⾯就进⼊到我们的实时和离线过程。

最终我们的数据会统计到HBase⾥⾯，对外暴露的是⼀个sql的接⼝，可以通过各种sql的组合去查询所需要的统计数据。

⽬前我们⽤的主要版本，Spark⽤的还是1.5.1，我们⾃⼰根据我们⾃⼰的业务需求打了⼀些定制的patch，Hadoop⽤的还是2.5.2，HBase是0.98，Phoenix是4.7.0，我们修复了⼀些⼩的bug，以及加了⼀些⾃⼰的特性，打了⾃⼰的patch。

Hadoop危机？替代HDFS的8个绝佳⽅案
Ceph 是⼀个开源、多管齐下的操作系统，因为其⾼性能并⾏⽂件系统的特性，有⼈甚⾄认为它是基于Hadoop环境下的HDFS的接班⼈，因为⾃2010年就有研究者在寻找这个特性。

Apache Flink
Apache Flink是⼀种可以处理批处理任务的流处理框架。

该技术可将批处理数据视作具备有限边界的数据流，借此将批处理任务作为流处理的⼦集加以处理。

为所有处理任务采取流处理为先的⽅法会产⽣⼀系列有趣的副作⽤。

这种流处理为先的⽅法也叫做Kappa架构，与之相对的是更加被⼴为⼈知的Lambda架构（该架构中使⽤批处理作为主要处理⽅法，使⽤流作为补充并提供早期未经提炼的结果）。

Kappa架构中会对⼀切进⾏流处理，借此对模型进⾏简化，⽽这⼀切是在最近流处理引擎逐渐成熟后才可⾏的。

流处理模型
Flink的流处理模型在处理传⼊数据时会将每⼀项视作真正的数据流。

Flink提供的DataStream API可⽤于处理⽆尽的数据流。

Flink可配合使⽤的基本组件包括：
Stream（流）是指在系统中流转的，永恒不变的⽆边界数据集
Operator（操作⽅）是指针对数据流执⾏操作以产⽣其他数据流的功能
Source（源）是指数据流进⼊系统的⼊⼝点
Sink（槽）是指数据流离开Flink系统后进⼊到的位置，槽可以是数据库或到其他系统的连接器
为了在计算过程中遇到问题后能够恢复，流处理任务会在预定时间点创建快照。

为了实现状态存储，Flink可配合多种状态后端系统使⽤，具体取决于所需实现的复杂度和持久性级别。

此外Flink的流处理能⼒还可以理解“事件时间”这⼀概念，这是指事件实际发⽣的时间，此外该功能还可以处理会话。

这意味着可以通过某种有趣的⽅式确保执⾏顺序和分组。

批处理模型
Flink的批处理模型在很⼤程度上仅仅是对流处理模型的扩展。

此时模型不再从持续流中读取数据，⽽是从持久存储中以流的形式读取有边界的数据集。

Flink会对这些处理模型使⽤完全相同的运⾏时。

Flink可以对批处理⼯作负载实现⼀定的优化。

例如由于批处理操作可通过持久存储加以⽀持，Flink可以不对批处理⼯作负载创建快照。

数据依然可以恢复，但常规处理操作可以执⾏得更快。

另⼀个优化是对批处理任务进⾏分解，这样即可在需要的时候调⽤不同阶段和组件。

借此Flink可以与集群的其他⽤户更好地共存。

对任务提前进⾏分析使得Flink可以查看需要执⾏的所有操作、数据集的⼤⼩，以及下游需要执⾏的操作步骤，借此实现进⼀步的优化。

优势和局限
Flink⽬前是处理框架领域⼀个独特的技术。

虽然Spark也可以执⾏批处理和流处理，但Spark的流处理采取的微批架构使其⽆法适⽤于很多
⽤例。

Flink流处理为先的⽅法可提供低延迟，⾼吞吐率，近乎逐项处理的能⼒。

Flink的很多组件是⾃⾏管理的。

虽然这种做法较为罕见，但出于性能⽅⾯的原因，该技术可⾃⾏管理内存，⽆需依赖原⽣的Java垃圾回收机制。

与Spark不同，待处理数据的特征发⽣变化后Flink⽆需⼿⼯优化和调整，并且该技术也可以⾃⾏处理数据分区和⾃动缓存等操作。

Flink会通过多种⽅式对⼯作进⾏分许进⽽优化任务。

这种分析在部分程度上类似于SQL查询规划器对关系型数据库所做的优化，可针对特定任务确定最⾼效的实现⽅法。

该技术还⽀持多阶段并⾏执⾏，同时可将受阻任务的数据集合在⼀起。

对于迭代式任务，出于性能⽅⾯的考虑，Flink会尝试在存储数据的节点上执⾏相应的计算任务。

此外还可进⾏“增量迭代”，或仅对数据中有改动的部分进⾏迭代。

在⽤户⼯具⽅⾯，Flink提供了基于Web的调度视图，借此可轻松管理任务并查看系统状态。

⽤户也可以查看已提交任务的优化⽅案，借此了解任务最终是如何在集群中实现的。

对于分析类任务，Flink提供了类似SQL的查询，图形化处理，以及机器学习库，此外还⽀持内存计算。

Flink能很好地与其他组件配合使⽤。

如果配合Hadoop 堆栈使⽤，该技术可以很好地融⼊整个环境，在任何时候都只占⽤必要的资源。

该技术可轻松地与YARN、HDFS和Kafka 集成。

在兼容包的帮助下，Flink还可以运⾏为其他处理框架，例如Hadoop和Storm编写的任务。

⽬前Flink最⼤的局限之⼀在于这依然是⼀个⾮常“年幼”的项⽬。

现实环境中该项⽬的⼤规模部署尚不如其他处理框架那么常见，对于Flink在缩放能⼒⽅⾯的局限⽬前也没有较为深⼊的研究。

随着快速开发周期的推进和兼容包等功能的完善，当越来越多的组织开始尝试时，可能会出现越来越多的Flink部署。

总结
Flink提供了低延迟流处理，同时可⽀持传统的批处理任务。

Flink也许最适合有极⾼流处理需求，并有少量批处理任务的组织。

该技术可兼容原⽣Storm和Hadoop程序，可在YARN管理的集群上运⾏，因此可以很⽅便地进⾏评估。

快速进展的开发⼯作使其值得被⼤家关注。

Spark or Flink or hadoop or Storm 总结
⼤数据系统可使⽤多种处理技术。

对于仅需要批处理的⼯作负载，如果对时间不敏感，⽐其他解决⽅案实现成本更低的Hadoop将会是⼀个好选择。

对于仅需要流处理的⼯作负载，Storm可⽀持更⼴泛的语⾔并实现极低延迟的处理，但默认配置可能产⽣重复结果并且⽆法保证顺序。

Samza与YARN和Kafka紧密集成可提供更⼤灵活性，更易⽤的多团队使⽤，以及更简单的复制和状态管理。

对于混合型⼯作负载，Spark可提供⾼速批处理和微批处理模式的流处理。

该技术的⽀持更完善，具备各种集成库和⼯具，可实现灵活的集成。

Flink提供了真正的流处理并具备批处理能⼒，通过深度优化可运⾏针对其他平台编写的任务，提供低延迟的处理，但实际应⽤⽅⾯还为时过早。

最适合的解决⽅案主要取决于待处理数据的状态，对处理所需时间的需求，以及希望得到的结果。

具体是使⽤全功能解决⽅案或主要侧重于某种项⽬的解决⽅案，这个问题需要慎重权衡。

随着逐渐成熟并被⼴泛接受，在评估任何新出现的创新型解决⽅案时都需要考虑类似的问题。

数据存储: HBase vs Cassandra
HBase Cassandra
语⾔Java Java
出发点BigTable BigTable and Dynamo
License Apache Apache
Protocol HTTP/REST (also Thrift)Custom, binary (Thrift)
数据分布表划分为多个region存在不同region server上改进的⼀致性哈希（虚拟节点）
存储⽬标⼤⽂件⼩⽂件
⼀致性强⼀致性最终⼀致性，Quorum NRW策略
架构master/slave p2p
⾼可⽤性NameNode是HDFS的单点故障点P2P和去中⼼化设计，不会出现单点故障
伸缩性Region Server扩容，通过将⾃⾝发布到
Master，Master均匀分布Region扩容需在Hash Ring上多个节点间调整数据分布
读写性能数据读写定位可能要通过最多6次的⽹络
RPC，性能较低。

数据读写定位⾮常快
数据冲突处理乐观并发控制（optimistic concurrency
control）向量时钟
临时故障处理Region Server宕机，重做HLog数据回传机制：某节点宕机，hash到该节点的新数据⾃动路由到下⼀节点做
hinted handoff，源节点恢复后，推送回源节点。

永久故障恢复Region Server恢复，master重新给其分配
region
Merkle 哈希树，通过Gossip协议同步Merkle Tree，维护集群节点间的数据⼀致
性
成员通信及
错误检测
Zookeeper基于Gossip
CAP1，强⼀致性，0数据丢失。

2，可⽤性低。

3，扩容⽅便。

1，弱⼀致性，数据可能丢失。

2，可⽤性⾼。

3，扩容⽅便。

HBase Cassandra
⼆：部署运维
单纯的就部署和运维hbase以及Cassandra来说，部署hbase前，需要部署的组件有zookeeper，hdfs，然后才是hbase。

对应的Cassandra 就⽐较简单很多，编译完成⼀个jar包，单台服务器启动⼀个Cassandra进程即可。

在部署hbase的时候，可能需要规划好，哪些机器跑hmaser，rs,zk,hdfs的相关进程等，还有可能为了集群的性能，还要预先规划好多少个rs。

⾃⼰⼈⼯去部署这么⼀个hbase集群还是⽐较⿇烦的，更别提⾃⼰维护（阿⾥云ApsaraDB-HBase你值得拥有）。

Cassandra部署的时候⽐较简单，⼀个tar包搞定，由于cassandra数据落本地盘，需要⼈为的配置⼀些参数⽐如是否需要虚拟节点（vnode）以及多少vnode；需要基于业务的场景选择特定的key的放置策略（partitioner），这个放置策略的选择以及⼀些参数的配置需要⼀定的门槛。

简单总结下：部署运维的话，hbase依赖组件多，部署⿇烦⼀点，但是相关资料很多，降低了难度；cassandra部署依赖少，但是配置参数多，相关资料较少。

特别是使⽤云HBase完全避免了部署造成的各种⿇烦，⽐⼿⼯部署运维任何⼤数据数据库都⽅便太多。

预测系统架构
整体架构从上⾄下依次是：数据源输⼊层、基础数据加⼯层、核⼼业务层、数据输出层和下游系统。

⾸先从外部数据源获取我们所需的业务数据，然后对基础数据进⾏加⼯清洗，再通过时间序列、机器学习等⼈⼯智能技术对数据进⾏处理分析，最后计算出预测结果并通过多种途径推送给下游系统使⽤。

数据源输⼊层：京东数据仓库中存储着我们需要的⼤部分业务数据，例如订单信息、商品信息、库存信息等等。

⽽对于促销计划数据则⼤部分来⾃于采销⼈员通过Web系统录⼊的信息。

除此之外还有⼀⼩部分数据通过⽂本形式直接上传到HDFS中。

基础数据加⼯层：在这⼀层主要通过Hive对基础数据进⾏⼀些加⼯清洗，去掉不需要的字段，过滤不需要的维度并清洗有问题的数据。

核⼼业务层：这层是系统的的核⼼部分，横向看⼜可分为三层：特征构建、预测算法和预测结果加⼯。

纵向看是由多条业务线组成，彼此之间不发⽣任何交集。

特征构建：将之前清洗过的基础数据通过近⼀步的处理转化成标准格式的特征数据，提供给后续算法模型使⽤。

核⼼算法：利⽤时间序列分析、机器学习等⼈⼯智能技术进⾏销量、单量的预测，是预测系统中最为核⼼的部分。

预测结果加⼯：预测结果可能在格式和⼀些特殊性要求上不能满⾜下游系统，所以还需要根据实际情况对其进⾏加⼯处理，⽐如增加标准差、促销标识等额外信息。

预测结果输出层：将最终预测结果同步回京东数据仓库、MySql、HBase或制作成JSF接⼝供其他系统远程调⽤。

下游系统：包括下游任务流程、下游Web系统和其他系统。

预测系统核⼼介绍预测系统核⼼层技术选型
预测系统核⼼层技术主要分为四层：基础层、框架层、⼯具层和算法层。

基础层：
HDFS⽤来做数据存储，Yarn⽤来做资源调度，BDP（Big Data Platform）是京东⾃⼰研发的⼤数据平台，我们主要⽤它来做任务调度。

框架层：
以Spark RDD、Spark SQL、Hive为主， MapReduce程序占⼀⼩部分，是原先遗留下来的，⽬前正逐步替换成Spark RDD。

选择Spark除了对性能的考虑外，还考虑了Spark程序开发的⾼效率、多语⾔特性以及对机器学习算法的⽀持。

在Spark开发语⾔上我们选择了Python，原因有以下三点：
Python有很多不错的机器学习算法包可以使⽤，⽐起Spark的MLlib，算法的准确度更⾼。

我们⽤GBDT做过对⽐，发现xgboost⽐MLlib⾥⾯提供的提升树模型预测准确度⾼出⼤概5%~10%。

虽然直接使⽤Spark⾃带的机器学习框架会节省我们的开发成本，但预测准确度对于我们来说⾄关重要，每提升1%的准确度，就可能会带来成本的成倍降低。

我们的团队中包括开发⼯程师和算法⼯程师，对于算法⼯程师⽽⾔他们更擅长使⽤Python进⾏数据分析，使⽤Java或Scala会有不⼩的学习成本。

对⽐其他语⾔，我们发现使⽤Python的开发效率是最⾼的，并且对于⼀个新⼈，学习Python⽐学习其他语⾔更加容易。

⼯具层：
⼀⽅⾯我们会结合⾃⾝业务有针对性的开发⼀些算法，另⼀⽅⾯我们会直接使⽤业界⽐较成熟的算法和模型，这些算法都封装在第三⽅Python包中。

我们⽐较常⽤的包有xgboost、numpy、pandas、sklearn、scipy和hyperopt等。

Xgboost：它是Gradient Boosting Machine的⼀个C++实现，xgboost最⼤的特点在于，它能够⾃动利⽤CPU的多线程进⾏并⾏，同时在算法上加以改进提⾼了精度。

numpy：是Python的⼀种开源的数值计算扩展。

这种⼯具可⽤来存储和处理⼤型矩阵，⽐Python⾃⾝的嵌套列表结构要⾼效的多（该结构也可以⽤来表⽰矩阵）。

pandas：是基于NumPy 的⼀种⼯具，该⼯具是为了解决数据分析任务⽽创建的。

Pandas 纳⼊了⼤量库和⼀些标准的数据模型，提供了⾼效地操作⼤型数据集所需的⼯具。

sklearn：是Python重要的机器学习库，⽀持包括分类、回归、降维和聚类四⼤机器学习算法。

还包含了特征提取、数据处理和模型评估三⼤模块。

scipy：是在NumPy库的基础上增加了众多的数学、科学以及⼯程计算中常⽤的库函数。

例如线性代数、常微分⽅程数值求解、信号处理、图像处理和稀疏矩阵等等。

算法层：
我们⽤到的算法模型⾮常多，原因是京东的商品品类齐全、业务复杂，需要根据不同的情况采⽤不同的算法模型。

我们有⼀个独⽴的系统来为算法模型与商品之间建⽴匹配关系，有些⽐较复杂的预测业务还需要使⽤多个模型。

我们使⽤的算法总体上可以分为三类：时间序列、机器学习和结合业务开发的⼀些独有的算法。

1. 机器学习算法主要包括GBDT、LASSO和RNN ：
GBDT：是⼀种迭代的决策树算法，该算法由多棵决策树组成，所有树的结论累加起来做最终答案。

我们⽤它来预测⾼销量，但历史规律不明显的商品。

RNN：这种⽹络的内部状态可以展⽰动态时序⾏为。

不同于前馈神经⽹络的是，RNN可以利⽤它内部的记忆来处理任意时序的输⼊序列，这让它可以更容易处理如时序预测、语⾳识别等。

LASSO：该⽅法是⼀种压缩估计。

它通过构造⼀个罚函数得到⼀个较为精炼的模型，使得它压缩⼀些系数，同时设定⼀些系数为零。

因此保留了⼦集收缩的优点，是⼀种处理具有复共线性数据的有偏估计。

⽤来预测低销量，历史数据平稳的商品效果较好。

2. 时间序列主要包括ARIMA和Holt winters ：
ARIMA：全称为⾃回归积分滑动平均模型，于70年代初提出的⼀个著名时间序列预测⽅法，我们⽤它来主要预测类似库房单量这种平稳的序列。

Holt winters：⼜称三次指数平滑算法，也是⼀个经典的时间序列算法，我们⽤它来预测季节性和趋势都很明显的商品。

3. 结合业务开发的独有算法包括WMAStockDT、SimilarityModel和NewProduct等：
WMAStockDT：库存决策树模型，⽤来预测受库存状态影响较⼤的商品。

SimilarityModel：相似品模型，使⽤指定的同类品数据来预测某商品未来销量。

NewProduct：新品模型，顾名思义就是⽤来预测新品的销量。

预测系统核⼼流程
预测核⼼流程主要包括两类：以机器学习算法为主的流程和以时间序列分析为主的流程。

1. 以机器学习算法为主的流程如下：
特征构建：通过数据分析、模型试验确定主要特征，通过⼀系列任务⽣成标准格式的特征数据。

模型选择：不同的商品有不同的特性，所以⾸先会根据商品的销量⾼低、新品旧品、假节⽇敏感性等因素分配不同的算法模型。

特征选择：对⼀批特征进⾏筛选过滤不需要的特征，不同类型的商品特征不同。

样本分区：对训练数据进⾏分组，分成多组样本，真正训练时针对每组样本⽣成⼀个模型⽂件。

⼀般是同类型商品被分成⼀组，⽐如按品类维度分组，这样做是考虑并⾏化以及模型的准确性。

模型参数：选择最优的模型参数，合适的参数将提⾼模型的准确度，因为需要对不同的参数组合分别进⾏模型训练和预测，所以这⼀步是⾮常耗费资源。