序言

数据化运营是通过系统地收集、分析和利用数据，优化业务流程、提升决策效率、增强竞争力的一种运营模式，它强调以数据为核心驱动力，建立数据指标体系用于企业生产的各个环节，从而实现精细化管理和智能化决策。

本文详细阐述开发者对这个领域技术演进路线的一些看法，XL-LightHouse项目的由来、定位、发展方向以及该领域的商业前景和合作机会。

其实企业别无选择

曾经网络上有个热门的问题：手机上的APP有微信、抖音、淘宝、拼多多、美团、滴滴、京东、王者荣耀...，如果这些APP只能保留一个，你会选择哪个？

对于C端用户每个人的选择或许彼此不同，毕竟每个人生活的侧重点是不同的。

我时常设想一个问题：在不远的将来对于拥有线上业务的互联网和物联网类企业，在数据化运营这个细分领域内，有这样几种技术方案：通用型流式数据统计、OLAP、关系数据库、HTAP、以Spark/Flink为代表的实时计算、离线计算、时序数据库、各种数仓数据湖衍生方案...，如果只能保留其中的一种技术方案，那企业会选择什么？

我认为这个问题B端用户只有一个选择，那就是通用型流式数据统计，因为在数据化运营这个领域内其他技术方案完全没有与之相提并论的资格。通用型流式数据统计技术是互联网和物联网类企业没有可能绕过去的技术方案，企业或许可以现在不使用，但最终一定会使用。

如果将企业数据化运营比喻成一场战役，通用型流式大数据统计这一项技术方案就能够发挥95%的作战力，剩下的5%是由其他技术方案一起提供的。C端用户或许可以偏执的按照个人喜好选择产品，但在残酷的商业竞争中通用型流式数据统计技术就像企业的“眼睛”和“耳朵”一样重要，不用通用型流式数据统计就如同自己选择闭塞耳目。企业数据化运营水平越高，对通用型流式数据统计技术的依赖就越重。

不少朋友会觉得我的观点是”臆想“天开，信口开河，本篇文章我会为大家详细的分析一下为什么会是这样。

• 没有任何一种计算方案能够像通用型流式大数据统计一样如此善于应对大批量的数据指标，XL-LightHouse一个任务可以同时应对大批量的业务场景，可以轻松承载几十万上百万的数据指标，未来云服务厂商凭借通用型流式大数据统计技术一个计算集群就可以支撑千万个、乃至上亿个数据指标的并行计算，可以同时满足庞大数量的企业和用户共同使用。

• 通用型流式大数据统计技术具有极低的使用成本和极其广泛的应用场景，绝对的成本优势使得它能够像触角一样渗透到社会运转的方方面面，成为社会运转的基础型计算服务，而其他任何一种计算方案都没有可能达到这种高度。

• 通用型流式大数据统计技术有鲜明的优势，也存在一些缺点，但是它的缺点容易被补足。

产品的选择或许琳琅满目，但技术路线的选择从来都是清晰的一塌糊涂。就像世界上的高楼大厦星罗棋布、造型各异，但几乎都是用钢筋混凝土建造的。未来企业数据化运营乃至社会数据化运营一定是以通用型流式大数据统计技术为主，以其他技术方案为辅的技术选型，通用型流式大数据统计代表着一种全新的技术路线，它是互联网和物联网类企业发展到一定阶段后的必然选择。

目前主流技术方案

在介绍XL-LightHouse之前我们可以先了解一下目前各类技术方案的优点和缺点，数据处理是一个非常宽泛的话题，以下内容侧重在数据化运营这个细分领域（数据统计分析方面）进行阐述。

OLAP

OLAP是一种用于大规模多维数据分析的技术，广泛应用于商业智能（BI）、数据仓库和大数据分析等领域，帮助用户从不同角度快速洞察数据。通常采用列式存储、预计算、索引、分区裁剪、向量化执行等技术，能够高效处理复杂的聚合查询。

优点：

• 适合大规模复杂的多维数据分析场景；
• 适合交互式即席查询，拥有高性能查询能力；
• 支持多表连接、嵌套查询和窗口函数；
• 支持原始数据明细查询；
• 可支持非常多的维度字段；
• 大多数OLAP引擎支持数据更新和删除；
• 支持按时间或其他维度字段分区和跨分区查询；

缺点：

• OLAP一般应用在比较重量级的数据统计分析业务场景中（如数据量大、字段多、查询逻辑复杂），比如电商企业的订单数据分析、商品数据分析等，由于维护成本高昂并不适合在相对轻量级的业务场景中使用；
• 需要存储海量明细数据、预计算类数据和索引类数据，数据存储和维护成本非常巨大；
• 虽然单次查询响应速度较快，但每次查询需要对数据进行遍历汇总分析，并发查询支持能力有限；
• 主要用于分析历史数据（存量数据分析场景），对实时高并发写入的数据分析能力有限，大多数OLAP引擎不适合用于实时指标计算、业务监控等场景；
• 需要指定分区策略、索引字段类型、预计算方式、运行参数等信息，使用较为笨拙繁琐，不同的OLAP引擎操作各不相同，需要使用者对OLAP引擎的内部机制有深刻理解。整体的接入和维护成本很高，主要面向专业的大数据研发和维护人员，使用门槛比较高；

关系数据库

关系数据库是一种用于管理事务性数据的技术，支持高并发的增删改查操作，广泛应用于需要快速处理大量事务的系统。通常采用行式存储，将一行数据所有列存储在一起，适合频繁的单行读写操作，通过B+树、哈希索引等数据结构，快速定位和访问数据，提升查询性能，使用锁机制和事务隔离级别来保证数据一致性。

优点：

• 侧重于支持高并发、短小的事务处理，通常以关系型数据库为基础，适合实时数据处理，如银行交易、电商订单等；
• 严格遵循ACID特性，能够确保数据的准确性和一致性；
• 针对单条记录的读写操作进行优化，具有低延迟响应能力；
• 主要用于处理结构化数据，可以支持复杂的表关联和约束；
• 能够实时更新和删除数据，适合事务频繁的业务场景；

缺点：

• 由于关系数据库主要基于行存储实现方案，与OLAP列式存储方案相比，列式存储只需要读取相关列的数据，可以减少不必要的数据读取，从而提升跨行数据的查询分析性能，此外列式存储更容易进行数据压缩，可减少了磁盘I/O的开销，相对而言基于行存储方案不具备这些优势，此外关系数据库没有预计算、向量化计算类功能，所以除非一些金融核算等对事务有绝对要求的场景，关系数据库并不适合较大规模的数据统计分析需求；
• 关系数据库的表用于存储高度规范化数据，表与表之间通过外键关联，由于对事务的要求不提倡使用冗余字段，冗余字段会打破数据一致性，很多数据统计分析场景需要依赖多个表之间的Join操作，性能比较低；
• 在高并发场景中，多个事务操作相同数据可能会出现锁竞争，影响读写效率；
• 关系数据库需要处理高并发和实时事务，随着数据量的增大，会面临存储和性能瓶颈导致横向扩展能力受限（行式存储不适合大规模数据的并行读取、索引的维护和锁机制会增加分布式环境下的协调成本）；

以Spark/Flink为代表的实时计算

以Spark/Flink为代表的实时计算主要用于处理流式数据，能够对持续生成的数据流进行实时处理分析。与传统的批处理不同，实时计算强调低延迟、基于事件驱动、适合需要快速响应的业务场景，比如实时监控、推荐系统、风控、物联网数据处理等。

优点：

• 低延迟，可以实现实时或准实时的数据处理，在数据化运营场景适合实现实时性要求较高的数据指标（如每分钟、每小时的实时PV和UV）；
• 高吞吐量，适用于大规模数据实时处理；
• 可以灵活定义窗口大小，支持滚动窗口、滑动窗口、会话窗口等多种窗口类型，满足不同时间粒度的实时指标计算需求；
• 内置容错机制，节点故障时可重新计算丢失的数据，保证数据一致性；
• 支持有状态计算，基于状态管理可实现较复杂的计算逻辑，如实时分布式聚合、分组、去重等；

缺点：

• 复杂度高，流处理系统的搭建、开发和运维较为复杂，特别是在处理高吞吐量数据时需要依据业务场景、数据特点和计算方式等进行特定优化，需要开发者熟悉Spark或Flink比较晦涩的API、窗口机制、水印机制、状态管理等技术细节，使用门槛较高，只面向专业的大数据研发和维护人员；
• 流式计算不适合离线场景（存量数据）处理分析场景；
• 任务执行过程中的Shuffle、数据倾斜等问题可能会严重影响程序的正常执行；
• 每个流式任务需要单独设置cpu、memory、并行度等参数，设置不当会产生比较大的资源浪费，程序执行过程中可能会有内存溢出等异常情况；
• 流式任务处于一直运行的状态，即便没有待处理的消息也会长期占用系统资源，任务并行执行会互相影响；
• 流式任务需要将结果输出到外部存储服务中，如果需要报表展示需要单独实现增加了使用成本；
• 乱序可能导致的数据丢失问题，虽然窗口和水印机制可以减少这种情况，但不能完全规避；
• 状态管理增加系统复杂性，当状态数据过大时会增加存储和计算开销影响执行效率；

离线计算

离线计算一般是采用MapReduce或Spark的计算方式，主要用于处理历史数据或定期更新的批量数据。

优点：

• 能够高效处理大规模离线数据，吞吐量大，适合用于深度数据分析和数据挖掘场景；
• 计算任务执行完成即释放资源，不必长期占用系统资源；
• 可灵活处理任意类型的数据（如结构化、半结构化、非结构化）；
• 任务执行失败后的恢复机制实现相对容易；
• 依赖数据是静态的，一次性执行完成，不需要维护中间态数据；
• 在数据化运营方面，适合计算小时、天、周、月等较长周期的指标需求，适合较为复杂的数据清洗、数据转化、逻辑计算以及多种数据源混合计算的场景；

缺点：

• 计算任务开发成本较高，需要针对数据特征、数据量、计算类型进行特定优化，比如要避免数据倾斜、内存溢出、优化Shuffle等问题，只面向专业的大数据研发和维护人员；
• 延迟高，批处理通常以全量计算为主，适合处理历史数据或定期更新的数据，只适用于对实时性要求不高的场景；
• 离线任务需要单独设置运行参数，设置不当可能会产生比较大的资源浪费，离线任务并行执行会互相影响；
• 离线任务执行需要依赖定时调度，系统整体复杂度较高；
• 离线任务需要将结果输出到外部存储服务中，如果需要报表展示需要单独实现增加了使用成本；

时序数据库

时序数据库是一种专门用于存储和分析时间序列数据的数据库，主要应用于物联网、监控、金融、工业互联网等场景，通常采用列式存储、时间分区、时间索引、数据分片、数据压缩、预计算、倒排索引等技术，其核心特点是高吞吐的写入能力、高效的查询性能和时间序列聚合计算等。

优点：

• 支持高效的时间序列数据存储，适合高频数据采集场景；
• 通过压缩算法（如Gorilla、Delta）可大幅度减少存储数据量；
• 支持时间分区并且支持时间索引、标签索引，支持高效的时间范围查询；
• 支持预计算可显著提升查询效率；
• 支持对时间序列数据进行多种聚合运算操作；

缺点：

• 在复杂场景下的查询能力较弱，大多数场景读写都集中在新数据，集群容易产生负载不均衡；
• 存在高基数数据存储问题，当标签（tags）取值非常多时，倒排索引和元数据管理的开销会急剧增加，可能导致查询性能下降、索引更新缓慢影响写入速度、内存占用过大（倒排索引为了提升读写速度，一般放在内存中维护）；
• 预聚合等机制行业内并没有约定俗成的标准，不同数据库实现方式各有差异，使用逻辑较为繁琐，有较高的接入成本，对于大规模集群的运维管理依赖专业的维护人员；
• 大多数情况下适合较为平稳的数据写入与查询场景，写入速度和整体数据规模有相对准确的预估，对于突发性数据暴涨类场景支持能力有限；
• 大多数情况下并不适合长期累积存储大规模数据，时序数据库通常按照时间分区，新加入节点无法均衡历史数据，集群横向扩容能力相对较弱（基于时间分区的水平扩容方案相比基于hash、rowkey等水平扩容方案更为复杂）；
• 历史数据不可修改；

其他方案

数据化运营领域针对较大规模的数据统计分析主要是以上方案，除此之外还可以由以下方案来实现。

1、基于Redis计数等方案实现

优点：

• 相对于Flink/Spark之类流式计算的技术门槛较低，开发成本较低，适合较为简单的计算场景，适合中小型企业或业务团队使用；
• 数据延迟低；
• 查询性能高；

缺点：

• 没有Flink/Spark之类窗口聚合、状态管理等机制，需要自己单独实现，否则如果每次消息事件都读写Redis在请求量较大的情况下会对集群产生比较大的压力，系统瓶颈主要受限于CPU和网络IO；
• 数据存储在Redis中内存成本相对较高；
• 集群重启可能导致数据丢失；
• 系统架构包含后端服务、Redis集群和可视化服务，整体架构较为复杂；
• 不同计算任务复用性差，每个任务都需要维护相应数据，维护成本较高；

2、基于数据湖之类方案，比如Iceberg、Hudi

以Iceberg为例：

优点：

• 基于开放式数据存储格式，支持大规模数据存储，存储成本较低，同一份数据可被多种计算引擎兼容；
• 支持ACID事务，可保证数据的一致性和完整性；
• 支持SQL查询；
• 支持高效的单行Upsert操作（单行写入和更新）；
• 基于snapshot可保留所有数据版本，支持查询历史版本数据；
• 可以同时支持存储结构化和非结构化数据；
• 存储和计算分离，可按需弹性扩展；
• 支持动态添加、删除和修改字段（可灵活修改Schema结构，历史数据自动兼容不需要重写数据）；
• 支持小文件自动合并；
• 相较于传统数仓(hive)等方案对数据的实时写入能力更强，可满足一定有时效性的计算需求；

