Lansonli（蓝深李）的博客

利用框架的力量，看懂游戏规则，才是入行的前提大多数人不懂，不会，不做，才是你的机会，你得行动，不能畏首畏尾选择才是拉差距关键，风向，比你流的汗水重要一万倍，逆风划船要累死人的上面这些看似没用，但实际很重要，这里就不再具体说明，感兴趣的同学可以看看我的学习框架的重要性我是怎么坚持学习的怎么确定学习目标本栏目为缺少OLAP技术体系的同学全面整理的体系学习知识，内容是按不同的技术体系整理的，带你丰富大数据OLAP技术知识体系，想学会就得自律加坚持，赶快行动吧。

在Flink开发平台，新建名为DWD的SQL流作业，并将如下代码拷贝到SQL编辑器后，部署并启动作业。创建Catalog时可以设置默认的源表、维表和结果表的WITH参数，也可以设置创建Hologres物理表的默认属性，例如上方table_property开头的参数。a) 在Flink开发平台，新建名为ODS的SQL流作业（步骤与test作业相同，引擎一致），并将如下代码拷贝到SQL编辑器。创建作业后，将如下代码拷贝到test作业的SQL编辑器上，修改目标参数取值后，选中代码片段后单击左侧代码行上的运行。

行存表设置了Primary Key（PK）的场景，系统会自动生成一个Row Identifier（RID），RID用于定位整行数据，同时系统也会将PK设置为Distribution Key和Clustering Key，这样就能快速定位到数据所在的Shard和文件，在基于主键查询的场景上，只需要扫描一个主键就能快速拿到所有列的全行数据，提升查询效率。数据在底层存储时会存储两份，一份按照行存格式存储，一份按照列存格式存储，因此会带来更多的存储开销。

外部表在Hologres中不存储数据，只进行字段映射。通过外部表可以使用Hologres直接调用存储于MaxCompute公共空间MAXCOMPUTE_PUBLIC_DATA的数据。以下SQL语句用来创建名称分别为LINEITEM、ORDERS、PARTSUPP、PART、CUSTOMER、SUPPLIER、NATION和REGION的表，用于后续存储数据。

Hologres是阿里巴巴自主研发的一站式实时数仓引擎（Real-Time Data Warehouse），支持海量数据实时写入、实时更新、实时加工、实时分析，支持标准SQL（兼容PostgreSQL协议和语法，支持大部分PostgreSQL函数），支持PB级数据多维分析（OLAP）与即席分析（Ad Hoc），支持高并发低延迟的在线数据服务（Serving），支持多种负载的细粒度隔离与企业级安全能力，与MaxCompute、Flink、DataWorks深度融合，提供企业级离在线一体化全栈数仓解决方案。

相比之前的普通视图，物化视图就不需要每次都查询复杂SQL，每次查询的都是真实的物理存储地址中的一份数据（表）。如果要更新物化视图，可以采用触发器的形式，当原表中的数据被写后，可以通过触发器执行同步物化视图的操作。PostgreSQL中，对物化视图的同步，提供了两种方式，一种是全量更新，另一种是增量更新。视图对于用户来说，就是一张真实的表，可以直接基于视图查询一张或者多张表的信息。在有索引的情况下，再基于name做等值查询，看时间，同时看执行计划。在PGSQL中，简单（单表）的视图是允许写操作的。

2020年6月1日0时至6月18日24时，京东618全球年中购物节累计下单金额达到2692亿元，创下新的纪录。上市首日，京东股价报收于234港元，较发行价上涨3.54%，市值超过7200亿港元。2018年6月1日0点到6月18日24点，京东全球年中购物节累计下单金额达1592亿元。每年6月是京东的店庆月，每年6月18日是京东店庆日。从2019年6月1日0点到6月18日24点，累计下单金额达2015亿元，覆盖全球。1998年6月18日，刘强东在。活动，以“火红六月”为宣传点，其中6月18日是。

