开源XL-LightHouse与Flink、ClickHouse之类技术相比有什么优势

Flink是一款非常优秀的流式计算框架，而ClickHouse是一款非常优秀的OLAP类引擎，它们是各自所处领域的佼佼者，这一点是毋庸置疑的。Flink除了各种流式计算场景外也必然可以用于流式统计，ClickHouse同样也可以用于流式统计，但我不认为它们是优秀的流式统计工具。XL-Lighthouse在流式统计这个细分场景内足以完胜Flink和ClickHouse。在企业数据化运营领域，面对繁杂的流式数据统计需求，以Flink和ClickHouse以及很多同类技术方案为核心的架构设计不能算是一种较为优秀的解决方案。

一、从流式统计的特点说起

1、 流式统计是流式计算中的一种特殊运算形式

一个Flink任务只能并行处理一个或少数几个数据流，而XL-LightHouse一个任务可以并行处理数万个、几十万个数据流；一个Flink任务只能实现一个或少数几个数据指标，而XL-LightHouse单个任务就能支撑大批量、数以万计的数据指标。

流式计算是一个很宽泛的概念，目前没有办法用特定的某些运算操作类型将其抽象出来。流式计算是基于事件流驱动的运算方式，常见的应用场景有：计算用户实时画像、实时推荐、监控告警、实时电信反诈骗等等。正是因为目前流式计算没有办法通过某些运算操作类型将其抽象，所以只能从“流式数据处理过程”这种宽泛的视角来解决此类问题。因此我们可以看到不管是Flink还是Spark，都有类似数据源(Source)、转化操作(Map)、执行操作(Action)、窗口(Window)、结果处理(Sink)这类概念，因为这些概念都是围绕着“流式数据处理过程”而衍生出来的。当然Flink的工程师为了扩充其适用场景、提高产品的完善度，提供了类似状态管理、水印、聚合函数等等功能，但也都不可能脱离流式数据处理过程的主线。
而反观流式统计虽然是属于流式计算的一种计算形式，但它其实是一种完全可以被抽象成几种运算操作类型的计算形式。绝大多数的流式统计无外乎Count运算、Sum运算、Bitcount运算(count distinct)、Max运算、Min运算、Avg运算、Seq运算(时序数据)、Dimens运算(维度划分)、Limit运算(topN/lastN)，然后再结合时间窗口(滚动窗口、滑动窗口)的划分就可以完成一个个的流式数据统计需求。任何一类业务需求只要可以被抽象成若干种运算操作类型，那就一定可以为此类业务需求设计出一种与其适配的通用化解决方案。这个过程就像Photoshop将所有图片处理的操作抽象出移动工具、钢笔工具、圈选工具、裁剪工具、橡皮擦工具等，关系型数据库将所有数据相关操作抽象出增加、删除、修改、查询、事务、索引等过程类似。而很显然Flink、Spark面对流式计算场景，自身都没有基于这种“功能抽象”的概念来实现。
正因为Flink、Spark在流式处理方面都是基于宽泛的流数据处理过程所设计，所以流式计算的实现并不是一种“通用化”解决方案。每个Flink任务只能并行处理一个或少数几个数据流，而窗口则对应与之相应的数据流。这种设计如果从流式计算的角度来看并无问题，但如果从流式统计这个细分领域的角度来看却明显先天不足。从某种程度上来说Flink和Spark由于其自身定位，它们的这种设计方案只能将流式计算中的非流式统计任务的执行效率发挥到极致，而远远不可能将流式统计的效率发挥到极致。所以我一直认为：Flink和Spark称得上是优秀的流式计算工具，但根本不能算是优秀的流式统计工具。流式统计是一种可以被抽象的计算形式，所以必然能够为其设计出一套通用型且性能远远超过Flink和Spark的技术方案。这个原因就好比是专用的水果刀用来削苹果要比功能繁杂的瑞士军刀好用一样。
而XL-LightHouse作为适配流式统计的技术方案，它不再是围绕着“流数据处理过程”这条主线，而是围绕着“运算操作类型”来实现，这种设计更加贴合流式统计的运算特点，彻底打破了流式计算的束缚，也正因为如此，XL-LightHouse一个任务就可以同时并行处理十几万条、数十万条的数据流，每个数据流本身的运算过程中不再有窗口的概念，而XL-LightHouse单个任务就能够支撑大批量、数以万计的数据指标，这种优势是Flink和Spark刻板的使用流式计算的方式去解决流式统计的问题之类方案永远都无法比拟的。
XL-LightHouse每个统计项配置包括了其计算规则、维度信息和统计周期等元素，在系统接收到统计消息后，系统将原始消息按照统计项标识、运算函数类型、维度信息和统计周期划分成一个个的算子。这些算子分属于众多的统计指标，它们之间彼此独立，但却可以同时并行运行在一个进程当中，这种模式已然完全不同于Flink任务和Spark任务这种流数据彼此之间处于资源隔离的运算形式，大大提高了集群资源的利用效率。
XL-LightHouse虽然目前是基于Structured Streaming实现，也会按窗口批次来处理消息，但这个窗口跟Flink任务中的窗口已有本质区别，这里的窗口是相对于大批量的数据指标汇总的数据流整体来说的，更多的只是作为事件触发的功能而已。而Flink和Spark在处理流式统计任务时依旧刻板的按照流式计算的形式为每个统计指标所对应的数据流单独来划分窗口，执行聚合数据等操作，不同的统计指标需要单独启动不同的Job来实现，任务彼此间资源隔离，这严重制约了流式统计的运行效率。很多时候无关乎技术，一个软件本身的定位就已经决定了它在某个领域所能企及的上限。软件自身或许并无优劣，而只是侧重点不同而已。在流式统计这个细分领域，面对企业繁杂的流式数据统计需求，XL-LightHouse的运算性能瞬间就可以秒杀Flink和Spark之类的解决方案。