缺点：

• 本身并不是数据库，也不是计算引擎，而是一种数据湖表格式，数据存储需要依赖外部存储引擎如hdfs/s3，自身通过管理外部数据的存储路径和元数据信息实现存储功能，计算需要依赖其他计算引擎如Spark/Flink，查询需要额外计算资源；
• 查询结构化数据的性能相比clickhouse之类的OLAP引擎较差；
• 不适合较高并发的交互式查询；
• 整体数据平台架构非常复杂，需要依赖多种复杂组件的衔接，面向专业的大数据研发和运维团队，成本高昂，只适用于大中型企业；
• 只适合大规模离线数据湖的数据处理，除非一些要求强一致性业务否则并不太适合作为数据统计、报表输出等场景；

3、基于一站式数据平台

目前有很多厂商提供一站式数据平台，这些数据平台更像是在传统方案的衍生、增强和集成，这种一站式的数据平台大多数建立在OLAP、流式计算、时序数据库等技术方案之上并提供一些更便捷的功能。

优势：

• 提供更便捷的集群弹性扩容能力；
• 一体化的数据报表生成方式；
• 一次性数据录入，提供多种数据分析和利用方式；
• 运维自动化；

劣势：

• 并没有从底层逻辑改变传统方案计算和存储方面的特性，也没有打破传统方案的瓶颈；
• 虽然提供了便利性，但并不能较大幅度的降低使用方的成本，甚至成本可能更高；
• 一站式服务往往会聚合各类业务需求，提供的功能臃肿、繁多，这类产品的定位决定了几乎一定会偏执的追求功能丰富度，却也同时降低了易用性、灵活性和性价比；

数据化运营业务需求的变迁

企业关注哪些数据指标

企业运转所需要的数据指标是非常多的，以一个电商企业来说：

• 企业决策层关注平台的交易额、交易量、下单用户数、订单平均金额、人均消费金额、退款率等指标；
• 产品经理关注其所负责产品模块的pv、uv、点击率，关注APP内任何一个按钮的点击量或表单的提交量、提交用户数等指标；
• 某个业务线的负责人关注各个类目下商品的订单量、加购量、加购率、付款率、退款率、物流包裹量、配送时长、订单好评率、差评率、举报率等指标；
• 运营人员关注拉新用户量、各访问渠道用户量、站内各个广告位的点击量、点击用户数、点击收益等指标；
• 后端工程师关注接口调用量、异常量、耗时情况等指标，需要为线上服务建立完善的指标监控体系，需要辅助进行服务的压力测试；
• 客户端工程师关注App启动耗时、App异常退出率、各版本号App的用户量、下载量、用户停留时间，关注每个弹窗广告显示量、加载异常量；
• 算法工程师关注模型训练时长、模型上线后的效果评测、各模型的ABTest效果对比；
• 运维工程师关注线上集群的CPU、内存、负载状况、IO、请求数、流量传输大小、线上服务请求量、404异常率、服务器宕机情况；
• 数据库工程师关注数据库的数据写入量、SQL执行量、SQL执行平均耗时、请求数据返回量、SQL异常率、超时率、集群负载状况等指标；
• UI设计师关注不同设计方案的点击转化对比情况；
• 数据分析师需要全面的数据指标才能更准确的判断业务短板、业务走势、辅助决策层有针对性制定营销计划；
• 销售主管关注每个下属的营销电话量、营销平均通话时长、投诉率、签约率等指标；
• HRBP关注各个部门每个员工每天的打卡情况、工作时长、迟到率、缺勤率、早退率等指标；

不同业务领域的企业关注的数据指标可能会有较大差异：

• 短视频App关注某个视频的播放量、点赞量、主播关注量、评论量、完播率，每天每个主播的新增关注量、取关量；
• 直播类App关注直播间的访客量、停留时长、刷礼物的数量、打赏金额；
• 房产类App关注各个城市各个片区每天房源上架量、下架量、涨价量、降价量；
• 交通领域关注各城市的各条道路的车流量、人流量；
• 电力领域关注各城市的各企业、各小区、各家庭用电量情况；
• 农业领域关注各城市的各辖区每一亩麦田的长势情况；
• 房管领域关注各城市的每栋建筑的承压健康情况；
• 水利领域关注每条河流每条河段的水温、水质、水位、水流速度等情况；
• 一个物联网类企业关注终端设备每分钟、每小时、每天的数据上报量以及相关各类指标计算；
• 一个智能工厂关注每个车间每台机器的运转情况，比如计件数、是否正常运转、故障率、耗电情况等；

数据指标呈现的特性

站在更高的视角观察企业运转乃至社会运转所需要的各类数据指标，会发现这些数据指标呈现以下特点：

• 指标数量繁多，遍及企业运转的各个细微环节；
• 指标彼此间数据量差异很大；
• 指标计算的时间窗口各不相同；
• 数据源头各式各样；
• 有些指标是需要长期关注的而有些可能只是临时性的；
• 指标面向的使用人群各不相同；
• 指标的重要程度参差不齐；

市场需求的变化趋势

• 数据驱动决策成为核心，未来社会需要千亿量级的数据指标；

在现代商业环境中，数据驱动已逐步取代过去单纯依赖经验和直觉的决策模式，成为企业竞争的关键要素。小微企业可能关注数十到数百个数据指标，而中大型企业关注的数据指标量可达数千个到十几个万个。数据指标不再只是辅助工具，而是企业核心生产力，渗透至生产、运营、营销、供应链、客户管理等多个环节。随着物联网、车联网、工业互联网和AI等新兴技术的快速发展，企业对数据的依赖程度持续增强，而数据指标需求将呈现爆炸式增长。

• 实时数据分析需求快速增加；

物联网、工业互联网及数值监控告警等场景对实时数据分析需求尤为突出，此外实时数据分析能够帮助企业及时捕捉市场趋势、消费者行为变化等关键信息，从而快速调整策略，抢占市场先机。实时数据分析已成为企业应对快速变化的重要能力。

• 自助式数据分析工具将成为主流，而同时方便、快捷、易用的产品更容易获得青睐；

在PC时代和移动互联网初期，数据分析工具通常提供固定、统一的数据指标，难以满足企业多样且快速变化的需求。如今，企业迫切需要更为便捷、灵活的自助式工具。另外，很多数据分析工具需要专业的技术背景和编程技能，限制了非技术人员的使用，企业期望这类工具通过直观的界面和可视化功能，充分降低使用门槛，非技术人员也能轻松进行数据探索和分析，减少对IT支持的依赖提升效率。

• 市场用户更为理性，更加追求"性价比为王"的产品；

市场竞争日益激烈，企业用户在选择数据分析工具时更加注重性价比，企业希望在有限预算内获得兼具强大功能、易用性和可扩展性的产品。过于昂贵、使用复杂的解决方案正逐步被市场淘汰，而那些能够提供核心价值同时使用成本更低的产品则更具竞争力。

• "数据指标共享体系"才能实现最大化的商业价值；

数据指标共享体系能够打破数据孤岛，实现数据的高效利用，在企业内部不同部门往往拥有各自的数据指标，通过建立数据指标共享体系，可以将这些分散的数据整合起来提升数据的利用率，单一部门的数据指标往往只能反映局部的业务情况，而共享的数据指标能够提供全局视角，帮助管理层做出更全面、准确的决策，数据是企业的重要资产，通过共享体系可形成更强大的数据资产。在社会层面当众多的企业和行业参与者能够共享有价值的数据指标才能促进更紧密的商业协作。

什么是流式统计？

流式数据指的是实时产生的、连续的数据流，由一个个带有时间戳的消息事件组成，通常来自外部数据源（如线上服务、操作日志、传感器、设备监控等），一般来说流式数据是在事件发生时产生的仍处于流转过程中暂未被存储的数据，与之相对应的概念是已被存储的数据（可称作批处理数据、历史数据或者持久化数据）。

比如：

• 用户点击某个按钮称作一个点击事件，线上所有用户点击该按钮的事件序列称作一份流式数据，所有用户点击按钮的数据存储到hdfs后称之为批处理数据/历史数据。
• 用户下单操作称作一个下单事件，线上所有用户下单事件流称作一份流式数据，订单数据保存到数据库后称之为批处理数据/历史数据。

流式统计是针对流式数据基于窗口（滚动窗口、滑动窗口）进行即时处理、分析、聚合的技术，流式统计的优点在于：低延迟、高吞吐量、计算性能高、不依赖数据存储即可完成计算、使用更为灵活便捷。

XL-LightHouse拥有极致的爆发力

产品定位

行业发展催生了一大批开源或商用的产品，并演化出多种技术路线，这个领域似乎已经发展到了一个较为成熟的阶段，琳琅满目的产品可供选择，也几乎没有什么业务场景是现有的技术方案难以解决的。但即便如此我依然感觉这个领域中缺少了一个更具有“爆发力”的产品，以至于不管是互联网企业、物联网企业还是更大范围的城市治理、社会治理的数据化运营水平始终停留在一个较低层次徘徊，而没有迎来一个“质变”的时刻。企业内部数据指标的获取成本依然很高，行业内没有形成广泛统一、约定俗成的数据指标存储和可视化标准，更大范围的数据指标共享体系建设方面依然步履维艰。

导致这些现象的原因我认为有两点：

• 目前的技术方案虽然可以应对各种复杂场景，但都太过于"笨重"、也太过于"奢侈"，善于应对单个或少数业务场景，但不善于应对大批量业务场景，技术门槛、实施难度等多种因素产生高昂的成本限制了很多技术方案被大范围使用，所以不能触发这种质变；
• 数据化运营产品的角逐不应该只局限在"计算"环节，而应该涵盖：指标计算、指标存储、指标管理、指标可视化和指标共享整个链条，最强大的数据化运营产品是提供一套机制解决各个环节的问题，并建立更大范围的数据指标共享体系才能将社会价值最大化；

所以我设计和开发了XL-LightHouse这个项目，相比于其他任何技术方案，它拥有更极致的“爆发力”，它的目的在于：

• 聚焦于指标计算，大幅度降低企业数据指标获取成本，帮助企业搭建遍布全身的数据化运营体系；
• 在行业内形成广泛统一的数据指标计算、存储、监控告警和可视化标准；
• 为更大范围的数据指标共享体系的建立奠定基础；

流式事件驱动计算机制

数据指标计算方式分为三种：离线处理（Offline Processing）、交互式即席查询（Ad-hoc Query）和流式处理（Stream Processing）。随着企业数据化运营理念的逐渐深入，数据分析的核心目标从历史数据复盘逐步向实时智能决策转变，在这一趋势下流式指标计算正迅速成为企业数据分析的主流模式，并且流式计算本身并不依赖原始数据的存储，它在数据流转过程中即可完成指标计算，在很多场景下这种模式可以大幅度减少不必要的原始数据存储和维护成本，相较于传统的离线计算和Ad-hoc查询，流式计算在时效性、使用灵活性、计算效率和决策驱动性等方面展现出更大的优势。

离线计算通常会全量扫描数据，以小时或天为粒度计算数据，难以实时响应业务需求。Ad-hoc应对高并发、超大数据量的查询压力比较大，查询性能受到数据分布、索引机制和预计算策略等多方面的影响，使得Ad-hoc更适用于偶发性分析，而非高频、大规模的实时指标计算。物联网、工业互联网、AI智能制造等技术的普及使得数据生成速度和规模呈指数级增长，数据流动性和实时化将成为数据生态系统的核心特征，未来流式指标计算将在数据分析领域占据主导地位，相比之下离线指标计算和Ad-hoc Query虽然仍有其价值，但应用场景将逐渐收窄，所以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。

线程模型

以SparkSQL为例对比XL-LightHouse的线程模型。

1、SparkSQL任务线程模型：

• Spark一个任务只能处理一条或少数几条数据流，只能实现一个或少数几个数据指标；
• Spark集群分为Driver节点和Executor节点；
• Driver节点主要包含：Main线程（负责启动任务、应用初始化、开始流计算、管理任务生命周期、维护checkpoint机制）、任务执行线程（负责任务解析生成物理计划、任务拆分、提交子任务给Executor、申请运算资源、接收Executor返回数据）；
• Executor为集群的运算节点，主要包含：Task线程（负责连接外部数据源并读取数据、负责具体的任务执行，一个线程处理一个Task）、Shuffle线程（负责分布式计算节点间的数据发送和接收）、Output线程（负责向外部输出结果）；
• Driver节点解析SQL语句，使用Catalyst优化器将SQL语句解析为查询计划并优化查询计划；
• Driver依据是否会触发Shuffle操作（如Join、Group By、Distinct）将任务划分为多个Stage，每个Stage包含一组可以并行执行的Task子任务，Task是最小的执行单元，然后将子任务提交给Executor；
• Executor接收Task并执行，每个Task处理一个数据分区，并占用分配的CPU核数和内存，通过Shuffle完成不同Stage之间的数据交换；
• 执行完成后，将计算结果返回给Driver；

资源分配逻辑：

• 一个集群内不同的计算任务需要分别分配资源，几乎所有的数据指标都需要单独分配资源；
• Spark的资源分配是基于Executor，每个Executor上可运行多个Task，Executor的资源由Cluster Manager（比如YARN）分配；
• 每个Task占用一定的CPU和内存资源，由spark.task.cpus和spark.task.memory等参数控制；
• 如果多个SQL语句同时提交，Spark会尝试将它们的Task子任务分配到可用的Executor上；
• 如果资源不足，Spark会按照 FIFO（先进先出）或FAIR（公平调度）策略调度任务，两个SQL语句共享同一个SparkContext，它们会竞争相同的资源池；

