为何丢掉数据库，Hive和Spark,偏偏选择Flink?
发布时间：2021-06-04 16:51:36 所属栏目：大数据 来源：互联网
导读：技术选型: 为什么批处理我们却选择了 Flink? 最近接手了一个融合日志的服务. 经过梳理, 我认为当前服务的设计上存在缺陷. 与 Leader 开会讨论后, 决定重新进行技术方案调研, 最终我们选择使用 Flink 重构了该服务. 目前重构后的服务已成功经受了国庆节流量洪
|
技术选型: 为什么批处理我们却选择了 Flink?
最近接手了一个融合日志的服务. 经过梳理, 我认为当前服务的设计上存在缺陷. 与 Leader 开会讨论后, 决定重新进行技术方案调研, 最终我们选择使用 Flink 重构了该服务.
目前重构后的服务已成功经受了国庆节流量洪峰的考验, 今日特来总结回顾, 和大家分享一下经验.
业务需求及背景
首先我们要明确, 我们要解决什么问题以及目前的服务是如何解决的.
当前的业务逻辑还是比较清晰的:
采集同一时段不同数据源的日志.
对采集的数据进行处理.
将处理后的数据上传到指定位置, 供客户下载.
我们面临的痛点和难点:
日志的量比较大, 每小时未压缩日志在 50 多个 G 左右; 如果是节假日等特殊时间节点, 日志量一般都会翻倍.
目前服务使用单机进行处理, 速度比较慢, 扩容不方便.
目前服务处理数据时需要清洗字段, 按时间排序, 统计某字段的频率等步骤. 这些步骤都属于 ETL 中的常规操作, 但是目前是以代码的形式实现的, 我们想以配置形式减少重复编码, 尽量更加简单, 通用.
方案1: 我们需要一个数据库吗?
针对以上业务需求, 有同学提出: "我们可以把所有原始数据放到数据库中, 后续的 ETL 可以通过 SQL 实现".
如果你一听到"数据库"想到的就是 Pg, Mysql, Oracle 等觉得这个方案不具有可行性, 那你就错了. 如下图所示, 数据库的类型和维度是非常丰富的.
为何放弃数据库，Hive和Spark,偏偏选择Flink?
按业务负载特征，关系型数据库可分为 OLTP 数据库(交易型)和 OLAP数据库(分析型) :
OLTP, Online Transaction Processing. OLTP 数据库最大的特点是支持事务, 增删查改等功能强大, 适合需要被频繁修改的"热数据". 我们耳熟能详的 Mysql, Pg 等都属于这一类. 缺点就是由于支持事务, 插入时比较慢. 拿来实现我们的需求显示是不合适的.
OLAP, Online Analytical Processing, 数据分析为主. 不支持事务, 或对事务的支持有限. OLAP 的场景是: 大多数是读请求, 数据总是以相当大的批(> 1000 rows)进行写入, 不修改已添加的数据.
方案1小结
OLAP 的使用场景符合我们的需求, 为此我们还专门去调研了一下 ClickHouse. 但是有一个因素让我们最终放弃了使用 OLAP. 请注意, 数据库存储的数据都是二维的, 有行和列两个维度. 但是日志只有行一个维度. 如果说为了把日志存入数据库把每行日志都切分, 那我们统计字段的需求也就顺手实现了, 又何必存到数据呢?
所以, OLAP 使用场景隐含的一个特点是: 存入的数据需要被多维度反复分析的. 这样才有把数据存入数据库的动力, 像我们当前的需求对日志进行简单的变形后仍旧以文本日志的形式输出, 使用 OLAP 是不合适的.
方案2: Hive 为什么不行?
看到这, 熟悉大数据的同学可能会觉得我们水平很 Low, 因为业务需求归根到底就是三个字: "批处理". (提炼一下我们的需求, 其实正是大数据的典型应用场景. 大数据处理流程, 见下图) 那么我们为什么第一时间没有考虑上大数据呢?
 （编辑：伊春站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
