Kudu 删除表range分区

https://kudu.apache.org/docs/command_line_tools_reference.html#table-drop_range_partition

注意事项

1. 一次只能删一个分区
2. 分区条件必须前后精准匹配
3. 可以通过kudu table describe查看表信息（包括分区信息）：

1
2

# 查看表信息，包括列、分区信息
kudu table describe 10.128.2.162:7051,10.128.2.72:7051,10.128.2.172:7051 bn_op_1228

Kudu 表复制（表数据迁移）

https://kudu.apache.org/docs/command_line_tools_reference.html#table-copy

注意事项：

1. 要求复制表于原表的列的结构一致（不要求分区和副本一致，所以可以调整表的副本数）
2. 可以先只复制表结构
3. predicates 预言 大小比值 只支持数值类型，时间戳类型不支持
4. 注意超时设置
5. write_type 参数有3种：
   1. 空字符 ，表示只复制表结构
   2. insert，直接插入
   3. upsert，更新插入

行为数据存储中的分区和分桶

存储引擎一般都支持分区分桶

分区的意义在于将数据分散到多个子目录中，在执行查询时，可以只选择查询某些子目录中的数据来加快查询效率。

分桶的意义实际和分区一样，只是并非所有的数据都可以形成合理的分区，而分桶可以弥补分区这个缺陷，将数据集分解为若干部分

分区可以做多级分区，分区的个数可以指定，也可以由程序自动生成， 分区是可以动态增长的

分桶的个数是一经决定，就不能更改，所以如果要改变桶数，要重新插入分桶数据

行为数据本质是时序数据，所以分割的关键要素第一肯定是 时间，第二个分割的关键要素就是 事件

分布式 Trace 数据模型

distributed-tracing 数据模型

通过跟踪从前端到后端的交互，通过trace数据，可以扩展现有的错误数据，跟踪软件的性能，测量吞吐量和延迟等指标，并显示跨多个系统的错误影响：

• 出现特定错误事件或问题时发生了什么
• 哪些因素导致应用程序出现瓶颈或延迟问题
• 哪些的endpoint或操作消耗时间最多

什么是追踪？

首先，请注意Trace不是什么：Trace不是分析。尽管概要分析和跟踪的目标有相当多的重叠，虽然它们都可用于诊断应用程序中的问题，但它们在测量的内容和记录数据的方式方面有所不同。

一个Profiler可以测量任何数目的应用程序的操作的各方面的：指令执行数，正在使用的各种处理的内存量，给定的时间的函数调用需要的量，等等。生成的配置文件是这些测量值的统计汇总。

一个tracer工具，在另一方面，侧重于什么事（何时），而不是发生了多少次发生或者花了多长时间。trace的结果是在程序执行期间发生的事件日志，这些事件往往跨越多个系统。就 Sentry 的跟踪而言，总是——包括时间戳，允许计算持续时间，但测量性能并不是它们的唯一目的。它们还可以显示互连系统交互的方式，以及一个系统中的问题可能导致另一个系统出现问题的方式。

（备注：除了测量性能外，还可以做故障的根因分析）

如何理解session分析

假设我们是个电商企业，包含了web端,app,小程序的产品。以下是小王访问产品的行为序列：

1. 启动(平台=JS)
2. 浏览页面(平台=js,商品=男装)
3. 浏览页面(平台=js,商品=手机)
4. 浏览商品详情(平台=js,商品=手机)
5. 加入收藏(平台=JS,商品=手机)
6. 浏览页面(平台=js,商品=食品)
7. 启动(平台=JS)
8. 浏览页面(平台=js,商品=电脑)
9. 浏览商品详情(平台=js,商品=电脑)
10. 加入购物车(平台=js，商品=电脑)
11. 提交订单(平台=安卓，商品=电脑)
12. 订单详情(平台=安卓，商品=电脑）
13. 确认支付、完成订单(平台=后端埋点)
14. 结束(平台=安卓)
15. 启动(平台=小程序)
16. 我的订单(平台=小程序)

小王同学的这一系列行为，应该算成几次会话呢？

漏斗的计算

漏斗的计算归根到底是计算用户最长转化步骤的问题

1. 漏斗一般默认是按照日期分组，所以漏斗的问题，实际上是计算用户在每日以及整个统计周期内，最长转化步骤的问题。
2. 漏斗往往是多步的，那么就有可能在不同时间周期内完成。因此我们约定，以首事件发生的周期，作为本次漏斗转换的统计周期。（为什么不用目标事件呢，个人的理解是，首先不是每次转换都会有目标的达成，且每次转换的最长步骤可能都不一样）
3. 漏斗的计算，每一个周期的计算都是独立的。比如 A1-A2-B的行为序列。A1 发生在1号 A2-B发生在2号。 那么1号 2号都会认为完成了A-B的转换。 这么做是为了避免统计结果会因为选择的时间范围不同而发生变化。

往往，用户的最长转换的路径不是唯一的。如果是简单漏斗，即 我只需要计算每一个步骤的转换人数。那么不唯一就是不重要的。但是，如果我希望去分析这一次转换，比如 看转换时间、分组 等等。那么就必然需要 挑选出唯一的路径。我们称之为 最优的转换的路径

最优转换的路径的规则就是规则中的：优先选择更靠近最终转化目标的事件作为转化事件，并在第一次到达目标事件时，停止继续计算

漏斗的基础规则

漏斗分析是帮助运营人员分析一个多步骤过程中每一步的转化和流失情况。

假设我们在购买商品的过程，需要触发的事件包括“启动”，“登录”，“搜索商品”，“查看商品”，“生成订单”等。运营人员需要分析某段时间类（比如2020-01-01 到2020-01-07），在全部用户中依次有序触发了“登录” =》“搜索商品”=》“查看商品”=》“生成订单”事件的人群的转化流失情况，即计算全部用户中触发了“登录”事件的总人数A，A中触发了“搜索商品”事件的总人数B，B中触发了“查看商品”事件的总人数C，以及C中触发“生成订单”事件的总人数D

在进行漏斗计算时，实际情况会更加复杂，在时间范围内，用户的行为明细会出现多次包含在漏斗定义中的事件，那么会优先选择更靠近最终转化目标的事件作为转化事件，并且在第一次到达目标事件时，停止继续计算。下面的例子，转换的步骤是什么？

例1: 登陆-生成订单-搜索商品-查看商品-生成订单

例2: 登陆-搜索商品-登陆-搜索商品-搜索商品-查看商品-生成订单-生成订单

例3: 登陆-搜索商品-查看商品-生成订单-登陆-搜索商品-查看商品-生成订单

用户行为分析基础模型的约束概述

不同于传统的BI工具，用户行为分析中的所有分析模型均是基于元数据抽象的分析模型，它底层的数据模型其实是非常简单的，即三个主体模型：用户、事件以及item，其中item只是补充作用

基础模型的特点

1. 基于元数据来构建的
2. 去业务的
3. 有约束的
   1. 基于事件、用户、item模型
   2. 约定数据格式
4. 统一用户的标识（多端的用户打通、登录前和登录后的打通）

后续的分析模型都是解决一类特定场景的问题，先定义场景，再拆解场景，最后在套用模型进行分析

主体描述：

事件：可追加，无状态的数据。用主谓宾来描述 谁在什么时候什么地点以什么方式做了一件什么事情，其5要素为：