一是人工采集,二是智能采集(苏宁人工智能研发中心智能创意平台架构成长之路(一))

　　一是人工采集,二是智能采集(苏宁人工智能研发中心智能创意平台架构成长之路(一))

　　苏宁人工智能研发中心智能创意平台架构成长之路（一)--长篇开篇

　　我们继续第一篇文章。

　　（这是大数据架构第二章，成长路径序列将收录多篇文章。作者作为该平台的架构和技术经理，充分描述了迭代的悲伤路径以及中间遇到的问题和解决方案）

　　声明：文章不涉及泄露公司内部技术信息。涉及到的图片都是重新绘制的简单架构图，主要是通过架构的演进，来描述共享技术的迭代路径和过程。

　　第二次迭代完成后，在第三次迭代中，我们开始分析平台的数据。这里我们以工作台的数据分析为例，说明平台如何利用大数据进行数据分析。

　　在工作台中，需要进行数据分析，比如平台合成的banner图被用户点击的次数，banner图合成后用户下载的数据，workbench中的PV/UV情况.

　　在这一轮设计中，我们直接使用的大数据方案一开始并没有使用关系数据来做这样的数据分析和统计。架构方案如下。我们选择 Druid 进行数据存储和 OLAP。在数据分析方面，Druid.io（以下简称Druid）是一个面向海量数据的OLAP存储系统，用于实时查询和分析。Druid 的四个关键特性总结如下：

　　1），亚秒级OLAP查询分析，Druid采用列存储、倒排索引、位图索引等关键技术，可以完成亚秒级海量数据的过滤、聚合和多维分析.

　　2），实时流式数据分析，区别于传统分析数据库采用的批量导入数据分析方式。Druid 使用 LSM（长结构）提供实时流数据分析

　　merge)-Tree 结构使 Druid 具有极高的实时写入性能；同时实现了亚秒级实时数据的可视化。

　　3），丰富的数据分析功能。针对不同的用户群体，Druid 提供了友好的可视化界面、类 SQL 的查询语言和 REST 查询界面

　　4），高可用和高扩展性。Druid采用分布式、SN（share-nothing）架构，管理节点可配置HA，工作节点功能单一，互不依赖。这些特性使得 Druid 集群在管理、容错、容灾、扩容等方面都非常简单。.

　　关于德鲁伊的介绍可以参考

　　这个文章。

　　1、页面上，我们使用采集插件做数据嵌入采集，通过数据采集将数据采集丢入kafka服务。

　　2、

　　我们在druid中设计了两张表，数据的粒度精确到分钟时间段，即有分钟表和小时表两个。分钟表数据量可能比较大，所以我们只会保留1个月内的分钟表数据，而小时表数据会长期保存。

　　3、 在kafka中，我们创建了两个消费组，一个用于小时消费处理，一个用于分钟消费处理。

　　4、 在平台的设计中，每个banner图片都有一个唯一的bannerId和url。在数据聚合处理操作中，bannerId

　　成为唯一标志，根据bannerId进行分钟级聚合处理和小时级聚合处理。

　　5、

　　Hive 也可以考虑用于小时级别的聚合处理。处理方案如下。由于分钟表中的数据会存储1个月，所以1个月内的查询实际上是直接查询分钟表，超过1个月的数据会被使用。查询小时表。所以这个方案虽然可能有数据采集的延迟，但不会延迟长达一个月，所以可以通过定时任务处理，第二天就可以处理前一天的数据。

　　6、 查询数据报表时，可以查询1个月内的分钟表，超过1个月的可以查询小时表。

　　上面提到的workbench中数据分析的场景，界面合成banner图的数据也需要分析。在第二轮迭代中，接口请求合成的banner图的结果数据同时输入到hbase和mysql表中。如上所述，输入到hbase中的数据是供用户查询界面合成结果的。进入mysql准备进行数据分析（因为第二轮调用量不够大，所以当时没有采用大数据方案），如下图

　　在第三轮接口迭代中，我们对架构进行了优化，以适应每天数千万的接口合成调用，否则mysql数据库将成为最终的瓶颈，如下图

　　我们将输入mysql的数据改成写入kafka，这样就可以实时分析kafka的数据，也可以将kafka的数据输入hive进行离线分析。

　　待续