2、 流式统计应用场景广泛，应该拥有与其市场价值匹配的通用型解决方案。

一类业务需求即便是能够被抽象成若干种运算操作类型，也要同时考虑是否有将其适配成一种通用型解决方案的必要。如果应用场景较少、市场价值有限，将其适配成一种通用型解决方案是完全没有必要的，然而流式统计明显不是这一类。
流式统计应用场景广泛，随着企业数据化运营理念的不断渗透，企业对数据指标的需求越来越多，粒度越来越细，几乎可以遍布企业运转的方方面面，这是科技发展的必然趋势。

随着流式统计技术的日益普及，它将在所有流式计算需求中占有越来越高的比例。由于流式计算中的非流式统计问题和流式统计问题从运算特点的角度来看具有显著差异，所以应该被分开应对，刻板的按照流式计算的固有模式去解决流式统计的问题是一种低效的表现。

当前大数据领域所恪守的SQL规范由于其自身的瓶颈已经制约流式统计的快速普及和大规模应用，而只要打破这种桎梏，流式统计或将迎来井喷式增长。XL-LightHouse依据流式统计的计算特点，为流式统计量身打造的自定义配置规范（XL-Formula），用于描述形式各样的流式统计运算方式，在该领域使用远比SQL规范要简洁高效的多。

在软件研发领域，我认为通用型流式统计将会对现在的软件类产品研发产生较为巨大的影响，它会发展成为如同日志一样的重要角色，通用型流式统计或将成为独立于日志之外且重要程度不亚于日志的另一套辅助类工具体系，各种工种的程序员将会在任何有必要的地方加上流式统计的代码就像加日志一样司空见惯、习以为常。

在企业级服务市场，我认为通用型流式数据统计将凭借其庞大的应用场景和巨大的业务价值而成为企业最核心的基础服务之一，而以通用型流式数据统计为核心理念、以其他技术方案为辅助手段的数据化运营类产品将成为企业级B端市场不可或缺的中坚力量。

二、Flink用于流式统计存在哪些问题

如上所述，Flink是针对流式计算领域中各类运算场景相对宽泛的解决方案，而对比XL-LightHouse，Flink在应对流式统计问题方面存在着以下问题：

1、资源利用率低

Flink的资源利用率低要从两个角度来看，一个是集群运行的拓扑结构，另一个是Flink任务执行的特性。

从集群运行的拓扑结构来看，Flink一个Job只能处理一个或少数几个统计指标，每个Job都需要单独向集群申请运算资源，不同Job的运行处于资源隔离的状态。那这个过程至少存在几个方面的资源浪费：

• 每个Job除了运算必须的资源外，还需要维持一定比例的“空闲资源”，空闲资源是为了保障在流量上涨时程序的稳定运行。由于Flink一个任务只能实现少量的数据指标，而大批量的数据指标需要依靠大量的Job来实现，而这些Job的空闲资源的叠加是相当大的一笔浪费。

