通用型流式数据统计技术在大数据生态中的位置以及所要解决的问题

本篇文章是对这篇文章"什么是通用型流式数据统计技术"的进一步补充。本篇文章不涉及太多技术细节，旨在于从一个更高的视角，从理论层面让大家更清晰的了解这一技术方案究竟是用来做什么的以及它在大数据生态中的独特性。

通用型流式数据统计技术填补了大数据生态中一个极为重要的空白位置，它主要解决三个层面上的问题：

• 1、繁杂业务场景下大批量数据指标的并行计算问题；
• 2、提供一套完整的数据指标计算、存储、管理、可视化、权限、监控告警、指标订阅的机制；
• 3、为大规模数据指标共享体系的建立奠定基础；

繁杂业务场景下大批量数据指标的并行计算问题

在解释这个问题之前，不知道大家觉得企业治理乃至更大层面的社会治理，仅从技术层面分析：当前的数据化运营程度究竟处于一个什么水平？一个大型互联网企业的数据指标数量目前大约可以达到10万~30万个，这究竟是一个什么水平？

我个人总是习惯将一个技术领域的演进历程想象成是一个物种进化的历程，一个单细胞生物是初级阶段，而像我们人体则是一个高等物种。如果将企业的数据化运营程度比喻成一个物种的神经系统，我认为最顶级的互联网企业、最先进的智能工厂，其实目前的数据化运营程度仅仅只是一只“毛毛虫”的水平。

企业的数据化运营理念、基础设施水平仍然处于比较初级的阶段，而伴随着通用型流式大数据统计技术的出现，数据化运营这个看似古老的领域或许才刚刚拉开序幕。

现行技术方案OLTP、OLAP、时序数据库、Spark、Flink，它们都非常优秀，但它们更多的是侧重单一或少数业务场景下的计算问题，追求的是在少数业务场景下更快的计算效率、覆盖尽可能多的计算类型、承载更大的数据量和更复杂的计算逻辑。现在的数仓、数据湖也更像是前面技术方案的衍生品，对“繁杂”场景的应对能力同样非常薄弱。这些技术方案太笨重、不够轻巧、成本太高、爆发力太弱，而它们正在制约着企业数据化运营水平向下一个阶段迈进。

通用型流式数据统计技术聚焦于解决大批量数据指标的并行计算问题，XL-LightHouse所有的功能实现方案全部围绕着这一个中心展开，这和其他技术方案有着鲜明的不同。它所要做的是将企业的数据化运营程度提升两到三个数量级，也就是一个互联网大厂在成本不变的情况下数据指标数量可以达到1000万~3000万个。

有些朋友可能会怀疑企业是否需要那么多数据指标？这当然属于另外一个话题，我简单做下解释：数据化运营或许不能给企业带来直接收益，但是它可以让决策者站在一个前所未有的高度来俯视所面临的问题，空前提升决策者的业务驾驭能力。业务就像我们身体的血肉，而数据化运营就像我们的神经系统，每生长一块血肉就要有足够的神经覆盖。以前的技术方案针对一份业务只能提供几个单薄的指标、碎片化的图表，甚至很多时候内心都会怀疑这些数据指标的准确性，而通用型流式数据统计则是要向你呈现一个遍布上下游业务链条，互相关联、彼此佐证密集的数据网络。

通用型流式数据统计技术可以大幅度降低企业获取各类数据指标的成本，对于互联网、物联网类业务，它将颠覆很多人对数据化运营的理解和认知，会极大的影响甚至重塑企业现行的决策链路。

我认为在不远的将来程序员开发线上业务，将会在项目中添加流式统计的代码，就像打日志一样稀疏平常，加一个流式统计指标就像加一行日志一样平常。在工程研发领域，流式统计会发展成为像日志一样拥有同等重要地位的辅助型工具，很多企业也会像现在考核”单元测试覆盖率“一样来考核”线上服务流式监控指标覆盖率“，不管是业务类指标还是技术类指标，它们会充斥在所有线上业务代码之中。

提供一套完整的数据指标计算、存储、管理、可视化、监控告警、指标订阅的机制；

如果说git是项目研发管理、版本控制领域的事实标准，而反观指标管理领域，涉及指标整个链条其实并没有形成一个广泛统一的事实标准。

不管是要统计一下订单数据，还是接口调用量、异常量，线上的pv/uv/ctr...， 不要说不同企业之间了，就算是一个企业内部，甚至不同的程序员实现的功能也是千奇百怪、五花八门。打个比方：假如要将这些数据指标通过API提供出来，你会发现形形色色的API。

有没有必要建立一种标准化的指标管理机制

• 标准化指标管理机制可以提升协作效率；

