A | I - Augmented Intelligence - Analytics, Data Mining, and Big Data architectures and supporting ...
Title: A | I - Augmented Intelligence - Analytics, Data Mining, and Big Data architectures and supporting ...
Description: A | I - Augmented Intelligence - Analytics, Data Mining, and Big Data architectures and supporting practices by Don Krapohl Skip to content A | I – Augmented Intelligence Analytics, Data Mining, and B is ranked 5944919 in the world (amongst the 40 million domains). A low-numbered rank means that this website gets lots of visitors. This site is relatively popular among users in the united states. It gets 50% of its traffic from the united states .This site is estimated to be worth $3,324. This site has a low Pagerank(0/10). It has 1 backlinks. has 43% seo score. Information

Website / Domain:
Website IP Address:
Domain DNS Server:, Rank

Alexa Rank: 5944919
Google Page Rank: 0/10 (Google Pagerank Has Been Closed) Traffic & Earnings

Purchase/Sale Value: $3,324
Daily Revenue: $9
Monthly Revenue $273
Yearly Revenue: $3,324
Daily Unique Visitors 838
Monthly Unique Visitors: 25,140
Yearly Unique Visitors: 305,870 WebSite Httpheader

StatusCode 200
Cache-Control no-cache, must-revalidate, max-age=0
Content-Type text/html; charset=UTF-8
Server Microsoft-IIS/7.5
Date Thu, 04 Aug 2016 16:09:56 GMT Keywords accounting

Keyword Count Percentage Traffic Sources Chart Similar Website

Domain Site Title Data Analytics, Big Data, Data Consulting, Business Intelligence, Master Data Management Business Intelligence and Data Analytics Web :: Business Intelligence, Data Mining y Analytics para Empresas Analytics, Data Mining, and Data Science Intelligence Computing | Cloud,Big Data,Analytics,IoT,Cognitive,Intelligence,AI Java Data Mining Package | Machine Learning and Big Data Analytics Analytics Blog | Data Science | Big Data | Business Intelligence Big Data Systems | Business Intelligence | Smart Data Analytics Ireland Scalable Systems - Big Data, Analytics, Integration, Intelligence Business Intelligence Services - Big Data & Analytics Experts Alexa Rank History Chart aleax Html To Plain Text