2、XL-LightHouse线程模型：

• XL-LightHouse所处理的数据流是所有统计指标原始数据汇总的数据流，每个数据指标不需要依赖单独的任务，在计算过程中按照xl-formula配置拆分为若干种算子，每个数据指标也没有单独的时间窗口的概念，一个任务能并行处理上百万条数据流；
• XL-LightHouse集群包含Driver节点和Executor节点；
• Driver节点主要包含：Main线程（负责启动任务、应用初始化、开始流计算、管理任务生命周期、维护checkpoint机制）、任务执行线程（申请运算资源、接收Executor返回数据）；
• Executor为集群的运算节点，所有统计任务汇总数据流均匀分配到每个Executor节点进行消费，主要包含：Task线程（负责连接外部数据源并读取数据、加载计算任务、任务拆分），运算算子线程池（系统使用异步处理、批量消费的处理模式，每种运算算子都有对应的消费线程池、消费线程读取缓冲池数据进行聚合计算、在计算过程中维护结果和中间态数据）；
• Executor解析每条原始消息根据原始消息中的标识字段加载对应的统计任务即xl-formula配置信息；
• Executor按照统计任务的时间窗口、维度信息、运算函数类型划分成独立的算子，并将每个算子放入到消息缓冲池；
• Executor中维护不同算子类型的消费线程池，由消费线程对各消息缓冲池数据进行聚合计算；
• 计算结果写入状态存储；

资源分配逻辑：

• XL-LightHouse一个任务可以应对大批量数据指标，只需要对集群整体进行资源分配即可；
• 所有统计指标相同类型算子都是混合在一起处理，不需要单独为每个统计指标或算子分配计算资源，彼此间没有资源隔离；
• 一个线程可同时处理不同统计指标的计算逻辑，算子之间互不影响；

基于流式统计配置标准XL-Formula

由于SQL规范本身更适合面向批处理、离线数据分析、即席查询等场景，在流式统计方面存在很多瓶颈，所以本项目基于自主设计的配置标准XL-Formula（将在下面内容中对比SQL标准和XL-Formula标准的执行逻辑）。

XL-Formula是一种用于描述流式统计运算方式的配置标准，它代表着一种通用型流式统计系统的实现方法，更深层次它代表着一种以通用型流式统计技术为切入点，低成本实现企业数据化运营的理念。

相比于SQL规范，该配置标准语法简洁、功能强大、解析效率高、便于理解和使用。

• XL-Formula涵盖了各种流式数据统计运算场景，包括count、sum、max、min、avg、bitcount等多种运算。
• XL-Formula支持单维度、多维度计算。
• XL-Formula支持秒级、分钟级、小时级、天级多种时间粒度的统计，支持自定义统计周期的配置。
• XL-Formula支持滚动窗口和滑动窗口的数据统计。
• XL-Formula支持多种运算函数的组合使用。
• XL-Formula可以满足各种复杂的条件筛选和逻辑判断。
• XL-Formula支持topN/lastN运算。
• XL-Formula内置丰富的转化类函数，支持系统变量、日期变量的插入使用。
• XL-Formula支持时序性数据存储和计算。
• XL-Formula支持统计结果有效期设置。

部分场景使用示例，请查阅dtstep.com相关文档了解更多：

1、统计总订单量
<stat-item title="订单量" stat="count()"/>
2、统计总下单用户数
<stat-item title="下单用户数" stat="bitcount(userId)"/>
3、统计订单总金额
<stat-item title="订单总金额" stat="sum(amount)"/>
4、统计每个城市的订单量
<stat-item title="各城市_订单量" stat="count()" dimens="city"/>
5、统计每个城市的订单总金额
<stat-item title="各城市_订单总金额" stat="sum(amount)" dimens="city"/>
6、统计每个业务的下单用户数
<stat-item title="各业务_下单用户数" stat="bitcount(userId)" dimens="biz"/>
7、统计各个城市订单金额超过100元的比例
<stat-item title="各城市_大于100元订单占比" stat="count(amount>100)/count()" dimens="city"/>
8、统计每个商户的订单总金额
<stat-item title="各商户_订单总金额" stat="sum(amount)" dimens="sellerId"/>
9、统计每个业务的订单总金额
<stat-item title="各业务_订单总金额" stat="sum(productAmount)" dimens="biz"/>
10、统计北京市和上海市各业务的订单总金额
<stat-item title="北京上海_各业务_订单总金额" stat="sum(productAmount,province == 'beijing') + sum(productAmount,province == 'shanghai')" dimens="biz"/>
11、统计各个城市各个业务的下单用户数
<stat-item title="各城市_各业务_下单用户数" stat="bitcount(userId)" dimens="city;biz"/>
12、统计各个城市各个业务的下单总金额
<stat-item title="各城市_各业务_下单总金额" stat="sum(productAmount)" dimens="city;biz"/>
13、统计各个业务、各个商品类别总成交金额
<stat-item title="各业务_各商品类别_总成交金额" stat="sum(productAmount)" dimens="biz;category"/>
14、统计每个城市、各个业务、各个类别的下单用户数
<stat-item title="各城市_各业务_各类别_下单用户数" stat="bitcount(userId)" dimens="city;biz;category"/>
15、统计各个业务的平均订单金额
<stat-item title="各业务_平均金额" stat="avg(productAmount)" dimens="biz"/>
16、统计每天、下单用户数top10的商户
<stat-item title="每天_交易额top10商户" stat="sum(productAmount)" dimens="dealerId" limit="top10"/>
17、统计每天、每个业务销售额最高的商品top10商品
<stat-item title="每天_成交金额top10商品" stat="sum(productAmount)" dimens="productId" limit="top10"/> 

逐层递减的消费链路

XL-LightHouse聚焦于流式指标计算，与Flink/Spark之类方案的定位显著不同，它依据流式统计运算特点量身设计，在整体数据消费链路层面遵循逐层递减原则。

• 系统在每个环节都会尽早抛弃与下游计算无关信息并将所有同类算子充分聚合；
• 系统在每个环节都会尽可能减少向下游环节的数据传输量；
• 系统在每个环节都会尽可能减少对外部存储的读写次数；

系统消费链路分成以下基本环节：Client模块上报原始数据环节、RPC模块接收数据环节、运算模块执行展开、分组和实时计算环节、统计结果存储环节。在每个环节系统使用异步处理、批量消费、对重复性计算进行聚合处理的方案，各环节接收到消息后放入消息缓冲池，系统依据各环节的预定义聚合逻辑将消息划分成不同的计算类型并对进程内相同类型消息聚合处理，这种设计可以充分降低下游环节的运算量、数据传输量、DB读写次数，有效提升计算效率。

不同环节的消息聚合逻辑各有不同，以Client模块为例包括以下内容：

• 消息体列裁剪

为了提高消息的传输速度并提升后续步骤消息聚合效率，Client模块需要对原始消息进行裁剪操作，其目的是去掉统计无关字段。统计无关字段是系统根据各统计组下所有有效统计项计算得来，将所有与有效统计项均不相关的字段在Client模块上报数据之前将其过滤掉，避免非必要的数据传输。

• 篡改消息体时间戳

Client模块上报消息环节在执行聚合操作前修改消息原始时间戳为最小批次时间，其目的是为了后续步骤中在保证数据准确性的前提下能够将尽可能多的消息聚合到一起。Client模块以当前统计组下所有有效统计项的统计周期的最大公约数为时间窗口，按照该时间窗口和消息原始时间戳计算得到消息所对应的最小批次时间。Client模块将消息原来的时间戳修改为最小批次时间然后放入缓冲池。

• 聚合操作

聚合操作即为将同类型消息按预定义聚合逻辑合并到一起。不同环节的聚合逻辑略有不同，Client模块的聚合逻辑是指消息内容一致的消息，即为相同统计组、相同参数值的消息。原始消息发送到缓冲池后消费线程组定时从缓冲池中批量读取消息，并将其中符合聚合规则的消息聚合到一起，经过聚合操作后消息体的数据结构由单条消息体内容变更为消息体内容和消息体重复次数两个属性。

消息缓冲池设计

XL-LightHouse是多流并行机制，逐层递减的消费链路，能否最大化的将相同算子的消息事件聚合在一起处理对程序执行效率有很大影响，为此系统使用与这种数据消费模式更为匹配的消息聚合缓冲池。

聚合处理所依赖的消息缓冲池实现方案基于优先阻塞队列，系统将消息缓冲池划分成若干个Slot，每一个Slot由一个BoundedPriorityBlockingQueue（优先阻塞队列）和Slot对应的最后访问时间戳组成。

消息缓冲池的处理逻辑包括以下步骤：

• Producer指定消息事件的唯一标识，唯一标识用于区分是否为相同类型的消息，可根据统计组标识、统计项标识、时间批次和统计维度等信息生成（在消息各环节唯一标识的生成逻辑各有不同）；
• 消息缓冲池依据消息唯一标识分配对应的Slot；
• Slot对其内部的消息按照唯一标识进行优先排序，优先排序按照窗口优先和唯一标识自然顺序进行排序，窗口由系统指定，默认为1分钟，不同窗口的消息按照窗口时间正序排列，相同时间窗口的消息按照唯一标识自然顺序排列，越靠前的消息越早被处理；
• 消费队列定时轮询各个Slot；
• 判断Slot的使用容量是否超出阈值，阈值为batchsize * backlog_factor，其中batchsize为指定的单次消费最大消息数量，backlog_factor为指定的消息积压系数，用于控制消费速度，消息过早被消费会使得聚合不够充分，而过晚消费会导致一定延迟；
• 如果Slot使用容量没有超出阈值，则继续判断Slot的上次消费访问时间，如果超出时间阈值则读取消息批量消费，否则跳过本次任务。
• 消费Slot消息后同时更新Slot使用容量以及最后访问时间。

基数计算

1、常见的技术实现方案

实际业务需求中有很多基数统计场景（Count Distinct），常见的基数实现方案有以下几种：

• 精确值统计

将每个元素放入Hash/Set/List集合，在每次插入新元素时检查是否已存在，通过获取集合元素的数量得到最终结果。该算法统计结果准确，适用于需要精确统计或需要准确判断某个元素是否存在的场景，但缺点是内存占用极高，需要存储所有元素，随着数据增长查询和去重的开销不断上升，不适合基数较大的计算场景。

• 基于HyperLogLog算法

HyperLogLog是一种概率性基数估计算法，用于高效统计海量数据中的唯一元素数量（如独立访客数UV）。其核心特点是极低的内存占用和可控的误差率，它利用哈希函数的随机性，估计去重后的元素个数而不存储实际元素，只需要维护小型寄存器数组，适用于大规模数据统计。这种算法内存占用极低，但对有较高精度要求的场景不适用，仅支持去重统计不适用于查询已存在元素，这种算法误差约2%，但误差率并不稳定，很可能更高。

• 基于Bitmap实现

Bitmap（位图）是一种基于位运算的数据结构，它的核心是一个二进制数组，用于高效存储和操作布尔值（如存在/不存在）。在UV统计中Bitmap通过将每个用户映射到位图中的某一位，统计值为（Bit=1）的数量来计算独立用户数。这种算法的优点在于内存占用相比HashSet等方式要少得多，每个用户仅占用1个比特位，连续的1亿用户存储仅需约12MB内存，支持O(1)时间复杂度的插入和查询操作，结果100%准确，无误差，缺点是更适合连续id的存储场景，在稀疏存储的情况下Bitmap同样会浪费大量内存。

• 基于RoaringBitmap实现

RoaringBitmap是针对Bitmap的改进方案，优化Bitmap的存储方式，是一种高效的位图压缩算法。它内置三种存储容器，针对高密度数据、低密度数据和连续型数据分别选择对应容器，采用分块（chunk-based）存储，避免存储所有bit，相对于Bitmap可明显减少内存浪费，读写速度与Bitmap接近。

2、针对基数计算的优化

XL-LightHouse的基数运算使用"分片 + Roaringbitmap"的方案实现，并针对流式统计的运算特点进行了改进。

系统通过使用基数过滤装置过滤已存在的基数值，判定在过滤装置中不存在的基数数量然后更新DB中的统计结果从而实现基数统计。基数过滤装置包括内存基数过滤装置和分布式基数过滤装置两部分。内存基数过滤装置的作用在于初步判断基数值是否已存在，内存判断效率更高，可以尽可能避免重复性的基数判断对整体性能的影响，内存基数过滤装置使用RoaringBitMap工具包实现。分布式基数过滤装置内含多个分片，每个分片对应一个RoaringBitMap数据存储结构。

基数运算包括以下环节：

• 将原始数值经过MurmurHash-128Bit生成原始数值对应的Long型的Hash值；
• 设置统计任务所需的分片数，每个分片对应一个RoaringBitMap数据过滤装置，通过Hash取余获取始数值对应的分片；
• 将Long型Hash值按高32bit和低32bit拆分成两个Int类型整数，两个Int值的组合对应原始值在RoaringBitMap数据结构中的index值；
• 判断Int值组合是否在过滤装置中存在，如果两个Int值都在过滤装置中存在，则表示原始值已存在，否则表示原始值不存在；
• 统计在过滤装置中不存在的原始值的数量并更新到DB中；

该实现方案基数运算不需要存储原始值可以减少对内存的占用；使用MurmurHash-128Bit生成index值的方式不需要维护原始数值和Index的映射关系；RoaringBitMap算法本身具有压缩位图功能可以减少基数稀疏情况下的资源占用的问题；内存基数过滤可有效减少对外部存储的读写次数和数据量；统计计算可以保持非常高的精确度（1亿级基数误差率在千分之一以内），通过调整分片数可控制基数运算准确度。

完全规避Shuffle