• 流式统计任务大多处于长期运行的状态，而诸如Flink和Spark之类的解决方案，一个流式统计任务即便一天只有零星几条的消息数据也依然要为其分配额定的运算资源，反观XL-LightHouse，系统中的所有统计指标没有资源隔离的束缚，系统的资源分配是按照整体运行状况进行分配的，对于没有消息数据的统计指标则丝毫不必占用任何运算资源。

• 对于有明显波峰和波谷的统计需求来说，Flink任务需要为波峰时段分配较高的运算资源，而这些运算资源在波谷时段基本处于闲置状态（虽然像Flink/Spark以及Yarn这种任务管理平台不断地优化资源利用率，提供动态的扩容和缩容功能，但其实实际效果并不明显）。

• 实现不同的统计任务需要研发人员在Flink集群开发并提交相应的计算任务，而如果研发人员资源参数配置不当，也将造成的较大的资源浪费。

• 很多Flink任务需要依据数据量、数据倾斜状况、统计周期粒度等因素进行特定的优化，而很多研发人员对相应优化未必有充沛的时间和相关经验，这就导致低效任务运行间接浪费了大量运算资源。

而从Flink任务执行的特性来看，不管是基于FlinkSQL还是它基础的API，比如keyBy、WindowProcess、aggregate等函数，这些函数处理的过程都是采用将数据转移到某个特定分区统一处理，这个过程除了会导致数据倾斜之外，也必然产生大量的运算资源浪费。
我举一个可能不是非常严谨的例子来说明：一个Flink任务并行度为5，每个运算进程的数据量假设为1G，那正常来说只需要给它分配5G的内存就足够了。而如果在指标统计时需要使用keyBy之类的函数，程序则必然发生数据倾斜。我们假设任务发生了最严重的数据倾斜，那每个进程我们至少要给它分配5G的资源才能防止出现内存溢出的状况，也就是说实际上这个任务运行耗费了25G的内存。而相比较XL-LightHouse依据流式统计的运算特点，采用完全规避shuffle，将中间态数据和结果数据均放在外部存储中，不同运算节点之间互不影响，所以完全不会出现数据倾斜的状况。

目前业内针对集群资源利用率的观测，大都是基于操作系统层面的内存和CPU参数，但这种观测其实并不能发现更深层次的资源浪费问题。大数据集群的资源浪费问题远比很多朋友想象中要严重的多得多。而相比之下XL-LightHouse自身设计更能将集群算力发挥到极致。

2、运算性能低

我们总能看到很多文章在渲染Flink运算性能的优势，当然这是没有问题的。Flink作为一个业内优秀的流式计算引擎，确实在性能方面技艺精湛且已经达到了相当高的程度。但是作为一个流式统计工具，与XL-LightHouse相比的话，它的表现其实乏善可陈。
Flink受限于自身的定位，依旧刻板的选择流式计算那一套臃肿笨重的计算方式来实现流式统计，而它针对流式统计各种运算单元的优化也只能在其现有的运行机制体系下有限的范围内进行。
它的一个Job只能同时处理一两个或很少量的数据流，数据消费逻辑只能机械的依赖窗口时间和水印时间执行，它所有的设计方案出发点只能从流式计算各类场景综合角度去考虑，而不可能只从贴合流式统计的角度去考虑，它也不可能引入更加高效、但较重的方案来实现各种流式统计函数，它的执行逻辑不可能规避shuffle，也不可能规避数据倾斜。所以受限于自身定位，Flink和Spark都不能算是优秀的流式统计工具，将来也不可能成为优秀的流式统计工具。

3、接入成本较高

虽然各种大数据平台越来越多，研发人员可以提交Flink Jar任务和FlinkSQL任务，而不少互联网大中型企业在坚定的朝着这个方向努力。
在所有Flink任务当中有较大比例的任务只是进行流式统计，随着企业数据化运营理念的不断推进，使用流式统计的业务需求数量会越来越多，占比会越来越高。
而对比XL-LightHouse一行代码的接入方式来说，Flink的接入成本太高了，体现在几个方面：
（1）、Flink面向专业的大数据研发人员，大量统计指标的实现需要耗费大量的研发成本。
（2）、由于Flink自身在流式统计领域的基础功能并不完善，所以很多场景下都需要研发人员依据统计任务的数据量、统计周期的粒度、数据倾斜状况等因素进行特定的优化。所以使用Flink实现很多相类似的功能，由于数据量差异、统计周期的不同，程序的实现方式也可能截然不同。

