olap
画像 doris+es
1、过去画像也是es 好用不代表能用好，
画像场景，看里面人群数，符合某些条件的人群数有多少？统计级
select count() groupby xxx 语义. 重要不优雅，用户需要学习dsl。包一层平台可以解决
人群如果有1000万（有将近1千多万条数据，大概占用空间有 300G 左右），几百万，导出来就比较崩溃，es 怎么用接口，并发导出，分布式读，并发控制，es黑科技，平台复杂度较高。普通用户对于高级玩法做不到。
几十万，几十分钟很正常，用游标scoll来做，如果失败，需要重跑，几千万，上亿就跑不出来了
doris on es 实现，列存，本地优先扫描，不排序(es 本身会排序，节省了很多计算开销)，性能解决了，并且可以直接写sql了，不用写dsl了，扩展性，用户可以直接写sql了。中台必要的能力
更新场景，doris 更新不好，提升查询性能，需要做很多预计算，预计算需要有规则的。分析场景，维度跟指标要定义好，可以通过维度可以把指标预计算出来，画像场景，主键或者叫维度，更新大量是指标，查的时候要根据指标去查，某个年龄，金额大于xxx的，某个地域是xxx的人群是多少个，属性来查询。doris需要索引，排序，查询速度非常快，因为会预聚合，更新的结果应不应该在结果集中，性能会掉的很厉害，但是更新满足不了，
es 通过docid就可以更新了，性能一般，但是好歹是支持的。并且不影响读取。
所以画像场景，es把更新搞定，doris把上层查询搞定，查询快，有sql接口.
画像场景key 就是uid,其他都是属性一直在更新。预计算，就是终端类型android ios,地市，我想看北京市下的ios的用户数总共有多少人，报名人数，这种就是根据维度，预聚合求和，
kylin是所有维度预计算变成kv查询，这样会有维度爆炸，存储成本很高，加维度不方便，无法实时
，doris可以实时更新维度 tables schema change，上线没有kylin那么快，不会是毫秒级别的，做不到kylin那种kv查询，全部用预计算，比如要算几千万uv，每天都要groupby,如果现查询，肯定做不到秒出，
doris 要源源不断的更新的，并且可以计算的很好。也有物化视图，功能米有ck那么丰富，用不到太高级的能力，加一个rollup上卷就搞定了，一个物化视图的子集
clickhouse是一坨数据扔进去，查询会非常快
k1 k2 k3（城市） 维度列，pv uv 指标求最大，最小值，求k1 k3 算pv uv 可以k1 k3 pv uv做一个上卷，直接可以命中rollup列
clichouse 物化视图是跑sql，定期跑sql,doris做的是实时的，不是微批的，写的时候就把预计合全做了。
doris 预计算会把结果存在一个独立的表中，对外是可见的，sql会自动路由到rollup表里，自动分析sql的，可以指定维度和指标做预计算，业务是知道哪些是常用列，
es—doris+es 数据是不用动的，doris把es当成一个外表，挂上去就可以了，实时可用，外表创建成功了，fe模块会跟es元数据信息拉取es原信息，shard信息会拉取过来，doris访问失败，基本上都是因为es某个节点失败了，运维排查一下就好了
dorisdb数据更新，es就不用了，es维护成本太高了，需要写两套不同的实现，写入es keyword,doris必须是varchar int就会有问题，sql就解析失败了，doris有date类型，datetime有可能有不兼容问题，会查不出来。
es 类型不敏感，类型对应不上就会很麻烦。现在客户是通过平台化统一了，做了对应关系。
最终一致性，事务要求也不高，从业务库过来变成日志流了，客户对doris熟悉，人和事都认识，文档技术大家都知道，有问题会有人快速响应。
clickhouse运维复杂，c++,很难运维
目前所有分析都用doris,字段变更也很常见，现在有平台,改完字段，可以直接掉doris接口，alter table接口，不影响业务，无感知的
系统要能把控，技术做不深入 做proxy 做一些屏蔽 做平台化建设。在平台化解决掉
教学和拉新，1、统计类，分析
拉新，投放 端上PV uv多少人+业务的指标 来源，维度列可以枚举出来的。直接用doris
doris+es
1、老业务，裸用es 迁移doris 有成本。
2、微批架构 lamada kappy flink读业务流写到两个es表，ods–dwd,跟业务侧比较近，上面写sql 5分钟调度一次，当前时间往前推5分钟，a表更新3行，跟b表进行更新，如果join到了，说明b表也有更新了，
flinksql跟doris语法不一样，开发环境也不同，dwd dws ad 全部都是doris sql
select xxxx into xxx表，5分钟调度一次
flink实时，多留Join很麻烦
选择标准，微批数据不能太多，如果数据太多，还是走离线回灌回去
flink更新数据量很大，用redis做维表，doris不适合
对于客户要求要计算时间较长的数据，从doris再同步到hive里面去一份，这样就可以了，短时查询用doris，长周期用hive查，一个指标出口复用，但是不同需求，不同语法是合理的，目前在跟投放合作，还没有大规模用起来
腾讯没有调度系统
airflow 运维工作，对客户没有价值，体量？
clickhouse 可以通过shuddingkey 让多个表相同数据到同一个节点吗？