在分布式计算中Shuffle是将数据在不同节点之间重新分配和重组的过程，通常发生在分布式计算的某些操作中，如groupBy、reduceBy、join、distinct、orderBy等。将具有相同键的数据重新分配到同一个节点以便进行后续聚合计算，这个过程就是Shuffle。Shuffle需要将大量数据通过网络传输，这会消耗网络IO并增加延迟，数据在传输前需要序列化，接收后需要反序列化会消耗CPU资源。Shuffle是一个全局同步操作，所有任务需要等待Shuffle完成后才能继续执行，这可能导致任务延迟，在分布式计算中Shuffle是影响性能的最主要因素之一。

XL-LightHouse单个任务可以处理上百万条数据流，能够实现大批量数据指标的并行计算，大批量的数据指标的计算特性存在很大的差异性，数据量、运算函数类型、时间周期、维度基数数量等因素可能截然不同，而如果一个数据指标在计算过程中产生大量Shuffle，那会给整个服务的稳定性造成严重影响，因此为了避免Shuffle可能带来的不稳定性，系统采用完全规避Shuffle的实现方案。

XL-LightHouse的每个计算节点处理指定分区的消息数据，在计算节点内部解析基于XL-Formula配置的计算任务，系统使用外部装置存储中间态数据，每个计算节点只与状态存储进行通讯，计算节点之间不需要任何数据通信，通过分布式分段锁保证结果的准确性。

完全规避数据倾斜

Spark/Flink在执行groupBy、reduceBy等操作时，会将相同键值的数据汇聚到一起，如果某些键的数据量远大于其他键会导致部分节点负载过高形成数据倾斜，从而拖慢整体计算速度，严重时可能会导致内存溢出严重影响服务的稳定性。

由于XL-LightHouse的每个计算节点是平均消费消息服务中的数据，而在计算时采用完全规避Shuffle的方案并不需要将不同节点的数据聚合在一起，所以完全不存在数据倾斜的情况。

完全规避Shuffle和数据倾斜才使得XL-LightHouse具有极高的稳定性，不会因为单个数据指标的计算特性而影响到整体服务，使得其承载百万量级数据指标并行计算成为可能。

对于流式计算的乱序问题

在流式计算中乱序问题是指数据流中的事件没有按照其实际发生的时间顺序到达计算系统。出现这种情况的原因有多种，比如：数据在传输过程中因为网络拥塞、路由问题等导致延迟，使得后发生的事件先到达；分布式数据源可能来自多个分区或节点，不同分区的数据到达计算系统的顺序不一致；数据通常会被并行处理，不同节点的处理速度不一致而使得事件顺序混乱。

乱序事件可能导致窗口的触发时间不准确从而影响计算结果，在目前主流的流式计算框架中采用Watermark机制来减少乱序导致的数据错误问题。Watermark是一种用于衡量数据时间进度的机制，表示“在某个时间点之前的数据已经全部到达”，当Watermark超过窗口的结束时间窗口会被触发计算。 Watermark机制允许用户设置一个最大乱序时间（如5秒），如果事件的延迟超过最大乱序时间，则会被认为该事件是“迟到事件”并将其丢弃，一旦窗口被触发计算，计算引擎默认关闭该窗口，不再接受新的事件，即使延迟事件在窗口关闭后到达也无法被处理，并且在窗口时间和水印时间过期后，计算引擎会定期清理历史窗口的状态数据，所以Flink和Spark基于Watermark机制可有效处理乱序问题但不能完全避免。

而XL-LightHouse并不按照每个统计任务的时间窗口进行数据处理，XL-LightHouse虽然按照微批（Micro-Batch）来消费数据，但窗口时间是相对所有统计指标汇总数据流来说的，每个统计指标并没有单独的数据流和时间窗口，不同统计周期的计算逻辑被划分成不同的"算子"进行逻辑运算。此外由于XL-LightHouse将统计指标的状态数据放在外部存储系统中维护，所以在每个微批窗口结束时不会清理原状态数据，所以XL-LightHouse项目不会出现由于乱序而导致统计错误的情况。

对流式计算的资源浪费和持续占用问题

流式计算框架会耗费大量的系统资源，导致这一情况的原因主要有以下几种：

• 持续运行与资源占用：流式计算框架需要持续运行以处理源源不断的数据流，无法像批处理任务那样在计算完成后立即释放资源；
• 任务与资源分配：单个流式任务通常只能处理少量数据流，实现少数数据指标，而大批量的数据指标需要依赖大量任务并行执行，每个任务都需要单独分配计算资源；
• 状态数据存储：流式计算中的窗口计算和有状态计算需要在内存或外部存储中保存中间状态数据，而对于长窗口（如1天、7天）或大数据量任务，状态数据急剧膨胀，进一步增加资源消耗；
• 数据分布不均匀：数据分布不均匀可能导致某些计算节点处理的数据量远超其他节点，引发CPU过载、内存溢出（OOM）等问题，而为了避免这一情况就需要分配更充分的资源；
• 资源冗余配置：为了应对突发流量，许多流式计算场景需要设置较大的资源冗余，这可能导致资源利用率低下；
• 程序优化不足：Flink/Spark等流式计算框架的性能高度依赖于任务优化（如数据量、数据倾斜、运算类型、统计周期粒度等），而研发人员可能缺乏足够的时间或经验进行针对性优化，导致任务运行效率低下，间接浪费大量计算资源；
• 资源配置不当：实现不同的统计需求需要研发人员开发并提交相应的计算任务。如果资源配置设置不当（如申请的资源远超实际需求），也会造成较大的资源浪费，开发人员申请超过实际需求数倍资源的情况并不少见；

在实现流式指标计算方面，XL-LightHouse对资源的利用率要比Flink/Spark之类方案高的多得多，可以极大程度上的解决持续资源占用/资源浪费的问题，主要区别在于：

• XL-LightHouse是针对集群整体分配资源，不需要单独为每一个数据指标分配资源，所以不存在单个任务的冗余资源，也不会因为开发人员参数设置等问题而造成资源浪费；
• XL-LightHouse针对每一种流式统计运算函数进行了反复的优化，具有极高的执行性能，使其可以无限制的复用，除了元数据上报逻辑之外不需要业务接入人员进行任何定制化的开发和优化；
• XL-LightHouse只保存统计结果，并且统计结果和中间态数据都放在外部存储中，不存在数据分布不均匀、内存溢出、运行过程中Shuffle问题等情况；
• XL-LightHouse可并行处理大量数据指标，可以充分发挥规模优势，并且如果某些数据指标在某个时段没有消息数据则丝毫不占用运算资源；

数据指标的计算逻辑

XL-LightHouse使用"统计工程-统计组-统计项"的三层结构管理所有统计需求，每一个统计需求对应一个统计项，用户可根据需要创建若干个统计工程，每个统计工程可以包括多个统计项，而基于同一份元数据的多个统计项叫做一个统计组。

系统将流式统计运算场景抽象分类成多种运算单元，包括：count次数运算单元、sum求和运算单元、max最大值运算单元、min最小值运算单元、avg平均值运算单元、seq时序运算单元和bitcount基数运算单元等。在系统中统计项基于xl-formula格式的表达式创建，每个统计项的计算逻辑都是由一个或多个统计运算单元组合生成。

XL-LightHouse针对一份元数据可以创建任意数量的统计任务，统计组下所有统计项共用一份消息数据，其目的在于统计组下每个统计项不需要单独的消息数据发送，可有效减少重复性的数据接收、解析、参数校验等逻辑，并提升了网络IO效率，当运算模块接收到消息数据后会对统计消息进行展开和分组操作。

• 展开操作：即为查询统计组下所有有效统计项，提取各统计项的关联字段，为各统计项复制一份单独的消息数据并只保留其运算相关字段的过程，展开操作的目的是为了避免各统计项的后续运算逻辑相互之间产生影响；

• 分组操作：即为在接收到原始消息后，将相应统计任务拆解成若干算子的过程，系统依据时间窗口、维度属性、统计运算单元将统计运算过程进行分解，并将同类型消息聚合处理，不同类型的消息运算过程互不影响；

限流保护机制

XL-LightHouse可以并行处理百万量级数据指标，为了避免因为某个大数据量的统计需求的突然接入或某个统计指标的流量暴涨而导致系统整体不稳定，系统具有限流保护机制。限流保护机制包含两个方面：

• 统计组消息量限流

统计组消息量限流是针对单位时间内接收到的统计组消息数量的限流策略。系统内置统计组消息量计数装置用于计算单位时间内接收到的统计组消息数量。当单位时间内消息量超出阈值后触发限流，使当前统计组进入限流状态。Client模块以及Tasks模块自动抛弃非正常状态下的统计组消息。由于一个统计组可对应一个或多个统计项，所以该限流策略会影响统计组下所有统计项的正常统计。统计组进入限流状态后在指定时间内（默认20分钟）自动抛弃相应消息，当限流时间达到时间阈值后统计组自动恢复到正常状态。

• 统计项结果量限流

统计项结果量限流是针对单位时间内统计项生成的统计结果数量的限流策略。系统内置统计项结果量计数装置用于计算单位时间内统计项结果的生成数量。当单位时间内结果量超出阈值后触发限流，使当前统计项进入限流状态。统计项结果量跟两个因素有关，一是统计周期的时间粒度，统计周期粒度越细的指标数据量越多，比如秒级和分钟级统计单位时间内生成的统计结果要多于小时级和天级的统计。第二个影响因素是维度，维度数量越多的统计项单位时间内生成的统计结果更多，比如以城市为维度的统计指标生成的统计结果量要高于以省份为维度的统计指标。统计项结果量限流是针对当前统计项的限流策略，所以只对当前统计项有影响，对于统计组下其他统计项没有影响。当统计项进入限流状态后在指定时间内（默认20分钟）自动抛弃相应相应消息，当限流时间达到时间阈值后当前统计项自动恢复到正常状态。

支持高并发API查询

与OLAP/时序数据库之类技术方案不同，XL-LightHouse直接存储统计结果，在查询时直接通过key查询统计结果，不需要通过SQL计算。OLAP和时序数据库之类方案都是存储明细数据，每次查询时需要遍历明细数据，在没有预计算或没有触发索引的情况下容易造成比较高的查询延迟，相比之下XL-LightHouse查询效率更高，可以满足大批量、高并发的查询场景。

对高基数问题的容忍度更强

高基数是影响分布式计算和存储服务的主要问题之一，下面以时序数据库为例阐述高基数的影响。

1、什么是高基数问题？

在分布式计算和存储领域，高基数问题指的是数据集中某个字段或索引值具有极大量的唯一值，导致数据处理和存储变得困难。比如基于userId，itemId,uuid等类似字段进行聚合计算或存储时就容易产生高基数问题。不同的计算和存储组件由于内部机制不同，高基数的影响方面和影响程度也各不相同。

一般来说有如下几种：

• 存储开销巨大：对于高基数字段，索引结构（如 B+ 树、倒排索引、哈希索引）需要存储大量的唯一值，占用大量的内存资源，而包含高基数的明细数据维护也会占用大量的磁盘空间；
• 索引的构建和更新成本增高：高基数字段被用于索引，插入或更新操作可能会导致频繁的索引重建，影响写入性能；
• 数据倾斜和Shuffle问题：在分布式计算框架（如Spark、Flink）中，数据通常会根据某些字段进行分区聚合，如果字段基数过高，某些分区会特别大，而其他分区很小，导致任务负载不均衡,某些计算节点的负载远高于其他节点，影响整体性能，并且大量key的Shuffle过程可能造成严重的io阻塞；
• 查询性能下降：高基数会导致索引放大（比如B+树索引会使得索引层级加深，倒排索引会使得标签数量急剧增加）而影响查询效率；

2、时序数据库的数据组织方式

时序数据库是专门为高效存储和查询时间序列数据而设计的数据库，在时序数据库中每条记录由三个部分组成：标签、时间戳和值。为了优化存储和查询性能，时序数据库一般采用列式存储、数值压缩、时间分片和索引等技术。

时序数据库主要包含三种索引结构：

• 时间索引

在时间分片的基础上，为每个分片建立时间索引，通过时间戳能够快速定位到目标时间范围内的数据，避免全表扫描。

• 字段索引

字段索引是对常用字段（如指标值等）进行索引，方便通过这些字段快速检索数据（比如：amount < 100）。常见的实现方式包括B+树和LSM树。字段索引可以显著提升基于单一字段的过滤查询性能，特别是在大规模数据集下，字段索引能有效减少不必要的数据扫描。

• 倒排索引

倒排索引主要用于支持标签（tags）查询，每个标签值（如cluster=A, node=1）会在倒排索引中有一个对应的索引条目，记录包含该标签值的所有时间序列的ID列表。倒排索引通过为每个标签值建立倒排列表，使得数据库可以快速查找所有包含特定标签值的时间序列，倒排索引是处理多维查询和复杂查询时的关键。

3、时序数据库查询逻辑

• 定位时间序列：时序数据库中每个tags组合对应一个时间序列，数据库根据查询条件（如 cluster=clusterA和node=node1）通过倒排索引定位到与查询条件匹配的时间序列ID列表；
• 定位时间分片：根据时间范围（如查询最近一天的数据），通过时间索引定位到对应的时间分片；
• 数据序列合并：如果查询条件匹配到多个时间序列，数据库会按照时间戳对齐的方式将多个时间序列合并到一起；
• 数值聚合计算：对合并后的数据进行聚合、排序、合并等计算，并将合并后的结果返回给用户；

在计算流程中主要有几种优化方案：

• 预计算（预聚合）

在数据写入时预先计算聚合值（如 SUM、MAX等），减少查询时的计算量。 例如，预先计算每个时间分片的SUM值，查询时只需加载预计算结果，而不需要重复计算。

• 流式处理