A | I - Augmented Intelligence - Analytics, Data Mining, and Big Data architectures and supporting practices by Don Krapohl Skip to content A | I – Augmented Intelligence Analytics, Data Mining, and Big Data architectures and supporting practices by Don Krapohl Menu and widgets Search for: Archives July 2015 January 2015 March 2014 January 2014 July 2013 June 2013 May 2013 Categories Events Practices Resources Strategy Technologies Uncategorized Meta Log in Entries RSS Comments RSS TDWI speaking engagement I’ll be speaking with Scott Wallace at the TDWI Executive Conference in San Diego on September 21st, 2015. Information and agenda online Posted on July 20, 2015July 20, 2015Categories Events, Uncategorized Double effective IO on AWS EBS-backed volumes A frequently overlooked task on Amazon Cloud instances is pre-warming the EBS volumes. Per Amazon ( failure to pre-warm EBS volumes incurs a 5-50% loss in effective IOPS. Worst case that means you could DOUBLE the IO portion of your HDFS writes until each sector has been touched by the kernel. Amazon asserts that this performance loss, amortized over the life of a disk, is inconsequential to most applications. For one of our current clusters we have a portion with 8-1TB drives in each of 10 compute nodes as a baseline. Our estimated pre-warm time is 30 hours on each mount point so if done sequentially that’s 2,400 hours to touch each drive block. What does this imply? Without pre-warming we would have added as much as 2,400 additional hours of write latency during initial HDFS writes and that latency could appear in many different places in the stack (HDFS direct writes, Hive postgresql/mysql metadata writes and management, log writes, etc.) Read the AWS document above carefully as it will ERASE EVERYTHING ON THE DISK if you use the first method in their article. The steps below will execute this safely on disks with existing content. To pre-warm the drives on your cluster: stop the cluster services ssh into each server execute lsblk and note the mount points (they likely start from /dev/xvdf and go down from there increasing the letter at the end, such as /dev/xvdg, /dev/xvdh, etc.) unmount each one at a time with sudo umount /ONEMOUNTPOINT Continue until all mount points are unmounted, meaning there’s nothing shown after the ‘disk’ column as below: CAUTION: DO NOT DO THE FOLLOWING ON A MOUNTED DISK AND MAKE SURE YOU USE THE SAME MOUNT FOR BOTH if AND of execute the following, changing the if= and of= to the same mount pointsudo dd if=/YOURMOUNTPOINT of=/YOURSAMEMOUNTPOINT conv=notrunc bs=1MExample: sudo dd if=/dev/xvdf of=/dev/xvdf conv=notrunc bs=1M Wait. It’ll be a few minutes for a 32GB drive as shown in the Amazon write-up above or 1 day+ for a 1TB drive. After ALL the processes on the server complete, reboot the server If you’d like to check the process or if your ssh session has expired and you want to ensure you’re still warming execute ps aux|grep YOURMOUNTPOINT , example: ps aux |grep /dev/xvdf A far better approach, of course, would be to automate this as part of your cluster deployment process using Chef or equivalent infrastructure automation tool. Posted on January 23, 2015January 23, 2015Categories Technologies How to recover a corrupt HDFS namenode Scenario 1: There was data, the logs say Namenode not formatted, the (check your config to see where it is) is empty Cause: The data was emptied out of your namenode directory. Things to try (in order): FSCK (see scenario 2 below) recover the namenode hadoop namenode start -recover If the output says some directories are missing, create them, chgrp to hadoop, chown to hdfs, chmod 755, then run again Import the fsimage from a non-corrupt secondary namenode hadoop namenode -importCheckpoint If the output says some directories are missing, create them, chgrp to hadoop, chown to hdfs, chmod 755, then run again Brute force it Find out in the config where the snn checkpoint is kept (fs.checkpoint.dir) SCP down ALL the files in the fs.checkpoint.dir to your local machine SCP up ALL the files you just downloaded to the For all those files chgrp to hadoop, chown to hdfs, chmod 755 Start your HDFS service as usual through the cluster manager and think optimistic thoughts. Scenario 2: There was data, the logs point to corrupt blocks Cause: Probably a bad termination signal during copy or high volume data movement with bad network Things to try (in order): FSCK You can use hadoop fsck / to determine which files are having problems. Look through the output for missing or corrupt blocks (ignore under-replicated blocks for now). This command is really verbose especially on a large HDFS filesystem so I normally get down to the meaningful output with hadoop fsck / | egrep -v '^\.+$' | grep -v eplica which ignores lines with nothing but dots and lines talking about replication. Once you find a file that is corrupt hadoop fsck /path/to/corrupt/file -locations -blocks -files Use that output to determine where blocks might live. If the file is larger than your block size it might have multiple blocks. You can use the reported block numbers to go around to the datanodes and the namenode logs searching for the machine or machines on which the blocks lived. Try looking for filesystem errors on those machines. Missing mount points, datanode not running, file system reformatted/reprovisioned. If you can find a problem in that way and bring the block back online that file will be healthy again. Lather rinse and repeat until all files are healthy or you exhaust all alternatives looking for the blocks. Once you determine what happened and you cannot recover any more blocks, just use the hadoop fs -rm /path/to/file/with/permanently/missing/blocks command to get your HDFS filesystem back to healthy so you can start tracking new errors as they occur. Scenario 3: Secondary Namenode can’t checkpoint the namenode the SNN logs show checkpoint failed, probably with missing txid=#### Change /etc/fstab and set the mount point to allow fsck on boot vi /etc/fstab as root Change the last zero in the first line to one, so change: LABEL=cloudimg-rootfs / ext4 defaults 0 0 to LABEL=cloudimg-rootfs / ext4 defaults 0 1 Save the file and exit Change the FSCKFIX in /etc/default/rcS to yes vi /etc/default/rcS as root Find the line that says #FSCKFIX=no Change it to FSCKFIX=yes (make sure you remove the commenting # at the beginning) Save and exit Check and record the last FSCK run execute and record the output of sudo tune2fs -l /dev/xvda1 | grep “Last checked” Reboot (use AWS instance reboot or do it from ssh) Check that FSCK ran on boot execute and verify that the date changed using sudo tune2fs -l /dev/xvda1 | grep “Last checked” Reverse the changes you made in steps 1 and 2 Reboot Posted on January 21, 2015January 23, 2015Categories Technologies, Uncategorized Posts navigation Page 1 Page 2 … Page 10 Next page Proudly powered by WordPress Whois

Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to
for detailed information.
  Registrar: ENOM, INC.
  Sponsoring Registrar IANA ID: 48
  Whois Server:
  Referral URL:
  Name Server: NS1.BRINKSTER.COM
  Name Server: NS2.BRINKSTER.COM
  Status: clientTransferProhibited
  Updated Date: 19-dec-2015
  Creation Date: 17-sep-2012
  Expiration Date: 17-sep-2017
>>> Last update of whois database: Mon, 16 May 2016 06:57:21 GMT <<<
For more information on Whois status codes, please visit
NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and