共计 2665 个字符，预计需要花费 7 分钟才能阅读完成。
5. 实时离线统计零碎
一、序
在有了日志等数据之后，咱们须要依据业务方的需要来统计各类数据报表以供业务剖析应用。这里咱们分两个方向离线和实时，都是从零到一随着技术的倒退逐渐建设和倒退欠缺起来的。因为都是通过肯定的模型进行统计，统称为模型化统计零碎。
原始阶段：在各种技术刚刚起步的阶段，对于各种需要根本都是手动编码去做一下定制化统计与展现；
初始阶段：离线和实时的数据统计，在没有指标零碎之前，都是通过形象日志，造成对应的统计规定，而后统计程序依据配置的规定进行解析与统计；
倒退阶段：通过多维数仓、实时技术的倒退，与各种剖析组件买通，比方 kylin、druid、clickhouse 实现数据的统计与剖析；
指标零碎阶段：由实时离线统计零碎，解析指标管理系统的配置信息，进行数据的统计工作，从而保证数据口径的统一。
二、离线
后期：定制化统计
大多数公司，都是从定制化开发开始做数据分析的工作，比方最开始针对不同的数据分析需要编写对应的 MapReduce 程序；针对对应的报表写 hive sql 统计成后果表，再抽取到 mysql 进行数据分析与展现 … 很多状况下都是烟囱式开发，毛病显著：1、保护开发成本高；2、不成体系，逻辑无奈复用；3、计算资源的节约。为了解决这些问题，咱们开发了一个 MapReduce 的离线统计零碎，就是上面所述的单维模型统计零碎。
中期：单维模型统计与展现
为了解决一些常见的离线的数据统计，首先咱们定义了一个后端日志、前端日志的统计模型，在这个模型的根底之下来定义指标，在该零碎下只能对一个指标只能做确定性的维度精选统计，比方统计品类下 A、B 的数据，咱们须要配置成 2 个指标来进行统计，指标反对 pv、uv、sum、top 统计。这样在后端统计程序上能够绝对简略的实现对应的统计，缩小了后端复杂度，减少了可靠性。
咱们统计好了数据之后，有对应的展现零碎来做数据的展现，咱们能够通过组合各种指标来造成对应的报表。这套零碎在前中期为咱们解决了一部分一般的统计需要。
当然，这个零碎也是有局限性的，1、对多维分析反对的不够敌对 2、展现的单一性 3、整体上不够灵便，在肯定范畴内实现了配置化统计。这种模式根本也就是实现了通知你数据是怎么的，不可能进行摸索式剖析，充沛的挖掘数据价值。
以后：多维明细数仓 +kylin/clickhouse（多维分析）
当初更多的状况是采纳数仓明细表 + 数据分析的各种组件组合这样的形式，这样咱们充沛的施展了数据仓库的价值，保障了逻辑的复用口径的对立，因为 kylin、clickhouse 的特点不同，咱们能够针对不同需要数据的特定抉择接入到不同的剖析组件下，来实现疾速的 OLAP 数据分析。因为这些计算剖析的组件，根本都反对 sql 化的查问，为后续的数据对立的展现对接打下了较好的根底。
以后：SQL 模板与数据提取（圈群提取与剖析）
这套零碎是针对业务经营、产品人员疾速的提取数据所设计的。实质上是通过事后配置好的 SQL 模板，来帮忙不会写 sql 的经营、产品实现数据统计 SQL 逻辑的开发。相当于用户标签画像的雏形后期阶段。后续依据这套统计零碎扩大了留存、漏斗、标签模型的计算。
SQL 模板的定义：配置一个 SQL 模板，形容对应的 sql 须要填写哪些参数，应用对应的占位符进行填充，指定对应的占位符应用哪个维度来解析，比方：是日期、品类、城市，这样能够通过下拉框来确定具体执行的 sql。
模板关系：通过配置各个模板 SQL 所筛选进去的人群，能够对各个模板的人群做交加、或集等汇合逻辑运算，最终获取到对应满足条件的人群。
数据的计算：在参数与关系确定的状况下，咱们通过 hive JDBC 的形式管制工作的执行与数据的下载。
这个套零碎解决了业务人员提取数据的需要，是帮忙不会写 sql 的人员用图形化的形式实现业务 sql 逻辑的编写。当然这个套零碎也有着显著的毛病：
1、实现了 sql 模板的复用，然而重复性计算，节约了计算资源
2、逻辑绝对黑盒，无奈积淀成对应的数据仓库表，导致 sql 模板在肯定水平上的局限，不能把数据积淀下来
3、业务逻辑变动时须要更新对应模板
在此基础上咱们后续从新设计开发了用户标签零碎，做了如下的改良
1、保留了 sql 模板，不过这个模板是为了能够对接各个业务方的标签数据，比方：搜寻举荐的标签库、风控的标签、也能够比拟不便的对接到已在数仓的标签表。相对来说用 sql 模板保留了扩展性。
2、数据标签后果可积淀数仓，这样相当于生成了对应的标签数仓表，各个剖析或业务团队能够间接应用与对接，对立标签规范。
3、引入 clickhouse 组件，放慢标签数据提取效率。绝对与之前的 hive jdbc，也是一个预计算的过程，因为预计算能够实现更快的数据查问与提取。
三、实时
实时统计零碎的倒退整体上与离线统计的倒退相似，实时的流式解决，向着 sql 化与批流对立的方向一直的提高与倒退，从最开始的 storm、spark、spark streaming、flink，一直的提高晋升性能，解决各种实时问题，加强性能。各种后续相干的零碎也随之应运而生。
后期：定制化统计
在这个阶段，咱们次要是依据用户的实时需要，依照特定的业务逻辑编写对应的 storm 程序进行数据统计，最终把后果落地到 hbase 当中，以供后续查问零碎进行查问与数据展现。在实时模型化统计不能反对的状况下，还须要采纳这种形式应用 flink 等对非凡数据进行统计与解决。
以后：模型化配置统计
kafka 日志形象：针对不同的 topic 日志，对日志进行形象配置，指定分隔符和日志行对应的字段信息等
监控项：通过配置好的日志行，来定义监控项生成对应的统计规定，包含条件、维度组合、维度主动发现等等
数据展现：通过前端平台依照特定的数据逻辑来查问对应实时的数据后果
实时模型化统计，整个后端计算引擎最开始咱们应用 storm，后续逐渐降级 spark streaming 版本，以及 flink 版本，依据不同的技术特定引入了新的统计形式的反对，比方 flink 的 join 操作等。后续能够扩大后果数据能够写入到不同的目的地当中。
以后：实时数据处理 +druid
同离线数据一样，实时咱们也有着各种多维分析的场景，这里咱们应用实时的流式解决技术把数据洗如到 druid 当中，而后应用 druid 做实时多维分析的查问与后果数据的展现。
四、瞻望
- 对立指标模型零碎：实时离线统计零碎对立对接一套统计模型管理系统，最大水平上保障实时离线数据口径的一致性；
- 批流合一：随着流式解决的倒退、实时数仓等建设，逐渐实现实时、离线统计零碎的合并，只保留一套统计零碎，缩小各种计算资源的节约。