采用流式处理的方式，逐块加载数据并进行合并，避免一次性加载所有时间序列的数据。

• 并行计算

按照时间分片、时间序列将计算任务拆分成多个子任务，并将子任务分配到多个节点或线程上并行执行，提高查询性能。

4、高基数对时序数据库的影响

对于时序数据库来说，高基数除了增加元数据存储开销之外，还会带来更为严重的索引放大问题。在时序数据库中不同标签（Tag）的任意组合都对应一个时间序列，高基数是指数据集中某个标签具有大量不同的唯一值，导致时间序列（Time Series）的数量剧增。

这会产生以下问题：

• 索引放大：倒排索引通常存储在内存中，以加速查询，高基数会导致索引体积急剧膨胀，占用大量内存，同时管理大量索引条目的创建、更新和删除操作变得更加复杂；
• 查询性能下降：查询涉及高基数标签时，数据库需要扫描大量索引条目，同时聚合计算涉及多个独立时间序列的数据合并，对CPU和内存消耗巨大并且导致查询延迟增加；
• 写入性能下降：每次写入新数据时，数据库需要更新倒排索引，高基数会导致频繁索引更新，增加写入延迟；
• 影响压缩效率：时序数据库的压缩通常是针对单个时间序列内的数据进行，包括时间戳和值的压缩，压缩算法通常对较大的数据块更有效，而高基数导致数据被分散到大量小时间序列中，从而降低了压缩效率；

5、高基数对XL-LightHouse的影响

XL-LightHouse是流式统计运算系统，只存储KV格式的统计结果，不存储明细数据。OLAP引擎和时序数据库都是在已保存的明细数据基础上进行运算，它们会完整存储明细数据，而XL-LightHouse是流式统计系统，是在接收到消息后按照预先配置的规则计算并将结果保存下来。举一个例子，如果要用OLAP和时序数据计算pv,uv，它们需要将日志保存下来后，在查询时再进行聚合计算，而XL-Lighthouse是在接收到日志时实时计算结果并保存到数据库。统计结果在使用时只需要通过get方式查询，不需要再进行类似sum、count等聚合运算，也没有其他基于时间范围的查询逻辑，所以没有必要再为维度字段创建索引，对于XL-LightHouse来说高基数会导致结果存储开销的增加，但这种KV存储机制比较简单，所以XL-LightHouse相对于时序数据库之类方案对高基数问题的容忍度更强，这种机制也更适合处理大批量数据指标的并行计算和结果存储。

同时支持单机与集群模式

XL-LightHouse包含单机版本和大数据集群版本，面向不同体量的企业提供与之匹配的技术方案。

1、集群模式

集群模式可作为大中型企业的基础计算服务使用，集群模式的优势：

• 可以提供超大规模数据集的实时运算能力和支撑高并发的数据查询能力；
• 可以方便的进行集群的扩容和缩容；
• 可以满足大量用户同时使用；
• 可以为企业内部的其他系统提供数据统计接入服务；
• 集群模式可在企业内部共用，减少运维成本，并且便于加强企业内部数据指标的共享；

2、单机模式

单机模式成本低廉，最低配置只需要一台4核8G的云服务器，适用场景：

• 面向中小企业或中小型业务团队使用；
• 面向"用完即弃"的使用场景； 有些时候对数据指标的需求，往往只在某个特定的阶段。比如：新接口上线要进行接口性能优化；线上业务出现数据异常问题需要排查；数据库读写压力突然暴涨，需要确定异常请求的来源等等，对于此类问题排查，流式统计可以起到至关重要的作用。但问题排查一般不需要持续很长时间，可能一两周甚至两三天，这种情况可使用单机版，一键部署，轻量级使用，问题排查完将XL-LightHouse删除即可。
• 用于初步体验XL-LightHouse或作为二次开发的联调测试环境；

支持数据导出与导入

具有高效的数据导出和导入功能，基于数据导出功能可以定时完整备份统计结果数据和集群所有配置类数据，通过导入功能可将备份数据迁移到新集群，保护业务数据的安全性。

数据有效期设置

系统支持单元格级的细粒度ttl设置，每个统计任务可根据需要灵活设置数据有效期。

"零优化"原则和"零运维"原则

很多产品不能快速普及一个重要原因是使用门槛太高，该领域其他技术工具大多是面向专业的大数据研发维护人员，比如：Spark/Flink需要研发人员熟悉其计算特性和各类API，OLAP引擎需要使用者对其数据存储原理有清晰的理解，而时序数据库也需要对其承载的数据量，预计算策略、索引机制等具备足够的经验才能驾驭，数据仓库/数据湖更是只适用于大中型企业，很少有真正开箱即用的产品。

但XL-LightHouse不同，它期望帮助各类企业搭建遍布全身的数据化运营体系，期望将通用型流式数据统计技术应用到企业运转每一个细微的角落。所以不管是运维部署、Web端操作、数据接入等各方面都充分考虑易用性，尽可能降低使用门槛。在指标管理和查看方面它面向企业自上而下所有人员使用，在系统运维方面只要具备基础的linux经验就可以维护xl-lighthouse集群，普通工程人员即可驾驭，并且开发者免费提供技术支持。

为了实现"零优化"和"零运维"的目标，XL-LightHouse采取了很多技术层面的设计。

• 不需要使用者像Spark/Flink那样开发相应的计算任务，基于简单明了的xl-formula创建指标即可；
• 不需要使用者进行任何定制化优化；
• 运行时不产生任何Shuffle、数据倾斜等情况，完全规避分布式领域最常见的故障根源；
• 整个集群只有一个计算任务，不会产生资源竞争等情况；
• 只存储统计结果，不存储明细数据，降低集群规模，减少维护成本；
• 内部虽然有很多复杂组件，但xl-lighthouse都完全做了完善的封装，对使用者来说内部细节是完全隐藏的；

通用型流式数据统计对行业的影响

数据指标对于社会运转、企业生产的价值是毋庸置疑的，目前行业内普遍使用各类实时计算、离线计算、OLAP、关系数据库、时序数据库、数仓/数据湖等较为"昂贵"的技术方案，而通用型流式大数据统计技术将会完全改变这一局面。未来的数据化运营技术方案将会以通用型流式大数据统计为主，以其他方案为辅的技术选型。更通俗点来说是：能用通用型流式大数据统计实现的数据指标就用通用型流式大数据统计来实现，实现不了的才会用其他技术方案实现。

从软件运行和数据存储模式的角度来看，云厂商的软件运行有两种模式：第一种是单租户模式，由一个或少量用户占有某个服务的运行和存储资源，所有用户之间基本处于资源隔离的状态，资源隔离的形式分为多种，比如运行资源隔离、数据资源隔离，而数据资源隔离又包括实例隔离、表隔离等，常见的有Mysql服务，Redis服务、Clickhouse服务、HBase服务、Kafka服务、Prometheus服务。第二种是多租户模式，所有用户共同占有某个服务的运行资源，比如常见的短信服务、对象存储服务、图片存储服务等。

很显然第二种模式的资源利用率更高，使用成本更低，目前数据化运营其他技术方案都属于第一种运行模式，而唯独XL-LightHouse属于第二种模式，它可以轻松的承载上百万个数据指标，未来云服务厂商一个集群可以支撑上亿个数据指标并行计算，可以同时满足庞大数量的企业和用户共同使用。

而这种转变对于行业来说意味着什么？我认为有两点：

• 数据指标将从此迈入"极低获取成本"的时代；
• 未来企业的数据化运营体系会像我们人体的神经系统一样遍布全身，涉及企业生产各个细微环节；

数据化运营的"分层治理"思想

1、什么是分层治理？

"分层治理"是计算机领域常见的设计思想，它的核心目标是通过将系统划分为不同的层次，每一层专注于解决特定问题，从而提高系统性能、可扩展性和可维护性。

2、有哪些常见的分层治理方案？

常见的分层治理方案有：

• 数据存储分层（冷数据、温数据、热数据）
• 多级缓存分层（内存缓存、分布式缓存、数据库）
• 业务架构分层（前端表示层、后端业务逻辑层、数据存储层）
• 数据治理分层（采集层、处理层、存储层、服务层、应用层）

3、数据化运营"分层治理"是什么，有哪些作用？

数据化运营分层治理是指将通用型流式大数据统计服务作为其他技术方案的前置环节，这种设计方案的好处在于：

• 保护后端存储服务

不同企业、不同业务场景所使用的存储服务可能不同，可以选择关系数据库、OLAP或者时序数据库。由于数据库自身是较为核心、又相对薄弱的环节，出现故障的风险高、故障恢复困难，出现故障后可能影响生产服务访问或者造成数据丢失等无法挽回的恶劣影响。将过多查询和计算压力交给数据库承担不是明智的选择，而此时通用型流式大数据统计服务可以极大的分担存储引擎的压力，保障存储服务的稳定性。

• 减少存储服务集群规模

对于存储服务来说，维护的数据量越大、承担的查询和计算压力越大，集群规模也必然越大。而集群规模越大出现风险的概率和维护成本也就越高，如果将大部分的指标计算和查询压力交给通用型流式统计服务 承担，可以减少很多不必要的索引数据、预计算类数据的维护，大幅度缩减存储服务的集群规模。

• 可以影响存储方案的技术选型

不同存储方案维护成本有很大差异，比如hdfs/s3/数据湖等方案的存储成本相比于时序数据库和OLAP引擎要小得多（hdfs之类方案不需要建立很多索引，也不需要占用太多内存资源），但是时效性较差。很多时候为了满足个别指标的时效性要求，而选择实时性更强的存储方案，这就增加了存储成本。而如果引入通用型流式数据统计，可以将时效性高的数据指标由通用型流式统计服务来实现，这种情况下存储服务就可以选择成本更低廉的方案。

• 减少研发成本

通用型流式统计服务的使用门槛极低、使用便捷、计算性能强大、维护成本低，可以减少很多不必要的计算任务的研发成本。

• 支持高并发查询场景

相比于时序数据库、OLAP、数据湖等方案，通用型流式统计服务可以支撑高并发的查询场景；

• 提供统一的监控告警、指标可视化方案对于业务方来说使用更为便捷。

与大中型企业自建的数据平台的关系

目前大中型互联网企业的指标平台大都是寄生在数据平台之上的，但我个人并不太认同这种方案。

首先思考一个问题：要实现一个数据指标，在不考虑时效性的情况下，使用Spark/Flink、OLAP、离线计算等方式，哪一种成本最低？

其实这个问题并不一定哪种方案成本一定低，Spark/Flink任务运行资源占用比较大，需要长时间运行，也需要统计结果的存储成本；OLAP的成本主要在于集群规模和接入维护成本；离线计算的成本在于数据写入任务、离线存储、定时调度的统计任务的成本。

但是通用型流式数据统计技术的出现会完全改变这种情况。只要通用型流式数据统计能够实现的数据指标，它的成本绝大多数情况下要远远小于上面几种方案。

• 它的计算过程不依赖明细数据的存储，它只存储统计结果，而且也没有OLAP、时序数据库复杂的索引机制、预计算逻辑，它整体的集群维护成本非常低；
• 它一个任务可以并行支撑大批量指标，可以充分发挥规模优势；
• 它有一体化的监控告警、指标可视化功能；
• 它能轻松实现大量数据指标快速上下线，从容应对指标需求的指数级增长；
• 接入简单，普通工程人员即可驾驭，使用门槛低；

很多企业开发的数据平台并不足够完善，由于开发人员的主观原因或者历史债务等原因，导致各种数据指标被分散存储在多种存储服务中，造成数据指标彼此孤立，而如果使用通用型流式数据统计，它本身可以应对互联网、物联网类企业大部分的数据指标并且也可以存储其他服务输出的统计结果，它提供标准化的数据指标管理、可视化和告警机制便于在企业内部的共享。

此外，企业的数据平台更多是面向大数据研发和维护人员，相对来说通用型流式数据统计更能够面向各种职能人员（比如：前端、后端、算法、数据、产品、销售、运营、客服...），更容易建立全面的指标体系。

数据指标共享体系的商业价值

数据已成为推动经济增长和社会进步的核心要素，被誉为数字时代的“新石油”。但数据真正的价值在于共享，而非孤立存储，数据指标共享体系可以为企业和政府提供决策支持，优化资源配置，打破行业壁垒，更充分的释放数据的商业潜力。

数据指标共享体系是什么：

• 把现实世界、网络世界每一个角落所有有价值的指标型数据以统一标准收集起来；
• 在符合法律和数据提供方意愿的前提下，将有共享价值的数据分享出来；
• 将无形的数据指标转变为标准化商品，并提供数据指标的交易和安全保障机制；
• 提供标准化的指标可视化、接口查询、离线下载、监控告警和指标订阅等功能；
• 建立数据遴选机制，区分出其中的高价值数据、低价值数据和错误数据，保障数据的准确性和可靠性；
• 通过不断软硬件迭代和数据规模优势不断降低数据指标的采集、存储、维护成本，既让数据发挥社会价值又能为数据提供方创造可观的收益；

未来的商业活动会越来越像一个数学游戏，不管是宏大的城市治理、社会运转还是微观的企业生产、个人生活都与这个庞大的数据指标共享体系脱离不了关系。如果说过去的商业活动主要依靠的是“经验”，那以后更多依靠的是“数据”，每个人的认知都有很大的局限性，过往的经验也会过时，商业竞争越是充分，过去奉为圭臬的经验却反而成了枷锁。

数据指标共享体系的作用：

1、提升决策效率

企业和个人可以通过数据指标共享体系获取跨行业的实时数据，更准确地预测市场趋势、优化运营策略。

例如：

