Kevin__Durant的博客

Impala内存不够、查询超出内存的原因以及优化方式【附官网链接与解决过程】

背景适用于配置化传入Flink全局参数；项目起源于公司多数据源对接，此Demo只是其中一种，整个过程是公司前端部门因为各方渠道传入的不同数据，风控的业务方需要保留进行规则查询；数据流转过程就是Kafka接入不同数据源，按照不同的要求进行es的直接存储或者查询拼接后的存储；摘要关键字Flink_Elasticsearch查询、Elasticsearch_Sink、Flink全局配置化参数；设计整个过程比较简单，每个类中注释很详细；Kafka_Source对接数据源；Mapper_P

背景适用于配置化操作流，无需终止流式程序实现配置，并且以广播流的形式在流式程序中使用；实现MySQL_Source配置信息动态定时更新；实现MySQL_Source广播流，此处使用最常用的keyby广播流KeyedBroadcastProcessFunction；摘要关键字MySQL_Source、Flink广播流；设计MyJdbcSource日常创建一个继承源富函数的类；初始化单连接；配置更新时间设置自己可以编写方法应用；配置化Flink广播流；获取配置S

背景- 大数据架构业务场景中需要实时数据落入ES，基本上是业务数据，目的是为了封装后作为规则引擎的变量提供，是变量系统的一部分；- 架构数据流来源于Maxwell，Spark Streaming做数据流处理，落库使用RestHighLevelClient的同步提交Bulk写入；增删改此文档不涉及，主要就是客户端以及查询的封装，为后续变量系统的应用部分；客户端streaming直接使用def createESClientNew(): RestHighLevelClient = { new Re

背景接入Kafka实时数据经过数据处理写入HBase，后续会应用于类似变量系统以及实时日志中，对于变量系统这类中间需要做实时缓存宽表可能使用HBase连接极其频繁，所以是使用客户端还是Sink的方式就看实际情况而定，具体数据处理后的落库Sink还是比较方便的；摘要关键字Flink，Sink，HBase，数据处理，数据流转设计使用的是Max Well数据源，将业务数据接入Kafka，Flink-Source接入Kafka，中间经过数据流转将数据存储到HBase作实时表；实现说明

背景部分API数据需要实时接入，数据分析师以及风控部门实时调用做规则，尝试使用HBase做映射使用Impala提供分析，HBase做接口返回实时数据结果；摘要关键字Flink将商城接入的API实时数据写入HBase设计Flink对接Kafka数据源，数据处理之后在客户端直接写入，较低效，每条数据需要建立连接；说明因为是一个简单的开始Demo，刚开始使用Flink写入，所以有很多待优化的地方，也是需要跟进学习的地方；Demo为使用HBase客户端，并非标准的Flink-HBas

背景互联网金融，面对的业务方较多；风控部门的数据分析师，策略分析师，反欺诈分析师等，目前的数据量这些分析师使用Python以及MySQL是无法满足快速高效的分析的；商城、运营部门等的报表看板，定制化用户行为分析等。；目前的自主分析是使用的开源产品Superset做一部分的改造，接入Druid，ES，Impala，分析师们已经全部转到我们的平台，大部分的使用都是基于我们数仓的DWS，但是除此之外实时数据没有完全接入，这是目前的痛点，也是最需要做的；尝试使用HBase做映射使用Impala分析，但是只能按照

背景当前公司为互联网金融公司，面对的业务方较多；风控部门的数据分析师，策略分析师，反欺诈分析师等，目前的数据量这些分析师使用Python以及MySQL是无法满足快速高效的分析的；商城、运营部门等的报表看板，定制化用户行为分析等。；目前的自主分析是使用的开源产品Superset做一部分的改造，接入Druid，ES，Impala，分析师们已经全部转到我们的平台，大部分的使用都是基于我们数仓的DWS，但是除此之外实时数据没有完全接入，这是目前的痛点，也是最需要做的；尝试使用HBase做映射使用Impala分析

实时数仓离线→实时介绍从某种角度而言，实时数仓是针对基础实时应用的优化版，避免实时处理的烟囱式发展，分层管理，数仓思想，逻辑、性能优化，提高了代码的复用率和整体生产效率。从离线到实时的角度而言，实时性更强了，能够满足即时性的需求，数据本身的价值有所增加。抛出问题有离线数仓了，做实时数仓，是否能兼顾到以前的指标体系，是不是可以直接替代？类似于画像体系是否可以在此基础上进行构建？实...