开源 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 端功能，提供数据指标可视化、数据指标的权限管理等功能；
• 接入成本低、维护成本低、服务器成本低，使用门槛低，对中小企业友好；