责任编辑分为五个段落如是说动态排序，第一节如是说动态排序出现的原因及基本概念；第一节如是说动态排序的应用应用领域情景；第二节如是说动态排序常用的构架；第二节是动态数仓软件控制系统。

一、动态排序

动态排序一般都是特别针对海量统计数据展开的，并且要求为秒级。由于大统计数据蓬勃发展Hathras，Hadoop并没得出动态排序软件控制系统，随后Storm，SparkStreaming，Flink等动态排序架构不断涌现，而Kafka，ES的蓬勃发展使得动态排序应用领域的技术愈来愈健全，而随著物联网，机器学习等控制技术的推展，动态INS13ZD排序将在那些应用领域得到充份的应用应用领域。

动态排序的三个特征：

无穷统计数据：无穷统计数据指的是一类不断增长的，大体上无穷的统计数据集。那些通常被称为“流统计数据”，而与之相对的是非常有限的统计数据集。景丰纯统计信息处置：一类稳步的统计信息处置商业模式,能透过处置发动机多次重复的去处置下面的无穷统计数据，是能突破非常有限统计信息处置发动机的困局的。低延后：延后是多少并没明确的表述。但他们都知道统计数据的价值将随著时间的推移降低，及时性将是须要稳步解决的问题。

现在大统计数据应用应用领域比较火热的应用领域，比如说所推荐控制系统在课堂教学Hathras受控制技术受限于，可能要五分钟，一半小时，甚至更久对使用者展开所推荐，这相比之下不能满足要求，他们须要更慢的完成对统计数据的处置，而不是展开app的批处置。

二、动态排序应用应用领域情景

随著动态控制技术发展趋向成形，动态排序应用应用领域愈来愈广泛，以下仅列出常用的三种动态排序的应用应用领域常用：

1. 动态智能化所推荐

智能化所推荐会根据使用者历史的买回或下载行为，透过所推荐演算法体能训练数学模型，预估使用者未来可能会买回的贵重物品或钟爱的资料库。对个人而言，所推荐控制系统起着信息过滤器的作用，对Web/App服务器端而言，所推荐控制系统起着满足使用者个人化需求，提升使用者满意率的作用。所推荐控制系统本身也在飞速发展，除了演算法愈来愈健全，对时延的要求也愈来愈苛刻和动态化。利用Flink流排序帮助使用者构建更加动态的智能化所推荐控制系统，对使用者行为指标展开动态排序，对数学模型展开动态更新，对使用者指标展开动态预估，

2. 动态欺诈检测

在金融应用领域的业务中，常常出现各种类型的欺诈行为，例如信用卡欺诈，信贷申请欺诈等，而如何保证使用者和公司的资金安全，是近年来许多金融公司及银行共同面对的挑战。随著不法分子欺诈手段的不断升级，传统的反欺诈手段已经不足以解决目前所面临的问题。以往可能须要几个半小时才能透过交易统计数据排序出使用者的行为指标，然后透过规则判别出具有欺诈行为嫌疑的使用者，再展开案件调查处置，在这种情况下资金可能早已被不法分子转移，从而给企业和使用者造成大量的经济损失。而运用FlinkINS13ZD排序控制技术能在毫秒内就完成对欺诈行为判断指标的排序，然后动态对交易流水展开动态拦截，避免因为处置不及时而导致的经济损失。

3. 舆情分析

有的客户须要做舆情分析，要求所有统计数据存放若干年，舆情统计数据每日统计数据量可能超百万，年数据量可达到几十亿的统计数据。而且爬虫爬过来的统计数据是舆情，透过大统计数据控制技术展开分词之后得到的可能是大段的网友评论，客户往往要求对舆情展开查询，做全文本搜索，并要求响应时间控制在秒级。爬虫将统计数据爬到大统计数据平台的Kafka里，在里面做Flink流处置，去重去噪做语音分析，写到ElasticSearch里。大统计数据的一个特点是多统计数据源，大统计数据平台能根据不同的情景选择不同的统计数据源。

4. 复杂事件处置