企业是由不同部门和人员组成的有机整体，伴随着业务复杂化和人员组织机构的臃肿化，协作效率会急剧降低。而数据指标网络可以将每个业务的上下游链条和关联节点串联起来，是企业内部最快捷、最准确、最直接的信息传播途径，数据是辅助自己思考、验证自己的结论、佐证自己的观点最有利的武器，它在很多时候要比人与人之间的语言沟通高效的多。

• 标准化指标管理机制是在保护企业的数据资产，避免数据资产的流失；

数据指标是企业数据资产中非常非常重要的组成部分，但这部分资产却每时每刻都在不断的流失。一个大型电商企业，你问他们要3年前、5年前，10年前的某个数据指标，比如：某家电品牌最近10年的浏览量、搜藏量、加购量、购买量、退货率的走势情况，那大概率是很难拿的出来的。随着版本的迭代、技术方案的重构、数据表结构的变更和迁移、埋点类型和字段含义的变化、人员的离职和流动，相关的日志可能早就没有了，当然或许日志还存储在磁盘里，但是鬼知道那是什么玩意呢，总不能找一篇5年前、10年前的文档来核对以前的字段含义吧？现实中很多企业的数据资产，虽然好像理论上还存在，但其实早就已经永久性的丢失了...

所以，不管是从短期利益还是长远考虑，企业建立标准化的指标管理机制都是一件迫在眉睫的事情。

BI产品的硬伤是什么

大中型企业大多都是有指标管理平台或者数据平台的，这些平台在指标计算方面的实现方案主流程基本都是通过SQL查询OLTP、OLAP、数据仓库、数据湖、时序数据库等之类技术方案实现的。

对于这类方案，算不算是标准化的指标管理机制呢，我认为：不算。

这类技术方案和市面上的BI产品并不存在显著差异，下面我们分析一下BI产品是做什么的，为什么它不算是标准化的指标管理机制。

BI产品经过几十年的发展已经是一个比较“固化”的概念了，市面上任何BI产品几乎都是千篇一律，主流程有着极大的重复度和相似性。无外乎这几个流程：连接数据源、创建数据集、生成可视化图表和制作看板。

• BI产品的优势

数据指标计算直接基于业务表，数据源头更可靠，不需要额外保证数据源的一致性，实现方案的复杂度较低；通过页面交互生成SQL再获取指标结果并渲染出图表，整体流程也比较方便。

• BI产品的缺陷

BI对数据源的要求比较苛刻，相对来说更适合比较“稳定“、“规范”的业务。这类业务数据源表结构非常固定，基本不需要变化，每个字段的含义非常清晰、格式分明、所要存储的内容有严格的约束。而反过来说，如果业务经常发生迭代，会较为频繁增加、删除字段，每个字段的含义可能会随着版本的迭代而发生改变，字段存储的数据也会同时变化，而有些像枚举、字典表这类字段更是会频繁扩充、删减和改变。这种情况下直接基于业务表进行统计分析就会有很大影响，很可能一个表里面存储的数据虽然看着差不多，但其实里面存储了好多个版本的数据。这就可能会出现一个SQL语句在一个时间段内它是正确的，但是在其他时间段又是错误的，今天执行是正确的，明天执行可能又是错误的。

除此之外，BI产品的主流程是基于SQL，所以所有SQL的缺陷它都具备，比如：它完全依赖业务表数据，只要业务表数据丢失或删除，那指标类数据也就同时没有了；并发支持度有限；SQL执行时间不可控，数据量较大的情况下严重影响交互体验；而且每次查询都会造成比较高业务数据库压力等等。

所以，BI产品和大中型企业目前在使用各种数仓、数据湖、数据平台类方案，它们的价值是毋容置疑的，但它们也有很大的局限性：不适合快速迭代的业务，它们的设计初衷更多是为了满足现阶段、短周期内的业务需要，而不是为了满足长期性、永久性的业务需要。

而为了满足长期性业务需要，一套完善的数据指标管理机制，它首先要遵循一个基本前提就是能够承载将数据指标作为资产进行传承。为了说的更直白一点，我举一个例子：

程序员A在职期间开发了一个各家电品牌搜藏量、加购量、购买量的数据指标，实现方案是基于当前日志表的SQL语句实现，A离职后交接给B。那这种算不算数据资产的传承呢？当然不算，这只是工作交接而已，但凡是日志表发生几个版本的变化，以前的数据指标可能就丢失了。

程序员A在职期间开发了一个各家电品牌搜藏量、加购量、购买量的数据指标，为了辅助验证核心指标的准确性，他还同时分别为搜藏量、加购量和购买量计算了若干个关联指标，并将这些指标的结果每天按照“固定规则”写入到企业的指标库中。A离职后交接给B，B负责后续这些指标的维护工作，如果线上日志发生迁移、数据格式变化等情况，B修改原来的计算逻辑，同时继续按“固定规则”将指标结果每天写入到公司的指标库中，其他人员只需要从指标库中查询数据就可以了，这种才算数据资产的传承。因为它更为稳定，不会因为外部变化、人员流动而流逝。

