总结：人工智能-智能创意平台架构成长之路(二)--大数据架构篇

　　人工智能智能创意平台架构的发展路径（二)-大数据架构章节

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

　　在工作台中，需要进行数据分析，例如，用户对平台合成的横幅图的点击次数，用户在合成横幅图后下载的数据以及其中的PV / UV情况。工作台。

　　在这一轮设计中，我们直接使用的大数据解决方案在开始时并未使用关系数据来进行此类数据分析和统计。体系结构方案如下。我们选择Druid进行数据存储，选择OLAP进行数据分析，Druid.io（以下简称Druid）是用于海量数据的OLAP存储系统，用于实时查询和分析。德鲁伊的四个主要特征总结如下：

　　1），亚秒级OLAP查询分析，Druid使用了关键技术，例如列存储，倒排索引，位图索引等，可以在亚秒级内完成海量数据的过滤，聚合和多维分析级操作。

　　2），实时流数据分析，与传统分析数据库使用的批量导入数据分析方法不同。 Druid提供实时流数据分析。 LSM（长结构合并）-Tree结构使Druid具有极高的实时写入性能；同时，实现了亚秒级的实时数据可视化。

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

　　4），高可用性和高可伸缩性。 Druid采用分布式SN（无共享）架构，管理节点可以配置HA，工作节点具有单个功能，并且彼此不依赖。这些功能使Druid集群在管理，容错，灾难恢复和容量扩展方面非常简单。

　　有关德鲁伊的介绍，请参阅本文文章。

　　1、在页面上，我们使用采集插件进行数据嵌入采集，并且数据采集通过数据采集服务放入了kafka。

　　2、我们在druid中设计了两个表，数据的粒度精确到分钟时间段，即有两个分钟表和小时表。计时器的数据量可能相对较大，因此我们只会将计时器的数据保存在一个月之内，而计时器的数据将被长时间存储。

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

　　4、在平台的设计中，每个横幅图像都有唯一的bannerId和url。在数据聚合处理操作中，bannerId成为唯一的符号，并且根据bannerId执行分钟级聚合和小时级处理。聚合过程。

　　5、 Hive也可以用于小时级别的聚合处理。处理计划如下。由于分钟表中的数据将存储一个月，因此一个月内的查询实际上是分钟表的直接查询，因此将查询小时表中月份以外的数据。因此，尽管此方案可能有数据采集延迟，但不会延迟一个月之久，因此可以通过定时任务进行处理，该任务可以处理第二天前一天的数据。

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

　　上述工作台中的数据分析场景，此外，我们还需要分析界面综合横幅图的数据。在第二轮迭代中，由接口请求合成的标题图的结果数据同时输入到hbase和mysql表中。如上所述，输入到hbase中的数据供用户查询接口综合的结果。如下所示，进入mysql可以进行数据分析了（因为第二轮调用量不够大，所以当时没有采用大数据解决方案）

　　在第三轮接口迭代中，我们优化了体系结构以适应每天数千万个接口综合调用，否则mysql数据库将成为最终的瓶颈，如下所示

　　我们将输入mysql的数据更改为要写入kafka，然后可以实时分析kafka的数据，也可以将kafka的数据输入hive进行离线分析。

　　待续