• 交通数据共享：一个城市的交通部门共享每条道路的车流量、人流量和拥堵数据，物流企业通过购买这些数据，可以有针对性地制定运输路线，降低运输成本；地图导航企业可以利用这些数据为用户提供实时路况信息，优化出行体验；快餐店老板可以通过分析道路的人流量数据，选择最佳的新店地址。
• 水利数据共享：水利部门共享河流、河段的水质、水温和水草含量数据，生鲜养殖企业通过这些数据可以判断更适合饲养的鱼类品种，提高养殖效率。
• 建筑数据共享：建筑部门可以实时掌握辖区所有楼宇的“体检”数据（如结构健康、承压数据、能耗等），及时发现潜在问题，确保建筑安全。
• 农业数据共享：农民可以足不出户获取农田的长势、虫害、土壤湿度和气象数据，制定灌溉和施肥计划，提高农作物产量。

2、提升数据变现能力，形成新的商业模式

数据指标共享体系可以催生新的商业模式，如数据交易、数据订阅服务，企业在符合法律规定的前提下可通过出售自身数据资源获取收益。

例如：

• 电商企业可以共享每个品类各价格区间在售商品数量、订单量、平均订单金额、退货率，而一个服装工厂或者一个服装门店通过该数据在竞争激烈的服装类目下依然可以找到相对蓝海的小众爆款；
• 交通保险公司可利用共享的各城市交通事故数据，可以优化保费定价，提高用户体验；

3、推动跨行业协同创新

数据指标共享体系可以打破行业边界，促进不同领域的企业合作，推动新技术、新模式创新。

例如：

• 智慧城市项目通过整合交通、能源、人口流动数据，优化公共交通规划，减少城市拥堵，提高居民出行体验；
• 农业创新企业可以基于土壤、气象和农作物生长数据，开发智能农业解决方案，如精准灌溉系统和病虫害预警系统；
• 智能科技类企业可以研发更便捷高效的一键社会救援类系统（110/120/119）；

为数据买单是未来商业的常态

说到数据指标共享，大家总是会想到一些特别宏大的场景，比如交通、农业、水利等，但其实数据共享体系即会涉及宏大的社会运转又会涉及微观的企业生产和个人生活。

数据指标是数字现代的新型商品，我们每个人都是潜在的消费者。消费者是否愿意购买某个商品，取决于两点：商品对于自己的价值和购买成本。以通用型流式大数据统计技术为基础的指标共享体系可以大幅度降低数据指标的获取成本，让数据指标成为一种极为廉价又极具有性价比的商品，未来不管是企业还是个人，购买数据就如同充话费、充流量一样稀疏平常，我们会习惯于“为数据买单”。

示例1：假如某企业研发了一种室内检测设备，同时具有检测甲醛含量、烟雾含量、各有害物质含量、PM2.5、天然气泄露、温度、湿度、CO₂浓度、噪声污染、电磁辐射等功能，各类数据实时上报到云端提供给用户查看并有异常报警功能。刨除硬件成本，如果数据的使用成本是每月100块钱，那可能只有少数人会购买该数据，如果每月使用成本是10块钱，那城市的中产阶层或许会购买该数据，如果每月使用成本不到1块钱，那这份数据可能成为绝大多数家庭的标配。

示例2：一个购房者要购买价值100万的房产，如果数据服务商可以向他提供意向房源相关的各类数据指标，包括：房龄；整栋房屋是否发生过火灾、地震；所属楼宇的"健康指标"；所在小区以及周边小区历年房价走势图；租房价格走势图；片区一居室、两居室、三居室各种户型房屋的供给量；二手房的带看量、平均转手周期；当前房源每月的光照时长；周边各主要街道人流量、车流量、拥堵指数；周边各个停车位的停车价格；小区的入住率；周边办公区域各行业公司的数量、在职人员规模、招聘岗位数量、平均薪资水平；片区的物价指数甚至周边餐饮店、超市的数量、外卖平均金额等等。购房者是否愿意为数据买单呢？如果这份数据报告收费1000块钱，大部分消费者会望而却步，如果这份数据报告收费是100块钱，可能会有一部分人选择购买，如果这份报告只要10块钱，那可能购买相关数据指标会成为买房的常规流程。

数据指标共享体系的作用是跨行业将各个具有共享价值的数据指标汇总到一起，以规模优势充分降低数据的采集、计算、存储、维护和使用成本，再将这些数据指标包装成商品销售给消费者。过去看似微利、甚至赔本的生意或许摇身一变会成为一个“暴利行业”，而很多看似没有太多价值的数据或许会因为成本的骤降而得到最广泛的使用。

一吨矿泉水的净利润可能超过一吨钢，矿泉水一块钱一瓶，而一块钱的数据通过不断的软硬件迭代，极致的压缩成本会有多少利润呢，我认为数据销售商或许会是未来利润率最高的行业之一。

数据指标共享体系将整个商业活动更为透明，辅助决策者思考，它发展到一定阶段后会对现有的商业模式和人们生活产生深远影响，不管是买家电、买家具、购买房产、租房、做装修、买保险、买汽车、买理财、买股票、搞投资、就业、择业、创业...，数据指标共享体系都会影响到个人生活的方方面面。

消费者购买某个商品可能是因为厂家无处不在的营销广告，电商网站上的精美的文字和图片，直播平台上主播口若悬河的宣传和精心打造的人设，但这些都是营销者刻意给消费者制造的一种"感觉"，依托于感觉的消费更像是一种感性思维，而依托于数据的消费模式更接近理性思维，感性思维永远都不会消失，但我也认为理性思维也将会在未来消费决策中发挥越来越大的作用。

如何建立数据指标共享体系

XL-LightHouse项目本身不包含数据指标共享和数据共享方面的功能，以下内容是指一种基于XL-LightHouse衍生出数据指标共享体系的实现方式。

数据指标共享体系并不是一个比较新的概念，甚至是有些老套的技术名词，近年来不少企业和机构在这个领域进行各种商业化尝试，但似乎没有取得明显的成效。

比如：

• 数据指标交易平台所覆盖的指标数量、丰富度、数据规模较为有限；
• 即便对于各领域巨无霸类的平台企业（比如：房产、招聘、外卖、社交、电商、旅游）这些平台占据流量入口，拥有强大的技术研发能力，同时也掌握各领域的优质数据，但即便如此自身的数据变现能力依然较为羸弱；
• 数字化时代几乎所有的商业活动都需要数据指标支撑，不管是企业生产还是个人生活，为数据指标买单是常规流程，但目前现状距离这种状态仍有不小的差距；

出现这种情况的原因有很多，而技术选型是其中核心因素之一。技术选型决定了数据指标共享体系的建设和接入成本，也影响着数据指标的采集、计算、存储、维护和使用成本。数据指标首先是一种商品，成本越高性价比就越低，要建立大范围的富有实用价值的共享体系，成本的高低发挥着决定性作用。

下面谈一谈数据指标共享体系应该如何建立。

常规方案1

有些朋友会觉得这还不简单，只要平台定义一套数据存储标准，然后对外提供统一数据接入和查询API，让提供方将数据同步过来，再共享给用户这不就行了？

大概类似下面的结构：

这种架构主要包含两种角色：

• 数据提供方：负责将具有共享价值的数据指标按照约定标准同步到交易平台；
• 数据交易平台：负责制定数据存储标准；对外提供统一的数据同步API和查询服务；负责存储和维护数据；提供数据交易机制和安全保障机制；

其实这个问题要比想象中复杂很多，要建立覆盖社会运转、企业生产、人们日常生活如此庞大范围的数据指标共享体系，这种方案是明显不能满足的。

该方案的优点：

• 系统结构较为简单，相对容易实现；

该方案的缺点：

• 数据提供方自身的技术选型、指标存储方案千差万别，让他们遵循第三方标准同步数据，需要耗费大量的同步任务研发和维护成本并且数据同步过程中容易出错；
• 对于数据交易平台来说，自身需要维护庞大量级的数据，有高昂的数据维护成本；
• 数据同步到交易平台后就完全脱离了数据提供方自己的控制，存在很大的数据泄露风险；
• 很多数据指标有很强的实时性，采用数据同步这类方案不能满足有较高时效性的应用场景；
• 数据提供方对于“已同步”的数据，如果进行后续操作，比如修改、删除、下线等较为不便；
• 数据交易平台自身设计的数据同步标准、API查询方式难以成为业内统一标准；

这就好比要建立一个大型电商平台，有很多的第三方商户入驻，如果将所有商品都汇总到电商平台自己的仓库进行存储是不现实的。这类技术方案存在明显瓶颈，只能满足较小范围内的数据指标共享。

常规方案2

方案1里面将数据同步到数据共享平台这种方式是不可取的，如果是下面的架构设计是否更好？

这种方案的特点：

• 数据仍有提供方自己维护；
• 提供方将库表结构共享给数据交易平台；
• 用户在数据交易平台通过SQL的方式查询数据；

这种方案的优点：

• 数据仍有提供方自己维护，所以不需要方案1中的数据同步任务等相关功能的开发，并且数据泄露风险相对于方案1要小；
• 数据时效性取决于数据提供方所选择的存储和设计方案，相对于方案1来说时效性更强；
• 数据提供方对已共享的库表进行后续操作（如修改、删除、下线）相对于方案1更方便；

这种方案的缺点：

• 成本太高

能够支撑这种架构的技术方案无外乎关系型数据库、OLAP、HTAP、时序数据库、数仓/数据湖等。在指标共享场景用户大多数时候需要的是"指标"而非明细数据，比如用户查看道路的车流量，是关注的车流量而非每个车辆的通行记录。用户需要获取某个商品类目的成交额，大多数情况并不需要订单明细，数据提供方对外提供"明细"数据，需要很大的数据存储和维护成本。而如果将计算后的统计结果存入到OLAP或者时序数据库中也会存在很多问题，一是这类引擎主要提供时间范围的聚合计算，但按key查询的效率比较低，同时指标计算需要额外的服务实现。

• 使用门槛高

基于SQL查询更多是面向有一定技术能力的人员使用，这也增加了使用者的技术门槛，并且使用者需要对数据提供方的库表结构、字段含义、数据格式、数据量甚至是一些业务逻辑都较为熟悉的情况下才能使用，这对于使用者来说是不够友好的；

• 不能实现便捷的可视化查询功能

这种方案如果想规避SQL查询方式，但并不容易实现便捷的可视化查询。可视化查询需要将用户的筛选条件组合成完整SQL语句，这需要预先设置维度（筛选字段）和时间范围、筛选指标、过滤参数、计算方式等信息，每个数据指标的接入几乎都需要数据提供方完成大量的准备工作。

• 并发查询能力有限

SQL查询方式性能可能较差，难以支持高并发查询，尤其是在没有命中索引和预计算逻辑的情况下，而且有些慢SQL可能会影响数据提供方自身存储服务的稳定性；

• 数据长期存储能力有限

这种方案由于需要维护大量的数据（比如：明细数据、索引数据、预计算数据等），存储成本是比较高的，很多场景只能通过缩减数据存储周期来减少成本，这也意味着长期数据存储能力有限；

• SQL标准并不完全统一

SQL虽然是大数据领域的主流标准，但不同的存储引擎往往有各自的扩展语法，而这些扩展语法在标准SQL中不存在或者效率比较低，而要求所有数据提供方使用统一的存储引擎并不现实；

• 提供数据监控告警、数据订阅服务的能力有限

针对于每个数据指标能否提供监控告警、数据订阅等服务取决于所采用的存储方案，而这种基于SQL的存储方案有很多种，但并不是每种存储引擎都能支持此类功能；

• 权限粒度控制较差

将库表提供给使用方，对于数据的权限的控制粒度太宽泛，很多明细数据的字段属于隐私、敏感字段，这会导致一定的数据泄露风险；

这种技术方案类似企业内部的数仓/数据湖之类方案，但这种方案成本过于高昂，使用笨拙，只能满足较小范围内的数据指标共享，如果基于此类方案实现庞大范围，千亿甚至万亿数量级的数据指标共享体系是没有可能的。

更为理想的架构设计方案

技术方案成本足够低才能让更多数据指标接入到这个体系中来，而数据指标作为一种商品它自身的性价比才会更高，只有使用门槛足够低才能让更多的用户成为这个体系的消费者，为数据买单才能成为企业生产和人们日常生活的常态。

我认为以目前行业的计算技术和存储技术的发展现状来看，能够以极低成本支撑千亿数量级指标共享体系只有一种技术方案那就是通用型流式数据统计。

这种架构包含三个组成部分：

1、数据中心

• 数据中心基于通用型流式数据统计服务实现（比如：xl-lighthouse），遵循统一的指标存储、指标可视化（提供统一格式的统计结果数据、维度筛选数据等）、指标查询API、监控告警、指标订阅和指标共享标准；
• 数据中心由数据提供方维护，拥有唯一标识，它的作用是负责接入、存储、管理和维护数据指标；
• 数据共享体系可以包含任意数量的数据提供方，每个数据提供方可拥有一个或多个数据中心；
• 数据中心负责响应聚合服务的数据查询请求并返回数据，包括维度筛选初始化数据和统计结果数据；
• 数据中心向聚合服务上报数据指标的目录结构信息（包括：统计组元数据信息、统计指标配置信息、统计周期、数据有效期、描述信息等）；

2、聚合服务

• 聚合服务由数据提供方维护，每个数据提供方可拥有一个或多个数据中心，而聚合服务的作用即管理多个数据中心，监控各数据中心的运行状态、并负责与外部数据交易平台的数据传输和请求转发；
• 每个聚合服务拥有唯一标识，用于区分不同的数据提供方，数据共享体系包含若干个数据交易平台，每个聚合服务都可同时注册到一个或多个交易平台；
• 聚合服务汇总每个数据中心的数据指标，数据提供方根据自身需要选择要共享的指标上报给交易平台；
• 聚合服务定时上报各数据中心的运行状态和数据指标的共享状态到交易平台；
• 聚合服务含有指标路由功能，可根据交易平台的查询请求指向到相应的数据中心并返回数据给交易平台；
• 聚合服务负责设置数据指标的销售价格以及核验查询请求的授权状态；
• 数据提供方可以通过聚合服务上线、下线每一个数据指标；
• 聚合服务提供数据指标的访问日志、数据审计等功能，便于在出现数据泄露风险时的溯源排查；