对于复杂事件处置，比较常用的集中于工业应用领域，例如对车载传感器，机械设备等动态故障检测，那些业务类型通常统计数据量都非常大，且对统计信息处置的及时性要求非常高。透过利用Flink提供的CEP展开时间商业模式的抽取，同时应用应用领域Flink的Sql展开事件统计数据的转换，在INS13ZD控制系统中构建实施规则发动机，一旦事件触发报警规则，便立即将告警结果通知至下游通知控制系统，从而实现对设备故障快速预警检测，车辆状态监控等目的。

5. 动态机器学习

动态机器学习是一个更宽泛的基本概念，传统静态的机器学习主要侧重于静态的数学模型和历史统计数据展开体能训练并提供预估。很多时候使用者的短期行为，对数学模型有修正作用，或者说是对业务判断有预估作用。对控制系统而言，须要采集使用者最近的行为并展开特征工程，然后给到动态机器学习控制系统展开机器学习。如果动态地实施新规则，或是推出新广告，就会有很大的参考价值。

三、动态排序构架

他们先来看一张大统计数据平台的动态构架图：

统计数据同步：

在下面这张构架图中，统计数据从Web平台中产生，透过统计数据同步控制系统导入到大统计数据平台，由于统计数据源不同，这里的统计数据同步控制系统实际上是多个相关控制系统的组合。统计数据库同步通常用 Sqoop，日志同步可以选择 Flume等，不同的统计数据源产生的统计数据质量可能差别很大，统计数据库中的格式化统计数据直接导入大统计数据控制系统即可，而日志和爬虫产生的统计数据就须要展开大量的清洗、转化处置才能有效使用。

统计数据存储：

该层对原始统计数据、清洗关联后的明细统计数据展开存储，基于统一的动态统计数据模型分层理念，将不同应用应用领域情景的统计数据分别存储在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存储中。

统计数据排序：

排序层主要使用 Flink、Spark、Presto 以及 ClickHouse 自带的排序能力等四种排序发动机，Flink 排序发动机主要用于动态统计数据同步、 INS13ZD ETL、关键控制系统秒级动态指标排序情景，Spark SQL 主要用于复杂多维分析的准动态指标排序需求情景，Presto 和 ClickHouse 主要满足多维自助分析、对查询响应时间要求不太高的情景。

动态应用应用领域：

以统一查询服务对各个业务线统计数据情景展开支持，业务主要包括动态大屏、动态统计数据产品、动态 OLAP、动态特征等。

当然一个好的大统计数据平台不能缺少元统计数据管理及统计数据治理：

1. 元统计数据及指标管理：主要对动态的Kafka表、Kudu表、Clickhouse表、Hive表等展开统一管理，以数仓数学模型中表的命名方式规范表的命名，明确每张表的字段含义、使用方，指标管理则是尽量透过指标管理控制系统将所有的动态指标统一管理起来，明确排序口径，提供给不同的业务方使用；

2. 统计数据质量及血缘分析：统计数据质量分为平台监控和统计数据监控两个部分，血缘分析则主要是对动态统计数据依赖关系、动态任务的依赖关系展开分析。

以上构架只是大统计数据平台通用的统计数据数学模型，如果要具体的建设，须要考虑以下情况，业务需求须要动态还是准动态即可，统计数据及时性是秒级还是分钟级等。

在调度开销方面，准动态统计数据是批处置过程，因此仍然须要调度控制系统支持，调度频率较高，而动态统计数据却没调度开销；在业务灵活性方面，因为准动态统计数据是基于 ETL 或 OLAP 发动机实现，灵活性优于基于流排序的方式；在对统计数据晚到的容忍度方面，因为准动态统计数据可以基于一个周期内的统计数据展开全量排序，因此对于统计数据晚到的容忍度也是比较高的，而动态统计数据使用的是增量排序，对于统计数据晚到的容忍度更低一些；在适用情景方面，准动态统计数据主要用于有动态性要求但不太高、涉及多表关联和业务变更频繁的情景，如交易类型的动态分析，动态统计数据则更适用于动态性要求高、统计数据量大的情景，如动态特征、流量类型动态分析等情景。

