我最近接手了融合日志的服务。 整理的结果是我认为现在的服务设计有缺陷。 和Leader开会后，决定重新调查技术方案。 我最终决定使用Flink重建服务。
现在重建的服务成功地考验了国庆节的流量洪峰，今天特别总结回顾，和大家分享经验。
业务需要和背景
首先，我们必须明确解决什么样的问题，以及现在的服务如何解决。
现在的商业逻辑是比较清楚的：
在同一时间段收集不同数据源的日志。
处理收集的数据
将处理后的数据上传到指定的位置，让客户下载。
我们面临的痛点和难点：
日志量比较多，每小时的未压缩日志为50多个g左右。 对于特殊时间节点(如假日)，日志量通常是两倍。
目前，服务单独进行处理，速度比较慢，扩展不方便。
现在，服务需要在处理数据时清洗字段，按时间顺序排序，统计某个字段的频率等步骤。 这些步骤是ETL的通常操作，但现在是以代码的形式实现的。 我想用配置形式减少重复代码，尽量简单通用。
需要方案1:数据库吗？
针对以上业务需要，有的学生提出：’我们可以把所有的原始数据放入数据库，后续的ETL可以用SQL实现’。
如果听“数据库”，Pg、Mysql、Oracle等认为这个方案不可行，你就错了。 如下图所示，数据库的类型和维度非常丰富。
根据业务负荷的特点，关系数据库分为OLTP数据库(事务型)和OLAP数据库(分析型) :
OLTP、onlinetransactionprocessing.OLTP数据库的最大特点是事务支持、添加、删除、更改等功能强，适合需要频繁修改的“热数据”。 我们熟悉的Mysql、Pg等就是这样的。 缺点是支持托托托托事务。
OLAP、在线分析处理和数据分析是主要的。 不支持事务，或对事务的支持有限。 OLAP场景中，多数是读取请求，数据总是以相当大的批量(超过1000 rows )写入，添加的内容不变。方案1总结
OLAP的使用场景符合我们的需要。 因此，我们调查了ClickHouse。 但是，有一个因素。 数据库中存储的数据是二维的，有行和列二维。 但是日志只有一维。 如果分割每行的日志以将日志存储在数据库中，则会汇总字段的需要。
因此，OLAP使用的场景的一个隐含特征是需要多维重复分析存储在：中的数据。 这样，将数据存储在数据库中的动力在我们现在的需要对日志进行简单变形后也作为文本日志输出是不合适的。
方案2: Hive为什么不行？
看了这个，熟悉大数据的同学可能会觉得我们的水平很低
大数据确实像雷贯耳，但我们的团队日志处理这一大部分是在Golang实现的。 团队中的其他业务从未使用过Python、Lua、C .用于Java。 现在大数据是基于JVM开发的。 Golang没有客户端可以帮助调用这些服务。
所以基于团队现在的技术储备，大数据没有成为我们的优先
毫无疑问，不用数据库，直接用HDFS保存日志文件。
我们的需求是离线批处理数据，时效性没有要求，MapReduce和Hive都可以满足需求.但是MapReduce与Hive相比Hive在MapReduce上被分层封装，支持SQL .
那我们为什么最终放弃了Hive呢？
无法批准机器资源。 公司的其他团队已经有了HDFS的设施，只用于存储。 Hadoop的MapReduce组件一点也不跑我们想批准新机器，用Ambari重新制作Hadoop，但据说没有那么多空闲的机器资源。 而且，无论是申请机器还是只跑现在的服务都有不满。 机器资源大部分是空的，有浪费资源的嫌疑。存储分离是一种趋势。 在调查中，像Hadoop一样总结存储和计算是“过时”的。 Hadoop存储的分离需要修改源代码。 现在还没有开源的实现，但云制造商和大型数据公司有相关的商业产品。
文/上海蓝盟 IT外包专家
中文
电话咨询
微信咨询
公众号
