科学的N次方

【代码】Flinkcdc通过catalog同步mysql数据到hologres的ods中。

制定技术侧埋点规范以实现系统性能监控，主要包括以下几个关键步骤：

通过创建物化视图，可以将原始数据汇总、摘要，以适应不同层次和粒度的分析需求，从而提高查询的灵活性和效率。

总之，通过上述步骤，可以构建出一个基于Flink和Hologres的实时数仓，实现数据的实时处理、存储和分析，帮助企业快速响应市场变化，提升决策效率。

通过以上步骤，你应该能够较为全面地排查出 Flink 实时计算从 Hologres 源表到目标表的错误，并找到解决方案。

–create table xxxx(log_time bigint,ord_id bigint,biz_type int,status int,city_id int,city_name varchar,start_charge_time timestamp(3),end_charge_time timestamp(3),cancel_source varchar,car_type int,risk_type int,is_normal int,call_time strin

在模型设计时多事务事实表和累积快照事实表的选取，如果是基于多个业务过程联合分析而构建的事实表，比如订单全流程表应设计为累积快照事实表，而多事务事实表应该是有多个业务过程，多个度量，并且这些业务过程还应该有一定的相似性，度量差异大时，采用多字段分别记录多个业务过程的发生时间和相关度量的 方式实现，度量差异不大时，采用“事件 时间+事件类型方式”多记录方式存储，下游取对应事务的统计数据时，只需要统计数据处理日期该事务对应的当日是否发生标签为是对应的数据即可。数据域->业务流程->粒度->度量

1 源消息乱序 由于我们的业务数据是整库从mysql。由于我们的消息源是通过。

基础是标准化、规范化建立数据仓库，面向主题的、集成的、相对稳定的、反映历史变化的数据集合，以支持管理决策decision making大数据：大量volumn、多样variety、快速velocity、价值密度低value、准确性veracity、可视化visualization、合法性validity多源数据、多样数据、提炼并应用数据价值平台化及场景化的数据仓库、元数据管理、主数据管理、数据质量、数据泄漏、数据科学云上数据中台致力于构建标准统一、融会贯通、资产化、服务化和闭环自优化的智能大数据体

埋点方案设计是指在软件开发或者数据分析中，为了跟踪用户行为、收集数据以及进行分析，需要在代码中插入一些埋点（Tracking）代码，记录用户在应用中的各种操作和行为。确定埋点点：根据需求确定需要埋点的地方，包括页面浏览、按钮点击、表单提交等，一般来说可以分为页面级别埋点和事件级别埋点。实施埋点：根据埋点计划，在代码中插入埋点代码，记录用户的各种操作和行为，并将数据上报到埋点工具或自建埋点系统。制定埋点计划：根据确定的埋点点，制定具体的埋点计划，包括埋点的代码实现、数据上报的方式、数据格式等。

增量数据采集，目前实现的方式是hive中按某个字段创建分区表，insert override的时候where语句带上对应的增量过滤条件。我一般选取日期字段ETL_DATE。hive建立分区表，hql如下：CREATE TABLE IF NOT EXISTS product_sell(category_id BIGINT,province_id BIGINT,product_id BIGINT,price DOUBLE,sell_num BIGINT)PARTITIONED BY (ds

在hive中认为null在排序时为最小值，即ASC排序时在最前面，DESC排序时在最后。语法：order by 字段名 asc/desc（升序/降序）4. 当order by 遇到null 时，将如何排序？order by默认是升序排序，所以asc可以省略。例如，对a1字段生序排序，a2字段降序排序。3. 多字段混合排序。

带窗口聚合时，你可以指定一个时间窗口（如过去一小时、过去一天等），并在这个时间窗口内对 key 进行聚合。这允许你分析在特定时间范围内的数据，而不是整个历史数据集。这个聚合是基于 key 的所有历史数据进行的，不考虑时间窗口或数据排序。在处理流数据时特别有用，因为它允许你分析数据的实时变化，而不仅仅是整个数据集的历史聚合。查询将返回每个用户在每个一小时窗口内的行为数。带窗口聚合的主要区别在于它们如何处理数据的时间维度和计算结果的粒度。函数用于确定每个小时的时间窗口的开始时间，而。这些区别使得带窗口的。

【代码】hive udf 判断四边形是否为矩形。

这个错误通常表示Flink程序中使用了某个类或接口中不存在的字段。具体而言，这个错误通常与使用Flink API中的字符串相关函数有关，比如TextOutputFormat.setField加入了不存在的字段。这次我是遇到第四点了，本地使用Flink是1.13.0，集群是flink1.12.0 , 使用的是不同的版本，存在API不兼容的问题。

select date_add(last_day(add_months(‘datadesc′,−2)),1);−−上月月初selectlastday(addmonths(′{data_desc}', -2)), 1);--上月月初select last_day(add_months('datad​esc′,−2)),1);−−上月月初selectlastd​ay(addm​onths(′{data_desc}’, -1));–上月月末select date_add(last_day(add_mon

JVM堆大小：JVM堆大小越大，可以同时运行的线程数就越多。因此，我们可以尝试提高JVM堆大小以提高并发度，从而降低CPU和内存的使用量。数据规模：Flink任务需要的CPU和内存与数据规模成正比。如果数据规模较大，那么任务需要更多的CPU和内存来处理数据。Flink任务需要的CPU和内存取决于任务的具体实现和数据规模。并行度：Flink任务的并行度越高，需要的CPU和内存就越多。

并发优化：Flink任务需要多个线程或进程来并发执行计算操作。因此，我们需要尽可能地提高并发度以提高任务的性能和效率。CPU优化：Flink任务需要大量的CPU资源来执行计算操作。因此，我们需要尽可能地减少CPU的使用量。内存优化：Flink任务需要大量的内存来存储数据和状态信息。因此，我们需要尽可能地减少内存的使用量。flink实时计算任务可以从以下四个方面进行优化。

flinksql

SPARKSQL 如何获取一个开始日期到结束日期的连续月份

【代码】flink scala sourceTest。

kafka命令行

Spark On Yarn模式启动流程

spark的宽依赖和窄依赖

补齐工单状态

最近有个字段里面存的是个数字数组，需要提取一个最大的元素作为结果输出，编写一个UDF完成此需求。

在sparksq下，也可以使用grouping(xx)来组合多维cube的维度组合。

实时分析城市天气对订单的影响，并实时调整营销策略。

sparksql中Grouping__ID的推理hivesql中Grouping__ID的推理

–1 计算子项的聚合值create table tmp_xxxx_20220322as select user_id ,item_id ,count(ord_id) as item_ord_cnt_1dfrom xxxxgroup by user_id,item_id;–2 按 company_id 计算子项的累积select a.company_id ,round(power(10, sum(lo

什么是Watermaker？Watermaker 是和 event_time相匹配的。Watermaker就是基于event_time 给消息再额外的加的一个时间列也就是Watermaker是个时间戳!如何计算Watermaker？Watermaker = 当前窗口的最大的事件时间 - 最大允许的延迟时间或乱序时间Watermaker水位线会一直上升(变大),不会下降Watermaker有什么用？Watermaker是用来触发窗口计算的！Watermaker如何触发窗口计算的？窗口计

基于flinksql的kafka-upsert案例

1 ）一个kafka的topic order{“ord_id”:“1”,“city_id”:“300100”,“submit_time”:“2021-11-25 11:32:24”,“total_fee”:25}{“ord_id”:“1”,“city_id”:“300100”,“submit_time”:“2021-11-25 11:32:55”,“total_fee”:25}{“ord_id”:“1”,“city_id”:“300100”,“submit_time”:“2021-11-25 11:3

flinksql里面最常用的事情就是时间格式转换，比如各种时间格式转换成TIMESTAMP(3).

从业八年来，一直在做数仓相关工作，慢慢的发现数仓的难点在于什么？有人说是模型的构建，比如明细层DWD是按照业务过程来构建事实表，还是按照主题来构建事实表，还有人说是指标的定义，如果划分原子指标，派生指标。其实，我个人觉得这些都是过程，站在最终的结果导向上来看，数仓的痛点就在于如何保障数据的一致性，正确性和时效性的统一，目前看来前路应该是流批一体。 单就目前还是流批分离的情况下，离线数仓在一致性和正确性上基本没有太大的难点，但是在时效性上，却存在明显的短板。因为全过程的数据一致性，基本上在无论是mpp架构.

因公司发展需要，需半小时统计一次截止到当前时间的关键指标的当日累计值。v1.0 链路采取的是 kafka-> clickhouse在设计的时候，一开始本人是想一个flinksql从source到transform到sink完成.v2.0 链路采取的是 kafka->kafka-> clickhouse奈何公司平台sink到ck的时候不支持upsert流。因此只能分解到先用一个flinksql加工出dwd.再起一个任务从dwd读数加工到ck....

一、明细层分区日期为终态业务过程日期，其余归档30001231分区采用二级分区：create table target_table(COL …) partitioned by (state string,dt string);–partition(state=“china”,dt)，表示state为静态分区，dt为动态分区，以src_table中的city字段为分区名insert overwrite table target_table partition(state=“3”,dt) selec

一、明细层分区日期为数据数据处理日期每次ods层来的是新增与变化的记录，可能一个业务主键会有多条事件记录，中间状态数据不会丢失。对数据处理日期该事件是否发生打标签每天新增与变化的数据里面，通过状态和事件发生时间（与数据处理日期相比较），如果是事件处理日期发生的事件，则标记为is_td_xxx发生，字段值赋为1，当然也存在数据处理日期前发生的记录，因为有其他属性值发生变更导致存在于当日变化的数据里面，这部分数据因为is_td_xxx为false,0 ,后续汇总层统计时，并没有计算在内。二、汇总层

sudo systemctl start gitlab-runsvdirsudo gitlab-ctl restart

一张表dwd_user_log 有如下字段：1）直播间： live_id2）用户:userid3）时间戳:date_stamp4）登陆类型:entry_type (登入in和登出out)求某天每个直播间最大在线人数？select live_id,max(total_users) max_total_usersfrom ( selectlive_id,userid,date_stamp,sum(ind) over (partition by live_id order by date_s