动态构架

在某些情景中，统计数据的价值随著时间的推移而逐渐减少。所以在传统大统计数据app数仓的基础上，逐渐对统计数据的动态性提出了更高的要求。

于是随之诞生了大统计数据动态数仓，并且衍生出了两种控制技术构架Lambda和Kappa。

1. Lambda构架

先来看下Lambda构架图：

Lambda构架图

统计数据从底层的统计数据源开始，经过Kafka、Flume等统计数据组件展开收集，然后分成两条线展开排序：

一条线是进入INS13ZD排序平台（例如 Storm、Flink或者SparkStreaming），去排序动态的一些指标；另一条线进入批量统计信息处置app排序平台（例如Mapreduce、Hive，Spark SQL），去排序T+1的相关业务指标，那些指标须要隔日才能看见。

为什么Lambda构架要分成两条线排序？

前的结果，这对于动态决策而言有一个巨大的时间鸿沟，很可能导致管理者错过最佳决策时机。

Lambda构架属于较早的一类构架方式，早期的流处置不如现在这样成形，在准确性、扩展性和容错性上，流处置层无法直接取代批处置层，只能给使用者提供一个近似结果，还不能为使用者提供一个一致准确的结果。因此Lambda构架中，出现了批处置和流处置并存的现象。

在 Lambda 构架中，每层都有自己所肩负的任务。

1. 批处置层存储管理主统计数据集（不可变的统计数据集）和预先批处置排序好的视图：

批处置层使用可处置大量统计数据的分布式处置控制系统预先排序结果。它透过处置所有的已有历史统计数据来实现统计数据的准确性。这意味着它是基于完整的统计数据集来重新排序的，能修复任何错误，然后更新现有的统计数据视图。输出通常存储在只读统计数据库中，更新则完全取代现有的预先排序好的视图。

2. 流处置层会动态处置新来的大统计数据：

流处置层透过提供最新统计数据的动态视图来最小化延后。流处置层所生成的统计数据视图可能不如批处置层最终生成的视图那样准确或完整，但它们几乎在收到统计数据后立即可用。而当同样的统计数据在批处置层处置完成后，在速度层的统计数据就可以被替代掉了。

那Lambda构架有没缺点呢？

Lambda构架经历多年的发展，其优点是稳定，对于动态排序部分的排序成本可控，批量处置可以用晚上的时间来整体批量排序，这样把动态排序和app排序高峰分开，这种构架支撑了统计数据行业的早期发展，但是它也有一些致命缺点，并在大统计数据3.0时代愈来愈不适应统计数据分析业务的需求。缺点如下：

使用两套大统计信息处置发动机：维护两个复杂的分布式控制系统，成本非常高。批量排序在排序窗口内无法完成：在IOT时代，统计数据量级愈来愈大，经常发现夜间只有4、5个半小时的时间窗口，已经无法完成白天20多个半小时累计的统计数据，保证早上上班前准时出统计数据已成为每个大统计数据团队头疼的问题。统计数据源变化都要重新开发，开发周期长：每次统计数据源的格式变化，业务的逻辑变化都须要特别针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。

导致 Lambda 构架的缺点根本原因是要同时维护两套控制系统构架：批处置层和速度层。他们已经知道，在构架中加入批处理层是因为从批处置层得到的结果具有高准确性，而加入速度层是因为它在处置大规模统计数据时具有低延时性。

那他们能不能改进其中某一层的构架，让它具有另外一层构架的特性呢？

例如，改进批处置层的控制系统让它具有更低的延时性，又或者是改进速度层的控制系统，让它产生的统计数据视图更具准确性和更加接近历史统计数据呢？

另外一类在大规模统计信息处置中常用的构架——Kappa 构架，便是在这样的思考下诞生的。

2. Kappa构架