从测试和线上的表现来看，Doris引擎的表现还是非常优秀的。多维分析聚合查询场景对比Druid引擎有很大的性能优势，再加上Doris on ES的加持和上层业务的抽象，可以即拥有ES引擎强大的分词检索能力，又不失Olap场景海量数据的聚合分析性能。两者的结合可以为这类需求提供全新的解决方案与思路。在快手商业化业务场景里面，维度数据与事实数据Join查询是非常普遍的，有了比较不错的实践成果，后续会在Doris on ES解决方案上继续投入。

总结来说，如果要支持维度数据存储，并且支持Join，目前开源的各类引擎或多或少都存在一些局限性。Doris和Clickhouse这里引擎都支持Join，并且支持明细数据存储，但是如要要高频Update，也是没办法做到。如果跳出Olap引擎，在应用层做Join实现，也是一种解法，但是实现成本高。Doris on ES构建在这个能力之上，并且对查询做了大量的优化，这给对ES原理理解不深的同学带来了方便。目前Doris on ES还不支持聚合下推，但是对于我们维度数据查询场景其实是用不到聚合操作。

进而导致每个KIS task包含了所有取值的数据(我们生成环境KIS task数目与topic的partion数是一一对应的)，造成KIS task的segment文件大幅膨胀（两种区别的理论值为key By处理生成的segment大小为不做key by的 1/partion总数），影响实时数据的查询性能(这里如果没太看明白可以参考阅读Druid官方文档，了解Druid数据聚合、索引构建原理)。ES拥有强大的分词检索能力，支持较高频率的update操作，和很好的横向扩展能力。屏蔽复杂的跨引擎管理查询逻辑。

大宽表，空间换时间。理论上都是维表主键为唯一ID来填充所有维度，这样只是冗余存储了多条维度数据，但是在OLAP引擎里，不管是DRUID、KYLIN还是DORIS都不会造成数据量的基数膨胀。优势：维度数据与事实数据完全分离，维度数据用专门的引擎存储(如mysql、elasticsearch等等)，可以支持高频update操作，查询时通过主键关联查询维度数据。劣势：对应的弊端就是如果有维度数据update场景，支持的代价非常大。优势：应用层查询的时候非常方便，无需关联额外的维表，直接面向大而全的宽表查询。

对于明细数据在TiDB或者ES的，我们选择了在Flink中进行窗口聚合写入到下游Doris或者ES中。需要对监听的源表以及变更字段进行配置，在配置的interval时间窗口内多个源表进行扫描，然后将结果进行merge后生成参数，根据配置的threshold对参数进行拆分后传入多个insert sql中，并在每天凌晨进行T+1的全量聚合，修复微批计算的错误数据。由于之前我们的实时数仓只有ES，所以在使用Doris的初期，我们选择了通过Doris创建ES外表的方式来完善我们的Doris数仓底表。

理论上都是维表主键为唯一ID来填充所有维度，这样只是冗余存储了多条维度数据，但是在OLAP引擎里，不管是DRUID、KYLIN还是DORIS都不会造成数据量的基数膨胀。维度数据与事实数据完全分离，维度数据用专门的引擎存储(如mysql、elasticsearch等等)，可以支持高频update操作，查询时通过主键关联查询维度数据。业务场景主要为两大块——传统型的OLAP分析查询场景+星型模型join场景下的OLAP多维分析查询。应用层查询的时候非常方便，无需关联额外的维表，直接面向大而全的宽表查询。

Doris的引入推进了有道精品课数据分层的构建，加速了实时数仓的规范化进程。数据中台团队在此基础上一方面向全平台各业务线提供统一的数据接口，并依托于Doris生产实时数据看板，另一方面定时将实时数仓数据同步至下游离线数仓供分析师进行自助分析，为实时和离线场景提供数据支撑。

Spark Doris Connector 可以支持通过 Spark 读取 Doris 中存储的数据。编译成功后，会在 output/ 目录下生成文件。将此文件复制到 Spark 的 ClassPath 中即可使用 Spark-Doris-Connector。例如：Local 模式运行的 Spark，将此文件放入 jars/ 文件夹下。Yarn集群模式运行的Spark，则将此文件放入预部署包中。--Doris FE http 地址，支持多个地址，使用逗号分隔--