4、运维成本高、运算资源成本高

对比XL-LightHouse，Flink的运维成本更高，体现在几个方面：
（1）、实现相同的流式统计需求，Flink集群规模要明显大于XL-LightHouse的集群规模，导致运维成本增加。
（2）、由于Flink集群面向专业的研发人员，Flink集群的运转是由集群维护人员和Flink任务的研发人员共同参与，如果集群要进行版本升级、集群扩容、日常维护、数据迁移等操作均需要与研发人员事先沟通、达成默契，很多类似版本升级的操作会涉及相关任务的升级改造。如果集群规模庞大、涉及研发人员、相关任务较多的话，那这个过程也必然会耗费了较大的维护成本。

三、ClickHouse用于流式统计存在哪些问题

ClickHouse是OLAP类引擎，其实与XL-LightHouse是有着本质不同的，应用的场景也不相同。

• ClickHouse适用场景的特点
  （1）单个或较少数量的应用场景，且每个应用场景都有海量的数据；
  （2）业务场景有大量的维度字段，可能需要按照十几个甚至几十个以上的维度随意组合进行多维度即席查询操作；
  （3）业务场景有明细查询的需求；
  （4）不同数据源之间可能有join查询的需求；

• ClickHouse的缺点
  （1）由于每次查询都需要遍历海量数据，所以并发度支持有限；
  （2）由于系统内存储着海量的明细数据，集群规模庞大、结构复杂，维护成本高昂；
  （3）每次查询都要遍历数据，进行实时统计运算，需要耗费的大量的内存和CPU资源；
  （4）数据接入需要进行各种层面的优化，使用门槛较高、面向专业的大数据研发人员使用；
  （5）接入成本高、维护成本高、服务器成本高，使用门槛高，对中小企业不太友好；

四、XL-LightHouse的优势

XL-LightHouse是一套通用型流式大数据统计平台，致力于推动流式统计的快速普及和大规模应用，定位是以一套服务使用较少的服务器资源同时支撑数以万计、数十万计流式数据统计需求的大数据平台。XL-LightHouse面向企业自上而下所有职能人员共同使用，倡导以通用型流式数据统计技术为切入点，倾向于选择轻巧的技术方案帮助企业以更低的成本，更快速的搭建起一套犹如我们人体神经系统一样遍布全身的、较为完善、稳定可靠的数据化运营体系。
XL-LightHouse抛弃了Flink和Spark这种基于流数据处理过程的实现方案，打破了流式计算的束缚，采用“多流并行处理”的计算模型更加贴合流式统计运算特性。抛弃SQL语言这种臃肿笨重的业内标准，自定义更加简洁高效，符合流式统计运算特点的配置规范。XL-LightHouse一个任务可并行处理数十万个数据流，单个任务就可以支撑大批量的数据指标。XL-LightHouse尽可能避免资源浪费，充分发挥集群的运算能力，并对流式统计的各种运算单元进行反复优化以提高数据的处理能力。

XL-LightHouse适用场景及优缺点：

• 面向企业繁杂的流式数据统计需求，一套系统可以在超短的时间内快速实现成千上万个数据指标，指标体系可以遍布企业运转的方方面面；
• 对单个流式统计场景的数据量无限制，既可以非常庞大，也可以非常稀少。您既可以使用它完成十亿级用户量APP的DAU统计、十几万台服务器的运维监控、一线互联网大厂数据量级的日志统计、也可以用它来统计一天只有零星几次的接口调用量、耗时状况；
• 流式统计时间窗口最大范围是1天，所以不支持月活跃用户数之类的长统计周期指标；
• 可以支持高并发查询统计结果；
• 不支持明细查询，如果想要支持明细查询需要借助于其他工具实现；
• 由于不存储明细数据，只存储统计结果，所以相对于ClickHouse之类的OLAP引擎来说维护的总数据量级要少得多，运维成本低；
• 一键部署、一行代码接入，普通工程人员就可以轻松驾驭。
• 有完善的Web端功能，提供数据指标可视化、数据指标的权限管理等功能；
• 接入成本低、维护成本低、服务器成本低，使用门槛低，对中小企业友好；

热门相关：流鱼无恙   豪门情变，渣总裁滚远点！   大妆   大妆   未来兽世：买来的媳妇，不生崽