3、数据交易平台

• 数据共享体系可以包含任意数量的数据交易平台，每个交易平台就像是一个电商平台一样，可入驻任意个数据指标提供方，交易平台只展示指标目录，不需要存储具体指标数据；
• 数据交易平台向用户提供指标的目录分类、指标筛选、交易机制、安全保障机制；
• 数据交易平台提供指标的遴选机制，区分高价值数据、低价值数据和错误数据，保障指标的准确性和可靠性；
• 数据交易平台可以接入无限数量的聚合服务，与聚合服务之间的通讯遵循统一的数据传输协议，就像企业使用的git仓库一样；
• 用户可在交易平台通过页面或接口查询数据，交易平台自动调用相应聚合服务的查询接口；
• 用户可在交易平台配置监控告警策略、数据订阅策略，该配置信息被下发到相应的聚合服务，并由聚合服务下发给相应的数据中心；
• 数据交易平台可以向用户提供更多扩展类服务，如数据的聚合分析服务、数据报告类服务、数据指标引用服务（将数据指标以更为简便的方式嵌入到第三方服务中）等等；

为了便于理解，可以把上述模式理解成常见的电商交易模式，两者之间存在一些相似的地方。

在电商模式下：

• 一个电商平台可以入驻众多的第三方商户，每个商户也可以入驻到不同的电商平台；
• 商品由入驻商户管理和维护，每个商户都可以有一个或多个存放仓库，每个商户也可以同时销售众多品类的商品，各类商品存放在不同的仓库，商户通过客户端将商品信息提交给电商平台；
• 电商平台提供商品的交易机制、安全保障机制、商品的目录管理和筛选机制、商品信息展示、商品和商户的优质排名机制等；
• 消费者在电商平台下单，商户获得订单信息后，从相应仓库中获取商品并发货；

数据指标共享体系从角色分工的角度来看类似电商交易模式，不过数据指标是一种无形的特殊化商品，为了实现更大范围的共享，所以指标交易平台、聚合服务、数据中心之间的数据传输都基于统一的数据传输协议，这一点类似Git工具。

这种设计方案的好处在于：

• 无限容量，由于数据是存储在数据中心的，而数据中心可以是任意数量，所以理论上这种模式没有存储上限，不管是一千亿个数据指标还是更多数量都可以支撑；
• 数据提供方不需要将数据同步给第三方交易平台，可以最大程度保障数据安全性，避免数据泄露风险，同时保障数据产权清晰；
• 数据中心基于通用型流式统计服务实现（比如：xl-lighthouse），任何企业可以使用遵循统一标准的开源或商业软件搭建，就像使用git工具一样，对于数据提供方来说没有任何开发工作，并且同时支持单机版本和大数据版本，可以满足不同量级的企业使用，成本低廉、接入简单；
• 通用型流式统计服务善于应对大批量数据指标计算和存储场景，便于大批量数据指标快速接入；
• 可以满足时效性非常强的实时查询场景，同时可以满足高并发查询场景；
• 数据始终由数据提供方自己掌控，数据提供方可随时根据需要修改、删除、上线、下线各个数据指标；
• 通用型流式统计服务基于xl-formula规范，相比于SQL标准简洁高效，能够实现更为简便快捷的指标可视化、监控告警和指标订阅功能；
• 权限控制粒度是以数据指标为单元，并且可以根据日期和其他筛选条件灵活授权，相比于方案2的库表的方式更安全；
• 数据交易平台并不是整个流程的标准制定方，这个体系下可以由众多数据交易平台组成，有助于形成业内统一标准，不同的企业和机构可以根据自身需要搭建私有的数据交易平台，就像部署一个小范围内共享的git仓库一样；

数据指标共享体系最需要的什么？

数据指标共享最需要并不是一套单纯的规范、标准、数据传输协议或者一种方法论，其实它最需要的是一套"机制"，而所谓的机制是整条链路上各核心环节所有规范、标准、协议的总和。就像你会觉得Git是一个单纯的传输协议吗，这肯定不是，它是汇聚项目研发、存储、协同、共享的所有标准的总和，所以Git的核心是一种机制。一套单薄的标准无法支撑一套复杂的体系，而一种机制可以！ XL-LightHouse项目的理念就是期望对外提供这种机制。

数据确权和交易机制

什么是数据确权？

数据已成为一种重要资产，涉及商业交易、个人隐私保护、知识产权等多个领域，数据确权是数字时代的核心问题之一。它是指通过法律、协议和技术手段，明确数据产生、收集、处理和使用过程中各相关方对数据享有的权利边界及其法律属性的过程。数据权利包括数据持有权、加工使用权和产品经营权，数据确权的意义在于保护用户隐私和企业数据安全、确保数据的合法流通、解决数据纠纷、促进数据的市场化应用。

数据确权逐渐成为一个复杂且重要的议题，涉及法律、经济、伦理、技术等多个维度。数据作为一种无形资产，与传统资产（如土地、房屋等）不同，它不具备固定的形态，且能够被复制、传播和加工而不消耗原始资源，这使得数据的所有权界定变得复杂。现有的法律框架对数据交易监管不够完善，全球范围内也缺乏统一的数据确权框架，各国和地区的相关法规存在差异，数据跨境和跨地区流通存在合规障碍。此外数据常常通过多个主体的共享、加工、转换和融合进行使用，导致原始数据的所有者难以追溯，这也增加了数据确权的难度。

确权需要多方面的协同保障

1、法律法规

法律层面的作用主要在以下方面：

• 通过立法界定数据的产权归属（如：个人数据、企业数据和公共数据），明确数据主体（如用户、平台、政府）的权利边界；
• 制定数据交易规则，明确数据侵权行为的认定和执法标准；
• 明确数据共享体系所提供的数据登记凭证、交易凭证、使用授权协议等相关文件的法律效力；

2、使用协议

使用协议的作用是在法律框架下，具体约定数据的使用范围、使用期限、收益分配方式、保密要求、限制性条款以及赔偿机制等信息；

3、数据共享体系（技术层面）

技术层面的作用主要在以下方面：

• 建立完善的数据共享平台交易机制，交易流程中减少数据泄露风险；
• 提供数据登记凭证、数据交易凭证等必要的保护机制，为侵权纠纷提供法律证据；
• 通过数字水印、哈希校验、数字隐写、区块链等技术，确保数据来源可追溯，防止数据被篡改或盗用；

数据确权类问题就像人体会携带一些有害的细菌、病毒一样，虽然没有办法完全清除掉它们，但是可以控制在一定的程度之内，既让数据共享发挥其社会价值又同时充分降低数据泄露、数据侵权的风险。

区块链确权方式的不足

1、基于区块链技术的数据确权方式的缺点

• 存储成本高昂

区块链采用去中心化的存储方式，每个节点都有一份完整的账本副本，随着交易记录的增加，整个区块链的存储容量成倍增长，它的信息存储成本是远高于常规的数据库存储方式的，大范围交易信息存储成本巨大；

• 读写和检索计算效率低

区块链的共识机制（如PoW、PoS）限制了交易处理速度，在大规模数据共享和确权场景下，可能导致数据写入和访问效率低下，无法满足实时共享需求，它相对更适合高价值、低频交易的业务场景；此外由于区块链的链式结构，区块之间是顺序存储的，无法像传统数据库那样进行随机访问或基于索引查询，读取特定交易需要遍历整个区块链数据，随着链的增长查询时间成倍增加，导致数据检索变慢，区块链技术没有任何复杂查询的支持能力（如：聚合查询、多维查询等），在涉及大数据量计算或分析场景时存在明显不足；

• 扩展瓶颈

随着交易量不断增长，链的规模也会增加，新节点加入时需要下载所有历史数据，耗时较长，区块链的扩展存在明显瓶颈；

• 信息变更困难

区块链数据一旦写入就不可篡改，但在实际数据共享场景中，用户可能希望对部分信息进行变更，但区块链不可篡改特性与数据权属动态调整（如用户撤回授权、企业数据合并）互相矛盾，修改区块链信息较为复杂；

• 交易隐私问题

虽然区块链可以确保数据不可篡改，在区块链上所有交易信息都是公开的，但如果敏感数据（如：用户身份、交易金额等）直接上链，存在信息泄露风险；

2、更便捷实用的确权机制

区块链主要解决去中心化、防篡改、可追溯性的问题，虽然在防篡改、去中心化方面存在绝对优势，但区块链这一技术仍在发展过程中，目前的区块链更适合小范围、高价值、低频交易场景中使用，大规模的数据确权场景仍存在明显瓶颈。

而如果在大多数数据确权场景中使用"多端存证"（多端数据库 + 数字签名）服务，在少数高价值数据确权方面使用"多端存证 + 区块链"（多端数据库 + 数字签名 + 区块链）的确权机制较为适合。"多端存证"是指将凭证信息存储在由不同机构维护的多个服务中，虽然该方案无法绝对避免防篡改问题，但可以以较低的成本保持极高的安全性，在大规模的数据确权场景下更具有性价比。

自动化数据登记的重要性

1、法律层面数据登记的局限性

说到数据登记，大家会想到行政部门的数据产权登记，这种登记方式的优势不言而喻：可信度度，具有极高的法律效力；由专业人员对数据进行审查（实质审查/形式审查），确保数据质量和价值；便于对数据的监管和合规性审查；对数据进行存档，防止丢失风险。但是这种登记制度也存在一些不足：

• 成本高、效率低：需要专门的审查人员介入，流程繁琐，效率较低、成本较高、周期较长；
• 适用范围有限：一般来说只能面向大型企业或机构所提供的具有较高业务价值、数据变更频率低、数据量较小的业务场景；

2、自动化数据登记是重要补充

数据登记制度应该是法律层面和技术层面互相协同、互相补足的处理机制，自动化登记制度的优势在于：

• 适合实时、高频率产生的应用场景

互联网和物联网时代各类数据不断实时产生，比如电商的订单数据、物联网的采集数据、内容平台的发帖数据和评论数据、用户的行为数据以及在这些数据基础上加工、整合、统计、分析后生成的复合型数据，面对这些实时、高频产生的海量数据人工登记方式无法满足；

• 适合大范围、细粒度的业务场景

数据种类多种多样，企业为了防止有价值的业务数据丢失，预先登记是重要环节，而大规模、种类繁多的数据登记采用人工方式并不现实，而使用自动化登记技术，企业可以根据自身需要按照业务场景、日期、数据特点等多种方式灵活登记数据，提高了数据流通的便利性，此外这种方式同样适合中小企业；

更为理想的数据确权和交易机制的特点

1、数据共享体系各组件遵循统一标准化协议

数据共享体系是一个生态，而非仅仅是某个企业研发的一款商品。生态是指围绕某一核心技术、平台或标准形成的协作网络，包括开发者、工具、服务、社区、商业产品等多元角色，通过互补和协同推动整体发展。数据共享体系包括数据登记、共享、管理、交易、授权、交付、溯源等若干流程，而众多流程遵循统一协议，不同厂商研发的组件互相兼容，才能带动更多企业、机构和开发者加入到生态体系的建设中来。

本文倡导以通用型流式数据统计技术为切入点建立共享体系，该体系包含：数据中心、聚合服务、数据交易平台和存证服务几个核心组件，每个组件可分别由不同的企业或机构研发运营。在这套模式下每个聚合服务代表一个数据提供方，每个聚合服务可以接入多个数据交易平台，一个数据交易平台可以接入多个存证服务，每个存证服务也可以同时接入多个数据交易平台。

比如，聚合服务接入交易平台的注册逻辑如下：

• 数据提供方部署完成聚合服务，程序自动生成去中心化身份，包括：唯一标识、企业域名、所属主体，并选择自身的加密方式，生成公钥、私钥信息和数字签名机制等；
• 聚合服务接入交易平台，首先需要向其发起注册申请（即基于SSL/TLS证书、企业主体名称等信息完成合法性校验）；
• 交易平台根据提交信息进行审批，审批通过后向聚合服务返回相应的唯一注册令牌（Token）即注册完成；

2、"端到端"的交易模式

端到端交易模式是指在数据提供方（卖方）和数据需求方（买方）之间进行直接、安全、高效的数据交易，相比传统的中心化数据交易模式，数据提供方不需要将数据同步到任何第三方平台，交易平台只提供交易和安全保障机制，但并不需要关注"数据商品"本身，端到端交易模式避免了中间环节参与数据的分发和存储，使数据交易更加高效和安全。

3、实时、高并发、自动化的数据登记和交易支持能力

• 实时性

越来越多的数据具有显著时效性，特别是在金融、互联网、物联网等领域，实时登记可以确保数据在生成后较短时间内就被记录，降低数据被篡改和伪造的风险，并且可保障数据的“时效价值”，加快数据流通效率；

• 高并发

现代社会的数据量和数据种类急剧膨胀，数据共享平台需要具有高并发承载能力，这样才能保障大批量数据交易避免堵塞；

• 自动化

传统方式往往依赖人工输入、审批、记录，效率很低且容易出现数据丢失、错误等问题，而自动化可以显著降低人力成本，提高数据质量；

4、多端存证

数据在登记和交易过程中产生凭证信息，而凭证信息只存储在一方会有被篡改、删除或丢失的风险。多端存证是多平台、多角色、多技术的联合存证机制，将数据的权属、交易记录等关键信息同步存储到多个独立、互不信任的节点或系统中，通过多方交叉验证确保数据的不可篡改性和可追溯性。