将一个字符串转化为一个BITAMP，字符串是由逗号分隔的一组UINT32数字组成. 比如”0, 1, 2”字符串会转化为一个Bitmap，其中的第0, 1, 2位被设置. 当输入字段不合法时，返回NULL。对任意类型的输入计算32位的哈希值，返回包含该哈希值的bitmap。将一个bitmap转化成一个逗号分隔的字符串，字符串中包含所有设置的BIT位。返回一个空bitmap。计算两个输入bitmap的交集，返回新的bitmap.计算两个输入bitmap的并集，返回新的bitmap.

BITMAP_UNION_COUNT(expr): 和 BITMAP_COUNT(BITMAP_UNION(expr)) 等价。它比 COUNT 和 DISTINCT 组合的速度更快，并使用固定大小的内存，因此对于高基数的列可以使用更少的内存。BITMAP_UNION(expr) : 计算两个 Bitmap 的并集，返回值是序列化后的 Bitmap 值。基于它得到的是一个估算结果，误差大概在1%左右，hll列是通过其它列或者导入数据里面的数据生成的。用于返回满足要求的行的数目。返回expr表达式的最大值。

如果 len 大于 str 的长度，则在 str 的后面不断补充 pad 字符，直到该字符串的长度达到 len 为止。如果 len 小于 str 的长度，该函数相当于截断 str 字符串，只返回长度为 len 的字符串。如果没有匹配，返回空字符串。将字符串 str 重复 count 次输出，count 小于1时返回空串，str，count 任一为NULL时，返回 NULL。它返回具有指定长度的字符串的右边部分, 长度的单位为utf8字符。将字符串反转，返回的字符串的顺序和源字符串的顺序相反。

如果 len 大于 str 的长度，则在 str 的前面不断补充 pad 字符，直到该字符串的长度达到 len 为止。如果 len 小于 str 的长度，该函数相当于截断 str 字符串，只返回长度为 len 的字符串。返回 substr 在 str 中出现的位置（从1开始计数）。如果指定第3个参数 pos，则从 str 以 pos 下标开始的字符串处开始查找 substr 出现的位置。如果 substr 不在 str 中出现，则返回0。它返回具有指定长度的字符串的左边部分, 长度的单位为utf8字符。

如果路径中包含 . ，则可以使用双引号包围。如果 json_string 格式不对，或 json_path 格式不对，或无法找到匹配项，则返回 NULL。如果 json_string 格式不对，或 json_path 格式不对，或无法找到匹配项，则返回 NULL。如果 json_string 格式不对，或 json_path 格式不对，或无法找到匹配项，则返回 NULL。使用第一个参数 sep 作为连接符，将第二个参数以及后续所有参数拼接成一个字符串. 如果分隔符是 NULL，返回 NULL。

其中center_lng表示的圆心的经度， center_lat表示的是圆心的纬度，radius表示的是圆的半径，单位是米,最大支持99999994。通过给定的X坐标值，Y坐标值返回对应的Point。计算地球两点之间的球面距离，单位为 米。传入的参数分别为X点的经度，X点的纬度，Y点的经度，Y点的纬度。将一个WKT（Well Known Text）转化为对应的内存的几何形式。当point是一个合法的POINT类型时，返回对应的X坐标值。当point是一个合法的POINT类型时，返回对应的Y坐标值。

返回datetime_expr2−datetime_expr1，其中datetime_expr1和datetime_expr2是日期或日期时间表达式。对于在 1970-01-01 00:00:00 之前或 2038-01-19 03:14:07 之后的时间，该函数将返回 0。TIMEDIFF函数返回表示为时间值的expr1 - expr2的结果，返回值为TIME类型。Format 的格式请参阅 date_format 函数的格式说明。获得日期中的秒的信息，返回值范围从0-59。