Kafka的创始人Jay Kreps认为在很多情景下，维护一套Lambda构架的大统计信息处置平台耗时耗力，于是提出在某些情景下，没必要维护一个批处置层，直接使用一个流处置层即可满足需求，即下图所示的Kappa构架：

Kappa构架

可以认为Kappa构架是Lambda构架的一个简化版本，只是去除掉了Lambda构架中的离线批处置部分；

Kappa构架的蓬勃发展主要有两个原因：

Kafka不仅起到消息队列的作用，也可以保存更长时间的历史统计数据，以替代Lambda构架中批处置层统计数据仓库部分。流处置发动机以一个更早的时间作为起点开始消费，起到了批处置的作用。Flink流处置发动机解决了事件乱序下排序结果的准确性问题。

Kappa构架相对更简单，动态性更好，所需的排序资源远小于Lambda构架，随著动态处置的需求在不断增长，更多的企业开始使用Kappa构架。但这不意味着kappa构架能取代Lambda构架。

Lambda和kappa构架都有各自的适用应用领域；例如流处置与批处置分析流程比较统一，且允许一定的容错，用Kappa比较合适，少量关键指标（例如交易金额、业绩统计等）使用Lambda构架展开批量排序，增加一次校对过程。

还有一些比较复杂的情景，批处置与流处置产生不同的结果（使用不同的机器学习数学模型，专家控制系统，或者动态排序难以处置的复杂排序），可能更适合Lambda构架。

四、动态数仓软件控制系统

动态数仓分层构架为了避免面向需求响应的烟囱式构建，动态数仓也引入了类似于app数仓的分层理念，主要是为了提高数学模型的复用率，同时也要考虑易用性、一致性以及排序成本。

当然动态数仓的分层构架在设计上并不会像app数仓那么复杂，避免统计数据在流转过程中造成的不必要的延时响应；

动态数仓分层构架图：

动态数仓分层构架

ODS层：以Kafka为支撑，将所有须要动态处置的相关统计数据放到Kafka队列中来实现贴源统计数据层；DWD层：动态排序订阅业务统计数据消息队列，然后透过统计数据清洗、多统计数据源join、INS13ZD统计数据与app维度信息等的组合，将一些相同粒度的业务控制系统、维表中的维度属性全部关联到一起，增加统计数据易用性和复用性，得到最终的动态明细统计数据；DIM层：存放用于关联查询的维度信息，可以根据统计数据现状来选择存储介质，例如使用HBase或者MysqlDWS层：轻度汇总层是为了便于面向AdHoc查询或者Olap分析构建的轻度汇总结果集合，适合统计数据维度、指标信息比较多的情况，为了方便根据自表述条件的快速筛选和指标聚合，所推荐使用MPP类型统计数据库展开存储，此层可视情景情况决定是否构建；APP层：面向动态统计数据情景需求构建的高度汇总层，可以根据不同的统计数据应用应用领域情景决定使用存储介质或者发动机；例如面向业务历史明细、BI支持等Olap分析情景，可以使用Druid、Greenplum，面向动态监控大屏、高并发汇总指标等需求，可以使用KV商业模式的HBase；统计数据量较小的时候，也可以使用Mysql来展开存储。

这里要注意下，其实APP层已经脱离了数仓，这里虽然作为了数仓的独立分层，但是实际APP层的统计数据已经分布存储在各种介质中用于使用。

基于Flink 构建的动态数仓

随著业务情景的丰富，更多的动态需求不断涌现，在追求动态任务高吞吐低延后的同时，对排序过程中间状态管理，灵活时间窗口支持，以及 exactly once 语义保障的诉求也愈来愈多。

：

高吞吐、低延时；端到端的 Exactly-once，保证了统计数据的准确性；可容错的状态管理，动态数仓里面会展开很多的聚合排序，那些都须要对于状态展开访问和管理；丰富的API，对Streaming/Table/SQL支持良好，支持UDF、INS13ZDjoin、时间窗口等高级用法；健全的生态体系，动态数仓的构建会涉及多种存储，Flink在这方面的支持也比较健全。

基于Flink的动态数仓统计数据流转过程: