Open russellchang54 opened 7 years ago
docker命令报证书过期错误,主要原因是RHEL的证书库太旧了,要更新RHEL的证书库即可
启用docker remote api, docker engine启动时加参数
-H unix:///var/run/docker.sock -H tcp://0.0.0.0:18383
普通用户 使用docker :
重新登陆
交通大数据平台
1,源数据接入
将数据从从已有系统中经过抽取、清洗、转换、加载至交通大数据平台的过程
2,实时数据流处理
事前、事中 实时分析处理 RTAP
接受实时交通数据流,是实现实时交通监控系统的数据基础,能够为指挥调度、道路规划、事故预警等交通信息管理和决策提供支持,为交通用户提供更为全面和便捷的服务。
该子系统包含数 据流管理系统,提供对数据流的连续查询和混合查询支持。连续查询用于实时持续不断地监控,如“查 询超速的车辆信息”以及“开始监控违法车辆行踪”是连续运行的查询,后者涉及空间数据库。用户 可以指定连续查询的滑动时间窗口,对于进入窗口且符合查询条件的事件进行报警监控。混合查询用 于那些不仅需要涉及动态流数据还需要访问静态历史和空间数据的复杂查询,如“统计未来 5 分钟内 从黄龙流出的车流量”。 交通流的实时监控、交通拥堵状况的实时信息、交通诱导等应用均要求系统能够返回当前的交通状态
3,大数据综合分析
事后,复杂事件处理 CEP、联机分析处理 OLAP、深度分析 OLAM
运用各种先进的数据处理技术,包括数据集成技术、人工智能与数据挖掘技术、 决策支持与专家系统等,根据各交通子系统的需求和它们之间的内在联系,对来自多来源渠道、格式 不一致的数据在综合交通信息的基础上进行抽取、集成,并进行深度分析与处理,获得可用于决策的 模式、模型、规则和知识。
需要改造传统的数据挖掘、机器学习算法,以适应大数据的需要
大数据OLAP平台:CDH + Hive + Kylin + HBase
分布式计算引擎:Hadoop的MR VS spark
spark: spark sql,spark streaming,spark mlib,spark GraphX
Spark 在具体业务上的应用: 1》用户画像、模型迭代以及一些推荐算法直接使用MLIB 2》实时统计分析:spark streaming 3》复杂的ETL:使用 Spark 通过 cache 中间结果(Redis),然后再统计其他维度,大大地减少了 I/O 消耗,显著地提升了统计处理速度
apache kylin: 1>cube 构建引擎 2>元数据 3>路由 4>查询引擎 5>REST server
MPP的思考(VS hadoop): 优点: 1》快 2》SQL的支持 3》BI的外延工具 1》和2》kylin解决,另外传统的BI厂家都会像hadoop靠拢
缺点: 1》扩展性:架构本身的问题。MPP DB还是基于原DB扩展而来,DB里面天然追求一致性(Consistency),必然带来分区容错性较差。集群规模变得太大,业务数据太多时,
MPP DB的元数据管理就完全是一个灾难。元数据巨大无比,一旦出错很难恢复,动不动导致毁库
所以 MPP DB要在扩展性上有质的提升,要对元数据,以及数据存储有架构上的突破,降低对一致性的要求,否则的话很难相信一个MPP DB数据库是可以容易扩展
2》并发的支持:单个查询通过分割为多个子查询,通过多线程并发暴力扫描来实现高速。单个查询来说,动用了整个系统的能力,单个查询比较快。从目前实际使用的经验来说,也就支持50~100的并发能力
HBASE为什么号称支持上千并发,这也是在特定的场景下(带row key)才能实现的。复杂查询场景下,什么系统都歇菜?(kylin)
所以MPP DB应用场景适合小集群(100节点以内),低并发的(50左右)的场景
分析&挖掘系统 应用的两个场景
场景一:用大数据技术,不到1秒即可得到从24亿条过车数据中的机动车号牌查询出的精确结果和行车轨迹。如果遇到交通案件侦破需要侦破, 过去需要警察通过肉眼在图像中识别犯罪车辆,安装了大数据处理系统之后机动车违法图像信息门可根据车辆的颜色、车型、号牌等信息实时查询其历史行为、 行车路线和车辆营运公司、驾驶人等关联信息,也许几十天完成的工作量可以在十秒钟时间内完成。
场景二: 在使用信用卡的过程中也有许多大数据的应用,比如某金融机构的信用卡中心拥有大量银行卡实时交易数据,该中心需要打造开放的大数据平台使得各业务部门可以挖掘这些数据中的价值。 大数据的软件可以根据刷卡消费的时间、金额和种类,分析商圈的范围和密度,找出特定消费类别的重点区域和重点人群。根据刷卡记录分析持卡人的行为特征, 如年龄阶段、性别、支付能力、消费频繁度、兴趣爱好、职业性质等等,采用协同过滤等机器学习算法为持卡人推荐合适的商户或产品。从持卡人复杂的连续交易行为中挖掘出规律, 一方面找出沉默用户并分析流失可能性,另一方面利用消费规律下推测该用户在未来一段时间内很大概率会发生的消费行为,进行精准的营销
图计算应用场景:
利用“图计算”实现大规模实时预测分析
图数据结构很好的表达了数据之间的关联性( dependencies between data ),关联性计算是大数据计算的核心——通过获得数据的关联性,可以从噪音很多的海量数据中抽取有用的信息。 比如,通过为购物者之间的关系建模,就能很快找到口味相似的用户,并为之推荐商品;或者在社交网络中,通过传播关系发现意见领袖。 但现有的并行计算框架像MapReduce还无法满足复杂的关联性计算
在GraphX上实现。这些模型应用于用户网络的社区发现、用户影响力、能量传播、标签传播等,可以提升用户黏性和活跃度; 而应用到推荐领域的标签推理、人群划分、年龄段预测、商品交易时序跳转,则可以提升推荐的丰富度和准确性。
docker run...报错 exec: "docker-proxy": executable file not found in $PATH. 修改配置文件 /etc/systemd/system/docker.service,尤其是ExecStart的配置,确保以下配置: ExecStart=/usr/bin/dockerd-current \ --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current \ --default-runtime=docker-runc \ --exec-opt native.cgroupdriver=systemd \ --userland-proxy-path=/usr/libexec/docker/docker-proxy-current \
服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/?utm_source=tuicool&utm_medium=referral
Zookeeper-Zookeeper可以干什么 http://www.cnblogs.com/yuyijq/p/3424473.html 其中 在中心配置、分布式锁、集群管理的使用包括: zk+ hbase(Cassandra) : 集群配置信息,region/region server 的管理,master 的 leader 选举 zk + dubbo: 服务治理,集群配置信息,leader选举 zk + kafka: 维护broker信息,集群配置信息,消息的消费进度(offset)
用本地已有的仓库,”填“ remote 之空仓库
git remote rm origin
git remote add origin https://xxxx/yy/aa.git
git push -u origin master
ssh 签名登陆(切换到对应的用户下,如jenkins) jenkins@k8s#ssh-keygen -t rsa --------------生成密钥对
jenkins@k8s#cd .ssh jenkins@k8s#cp id_rsa.pub authorized_keys
//copy /home/avatar/.ssh/id_rsa to windows,再用puttygen 打开id_rsa,再保存成putty格式的私钥(.ppk)
jenkins@k8s#ssh-copy-id -i id_rsa.pub slave -------- 上传公钥至/home/jenkins/.ssh目录
如果本地 与 远程一致,可以直接:ssh ;如果不一致,要把私钥拷贝到当前用户的.ssh目录下。如通过ssh 密钥免密登陆 服务器slave,假如当前用户为root,免密的用户为jenkins,ssh服务的端口2222。把id_rsa 拷贝到/home/root/.ssh/id_rsa
root@k8s#ssh -p 2222 jenkins@slave
如果当前用户为jenkins jenkins@k8s#ssh -p 2222 slave