默认为 yyyy-MM-dd HH:mm:ss ,也支持date_format中的format格式。将 unix 时间戳转化为对应的 time 格式，返回的格式由 string_format 指定。参数为Date或者Datetime类型或者可以cast为Date或者Datetime类型的数字。DAYOFWEEK函数返回日期的工作日索引值，即星期日为1，星期一为2，星期六为7。获得日期中的小时的信息，返回值范围从0-23。获得日期中的分钟的信息，返回值范围从0-59。参数为Date或者Datetime类型。

转换datetime值dt，从 from_tz 由给定转到 to_tz 时区给出的时区，并返回的结果值。将日期类型按照format的类型转化为字符串， 当前支持最大128字节的字符串，如果返回值长度超过128，则返回NULL。%V | 周 (01-53) 星期日是一周的第一天，与 %X 使用。%v | 周 (01-53) 星期一是一周的第一天，与 %x 使用。%X | 年，其中的星期日是周的第一天，4 位，与 %V 使用。%x | 年，其中的星期一是周的第一天，4 位，与 %v 使用。

使用说明：每次查询的随机序列都会重置，多次调用rand 函数会产生相同的结果。功能：进制转换函数，返回某个整数在特定进制下的的字符串形式。使用说明：如果你需要确保所有返回值都是负值，可以使用-abs(a)函数。使用说明：如果你需要确保所有返回值都是正值，可以使用abs()函数。功能：返回log以base为底数，以a为指数的对数值。功能：将参数a的符号位取反，如果参数是负值，则返回正值。功能：返回参数的原值，即使参数是负的，仍然返回原值。功能：返回log以10为底数，以a为指数的对数值。

Colocation Join 功能，是将一组拥有相同 CGS 的 Table 组成一个 CG。并保证这些 Table 对应的数据分片会落在同一个 BE 节点上。使得当 CG 内的表进行分桶列上的 Join 操作时，可以通过直接进行本地数据 Join，减少数据在节点间的传输耗时。

数据导出的其他导出案例参考

数据导出（Export）是 Doris 提供的一种将数据导出的功能。该功能可以将用户指定的表或分区的数据，以文本的格式，通过 Broker 进程导出到远端存储上，如 HDFS/BOS 等。假设一共 10 个查询计划，当前已完成 3 个，则进度为 30%。表示 Export 作业中，一个查询计划在单个 BE 上的内存使用限制。broker：使用的 broker 的名称。coord num：查询计划的个数。

注：2019-12-31 和 2020-01-01 在同一周内，如果分区的起始日期为 2019-12-31，则分区名为 p2019_53，如果分区的起始日期为 2020-01-01，则分区名为 p2020_01。同时，因为分区列 k1 的类型为 DATETIME，则分区值会补全时分秒部分，且皆为 0。在 2020-06-15，即第25周时，会删除2周前的分区，即删除 p2020_22。设置为 7，则将删除7天前的分区，即删除分区 p20210215。创建一张调度单位为天，可以删除历史分区的动态分区表。

根据 time_unit 属性的不同，以当天（星期/月）为基准，分区范围在此偏移之前的分区将会被删除。在某些使用场景下，用户会将表按照天进行分区划分，每天定时执行例行任务，这时需要使用方手动管理分区，否则可能由于使用方没有创建分区导致数据导入失败，这给使用方带来了额外的维护成本。动态分区的时区，如果不填写，则默认为当前机器的系统的时区，例如 Asia/Shanghai，如果想获取当前支持的时区设置，可以参考。动态分区调度的单位。动态创建的分区所对应的副本数量，如果不填写，则默认为该表创建时指定的副本数量。

匹配到这个物化视图表后就需要对查询进行改写，将之前的对用户id求 count(distinct) 改为对物化视图中bitmap_union列求count。：刚才的查询选中mv_1后，将查询改写为从mv_1中读取数据，过滤出日志为2月10日的mv_1中的数据然后返回即可。因此，如果对数据的分析需求既覆盖了明细查询也存在分析类查询，则可以先创建一个明细模型的表，并构建物化视图。实际上物化视图是Rollup的一个超集，在覆盖Rollup的工作同时，还支持更灵活的聚合方式。最后再根据选择出的最优解，改写查询。

