开源XL-LightHouse与Flink、ClickHouse之类技术相比有什么优势？
为什么开发XL-LightHouse？
说到流式统计大家都不会陌生，流式统计的应用场景广泛，可以遍布企业运转的各个方面。比如常见的PV、UV统计；电商订单的销售额、下单用户数统计；广告的点击量统计；日志数据统计；接口的调用量，耗时状况统计等等。 而面对较为庞大的流式数据统计需求，开源社区中并没有专门针对此类需求的开源工具。说到这可能有些小伙伴会表示怀疑，因为像Flink、Spark、ClickHouse、Doris等等这些工具不都可以解决这类问题吗？ 没错，这些工具都可以用来解决流式统计的问题，不过它们都不是专门为解决流式统计问题而设计的。Flink和Spark是流式计算框架（这里刨除离线部分不谈），而ClickHouse和Doris是OLAP计算引擎。也正因为如此，这些软件在流式统计方面其实存在着很多短板。XL-LightHouse基于这种行业背景完全依据流式统计的运算特点而设计，在流式统计方面的表现可以完胜上面任何一种运算工具。XL-LightHouse单个任务就能支撑大批量、数以万计的数据指标，可以帮助企业以非常低的成本快速搭建起数据指标体系。
从流式统计的特点说起
流式统计是流式计算中的一种特殊运算形式
一个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的技术方案。
XL-LightHouse作为适配流式统计的技术方案，它不再是围绕着“流数据处理过程”这条主线，而是围绕着“运算操作类型”来实现。它将所有流式统计需求抽象分类成多种运算场景，每个统计需求都是基于其中的一种或多种运算场景来实现。系统中统计项配置包括了其计算规则、维度信息和统计周期等元素，在系统接收到统计消息后，系统将原始消息按照统计项标识、运算函数类型、维度信息和统计周期划分成一个个算子。这些算子分属于众多的统计指标，它们之间彼此独立，但却可以同时并行运行在一个进程当中，每个数据流本身的运算过程中不再有窗口的概念。XL-LightHouse虽然也会按窗口批次来处理消息，但这个窗口跟Flink任务中的窗口已有本质区别，这里的窗口是相对于大批量的数据指标汇总的数据流整体来说的，更多的只是作为事件触发的功能而已。
这种设计更加贴合流式统计的运算特点，已然完全不同于Flink和Spark这种数据流彼此之间处于资源隔离的运算形式，打破了流式计算的束缚，大大提高了集群资源的利用效率。也正因如此，XL-LightHouse一个任务就可以同时并行处理数十万条数据流，单个任务就能够支撑庞大量级数据指标，这种优势是Flink和Spark刻板的使用流式计算的方式去解决流式统计的问题永远都无法比拟的。 很多时候无关乎技术，一个软件本身的定位就已经决定了它在某个领域所能企及的上限。软件自身或许并无优劣，而只是侧重点不同而已。在流式统计这个细分领域，面对企业繁杂的流式数据统计需求，XL-LightHouse的运算性能瞬间就可以秒杀Flink和Spark之类的解决方案。
流式统计应用场景广泛，应该拥有与其市场价值匹配的通用型解决方案
一类业务需求即便是能够被抽象成若干种运算操作类型，也要同时考虑是否有将其适配成一种通用型解决方案的必要。如果应用场景较少、市场价值有限，将其适配成一种通用型解决方案是完全没有必要的，然而流式统计明显不是这一类。
随着企业数据化运营理念的不断渗透，企业对数据指标的需求越来越多，粒度越来越细，这是科技发展的必然趋势。而通用型流式统计相比于目前业内主流的实时计算、离线计算、OLAP这些"奢侈"的技术，它是成本最为低廉的一种技术方案，这对于企业实现数据化运营具有不可替代的巨大优势。
在软件研发领域，我认为通用型流式统计将会对现在的软件类产品研发产生较为巨大的影响，它会发展成为如同日志一样的重要角色，通用型流式统计或将成为独立于日志之外且重要程度不亚于日志的另一套辅助类工具体系，各种工种的程序员将会在任何有必要的地方加上流式统计的代码就像加日志一样司空见惯、习以为常。
在企业级服务市场，我认为通用型流式数据统计将凭借其庞大的应用场景和巨大的业务价值而成为企业最核心的基础服务之一，而以通用型流式数据统计为核心理念、以其他技术方案为辅助手段的数据化运营类产品将成为企业级B端市场不可或缺的中坚力量。
Flink用于流式统计存在哪些问题
如上所述，Flink是针对流式计算中各类运算场景相对宽泛的解决方案，而对比XL-LightHouse，Flink在应对流式统计问题方面存在着以下问题：
资源利用率低
Flink的资源利用率低要从两个角度来看，一个是集群运行的拓扑结构，另一个是Flink任务执行的特性。
从集群运行的拓扑结构来看，Flink一个Job只能处理一个或少数几个统计指标，每个Job都需要单独向集群申请运算资源，不同Job的运行处于资源隔离的状态。那这个过程至少存在几个方面的资源浪费：
每个Job除了运算所必须的资源外，还需要维持一定比例的“空闲资源”，空闲资源是为了保障在流量上涨时程序的稳定运行。由于Flink一个任务只能实现少量的数据指标，而大批量的数据指标需要依靠大量的Job来实现，而这些Job的空闲资源的叠加是相当大的资源浪费。
流式统计任务大多处于长期运行状态，而诸如Flink和Spark之类的解决方案，一个流式统计任务即便一天只有零星几条的消息数据也依然要为其分配额定的运算资源，反观XL-LightHouse，系统中的所有统计指标没有资源隔离的束缚，系统的资源分配是按照整体运行状况进行分配的，对于没有消息数据的统计指标则丝毫不必占用任何运算资源。
对于有明显波峰和波谷的统计需求来说，Flink任务需要为波峰时段分配较高的运算资源，而这些运算资源在波谷时段基本处于闲置状态（虽然像Flink/Spark以及Yarn这种任务管理平台不断地优化资源利用率，提供动态的扩容和缩容机制，但其实实际效果并不明显）。
实现不同的统计需求需要研发人员开发并提交相应的计算任务，而如果研发人员资源参数配置不当，也将造成的比较大的资源浪费。以我过往的经历来看，开发人员申请超过所需运算资源数倍的情况并不少见。
很多Flink任务需要依据数据量、数据倾斜状况、统计周期粒度等因素进行特定的优化，而研发人员对相应优化未必有充沛的时间和相关经验，这就导致低效任务运行也会间接浪费大量运算资源。
而从Flink任务执行的特性来看，不管是基于FlinkSQL还是它基础的API，比如keyBy、WindowProcess、aggregate等操作，这些函数处理的过程都是采用将数据转移到某个特定分区统一处理，这个过程除了会导致数据倾斜之外，也必然产生大量的运算资源浪费。
我举一个可能不是非常严谨的例子来说明：一个Flink任务并行度为5，每个运算进程的数据量假设为1G，那正常来说只需要给它分配5G的内存就足够了。而如果在指标统计时需要使用keyBy之类的函数，程序则必然发生数据倾斜。我们假设任务发生了最严重的数据倾斜，那每个进程我们至少要给它分配5G的资源才能防止出现内存溢出的状况，也就是说实际上这个任务运行耗费了25G的内存。而相比较XL-LightHouse依据流式统计的运算特点，采用完全规避shuffle，将中间态数据和结果数据均放在外部存储中，不同运算节点之间互不影响，所以完全不会出现这种状况。
目前业内针对集群资源利用率的观测，大都是基于操作系统层面的内存、CPU、负载等参数，但这种观测其实并不能发现更深层次的资源浪费问题。大数据集群的资源浪费问题远比很多朋友想象中要严重的多得多。而相比之下XL-LightHouse自身设计更能将集群算力发挥到极致。
运算性能低
我们总能看到很多文章在渲染Flink运算性能的优势，当然这是没有问题的，因为运算性能的高低本身就是一个相对的概念。Flink作为一个业内优秀的流式计算引擎，确实在性能方面技艺精湛且已经达到了相当高的程度。但是如果作为一个流式统计工具，与XL-LightHouse相比的话，它的表现其实乏善可陈。
Flink受限于自身定位，刻板的选择流式计算那一套臃肿笨重的计算方式来实现流式统计，而它针对流式统计各种运算单元的优化也只能在其现有的运行机制体系下很有限的范围内进行。 它的一个Job只能同时处理一两个或很少量的数据流，数据消费逻辑只能机械的依赖窗口时间和水印时间执行，它所有的设计方案出发点只能从流式计算各类场景综合角度去考虑，而不可能只从贴合流式统计的角度去考虑，它也不可能引入更加高效、但较重的方案来实现各种流式统计函数，它的执行逻辑不可能规避shuffle，也不可能规避数据倾斜。Flink和Spark都不能算是优秀的流式统计工具，将来也不可能成为优秀的流式统计工具。
接入成本高
Flink的接入成本太高，主要体现在：Flink面向专业的大数据研发人员，不少Flink任务需要依据数据量、运算类型等各种情况进行特定优化，实现大量的统计指标需要耗费大量研发成本。 而XL-LightHouse一行代码接入，普通工程人员即可驾驭，不管数据量有多大，都不需要针对单个统计任务进行任何特定优化。
运维成本高
对比XL-LightHouse，Flink的运维成本更高，体现在以下方面：
- 实现相同数量级的流式统计需求，Flink集群规模要明显大于XL-LightHouse的集群规模，导致运维成本增加。
- 由于Flink集群面向专业的研发人员，Flink集群的运转是由集群维护人员和Flink任务研发人员共同参与，如果集群要进行版本升级、集群扩容、日常维护、数据迁移等操作均需要与研发人员事先沟通、达成默契，很多类似版本升级的操作会涉及相关任务的升级改造。如果集群规模庞大、涉及研发人员、相关任务较多的话，那这个过程也必然会耗费了较大的维护成本。
ClickHouse用于流式统计存在哪些问题
ClickHouse是OLAP类引擎，其实与XL-LightHouse是有着本质不同的，应用的场景也不相同。
ClickHouse适用场景的特点
- 单个或较少数量的应用场景，且每个应用场景都有海量的数据；
- 业务场景有大量的维度字段，可能需要按照十几个甚至几十个以上的维度随意组合进行多维度即席查询操作；
- 业务场景有明细查询的需求；
- 不同数据源之间可能有join查询的需求；
ClickHouse的缺点
- 由于每次查询都需要遍历海量数据，所以并发度支持有限；
- 由于系统内存储着海量的明细数据，集群规模庞大、结构复杂，维护成本高昂；
- 每次查询都要遍历数据，进行实时统计运算，需要耗费的大量的内存和CPU资源；
- 数据接入需要进行各种层面的优化，使用门槛较高、面向专业的大数据研发人员使用；
- 接入成本高、维护成本高、服务器成本高，使用门槛高，对中小企业不太友好；
XL-LightHouse适用场景及优缺点
XL-LightHouse是一套通用型流式大数据统计系统，致力于推动流式统计的快速普及和大规模应用，定位是以一套服务使用较少的服务器资源同时支撑数以万计、数十万计流式数据统计需求的大数据平台。XL-LightHouse面向企业自上而下所有职能人员共同使用，倡导以通用型流式数据统计技术为切入点，倾向于选择轻巧的技术方案帮助企业以更低的成本，更快速的搭建起一套犹如我们人体神经系统一样遍布全身的、较为完善、稳定可靠的数据化运营体系。
XL-LightHouse抛弃了Flink和Spark这种基于流数据处理过程的实现方案，打破了流式计算的束缚，采用“多流并行处理”的计算模型更加贴合流式统计运算特性。抛弃SQL语言这种臃肿笨重的业内标准，自定义更加简洁高效，符合流式统计运算特点的配置规范。系统设计层面尽可能避免资源浪费，充分发挥集群运算能力，并对流式统计的各种运算单元进行反复优化以提高数据的处理能力。
- 面向企业繁杂的流式数据统计需求，一套系统可以在极短的时间内快速实现成千上万个数据指标，指标体系可以遍布企业运转的方方面面；
- 对单个流式统计场景的数据量无限制，既可以非常庞大，也可以非常稀少。您既可以使用它完成十亿级用户量APP的DAU统计、十几万台服务器的运维监控、一线互联网大厂数据量级的日志统计、也可以用它来统计一天只有零星几次的接口调用量、耗时状况；
- 流式统计时间窗口最大范围是1天，所以不支持月活跃用户数之类的长统计周期指标；
- 可以支持高并发查询统计结果；
- 不支持明细查询，如果想要支持明细查询需要借助于其他工具实现；
- 由于不存储明细数据，只存储统计结果，所以相对于ClickHouse之类的OLAP引擎来说维护的总数据量级要少得多，运维成本低；
- 轻量级使用、一键部署、一行代码接入，普通工程人员就可以轻松驾驭。
- 有完善的Web端功能，提供数据指标可视化、数据指标的权限管理等功能；
- 接入成本低、维护成本低、服务器成本低，使用门槛低，对中小企业友好；
结束语
如果有人跟我说，Flink、Spark、ClickHouse、Doris... 这些技术会在未来的互联网和物联网发展过程中发挥越来越大的市场应用价值，我认为：这是毫无疑问的。
如果有人跟我说，Flink、Spark、ClickHouse、Doris... 这些技术将在未来互联网和物联网数据化运营浪潮中发挥中流砥柱的作用，我认为：这一点可能都没有。
企业数据化运营技术方案应该以通用型流式统计为主，以其他技术方案为辅，目前行业内所极力推崇的以Flink、Spark或者各色的OLAP引擎为核心的解决方案，包括在此基础上的各种数仓类衍生方案，只是企业数据化运营技术演进历程中一个微不足道的过渡阶段。
Flink、Spark、ClickHouse、Doris ... 固然有其精妙绝伦的设计、登峰造极的实现和在某些场景下难以撼动的地位，但是在数据化运营这个细分领域内，它们的笨拙已经限制了它们所能企及的上限。
企业对数据的需求是无止境的，但所能承担的成本却是有上限的。我们难以想象如果基于Flink、Spark、OLAP这些技术要实现十万、百万的数据指标，那系统的架构会是多么的臃肿不堪，昂贵无比，而如果基于通用型流式数据统计，一切只在弹指之间。
我相信未来的云服务厂商凭借通用型流式数据统计技术，一个计算集群就可以支撑千万个乃至上亿个数据指标的并行计算，可以同时满足庞大数量的企业和用户的共同使用，这种惊人的计算能力是其他技术方案难以望其项背的。真诚期望互联网大厂尤其是云服务厂商尽早做出技术转型，全面拥抱通用型流式数据统计。
通用型流式数据统计并不完美，确实有一些场景并不适合使用流式统计来实现，但我依然认为在企业数据化运营领域，在所有的技术方案中能够发挥中流砥柱作用的只有可能是通用型流式数据统计。通用型流式数据统计技术凭借其庞大的应用场景、低廉的使用成本和彪悍的运算性能，足以掩盖它一切的不足。
通用型流式数据统计是企业数据化运营发展到一定阶段后的唯一选择，只有通用型流式数据统计才能轻松的将企业数据化运营水平提升两到三个数量级。
我深知很多企业以及很多技术人员痴迷于追求所谓"一站式"的解决方案，但以我一个工程人员视角来看，其实世界上根本不存在什么"一站式"的解决方案，所有的软件都不完美，这只是一种营销的噱头。我从来不愿意标榜xl-lighthouse是什么一站式解决方案，它有它的不足，但也有它独到的优势。 我更期望将xl-lighthouse打造成在它擅长的领域内，在世界上所有的软件中，它的锋芒都无与伦比。
我相信在绝对的成本优势面前，那些所谓"一站式"解决方案，其实根本不值一提，对于执着追求"一站式"解决方案的企业和技术人员，如果有一天你意识到xl-lighthouse可以帮您实现非常非常多的功能、解决非常非常多的问题，而成本只有Flink、Spark、ClickHouse、Doris...这些技术的百分之一、千分之一，甚至在不远的将来只有万分之一的时候，你们也会毫不犹豫、彻底放下这种执念。