由于公司的mongoDB部署在容器平台在本地测试 没有问题   项目部署于容器平台之后 报pymongo.errors.OperationFailure: Authentication failed.之前有人遇到同样的问题 但是 导致认证失败的原因有多个    在stackoverflow上有类似方案 但是中文博客没有  导致 还是费了一番功夫做过的尝试：1.修改认

原因是pymongo  访问mongodb时 用到了  .function 调用一些方法   所以 MongoDB对key是由要求的  key中不能出现以下字符  Windows下：/ . " $ *: | ?Linux下：/ . " $我的业务上 以一个域名来作为key   域名中必然包含英文句号  用@取代英文句号

使用json格式化工具格式化，将特殊 空格 换行 符号替换。sublime打开ipynb,将文件改为 utf8格式。

获取容器平台使用权：是一个配置文件   放入  容器   ~/.kube目录下制作容器镜像1.定义容器：Dockerfile2.构建容器：docker build -t test:1.0 .上传容器镜像1.打标签：docker tag logextract:1.0  registry.k8s.intra.knownsec.com/songyx/logextract:1.02

维表关联系列目录:一、维表服务与Flink异步IO二、Mysql维表关联：全量加载三、Hbase维表关联：LRU策略四、Redis维表关联：实时查询五、kafka维表关联：广播方式六、自定义异步查询LRULRU(Least Recently Used)，最近最少使用缓存淘汰算法，认为最近访问过的数据在将来被访问的概率也比较大，当内存达到上限去淘汰那些最近访问较少的数据。在Flink中做维表关联时，

Kafka设计的初衷是迅速处理短小的消息，一般10K大小的消息吞吐性能最好（可参见LinkedIn的kafka性能测试）。但有时候，我们需要处理更大的消息，比如XML文档或JSON内容，一个消息差不多有10-100M，这种情况下，Kakfa应该如何处理？针对这个问题，有以下几个建议：  最好的方法是不直接传送这些大的数据。如果有共享存储，如NAS, HDFS, S3等，可以把这些大

Kafka的消息是保存或缓存在磁盘上的，你可能会认为：在磁盘上读写数据是会降低性能的，因为寻址会比较消耗时间。事实上，磁盘读写的快慢取决于你怎么使用它了（顺序读写、随机读写）。Kafka的设计目标是高吞吐量，它比其它消息系统快的原因体现在以下几方面：1、Kafka操作的是序列文件I / O（序列文件的特征是按顺序写，按顺序读），为保证顺序，Kafka强制点对点的按顺序传递消息，这意

spark streaming每个 job的数据量 与以下几个参数有关。1. 批次间隔时间，例如5秒拉取一次2. 自己配置的 每个partition 一次最少拉取的条数假设5秒一个批次 ，kafka 5个partition，配置每个partition最少拉取1000条那么最终一个Job中的数据条数 25000条（1000*5*5)（正常情况下）。如果kafka有数据堆积，比如...

1个partition只能被同组的一个consumer消费，同组的consumer则起到均衡效果消费者多于partitiontopic： test 只有一个partition创建一个topic——test，bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --part

网络相关大数据分析架构用kafka+ spark + hadoop比较好，还是ELK的解决方案比较好？不考虑机器学习，主要是用到spark的sql和streaming来做定时处理和数据聚合查询，发现elk也能完成同样的功能，ELK是不是相对来说轻量很多，更容易部署和维护？不是同一个领域的东西elk主要做搜索，日志，不太适合做大数据统计，当然数据量不大，或者在现有数据上顺便