从表结构中可以看出，Base表的销售日期列是一个非排序列，而物化视图表的日期是一个排序列，同时聚合程度上mv_1表明显比Base表高。候选集过滤完后输出一个集合，这个集合中的所有表都能满足查询的需求，但每张表的查询效率都不同。这时候就需要在这个集合根据前缀索引是否能匹配到，以及聚合程度的高低来选出一个最优的物化视图。📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨。候选集过滤目前分为4层，每一层过滤后去除不满足条件的物化视图。这里再举一个相对复杂的例子，来体现这个过程。

查询物化视图和自动匹配

提交完创建物化视图的任务后，Doris就会异步在后台生成物化视图的数据，构建物化视图。在构建期间，用户依然可以正常的查询和导入新的数据。创建任务会自动处理当前的存量数据和所有新到达的增量数据，从而保持和Base表的数据一致性。

如果想要删除渠道为APP端的数据，由于存在一个物化视图并不包含渠道这个字段，则这个删除不能执行，因为删除在物化视图中无法被执行。物化视图创建成功后，用户的查询不需要发生任何改变，也就是还是查询的 base 表。Doris 会根据当前查询的语句去自动选择一个最优的物化视图，从物化视图中读取数据并计算。则会导致这张物化视图的性价比不高，既占用了集群的存储资源，还不能为更多的查询服务。创建物化视图是一个异步的操作，也就是说用户成功提交创建任务后，Doris 会在后台对存量的数据进行计算，直到创建成功。

从定义上来说，就是包含了查询结果的数据库对象，可能是对远程数据的本地Copy；也可能是一个表或多表Join后结果的行或列的子集；物化视图则在覆盖了 Rollup 的功能的同时，还能支持更丰富的聚合函数。物化视图是将预先计算（根据定义好的 SELECT 语句）好的数据集，存储在 Doris 中的一个特殊的表。物化视图的出现主要是为了满足用户，既能对原始明细数据的任意维度分析，也能快速的对固定维度进行分析查询。自动维护物化视图的数据会造成一些维护开销，会在后面的物化视图的局限性中展开说明。

也就是说，在 count(*) 查询中，Doris 必须扫描所有的 AGGREGATE KEY 列（这里就是 user_id 和 date），并且聚合后，才能得到语意正确的结果。因为在实现上，我们可以通过如“导入时对行进行计数，保存count的统计信息”，或者在查询时“仅扫描某一列数据，获得count值”的方式，只需很小的开销，即可获得查询结果。也就是说，任何还未聚合的数据（比如说两个不同导入批次的数据），必须通过某种方式，以保证对外展示的一致性。同时，这种一致性保证，在某些查询中，会极大的降低查询效率。

底层的数据存储，是按照各自建表语句中，AGGREGATE KEY、UNIQ KEY 和 DUPLICATE KEY 中指定的列进行排序存储的。这对于使用其他不能命中前缀索引的列作为条件进行的查询来说，效率上可能无法满足需求。Doris 这类 MPP 架构的 OLAP 数据库，通常都是通过提高并发，来处理大量数据的。可以看到，ROLLUP 和 Base 表的列完全一样，只是将 user_id 和 age 的顺序调换了。而前缀索引，即在排序的基础上，实现的一种根据给定前缀列，快速查询数据的索引方式。

可以看到，ROLLUP 中仅保留了每个 user_id，在 cost 列上的 SUM 的结果。Doris 会自动命中这个 ROLLUP 表，从而只需扫描极少的数据量，即可完成这次聚合查询。因为 Uniq 只是 Aggregate 模型的一个特例，所以这里我们不加以区别。

在 Doris 中，我们将用户通过建表语句创建出来的表成为 Base 表（Base Table）。Rollup可以理解为表的一个物化索引结构，Rollup可以调整列的顺序以增加前缀索引的命中率，也可以减少key列以增加数据的聚合度。可以看到，ROLLUP 和 Base 表的列完全一样，只是将 user_id 和 age 的顺序调换了。这些 ROLLUP 的数据是基于 Base 表产生的，并且在物理上是独立存储的。ROLLUP 表的基本作用，在于在 Base 表的基础上，获得。以site_visit表为例。