所以，BI产品的不足是更侧重短期需要，而非长期需要，它是为了满足现阶段的指标需求，而非承载企业的数据指标资产。

如何建立指标管理机制

BI类产品显然不适合作为企业的指标库来使用，那一套完善的指标管理机制应该如何定义呢？

有些朋友会觉得，指标库直接使用KV存储，企业内部约定一种每个指标值Key的生成逻辑，然后将Value保存不就可以了吗？或者像Prometheus一样每个数据点存储一条记录，大概包括：指标名称、标签、数值和时间戳几个参数不也可以吗？

• Prometheus这类指标存储方案（指标名称+标签+数值+时间戳）是否能够满足大规模数据指标长期存储呢？

先不谈这种方案好还是不好，首先要弄明白这种存储格式被设计出来是用来干什么的？这种存储格式是典型的时序数据库存储结构，它的目的是用来快速存储每个指标下实时产生的数据点，并在查询时在这些数据点的时间序列基础上，进行聚合运算和数据分析使用的。也就是说统计结果是在这类数据的基础上聚合运算分析得来的，这种结构根本就不是用来保存统计结果的！

有些朋友可能会想假如就要用这种结构来存储大规模数据指标的统计结果会怎么样呢？那其实答案很明显：统计结果的写入、更新、删除等操作要遵循行级别原子化操作，但这种结构它是遵循不了的，所以要存储大规模数据指标的统计结果，这种格式首先就被排除了。

• 企业内部约定一种key的生成逻辑，然后将各数据指标的结果按照kv存储的方案有什么问题呢？

其实任何形式的约定、标准、规范、协议它只能实现比较小范围的指标数据存储，涉及的人员不能太多，指标数量不能太多。否则，不管你的标准制定的多么精细，在真正执行落地过程中都会发生严重的变形走样，最终难以为继。而只要指标的数量变多就会发现所要应对的问题变得复杂，而之前的所有的定义都会显得特别简陋，这也是市面上你所能找到的任何指标存储相关的标准、规范、协议都有很大局限性的原因。我认为一套单薄的标准承载不了一套复杂的体系，而一套机制才可以。

XL-LightHouse和xl-formula是一套完备的指标管理机制，它具备以下特性：

• 稳定性

这里说的稳定性不仅仅是系统服务的稳定性，更是一种运行逻辑的稳定性。稳定性是承载数据指标资产传承的前提，基于SQL对业务表分析的方案只要业务表发生变更、迁移、删除、丢失等任意情况，都可能影响数据指标的历史结果，所以SQL类方案严重缺乏稳定性。

XL-LightHouse整个运行逻辑并不依赖业务表，它只依赖线上实时产生的业务数据流，根据Web端的统计配置完成每个指标运算并将结果更新到DB，而对于已写入数据的查询不需要依赖任何外部服务。

• 对繁杂场景的支持能力

大规模数据指标彼此之间具有很大的差异性。比如：数据指标从时间粒度上可分为秒、分钟、小时、天、周、月、年等统计周期；从维度数量可以分为：无维度、单维度、多维度；每个指标的数据量可能存在很大差异，比如电商平台每天交易额，一天只生成一个数据点，但是每个商品的交易额，数量级却会非常巨大；从有效期层的角度，有些数据指标需要长期永久性存储，而有些只需要短期存储。所以，一个指标库的设计要具备应对繁杂场景的支持能力。

• 高并发查询能力

指标库作为企业的基础服务，需要承载所有人员的交互式查询，并且指标库也可以通过api等方式查询，所以指标库设计需要支持高并发查询能力。而OLAP、OLTP、时序数据库之类方案的并发查询能力非常有限，这些方案的并发能力取决于：数据量的大小、存储引擎自身、服务器资源和能否命中索引、预计算逻辑等原因，有很大的不确定性。

而通用流式数据统计的计算方案只存储统计结果，所以查询时直接通过Get获取结果就可以了，查询本身并没有任何聚合计算的过程，所以更具有高并发查询能力。

• 灵活迁移 & 数据备份能力

指标库用于承载企业的核心数据资产，需要具备数据迁移和备份的能力，防范数据丢失风险，提高可靠性。在这个方面SQL类方案也存在明显不足，因为SQL方案是在查询时对业务表进行聚合分析才得到结果。而大规模的数据指标可能需要依赖大规模的数据库和表结构，这类方案几乎不具备整体迁移和备份能力。

而通用流式数据统计的实现方案只存储统计结果，即便是大规模的数据指标也只需要一个数据库用来存储就可以，所以它天然具备灵活的整体迁移和备份能力。