在该共享体系下，存证服务遵循统一的数据传输协议，用于存储数据流通链路中所产生的凭证信息，覆盖数据登记、权属变更、交易记录、访问记录等各核心环节，形成更为完整的溯源体系。

• 每一份数据加入到共享体系，程序自动分配唯一标识（数据标号），由数据中心服务生成；
• 每一份数据按照生成日期、文件大小、指定维度字段（比如：省份、城市）等因素可拆分为不同的批次，系统自动为每一批次数据分配唯一标识（数据批号）和Hash指纹（用于唯一性校验）；
• 在数据流通环节，交易双方分别选择自己信赖的存证服务提供商，对于某些高价值数据交易可按照行政部门要求强制将交易信息同步到指定的存证服务，便于监管和合规性检查；

5、支持灵活的交易和确权形式

不同数据类型、行业需求、使用方式，对交易和确权机制的要求差异较大，构建多样的交易模式至关重要，比如：

• 按交易模式可分为：一次性买断、订阅制（按时间付费）、按量付费（按数据量或API查询次数等）、分成模式（按数据使用方获取收益的提成比例付费）；
• 按照数据交付形式可分为：实时类数据（指标数据）和文件类数据（离线生成的数据形式）；
• 按照数据的加工处理流程可分为：原始数据、衍生类数据（二次加工的数据，比如报表数据等）和复合型数据（多种数据源混合加工生成的数据）；
• 按数据授权使用范围可分为：仅限内部使用、可进行数据产品的加工和销售、可进行衍生产品的研发和销售；

6、高性能数据订阅和监控告警能力

对于数据使用场景，尤其是实时指标数据使用场景，数据订阅和监控告警是核心功能之一。数据订阅是指用户订阅其关注的某份数据，当数据发生更新和变化时及时通知给用户，便于用户获取最新内容，订阅可分为实时订阅（数据更新即发送通知）和周期性订阅（按照天、周等时间维度发送通知）等多种方式；监控告警是指用户针对某份数据设置自定义告警策略，当触发告警条件时及时通知用户。

在该共享体系下数据订阅和监控告警遵循统一的配置格式，数据订阅的执行逻辑如下：

• 用户在交易平台配置数据订阅策略（包含数据唯一标识、筛选条件、通知频率等信息）；
• 交易平台将订阅策略下发到相应的聚合服务；
• 聚合服务将订阅策略继续下发到数据中心；
• 数据中心加载订阅策略，当订阅条件被触发时，向聚合服务发送通知；
• 聚合服务将通知发送到交易平台，再由交易平台同步给用户；

XL-Formula比SQL规范更强大

SQL在指标计算方面能否强者恒强

我认为不会，SQL规范在关系数据库、OLAP、离线数据处理分析等领域的地位是无可撼动的，目前大数据生态也大多以SQL为核心标准。虽然SQL在存量数据指标计算方面的能力无法被替代，但是伴随着企业数据化运营理念逐渐深入以及物联网、产业互联网、AI智能制造的发展，基于增量数据指标计算需求呈现指数增长，流式计算方案占比快速膨胀而成为主流，但在这些方面SQL并不擅长，SQL在基于增量数据的指标计算场景内存在感必然越来越弱。

SQL执行过程

SQL执行过程分为解析、优化、执行和返回结果几个环节，逻辑如下：

• 解析SQL语句，将语句拆分为多种词法单元，比如：SELECT、FROM、GROUP、WHERE、表名、列名等；
• 根据语法规则，检查语句并生成抽象语法树（AST）；
• 优化器依据表结构统计信息、数据分布、索引分布、字段类型等因素分别进行逻辑优化（谓词下推、子查询优化、列裁剪等）和物理优化（分区优化、索引选择、缓存优化等），从而对语法树进行各种变换，生成最佳的执行计划，以减少磁盘IO和CPU计算成本；
• 从磁盘或内存读取数据依据索引或全表扫描定位到指定数据，将执行计划拆解成多个可执行的子任务（子任务类型一般分为：Scan任务、Filter任务、Join任务、Aggregate任务、Sort任务等）；
• 在分布式环境中调度计算资源（CPU、内存、磁盘I/O），将子任务分配到不同节点并行执行；
• 在每个分区内进行结果局部聚合，通过Shuffle汇总多个分区结果再进行全局聚合得到最终结果；

SQL规范的优点和缺点

优点：

• SQL支持各种复杂的数据操作，在计算方面的表述能力非常强大；
• SQL生态健全，具有较高的可移植性；

缺点：

• SQL的并行处理能力弱，不同的SQL任务并行执行会抢占资源、互相影响；
• 更侧重处理批量数据（存量数据场景），在实时处理方面性能较弱；
• SQL在大规模数据查询分析可能会遇到瓶颈，尤其是在没有索引、预分区或者预计算的情况下，数据返回比较慢；
• SQL的执行过程会触发大量Shuffle，可能导致I/O阻塞，严重影响集群稳定性；
• SQL的分组、聚合函数等功能都会导致数据倾斜，甚至内存溢出；
• SQL的语法过于臃肿复杂，实现相同的功能可能有多种写法，不同写法的执行性能各有差异；
• SQL任务需要依据数据量、数据特点、计算逻辑进行特定优化，接入成本较高，不善于应对大批量的业务场景；
• 不同的存储引擎依据自身特性会基于SQL规范进行定制化扩展，但这些扩展语法并不通用；

数据化运营最需要什么样的标准？

数据指标在社会运转、企业生产和人们日常生活等诸多方面能够产生重要影响，也将迎来井喷式增长，在广泛的业务需求背景下，数据指标应该从过于宽泛的数据处理分析场景中抽离出来，作为一类垂直细分领域并为之提供更适配的解决方案。

我认为在这个细分领域更需要的是一套机制而非一个孤立的标准，SQL规范虽然支持各种复杂的数据处理操作，但它的功能只局限在数据查询和计算方面，而能够发挥最大价值的标准，应该涵盖：指标计算、存储、管理、可视化、监控告警和指标共享所有环节，但是SQL规范在这些方面并无优势。

企业数据平台调度执行SQL任务，但任务的执行细节对于平台来说几乎是一种"黑盒"状态，平台并没有办法准确获取每个SQL指标的运算类型、维度信息、时间窗口；更没有办法预知SQL执行过程的Shuffle数据量，数据倾斜程度，所需要的内存量，一条拙劣的SQL语句能够拖垮一个集群；而对于OLAP、时序数据库、数仓/数据湖，SQL任务必须依赖明细数据的存储，这些局限性使得SQL在很多时候并不是一个高性价比方案。而XL-Formula标准更为简洁明了，易于使用、善于应对大批量数据指标，使用成本低廉，对于数据指标平台来说，每个任务都是完全可控、透明的运行状态，这种特质使得它更适合应对井喷式增长的指标计算需求。

与AI的关系

AI的发展赢得了全世界目光，国内外一个个大模型横空出世让世人惊叹，我们有幸生活在一个科技爆炸的时代，也有可能去见证这个世界将完成由碳基生命向碳基和硅基生命共存这样一个划时代的转变。

AI影响数据化运营

AI的发展会对数据化运营方式产生深远影响，相比于以SQL为核心的指标计算、管理和可视化方式，xl-formula的方案更为清晰明了，基于xl-formula建立的指标管理体系更便于与AI协作。

• SQL语法晦涩、复杂，AI生成SQL出现问题的概率要大得多，而xl-formula语法简洁，AI生成的错误率要低很多；
• SQL语句需要结合业务场景、数据特点进行优化，但AI没有办法提前预知数据特点、数据量，相对来说生成xl-formula更可靠，因为xl-formula语法固定，不需要任何定制化优化；
• SQL虽然可以实现可视化，但是实现可视化的方式较为不便，比如需要为每个指标预先设置维度筛选、日期筛选等相关信息，但xl-formula则不需要，xl-formula配置中有清晰的维度筛选字段和时间窗口信息，AI获取这些信息只需调用统一接口查询即可；

对AI领域的影响

我们总是在谈论AI对未来社会的影响，但我们换个角度思考一下什么会影响AI的发展呢？

众所周知"AI=算法+算力+数据"，在数据方面目前AI语言大模型的训练主要基于互联网语料，但这对AI的发展来说是明显不足的。AI的发展亟需海量的各种各样的对现实世界的感知数据，这样才能真正做到赋能百业走进日常生产生活。

现实世界的感知数据分为很多，比如：环境、交通、农业、气象、水利、医疗等，而这些数据会以不同的格式投喂给AI，比如：文本、音频、视频、图像、GPS、GIS、3D矢量格式、点云格式、高精度地图格式、自定义的结构化/非结构化格式、数值型指标类数据格式等等。

每一种格式的数据大范围的采集、存储、维护和使用都意味着巨大的成本，而不同的组织和存储方式之间的成本有着天壤之别，技术选型尤为重要。

对于企业来说，通用型流式大数据统计技术可以用统一的标准，组织和维护大批量指标数据，降低成本，让企业在AI场景使用这些数据更为高效。而在社会层面，数据指标共享体系可以实时汇聚千亿量级的数据指标，打破行业壁垒，这也将使其成为AI最核心的上游数据源头之一。

XL-Lighthouse是一个什么项目

您可能会觉得XL-LightHouse是一个流式统计计算系统，或者是一个自助式BI工具、是一个指标管理系统，或者是通用化的监控告警系统，但这些只是XL-LightHouse所呈现出来的一些特性，并不是它的本质。

XL-LightHouse项目的本质是提供了一套涵盖指标计算、指标存储、指标可视化、指标管理、监控告警、指标订阅和指标共享的机制。它对于互联网和物联网类企业具有广泛的实际业务价值，并期望更多企业围绕这一技术搭建自身的数据化运营系统，同时让更大范围的数据指标共享成为可能。

每个复杂生态的建设都需要一个契机，绝不是一个单纯的资源堆砌的结果，而是一个环环相扣、循序渐进的过程。切入点的选择尤其重要，共享平台的建立首先应该提供一个产品，解决大多数企业在某方面比较棘手的问题，企业在使用过程中愿意将数据存储到这个产品体系之内，而数据共享是越来越多的企业加入到这个体系后，自然而然、水到渠成发生的一件事情。

XL-LightHouse代表了一种以通用型流式大数据统计技术为基础的指标共享体系的建设方式，而这套共享体系拥有强大的指标类数据收集能力，可以用极低的成本实时收集现实世界和网络世界每一个细微角落所有有价值的指标数据，而每个运行中的XL-LightHouse项目都可以是这个庞大体系的一个触角。

商业合作机会

以下使用"开发者"代指XL-LightHouse项目开发者，使用"共建者"代指合作方。

通用型流式大数据统计技术的诞生代表着一个富有实用价值的技术生态体系的萌芽，具有广泛的应用场景，也同时伴随着较为可观的商业机会，如果您认同XL-LightHouse的项目理念和未来发展方向，欢迎您加入到这个生态体系的建设中来，同时开发者也会将绝大多数收益让渡给共建者。

周边生态研发和销售

该合作模式是指基于XL-LightHouse项目进行各类产品的研发和销售，比如：

• 如果您拥有自己的产品（App、网站、游戏、小程序、企业软件等各种形式的终端），您可以将XL-LightHouse融合到您自己的产品和服务中，作为其中的数据统计模块；
• 如果您拥有硬件传感设备相关的设计、制造、采购或人脉资源，可以将传感设备采集数据接入到XL-LightHouse，将其整合成各领域的数据可视化、监控告警解决方案；
• 如果您从事企业数据服务类产品的研发和销售，可以将XL-Lighthouse整合到您自己的产品中，作为自身产品的功能扩充；
• 您可以基于XL-LightHouse开发各类指标管理服务、可视化服务（比如：Web端、Android、IOS、数据大屏）、监控告警服务等；

加入条件：

• 面向所有类型的企业和个人开发者；
• 需要支付销售分成费用：在获得销售收益后向开发者支付总销售金额0.2% ~ 2%的授权费用；

您可以以任何形式整合XL-LightHouse到自己的产品或服务中，甚至可以直接对外销售XL-LightHouse项目，并且开发者为您提供技术支持服务。在这个过程中开发者不会干预您任何研发和经营细节，除非必要情况下的技术支持，否则开发者不会与您自己的客户有任何直接往来。只要您具备资源整合能力，开发者会尽最大努力配合您。

底层基础设施研发和销售

该合作模式是指基于本项目相关设计方案进行以下产品的研发和销售，包括：

• 自研通用型流式数据统计服务；
• 研发数据共享体系各核心环节（数据中心、聚合服务、数据指标交易平台、数据交易平台、交易存证服务）；

对于一个较为庞大复杂的技术生态体系的底层建设来说，任何一个企业和个人的力量都是微不足道的，开发者期望汇聚一定数量的具有较高研发实力的企业共同开发基于本项目衍生的数据指标共享体系和数据共享体系的底层基础设施，并在小范围内共享各组件的功能设计、组件间交互逻辑、通信协议等相关技术资料，既分摊试错成本，加快开发效率，又同时避免过度竞争。

加入条件：

• 仅面向具有较高软件研发实力的企业；
• 需要支付一次性授权费用：在加入该研发团体时，向开发者一次性支付的授权费用（限定一定数量内的企业，授权费用随着加入企业数量增多而逐渐增加，具体金额请与开发者联系）；
• 需要支付销售分成费用：在获得销售收益后向开发者支付总销售金额0.2% ~ 2%的授权费用；

结束语

本文介绍了通用型流式大数据统计技术以及XL-Lighthouse项目，并包含开发者对数据化运营领域未来发展趋势的个人理解。

如有错误或不当之处敬请指正，如果您有任何问题可以提issue或给我发邮件，期待与您交流！