• 指标级原子性，可覆盖、可删除、可追溯

通用流式数据统计每个指标在同一个时间点、同一个维度下具有原子性，可以进行写入、更新、删除等原子化操作，对于高优先级指标具备版本追溯能力。

• 多访问模式支持

通用流式数据统计方案可以提供便捷的交互式页面查询能力、具有统一的API查询机制、数据导出机制，支持多种访问模式，能够满足指标库各种使用场景。

• 生命周期管理

存储大规模数据指标意味着数据量可能迅速膨胀，通用流式数据统计方案可以支持以数据指标为粒度按重要程度设置有效时长，相比而言SQL类方案只能做到以业务表为粒度的生命周期管理。

• 细粒度安全访问机制

通用流式数据统计方案能够支持非常细粒度权限控制，可根据业务需要按照指标级、维度级、时间周期等进行访问验证，有助于防范数据泄露风险。而由于BI产品是侧重在数据指标计算和分析，大多数BI产品都是以"数据库/数据源"为粒度的权限控制，也就是只要有一个数据库的权限那就可以读取任意指标，而没有一个数据库的权限也就不能读取任何指标。这种权限控制逻辑也完全不适合"指标库"场景，因为指标库是侧重指标的流通、共享，它和数据源、数据库、业务表的权限分配逻辑是完全隔离开的，互不影响。

• 高性能监控告警机制

通用流式统计方案具备高并发查询能力所以也同样适合高频率的监控告警场景，而SQL类方案在数据量较大时、计算类型比较复杂时(比如:count distinct等计算)、高频率场景都存在很大的局限性。

• 低成本存储、水平扩展能力

数据指标需要进行长期甚至永久性存储，低成本存储方案是非常重要的影响因素。通用流式方案不需要存储原始数据，只存储统计结果，整体维护的数据量级要小的多，并且也不需要像OLAP、时序数据库之类方案维护庞大的索引数据占用很多的内存资源，所以它整体数据存储成本和对服务器资源占用要小的多。

• 限流保护

指标库是同时管理大规模的数据指标，而不能因为单个数据指标的数据量暴涨和高频访问影响整体服务的稳定性，所有指标库服务需要具备限流保护机制。

• 支持数据订阅、数据共享

通用流式统计方案可以提供标准化的订阅和共享机制，可以实现数据指标跨部门、跨企业、跨行业的流通和使用。

为大规模数据指标共享体系的建立奠定基础

未来每个企业几乎都会拥有自己的指标库服务来承载指标类资产长期性、永久性存储和传承，那指标库会不会像Git仓库、Maven仓库一样同一套机制被广泛使用呢？

这个问题的回答毫无疑问是必然会发生的，或者说通用化的指标管理机制就是万亿级指标共享体系的雏形阶段。

如果说Git、Maven这些工具更多影响的是程序员群体，那未来万亿级指标共享体系不仅是关联每个企业的发展，也会跟每个人的学习、工作、生活，甚至生命，都息息相关。

其实不管是统计道路的车流量、人流量，还是监控每座建筑桥梁的承压状况；不管是每一盏路灯的运行状态，还是每一条河流的流速和水质状况；不管是资讯网站的PV/UV，还是电商网站的订单量、交易额；不管是存储金融机构的经济数据，还是片区的房价走势；不管飞机高铁实时运行参数，还是一辆私家车的重要组件的磨损程度；不管是气象局每天发布的温度、风速、降雨量，还是上市企业公开的财报；不管是每个家庭里安装一键救援（119/120/110），还是存储个人的体检报告...其实，从技术角度来看，它们并没有什么本质的差异。

使用一套机制来承载不同领域的服务，既可以充分的降低成本又便于数据的流通和利用，这也就是指标共享体系的价值所在。

技术的发展或许会迂回向前，但现实世界和网络世界每一个角落里的每一个有社会价值的数据指标，都终将被一套指标管理机制来承载。

我认为通用型流式大数据统计技术是承载大规模数据指标共享体系最完美的基座。

关于xl-lighthouse项目的一点补充

1、通用型流式数据统计技术是一种用于解决繁杂场景下大批量数据指标并行计算问题的“软件设计思想”，xl-lighthouse是由开发者提供的一套具体软件实现方案。而受限于开发者的资源和时间，短期还无法将xl-lighthouse完全摆脱对Spark、Redis..这些技术框架的依赖，所以从部署和源码的层面来看，xl-lighthouse还会显得有些笨重（但是从数据接入和使用层面来说，它是同领域所有技术方案中最为轻巧和简洁的）；

2、开发者已对它的运行稳定性、准确性等各方面问题进行了充分测试，请放心使用；

3、大型互联网企业如果比较在意技术方案的可控性，也完全可以参考xl-lighthouse实现自己的“通用型流式大数据统计系统”；